Anthropic總結智能體年度經驗：最成功的≠最複雜的

機器之心編譯

編輯：佳琪、張倩

高端的食材，往往需要最樸素的烹飪方式。

AI 發展到後半場「大霧散去」，如何讓大模型的智力落實成執行力，智能體似乎成了業界的共同答案。

從元寶到混元，各類智能體平台如雨後春筍般湧現。上個月，智譜發佈 AutoGLM 的發佈會上，智能體好像突破了次元壁，一句指令，就拿著手機在現場發了一個總計兩萬塊錢的紅包。

我們正在見證一個重要的轉折點：智能體正在將 AI 的能力從「能說會道」轉變為「能做會幹」。

作為最強大模型廠商的有力競爭者，Anthropic 推出的智能體功能也著實驚豔了我們一把。Computer Use 甚至已經可以做到跟 Claude 說一聲想做一個 90 年代風格的個人網站，剩下的只需要坐在屏幕前看網頁自己做自己就好了。

在過去一年中，Anthropic 與數十個行業團隊合作，對大模型智能體進行了系統研究。但他們發現，那些表現最出色的 AI 智能體，並非建立在龐大複雜的框架或專業庫之上，而是採用了簡單、可組合的模式。

Anthropic 將一年的實踐經驗總結成了這篇博客，機器之心在不改變原意的基礎上進行了編譯。

• 原文鏈接：https://www.anthropic.com/research/building-effective-agents

什麼是智能體？

「智能體」有多種定義。有人眼中的智能體是一個「全能管家」，能夠獨立思考、自主決策，靈活運用各種工具來完成複雜任務；也有人把它理解為一個「規矩員工」，按部就班地執行預設的工作流。

Anthropic 將兩者統稱為智能系統，但對工作流和智能體做出了區分：

• 工作流是通過預定代碼路徑編排 LLM 和工具的系統

• 智能體則是由 LLM 動態指導自身流程和工具使用的系統，能自主控制任務的完成方式

什麼時候該用智能體？

在開發 AI 應用時，Anthropic 的研究團隊給出了一個建議：能簡單就不要複雜。有時候，根本不需要建造一個智能系統 —— 因為智能系統雖然功能強大，但往往會讓響應變慢，成本也會更高。開發者需要權衡這種取捨。

當確實需要更複雜的系統時，工作流適合需要可預測和一致性的明確任務，而智能體則更適合需要靈活性和模型驅動決策的大規模場景。

不過對很多應用來說，配合檢索和上下文示例，拿著一個好的 prompt 去問大模型通常就足夠了。

何時使用框架以及如何使用

目前，有多個可以幫助開發者更容易地搭建 AI 智能體的框架，包括：

• LangChain 的 LangGraph

• 亞馬遜 Bedrock 的 AI Agent 框架

• 拖放式的大模型工作流構建工具 Rivet

• 用於構建和測試複雜工作流的 GUI 工具 Vellum

這些框架確實簡化了 AI 開發流程。但要注意的是，它們會在代碼中增加額外的抽像層，這不僅讓底層的運行邏輯變得不夠透明，也增加了調試的難度。而且，開發者可能會在一些簡單的場景中，不自覺地引入過度複雜的解決方案。

Anthropic 建議開發者從直接使用大模型的 API 開始：許多模式只需幾行代碼就能實現。如果選擇使用框架，一定要理解其底層原理。經驗表明，對框架底層機制的理解不足，往往是導致開發問題的主要原因。

具體示例請參考 Anthropic 的 cookbook。

• 手冊鏈接：https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents

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

基礎構建模塊：增強版 LLM

智能系統的基本構建模塊是加持檢索、記憶等功能，增強過的 LLM。目前，Anthropic 的模型可以主動使用這些能力 —— 生成自己的搜索查詢、選擇合適的工具，並決定保留哪些信息。

增強過的大模型。

Anthropic 建議做這些拓展功能的過程中大家可以重點關注兩點：

• 根據具體的應用場景來定製功能

• 確保為模型提供簡單且文檔完備的接口

除此之外，Anthropic 最近發佈的模型上下文協議提供了一種新的實現方式。這個協議讓開發者可以通過簡潔的客戶端代碼，輕鬆地將 AI 模型與持續擴展的第三方工具生態系統進行集成。

工作流：提示鏈

提示鏈是一種將複雜任務拆解為多個步驟的方法，每個步驟代表調用一次大模型，後一步將基於前一步的結果繼續處理。開發者可以在任意中間環節加入程序化的檢查點（比如圖中的「gate」），以確保流程按預期推進。

什麼時候更適合用提示鏈工作流呢？當一個複雜任務能夠被清晰地拆分成一系列固定的子任務時，提示鏈就是最佳選擇。這種方法讓每個模型只需專注完成一個簡單任務，雖然整體響應時間可能會略長，但準確率會得到顯著提升。

典型應用案例：

• 先生成營銷文案，再將其翻譯成其他語言

• 先寫文檔大綱並進行合規性檢查，再基於大綱撰寫完整文檔

工作流：智能分流

分流技術能夠判斷輸入任務的類型，並將其分配給相應的專門模塊。這種設計讓每個模塊都能針對特定任務進行優化，避免了不同類型任務之間的相互干擾。

如果不採用這種分發機制，僅提升針對某類問題的效果，往往會影響到其他類型問題的處理質量。

智能分流的工作流。

什麼時候適合用這種方法呢？當任務有明顯的分類特徵時，就很比較適合。AI 系統可以通過大語言模型或傳統算法，準確識別任務類型並做出分流。

