作者 | fred

歷經(jīng)多個業(yè)務系統(tǒng)的構(gòu)建，我深感Anthropic的《Build effective agents》一文與自身實戰(zhàn)經(jīng)歷高度契合。本文在詳解工作流與Agent的技術(shù)選型標準、設(shè)計模式應用及實施要點的同時，也融入了我的實戰(zhàn)心得與實踐經(jīng)驗總結(jié)。無論您正考慮構(gòu)建工作流系統(tǒng)還是Agent系統(tǒng)，都能在此找到適合場景的最佳實踐方案。特別值得關(guān)注的是文末的工具提示工程部分，這是Agent成功實施的關(guān)鍵因素。

本文從Anthropic的文章《Build effective agents》出發(fā)，為構(gòu)建高效的工作流、Agent提出實戰(zhàn)指南。我在保留原文精華的基礎(chǔ)上增強了三個核心方面：

核心內(nèi)容：

• 技術(shù)選型指南：明確工作流/Agent選用標準。
• 設(shè)計模式解析：通過實際業(yè)務場景展示復雜工作流模式的應用。
• 實踐要點擴展：增添詳細的實施建議和操作要點，將理論轉(zhuǎn)化為可執(zhí)行方案。

本文適合AI Agent技術(shù)管理者、開發(fā)者、產(chǎn)品經(jīng)理及愛好者閱讀，通過實踐層面的指導，幫您實現(xiàn)更合理的方案與更高效的實施。

一、Agent概述

1. 什么是Agent？

"Agent"有多種定義方式。部分客戶將其視為完全自主系統(tǒng)，能在較長時間內(nèi)獨立運行，使用各種工具完成復雜任務。也有人用此術(shù)語描述更固定的、預定義的工作流。Anthropic將這些變體歸類為類Agent系統(tǒng)，但在工作流和智能體間做了重要區(qū)分：

2. Workflow V.S Agent

在附錄1("Agent實戰(zhàn)")中，Anthropic描述了客戶在使用這類系統(tǒng)時發(fā)現(xiàn)特別有價值的兩個應用領(lǐng)域。

二、何時使用Agent

簡單性原則：適用場景評估

Anthropic強烈建議：在構(gòu)建LLM應用時，尋找盡可能簡單的解決方案，只在必要時增加應用復雜性。

關(guān)鍵權(quán)衡：類Agent系統(tǒng)通常以延遲和成本為代價換取更高性能，應謹慎評估這種取舍。

復雜性增加的指導原則：

• 選擇工作流：當任務明確定義，需要可預測性和一致性
• 選擇Agent：當任務需要靈活性和模型驅(qū)動的動態(tài)決策

重要提示：對許多應用而言，優(yōu)化單個LLM調(diào)用（通過檢索增強和上下文示例）通常已足夠有效。

三、何時、如何使用“Agent框架”

1. 框架使用的權(quán)衡考量

開發(fā)框架雖然便捷，但常存在過度抽象問題，使底層提示詞和LLM調(diào)用被隱藏。這導致兩個主要風險：

• 使用框架開發(fā)的Agent系統(tǒng)難以有效調(diào)試
• 簡化的搭建流程使開發(fā)者容易過度增加系統(tǒng)復雜性

2. 實用開發(fā)建議

Anthropic建議采取漸進式開發(fā)方法：

• 優(yōu)先直接使用LLM API：大多數(shù)模式可通過幾行代碼實現(xiàn)
• 深入理解框架底層：如選擇框架，確保理解其內(nèi)部工作機制
• 避免錯誤假設(shè)：對框架底層工作原理的誤解是項目失敗的常見原因

“我們建議開發(fā)者直接使用LLM API：許多模式可以用幾行代碼實現(xiàn)。如果你使用框架，請確保理解底層代碼。對底層工作的錯誤假設(shè)是客戶錯誤的常見來源?！?/p>

參考Anthropic的cookbook[1]獲取示例實現(xiàn)。

四、Agent系統(tǒng)設(shè)計模式

