OpenAI最強競對Anthropic：如何構建有效的Agent
在過去的一年里，我們與數十個團隊合作，在各個行業構建了很多大型語言模型（LLM）Agent。其中最成功的實現都沒有使用複雜的框架或專門的庫。相反，構建它們時用的是簡單、可組合的一些模式。
在這篇文章中，我們分享了從與客戶合作和自己構建 Agent 的經驗中學到的知識，並為開發人員提供了構建有效 Agent 的實用建議。
什麼是 Agent？
「Agent」可以用幾種方式來定義。一些客戶將 Agent 定義為完全自主的系統，它們在較長時間內獨立運行，使用各種工具來完成複雜的任務。其他人使用該術語來描述遵循一些預定義工作流的，更具規範性的實現。在 Anthropic，我們將所有這些變體都歸類為 Agentic 系統，但我們在工作流 和 Agent 之間劃出了一個重要的架構區別：
- 工作流是通過預定義代碼路徑編排 LLM 和工具的系統。
- 另一方面，Agent 是由 LLM 動態指導其自身的流程和工具使用的系統，從而控制其完成任務的方式。
下面，我們將詳細探討這兩種類型的 Agent 系統。在附錄 1（「實踐中的 Agent」）中，我們描述了客戶發現使用此類系統會特別有價值的兩個領域。
何時（以及何時不使用）Agent
在使用 LLM 構建應用程序時，我們建議找到最簡單的解決方案，並且僅在需要時增加複雜性。這可能意味著完全不用構建 Agent 系統。Agent 系統通常會犧牲延遲和成本來換取更好的任務性能，你應該考慮這種權衡何時才是有意義的。
當需要更多複雜性時，工作流可為明確定義的任務提供可預測性和一致性，而當需要大規模靈活性和模型驅動的決策時，Agent 是更好的選擇。但對於許多應用程序而言，使用檢索和上下文示例來優化單個 LLM 調用通常就足夠了。
何時以及如何使用框架
有許多框架能讓 Agent 系統更容易實現，包括：
- LangChain 的 LangGraph；
- Amazon Bedrock 的 AI Agent 框架；
- Rivet，一個拖放式 GUI LLM 工作流構建器；
- Vellum，另一個用於構建和測試複雜工作流的 GUI 工具。
這些框架通過簡化標準的低級任務（如調用 LLM、定義和解析工具以及將不同的調用鏈接在一起）來降低入門門檻。但它們通常會創建額外的抽像層，這些抽像層可能會掩蓋底層的提示和響應，使它們更難調試。當更簡單的設置就夠用時，它們還會讓人們傾向於增加複雜性。
我們建議開發人員一開始就直接使用 LLM API：許多模式用幾行代碼就能實現。如果你確實在使用某個框架，請確保你瞭解底層代碼。對底層內容的錯誤假設是客戶錯誤的常見來源。
請參閱我們的示例菜譜（https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents），瞭解一些示例實現。
構建塊、工作流和 Agent
在本節中，我們將探討在生產中看到的一些 Agent 系統的常見模式。我們將從基礎構建塊（增強型 LLM）開始，並逐步增加複雜性，從簡單的組合工作流談到自主 Agent。
構建塊：增強型 LLM
Agent 系統的基本構建塊是增強了檢索、工具和記憶等功能的一個 LLM。我們當前的模型可以主動使用這些能力，生成自己的搜索查詢、選擇合適的工具以及判斷要保留哪些信息。
增強型 LLM對於這種實現，我們建議關注兩個關鍵方面：根據你的特定用例定製這些功能，並確保他們為你的 LLM 提供了簡單、有良好文檔的界面。有很多方法可以實現這些增強功能，一種方法是通過我們最近發佈的模型上下文協議，它允許開發人員通過簡單的客戶端實現來同不斷擴大的第三方工具生態系統集成起來。
在本文的其餘部分，我們假設每個 LLM 調用都可以訪問這些增強功能。
工作流：提示鏈
提示鏈將單個任務分解為一系列步驟，其中每個 LLM 調用都會處理前一個調用的輸出。你可以在任何中間步驟上添加程序檢查（參見下圖中的「gate」），以確保流程仍在正常進行。
提示鏈工作流何時使用這個工作流：該工作流非常適合可以輕鬆、乾淨地將任務分解為多個固定子任務的情況。這裏的主要目標是讓每個 LLM 調用成為更簡單的任務，從而以犧牲延遲為代價獲得更高的準確性。
適合提示鏈的示例：
- 生成營銷文案，然後將其翻譯成不同的語言。
- 編寫文檔大綱，檢查大綱是否符合某些標準，然後根據大綱編寫文檔。
工作流：路由
路由對輸入進行分類並將其定向到專門的後續任務。這種工作流可以分離關注點並構建更專業的提示。如果沒有這種工作流，針對一種輸入進行優化可能會損害其他輸入的性能。
路由工作流何時使用這種工作流：路由非常適合複雜的任務，這些任務有不同的類別，最好單獨處理，並且可以通過 LLM 或更傳統的分類模型 / 算法準確分類。
適合路由的示例：
將不同類型的客戶服務查詢（一般問題、退款請求、技術支持）引導到不同的下遊流程、提示和工具中。
將簡單 / 常見問題路由到較小的模型（如 Claude 3.5 Haiku），將困難 / 不尋常的問題路由到更強大的模型（如 Claude 3.5 Sonnet），以優化成本和速度。
工作流：並行化
LLM 有時可以同時處理一項任務，並以編程方式聚合其輸出。這種工作流（並行化）有兩個關鍵變體：
分段：將任務分解為多個並行運行的獨立子任務。
投票：多次運行同一任務以獲得不同的輸出。
並行化工作流何時使用這種工作流：當任務可以並行劃分為多個子任務來提高速度，或者任務需要多個視角或嘗試以獲得更高置信度的結果時，並行化是有效的。對於具有多個考慮因素的複雜任務，當每個考慮因素由單獨的 LLM 調用處理時，多個 LLM 通常會表現得更好，這樣每個 LLM 可以集中注意力關注某個特定方面。
適合併行化的示例：
分段：
實施護欄，其中一個模型實例處理用戶查詢，而另一個模型實例則篩選不適當的內容或請求。這往往比讓同一個 LLM 調用同時處理護欄和核心響應效果更好。
自動評估 LLM 性能，其中每個 LLM 調用都會評估給定提示下模型性能的不同方面。
投票：
審查一段代碼是否存在漏洞，其中幾個不同的提示會各自審查代碼並在發現問題時標記代碼。
評估給定內容是否不合適，多個提示分別評估不同方面，或需要不同的投票閾值來平衡誤報和漏報。
工作流：編排器 –
工作者（Orchestrator-workers）
在編排器 – 工作者工作流中，中央 LLM 動態分解任務，將其委託給工作者 LLM，併負責綜合後者的結果。
編排器 – 工作者工作流何時使用這種工作流：這種工作流非常適合那種你無法預測需要哪些子任務的複雜任務（例如在編程中，需要更改的文件數量以及每個文件中更改的參數可能要取決於具體的任務）。雖然它在拓撲上很像並行化，但與後者的主要區別在於其靈活性——子任務不是預定義的，而是由編排器根據特定輸入來確定的。
適合編排器 – 工作者的示例：
每次要對多個文件進行複雜更改的編程產品。
需要從多個來源收集和分析信息以獲取可能的相關信息的搜索任務。
工作流：評估器 – 優化器
在評估器 – 優化器工作流中，一個 LLM 調用生成響應，而另一個調用在一個循環中提供評估和反饋。
評估器 – 優化器工作流何時使用這種工作流：當我們有明確的評估標準，並且迭代的改進提供了可衡量的價值時，這種工作流特別有用。兩個說明它非常合適的標誌是：首先，當人類表達反饋時，LLM 的響應可以明顯改善；其次，LLM 可以提供這樣的反饋。這類似於人類作者在製作精美文檔時可能經歷的迭代寫作過程。
適合評估器 – 優化器的示例：
- 文學翻譯，其中存在 LLM 翻譯器一開始可能無法捕捉到的細微差別，但 LLM 評估器可以提供有用的批評意見。
- 複雜的搜索任務，其需要多輪搜索和分析才能收集全面的信息，評估者決定是否有必要進行進一步搜索。
Agent
隨著 LLM 在關鍵能力方面的成熟——這些能力包括了理解複雜輸入、參與推理和規劃、可靠地使用工具以及從錯誤中恢復——Agent 正在投入生產環境。Agent 以人類用戶的命令或與人類用戶的互動討論為起點開始工作。一旦任務得到明確，Agent 就會獨立計劃和運作，並可能回來找人類獲取更多信息或判斷。在執行過程中，Agent 必須從每個步驟（例如工具調用結果或代碼執行）的所處環境中獲得「基本事實」以評估其進度。然後，Agent 可以在檢查點或遇到阻礙時暫停以獲得人工反饋。任務通常在完成後終止，但通常也會包含停止條件（例如最大迭代次數）以保持控制。
Agent 可以處理複雜的任務，但它們的實現通常很簡單。它們通常只是一些使用了基於環境反饋的工具的 LLM。因此，清晰而周到地設計工具集及其文檔是非常重要的。我們在附錄 2（「對你的工具做提示工程」）中擴展了工具開發的最佳實踐。
自主 Agent何時使用 Agent：Agent 可用於開放式問題，在這些問題中，人們很難或不可能預測所需的步驟數，並且你無法對固定路徑進行硬編碼。LLM 可能會運行很多輪，你必須對其決策有一定程度的信任。Agent 的自主性使其成為在受信任環境中擴展任務的理想選擇。
Agent 的自主性意味著更高的成本，還可能產生復合錯誤。我們建議在沙盒環境中進行廣泛的測試，並採用適當的防護措施。
適合 Agent 的示例：
以下示例來自我們自己的實現：
- 一個用於解決 SWE-bench 任務的編程 Agent，它需要根據任務描述來編輯許多文件；
- 我們的「計算機使用」參考實現，其中 Claude 使用一台計算機來完成任務。
一個編程 Agent 的高級流程組合和自定義這些模式
這些構建塊不是死板的。它們是開發人員可以用來塑造和組合，以適應不同用例的一些常見模式。與任何 LLM 功能一樣，成功的關鍵在於衡量性能並迭代實現。重覆一遍：只有當更多複雜性可以明顯改善結果時，才應考慮增加複雜性。
總 結
在 LLM 領域，取得成功不在於構建最複雜的系統，而在於構建適合你需求的系統。應該從簡單的提示開始，通過全面評估來優化它，並且只在更簡單的解決方案無法滿足要求時才添加多步驟 Agent 系統。
在實現 Agent 時，我們嘗試遵循三個核心原則：
框架可以幫助你快速入門，但在進入生產階段時，請果斷地減少抽像層並使用基本組件來構建。只要遵循這些原則，你就能創建功能強大且可靠、可維護並受到用戶信任的 Agent。
附錄 1：實踐中的 Agent
我們與客戶的合作揭示了兩種特別有前景的 AI Agent 應用，它們展示了上述模式的實際價值。這兩種應用都說明了 Agent 如何為那些需要對話和行動、具有明確的成功標準、啟用反饋循環並集成良好的人工監督的任務儘可能增加價值。
A. 客戶支持
客戶支持通過集成的工具結合了熟悉的聊天機器人界面與一系列增強功能。這自然適合更開放的 Agent，因為：
客戶支持交互過程天然地遵循對話流程，同時需要訪問外部信息和操作；
可以集成工具來提取客戶數據、訂單歷史記錄和知識庫文章；
可以通過編程方式處理諸如發放退款或更新票證之類的操作；
可以通過用戶定義的解決方案明確衡量成功指標。
幾家公司已經通過基於使用率的定價模型證明了這種方法的可行性，這些模型僅對成功的解決方案收費，顯示出對其 Agent 效率的信心。
B. 編程 Agent
軟件開發領域已經顯示出 LLM 的巨大潛力，其能力已從簡單的代碼自動完成發展到了自主解決問題。Agent 之所以特別有效，是因為：
- 代碼解決方案可通過自動化測試進行驗證；
- Agent 可以使用測試結果作為反饋來迭代解決方案；
- 問題空間定義明確且結構合理；
- 輸出質量可以客觀衡量。
在我們自己的實現中，Agent 現在可以僅根據拉取請求描述來解決 SWE-bench Verified 基準測試中的真實 GitHub 問題。然而，雖然自動化測試有助於驗證功能，但要確保解決方案符合更廣泛的系統要求，人工審核依舊是至關重要的。
附錄 2：對你的工具做提示工程
無論你構建的是哪種 Agent 系統，工具都可能是 Agent 的重要組成部分。工具能在我們的 API 中指定外部服務和 API 的確切結構和定義，從而讓 Claude 能夠與外部服務和 API 進行交互。當 Claude 響應時，如果它計劃調用工具，它將在 API 響應中包含一個工具使用塊。工具定義和規範應該像你的整體提示一樣受到提示工程的關注。在這個簡短的附錄中，我們描述了如何對你的工具做提示工程。
同一種操作通常可以有幾種方法來指定。例如，你可以通過編寫 diff 或重寫整個文件來指定一個文件編輯操作。對於結構化輸出，你可以在 markdown 或 JSON 中返回代碼。在軟件工程中，這些差異是表面的，可以無損地從一種轉換為另一種。然而，對於 LLM 來說，有些格式比其他格式更難編寫。編寫 diff 需要知道在編寫新代碼之前塊頭中有多少行發生了變化。在 JSON 中編寫代碼（與 markdown 相比）需要額外的轉義換行符和引號。
我們對選擇工具格式的建議如下：
- 在模型陷入困境之前，給它足夠的 token 來「思考」。
- 讓格式與模型在互聯網上看到的那些自然出現的內容儘量接近。
- 確保沒有格式化「開銷」，例如必須準確計算數千行代碼，或對編寫的任何代碼進行字符串轉義。
一個經驗法則是考慮人機界面（HCI）需要付出多少努力，並計劃投入同樣多的精力來創建良好的 Agent- 計算機界面（ACI）。以下是一些關於如何做到這一點的建議：
- 把自己放在模型的角度。根據描述和參數，這個工具的用法是顯而易見，還是需要仔細考慮？如果是後者，那麼對於模型來說可能也是如此。一個好的工具定義通常包括示例用法、邊緣情況、輸入格式要求以及與其他工具的明確界限。
- 如何更改參數名稱或描述來讓各種事情更明顯？可以把這一步看作是為你團隊中的初級開發人員編寫出色的文檔。在使用許多類似的工具時，這一點尤為重要。
- 測試模型如何使用你的工具：在我們的工作台中運行許多示例輸入，以查看模型犯了哪些錯誤，然後進行迭代。
- 讓你的工具減少錯誤。更改參數，使其更難出錯。
在為 SWE-bench 構建 Agent 時，我們實際上花費了比整體提示更多的時間來優化我們的工具。例如，我們發現 Agent 移出根目錄後，使用相對文件路徑的工具會讓模型出錯。為瞭解決這個問題，我們將工具更改為始終需要絕對文件路徑——我們發現模型完美地使用了這種方法。
原文鏈接：
https://www.anthropic.com/research/building-effective-agents
本文來自微信公眾號 「InfoQ」（ID：infoqchina），作者：Anthropic，36氪經授權發佈。
