本文主要講述Anthropic公司在構建大型語言模型（LLM）和智能體（Agents）方面的年度總結和設計原則。文章由Anthropic公司撰寫，內容包括成功方案的特點、智能體的定義、何時使用智能體、框架的使用、構建模塊與工作流、工作流模式、智能體的應用場景以及實踐案例等板塊。文章強調簡單性、透明度和精心設計的agent-computer interface（ACI）接口的重要性，并提供工具開發的最佳實踐和插件工具的提示詞工程的詳細信息。基于以上內容，Anthropic分享如何構建有價值的智能體，并為開發者提供實用的建議。

Agent構建指南

2024年12?20?

在過去的一年里，Anthropic 與多個行業團隊合作，構建大型語言模型（LLM）代理。最成功的方案并不是使用復雜的框架或專門的軟件包。相反，他們使用的是簡單、可組合的模塊來構建的。 在這篇文章中，Anthropic 分享了從與客戶合作和自身構建代理中學到的經驗，并為開發者提供如何構建有效代理的相關建議。

什么是Agent？

什么是Agent？ “Agent”能有多種定義。一些客戶將Agent定義為完全自主的系統，它們能長期獨立運行，使用各種工具完成復雜任務。其他人把Agent描述為遵循預定義工作流程且更符合規范性。在Anthropic，將所有這些變體歸類為代理系統，但在工作流和代理之間畫了一個重要的架構區別：

• 工作流是LLM和工具基于預定義的代碼路徑進行編排的系統。

• 代理是LLM動態規劃自己流程和工具使用的系統，并能控制如何完成任務的系統。

下面，我們將詳細探討這兩種類型的代理系統。在附錄1（“實踐中的Agent”）中，介紹了客戶發現使用這些系統特別有價值的兩個領域。

何時（以及何時不）使用Agent？

在構建LLM應用程序時，建議尋找盡可能簡單的解決方案，并只在需要時增加復雜性。這可能意味著根本不構建代理系統。代理系統通常為了更好的任務性能而延遲和消耗成本，需要考慮權衡這是否有意義。

當需要更多的復雜性時，工作流為定義明確的任務提供了可預測性和一致性，而當需要大規模的靈活性和模型驅動的決策制定時，Agent是更好的選擇。然而，對于許多應用程序來說，優化單個LLM調用，配合檢索和上下文示例通常就足夠了。

何時以及如何使用框架？

有許多框架可以使代理系統更容易實現，包括：

• LangChain的LangGraph；

• 亞馬遜Bedrock的AI代理框架；

• Rivet，一個拖拽式GUI LLM工作流構建器；

• Vellum，一個用于構建和測試復雜工作流的GUI工具。

這些框架通過簡化調用LLM、快速編寫和解析相關工具插件、鏈式調用等標準化的底層任務，簡化操作流程。然而，它們會創建額外的抽象層，這可能會遮蓋底層的提示和響應內容，使得調試變得更加困難。它們可能讓開發者在簡單的設置就能完成的操作中，增加工作的復雜程度。

我們建議開發者首先直接使用LLM API：許多常用的模式只需幾行代碼就能實現。如果確實想要使用框架，需確保理解底層代碼。對底層內容的錯誤假設是客戶出錯的常見來源。

查看我們的官方手冊以獲取一些示例實現。

構建模塊、工作流和代理

在本節中將探討在生產中遇到的代理系統的常見模式。我們將從基礎構建模塊——增強型LLM開始，逐漸增加復雜性，從簡單的組合工作流到自主代理。

構建模塊：增強型LLM

代理系統的基本構建模塊是通過檢索、工具和記憶等增強功能提升的LLM。如今的模型能自動地使用這些能力——自主生成搜索查詢、選擇合適的工具，并決定保留哪些信息。

我們建議重點關注實施的兩個關鍵方面：根據使用場景定制特定用例，并確保為LLM提供簡單且文檔齊全的接口。雖然實現這些增強功能有很多方法，但其中一種方法是使用Anthropic最近發布的模型上下文協議（Model Context Protocol），它支持開發者通過簡單的客戶端實現與借助該協議的各種第三方工具生態進行集成。

在本文的剩余部分，將假設每次LLM調用都可以訪問這些增強能力。

工作流：提示鏈工作流

提示鏈將一個任務分解成一系列步驟，其中每個LLM調用處理前一個調用的輸出。您可以在任何中間步驟添加程序化的檢查（見下圖中的“gate”），確保流程按預期進行。

• 適用場景：此工作流非常適合任務可以輕松且清晰地分解為固定子任務的場景。主要目的是通過使每個LLM調用變得更容易，在回復速度和更高的準確性之間進行取舍。

• 提示鏈適用示例：

• 生成營銷文案，然后將其翻譯成不同的語言。

• 編寫文檔的大綱，檢查大綱是否符合某些標準，然后根據大綱編寫文檔。

工作流：路由工作流

路由對輸入進行分類，并將輸入引導至后續的專門任務。工作流允許分離關注點，并構建更專業的提示。如果沒有這種工作流，針對一種輸入的優化可能會損害其他輸入的性能。