本節(jié)探討生產(chǎn)環(huán)境中常見的類Agent系統(tǒng)模式。Anthropic從基礎(chǔ)構(gòu)建模塊——增強型大語言模型(LLM)開始，逐步增加復雜性，從簡單組合工作流到自主Agent。

1. 增強型LLM模式

定義：類Agent系統(tǒng)最基礎(chǔ)的模塊是"增強的LLM"，即具備檢索、工具使用和記憶等功能的語言模型。Anthropic當前的模型能夠主動使用這些功能——生成搜索查詢、選擇合適工具以及確定需要記憶的信息。

增強型LLM

工程實現(xiàn)的關(guān)鍵要點：

• 為特定應用場景定制增強能力
• 確保為LLM提供簡單、文檔完善的接口

雖然實現(xiàn)這些增強功能的方法很多，一種推薦方式是通過Anthropic最近發(fā)布的模型上下文協(xié)議(MCP)，該協(xié)議允許開發(fā)者通過簡單的客戶端實現(xiàn)與不斷擴展的第三方工具生態(tài)系統(tǒng)集成。

2. 工作流模式

(1) 提示鏈

定義：提示鏈將任務分解為一系列有序步驟，每個LLM調(diào)用處理前一個調(diào)用的輸出?？稍谌魏沃虚g步驟添加程序檢查（"門控"）以確保流程保持在正確軌道上。

提示鏈工作流

適用場景：

• 任務可以輕松且清晰地分解為固定子任務時
• 主要目標是通過犧牲延遲來提高準確性，使每個LLM調(diào)用處理更簡單的子任務

應用示例：

• 生成營銷文案，然后將其翻譯成不同的語言。
• 編寫文檔大綱，檢查大綱是否符合特定標準，然后基于大綱撰寫文檔。

(2) 路由

定義：路由工作流對輸入進行分類并將其引導到專門的后續(xù)任務。這種工作流實現(xiàn)關(guān)注點分離，并構(gòu)建更專門化的提示。不使用路由時，為某一類輸入優(yōu)化可能會降低其他類型輸入的處理效果。

路由工作流

適用場景：

• 復雜任務包含明顯不同類別需要單獨處理
• 分類可由LLM或傳統(tǒng)分類模型/算法準確完成

應用示例：

• 引導不同類型客戶服務查詢（一般問題、退款請求、技術(shù)支持）進入不同的下游流程、提示和工具。
• 將簡單/常見問題路由到較小模型（如Claude 3.5 Haiku），將困難/不常見問題路由到更強大模型（如Claude 3.5 Sonnet），優(yōu)化成本和響應速度。

(3) 并行化

定義：并行化工作流讓LLM同時處理多個任務，并通過程序化方式聚合輸出。分為兩種關(guān)鍵形式：

• 任務拆分（Sectioning）：將任務拆分為獨立的子任務并行運行
• 投票（Voting）：多次運行相同任務以獲得不同的結(jié)果

并行化工作流

適用場景：

• 當拆分的子任務可以并行處理以提高速度
• 需要多種視角或不同嘗試來獲得更高置信度的結(jié)果時
• 復雜任務涉及多種考慮因素時，由獨立LLM調(diào)用分別處理各因素效果更佳。

應用示例：

①任務拆分（Sectioning）

• 安全防護機制：一個模型處理用戶查詢，另一個篩選不合規(guī)內(nèi)容，比單模型同時處理兩項功能效果更好。
• 自動化評估LLM性能：設(shè)置多個并行分支，評估模型在不同方面的表現(xiàn)。

②投票（Voting）

• 代碼漏洞審查：多個并行LLM分支審查代碼并標記問題。
• 內(nèi)容審核：并行評估內(nèi)容合規(guī)性，不同提示專注于不同評估維度，通過差異化投票閾值平衡誤報率與漏報率。

應用案例：內(nèi)容審核系統(tǒng)

假設(shè)我們正在構(gòu)建一個社交媒體平臺的內(nèi)容審核系統(tǒng)，需要評估用戶發(fā)布的以下內(nèi)容是否適當：

用戶發(fā)布內(nèi)容示例：

"這些政客都是垃圾，應該被扔進海里喂鯊魚。大家都應該去抗議這個荒謬的新政策，讓他們知道我們的憤怒！"

