Agent篇

Agent包含哪些模塊，實現了什么功能

Agent 就像一個多功能的接口，它能夠接觸并使用一套工具。根據用戶的輸入，Agent會規劃出一條解決用戶問題的路線，決定其中需要調用哪些工具，并調用這些工具。Agent = 大語言模型+規劃+記憶+工具使用，具備以下關鍵能力：

規劃（Planning）：最核心最關鍵的部分，負責拆解復雜任務為可執行的子任務，并規劃執行任務的流程。同時Agent還會對任務執行的過程進行思考和反思，決定是否繼續執行任務，并改進決策策略。
- 任務分解：將復雜任務分解為可執行的子任務，讓大模型逐步解決，例如將訂外賣分解為選擇餐廳+選擇菜品兩步。關鍵技術例如CoT、LLM+P等。
- 反思：Agent 通過完善過去的行動決策和糾正以前的錯誤來不斷改進。關鍵技術例如React、Reflexion等。
記憶（Memory）：包括短期記憶和長期記憶，用于存儲會話上下文和業務數據等信息，來優化未來行為。
- 短時記憶：即上下文學習，由于受到Transformer上下文窗口長度的限制，它是短暫的和有限的。
- 長期記憶：則可對應為外部的向量數據存儲，Agent 可在查詢時引用，并可通過快速檢索進行訪問。
工具使用（Tools）：通過調用外部工具（如API、插件）擴展Agent的能力，如文檔解析、代碼編譯等。

你有開發過Agent嗎，知道哪些Agent開發平臺

扣子coze（字節）
通義千問（阿里）
元器智能體（騰訊）
文心智能體（百度）
Dify
Fastgpt

開放式問題：談談你對Agent的理解

在Agent誕生之前，有兩種方式能使機器智能化：

基于規則的方法：將人類指令轉化成機器能理解的規則符號，這需要有豐富經驗的人類專家，并且容錯很低。
基于強化學習的方法：構建策略模型和獎勵模型，需要大量的數據進行訓練。

隨著大模型的誕生，人類利用其在邏輯推理、工具應用、策略規劃等方面的能力，構建以大模型為核心的Agent系統，極大的提升了機器的智能化程度。當然，為了進一步提升Agent的性能，還提出了CoT等規劃方法、引入記憶和工具模塊，使得Agent越來越逼近人類的思考方式。

從人機合作的角度出發，Agent 改變了人機合作的方式。截至現在，主要有三種模式：

人類主導：代表是SaaS+AI模式，人類完成大多數工作，而AI只負責完成特定任務。例如AI只負責實現人臉識別、OCR等能力，嵌入到人類操作的SaaS軟件中，其他功能AI不參與。
AI作為人類助手：代表是Copilot模式，AI可以隨時輔助人類完成各種任務，不再局限于特定的功能。
AI主導：代表Agent模式，人類只負責提出需求，在AI負責完成的過程中，可能需要人類進行進一步的描述需求、點評AI生成內容質量、矯正AI理解等。而Agent正式通往AGI（Artificial General Intelligence）的必經之路。

你怎么對Agent進行分類

按照工作模型可以分為單Agent、多Agent和混合Agent三種。

單Agent：

特點：由一個獨立的智能體構成，所有的決策和執行都集中在一個智能體上，沒有與其他智能體的協調和通信需求，適用于單一任務或相對簡單的任務。
優點：不需要處理多個智能體之間的協調問題，也不需要額外的資源來管理多個智能體。
缺點：難以處理復雜、多變的環境，并且如果Agent出現故障，整個系統都將癱瘓。
應用場景：比如專門用于進行市場分析調研的Agent。

多Agent：

定義：多個Agent協同工作，相互交流信息，共同完成更復雜的任務或目標。多個智能體在分布式環境中獨立運行，每個智能體可以自主決策，需要處理智能體之間的通信、協調和競爭等問題。
優點：能夠處理復雜、動態和多變的環境，可以完成單個智能體難以完成的任務。多個智能體之間可以相互協作，即使部分智能體出現故障系統仍然可以正常工作，魯棒性強。能根據環境和任務需求動態調整，具有可拓展性。
缺點：需要大量的通信和協調來確保智能體之間的同步和協作。
應用場景：比如一家公司就可以視為一個多Agent系統，由Agent來扮演產品經理、UI設計師、研發工程師、測試人員、項目經理等角色。
例子：斯坦福小鎮

