關于 Agent 的定義目前還沒有形成共識，目前有3個代表性的定義：

流行最廣的是前 OpenAI 研究與安全副總裁 Lilian Weng 對 Agent 的定義：Agent = LLM + Planning + Tools + Memory。

除此之外，LangChain 對 Agent 的定義為：使用 LLM 決定應用程序控制流的系統。

OpenAI 對 Agent 的定義是：Agent 是能夠代表用戶自主完成任務的系統。

盡管目前對 Agent 的定義還沒形成共識，但是大家對 Agentic System（智能系統）基本的共識是：Agentic System 是一種有目標、基于環境的決策系統。與 LLM 最大的區別在于，Agentic System 可以與現實世界交互，從感知環境開始，做出決策并執行，影響環境，然后基于反饋調整，不斷持續迭代循環。

1、Agentic System 架構設計剖析

一個完整的 Agentic System 架構包含四個核心組成部分：

• 感知：為大模型構建上下文信息。常見的方法包括檢索增強生成（RAG），查詢結構化數據（比如：數據庫、網頁內容）或者檢索歷史記錄（比如：長短期記憶）。
• 決策：本質上是 Planning 規劃過程。可以通過規則引擎（Workflow）實現，也可以由大語言模型（LLM）驅動（自主 Agent），或者借助外部規劃器。在設計時需要權衡泛化能力和準確性--LLM 驅動的決策泛化能力強，但不確定性較高；而基于規則的工作流泛化能力較弱，但更可控。
• 執行：通過調用工具來改變環境。包括 API 調用（比如：REST、RPC、SQL、函數調用）或與圖形軟件的集成（比如：Anthropic 的 Computer use）。
• 反饋：用于評估和迭代的機制。反饋可以通過人工標注、規則或模型生成，更新可以是離線的或在線的。

這個閉環構成了 Agent 的基礎單元（building block）。復雜的 Agent 可以由多個小 Agent 組成，復雜業務邏輯大決策通常由一系列小型決策構成。

2、多 Agentic System 架構設計原則

當多個 Agent 協同工作時，就構成了 Multi-Agent 系統。在設計 Multi-Agent 系統時，要避免過度拆分。每個 Agent 應該代表一個明確的業務決策點，并可以通過持續反饋進行優化。只有在單個 Agent 無法滿足需求時，才考慮引入更多的 Agent。

第一、借鑒分布式系統的思路，可以把 Agent 比作一臺計算機：

• LLM（大語言模型）是計算機的CPU，負責處理和運算。
• Context window（上下文窗口）是計算機的內存，用于臨時存儲信息。
• 向量數據庫是計算機的硬盤，用于長期存儲數據。
• 工具（Tools）是計算機上的程序，用于執行特定任務。

分布式系統主要解決以下三個問題：

1. 性能不足：單臺計算機的計算或存儲能力有限。
2. 容錯性：單個系統容易出現故障，需要多個系統協同工作以提高可靠性。
3. 協作：不同團隊負責不同的微服務，需要協同工作。

Multi-Agent 系統的設計原則與此類似：

• 解決單次 LLM 調用智力不足的問題：當單個 Agent 無法處理復雜的任務時，可以引入多個 Agent 協同工作。
• 提高容錯性：多個 Agent 協同工作可以提高系統的可靠性和穩定性。
• 促進協作：不同 Agent 可以負責不同的任務或決策點，實現更復雜的業務邏輯。

第二、Agentic System 架構演進

Multi-Agent 系統的設計應從單個 Agent 開始，只有在單個 Agent 無法滿足需求時，才逐步過渡到多 Agent 架構。這種逐步擴展的方式有助于保持系統的簡潔性和可維護性。

3、從單 Agent 到多 Agent 智能助手案例架構演進

智能助手的演進遵循了從單 Agent 到 Multi-Agent 的路徑：

• 初始階段：僅有產品問答模塊，使用簡單的 RAG（檢索增強生成）技術。
• 技能擴展：添加多種技能，但用戶需要手動切換。
• 意圖識別：開發意圖識別 Agent，但仍為單 Agent 架構。
• 多 Agent 體系：隨著場景復雜化和多團隊協作需求的增加，逐步過渡到多 Agent 體系。

除架構演進外，我們還進行了多項技術優化：

• RAG 優化：增加查詢改寫功能，提高系統的魯棒性。用戶不一定會提出完美的問題，通過查詢擴展和改寫，系統能夠更好地處理各種輸入變化。
• 知識圖譜：引入 GraphRAG 技術，將產品知識問答的準確度從 76% 提升到 93%。對于算法實力一般但工程能力強的團隊，知識圖譜是模型后訓練的實用替代方案。
• 強化學習：在經營分析場景中，將評價體系（如 AARRR 模型）轉化為強化學習的獎勵函數，實現模型的持續優化。

當然，我們也在經營分析場景中基于 SFT（監督微調）和強化學習進行微調。我們之前基于經營分析 Agent 構建的數據集和評價體系，天然地過渡到了 RL（強化學習）領域的環境和獎勵函數的構建。我們之前評價一個經營建議好壞的一個重要指標是思考過程是否符合 AARRR 模型，現在在 RL 中，這個指標也成為了獎勵函數之一。

本文轉載自??玄姐聊AGI??  作者：玄姐