實現(xiàn)方案：

① 并行LLM提示（專注不同維度）

• 提示1：評估暴力內(nèi)容
• 提示2：評估仇恨言論
• 提示3：評估不文明用語
• 提示4：評估合法政治表達
• 提示5：評估煽動抗議

② 差異化投票閾值設(shè)置

暴力威脅：低閾值(高敏感度)

• 提示1為"是"→內(nèi)容立即標記
• 理由：潛在危害大，寧可誤報也不能漏報

仇恨言論：中等閾值

• 提示2和提示3都為"是"→內(nèi)容標記
• 理由：需更多證據(jù)確認真正仇恨言論

政治表達：高閾值（寬容度高）

• 提示4為"是"且提示1、2不為"是"→允許內(nèi)容
• 理由：保護合法政治表達，避免過度審查

③ 決策流程示例

并行評估結(jié)果：

• 提示1（暴力）："是"（提到"扔進海里喂鯊魚"）
• 提示2（仇恨）："否"（針對政客非受保護群體）
• 提示3（不文明）："是"（使用"垃圾"等貶義詞）
• 提示4（政治表達）："是"（政策批評）
• 提示5（煽動抗議）："是"（鼓勵和平抗議）

規(guī)則應用：

• 暴力威脅閾值觸發(fā)（提示1為"是"）
• 政治表達規(guī)則也滿足
• 系統(tǒng)標記為"邊緣案例"，轉(zhuǎn)人工審核

系統(tǒng)優(yōu)勢：平衡誤報和漏報

這種多方面并行評估系統(tǒng)能夠：

• 減少漏報：低閾值捕獲嚴重違規(guī)(如明確暴力威脅)
• 減少誤報：多角度評估避免過度審查合法內(nèi)容
• 細粒度分析：識別具體問題方面，非簡單二分法
• 差異化風險應對：對不同類型違規(guī)設(shè)置不同敏感度

這種并行投票系統(tǒng)能同時考慮內(nèi)容多個維度，根據(jù)不同維度的嚴重性設(shè)置差異化決策標準，實現(xiàn)更平衡、更細致的內(nèi)容適當性評估，特別適合處理復雜邊界案例。

(4) 編排者-工作者

定義：在編排者-工作者工作流中，編排者（LLM）動態(tài)分解任務，將其委派給工作者LLM，并綜合其結(jié)果。

編排者-工作者工作流

適用場景：

• 適合無法預測所需子任務的復雜任務
• 與并行化的關(guān)鍵區(qū)別在于靈活性——子任務不是預定義的，而是由編排者根據(jù)任務輸入動態(tài)確定

應用示例：

• 需要對多個代碼文件進行編輯的編碼項目
• 涉及從多個來源收集和分析信息的搜索任務

應用案例：醫(yī)療研究助手

假設(shè)我們正在構(gòu)建一個醫(yī)療研究助手，研究人員輸入了以下查詢：

用戶查詢：

"我需要了解最近三年內(nèi)關(guān)于長新冠與認知障礙關(guān)聯(lián)的研究結(jié)果，特別是那些包含臨床試驗數(shù)據(jù)的研究。"

編排者-工作者工作流實現(xiàn)：

① 編排者規(guī)劃階段

編排者LLM接收查詢并制定搜索計劃：搜索計劃

• 識別關(guān)鍵搜索術(shù)語和相關(guān)概念
• 確定需要搜索的最佳來源
• 為每個來源設(shè)計特定搜索策略
• 分配多名工作者執(zhí)行不同來源的搜索
• 匯總和綜合所有發(fā)現(xiàn)的信息
• 確定是否需要進一步搜索
• 準備最終報告

② 工作者執(zhí)行階段

編排者將任務分配給多個專門的工作者LLM：

工作者1：醫(yī)學文獻搜索

• 任務：在PubMed和醫(yī)學期刊數(shù)據(jù)庫中搜索長新冠與認知障礙相關(guān)論文
• 搜索條件：發(fā)表于2022-2025年間，包含臨床試驗數(shù)據(jù)
• 工具：使用API接口查詢醫(yī)學數(shù)據(jù)庫
• 產(chǎn)出：找到15篇相關(guān)論文，包含初步結(jié)果摘要

