最近這幾年“智能體”這個(gè)詞幾乎被聊爛了但真正能把架構(gòu)思路講明白的文章其實(shí)不多。Anthropic 發(fā)過一篇《Building Effective Agents》我前前后后讀了不少遍每經(jīng)歷一個(gè)項(xiàng)目回頭再看感受都不一樣。這篇筆記不算長(zhǎng)但信息密度很高幾乎每一段都能對(duì)應(yīng)到實(shí)際開發(fā)中的痛點(diǎn)。如果你正準(zhǔn)備做智能體或者已經(jīng)在 LangGraph、Coze、Dify 這類平臺(tái)上折騰了一陣子我強(qiáng)烈建議你先把這套底層邏輯梳理清楚否則很容易陷入一種狀態(tài)工具用得很熟練但方案總差一口氣。這篇文章就是我從那篇架構(gòu)筆記出發(fā)結(jié)合自己折騰過的項(xiàng)目踩坑經(jīng)驗(yàn)把它拆開揉碎講清楚。我會(huì)從概念邊界、設(shè)計(jì)模式、工程落地的角度展開盡量用大白話但該嚴(yán)謹(jǐn)?shù)牡胤揭膊粫?huì)含糊。1. 先搞清楚一件事工作流和智能體根本不是一回事1.1 一個(gè)判斷標(biāo)準(zhǔn)誰在控制流程很多人把“調(diào)用了大模型接口”當(dāng)成智能體的標(biāo)志這其實(shí)是個(gè)認(rèn)知誤區(qū)。Anthropic 那篇筆記里有一個(gè)很關(guān)鍵的區(qū)分工作流Workflow和智能體Agent是兩種不同的東西。工作流的特征是“預(yù)定義代碼路徑”。也就是說系統(tǒng)要做什么、步驟怎么編排、每步之后怎么流轉(zhuǎn)全部由開發(fā)者提前在代碼里寫死。大模型只是流程中的一顆螺絲釘負(fù)責(zé)某個(gè)環(huán)節(jié)的生成、判斷或轉(zhuǎn)換。比如你寫一個(gè)腳本先讓模型做關(guān)鍵詞提取然后把提取結(jié)果拼成搜索 query再讓模型根據(jù)搜索結(jié)果寫摘要——這個(gè)流程從頭到尾都是你設(shè)計(jì)的模型沒有決策權(quán)。智能體的特征則是“模型動(dòng)態(tài)控制流程”。系統(tǒng)只給定目標(biāo)、可用工具和約束條件接下來該調(diào)用哪個(gè)工具、按什么順序調(diào)用、結(jié)果不滿意要不要重試、什么時(shí)候算完成這些都由模型在運(yùn)行中自行決策。它的行為不是靜態(tài)寫死的而是圍繞目標(biāo)動(dòng)態(tài)展開的。1.2 為什么這個(gè)區(qū)分如此重要這個(gè)區(qū)分不是學(xué)術(shù)概念摳字眼它直接決定你會(huì)不會(huì)過度設(shè)計(jì)。我知道很多團(tuán)隊(duì)看到“智能體”這個(gè)概念就興奮什么場(chǎng)景都想上 Agent。但 Anthropic 在筆記里擺了一個(gè)很現(xiàn)實(shí)的數(shù)據(jù)和論點(diǎn)工作流和智能體在大模型任務(wù)上都能帶來效果提升其中智能體的優(yōu)勢(shì)和潛力最大但它對(duì)應(yīng)的代價(jià)也最高——延遲更高、token 消耗更大、錯(cuò)誤模式更復(fù)雜、調(diào)試排查更難。如果簡(jiǎn)單的工作流已經(jīng)能解決強(qiáng)行上 Agent 只會(huì)給自己找麻煩。我見過最典型的一個(gè)失敗案例有個(gè)團(tuán)隊(duì)想做智能客服系統(tǒng)一上來就上了多智能體框架搞了三四個(gè)子 Agent 互相協(xié)調(diào)結(jié)果上線第一天光是 Agent 間的死循環(huán)就把 token 費(fèi)燒穿客服問題的解決率反而沒有原來那套簡(jiǎn)單的意圖識(shí)別 規(guī)則引擎高。后來我?guī)退麄兪崂碚嬲枰Ｐ妥灾鳑Q策的環(huán)節(jié)其實(shí)只占兩成其余完全可以用固定流程覆蓋。所以在你讀后面的架構(gòu)模式之前先建立這樣一個(gè)思維習(xí)慣先搞清楚你的系統(tǒng)哪個(gè)環(huán)節(jié)最需要“靈活性”然后只在那個(gè)環(huán)節(jié)引入智能體其他部分能寫死就寫死。1.3 落地場(chǎng)景直觀對(duì)比我常用一個(gè)例子來區(qū)分這兩類場(chǎng)景工單自動(dòng)分揀用戶提交一個(gè)工單系統(tǒng)判斷它屬于哪個(gè)類型再推到對(duì)應(yīng)部門。這屬于工作流因?yàn)榉謷念愋秃吐酚赡繕?biāo)是確定的模型只需要做一次分類。自動(dòng)化代碼修復(fù)給 Agent 一個(gè) Bug 報(bào)告它需要自己讀代碼、定位問題、改代碼、跑測(cè)試發(fā)現(xiàn)測(cè)試失敗還要接著修。這就是標(biāo)準(zhǔn)智能體場(chǎng)景因?yàn)橄乱徊皆趺醋鐾耆蕾嚿弦徊降姆答?。判斷的核心一句話如果?dòng)作空間是你預(yù)先枚舉好的、每一步的轉(zhuǎn)移關(guān)系是確定的那是工作流如果模型需要根據(jù)當(dāng)前狀態(tài)自行選擇動(dòng)作、甚至自行規(guī)劃動(dòng)作序列那是智能體。這兩個(gè)的工程復(fù)雜度完全不同預(yù)算和上線周期也完全不在一個(gè)量級(jí)。2. 三條黃金法則你的系統(tǒng)該用哪一層2.1 法則一最簡(jiǎn)單方案優(yōu)先Anthropic 那篇筆記里有一句話我印象特別深“智能體并不會(huì)隨隨便便就把一個(gè)問題解決得比大模型本身更好”。很多任務(wù)直接用大模型單次調(diào)用就能完成根本不需要額外的框架包裝。我第一次做智能體項(xiàng)目時(shí)就吃過這個(gè)虧。當(dāng)時(shí)想做一個(gè)“資料整理智能體”需求是讓用戶丟一篇文章進(jìn)來自動(dòng)輸出一份結(jié)構(gòu)化的筆記摘要。我第一反應(yīng)是給它配上網(wǎng)頁檢索工具、知識(shí)庫工具、甚至接了個(gè)播客轉(zhuǎn)寫工具結(jié)果搞了整整兩周效果還是不穩(wěn)定。后來我退回到最簡(jiǎn)單的方式直接把文章內(nèi)容丟給大模型讓它按模板輸出摘要效果反而干凈利落用戶的滿意度還更高。這條法則是很多資深從業(yè)者反復(fù)強(qiáng)調(diào)的能用一次 API 調(diào)用解決就不要上工作流能用工作流解決就不要上 Agent能用單個(gè) Agent 解決就不要上多 Agent。復(fù)雜度每上一層你要面對(duì)的不可控因素就多一個(gè)數(shù)量級(jí)。2.2 法則二延遲上智能體而不是搶先上這里有一個(gè)很樸素的道理智能體適合解決的是“問題空間大、最優(yōu)路徑不唯一”的場(chǎng)景。如果你的任務(wù)只有一兩種標(biāo)準(zhǔn)解法那模型直接輸出結(jié)果就行路徑的靈活性反而是負(fù)擔(dān)。舉個(gè)例子寫一篇營(yíng)銷文案它可能適合用工作流先提取產(chǎn)品賣點(diǎn)再根據(jù)目標(biāo)用戶調(diào)整語氣再生成最終文案。但你不需要一個(gè)能自由調(diào)工具、自己選策略的 Agent。反過來用自然語言操作一個(gè)復(fù)雜的視頻剪輯軟件這就是典型的 Agent 場(chǎng)景因?yàn)橛脩舻男枨罂赡苁恰鞍堰@里調(diào)得更有氛圍一點(diǎn)”具體怎么操作模型必須自己判斷。核心判斷標(biāo)準(zhǔn)很簡(jiǎn)單你有沒有把“怎么做”的規(guī)則寫清楚的能力如果能寫清楚就去寫工作流如果實(shí)在寫不清楚或者規(guī)則組合空間太大才輪到 Agent 出馬讓它通過試錯(cuò)和反饋?zhàn)约赫业铰窂健?.3 法則三為智能體保留人工兜底和可觀測(cè)性這一點(diǎn)筆記里沒有大篇幅展開但我從項(xiàng)目里得到的教訓(xùn)非常深刻。一旦決策權(quán)交給模型你的系統(tǒng)就不可避免地會(huì)出現(xiàn)“計(jì)劃外行為”。模型可能調(diào)用了一個(gè)你沒預(yù)料到的工具可能在某個(gè)分支上反復(fù)重試可能明明已經(jīng)拿到結(jié)果卻因?yàn)椤坝X得不完美”一直不終止。這些行為在生產(chǎn)環(huán)境里是致命的。所以當(dāng)你決定引入智能體時(shí)至少要同時(shí)做三件事設(shè)定最大迭代次數(shù)和超時(shí)時(shí)間超出就強(qiáng)制中止并走降級(jí)邏輯保留完整的行為日志包括每一步的思考過程、工具調(diào)用參數(shù)、返回結(jié)果在關(guān)鍵業(yè)務(wù)節(jié)點(diǎn)上留一個(gè)人工審核位尤其是涉及資金、合規(guī)、對(duì)外發(fā)布的場(chǎng)景。智能體適合處理的是“過程可以自主、結(jié)果需要可控”的任務(wù)。如果你的業(yè)務(wù)要求每個(gè)環(huán)節(jié)都完全確定那它就不適合用智能體。3. 五大工作流模式拆解從提示鏈到評(píng)估者-優(yōu)化者Anthropic 的筆記把常見的編排方式歸納成了五種工作流模式。這五種模式并不復(fù)雜但每一個(gè)都有自己的適用邊界。我結(jié)合實(shí)際項(xiàng)目逐個(gè)講清楚。3.1 提示鏈Prompt Chaining把大任務(wù)拆成順序小節(jié)提示鏈的核心思路是把一個(gè)復(fù)雜任務(wù)拆成多個(gè)順序執(zhí)行的步驟上一步的輸出作為下一步的輸入中間還可以插入必要的檢查點(diǎn)。它的典型應(yīng)用是內(nèi)容生成先寫大綱再逐節(jié)展開最后統(tǒng)一潤(rùn)色也可以用于批量處理先做格式轉(zhuǎn)換再做字段提取再翻譯。這種模式在什么時(shí)候特別有價(jià)值就是我前面說的當(dāng)任務(wù)可以被分解成清晰的、有先后依賴關(guān)系的子任務(wù)并且每一步的輸出質(zhì)量會(huì)顯著影響后續(xù)步驟時(shí)。比如在做營(yíng)銷郵件的自動(dòng)化生成時(shí)如果一次調(diào)用讓模型直接寫完整封郵件經(jīng)常會(huì)出現(xiàn)前后風(fēng)格不一致、邏輯跳脫的問題但用提示鏈拆成三步——定主題、寫正文、做標(biāo)題優(yōu)化——每一環(huán)節(jié)專注一件事效果會(huì)穩(wěn)定很多。寫提示鏈時(shí)最容易踩的坑有兩個(gè)。第一個(gè)是每步之間缺少“把關(guān)”你需要在步驟間嵌入一些輕量校驗(yàn)邏輯比如長(zhǎng)度檢查、JSON 格式校驗(yàn)、關(guān)鍵字段存在性檢查不要盲目地把上一步的輸出直接灌給下一步。第二個(gè)是把鏈條拉得太長(zhǎng)每增加一個(gè)環(huán)節(jié)就增加一次延遲和一次失敗可能理想的鏈條是 3 到 5 個(gè)環(huán)節(jié)以內(nèi)。3.2 路由Routing讓最合適的模型處理最合適的事路由模式解決的是“輸入類型高度分化、需要分類后再分別處理”的問題。它一般分兩跳先用一個(gè)分類器可以是大模型也可以是小模型甚至規(guī)則判斷輸入類別再把不同類別的輸入分發(fā)到對(duì)應(yīng)專門優(yōu)化的提示詞或模型調(diào)用上。這個(gè)模式最有價(jià)值的點(diǎn)在于你不需要用一個(gè)超大參數(shù)的模型解決所有問題也不用為所有場(chǎng)景維護(hù)一套復(fù)雜的通用提示詞。比如我做過一個(gè)文檔處理工具用戶會(huì)輸入各種內(nèi)容合同文本、技術(shù)博客、會(huì)議紀(jì)要、客服對(duì)話記錄。如果所有內(nèi)容都用同一套提示詞處理效果必然一般。后來用了路由先分揀出內(nèi)容類型然后合同走嚴(yán)謹(jǐn)條款摘要模板技術(shù)博客走要點(diǎn)提煉模板客服記錄走工單結(jié)構(gòu)化模板。同樣的模型能力整體輸出質(zhì)量提升了一個(gè)檔次。路由方案實(shí)現(xiàn)不難但它有一個(gè)關(guān)鍵前提分類本身要足夠可靠。如果分類錯(cuò)了后面的所有環(huán)節(jié)都會(huì)跟著錯(cuò)。所以在做路由時(shí)我會(huì)額外加一個(gè)置信度判斷——分類結(jié)果把握不高時(shí)走一個(gè)統(tǒng)一的默認(rèn)處理分支而不是強(qiáng)行塞進(jìn)某個(gè)特定分支。3.3 并行化Parallelization拆成多個(gè)子任務(wù)同時(shí)跑并行化模式適合抽絲剝繭式的任務(wù)把一個(gè)任務(wù)拆成多個(gè)互不依賴的子任務(wù)讓模型并行處理最后再匯總。Anthropic 筆記里把并行化分成兩種子類型。第一種是“分段式并行”大塊工作拆成小塊獨(dú)立完成。比如做行業(yè)調(diào)研報(bào)告時(shí)可以把“市場(chǎng)現(xiàn)狀”“競(jìng)品動(dòng)態(tài)”“技術(shù)趨勢(shì)”“用戶痛點(diǎn)”幾個(gè)板塊并行生成最后統(tǒng)一組裝。這種方式能明顯降低延遲因?yàn)楦鱾€(gè)部分互不依賴同時(shí)跑比串行快得多。第二種是“投票式并行”同一個(gè)任務(wù)交給多個(gè)模型實(shí)例分別做再用投票或評(píng)分機(jī)制選出最優(yōu)結(jié)果。這種方式適合那些“答案沒有唯一標(biāo)準(zhǔn)、但質(zhì)量可比較”的場(chǎng)景比如代碼審查、內(nèi)容合規(guī)判斷、創(chuàng)意方案篩選。多個(gè)角度同時(shí)審能有效減少單一模型視角偏差帶來的問題。并行化的實(shí)現(xiàn)細(xì)節(jié)里有一個(gè)技術(shù)要點(diǎn)子任務(wù)的拆分粒度要均衡。如果你把一個(gè)任務(wù)拆成 A 子任務(wù)需要 10 秒B 子任務(wù)需要 2 分鐘那并行化節(jié)省的時(shí)間其實(shí)很有限因?yàn)檎w耗時(shí)會(huì)卡在最慢的那個(gè)子任務(wù)上。合理的做法是先粗剖一遍看每個(gè)子任務(wù)的預(yù)估復(fù)雜度是否接近再?zèng)Q定要不要并行。3.4 編排者-協(xié)調(diào)者模式Orchestrator-Workers動(dòng)態(tài)拆解復(fù)雜任務(wù)編排者-協(xié)調(diào)者模式是五種工作流里最接近“弱化版智能體”的一種。主模型負(fù)責(zé)任務(wù)拆解、派發(fā)并匯總各子模型的結(jié)果子模型負(fù)責(zé)執(zhí)行被分配的具體子任務(wù)。它和前三種模式的最大區(qū)別在于任務(wù)拆分的方案不是預(yù)先設(shè)計(jì)的而是由編排模型根據(jù)動(dòng)態(tài)輸入現(xiàn)場(chǎng)決定的。這種模式非常適合那些“任務(wù)目標(biāo)明確但子任務(wù)的內(nèi)容和數(shù)量不固定”的場(chǎng)景。Anthropic 筆記里舉了一個(gè)很生動(dòng)的例子讓智能體對(duì)某個(gè)行業(yè)做多維度資料搜索和整理。用戶輸入“我是一家 SaaS 公司的市場(chǎng)負(fù)責(zé)人想了解教育行業(yè)的市場(chǎng)趨勢(shì)”Agent 會(huì)結(jié)合行業(yè)特征自行拆解出客戶群體分析、采購(gòu)決策鏈、競(jìng)品格局、獲客渠道、監(jiān)管環(huán)境等子任務(wù)然后分發(fā)給多個(gè)搜索 Worker 并匯總成報(bào)告。我第一次嘗試這種模式是在做一個(gè)“競(jìng)品分析自動(dòng)生成器”時(shí)。之前用提示鏈發(fā)現(xiàn)競(jìng)品數(shù)量不確定每家公司的數(shù)據(jù)字段也不一樣提示鏈寫死步驟根本覆蓋不了。換成編排者-協(xié)調(diào)者之后編排模型先列出當(dāng)前競(jìng)品名單再為每一個(gè)競(jìng)品生成一個(gè)獨(dú)立的 Worker 分析任務(wù)最后匯總成一章對(duì)比報(bào)告效果立馬就對(duì)了。這里要注意的是編排者模式對(duì) token 的消耗相當(dāng)大因?yàn)樗旧聿划a(chǎn)生太多最終內(nèi)容大部分 token 都消耗在“拆解-分派-匯總”的元操作上。如果你的任務(wù)結(jié)構(gòu)相對(duì)固定就別用這個(gè)模式如果子任務(wù)確實(shí)動(dòng)態(tài)變化這個(gè)開銷才值得。3.5 評(píng)估者-優(yōu)化者模式Evaluator-Optimizer生成-反饋的迭代閉環(huán)評(píng)估者-優(yōu)化者模式適合那些“一次生成很難到位、需要反饋迭代”的場(chǎng)景。它的結(jié)構(gòu)是一個(gè)生成模型產(chǎn)出內(nèi)容一個(gè)評(píng)估模型對(duì)產(chǎn)出質(zhì)量打分并給出修改建議生成模型再根據(jù)建議進(jìn)行優(yōu)化循環(huán)直到達(dá)到質(zhì)量標(biāo)準(zhǔn)。這個(gè)模式的靈感來源其實(shí)很像真實(shí)工作里的“初稿評(píng)審”機(jī)制。我經(jīng)常把它用在文案創(chuàng)作類任務(wù)上尤其是那種用戶只給了一句簡(jiǎn)短需求、但期望高質(zhì)量長(zhǎng)文案的場(chǎng)景。比如“寫一封給客戶的項(xiàng)目交付說明郵件”生成模型先按基本要求寫一版草稿評(píng)估模型從語氣、結(jié)構(gòu)完整性、風(fēng)險(xiǎn)信息覆蓋等維度打分指出“缺少時(shí)間節(jié)點(diǎn)說明”“語氣過于生硬”“結(jié)尾沒有明確下一步”等問題生成模型再改一版效果通常會(huì)顯著提升。但我要提醒一點(diǎn)評(píng)估者-優(yōu)化者模式是有成本陷阱的。如果評(píng)估環(huán)節(jié)的標(biāo)準(zhǔn)設(shè)計(jì)得模棱兩可模型可能陷入無限循環(huán)不斷改不斷被評(píng)“還可以更好”最終把 token 消耗到一個(gè)讓人心疼的程度。所以實(shí)操時(shí)必須設(shè)定最大迭代輪數(shù)并且在每輪評(píng)估時(shí)要求評(píng)估模型明確區(qū)分“必須修改”和“可選優(yōu)化”兩類建議只在必須項(xiàng)未清零時(shí)才繼續(xù)迭代。這五種工作流模式是基礎(chǔ)積木實(shí)際項(xiàng)目往往是它們的組合。比如先路由分類型再對(duì)其中一類走提示鏈另一類走并行化或者先用提示鏈輸出初稿再用評(píng)估者-優(yōu)化者做打磨。模式本身沒有高低之分組合得當(dāng)才是關(guān)鍵。4. 真正的智能體兩種形態(tài)與工程上的借力點(diǎn)4.1 自定義智能體自由但費(fèi)心當(dāng)你通過工作流已經(jīng)把任務(wù)拆解到極限、仍然發(fā)現(xiàn)某些環(huán)節(jié)需要模型自主規(guī)劃動(dòng)作時(shí)就需要上真正的智能體了。Anthropic 的筆記里把智能體分成了兩種形態(tài)自定義智能體和封裝式智能體。自定義智能體在工程實(shí)現(xiàn)上更為復(fù)雜。它本質(zhì)上是一個(gè)自主循環(huán)系統(tǒng)模型接收目標(biāo)和環(huán)境反饋決定調(diào)用什么工具工具返回結(jié)果后再?zèng)Q策下一步循環(huán)往復(fù)直到完成目標(biāo)或觸發(fā)終止條件。我最早實(shí)現(xiàn)這類循環(huán)是在做“自動(dòng)修復(fù)前端代碼風(fēng)格問題”的工具上接收一段不規(guī)范代碼自己調(diào)用 lint 工具、讀錯(cuò)誤日志、修改代碼、再 lint直到全綠。這個(gè)流程如果讓我預(yù)先寫死分支邏輯幾乎不可能覆蓋所有錯(cuò)誤類型所以必須讓模型自己決定下一步。實(shí)現(xiàn)這種循環(huán)的核心工程要素是一個(gè)清晰的工具接口、一個(gè)可靠的終止機(jī)制、以及一套完整的狀態(tài)記錄。工具接口要做成可枚舉的 JSON Schema 形式讓模型每次決策都走“選擇工具 填寫參數(shù)”的模式而不是文本生成式的亂寫終止機(jī)制要包含最大步數(shù)、無進(jìn)展判定連續(xù) N 步操作沒有改變狀態(tài)就停止、以及用戶主動(dòng)中斷通道狀態(tài)記錄則要把每一步的輸入輸出、模型思考過程、工具返回結(jié)果存下來方便事后復(fù)盤和調(diào)試。4.2 封裝式智能體更優(yōu)雅的封裝選擇封裝式智能體是另一個(gè)重要選擇。它的核心思路是基于一套框架協(xié)議比如模型上下文協(xié)議 MCPModel Context Protocol進(jìn)行標(biāo)準(zhǔn)化集成讓智能體框架能夠統(tǒng)一發(fā)現(xiàn)、調(diào)用和管理各種外部工具和數(shù)據(jù)源。這個(gè)思路的價(jià)值在于與其針對(duì)每家平臺(tái)、每個(gè)工具單獨(dú)寫適配層不如用一套標(biāo)準(zhǔn)協(xié)議把工具都“插”進(jìn)去相當(dāng)于給智能體做了一個(gè)統(tǒng)一插線板。這種封裝式方案其實(shí)就是目前市面上所謂“平臺(tái)搭建的智能體”和“用 Python 自己搭的智能體”的一個(gè)關(guān)鍵區(qū)別。你用 Coze、Dify 這類低代碼平臺(tái)搭智能體工具接入、上下文管理、日志追蹤基本都是平臺(tái)幫你封裝好的開箱即用但你能控制的細(xì)粒度有限你用 LangGraph、LlamaIndex 這類代碼框架自己搭上下文窗口策略、工具調(diào)用重試邏輯都能精細(xì)控制但所有封裝都要自己處理工作量也成倍增加。我自己的經(jīng)驗(yàn)是如果只是做一個(gè)內(nèi)部使用的效率工具低代碼平臺(tái)足夠省時(shí)省力如果要做一個(gè)對(duì)外交付、需要深度定制和長(zhǎng)期演進(jìn)的系統(tǒng)還是老老實(shí)實(shí)走代碼框架加封裝型協(xié)議這條路。判斷的尺度是你更缺時(shí)間成本還是更缺控制力。4.3 工具設(shè)計(jì)智能體的勝負(fù)手Anthropic 的筆記里用了大量篇幅強(qiáng)調(diào)工具設(shè)計(jì)但很多人在實(shí)操中完全不重視這個(gè)環(huán)節(jié)。工具設(shè)計(jì)的好壞直接決定智能體的成敗。好的工具設(shè)計(jì)要滿足三個(gè)原則命名要像 API 文檔一樣精準(zhǔn)。比如工具名用search_sales_orders不要用query_data這種含糊名稱。因?yàn)榇竽Ｐ褪强抗ぞ呙兔枋鰜硗茢喙ぞ哂猛镜拿筒粫?huì)在關(guān)鍵時(shí)刻調(diào)對(duì)工具。參數(shù)要帶類型和枚舉值說明。參數(shù) schema 里盡量把可選值列清楚比如訂單狀態(tài)字段注明[pending, paid, shipped, cancelled]避免模型傳一個(gè)領(lǐng)域里根本不存在的垃圾值。描述要寫“什么時(shí)候用”而不是“是什么”。比如股票價(jià)格查詢工具描述寫“當(dāng)用戶詢問某一公司的實(shí)時(shí)或歷史股價(jià)時(shí)使用”而不是“獲取股票數(shù)據(jù)的函數(shù)”。前者是引導(dǎo)模型在正確場(chǎng)景下觸發(fā)后者只是一句沒用的說明。這個(gè)道理特別像工具類軟件里的“空狀態(tài)引導(dǎo)”。用戶不知道這個(gè)功能什么時(shí)候該用它就永遠(yuǎn)不會(huì)被用。模型也是一樣。4.4 上下文管理別把什么垃圾都塞給模型智能體運(yùn)行過程中最常犯的錯(cuò)誤就是把每一步的結(jié)果全部堆進(jìn)上下文導(dǎo)致上下文越來越長(zhǎng)最后不僅 token 成本爆炸模型還會(huì)被無關(guān)信息干擾決策質(zhì)量急劇下降。Anthropic 的筆記里關(guān)于上下文管理給了一個(gè)很重要的指導(dǎo)思路不能把完整對(duì)話記錄一味塞給模型而應(yīng)該主動(dòng)管理上下文中的內(nèi)容。常用的處理策略有以下幾種窗口化Windowing只保留最近 N 輪的交互記錄更早的內(nèi)容丟棄或摘要化。結(jié)構(gòu)化摘要Summarization當(dāng)輪次太多時(shí)讓模型對(duì)歷史做階段性摘要摘要成為長(zhǎng)期記憶的替代品。關(guān)鍵信息提取Extraction把歷史中影響決策的關(guān)鍵數(shù)據(jù)結(jié)構(gòu)化抽取出來比如已經(jīng)完成的任務(wù)清單、已經(jīng)嘗試過的失敗方案、用戶的偏好設(shè)定之后每一輪都把結(jié)構(gòu)化關(guān)鍵信息注入上下文替代原文。我在做長(zhǎng)任務(wù)智能體時(shí)用的比較多的組合是窗口化 關(guān)鍵信息提取。會(huì)話早期完整保留每輪上下文當(dāng)累計(jì)長(zhǎng)度到達(dá)閾值后觸發(fā)一次壓縮把已明確完成的步驟匯總成一行記錄把用戶偏好提取成結(jié)構(gòu)化字段保存然后清空舊上下文。這樣既保留決策所需的記憶又不會(huì)讓對(duì)話記錄無限膨脹。4.5 記憶與多智能體最近討論度很高的擴(kuò)展方向順著上下文管理自然引出記憶這個(gè)話題。現(xiàn)在很多團(tuán)隊(duì)在做 Agent 時(shí)都會(huì)問“能不能讓智能體記住用戶偏好”。記憶不是簡(jiǎn)單地保存對(duì)話歷史而是要區(qū)分短期工作記憶和長(zhǎng)期語義記憶。短期記憶就是你正在處理的這條任務(wù)的上下文長(zhǎng)期記憶是跨會(huì)話的用戶畫像、歷史決策、偏好習(xí)慣。長(zhǎng)期記憶的實(shí)現(xiàn)方案業(yè)界目前比較常見的做法是把記憶轉(zhuǎn)成向量存進(jìn)向量數(shù)據(jù)庫在每輪對(duì)話開始時(shí)做語義檢索把最相關(guān)的幾條記憶注入上下文。這個(gè)方案有效但要注意隱私合規(guī)尤其是涉及用戶個(gè)人信息時(shí)不能一句話都不說明就開始沉淀記憶。多智能體是另一個(gè)熱詞。很多團(tuán)隊(duì)一聊架構(gòu)就想著搞多個(gè) Agent 協(xié)作但 Anthropic 那篇筆記里的態(tài)度非常審慎多智能體只在少數(shù)場(chǎng)景下才有收益比如多個(gè)角色需要獨(dú)立工具集和知識(shí)庫、或者任務(wù)天然可并行時(shí)。最常見的安全做法是“單個(gè)智能體 工具集”的組合而不是一上來就搞多智能體編排。多智能體系統(tǒng)的核心難點(diǎn)不是把 Agent 們串起來而是讓它們之間共享狀態(tài)和避免沖突這個(gè)復(fù)雜度是指數(shù)級(jí)上升的。如果你還沒有把單個(gè) Agent 吃透我勸你先別碰多智能體。5. 實(shí)戰(zhàn)選型與常見問題從需求到落地的避坑指南5.1 如何從需求出發(fā)選擇架構(gòu)我在帶項(xiàng)目時(shí)很少讓團(tuán)隊(duì)直接進(jìn)入編碼或配置階段而會(huì)先幫助他們回答一個(gè)核心問題你的系統(tǒng)到底需要哪種程度的自主性?；卮饐栴}最簡(jiǎn)單的路徑是畫一條思考線這個(gè)任務(wù)的輸入和輸出是否能被嚴(yán)格定義如果能直接用單次大模型調(diào)用。任務(wù)能否被拆分成固定的幾步驟如果能且每一步之間是先后依賴關(guān)系用提示鏈。輸入類型差異很大、不同類別的處理方式完全不同用路由。任務(wù)可以拆成相對(duì)獨(dú)立、互不依賴的子任務(wù)用并行化。輸出質(zhì)量要求高、需要多次迭代打磨用評(píng)估者-優(yōu)化者。子任務(wù)的內(nèi)容和數(shù)量事先不確定、需要?jiǎng)討B(tài)規(guī)劃用編排者-協(xié)調(diào)者或單智能體。模型需要自主調(diào)用多個(gè)工具并根據(jù)反饋調(diào)整策略用智能體。這些選項(xiàng)之間不是越往后“越高級(jí)”而是每一種都對(duì)應(yīng)不同的工程成本和效果預(yù)期。你可以把它理解成汽車變速箱的檔位不是檔位越高就越好而是匹配你當(dāng)前的路況才是最優(yōu)的。5.2 低代碼平臺(tái)和手寫框架怎么選前面提到了平臺(tái)和代碼框架的區(qū)別我在這里把二者的對(duì)比表列出來方便你直接參考維度低代碼/可視化平臺(tái)Coze、Dify代碼框架LangGraph、自定義循環(huán)上手成本低拖拽配置即可高需要熟悉框架約定和異步流程工具生態(tài)插件豐富但定制受限自由度最高按需封裝任意 API可觀測(cè)性平臺(tái)自帶日志但細(xì)節(jié)有限可深度自定義日志與追蹤上下文管理通常有固定機(jī)制可控性弱完全自控可精確設(shè)計(jì)壓縮和記憶策略多智能體平臺(tái)支持但內(nèi)部邏輯黑盒可精細(xì)控制協(xié)作與狀態(tài)共享生產(chǎn)級(jí)考驗(yàn)適合快速驗(yàn)證、內(nèi)部工具適合長(zhǎng)期演進(jìn)、To B 產(chǎn)品交付對(duì)大多數(shù)團(tuán)隊(duì)我的建議是先用低代碼平臺(tái)把業(yè)務(wù)邏輯驗(yàn)證跑通不要迷信“自己寫代碼更專業(yè)”。這個(gè)過程幫助你理解這套系統(tǒng)的行為邊界和效果預(yù)期一旦驗(yàn)證了場(chǎng)景確實(shí)需要更精細(xì)的控制再遷到代碼框架上此時(shí)你已經(jīng)知道要控制什么了遷移成本反而更低。我見過很多團(tuán)隊(duì)一上來就用代碼框架寫了個(gè)簡(jiǎn)陋的 Agent結(jié)果調(diào)試了一周還在解決最基本的工具調(diào)用問題這種彎路完全可以通過混合路徑規(guī)避。5.3 調(diào)試智能體的核心思路關(guān)注工具調(diào)用軌跡而非最終結(jié)果智能體和傳統(tǒng)程序最大的調(diào)試差異在于傳統(tǒng)程序可以逐行打斷點(diǎn)看狀態(tài)智能體的行為選擇是模型概率性的你無法簡(jiǎn)單復(fù)現(xiàn) Bug。所以調(diào)試智能體要換一種思路——重點(diǎn)看工具調(diào)用軌跡。我在排查智能體問題時(shí)一定會(huì)先拉出這類日志模型每一輪的思考、選擇的工具、填入的參數(shù)、工具返回的錯(cuò)誤信息。通過這些日志判斷失敗屬于哪一類模型選錯(cuò)了工具大概率是工具命名和描述寫得不對(duì)去改工具文檔。模型生成了非法參數(shù)大概率是參數(shù) schema 約束不足去補(bǔ)枚舉值和格式正則。工具本身報(bào)錯(cuò)檢查工具代碼不要把這筆賬算到模型頭上。模型在同一個(gè)工具上反復(fù)調(diào)用但結(jié)果無變化可能是工具返回信息不完整或者模型沒有理解返回結(jié)果需要調(diào)整工具返回內(nèi)容的格式和說明。模型在應(yīng)該結(jié)束時(shí)沒有結(jié)束檢查終止條件是否明確提示詞里是否明確告知“完成目標(biāo)后輸出最終答案”。這套排查思路和傳統(tǒng)后端聯(lián)調(diào)很像只不過你要調(diào)試的對(duì)象從“固執(zhí)的同事”變成了“一本正經(jīng)地胡說八道的 AI 同事”。5.4 企業(yè)落地中的典型失敗模式和兜底策略最后聊幾句企業(yè)落地層面的經(jīng)驗(yàn)。智能體在 demo 階段通常很驚艷一上生產(chǎn)就翻車原因往往不是模型能力不夠而是工程兜底沒做到位。我總結(jié)了幾種最常見的失敗模式第一是“可復(fù)現(xiàn)性缺失”。同樣的輸入這周跑出 A 結(jié)果下周跑出 B 結(jié)果業(yè)務(wù)方不敢用。應(yīng)對(duì)方案是固定模型版本、溫度參數(shù)和隨機(jī)種子并保留每次運(yùn)行的完整記錄至少在出問題時(shí)能復(fù)盤。第二個(gè)是“沒有降級(jí)路徑”。智能體一掛了整條業(yè)務(wù)線就癱了這比傳統(tǒng)系統(tǒng)更危險(xiǎn)。必須設(shè)計(jì)降級(jí)方案Agent 超時(shí)報(bào)錯(cuò)后走人工處理隊(duì)列或規(guī)則引擎兜底。第三個(gè)是“評(píng)測(cè)缺失”。很多團(tuán)隊(duì)在未定義清晰的評(píng)估指標(biāo)的情況下就直接上線 Agent 了。你需要準(zhǔn)備一套評(píng)測(cè)集里面包含正常樣本和異常樣本每次更換提示詞或模型版本后先跑一遍評(píng)測(cè)集對(duì)比通過率再?zèng)Q定是否上線。第四個(gè)也是最重要的一條不要在沒定義“成功”之前就優(yōu)化智能體。我看到太多團(tuán)隊(duì)日復(fù)一日調(diào)整提示詞試圖讓 Agent 在各種邊緣場(chǎng)景下表現(xiàn)更好卻沒有先想清楚一個(gè)最核心的問題——什么結(jié)果算完成什么結(jié)果算失敗什么情況算成本失控這三個(gè)定義不明白優(yōu)化就是在沙灘上蓋樓。5.5 面試視角智能體架構(gòu)的常見考點(diǎn)結(jié)合搜索引擎里頻繁出現(xiàn)的“智能體面試”這個(gè)熱詞順便聊一下這個(gè)話題?，F(xiàn)在很多公司的 AI 崗位面試都會(huì)聊到智能體架構(gòu)面試官通常不會(huì)問“你會(huì)不會(huì)用 LangGraph”而是會(huì)拋一個(gè)開放場(chǎng)景“如果讓你做一個(gè)自動(dòng)客服系統(tǒng)你會(huì)怎么設(shè)計(jì)為什么”這時(shí)候?qū)W好 Anthropic 這篇架構(gòu)筆記的價(jià)值就體現(xiàn)出來了。一個(gè)完整的回答應(yīng)該包含先分析任務(wù)是否真的需要智能體還是工作流就能解決如果涉及多類任務(wù)考慮路由或者混合流程在需要模型自主決策的地方說明工具設(shè)計(jì)和上下文管理的思路最后還要說明如何評(píng)測(cè)、如何兜底、如何觀測(cè)。面試官想看到的是架構(gòu)思維不是某個(gè)框架的函數(shù)用法。當(dāng)然如果還能順帶講一講低代碼平臺(tái)和代碼框架各自的優(yōu)缺點(diǎn)以及多智能體為什么大多數(shù)情況下不必要那就更完整了。這套思路也是我認(rèn)為所有做智能體相關(guān)工作的開發(fā)者都應(yīng)該練的基本功不是為了給面試官背答案而是因?yàn)橄肭宄@些問題真的能在項(xiàng)目里少走很多彎路。6. 我一直堅(jiān)持的經(jīng)驗(yàn)準(zhǔn)則寫了這么多最后分享幾條我在實(shí)際項(xiàng)目中形成的習(xí)慣希望對(duì)你有用。我做智能體的第一個(gè)原則是“先畫流程圖再寫代碼”。不管心里想得多清楚動(dòng)手之前一定把工作流用傳統(tǒng)的流程圖方式畫出來標(biāo)清楚哪些環(huán)節(jié)用模型、哪些環(huán)節(jié)用規(guī)則、哪些環(huán)節(jié)要人工審核。畫完之后再對(duì)照這篇架構(gòu)筆記里的模式看一遍能不能用更簡(jiǎn)單的模式替代這個(gè)習(xí)慣幫我避免過很多次過度設(shè)計(jì)。第二個(gè)原則是“先保底再優(yōu)化”。所有自主決策類系統(tǒng)我都先把退出條件、降級(jí)邏輯、最大成本限額這些安全機(jī)制寫好再開始調(diào)提示詞和工具。沒有兜底的智能體就像沒有剎車的車性能再好也不敢上路。第三個(gè)原則是“把失敗案例當(dāng)成產(chǎn)品需求”。模型每一次出錯(cuò)的日志我都不會(huì)只當(dāng)作 Bug 修掉而是歸類存檔定期回看看錯(cuò)誤主要集中在哪類輸入上。如果你的智能體總是在某類長(zhǎng)尾場(chǎng)景上失敗與其繼續(xù)調(diào)提示詞不如把它重新歸類單獨(dú)加一個(gè)路由分支處理。模型不該解決所有問題架構(gòu)才是解決問題的核心手段。