1. 為什么 Anthropic 這篇架構(gòu)筆記值得每個(gè)開發(fā)智能體的人重讀三遍先說(shuō)我自己的感受。這幾年智能體賽道有多熱不用我重復(fù)了團(tuán)隊(duì)里聊的是 agent開源社區(qū)里卷的是框架技術(shù)大會(huì)上走秀的是 demo?？僧?dāng)我真正動(dòng)手做一個(gè)智能體從 能跑通一個(gè)循環(huán) 到 能交付一個(gè)穩(wěn)定可靠的系統(tǒng)中間那條路遠(yuǎn)比我預(yù)想的長(zhǎng)。問(wèn)題不在模型能力而在架構(gòu)選擇。直到我讀到 Anthropic 關(guān)于構(gòu)建有效智能體的那篇工程筆記才把很多模糊的判斷理清了。它沒(méi)有講復(fù)雜的算法也沒(méi)有給花哨的架構(gòu)圖而是回答了三個(gè)最本質(zhì)的問(wèn)題智能體和工作流到底差在哪里、什么場(chǎng)景真正需要智能體、以及如何用最小成本設(shè)計(jì)出可靠的系統(tǒng)架構(gòu)。標(biāo)題里講清楚這三個(gè)字我覺(jué)得特別準(zhǔn)確。因?yàn)槭忻嫔现v agent 的資料大多數(shù)要么停在給你看個(gè)炫酷案例要么堆了一堆框架名詞。而 Anthropic 這篇筆記的價(jià)值在于它把智能體架構(gòu)從玄學(xué)拉回到了工程決策的層面——你要做的不是選一個(gè)最智能的方案而是選一個(gè)復(fù)雜度匹配你業(yè)務(wù)場(chǎng)景的方案。這篇文章適合誰(shuí)看如果你正準(zhǔn)備從零搭建一個(gè)智能體但不確定該用工作流還是 agent如果你已經(jīng)用框架搭了 demo卻在生產(chǎn)環(huán)境里頻繁翻車或者你只是想搞清楚agent 架構(gòu)到底是怎么回事——那這篇筆記都值得你靜下心讀完。我會(huì)結(jié)合自己的落地經(jīng)驗(yàn)把筆記里的核心邏輯拆開講透順便補(bǔ)充一些原文沒(méi)寫但實(shí)際工程中一定會(huì)遇到的細(xì)節(jié)。提示Anthropic 這篇文章的核心觀點(diǎn)可以濃縮成一句話——**能不用智能體就不用智能體能用簡(jiǎn)單工作流解決的絕不為了炫技而上 agent。**這句話我一開始不以為然踩了大半年坑之后才心服口服。2. 工作流和智能體先分清這兩個(gè)概念架構(gòu)才不會(huì)走偏2.1 Anthropic 的定義其實(shí)很反直覺(jué)很多人一聽(tīng)智能體就覺(jué)得是讓模型自己規(guī)劃、自己決策、自己執(zhí)行一聽(tīng)工作流就覺(jué)得是比較低級(jí)的東西。但 Anthropic 在筆記里的定義跟直覺(jué)恰恰相反工作流Workflow通過(guò)預(yù)設(shè)的代碼路徑來(lái)編排大語(yǔ)言模型LLM和各類工具。每一步做什么、什么時(shí)候做、結(jié)果給誰(shuí)這些都是開發(fā)者在代碼里寫死的。LLM 只負(fù)責(zé)完成單個(gè)步驟里的生成任務(wù)不負(fù)責(zé)決定流程走向。智能體Agent由大語(yǔ)言模型動(dòng)態(tài)決定自己的流程、使用哪些工具、按什么順序執(zhí)行并且會(huì)基于環(huán)境的反饋不斷調(diào)整行動(dòng)直到任務(wù)完成。流程的控制權(quán)在模型手里而不在開發(fā)者手里。我一開始覺(jué)得這個(gè)區(qū)分太簡(jiǎn)單了。但后來(lái)發(fā)現(xiàn)正是這個(gè)簡(jiǎn)單區(qū)分決定了你在工程上所有后續(xù)決策要不要設(shè)計(jì)狀態(tài)機(jī)、要不要做人工審批節(jié)點(diǎn)、怎么處理失敗重試、怎么控制 token 成本、怎么做可觀測(cè)性。工作流和智能體的架構(gòu)成本完全不是一個(gè)量級(jí)。2.2 用流水線和實(shí)習(xí)生來(lái)類比如果你覺(jué)得上面的定義還是抽象我用一個(gè)生活化的類比。工作流就像工廠里的流水線每個(gè)工位做固定的事物料從 A 傳到 B 再傳到 C順序永遠(yuǎn)不會(huì)亂。你給流水線加一個(gè)智能環(huán)節(jié)比如某個(gè)工位用 LLM 來(lái)寫一段文案、做一次翻譯那它的本質(zhì)還是一個(gè)可預(yù)測(cè)的、確定性的流程。它的優(yōu)點(diǎn)是可測(cè)試、可控制、成本可預(yù)估缺點(diǎn)是遇到流程里沒(méi)定義過(guò)的情況它不會(huì)自己繞路。智能體則像一個(gè)能力很強(qiáng)但需要你來(lái)帶的實(shí)習(xí)生你給他一個(gè)目標(biāo)他會(huì)自己琢磨怎么拆解任務(wù)遇到問(wèn)題會(huì)翻工具書、會(huì)去查資料、會(huì)嘗試不同的方法甚至?xí)谥型靖淖儾呗?。他的?yōu)點(diǎn)是有很強(qiáng)的自主性能處理沒(méi)遇到過(guò)的情況缺點(diǎn)是你不能完全預(yù)期他會(huì)走哪條路需要花更多精力帶他——這就是架構(gòu)上的成本。所以關(guān)鍵點(diǎn)來(lái)了你不是在所有場(chǎng)景都想要一個(gè)自主的實(shí)習(xí)生很多場(chǎng)景你只想要一條穩(wěn)定可靠的流水線。Anthropic 的整篇筆記本質(zhì)上就是在幫你做這個(gè)判斷。2.3 為什么能選工作流就不要選智能體是一條黃金法則這個(gè)觀點(diǎn)說(shuō)出來(lái)可能會(huì)被一堆 agent 狂熱者吐槽但它是工程經(jīng)驗(yàn)的真實(shí)總結(jié)。第一工作流的失敗模式可以預(yù)測(cè)。流水線上任何一環(huán)出了問(wèn)題你只需要排查那一個(gè)環(huán)節(jié)。而智能體一旦在某個(gè)中間步驟產(chǎn)生幻覺(jué)、誤調(diào)用工具、或者陷入循環(huán)排查的難度是指數(shù)級(jí)上升的——你面對(duì)的不再是一個(gè)線性流程而是一棵可能不斷分叉的決策樹。第二工作流的成本更容易控制。每一步調(diào)用多少次模型、用多大的模型、總共消耗多少 token基本是可以估算出來(lái)的。而智能體的 token 消耗取決于它自己決定思考多少輪、調(diào)用多少次工具預(yù)算很容易失控。我見(jiàn)過(guò)一個(gè)智能客服 agent理想情況下 2 輪對(duì)話能解決問(wèn)題模型偶爾抽風(fēng)時(shí)會(huì)來(lái)回檢索十幾次月底賬單直接翻了三倍。第三工作流對(duì)延遲更友好。并行化、緩存、裁剪 prompt 這些優(yōu)化手段在確定性的流程里都好做。智能體的循環(huán)是動(dòng)態(tài)的你很難把思考次數(shù)壓縮因?yàn)槟鞘悄Ｐ妥约簺Q定的。所以當(dāng)你在設(shè)計(jì)一個(gè)系統(tǒng)時(shí)你要問(wèn)自己的第一個(gè)問(wèn)題不是要不要用 agent而是我的任務(wù)路徑是不是基本固定的。如果答案是肯定的老老實(shí)實(shí)選工作流只有當(dāng)你明確遇到了需要根據(jù)不確定信息動(dòng)態(tài)做決策的任務(wù)才有必要考慮 agent。后面我會(huì)詳細(xì)拆解什么情況算真正需要 agent。3. 五種工作流模式Anthropic 給的最實(shí)用工具箱3.1 這五種模式不是讓你挑一個(gè)而是讓你組合Anthropic 筆記里花了大量篇幅講的是五種常見(jiàn)工作流模式Prompt Chaining提示詞鏈、Routing路由、Parallelization并行化、Orchestrator-Workers編排者-執(zhí)行者、Evaluator-Optimizer評(píng)估者-優(yōu)化者。我一開始以為這是五種并列的方案后來(lái)才領(lǐng)悟它們是五種架構(gòu)元素可以在同一個(gè)系統(tǒng)里疊加組合。這跟蓋房子很像。你不會(huì)只用一個(gè)結(jié)構(gòu)元素你會(huì)同時(shí)用梁、柱、樓板。同樣在真實(shí)的 Agent 系統(tǒng)里入口可能是 Routing中間可能包含 Parallelization最后輸出前可能套一個(gè) Evaluator-Optimizer 做質(zhì)量把關(guān)。理解每個(gè)模式的本質(zhì)你才有能力組合出適合自己的方案。我先用一個(gè)表把五種模式的要點(diǎn)列出來(lái)再逐個(gè)展開講適用場(chǎng)景和實(shí)現(xiàn)細(xì)節(jié)模式核心思路一句話適用場(chǎng)景關(guān)鍵注意點(diǎn)Prompt Chaining大任務(wù)拆成 sequential 小任務(wù)前一步輸出喂給后一步任務(wù)可以自然分階段每階段用一個(gè)精簡(jiǎn) prompt每步獨(dú)立提高準(zhǔn)確率可單步重試Routing先分類再分發(fā)給專門的 prompt 或流程輸入類型差異大不同類別需要不同處理分類本身可以用小模型省成本Parallelization多個(gè) LLM 同時(shí)干活或分塊處理、或多方案投票任務(wù)可并行、或需要多角度交叉驗(yàn)證收益來(lái)自延遲降低和相互糾正Orchestrator-Workers一個(gè)中心模型拆任務(wù)多個(gè) worker 模型執(zhí)行復(fù)雜任務(wù)需要?jiǎng)討B(tài)拆分成子任務(wù)不要讓中心模型決定它不理解的領(lǐng)域Evaluator-Optimizer生成器和評(píng)估器循環(huán)直到質(zhì)量達(dá)標(biāo)有明確質(zhì)量反饋標(biāo)準(zhǔn)、能迭代改寫的任務(wù)評(píng)估標(biāo)準(zhǔn)必須具體否則白費(fèi) token3.2 Prompt Chaining把一步登天改成步步為營(yíng)Prompt Chaining 是我自己用得最多、也最適合大多數(shù)團(tuán)隊(duì)起步的模式。它把一個(gè)復(fù)雜的提示詞任務(wù)拆成多個(gè)順序執(zhí)行的子任務(wù)前一個(gè) LLM 調(diào)用的輸出成為后一個(gè)調(diào)用的輸入。舉個(gè)內(nèi)容生成的例子。假設(shè)你要做一個(gè)產(chǎn)品介紹生成器一次性 prompt 讓模型寫一篇高質(zhì)量的產(chǎn)品介紹結(jié)果往往平庸結(jié)構(gòu)流于模板、賣點(diǎn)不突出、結(jié)尾沒(méi)有號(hào)召力模型還容易在一段長(zhǎng)輸出里犯邏輯錯(cuò)誤。但如果你拆成三步步驟一讓 LLM 提煉產(chǎn)品的核心賣點(diǎn)、目標(biāo)人群、用戶痛點(diǎn)步驟二讓 LLM 基于這些素材寫出正文初稿prompt 只聚焦結(jié)構(gòu)清晰、信息準(zhǔn)確步驟三讓 LLM 擔(dān)任資深文案編輯審核初稿并改寫開頭和結(jié)尾。每一步的任務(wù)邊界都很窄模型不需要既要又要輸出質(zhì)量會(huì)明顯上升。為什么這樣有效因?yàn)槊恳徊降?prompt 只有單一職責(zé)模型的注意力能集中。而且工程上還有一個(gè)隱性好處你可以針對(duì)某一步單獨(dú)優(yōu)化和重試。如果第三步的編輯效果不好你可以只換第三步的 prompt不用動(dòng)整個(gè)鏈路。這在調(diào)試階段的體驗(yàn)非常好。我在做客戶報(bào)告自動(dòng)生成系統(tǒng)的時(shí)候就用了四段鏈數(shù)據(jù)整理 → 分析解讀 → 報(bào)告撰寫 → 格式潤(rùn)色。每一步一個(gè) prompt 調(diào)用整體準(zhǔn)確率提升非常明顯尤其是第二步分析解讀單獨(dú)調(diào)整后整條鏈的輸出質(zhì)量馬上改觀。這比讓一個(gè)大 prompt 從頭干到尾可維護(hù)性強(qiáng)太多了。3.3 Routing讓最該干活的模型干它最擅長(zhǎng)的活Routing 是我特別推崇的一種省錢模式。它的核心思路是先用一個(gè)分類器判斷用戶的輸入屬于哪一類再把它分發(fā)給對(duì)應(yīng)的專用流程。這個(gè)分類器不一定非要用很強(qiáng)的模型。Anthropic 筆記里特別提到簡(jiǎn)單分類任務(wù)用更小、更便宜的模型就足夠。舉例來(lái)說(shuō)一個(gè)客戶支持系統(tǒng)的入口可以先用小模型判斷用戶的問(wèn)題是賬單相關(guān)、技術(shù)故障還是退換貨然后分別轉(zhuǎn)給三個(gè)不同的專業(yè)工作流去處理。我實(shí)測(cè)過(guò)這個(gè)小模型方案的效果。用一個(gè)大模型做分類和用一個(gè)小模型做分類準(zhǔn)確率差距在幾個(gè)點(diǎn)以內(nèi)但成本可能差 5 到 10 倍。而且分類任務(wù)本身就是低上下文復(fù)雜度的任務(wù)小模型完全足夠。Routing 也可以用在模型選擇上。一類輸入走 Claude 這類強(qiáng)模型一類走輕量模型一類甚至不需要 LLM 而直接用預(yù)設(shè)規(guī)則回答。模型不是越強(qiáng)越好而是在每個(gè)環(huán)節(jié)里夠用且最優(yōu)。這句話我是在被賬單教育過(guò)之后才記住的。3.4 Parallelization兩條路走通并行化Anthropic 筆記里把并行化分成了兩種形態(tài)這個(gè)分類我覺(jué)得非常實(shí)用。第一種是Sectioning分塊并行把一個(gè)大任務(wù)切成幾個(gè)獨(dú)立的小塊同時(shí)處理最后聚合成一個(gè)結(jié)果。比如做內(nèi)容分析時(shí)把一本書拆成多個(gè)章節(jié)每個(gè)章節(jié)用獨(dú)立的 LLM 調(diào)用生成摘要再讓另一個(gè) LLM 把所有摘要聚合成全書總結(jié)。這樣做的好處有兩個(gè)一是快多路并行讓總延遲大幅下降二是繞開了上下文窗口限制不需要把整本書塞進(jìn)一個(gè)上下文。第二種是Voting投票并行同一個(gè)任務(wù)讓多個(gè)獨(dú)立的 LLM 調(diào)用分別給出回答然后選一個(gè)最佳答案或達(dá)成多數(shù)共識(shí)。這類似于讓多個(gè)專家獨(dú)立評(píng)審。我自己用的一個(gè)經(jīng)驗(yàn)是在代碼審查場(chǎng)景下用三個(gè)不同 temperature 設(shè)置的模型分別檢查再讓一個(gè)模型綜合它們的意見(jiàn)能明顯提高 bug 檢出率。代價(jià)是多了三倍 token 和接近三倍的延遲它更適合質(zhì)量?jī)?yōu)先、延遲不敏感的場(chǎng)景。我建議如果你還沒(méi)有并行化經(jīng)驗(yàn)先從 Sectioning 開始。它在工程實(shí)現(xiàn)上非常直觀拆任務(wù)、并發(fā)調(diào)用、聚合成最終結(jié)果。Voting 則更適合你已經(jīng)有了穩(wěn)定的評(píng)估標(biāo)準(zhǔn)想讓結(jié)果更魯棒的場(chǎng)景。3.5 Orchestrator-Workers中心化拆解但不做萬(wàn)能裁判Orchestrator-Workers 是接近智能體感覺(jué)的工作流模式一個(gè)中央的 Orchestrator編排者模型負(fù)責(zé)分析任務(wù)、拆解子任務(wù)、分發(fā)給多個(gè) Worker執(zhí)行者模型Worker 回來(lái)后再由 Orchestrator 匯總結(jié)果。它和 Parallelization 的區(qū)別在于Parallelization 是提前確定好拆什么、怎么并的Orchestrator 則是由模型動(dòng)態(tài)決定要不要拆、拆成什么。所以它的靈活性和復(fù)雜度都比前面的模式高。使用 Orchestrator-Workers 最容易犯的錯(cuò)我在團(tuán)隊(duì)里見(jiàn)過(guò)不少次——讓 Orchestrator 承擔(dān)了它不理解的判斷。比如中心模型是通用的對(duì)話模型你卻讓它去評(píng)估醫(yī)藥領(lǐng)域的子任務(wù)結(jié)果那它根本判斷不了 Worker 干得好不好。我的做法是給 Orchestrator 提供明確的任務(wù)描述模板和子任務(wù)驗(yàn)收標(biāo)準(zhǔn)讓它專注于任務(wù)管理而不是去充當(dāng)領(lǐng)域?qū)＜?。另外還有一個(gè)工程細(xì)節(jié)Orchestrator 同時(shí)發(fā)起的 Worker 數(shù)量不宜太多。一方面并發(fā)調(diào)用會(huì)受 API 限流影響另一方面子任務(wù)過(guò)多時(shí)Orchestrator 匯總信息的質(zhì)量會(huì)下降。我一般控制在 5 到 10 個(gè)以內(nèi)再多就考慮分層分組。3.6 Evaluator-Optimizer把寫得好不好變成一個(gè)可循環(huán)的題目Evaluator-Optimizer 是我認(rèn)為最容易被忽略、但收益極明顯的一種模式。它的結(jié)構(gòu)是一個(gè) LLM 負(fù)責(zé)生成答案另一個(gè) LLM 負(fù)責(zé)評(píng)估這個(gè)答案的質(zhì)量如果評(píng)估不過(guò)關(guān)就把反饋傳給生成器進(jìn)行新一輪改寫直到通過(guò)或達(dá)到迭代上限。它的適用場(chǎng)景有兩個(gè)特征一是任務(wù)有明確的好壞標(biāo)準(zhǔn)二是結(jié)果可以反復(fù)迭代修改。比如翻譯、學(xué)術(shù)寫作、營(yíng)銷文案、代碼優(yōu)化這些任務(wù)天然適合這種生成—評(píng)估—再生成的循環(huán)。但這里有個(gè)大坑評(píng)估器的 prompt 如果不夠具體整個(gè)循環(huán)就是在空轉(zhuǎn)燒錢。你讓它評(píng)估這段文案好不好它可能永遠(yuǎn)覺(jué)得不錯(cuò)還可以更好然后無(wú)限迭代。我自己寫評(píng)估 prompt 時(shí)的經(jīng)驗(yàn)是把評(píng)估維度切成可打分的項(xiàng)比如事實(shí)準(zhǔn)確性信息是否有據(jù)可依結(jié)構(gòu)完整性是否包含背景、進(jìn)展、風(fēng)險(xiǎn)、建議四大部分表達(dá)精煉度是否有冗余表達(dá)目標(biāo)適配度是否針對(duì)目標(biāo)讀者做了措辭調(diào)整。每個(gè)維度給出明確說(shuō)明和評(píng)分標(biāo)準(zhǔn)后評(píng)估器才能給出真正有用的反饋而不是模糊的還可以。同時(shí)要設(shè)置最大迭代次數(shù)一般 3 輪就夠再多性價(jià)比就非常低了。提示Evaluator-Optimizer 在 Anthropic 原文里是一個(gè)典型工作流但我在實(shí)踐中發(fā)現(xiàn)它可以作為質(zhì)檢模塊嵌入到其他工作流里比如在 Prompt Chaining 的最后一步加一個(gè)評(píng)估環(huán)節(jié)質(zhì)量立刻有改觀。它不一定非得獨(dú)立存在。4. Agent 模式什么時(shí)候真正上線當(dāng)靈活性需求壓過(guò)穩(wěn)定性需求4.1 判斷的核心標(biāo)準(zhǔn)路徑可控性看完了五種工作流你可能會(huì)問(wèn)那到底什么時(shí)候才需要上真正的 AgentAnthropic 筆記里的判斷標(biāo)準(zhǔn)我用一句話總結(jié)當(dāng)你在設(shè)計(jì)系統(tǒng)時(shí)無(wú)法提前窮舉出所有執(zhí)行路徑并且系統(tǒng)需要在執(zhí)行過(guò)程中根據(jù)環(huán)境反饋實(shí)時(shí)調(diào)整行動(dòng)路徑時(shí)你才真正需要 Agent。什么是無(wú)法提前窮舉路徑我用實(shí)際例子說(shuō)明。一個(gè)文檔摘要系統(tǒng)輸入是文檔輸出是摘要。它可能有長(zhǎng)有短但處理路徑基本固定——不需要 Agent。一個(gè)小紅書文案生成器輸入產(chǎn)品信息輸出種草文案。路徑也固定——不需要 Agent。一個(gè)自動(dòng)管理任務(wù)的個(gè)人助理你告訴它幫我安排明天的會(huì)議順便整理會(huì)議資料發(fā)給參會(huì)人還要查一下明天交通狀況。它能自己規(guī)劃步驟、調(diào)用日歷工具、調(diào)用搜索工具、遇到?jīng)_突自己調(diào)整——這才需要 Agent。第一個(gè)和第二個(gè)任務(wù)路徑是可預(yù)知的你窮舉也就是那么幾種情況。第三個(gè)任務(wù)則完全不一樣用戶指令千變?nèi)f化外部環(huán)境日歷沖突、搜索結(jié)果的更新也在變化系統(tǒng)的路徑必須動(dòng)態(tài)生成。4.2 Agent 的核心模型驅(qū)動(dòng)的感知—決策—執(zhí)行—觀察循環(huán)Agent 不是一個(gè)更聰明的模型而是一種運(yùn)行時(shí)架構(gòu)。這個(gè)架構(gòu)的核心是一個(gè)循環(huán)感知把當(dāng)前任務(wù)、環(huán)境信息、可用的工具列表一起打包給 LLM決策LLM 決定下一步采取什么行動(dòng)調(diào)用哪幾個(gè)工具、或用哪個(gè)工具的參數(shù)執(zhí)行系統(tǒng)執(zhí)行這個(gè)工具調(diào)用拿到真實(shí)的結(jié)果觀察把工具結(jié)果以文本形式回傳給 LLM更新它的上下文回到第 2 步直到模型判定任務(wù)完成或觸發(fā)終止條件。Anthropic 筆記里把 Agent 描述為處理開放式問(wèn)題的擴(kuò)展系統(tǒng)——它的流程不是預(yù)先畫好的而是在運(yùn)行時(shí)被模型自己畫出來(lái)的。工程上這要求你的架構(gòu)具備幾個(gè)基礎(chǔ)能力工具調(diào)用Function Calling模型能輸出結(jié)構(gòu)化的工具調(diào)用指令而不是光說(shuō)我建議你去做某事工具解析與執(zhí)行層系統(tǒng)能把模型的輸出解析成真實(shí)的 API 調(diào)用并處理好參數(shù)校驗(yàn)和錯(cuò)誤返回循環(huán)控制器管理調(diào)用模型 → 執(zhí)行工具 → 結(jié)果回填 → 再調(diào)用模型的循環(huán)并設(shè)置最大迭代次數(shù)等終止條件。這也是為什么熱詞里會(huì)出現(xiàn)識(shí)的llm智能體自主容錯(cuò)控制:構(gòu)建可靠ai系統(tǒng)的工程實(shí)踐——Agent 的可靠很大程度上不是一個(gè)聰明模型能保證的而是由循環(huán)控制、錯(cuò)誤恢復(fù)、工具健壯性這些系統(tǒng)工程決定的。4.3 工具層的設(shè)計(jì)決定了 Agent 的天花板我見(jiàn)過(guò)不少團(tuán)隊(duì) Agent 效果差第一反應(yīng)是換個(gè)更強(qiáng)的模型其實(shí)問(wèn)題往往出在工具設(shè)計(jì)上。Anthropic 筆記也強(qiáng)調(diào)了工具是 Agent 連接世界的觸角。工具設(shè)計(jì)有四個(gè)我總結(jié)出來(lái)的關(guān)鍵點(diǎn)第一工具的描述要極其清晰。模型是通過(guò)你的工具 description 來(lái)決定什么時(shí)候調(diào)用、參數(shù)傳什么的。你寫獲取天氣信息模型會(huì)不知道能查城市列表你寫根據(jù)城市名獲取未來(lái) 7 天天氣預(yù)報(bào)參數(shù) city 為中文城市名如北京模型就非常明確。第二工具的輸入要做嚴(yán)格校驗(yàn)。千萬(wàn)不要把模型輸出的參數(shù)直接透?jìng)鹘o后端接口。模型可能輸出一個(gè)不存在的城市名也可能把溫度字段傳給了城市字段。在前端做一層校驗(yàn)和標(biāo)準(zhǔn)化能省掉大量臟數(shù)據(jù)問(wèn)題。第三工具的執(zhí)行要冪等或可重試。Agent 在循環(huán)中可能因?yàn)槌瑫r(shí)而重試同一個(gè)工具調(diào)用如果你的工具不是冪等的比如創(chuàng)建訂單接口就會(huì)造成重復(fù)操作。我在實(shí)際項(xiàng)目里對(duì)這類工具都會(huì)要求后端在參數(shù)里加一個(gè)冪等鍵idempotency key保證同一次任務(wù)的重試不會(huì)產(chǎn)生副作用。第四關(guān)鍵操作要設(shè)置權(quán)限護(hù)欄。完全信任模型自主執(zhí)行高影響操作是在給自己埋雷。我的做法是在工具層做人工確認(rèn)鉤子標(biāo)記工具是否需要人工審批如果涉及發(fā)送郵件、付款、刪除數(shù)據(jù)等操作系統(tǒng)會(huì)先暫停循環(huán)把待確認(rèn)信息發(fā)給管理員。這個(gè)人在環(huán)路的設(shè)計(jì)在 Anthropic 筆記里也被多次強(qiáng)調(diào)它是 Agent 系統(tǒng)里最重要的安全網(wǎng)沒(méi)有之一。4.4 自主容錯(cuò)控制Agent 不是永不失敗而是失敗后可恢復(fù)這里延伸一下熱詞里提到的自主容錯(cuò)控制問(wèn)題。我在做生產(chǎn)級(jí) Agent 時(shí)發(fā)現(xiàn)容錯(cuò)不是讓模型更準(zhǔn)而是在系統(tǒng)層面建立失敗恢復(fù)機(jī)制。工具調(diào)用失敗模型請(qǐng)求的 API 超時(shí)或返回錯(cuò)誤系統(tǒng)應(yīng)該把錯(cuò)誤信息作為 observation 回傳給模型讓模型自己決定是重試還是換一個(gè)替代方案。而不是簡(jiǎn)單地讓整個(gè)循環(huán)崩潰。模型輸出格式非法模型偶爾會(huì)返回不合 JSON 規(guī)范的輸出解析失敗不等于任務(wù)失敗。我的做法是給循環(huán)控制器加兩次重試機(jī)會(huì)把我無(wú)法解析你的輸出請(qǐng)按指定格式重新生成作為反饋再次請(qǐng)求模型通常第二次就能修正。死循環(huán)保護(hù)無(wú)論模型多么自主都要設(shè)置最大循環(huán)次數(shù)比如 20 輪和最長(zhǎng)執(zhí)行時(shí)間。到達(dá)上限強(qiáng)制終止而不是讓它無(wú)限燒 token。這個(gè)簡(jiǎn)單規(guī)則能幫你避免很多噩夢(mèng)。有一句話我在團(tuán)隊(duì)里反復(fù)講Agent 生產(chǎn)化的過(guò)程就是不斷把模型可能搞砸的地方用系統(tǒng)機(jī)制兜住的過(guò)程。如果你只是把一個(gè)模型裸奔在循環(huán)里它遲早會(huì)在意想不到的地方翻車而且翻車姿勢(shì)五花八門。5. 成本、延遲與偽 Agent架構(gòu)選擇的現(xiàn)實(shí)約束5.1 每一個(gè)決策點(diǎn)都是真金白銀Agent 比工作流智能但每一個(gè)智能都有價(jià)格。不是錢的問(wèn)題是 token 消耗和延遲的問(wèn)題。Anthropic 筆記里沒(méi)有回避這一點(diǎn)。每個(gè) Agent 決策循環(huán)都意味著一次完整的 LLM 調(diào)用而每次調(diào)用都要消耗上下文 token——包括系統(tǒng) prompt、工具描述、歷史消息、工具返回結(jié)果這些都會(huì)累積。一個(gè)看似最終只調(diào)用 3 次工具的 Agent實(shí)際可能因?yàn)樯舷挛脑絹?lái)越長(zhǎng)消耗了相當(dāng)于 10 次基礎(chǔ)的 token 量。我給你一個(gè)大概的體感估算一次簡(jiǎn)單的工具調(diào)用類 Agent 任務(wù)token 消耗可能是同等功能工作流的 5 到 20 倍。20 倍是什么概念如果你的業(yè)務(wù)每天有 10 萬(wàn)次請(qǐng)求成本差異就會(huì)讓人非常肉疼。延遲也一樣。工作流可以做并行、可以做緩存Agent 必須串行決策——思考、調(diào)工具、看結(jié)果、再思考。一個(gè) 3 步工具調(diào)用就是 4 次模型往返延遲通常在幾秒到幾十秒之間跟你平時(shí)用工作流做單次問(wèn)答的體感完全不同。所以架構(gòu)設(shè)計(jì)的本質(zhì)其實(shí)是一個(gè)成本預(yù)算題。你要問(wèn)自己這個(gè)任務(wù)的決策點(diǎn)上我付出的額外 token 和延遲換來(lái)的自適應(yīng)能力是否值得大多數(shù)情況是不值得的。5.2 很多Agent其實(shí)是披著 Agent 外衣的工作流我觀察到一個(gè)很有意思的現(xiàn)象市面上很多標(biāo)榜智能體的產(chǎn)品拆開看都是固定流程加幾個(gè) LLM 調(diào)用節(jié)點(diǎn)。它們叫 Agent但架構(gòu)上就是 Prompt Chaining 或者 Routing。這本身不是壞事甚至可能是正確選擇。我說(shuō)的偽 Agent不含貶義反而是一個(gè)務(wù)實(shí)判斷如果一個(gè)系統(tǒng)能用工作流可靠地實(shí)現(xiàn)你要的效果那它就是很好的系統(tǒng)你不需要去追求真正的 Agent這個(gè)標(biāo)簽。判斷一個(gè)系統(tǒng)是真 Agent還是偽工作流可以參考三個(gè)指標(biāo)決策點(diǎn)數(shù)量系統(tǒng)里有幾個(gè)地方允許模型自主選擇下一步動(dòng)作如果只有一個(gè)結(jié)果分支判斷if 條件那是工作流如果每個(gè)循環(huán)里模型都能選擇 5 個(gè)以上工具之一并自行決定順序那是 Agent。任務(wù)多樣性系統(tǒng)處理的輸入變化是否足夠大固定模板化的輸入不需要 Agent開放式指令才需要 Agent。失敗重試的自由度出錯(cuò)時(shí)系統(tǒng)只能走預(yù)設(shè)的失敗分支還是能動(dòng)態(tài)換一條策略前者是工作流后者才接近 Agent。我自己做系統(tǒng)設(shè)計(jì)時(shí)會(huì)把用工作流實(shí)現(xiàn) 80% 場(chǎng)景 少數(shù)復(fù)雜分支交給 Agent作為一個(gè)默認(rèn)思路。先把主干跑穩(wěn)再在真正需要靈活性的節(jié)點(diǎn)引入 Agent這是成本最可控的路徑。5.3 Agent 也不是單體控制面與執(zhí)行面的分離熱詞里出現(xiàn)了分布式架構(gòu)和微服務(wù)架構(gòu)這兩個(gè)詞背后其實(shí)也關(guān)系到 Agent 系統(tǒng)怎么落地。Agent 在架構(gòu)上不是一個(gè)大模型包辦一切的單體。把一個(gè) Agent 系統(tǒng)放到微服務(wù)的語(yǔ)境里看它天然分成了兩大部分控制面Controller負(fù)責(zé)決策的循環(huán)控制器管理狀態(tài)、工具調(diào)度、終止條件執(zhí)行面Executors被控制的工具服務(wù)可能是文檔檢索服務(wù)、數(shù)據(jù)庫(kù)服務(wù)、外部 API 網(wǎng)關(guān)、內(nèi)部業(yè)務(wù)系統(tǒng)。我推薦這個(gè)架構(gòu)思路的原因很簡(jiǎn)單如果你把 Agent 的所有邏輯都塞在同一個(gè)服務(wù)里后續(xù)擴(kuò)展和排查會(huì)非常痛苦?？刂泼婧蛨?zhí)行面分離后你可以單獨(dú)擴(kuò)縮容工具服務(wù)、單獨(dú)做緩存、單獨(dú)監(jiān)控每個(gè)工具的延遲和錯(cuò)誤率這些都是生產(chǎn)環(huán)境必須的。在具體實(shí)現(xiàn)里控制面可以直接調(diào)用后端微服務(wù)的內(nèi)部接口。工具既可以是 HTTP 接口也可以是 RPC 調(diào)用。關(guān)鍵是每個(gè)被暴露給模型的工具都要有清晰的契約——名字、描述、參數(shù) schema、返回結(jié)構(gòu)這相當(dāng)于給模型做了一套API 目錄讓它能正確選擇。另外關(guān)于平臺(tái)搭建的智能體與用 Python 搭建的智能體有什么不同這個(gè)問(wèn)題——本質(zhì)上也落在架構(gòu)層面。平臺(tái)通常把控制面的實(shí)現(xiàn)封裝成了可視化編排你又快又省力但定制邊界受平臺(tái)約束用 Python 從零搭控制邏輯完全在自己手里改造成本高但靈活度大。我的建議是demo 和驗(yàn)證階段用平臺(tái)快速試錯(cuò)有明確規(guī)模預(yù)期后再遷到代碼自建你才能真正掌控成本、延遲和故障排查。6. 從 Demo 到生產(chǎn)我踩過(guò)的幾個(gè)坑和應(yīng)對(duì)辦法Anthropic 筆記講了原則和模式但有一條它沒(méi)有展開講任何 Agent 或者工作流架構(gòu)從 Demo 到生產(chǎn)之間的距離往往比從想法到 Demo 更遠(yuǎn)。最后我用自己實(shí)際踩過(guò)的坑作為收尾這些經(jīng)驗(yàn)都是原文里沒(méi)有的。6.1 可觀測(cè)性與調(diào)試沒(méi)有 trace等于斷案沒(méi)有證據(jù)Agent 系統(tǒng)不像傳統(tǒng)的后端接口返回個(gè) 4xx、5xx 就能定位問(wèn)題。它的問(wèn)題可能出在模型理解錯(cuò)了用戶意圖、工具選擇不當(dāng)、參數(shù)傳錯(cuò)、中間某一步的返回內(nèi)容誤導(dǎo)了模型、上下文太長(zhǎng)導(dǎo)致模型忘了最初目標(biāo)。要應(yīng)對(duì)這些你需要在第一天就把完整的 trace 體系搭起來(lái)。每一步 LLM 調(diào)用的輸入和輸出、每次工具調(diào)用的請(qǐng)求和響應(yīng)、每一步的 token 數(shù)、延遲、模型的推理過(guò)程如果有的話全部落盤。我通常會(huì)把這些結(jié)構(gòu)化地存儲(chǔ)下來(lái)在調(diào)試頁(yè)面上按 session 查看樹狀 trace。沒(méi)有這套體系A(chǔ)gent 出問(wèn)題你只能靠復(fù)現(xiàn)和猜效率極低。Agent 系統(tǒng)生產(chǎn)化的第一優(yōu)先級(jí)不是模型調(diào)優(yōu)而是做好可觀測(cè)性。無(wú)法觀測(cè)的系統(tǒng)就無(wú)法優(yōu)化也無(wú)法信任。6.2 評(píng)估不是肉眼看好壞而是 golden set 回歸傳統(tǒng)開發(fā)有單元測(cè)試LLM 應(yīng)用沒(méi)有這是很多人覺(jué)得 Agent 工程玄的核心原因。我的做法是建立一套回歸評(píng)估集golden set收集歷史上真實(shí)用戶輸入和期望輸出做成幾十上百條的固定測(cè)試集每次修改 prompt、工具或流程都跑一遍測(cè)試集用 LLM 作為 judge按固定評(píng)估標(biāo)準(zhǔn)給每個(gè)輸出打分對(duì)比工具箱前后的得分差異。這比人工看一眼效果不錯(cuò)可靠太多。我團(tuán)隊(duì)里現(xiàn)在改任何一個(gè) prompt都要先跑回歸測(cè)試再上線。哪怕判斷比較主觀一個(gè)相對(duì)穩(wěn)定的分?jǐn)?shù)趨勢(shì)也好過(guò)拍腦袋。6.3 讓模型做更少的決策而不是更多最后一條是認(rèn)知層面最大的轉(zhuǎn)變。在我早期設(shè)計(jì) Agent 時(shí)總希望模型更聰明一點(diǎn)多自主判斷一些事情。后來(lái)的教訓(xùn)是模型越少做決策系統(tǒng)越穩(wěn)定。具體實(shí)踐是把那些可以通過(guò)規(guī)則、代碼、狀態(tài)機(jī)實(shí)現(xiàn)的部分全部用代碼實(shí)現(xiàn)絕不交給模型。比如任務(wù)執(zhí)行完要不要進(jìn)入人工審核這個(gè)判斷你可以讓模型決定但更好的做法是定義好什么級(jí)別的影響需要人工審批用代碼判斷只有面對(duì)未定義情況時(shí)怎么處理這類真正需要語(yǔ)義理解的判斷才留給模型。Anthropic 筆記里有一句話給我的印象特別深不要為了增加智能而增加復(fù)雜度。一個(gè)好的系統(tǒng)應(yīng)該是智能恰到好處地出現(xiàn)在它該出現(xiàn)的地方其他地方則用確定性邏輯來(lái)兜底。這個(gè)理念我執(zhí)行得越徹底系統(tǒng)就越可靠Debug 也越輕松。落到我個(gè)人經(jīng)驗(yàn)上現(xiàn)在設(shè)計(jì)任何一個(gè)智能體系統(tǒng)我都會(huì)先畫一張表左邊列任務(wù)步驟右邊標(biāo)代碼邏輯還是模型決策。如果模型決策點(diǎn)超過(guò) 30%我會(huì)停下來(lái)重新審視——是不是可以通過(guò)更好的拆分、更明確的工作流把一部分決策轉(zhuǎn)移到確定性邏輯里。這不是反對(duì) Agent而是把 Agent 用在刀刃上。希望這篇文章能幫你把 Anthropic 的架構(gòu)筆記真正用到自己的項(xiàng)目里。如果讀完之后你只記住一件事就記住那句話先想清楚任務(wù)路徑是固定的還是開放的再?zèng)Q定用工作流還是智能體而無(wú)論選哪種把工程兜底做扎實(shí)永遠(yuǎn)比追求更智能更重要。