工作者2：研究機構(gòu)報告搜索

• 任務：搜索CDC、WHO、NIH等機構(gòu)發(fā)布的長新冠研究報告
• 搜索條件：關(guān)注認知障礙相關(guān)發(fā)現(xiàn)
• 工具：機構(gòu)網(wǎng)站API和網(wǎng)頁抓取
• 產(chǎn)出：找到3份官方報告和2個正在進行的研究項目

工作者3：臨床試驗數(shù)據(jù)庫搜索

• 任務：在ClinicalTrials.gov等數(shù)據(jù)庫中搜索相關(guān)臨床試驗
• 搜索條件：長新冠與認知功能相關(guān)，已完成或有初步數(shù)據(jù)
• 工具：臨床試驗注冊數(shù)據(jù)庫API
• 產(chǎn)出：識別7個相關(guān)臨床試驗，包括3個有初步結(jié)果的試驗

工作者4：醫(yī)學會議與預印本資料搜索

• 任務：在研究預印本服務器和近期會議記錄中搜索
• 搜索條件：最新未正式發(fā)表的研究
• 工具：預印本服務器API和會議數(shù)據(jù)庫
• 產(chǎn)出：找到5篇預印本論文和2個會議演講

③ 信息分析與綜合

編排者接收所有工作者的搜索結(jié)果，然后：

• 識別重復信息：消除不同來源的重復研究
• 評估證據(jù)質(zhì)量：按照研究設(shè)計、樣本量、期刊影響因子等標準評估每篇研究
• 識別共同主題：分析跨多個研究的一致性發(fā)現(xiàn)
• 發(fā)現(xiàn)研究差距：識別缺乏研究的領(lǐng)域
• 權(quán)衡相互矛盾的結(jié)果：評估不同研究之間的差異原因

④ 動態(tài)迭代（可選）

編排者可能發(fā)現(xiàn)需要進一步信息：

• "注意到大多數(shù)研究未考慮年齡分層效應，需要專門搜索老年群體中的長新冠認知影響"
• 分配工作者5進行補充搜索，聚焦老年人群研究

⑤ 最終報告生成

編排者綜合所有信息生成最終報告：

• 總結(jié)主要發(fā)現(xiàn)
• 按證據(jù)強度和一致性水平組織信息
• 提供研究限制和未來研究方向
• 附上所有來源的完整引用

工作流優(yōu)勢：

• 全面性：多渠道信息收集確保研究覆蓋面廣
• 專業(yè)化：各工作者專注于特定來源和搜索策略
• 適應性：能根據(jù)初步發(fā)現(xiàn)調(diào)整搜索策略
• 深度分析：綜合多源信息進行對比分析
• 效率提升：并行搜索不同來源大幅節(jié)省時間

(5) 評估-優(yōu)化

定義：一個LLM調(diào)用生成響應，而另一個在循環(huán)中提供評估和反饋。

評估-優(yōu)化工作流

適用場景：當我們有明確的評估標準，且迭代優(yōu)化能提供可量化價值的情境

適合場景的兩個標志：

• 人類反饋能明顯改進LLM響應質(zhì)量
• LLM本身能提供類似人類的有效反饋

應用示例：

• 文學翻譯：初譯(生成) → 評估細微差別 → 根據(jù)反饋優(yōu)化 → 循環(huán)至達標
• 復雜信息搜索：初步搜索(生成) → 評估完整性 → 指出信息缺口 → 補充搜索 → 循環(huán)至完整（例如，DeepRearch）

應用案例：文學翻譯優(yōu)化系統(tǒng)

目標：將《了不起的蓋茨比》翻譯成保留原著文學風格和情感的中文版

角色分工：

• 優(yōu)化者LLM：負責生成翻譯
• 評估者LLM：評估質(zhì)量并提供改進建議

評估維度：準確性、風格一致性、文化適應性

最大迭代：3次（防止循環(huán)）

流程示例：

原文：