混合Agent：

定義：Agent系統和人類共同參與決策過程，交互合作完成任務，強調的是人機協作的重要性和互補性。這種系統通常包含一個或多個智能體，以及與人類用戶的交互接口。
優點：通過人類的參與，混合Agent系統可以更好地處理復雜和多變的任務，提高任務完成的質量和效率，靈活地調整人類和智能體的角色和任務分配，提供更個性化和人性化的服務。
缺點：開發難度和復雜度較高。
應用場景：醫生和Agent可以共同進行病情診斷，Agent負責快速分析病人的醫療記錄、影像資料等，提供初步的診斷建議；而醫生則可以基于Agent的分析結果和自己的專業知識和經驗，做出最終的診斷決定。

Planning是怎么實現的

目前Agent大部分的planning邏輯，是通過提示詞（prompt），手動告訴 LLM 它該怎么思考、怎么分步執行的。實際系統里常常先通過人工/程序硬編碼固定主干流程以及有嚴格要求的核心業務，再在需要模型能力的節點中（例如創新、總結、標注、推理等任務），通過 Prompt 來讓模型做局部規劃或執行，從而在靈活和可控之間找到平衡。

Prompt 更像“指導”或“原則”，讓模型在這些原則內自由思考、制定和執行流程，適合需要靈活應變、創造性或自動化程度高的場景。
人工/程序硬編碼的流程，適合高度可控、可預測、合規、安全的任務；這些場景往往我們不希望模型自由發揮。

舉個例子，比如在電商系統中，身份信息驗證不能出錯，售后政策有明確規定，這些都適合人工編碼。而智能客服則可以通過prompt指導LLM來進行回復。

CoT

思維鏈將復雜的問題分解為更簡單的任務，逐步解決問題，使用CoT能在算數、常識和推理任務都提高了性能。但這會增加推理的時間。CoT可以分為Few-Shot 和Zero-Shot（Zero-Shot 只需要在prompt中加入“讓我們一步步的思考”）兩種。

ToT

在需要多步驟推理的任務中，引導語言模型搜索一棵由連貫的語言序列（解決問題的中間步驟）組成的思維樹，而不是簡單地生成一個答案。ToT框架的核心思想是：讓模型生成和評估其思維的能力，并將其與搜索算法（如廣度優先搜索和深度優先搜索）結合起來，進行系統性地探索和驗證。對于每個任務，將其分解為多個步驟，為每個步驟提出多個方案，在多條思維路徑中搜尋最優的方案。

ReAct

ReAct的任務解決軌跡是Thought-Action-Observation，可以簡化為模型按照Reasoning-Acting框架。Reasoning包括了對當前環境和狀態的觀察，并生成推理軌跡。這使模型能夠誘導、跟蹤和更新操作計劃，甚至處理異常情況。ReAct的每一個推理過程都會被詳細記錄在案，這也改善大模型解決問題時的可解釋性和可信度；Acting在于指導大模型采取下一步的行動，比如與外部源（如知識庫或環境）進行交互并且收集信息，或者給出最終答案。

Reflexion

Redlextion采用了強化學習的方法，Reflexion代理在生成每一個軌跡后，進行啟發式評估，生成反思文本并保留在記憶緩沖區中，以誘導在隨后的嘗試中做出更好的決策。

你還了解哪些比較新的planning算法

我了解BabyAGI和AutoGPT

BabyAGI 使用一個“Task List”來管理所有待辦任務。它有三個主要組件：

Task Creation Agent: 根據當前任務、執行結果，不斷新建子任務。
Task Prioritization Agent: 對現有任務重新排序，決定執行順序。
Execution Agent: 真正去執行當前的任務（通常是調用LLM/工具等）。

