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