"In my younger and more vulnerable years my father gave me some advice that I've been turning over in my mind ever since. 'Whenever you feel like criticizing anyone,' he told me, 'just remember that all the people in this world haven't had the advantages that you've had.'"

① 迭代1

初次翻譯：

"在我年輕、更加脆弱的歲月里，父親給了我一些建議，我自那以后一直在腦海中回味。'每當你想批評任何人的時候，'他對我說，'請記住，這個世界上的所有人都沒有得到過你所擁有的那些優(yōu)勢。'"

評估（7/10）：

• ? 整體準確，主要含義傳達
• ? "turning over in my mind"→"回味"不準確
• ? "advantages"→"優(yōu)勢"過于直白
• ? 語氣平淡，缺少情感色彩
• ? 需要更流暢的過渡詞

② 迭代2

修改版：

"在我年少輕狂、尚且脆弱的歲月里，父親給了我一條忠告，此后我一直在心中反復思量。'每當你想要批評任何人的時候，'他對我說道，'請記住，這世上并非所有人都擁有過你所享有的那些機遇和條件。'"

評估（9/10）：

• ? 關(guān)鍵詞翻譯更準確
• ? 文學色彩增強
• ? 過渡更自然
• ? "年少輕狂"略帶貶義
• ? 最后一句可更精煉

③ 迭代3（最終版）：

最終翻譯：

"在我年少青澀、心思易傷的歲月里，父親給了我一條忠告，此后我便一直在心中反復思量。'每當你想要批評任何人，'他告誡我道，'請記住，這世上并非所有人都有幸獲得你所享有的那些機遇。'"

最終評估（10/10）：

• ? 完美捕捉原文情感和風格
• ? 用詞準確且富有文學性
• ? 結(jié)構(gòu)精煉，符合中文閱讀習慣
• ? 平衡了忠于原文與文化適應性

工作流優(yōu)勢：

• 質(zhì)量提升：通過專門評估角色和多輪迭代提高輸出質(zhì)量
• 自我改進：系統(tǒng)識別不足并主動優(yōu)化
• 透明度：評估標準和反饋可被清晰記錄
• 減少人工干預：在保持高質(zhì)量的同時減少人類參與
• 適應性：可根據(jù)特定領(lǐng)域定制評估標準

實施建議：

• 明確定義評估標準和質(zhì)量指南
• 設(shè)置合理迭代次數(shù)上限
• 保持優(yōu)化者和評估者角色分離
• 跟蹤記錄每次迭代的變化
• 在關(guān)鍵應用中保留人類最終審核

這種工作流特別適合需要高質(zhì)量、精心斟酌輸出的場景，模擬了人類專業(yè)人士的迭代改進過程。

3. 完整Agent模式

(1) Agent設(shè)計要點

隨著大模型核心能力的成熟（理解復雜輸入、推理規(guī)劃、工具使用、錯誤恢復），智能體正在生產(chǎn)環(huán)境中嶄露頭角。智能體的典型工作流程為：

• 啟動階段：接收用戶命令或通過交互確定任務
• 規(guī)劃執(zhí)行：任務明確后獨立規(guī)劃操作，必要時向人類請求更多信息
• 環(huán)境感知：每步驟從環(huán)境獲取"基礎(chǔ)事實"（工具調(diào)用結(jié)果或代碼執(zhí)行）評估進展
• 反饋循環(huán)：在檢查點或遇障礙時可暫停等待人類反饋
• 任務終止：通常在完成時終止，包含停止條件（如最大迭代次數(shù)）以保持控制

Agents can handle sophisticated tasks, but their implementation is often straightforward. They are typically just LLMs using tools based on environmental feedback in a loop. It is therefore crucial to design toolsets and their documentation clearly and thoughtfully.

智能體可以處理復雜任務，但其實現(xiàn)通常很直接 - 本質(zhì)上是在循環(huán)中基于環(huán)境反饋使用工具的LLMs。

因此，清晰且合理的工具集及其說明文檔至關(guān)重要。

我們在附錄2中詳述了工具開發(fā)的最佳實踐。

工具集及其文檔質(zhì)量直接決定智能體的成功率和速度，體現(xiàn)在：

