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