本篇文章來自Anthropic，我用大模型給翻譯了一下，以下是全文。

過去一年里，我們與數十個團隊合作，跨行業構建大型語言模型（LLM）智能體。通常，最成功的實施案例并不是使用復雜的框架或專門的庫。相反，它們是用簡單、可組合的模式來構建的。

在這篇文章中，我們分享了從與客戶合作及自行構建智能體中學到的經驗，并為開發者提供了構建高效智能體的實用建議。

什么是智能體？

“Agent”可以通過多種方式定義。一些客戶將智能體定義為完全自主的系統，這些系統在較長時間內獨立運行，使用各種工具完成復雜任務。另一些客戶則用這個詞來描述更規范的實現，這些實現遵循預定義的工作流程。在 Anthropic，我們將所有這些變體歸類為智能體系統，但在工作流程和智能體之間劃定了重要的架構區別：

• 工作流程是通過預定義的代碼路徑來編排LLMs和工具的系統。
• 另一方面，智能體（Agents）是這樣的系統：大型語言模型（LLMs）在其中動態地指導自己的流程和工具使用，保持對如何完成任務的控制。

下面，我們將詳細探討這兩種類型的智能體系統。在附錄 1（“實踐中的智能體”）中，我們描述了客戶在使用這類系統時發現特別有價值的兩個領域。

智能體可分成兩種：一種是工作流智能體，一種是自主智能體

何時（以及何時不）使用智能體

使用LLMs構建應用程序時，我們建議盡可能尋找最簡單的解決方案，僅在需要時增加復雜性。這可能意味著根本不需要構建智能體系統。代理系統通常會以更高的延遲和成本來換取更好的任務性能，你應該考慮何時這種權衡是合理的。

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

何時以及如何使用框架

有許多框架使得智能體系統更易于實現，包括：

LangChain的LangGraph ;  

Amazon Bedrock 的 AI 智能體框架

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

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

這些框架通過簡化標準的低級任務（如調用大型語言模型（LLM）、定義和解析工具以及將調用串聯在一起）來使入門變得容易。然而，它們通常會創建額外的抽象層，這可能會使底層提示和響應變得難以調試。它們還可能讓人產生增加復雜性的誘惑，而實際上一個更簡單的設置就足夠了。

我們建議開發者首先直接使用大型語言模型（LLM）API：許多模式可以用幾行代碼實現。如果你確實使用了框架，請確保你理解底層代碼。對底層機制的錯誤假設是客戶錯誤的常見來源。

查看我們的實用指南以獲取一些示例實現。（https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents）

構建模塊、工作流程和智能體

在本節中，我們將探討在生產環境中常見的智能體系統模式。我們將從基礎構建塊——增強型大型語言模型（LLM）開始，逐步增加復雜性，從簡單的組合工作流到自主代理。

構建模塊：增強的LLM

智能體系統的基本構建模塊是一個LLM，通過檢索、工具和記憶等增強功能進行擴展。我們當前的模型（Claude）能夠主動利用這些能力——生成自己的搜索查詢、選擇合適的工具，并決定保留哪些信息。

                                                   增強的LLM

我們建議重點關注實施的兩個關鍵方面：根據您的具體用例定制這些功能，并確保它們為您的LLM提供一個簡單、文檔齊全的接口。雖然實現這些增強功能的方法有很多，但一種方法是通過我們最近發布的模型上下文協議，該協議允許開發者通過簡單的客戶端實現與不斷增長的第三方工具生態系統集成。

在本文的剩余部分，我們將假設每個LLM調用都能訪問這些增強功能。

工作流程：提示鏈

提示鏈將任務分解為一系列步驟，其中每個LLM調用處理前一個調用的輸出。您可以在任何中間步驟添加程序化檢查（見下圖中的“gate”），以確保過程仍在正軌上。

                                                    提示鏈工作流程

何時使用此工作流：何時使用此工作流：當任務可以輕松且清晰地分解為固定的子任務時，這種工作流最為理想。主要目標是通過使每個LLM調用成為一個更簡單的任務，以犧牲延遲為代價來換取更高的準確性。

提示鏈有用的示例：生成營銷文案，然后將其翻譯成另一種語言。撰寫文檔大綱，檢查大綱是否符合特定標準，然后根據大綱編寫文檔。

代碼示例：

工作流程：路由

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

何時使用此工作流程：路由適用于復雜任務，這些任務具有明顯不同的類別，更適合分開處理，并且分類可以通過LLM或更傳統的分類模型/算法準確處理。

路由有用的示例：

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

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

工作流程：并行化

LLMs 有時可以同時處理一個任務，并通過編程方式聚合它們的輸出。這種工作流程，即并行化，表現為兩種關鍵變體：

分段：將任務分解為并行運行的獨立子任務。

投票：多次運行同一任務以獲得多樣化的輸出。

何時使用此工作流程：當劃分的子任務可以并行化以加快速度，或需要多個視角或嘗試以獲得更高置信度的結果時，并行化是有效的。對于具有多重考慮的復雜任務，LLMs通常在每個考慮由單獨的LLM調用處理時表現更好，這樣可以對每個特定方面進行集中關注。