• Agent選擇合適工具及調(diào)用順序的能力
• Agent正確填寫工具參數(shù)的能力
• Agent有效利用工具結(jié)果的能力

自主Agent

① 何時使用Agent：

Agent適用于開放性問題，這些問題特點是：

• 難以或不可能預測所需步驟數(shù)量
• 無法硬編碼固定解決路徑

在這類場景中，LLM可能需要多輪操作，您必須對其決策過程有一定信任度。

需要注意的是，Agent的自主性意味著：

• 可能產(chǎn)生更高成本
• 存在錯誤累積的潛在風險

建議在實際部署前在沙盒環(huán)境中進行廣泛測試，并設(shè)置適當?shù)谋Ｗo措施。

② Agent應用舉例：

以下是來自Anthropic實際實現(xiàn)的示例：

• 編程Agent：解決SWE-bench任務，根據(jù)任務描述對多個文件進行編輯
• 計算機使用Agent：computer use，Claude使用計算機完成復雜任務

編碼Agent的流程

4. 模式組合與定制

正如文章開頭所強調(diào)，"最成功的實現(xiàn)采用簡單、可組合的模式，而非復雜的框架"。這些設(shè)計模式是靈活的構(gòu)建模塊，可以根據(jù)具體應用需求進行組合和定制。

(1) 關(guān)鍵原則

• 這些模式是可自由組合的構(gòu)建塊，非固定框架
• 通過量化性能評估和迭代確定最佳組合
• 重要提示：僅在能顯著提升效果時才增加復雜性

(2) 五種高效組合模式

① 提示鏈 + 路由：

• 機制：路由分類任務，然后應用專用提示鏈
• 示例：客服系統(tǒng)先分類問題(賬單/技術(shù)/退款)，再應用對應專業(yè)處理鏈。

② 路由 + 并行化：

• 機制：先分類任務，對特定類別應用并行處理
• 示例：內(nèi)容審核系統(tǒng)分類內(nèi)容后，對復雜案例啟用多評估者并行投票。

③ 編排者-工作者 + 評估者-優(yōu)化者：

• 機制：編排者分解分配任務，工作者執(zhí)行，評估者提供反饋優(yōu)化
• 示例：代碼系統(tǒng)中編排者確定修改文件，工作者生成代碼，評估者檢查提供改進建議

④ 提示鏈 + 評估者-優(yōu)化者：

• 機制：在提示鏈關(guān)鍵節(jié)點使用評估-優(yōu)化循環(huán)提升質(zhì)量
• 示例：內(nèi)容創(chuàng)作流程生成大綱→細化大綱→基于大綱創(chuàng)作→評估優(yōu)化

⑤ 混合Agent系統(tǒng)：

• 機制：整合多種模式，不同任務階段使用最適合的模式
• 示例：全功能客服Agent先路由分類查詢，簡單問題用提示鏈，復雜問題用編排者-工作者，全程通過評估者-優(yōu)化者保證質(zhì)量

(3) 實施建議

• 從簡單開始，基于性能數(shù)據(jù)增加復雜性
• 關(guān)注每個組合的接口設(shè)計，確保信息順暢傳遞
• 設(shè)置明確的評估指標，量化每種組合的效果提升
• 注意模式組合可能增加成本和延遲，權(quán)衡利弊
• 建立有效的監(jiān)控和失敗恢復機制

(4) 組合設(shè)計的優(yōu)勢

• 靈活應對不同復雜度的任務需求
• 結(jié)合各個模式的優(yōu)勢創(chuàng)造協(xié)同效應
• 隨著需求變化可漸進式擴展系統(tǒng)能力
• 各組件可獨立優(yōu)化，提高整體系統(tǒng)可維護性

五、實踐指南

1. 核心建議

「在LLM領(lǐng)域，最成功的實現(xiàn)不是構(gòu)建最復雜的系統(tǒng)，而是為特定需求構(gòu)建最合適的系統(tǒng)?！故紫葟暮唵蔚奶崾驹~開始，通過全面評估進行優(yōu)化，僅在簡單解決方案不足時才添加更多步驟的類Agent系統(tǒng)。

