文章轉載自「INDIGO 科技加速站」

Anthropic 工程師 Barry Zhang 在 AI Engineer 工作坊上的一個分享 “如何構建有效的 Agent”，其中印象最深的一個觀點：Don't build agents for everything，反過來理解就是別做什么都能干的 Agent，那是我們大模型要干的事情

構建有效 Agent 的三大要點：

1. 明智選擇應用場景，并非所有任務都需要 Agent

2. 找到合適的用例后，盡可能長時間地保持系統簡單

3. 在迭代過程中，嘗試從 Agent 的視角思考，理解其局限并提供幫助

Barry 主要負責 Agentic System，演講內容基于他和 Eric 合著的一篇博文，下面詳細總結他們的核心觀點，以及對 Agent 系統的演進和未來的思考。

Agent 系統的演進

1. 簡單功能（Simple Features）：起初是簡單的任務，如摘要、分類、提取，這些在幾年前看似神奇，現在已成為基礎。

2. 工作流（Workflows）：隨著模型和產品成熟，開始編排多個模型調用，形成預定義的控制流，以犧牲成本和延遲換取更好性能。這被認為是 Agent 系統的前身。

3. Agent：當前階段，模型能力更強，領域特定的 Agent 開始出現。與工作流不同，Agent 可以根據環境反饋自主決定行動路徑，幾乎獨立運作。

4. 未來（猜測）：可能是更通用的單一 Agent，或多 Agent 協作。趨勢是賦予系統更多自主權，使其更強大有用，但也伴隨著更高的成本、延遲和錯誤后果。

Founder Park 正在搭建開發者社群，邀請積極嘗試、測試新模型、新技術的開發者、創業者們加入，請掃碼詳細填寫你的產品/項目信息，通過審核后工作人員會拉你入群～

進群之后，你有機會得到：

• 高濃度的主流模型（如 DeepSeek 等）開發交流；

• 資源對接，與 API、云廠商、模型廠商直接交流反饋的機會；

• 好用、有趣的產品/案例，Founder Park 會主動做宣傳。

01并非所有場景都適合構建 Agent(Don't build agents for everything)

Agent 主要用于擴展復雜且有價值的任務，它們成本高、延遲高，不應作為所有用例的直接升級。對于可以清晰映射決策樹的任務，顯式構建工作流（Workflow）更具成本效益和可控性。

何時構建 Agent 的檢查清單：

1. 任務復雜度 (Complexity)：Agent 擅長處理模糊的問題空間。如果決策路徑清晰，應優先選擇工作流。

2. 任務價值 (Value)：Agent 的探索性行為會消耗大量 token，任務的價值必須能證明其成本。對于預算有限（如每任務 10 美分）或高容量（如客服）場景，工作流可能更合適。

3. 關鍵能力的可行性 (Derisk Critical Capabilities)：需確保 Agent 在關鍵環節（如編碼 Agent 的編寫、調試、錯誤恢復能力）不存在嚴重瓶頸，否則會顯著增加成本和延遲。如有瓶頸，應簡化任務范圍。

4. 錯誤成本與發現難度 (Cost of Error & Error Discovery)：如果錯誤代價高昂且難以發現，就很難信任 Agent 自主行動。可以通過限制范圍（如只讀權限、增加人工干預）來緩解，但這也會限制其擴展性。

編碼（Coding）是一個很好的 Agent 用例，因為它任務復雜（從設計文檔到 PR）、價值高、現有模型（如 Claude）在許多環節表現良好，且結果易于驗證（單元測試、CI）。

02保持簡單 (Keep it simple)

Agent 的核心結構：

模型（Model）+ 工具（Tools）+ 循環（Loop）在一個環境（Environment）中運作。

三個關鍵組成部分：
1.環境 (Environment)：Agent 操作所在的系統。
2.工具集 (Tools)：Agent 采取行動和獲取反饋的接口。
3.系統提示 (System Prompt)：定義 Agent 的目標、約束和理想行為。

迭代方法：

優先構建和迭代這三個基本組件，能獲得最高的投資回報率。避免一開始就過度復雜化，這會扼殺迭代速度。優化（如緩存軌跡、并行化工具調用、改進用戶界面以增強信任）應在基本行為確定后再進行。

一致性：

盡管不同 Agent 應用（編碼、搜索、計算機使用）在產品層面、范圍和能力上看起來不同，但它們共享幾乎相同的簡單后端架構。

03像 Agent 一樣思考(Think like your agents)

問題：
開發者常從自身角度出發，難以理解 Agent 為何會犯看似反常的錯誤。

解決方法：
將自己置于 Agent 的“上下文窗口”中。Agent 在每一步的決策都基于有限的上下文信息（如 10k-20k token）。

換位思考練習：
嘗試從 Agent 的視角完成任務，體驗其局限性（例如，只能看到靜態截圖，在推理和工具執行期間如同“閉眼”操作）。這有助于發現 Agent 真正需要哪些信息（如屏幕分辨率、推薦操作、限制條件）以避免不必要的探索。

利用模型自身：
可以直接詢問模型（如 Claude）：指令是否模糊？是否理解工具描述？為什么做出某個決策？如何幫助它做出更好的決策？這有助于彌合開發者與 Agent 之間的理解差距。

04個人思考與未來展望

1. 預算感知 Agent (Budget-aware Agents)：

需要更好地控制 Agent 的成本和延遲，定義和強制執行時間、金錢、token 預算，以便在生產環境中更廣泛地部署。

2. 自進化工具 (Self-evolving Tools)：

Agent 或許能設計和改進自己的工具（元工具），使其更具通用性，能適應不同用例的需求。

3. 多 Agent 協作 (Multi-agent Collaboration)：

預計今年年底將在生產中看到更多多 Agent 系統。其優勢包括并行化、關注點分離、保護主 Agent 上下文窗口等。關鍵挑戰在于 Agent 間的通信方式，如何實現異步通信，超越當前的用戶-助手輪流模式。

引用鏈接:

[1]How We Built Effective Agents: Barry Zhang, Anthropic: https://youtu.be/D7_ipDqhtwk?si=atqYQAuvl0xWwrcH

轉載原創文章請添加微信：founderparker