Anthropic 打造高效 AI Agent – 實用模式與指南

TL;DR

Anthropic 發布了一份指南，總結了建立 LLM‑based agent 一年的經驗，指出簡單且可組合的模式——增強型 LLM (augmented LLMs)、提示詞鏈結 (prompt chaining)、路由 (routing)、並行化 (parallelization)、編排者‑工作者 (orchestrator‑workers)、評估者‑優化者 (evaluator‑optimizer) 以及自主 Agent (autonomous agents)——其表現優於笨重的框架，並針對何時使用各個模式以及如何設計工具提供了具體的建議。

什麼才算「Agent」？

Agent 是指 LLM 動態決定要調用哪些工具以及如何排序動作，並對過程保持控制權的系統。相比之下，workflow 則遵循固定的程式碼路徑來編排 LLM 調用與工具。這種區別構成了指南的其餘部分。

何時採用 Agentic 系統

  • 從簡單開始：優先使用帶有檢索 (retrieval) 與上下文範例 (in‑context examples) 的單一 LLM 調用。只有在能明顯改善結果時才增加複雜度。
  • 權衡意識：Agent 會增加延遲與成本，但對於開放式問題，它們可以提升任務表現。
  • 在模式之間做出選擇：
    • Workflows → 對定義明確的任務進行可預測且一致的處理。
    • Agents → 在大規模應用中進行靈活且由模型驅動的決策。

框架 vs. 直接使用 API

  • 熱門的 SDK (Claude Agent SDK, Strands Agents SDK, Rivet, Vellum) 透過抽象化 LLM 調用、工具解析與鏈結來降低進入門檻。
  • 注意：抽象化可能會隱藏提示詞與回應，使得除錯變得更困難，並鼓勵不必要的複雜度。
  • 建議：從原始的 LLM API 開始；如果使用框架，請保持對底層程式碼的可視性。

核心構建模組：增強型 LLM

Augmented LLM 將基礎模型與檢索 (retrieval)、工具使用與記憶結合起來。Anthropic 的模型可以生成搜尋查詢、選擇工具，並決定保留哪些內容。Model Context Protocol 為整合第三方工具提供了標準的客戶端實作。

常見的工作流模式

1. Prompt chaining

  • 定義：將任務分解為連續的 LLM 調用，並可選擇性地插入程式化閘門 (programmatic gates)。
  • 何時使用：固定子任務，且高準確度比增加的延遲更重要時。
  • 範例：生成行銷文案 → 翻譯；大綱 → 驗證 → 撰寫完整文件。

2. Routing

  • 定義：分類輸入並將其分發給專業化的下游提示詞或工具。
  • 何時使用：具有不同類別且能從量身定制的處理中獲益的任務。
  • 範例：將客戶服務查詢路由至不同的處理程序；將簡單問題發送給 Claude Haiku 4.5，將困難問題發送給 Claude Sonnet 4.5。

3. Parallelization

  • 變體：
    • Sectioning – 將獨立的子任務拆分並同時執行。
    • Voting – 同時執行多次相同的提示詞以收集多樣化的答案。
  • 何時使用：透過並行處理獲得速度提升，或透過多種觀點獲得更高的信心度。
  • 範例：護欄 (guardrails)（使用獨立模型進行安全篩選）；使用多個提示詞進行程式碼漏洞審查；內容審查投票。

4. Orchestrator‑workers

  • 定義：一個中央 LLM 動態地將問題分解為子任務，委派給工作者 LLM，並綜合結果。
  • 何時使用：複雜且不可預測的任務，其中子任務無法預先定義（例如：多檔案程式碼變更、多來源搜尋）。

5. Evaluator‑optimizer

  • 定義：一個 LLM 生成輸出；第二個 LLM 進行評估並提供回饋，形成一個迭代優化的循環。
  • 何時使用：存在明確的評估標準，且迭代改進能帶來可衡量的價值時。
  • 範例：文學翻譯（帶有細微差別的評論）；多輪搜尋，其中評估者決定是否需要進一步探詢。

Autonomous agents

  • 生命週期：接收指令或互動式提示詞 → 規劃 → 在循環中執行工具調用 → (可選) 暫停以獲需人類回饋 → 在完成或達到最大迭代次數限制後終止。
  • 關鍵需求：
    1. 具有清晰文件說明的 robust toolset。
    2. 來自環境的 ground‑truth 回饋。
    3. 為了減輕累積錯誤，需具備護欄 (guardrails) 與沙盒測試。
  • 何時使用：對於步驟數不可預測的開放式問題，且對模型的決策能力有足夠信任時。
  • 實際案例：
    • 解決 SWE‑bench 任務的程式碼 Agent，透過編輯多個檔案來完成。
    • 「Computer use」演示，其中 Claude 控制桌面以達成用戶指定的目標。

組合與自定義模式

本文提出的模式是構建模組，而非嚴格的食譜。 開發者應該：

  • 在每個階段衡量效能。
  • 僅在能帶來可衡量的改進時才增加複雜度。
  • 對提示詞、工具定義與編排邏輯進行迭代。

可靠 Agent 的核心原則

  1. Simplicity – 保持 Agent 的設計極簡化。
  2. Transparency – 在日誌中公開規劃步驟與工具調用。
  3. Tool engineering – 投入於開發清晰、文件完善的工具介面（見附錄 2）。

附錄 1 – Agent 實務應用 (摘要)

  • 客戶服務：對話式流程結合工具整合（例如：獲取訂單數據、發行退款）可實現可衡量的解決率指標。
  • 程式碼 Agent：自動化測試提供客觀驗證；Agent 透過測試回饋來迭代，以解決真實的 GitHub issues。

附錄 2 – 工具的提示詞工程

  • 設計技巧：
    • 為模型提供足夠的 tokens 以便在必須發出工具調用之前進行思考。
    • 使用模型熟悉的格式（例如：使用純程式碼而非重度轉義的 JSON）。
    • 避免不必要的格式化開銷（不進行行數追蹤、最小化轉義）。
  • 人機介面思維：將工具規格書視為開發者 docstrings——包含範例、邊緣案例與清晰的參數名稱。
  • 測試：在 Anthropic 的 workbench 中執行大量範例，以發現誤用模式。
  • Poka‑yoke（防錯設計）：結構化參數以使模型難以犯錯。
  • 案例研究：在 SWE‑bench agent 中將相對路徑切換為絕對路徑，消除了路徑解析錯誤。

最終總結

使用 LLM agent 的成功關鍵不在於建立最複雜的架構，而是在於選擇正確的可組合模式、嚴格測試工具介面，並僅在能帶來明顯改進結果時才增加複雜度層級。

Sources

相關