2. Agents開發(fā)原則

在實現(xiàn)Agent時，我們盡量遵循三個核心原則：

• 保持簡單性：只在能夠明顯改善結(jié)果時增加復雜性
• 透明性：明確展示Agent的規(guī)劃步驟來保證透明度
• 精心設(shè)計工具接口：通過詳細的工具文檔和充分的測試創(chuàng)建良好的Agent-計算機接口（ACI）

雖然開發(fā)框架可幫助快速入門，但轉(zhuǎn)向生產(chǎn)環(huán)境時，應減少抽象層級，直接使用基本組件構(gòu)建。遵循上述原則，你可以創(chuàng)建強大、可靠、可維護且受用戶信賴的智能體系統(tǒng)。

六、附錄1: Agent實戰(zhàn)

1. 智能體的實踐價值與應用條件

基于客戶合作經(jīng)驗，AI智能體在同時滿足以下條件的任務中能創(chuàng)造最大價值：

• 需要對話與行動相結(jié)合
• 具有明確的成功衡量標準
• 能夠形成有效反饋循環(huán)
• 整合有意義的人類監(jiān)督機制

2. 成功案例分析

案例一：智能客服

優(yōu)勢契合點：

• 自然對話流程：客服交互天然符合會話模式，同時需要信息檢索和行動執(zhí)行
• 工具集成能力：可接入客戶數(shù)據(jù)、訂單歷史和知識庫資源
• 行動自動化：退款處理、工單更新等可程序化執(zhí)行
• 清晰成功指標：通過用戶問題解決率直接衡量成效

商業(yè)驗證：

多家企業(yè)采用基于成功解決的定價模型（僅對成功解決的案例收費），證明了Agent在客戶支持領(lǐng)域的實際價值和可靠性。

案例二：編程Agent

應用優(yōu)勢：

• 解決方案可驗證：代碼輸出可通過自動化測試客觀驗證
• 反饋驅(qū)動優(yōu)化：測試結(jié)果提供明確反饋，支持Agent迭代改進
• 問題域結(jié)構(gòu)化：軟件開發(fā)問題通常有明確邊界和結(jié)構(gòu)
• 輸出質(zhì)量可量化：代碼性能和質(zhì)量可通過既定指標評估

實際成果：

在實際實現(xiàn)中，AI智能體能夠僅基于拉取請求描述解決SWE-bench Verified 基準測試中的真實GitHub問題，展示了在結(jié)構(gòu)化問題解決中的實際能力。

人類監(jiān)督價值：

盡管自動化測試能驗證功能正確性，人類審查仍在確保解決方案符合更廣泛系統(tǒng)要求方面發(fā)揮關(guān)鍵作用。

3. 實施要點

• 明確定義任務范圍：設(shè)置清晰的Agent職責邊界和權(quán)限
• 精心設(shè)計工具集：提供Agent所需的全部工具并優(yōu)化其文檔
• 建立反饋機制：確保Agent能接收并利用執(zhí)行結(jié)果改進行動
• 設(shè)置監(jiān)督檢查點：在關(guān)鍵決策節(jié)點引入人類監(jiān)督
• 量化成功指標：建立客觀評估Agent表現(xiàn)的指標體系

七、附錄2：工具提示工程

1. 定義

工具提示工程指的是：像編寫提示詞一樣設(shè)計工具定義，使大模型能清晰理解工具的用途、使用方法和結(jié)果含義。

2. 基本原則

清晰表達：

• 使用精確的術(shù)語描述工具功能
• 明確說明輸入?yún)?shù)的要求和格式
• 詳細解釋輸出結(jié)果的結(jié)構(gòu)和意義
• 包含使用限制和邊界條件

推薦參考我的另一篇文章從模糊到具體：高效使用DeepSeek-R1等推理型模型的前置步驟，使用問題定義優(yōu)化器提示詞，輔助完成清晰表達。

壓縮表達：

• 避免冗余信息，保持描述簡潔
• 使用結(jié)構(gòu)化格式提高可讀性
• 關(guān)注必要信息，減少不相關(guān)細節(jié)
• 確保核心用途和用法一目了然

