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