• 適用場景：路由適用于復雜任務，這些任務具有明確的類別，適合分別處理，并且分類可以由LLM或更傳統的分類模型/算法準確處理。

• 適用示例：

• 將不同類型的客戶服務查詢（一般問題、退款請求、技術支持）引導到不同的下游流程、提示和工具中。

• 將簡單/常見問題路由到較小的模型，如claude 3.5 Haiku，將困難/不尋常的問題路由到更強大的模型，如Claude 3.5 Sonnet，以優化成本和速度。

工作流：并行化工作流

LLM有時可以同時完成一項任務，并將它們的輸出以編程方式匯總輸出。這種工作流體現在兩個關鍵變體中：

• Sectioning（任務拆解）：將任務分解為獨立子任務并行運行。

• Voting（投票）：多次運行相同的任務以獲得不同的輸出。

• 適用場景：當分割的子任務可以并行化以提高速度，或者當需要多個視角進行嘗試來獲得更可靠的結果時，并行化是有效的。對于具有多重考慮因素的復雜任務，把每個考慮因素都用單獨的LLM調用處理時，LLM表現更好。

• 適用示例：

• 審查代碼中的漏洞，如果發現他們有問題，多個不同的提示審查并標記代碼。

• 評估給定內容是否不當，使用多個提示評估不同方面或設置不同的投票閾值來平衡測試的準確性。

• 安全防護，其中一個模型處理用戶查詢，而另一個篩選查找不適當的內容或請求。這通常比讓同一個LLM調用同時安全防護和核心響應表現得更好。

• 自動化評估用來評估LLM在給定提示下的表現，每個LLM用在評估模型表現的不同方面。

• Sectioning（任務拆解）：

• Voting（投票）：

工作流：協調者-執行者工作流

在協調者-執行者工作流中，一個中心LLM動態地分解任務，將它們委托給worker LLMs（工人LLM），并綜合考慮他們的結果。

• 適用場景：適合無法預測所需子任務的復雜任務（例如，在編碼中，需要更改的文件數量以及每個文件中內部的更改，可能取決于任務本身）。雖然它的流程圖跟 Parallelization 很像，但關鍵區別在于其更靈活——子任務不是預定義的，而是由Orchestrator指揮家根據特定輸入確定。

• 適用示例：

• 每次對多個文件進行復雜更改的編碼產品。

• 涉及從多個來源收集和分析信息以尋找可能相關信息的搜索任務。

工作流：評估器-優化器工作流

在這個工作流中，一個LLM調用負責生成響應，而另一個在循環中提供評估和反饋。

• 適用場景：當有明確的評估標準，并且迭代細化的價值能被衡量時，這種工作流特別有效。良好的適應性有兩個標志，第一，當人類表達反饋時，LLM的響應可以明顯改善；第二，LLM能夠提供這樣的反饋。這類似于人類作家在撰寫精煉的文檔時，可能經歷的迭代寫作過程。

• 適用示例：

• 文學翻譯，其中有一些細微之處翻譯LLM最初可能無法捕捉到，但評估LLM可以提供有用的改善建議。

• 復雜的搜索任務，需要多輪搜索和分析來收集全面的信息，負責評估的 LLM 決定是否需要進一步搜索。

代理

隨著LLM在理解復雜輸入、進行推理和規劃、使用工具及從錯誤中糾錯等關鍵能力的成熟，代理開始在生產中興起。

代理工作的開始，來自人類用戶的命令，或與人類用戶進行互動討論。一旦任務明確，代理就會獨立規劃和行動，可能需要反問人類，來獲取更多信息或判斷。在執行過程中，對于代理來說，每一步從環境中獲得“真實情況”（例如工具調用結果或代碼執行）以評估其進度至關重要。然后，代理可以在遇到阻礙時暫停以獲取人類反饋。任務通常在完成時終止，但也常常包括終止條件（例如最大迭代次數）以保持控制。

代理可以處理復雜的任務，但它們的實現通常很簡單。它們通常只是根據環境反饋在循環中使用工具的LLM。因此，設計周全且清晰的工具集和文檔至關重要。附錄2（”Prompt Engineering your Tools”（提示工程你的工具）中詳細介紹了工具開發的最佳實踐。

（自主代理）

• 適用場景：代理可用于難以或無法預測所需的步驟數量，并且無法規定好固定路徑的開放式問題。LLM可能會運行多個循環，你必須對其決策能力有一定程度的信任感。代理的自主性使其成為在受信任環境中執行任務時特別理想。代理的自主性質意味著成本更高，并且有可能出現不斷積累的錯誤。建議在沙盒環境中進行廣泛的測試，并設置適當的安全防護。

• 適用示例：以下是我們自己的實現中的一些示例：

• 一個編碼代理，用于解決SWE-bench任務，這些任務涉及根據任務描述對多個文件進行編輯；

• “計算機使用”參考手冊，其中Claude使用一個計算機來完成任務。

(編碼代理的高級流程)

組合和定制