3. 工具系統(tǒng)設(shè)計詳解

(1) 工具在Agent系統(tǒng)中的核心地位

在任何Agent系統(tǒng)中，工具都是關(guān)鍵組成部分，它們使Claude能夠通過API中定義的確切結(jié)構(gòu)與外部服務交互。當Claude決定調(diào)用工具時，會在API響應中包含工具使用代碼塊。工具定義的提示工程與主提示同等重要。

(2)「工具形式」設(shè)計指南

對于同一個目的，有不同的實現(xiàn)方式，考慮選擇何種方式的決定因素是：

• LLM實現(xiàn)的準確性、難易度
• LLM是否擅長這種方式，格式是否為LLM友好的

(3) 多種實現(xiàn)方式對比

同一操作通常有多種實現(xiàn)方式，例如：

雖然這些差異在技術(shù)上可以無損轉(zhuǎn)換，但對LLM而言難度差異顯著：

• 編寫diff需要預先計算變更行數(shù)
• JSON中的代碼需要處理“引號”和“換行符轉(zhuǎn)義”

(4) 格式選擇三原則

• 思考空間充足：為模型在輸出前思考提供足夠token（即，壓縮工具的token消耗）
• 貼近自然語料：選擇接近互聯(lián)網(wǎng)文本中常見的格式（Markdown、Txt）
• 最小化格式負擔：避免需要精確計數(shù)或復雜轉(zhuǎn)義的格式（例如，需要準確統(tǒng)計數(shù)千行代碼的數(shù)量、json中的換行符轉(zhuǎn)義字符）

4. Agent-計算機接口優(yōu)化

正如人機接口(HCI)設(shè)計重要，Agent計算機接口（ACI）需同樣重視：

(1) 設(shè)計策略

• 模型視角思考：從模型角度評估工具使用的直觀性。對于人來說，根據(jù)工具描述和參數(shù)，使用這個工具是否很容易、清晰，還是需要仔細思考？如果是這樣，那么模型可能也是如此。
• 完整文檔設(shè)計：好的工具定義通常包括使用示例、邊界情況、輸入格式要求以及與其他工具的清晰界限
• 命名優(yōu)化：像為初級開發(fā)者寫文檔一樣精心設(shè)計參數(shù)名稱
• 實證測試迭代：通過多樣化輸入觀察模型使用模式
• 防錯設(shè)計實施：重構(gòu)參數(shù)結(jié)構(gòu)減少錯誤可能性

(2) 實戰(zhàn)案例

在SWE-bench Agent開發(fā)中，工具優(yōu)化占用了大量精力：

• 問題：當智能體離開根目錄后，相對路徑引用導致錯誤
• 解決方案：強制要求使用絕對路徑
• 效果：模型能夠完美執(zhí)行文件操作

在為SWE-bench構(gòu)建我們的Agent時，Anthropic實際上花了更多的時間優(yōu)化我們的工具，而不是整體提示詞。

5. 實踐建議

設(shè)計原則：

• 將工具文檔視為API設(shè)計的關(guān)鍵環(huán)節(jié)
• 精簡必要參數(shù)，提供合理默認值
• 為復雜工具添加使用示例

使用場景界定：

• 定義與其他工具的區(qū)分方法：清晰界定工具的適用場景和不適用場景
• 使用模型能理解的語言和格式

持續(xù)優(yōu)化策略：

• 定期檢查工具使用日志，識別改進機會
• 平衡靈活性和防錯性，適應智能體能力水平

優(yōu)良的工具定義能顯著提升Agent的工具利用效率，減少錯誤調(diào)用，并提高整體系統(tǒng)性能。

技術(shù)的力量在于分享，希望這篇總結(jié)能成為他人開發(fā)之路上的指南針。如果您希望持續(xù)獲取工作流、Agent技術(shù)及大模型應用的最新動態(tài)和深度解析，歡迎關(guān)注我的公眾號硅基世界指北。智能體的未來已來，這不僅是去發(fā)現(xiàn)，更是去創(chuàng)造。期待與更多志同道合的朋友們共同探索AI的無限可能。