并行化有用的示例：

分段：

• 實施防護措施，其中一個模型實例處理用戶查詢，而另一個模型則篩選其中的不當內容或請求。這種方法通常比讓同一個LLM調用同時處理防護措施和核心響應表現更好。
• 自動化評估以評估LLM性能，其中每個LLM調用評估模型在給定提示下性能的不同方面。

投票：

• 審查一段代碼以查找漏洞，其中多個不同的提示會審查并在發現問題時標記代碼。
• 評估給定內容是否不當，通過多個提示評估不同方面或要求不同的投票閾值以平衡誤報和漏報。

工作流程：協調器-工作者

在協調者-工作者工作流中，一個中央LLM動態地分解任務，將它們分配給工作者LLMs，并綜合它們的結果。

何時使用此工作流：此工作流非常適合那些無法預測所需子任務的復雜任務（例如，在編碼中，需要更改的文件數量以及每個文件中更改的性質可能取決于任務）。盡管它在拓撲結構上相似，但與并行化的關鍵區別在于其靈活性——子任務并非預先定義，而是由協調器根據具體輸入確定。

編排器-工作者模式有用的示例：

• 每次對多個文件進行復雜更改的編碼產品。
• 搜索涉及從多個來源收集和分析信息以尋找可能相關信息的任務。

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

在評估器-優化器工作流程中，一個LLM調用生成響應，而另一個在循環中提供評估和反饋。

何時使用此工作流程：當我們有明確的評估標準，并且迭代改進能帶來可衡量的價值時，此工作流程尤為有效。適合的兩個標志是，首先，當人類明確表達其反饋時，LLM 的響應可以得到明顯改善；其次，LLM 能夠提供此類反饋。這類似于人類作家在創作一份精煉文檔時可能經歷的迭代寫作過程。

評估優化器有用的示例：

• 文學翻譯中存在一些細微差別，譯者LLM可能最初未能捕捉到，但評估者LLM可以提供有益的批評。
• 需要多輪搜索和分析以收集全面信息的復雜搜索任務，評估者決定是否需要進行進一步搜索。

Agents  智能體

智能體在生產中逐漸嶄露頭角，隨著關鍵能力的成熟——理解復雜輸入、參與推理和規劃、可靠地使用工具以及從錯誤中恢復。智能體的工作始于人類用戶的命令或互動討論。一旦任務明確，智能體便獨立規劃和操作，可能會返回給人類以獲取更多信息或判斷。在執行過程中，智能體在每一步從環境中獲取“真實情況”（如工具調用結果或代碼執行）以評估其進展至關重要。智能體隨后可以在檢查點或遇到阻礙時暫停以獲取人類反饋。任務通常在完成時終止，但為了保持控制，也常見包含停止條件（如最大迭代次數）。

智能體可以處理復雜的任務，但它們的實現通常很簡單。它們通常只是LLMs在循環中根據環境反饋使用工具。因此，清晰而周到地設計工具集及其文檔至關重要。我們在附錄 2（“提示工程你的工具”）中擴展了工具開發的最佳實踐。

何時使用智能體：智能體可用于開放式問題，這些問題難以或無法預測所需的步驟數量，且無法硬編碼固定路徑。LLM可能會運行多個回合，你必須對其決策能力有一定程度的信任。智能體的自主性使其成為在可信環境中擴展任務的理想選擇。

智能體的自主性意味著更高的成本和錯誤累積的可能性。我們建議在沙盒環境中進行廣泛測試，并設置適當的防護措施。

智能體有用的示例：

以下示例來自我們自己的實現：

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

參考我們的“computer use”實現，其中 Claude 使用計算機完成任務。

                                             編碼智能體的高級流程

                                              結合并自定義這些模式

這些構建模塊并非一成不變。它們是開發者可以根據不同使用場景塑造和組合的常見模式。與任何LLM功能一樣，成功的關鍵在于衡量性能并迭代實現。重申一遍：只有在明顯改善結果時，才應考慮增加復雜性。

總結

在LLM領域的成功并不在于構建最復雜的系統，而在于構建適合您需求的正確系統。從簡單的提示開始，通過全面評估進行優化，只有在更簡單的解決方案不足時，才添加多步驟的智能體系統。

在實現智能體時，我們嘗試遵循三個核心原則：

1、保持智能體設計的簡潔性。

2、優先考慮透明度，明確展示智能體的規劃步驟。

3、精心設計您的智能體-計算機界面（ACI），通過全面的工具文檔和測試。

框架可以幫助您快速入門，但在進入生產階段時，不要猶豫減少抽象層并使用基本組件進行構建。遵循這些原則，您可以創建不僅功能強大，而且可靠、可維護并贏得用戶信任的智能體。

由 Erik Schluntz 和 Barry Zhang 撰寫。本作品借鑒了我們在 Anthropic 構建智能體的經驗以及客戶分享的寶貴見解，對此我們深表感激。

參考：

??https://www.anthropic.com/research/building-effective-agents?cnotallow=1d9695e219e413270aa88f92565888be??

本文轉載自??AI 思與行??，作者：cc ????