Anthropic總結智慧體年度經驗：最成功的≠最複雜的 机器之心 發表於2024-12-31
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 智慧體的框架，包括： 亞馬遜 Bedrock 的 AI Agent 框架 用於構建和測試複雜工作流的 GUI 工具 Vellum 這些框架確實簡化了 AI 開發流程。但要注意的是，它們會在程式碼中增加額外的抽象層，這不僅讓底層的執行邏輯變得不夠透明，也增加了除錯的難度。而且，開發者可能會在一些簡單的場景中，不自覺地引入過度複雜的解決方案。 Anthropic 建議開發者從直接使用大模型的 API 開始：許多模式只需幾行程式碼就能實現。如果選擇使用框架，一定要理解其底層原理。經驗表明，對框架底層機制的理解不足，往往是導致開發問題的主要原因。 具體示例請參考 Anthropic 的 cookbook。 手冊連結：https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agents 智慧系統的基本構建模組是加持檢索、記憶等功能，增強過的 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）。