循環流程

從 “Task List” 中取出最高優先級的任務。
調用 Execution Agent 去執行。
把執行結果（Result）交給 Task Creation Agent，是否需要生成新的子任務？
把更新后的任務列表給 Task Prioritization Agent，排序并循環。

AutoGPT 也有一個任務/目標管理系統，也能生成子任務并執行。它側重更豐富的“工具”支持，如聯網、讀取/寫入文件、執行代碼等，包含以下模塊：

AI Config: 存放 AI 的角色、名稱、目標等基礎信息。
Memory: 把過去的重要信息存下來，供下一步參考。
Planner（或類似角色）: 生成下一步要干啥。
Command Executor: 解析 LLM 返回的命令，然后在外部執行相應操作。

介紹以下記憶模塊

記憶模塊是智能體存儲內部日志的關鍵組成部分，負責存儲過去的思考、行動、觀察以及與用戶的互動。

短期記憶關注于當前情境的上下文信息，是短暫且有限的，通常通過上下文窗口限制的學習實現。
長期記憶儲存智能體的歷史行為和思考，通過外部向量存儲實現，以便快速檢索重要信息。
混合記憶 -通過整合短期和長期記憶，不僅優化了智能體對當前情境的理解，還加強了對過去經驗的利用，從而提高了其長期推理和經驗積累的能力。

為什么要使用Memory-based agent

從認知心理學角度：對于人類的認知來說，記憶重要的模塊，agent想要替代人類完成一些任務，就要表現的像人類，為agent設置代理模塊。
從自我進化角度：在完成任務的過程中，agent也需要在與環境交互時自我進化。記憶能幫助agent積累經驗、探索更多的環境、抽象出概括性信息以增強泛化性。
從agent應用角度：在很多應用中記憶是不可取代的，例如chatgpt、虛擬角色。

Function call

為什么要用function call？

以前的LLM只能依靠自己已有的知識回答問題，無法直接獲取實時數據、也無法與外部系統交互。

Function Call 是一種實現大型語言模型連接外部工具的機制。通過 API 調用 LLM 時，調用方可以描述函數，包括函數的功能描述、請求參數說明、響應參數說明，讓 LLM 根據用戶的輸入，合適地選擇調用哪個函數，同時理解用戶的自然語言，并轉換為調用函數的請求參數（通過 JSON 格式返回）。調用方使用 LLM 返回的函數名稱和參數，調用函數并得到響應。最后，如果需要，把函數的響應傳給 LLM，讓 LLM 組織成自然語言回復用戶。

大模型的function call能力是如何獲得的？

主要通過對基礎模型進行sft獲得，基礎模型需要先具備良好的指令遵循和代碼/結構化數據生成能力。

sft的核心思想，是要教會LLM兩件事：

1、識別意圖：理解用戶的請求是否需要借助外部工具/函數來完成，而不是直接生成文本回答。

2、參數提取與格式化：如果需要調用函數，需要能夠正確地從用戶請求中抽取出所需的參數，并按照預先定義的格式（通常是json）生成函數調用的指令。

sft的過程如下：

步驟 1：數據集構建：構建包含 Function Calling 場景的指令微調數據集，每條數據樣本包含用戶輸入（可能需調用函數或直接回答的請求）、可用函數 / 工具描述（函數用途、參數類型等結構化文本）、期望輸出（需調用函數時為含函數名與參數的 JSON，否則為直接文本回答）。
步驟 2：選擇基礎模型：選用具備強大指令遵循能力的預訓練大模型（如 Llama、GPT、Qwen 等）。
步驟 3：格式化訓練數據：將 “用戶輸入” 與 “可用函數描述” 拼接為模型輸入（Prompt），“期望輸出”（JSON 函數調用或文本回答）作為目標輸出（Completion/Target），通過特定分隔符或模板區分。
步驟 4：進行微調：使用標準 SFT 方法（全參數微調或 PEFT 如 LoRA）在數據集上訓練，優化目標為最小化預測輸出與期望輸出的差異（如交叉熵損失），使模型學會根據輸入與函數描述，決定直接回答或生成特定格式的函數調用 JSON。