典型應用案例：

• 在客服系統中，可以將一般諮詢、退款申請、技術支持等不同類型的問題，分別引導到相應的處理流程。

• 將簡單 / 常見問題分配到 Claude 3.5 Haiku 等較小模型，將困難 / 罕見問題分配到 Claude 3.5 Sonnet 等更強大的模型，以優化成本和速度。

工作流：並行

大語言模型可以同時處理任務，並以編程方式聚合輸出。這種並行化的工作流主要有兩個特點：

• 任務分段：將任務拆分為可並行運行的獨立子任務，每個子任務可以同時進行處理，最後再整合結果。

• 投票機制：對同一任務進行多次運行，獲得多個不同版本的輸出，從而選擇最優結果或綜合多個答案。

並行工作流。

當子任務可以並行執行以提高速度，或需要多角度嘗試以獲得更高置信度的結果時，並行化的方法非常有效。對於涉及多個因素的複雜任務，讓每次調用專注處理特定方面，會獲得更好的效果。

典型應用案例：

任務分段：

• 安全防護：一個模型負責處理用戶請求，另一個專門負責內容審核，這比單個模型同時處理兩項任務效果更好。

• 性能評估：讓不同的模型分別評估系統的各個性能指標，實現全面的自動化評估。

投票機制：

• 代碼安全檢查：同時運行多個檢測模型，共同發現和標記潛在的代碼漏洞。

• 內容審核：通過多個模型從不同角度評估內容安全性，通過調整投票閾值來平衡誤判率。

工作流：領導 — 執行者

在這種工作流中，一個中央大語言模型會動態分解任務，分派給執行者模型，並彙總最終結果。

這種工作流最適合那些難以提前確定具體步驟的複雜任務。比如在編程中，一個功能需求可能涉及多個文件的修改，而具體要改哪些文件、如何修改，往往要根據實際情況來決定。

雖然這種方式看起來和並行任務很像，但這種工作流更靈活 —— 任務的拆分不是固定的，而是由 AI 系統根據具體情況動態決定的。

典型應用案例：

• 需要對多個文件進行複雜修改的編程應用。

• 需要從多個來源收集和分析相關信息的搜索任務。

工作流：評估 — 優化

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

何時使用這個工作流：當存在明確的評估標準，並且通過迭代細化可以帶來顯著價值時，這個工作流特別有效。

有兩個顯著特點：首先，當人類明確表達他們的反饋時，LLM 的響應可以明顯改進；其次，LLM 能夠提供這樣的反饋。這類似於人類作家在創作一篇精心打磨的文檔時所經歷的反復修改的寫作過程。

典型應用案例：

• 文學翻譯：翻譯模型可能在第一次翻譯時遺漏一些細微的語言差異，而評估模型能夠發現這些問題並提供有價值的修改建議。

• 複雜搜索：某些信息收集任務需要多輪搜索和分析才能獲得全面的結果，評估模型可以判斷是否需要繼續深入搜索。

智能體

智能體在生產中隨著 LLM 在關鍵能力上的成熟而出現，這些能力包括理解複雜輸入、進行推理和規劃、可靠地使用工具以及從錯誤中恢復。

智能體的工作始於人類用戶的命令，或與人類用戶的互動討論。一旦任務明確，智能體就會獨立規劃和操作，中途可能需要向人類索取更多信息或讓人類做判斷。

在執行過程的每一步，從環境中獲得「真實情況」（例如工具調用結果或代碼執行）以評估其進度至關重要。然後，智能體可以在檢查點或遇到阻塞時暫停以獲取人類反饋。任務通常在完成後終止，但也通常包含停止條件（例如最大迭代次數）以保持控制。

智能體能夠處理複雜的任務，但其實現通常很簡單。它們通常只是循環中根據環境反饋來使用工具的大型語言模型。因此，設計工具集及其文檔清晰、周到至關重要。作者在附錄 2 中擴展了工具開發的最佳實踐。

何時使用智能體：智能體可以用於開放性問題，這種問題往往難以或不可能預測所需的步驟數量，並且你不能硬編碼固定路徑。LLM 可能會操作多個回合，你必須對其決策能力有一定程度的信任。智能體的自主性使它們成為在受信任環境中 scaling 任務的理想選擇。

智能體的自主性意味著成本更高，並且可能存在錯誤累積的風險。作者建議在沙盒環境中進行廣泛的測試，並設置適當的防護措施。

智能體的用途示例：  

• 一個代碼智能體，用於解決涉及根據任務描述編輯多個文件的 SWE-bench 任務

• Anthropic 的「Computer use」功能，其中 Claude 使用計算機完成任務。

組合、定製這些模式

這些構建塊不是規定性的。開發者可以塑造和組合這些構建塊以適應不同用例。成功的關鍵是衡量性能並迭代實現。注意：只有在能夠明顯改善結果的情況下，你才應該考慮增加複雜性。

總結

在 LLM 領域取得成功並不在於構建最複雜的系統，而是在於為你的需求構建正確的系統。從簡單的提示開始，用全面的評估優化它們，同時只有當更簡單的解決方案無法實現時才添加多步驟智能體系統。

在部署智能體時，需要嘗試遵循三個核心原則：

• 在智能體設計中保持簡單；

• 要優先確保智能體的透明度，方法是清楚地展示它計劃中的每一步；

• 通過全面的工具文檔和測試精心打造你的智能體 – 計算機界面（ACI）。

更多詳情，請參考原博客。