這些范式不是嚴格規定好的。它們是開發者可以搭建和組合以適應不同用例的常見模式。和任何LLM功能一樣，成功的關鍵，是衡量性能并迭代落地。重復一遍：只有能明顯改善結果時，才應該考慮增加復雜性。

總結

在LLM領域取得成功并不是關于構建最復雜的系統。而在于為需求構建合適的系統。從簡單的提示開始，用全面的評估進行優化，只有當更簡單的解決方案不足以應對時，才添加多步驟的代理系統。

在實現代理時，我們嘗試遵循三個核心原則：

• 確保代理設計簡單。

• 通過明確顯示代理的規劃步驟來優先考慮透明度。

• 通過全面的工具文檔和測試，精心打造你的代理-計算機界面（ACI）接口。

框架可以幫助你快速入手，但在進入生產環境時，不要猶豫減少抽象層，并盡量使用基本組件構建。遵循這些原則，你可以創建不僅強大而且可靠、可維護并被用戶信任的代理。

致謝

由Erik Schluntz和Barry Zhang撰寫。這項工作借鑒了我們在Anthropic構建代理的經驗以及我們的客戶分享的寶貴見解，我們對此深表感激。

附錄1：實踐中的代理

我們與客戶的合作揭示了AI代理特別有前景的兩個應用，展示了上述模式的實際價值。這兩個應用都說明了代理對于需要對話和行動、有明確成功標準、能夠反饋循環并整合有價值的人類監督的任務中最有價值。

A. 客戶支持

客戶支持結合了熟悉的聊天機器人界面，并通過工具集成增強了能力。這對于更開放式的代理來說是自然的場景，因為：

• 遵循對話流程，互動自然，同時需要訪問外部信息和操作；

• 可以集成工具來提取客戶數據、訂單歷史和知識庫文章；

• 可以以程序化的方式處理如發放退款或更新工單等操作；

• 通過用戶定義的解決方案，明確的地衡量agents 是否解決了該問題。

一些公司通過基于使用量的定價模型證明了這種方法的可行性，這些模型僅對成功的解決方案收費，展示了對他們代理有效性的信心。

B. 編碼代理

軟件開發領域顯示出LLM功能的顯著潛力，功能從代碼補全演變到自主問題解決。代理特別有效，因為：

• 代碼問題的解決可以通過自動化測試來驗證；

• 代理可以使用測試結果作為反饋迭代解決方案；

• 問題定義明確且結構化；

• 輸出質量可以客觀衡量。

在我們自己的實現中，代理基于SWE-bench驗證基準，能單獨解決真實的GitHub問，。然而，盡管自動化測試有助于驗證功能，但人類審查仍然至關重要，以確保解決方案符合更廣泛的系統要求。

附錄2：提示工程你的工具

無論您正在構建哪種代理系統，工具插件都可能是您代理的重要組成部分。工具使Claude能夠通過在我們的API中指定它們的確切結構和定義來與外部服務和API交互。當Claude響應時，如果它計劃調用工具，它將在API響應中包含一個工具使用塊。工具定義和規范應該和整體提示一樣，獲得同樣的提示工程關注。在這個簡短的附錄中，描述了如何對工具進行提示工程。

通常有幾種方式可以指定相同的操作。例如，可以通過編寫差異(diff)或重寫整個文件來指定文件編輯。對于結構化輸出，可以在Markdown或JSON中返回代碼。在軟件工程中，這些差異是表面的，并且可以無損地從一種格式轉換為另一種格式。

然而，有些格式對于LLM來說比其他格式更難編寫。編寫差異(diff)需要在新代碼編寫之前就知道塊頭部有多少行在更改。在JSON中編寫代碼（與Markdown相比）需要對換行符和引號進行轉義額外的轉義。

我們對決定工具格式的建議如下：

• 給模型足夠的令牌，在它進入死胡同之前“思考”。

• 保持格式接近在互聯網上自然出現的文本。

• 確保沒有格式化“開銷”，例如必須準確計算數千行代碼，或對它編寫的任何代碼進行字符串轉義。

一個經驗是在人機界面（HCI）上投入了多少精力，就要投入同樣的精力來創建良好的代理-計算機界面（ACI）。以下是如何做到這一點的一些想法：

• 設身處地為模型著想。根據描述和參數，使用這個工具是否明顯，還是需要仔細思考？一個好的工具定義通常包括示例用法、邊界情況、輸入格式要求以及與其他工具的明確界限。

• 如何更改參數名稱或描述以使任務更明顯？將此視為為您團隊的初級開發人員編寫易讀的說明文檔那樣。當使用許多類似的工具時，這一點尤其重要。

• 測試模型如何使用您的工具：在我們的工作臺上運行多個示例輸入，來查模型犯了哪些錯誤，并進行迭代。

• 為您的工具實施防錯措施。更改參數，使其更難犯錯誤。

在構建SWE-bench代理時，Anthropic 實際上花在優化工具上的時間比優化整體提示還要多。例如，Anthropic 發現模型在使用相對文件路徑的工具時會出錯，尤其是在代理移出根目錄之后。為了解決這個問題，將工具更改為始終要求使用絕對文件路徑，我們發現模型完美地使用了這種方法。