通過上述監督微調流程，大模型掌握識別意圖（判斷是否需調用外部工具）與參數提取格式化（正確抽取參數并生成規范函數調用指令）的能力，從而獲得 Function Call 能力。

Function - Call 數據集的基本結構包含哪些部分？

Function - Call 數據集基本結構通常包含：

[系統提示 / 全局指令]（可選）：設定角色、能力邊界等。
[可用函數 / 工具描述區]：詳細列出每個可用函數的結構化描述。
[對話歷史]（可選，多輪對話重要）：記錄用戶（User）和助理（Assistant）的交互歷史及當前用戶請求。
[觸發指令 / 分隔符]：提示模型開始思考或生成，如 “Assistant:”。

Function - Call數據集中可用函數/工具描述區的格式是怎樣的？

通常使用JSON列表或結構化文本，包含以下核心字段：

[  {  "name": "函數名",  "description": "函數功能描述",  "parameters": {  "type": "object",  "properties": {  "參數名": {  "type": "數據類型",  "description": "參數含義描述"  }  },  "required": ["必填參數名列表"]  }  }  
]

例如：

{  "name": "get_weather",  "description": "查詢指定城市和日期的天氣信息",  "parameters": {  "type": "object",  "properties": {  "city": {  "type": "string",  "description": "需要查詢天氣的城市名稱，例如：北京"  },  "date": {  "type": "string",  "description": "需要查詢的日期，例如：今天、明天、2023 - 10 - 26"  }  },  "required": ["city", "date"]  }  
}

Function - Call數據集的關鍵要素有哪些？

name：函數的唯一標識符。
description：用自然語言清晰描述函數的功能和適用場景，是模型判斷何時調用的關鍵。
parameters：定義函數接受的參數，包含：
- type：通常為"object"。
- properties：列出每個參數的名稱、數據類型（如string、integer）和描述。
- required：必須提供的參數名稱列表。

Function - Call數據集中對話流程的格式是怎樣的？

用戶請求：用戶發出指令（如“幫我查一下明天上海的天氣，然后給張三發郵件”）。
模型首次響應（Function Call）：模型識別后生成調用函數的JSON（如get_weather）。
外部執行：應用程序調用實際工具（如天氣API）。
結果喂回模型：將工具執行結果格式化后再次輸入模型（如天氣結果{"temperature": "25°C", "condition": "晴朗"}）。
模型再次響應：可能再次調用函數（如send_email）或生成最終回答（如“已查詢并發送郵件”）。

如何將下游工具、插件轉化為模型可理解的方式？

核心是標準化描述和執行對接：

標準化描述（Standardized Description）：
- 為工具設計符合Function Call格式的結構化描述（如JSON Schema），包含唯一名稱（Name）、功能描述（Description）、參數定義（Parameters）。
- 描述語言自然準確，避免歧義。
執行對接（Execution Bridging）：
- 將工具描述作為上下文傳遞給模型。
- 解析模型輸出的Function Call JSON，調用實際工具，處理參數校驗和結果，再將結果反饋給模型。

簡述Function Call的工作原理

LLM接收用戶提示：用戶輸入請求。
LLM決定所需工具：根據提示判斷調用哪些工具。
程序處理調用請求：開發者實現邏輯，接收LLM的工具調用請求并準備參數。
執行函數調用：將帶參數的函數調用傳遞給后端服務執行，結果再反饋給LLM用于后續處理。

HuggingGPT

HuggingGPT是由大型語言模型（LLM）驅動的，設計用來自主處理一系列復雜的人工智能任務。HuggingGPT融合了ChatGPT與HuggingFace。具體來說，LLM在這里扮演著大腦的角色，一方面根據用戶請求拆解任務，另一方面依據任務描述選擇適合的模型執行任務。通過執行這些模型并將結果整合到計劃的任務中，HuggingGPT能自主完成復雜的用戶請求。下圖展示了從任務規劃到模型選擇，再到任務執行，最后是響應生成的完整流程：