模型到應用之間的距離，就是燒錢與搞錢之間的距離。

這條路上，Agent已經身經百戰，萬事俱備。

在這個2024的結尾，Anthropic開發者關系主管Alex Albert表示：2025年將是智能體系統之年！

「各個部分正在就位，是時候開始考慮構建這些系統了。」

過去的一年里，Anthropic與數十個團隊合作，構建了跨行業的大語言模型智能體系統。

實戰表明，最成功的實現方式并不是使用復雜的框架或專用庫，而是應用簡單的可組合模式。

根據與客戶合作的經驗，Anthropic在年末總結的博文中分享了構建有效智能體系統的實用建議。

Agent系統最佳實踐

智能體（Agent）可以有多種定義方式，比如將其視為完全自主的系統，可以在較長時間內獨立運行，并使用各種工具完成復雜的任務。

這聽起來很像另一個名詞：工作流，但兩者之間有著重要的架構區別：

工作流是通過預定義的代碼路徑來調用LLM和工具的系統；

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

那么，什么時候使用智能體？什么時候使用工作流？

一個原則是：找到盡可能簡單的解決方案，并且僅在需要時增加復雜性。

智能體系統通常會以延遲和成本為代價來獲得更好的任務性能，開發者應當根據實際情況權衡，是否真的需要構建智能體系統。

當需要更高的復雜性時，工作流為定義明確的任務提供可預測性和一致性；當需要大規模的靈活性和模型驅動的決策時，智能體是更好的選擇。

對于許多應用程序來說，使用檢索和上下文來優化單個LLM調用通常就足夠了。

何時使用框架

有許多現成的框架可以幫助構建智能體系統，比如：

LangChain的LangGraph；

Amazon Bedrock的AI Agent框架

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

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

框架簡化了標準的低級任務（如調用LLM、定義和解析工具、將調用整合在一起），但通常會創建額外的抽象層。

這可能會掩蓋底層提示和響應，使系統更難調試。但開發者有時會禁不住框架的誘惑而選擇增加系統的復雜性。

Anthropic建議開發人員盡量直接使用LLM（許多功能只需幾行代碼就能搞定），如果確實需要使用框架，請確保先了解底層代碼，——對框架實現原理的錯誤假設是錯誤的常見來源。

從0開始構建系統

生產中的常見模式，是從基礎模塊開始，逐步增加復雜性，從簡單的組合工作流到自主智能體系統。

基礎模塊：增強型LLM

智能體系統的基本構建塊是LLM，并通過檢索、使用工具和記憶等功能進行了增強。

增強型LLM可以主動使用這些功能，生成自己的搜索查詢、選擇適當的工具并確定要保留的信息。

Anthropic建議在實施中關注兩個關鍵方面：根據特定應用定制這些功能，以及確保為LLM提供簡單且文檔健全的接口。

比如Anthropic最近發布的Model Context Protocol，允許開發人員通過簡單的客戶端實現與各種第三方工具進行集成。

提示鏈（Prompt chaining）

提示鏈將任務分解為一系列步驟，每個LLM調用都會處理前一個調用的輸出。可以在任何中間步驟中添加編程檢查，以確保流程處于正軌。

這種工作流非常適合可以輕松將任務分解為固定子任務的情況（每個LLM負責一個簡單的子任務）。

提示鏈應用場景：

生成市場營銷策略，然后將其翻譯成不同的語言。

編寫文檔的大綱，檢查大綱是否滿足特定條件，然后根據大綱編寫文檔。

路由（Routing）

路由對輸入進行分類并將其定向到專門的后續任務，這個過程可以分離關注點，并構建更專業的提示。否則，針對一種輸入進行優化可能會損害其他輸入的性能。

路由適用于復雜任務，通過LLM或更傳統的分類算法準確處理分類，對于不同類別的子任務，可以更好地單獨處理。

路由應用場景：

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

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

并行化（Parallelization）

LLM有時并行處理一項任務，并以編程方式聚合其輸出。并行化工作流有兩種形式：

分段（Sectioning）：將任務分解可以為并行運行的獨立子任務。

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

當已劃分的子任務可以并行執行，或者需要多次推理以獲得更高置信度的結果時，并行化非常有效。

對于需要考慮多個因素的復雜任務，讓單獨的LLM負責一個特定的方面，通常會提高系統的表現力。

并行化的應用場景：

一個模型實例處理用戶查詢，另一個模型實例篩選用戶查詢是否存在不適當的內容。這往往比使用相同的LLM同時處理安全校驗和核心響應的性能要好。

自動評估LLM的性能：每個LLM調用都會評估模型在給定提示符下性能的不同方面。

檢查一段代碼是否存在漏洞，如果發現問題，則觸發不同的提示來檢查并標記代碼。

評估給定的內容是否合適：多個提示用來評估不同的方面或使用不同的投票閾值來平衡誤報和漏報。

Orchestrator-workers

在orchestrator-workers工作流中，中央LLM動態分解任務，將它們委托給worker LLM，并綜合其結果。

這種工作流非常適合于無法預測所需子任務的復雜任務（比如編碼中，需要更改的文件數以及每個文件中更改的內容取決于實際情況）。

orchestrator-workers與并行化在拓撲上相似，主要區別在于子任務不是預定義的，而是由orchestrator根據特定輸入確定的。

應用場景：

每次對多個文件進行復雜更改的編碼任務。

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

Evaluator-optimizer

在evaluator-optimizer工作流中，一個LLM調用生成響應，另一個LLM在循環中提供評估和反饋。

當開發者有明確的評估標準，且迭代過程能提供用于比較的值時，evaluator-optimizer工作流特別有效。

evaluator-optimizer應用場景：

文學翻譯中，譯者LLM最初可能無法捕捉到一些細節，但評估者LLM可以提供有用的批評反饋。

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

總結

智能體在生產中幫助理解復雜的輸入、參與推理和規劃、可靠地使用工具以及從錯誤中恢復。

執行過程中，智能體在每個步驟從環境中獲取「基本事實」以評估其進度，也可以在檢查點或遇到障礙時暫停以獲得人工反饋。

智能體用于難以預測所需步驟數，以及無法對固定路徑進行硬編碼的開放式問題。LLM可能會運行多個回合，需要用戶對其決策有一定程度的信任。

智能體的自主性意味著更高的成本，并且可能會使錯誤復雜化。作者建議在沙盒環境中進行廣泛測試，并使用適當的防護機制。

LLM的成功應用并不是構建最復雜的系統，而是根據需求構建正確的系統。在應用智能體時，盡量遵循三個核心原則：

保持智能體設計的簡單性；

明確顯示智能體的規劃步驟；

提供全面的工具文檔和測試，作為智能體和計算機之間的接口

框架可以幫助快速入門，但面對生產環境時，不要猶豫，減少抽象層并使用基本組件進行構建。