做 Agent 相關(guān)開發(fā)這一年多我最大的感受是Agent 技術(shù)棧的變化速度比傳統(tǒng)后端技術(shù)棧要快一個(gè)量級(jí)。今天還在刷屏的編排框架下個(gè)月可能就被新的范式蓋過去昨天大家還在聊單 Agent 怎么調(diào) Prompt今天討論的已經(jīng)是多 Agent 協(xié)作、工具協(xié)議、記憶分層。也正因?yàn)檫@樣很多剛?cè)肟拥娜藢W(xué)得很累——每天刷到的新工具、新概念像流水一樣但始終找不到一張能讓自己安心的全景圖。所以我一直建議別急著追新先把 Agent 技術(shù)棧從“工具名單”還原成“分層結(jié)構(gòu)”搞清楚每一層到底解決什么問題、層與層之間怎么銜接再回頭去看工具時(shí)每一個(gè)名字都能放回自己的位置。這篇文章我想把這張全景圖完整拆開來講。不只會(huì)畫分層的骨架還會(huì)把每一層的核心選型邏輯、常見誤區(qū)和實(shí)操經(jīng)驗(yàn)填進(jìn)去。適合兩類人看一類是準(zhǔn)備從零搭一個(gè) Agent 但不知道從哪兒入手的開發(fā)者另一類是已經(jīng)接了一些框架和模型但項(xiàng)目總在“能跑”和“跑不穩(wěn)”之間反復(fù)橫跳的人?？赐曛竽阒辽倌芑卮鹨粋€(gè)問題我的 Agent 出了 Bug問題出在技術(shù)棧的哪一層。1. 先看分層再看工具Agent技術(shù)棧的本質(zhì)是一條任務(wù)流水線很多 Agent 項(xiàng)目做不下去不是模型不夠強(qiáng)也不是工具不夠多而是從一開始就沒有建立分層意識(shí)。大家習(xí)慣了把框架當(dāng)作“Agent 本體”以為選了一個(gè)熱門框架就等于選好了技術(shù)棧結(jié)果后續(xù)的所有問題都被塞進(jìn)同一個(gè)黑盒里調(diào)試變成猜謎。其實(shí) Agent 技術(shù)棧的結(jié)構(gòu)沒有標(biāo)準(zhǔn)答案但骨架相對(duì)穩(wěn)定。任何一個(gè) Agent無論它是客服、編程助手還是數(shù)據(jù)分析機(jī)器人實(shí)際執(zhí)行路徑都可以抽象成一條流水線接收輸入模型理解規(guī)劃決策調(diào)用工具生成輸出。技術(shù)棧里的每一層都是為這條流水線上的某個(gè)環(huán)節(jié)服務(wù)的。1.1 為什么很多項(xiàng)目死在“沒有分層意識(shí)”我見過不少團(tuán)隊(duì)把所有邏輯都往 Prompt 里堆系統(tǒng)指令寫了一大段歷史會(huì)話原文塞進(jìn)去檢索回來的文檔片段也拼在后面工具調(diào)用結(jié)果再追加一段。結(jié)果模型輸出越來越飄一會(huì)兒重復(fù)用戶問題一會(huì)兒答非所問。這類問題排查起來特別痛苦因?yàn)槟愀静恢朗悄Ｐ屠斫馄诉€是參考資料把模型帶偏了還是工具返回的結(jié)果格式不對(duì)。如果在設(shè)計(jì)階段就按層切分定位會(huì)快很多輸出異常先看模型層上下文混亂先看記憶層工具沒生效先看工具層。這種隔離能力是分層最大的好處之一。另一個(gè)好處是替換成本可控。今天你用某套開源編排框架明天想換成可視化工作流平臺(tái)只要記憶層和工具層的對(duì)外接口不變替換范圍就被限制在單層內(nèi)部不會(huì)牽一發(fā)而動(dòng)全身。1.2 五層結(jié)構(gòu)全景圖我把 Agent 技術(shù)棧粗略拆成五層從下往上分別是模型層、記憶層、工具層、編排層、交互與可觀測(cè)層。它們之間有依賴關(guān)系但不嚴(yán)格串行實(shí)際項(xiàng)目中常做交叉組合。分層核心職責(zé)常見實(shí)現(xiàn)形態(tài)交互與可觀測(cè)層用戶入口、日志追蹤、效果評(píng)測(cè)聊天頁面、API 服務(wù)、Trace 系統(tǒng)編排層任務(wù)拆解、流程控制、多智能體協(xié)作各類編排框架與工作流平臺(tái)工具層外部系統(tǒng)調(diào)用、Function Calling、插件化服務(wù)工具網(wǎng)關(guān)、統(tǒng)一工具協(xié)議記憶層短期上下文、長(zhǎng)期記憶、外部知識(shí)檢索向量庫、摘要庫、數(shù)據(jù)庫模型層語言理解、內(nèi)容生成、工具調(diào)用決策各類大模型 API 或微調(diào)模型模型層在最底下因?yàn)樗?Agent 的智能上限首先由它決定。記憶層負(fù)責(zé)讓模型“記得住”和“查得到”工具層讓模型“做得到”編排層決定“怎么做”交互與可觀測(cè)層保證“能上線”。這五層中大多數(shù)項(xiàng)目最大的投入其實(shí)不在模型而在記憶、工具和編排上。1.3 分層之后再看新工具就不會(huì)慌剛?cè)肟拥娜擞龅揭粋€(gè)新框架第一反應(yīng)是“我是不是應(yīng)該趕緊遷移過去”。我的建議是反過來先問它替代的是哪一層。如果它只是某層的另一種實(shí)現(xiàn)而當(dāng)前實(shí)現(xiàn)沒有給你帶來不可忍受的痛點(diǎn)那就不急著換如果它在某層引入了新的機(jī)制比如更好的狀態(tài)管理、更完善的記憶方案那也要先在隔離環(huán)境里驗(yàn)證再考慮搬遷。分層思維還會(huì)幫你識(shí)別偽需求。比如有些團(tuán)隊(duì)一上來就想做“完全自主探索型 Agent”讓模型自己規(guī)劃每一步。這種設(shè)計(jì)聽起來很酷但在大部分業(yè)務(wù)場(chǎng)景里流程是相對(duì)確定的反而應(yīng)該用工作流把步驟固定下來。把這個(gè)問題想清楚技術(shù)棧的選擇范圍會(huì)立刻縮小一半。2. 底座模型選型三個(gè)硬指標(biāo)比跑分更值得關(guān)注模型層是 Agent 技術(shù)棧的地基但它也是最容易被“跑分誤導(dǎo)”的一層。很多人在選模型時(shí)只看綜合榜單和通用常識(shí)而忽略了 Agent 場(chǎng)景真正依賴的三項(xiàng)底層能力指令遵循、工具調(diào)用、長(zhǎng)上下文處理。這三項(xiàng)能力在通用對(duì)話里不一定顯眼但在 Agent 的復(fù)雜鏈路里任何一個(gè)短板都會(huì)被放大。2.1 指令遵循能力決定 Agent 能不能“聽人話”所謂指令遵循指的是模型能否理解并執(zhí)行你給定的結(jié)構(gòu)化指令而不是自由發(fā)揮。比如你讓一個(gè)查詢類 Agent 嚴(yán)格按三步執(zhí)行先識(shí)別實(shí)體再檢索資料最后給出帶來源的結(jié)論。指令遵循強(qiáng)的模型會(huì)按部就班弱的模型可能會(huì)跳步甚至把“識(shí)別實(shí)體”當(dāng)成一個(gè)回答環(huán)節(jié)直接輸出導(dǎo)致整個(gè)流程錯(cuò)亂。有一個(gè)非常典型的翻車場(chǎng)景用戶問“明天上海適合出門嗎”如果模型不知道今天的日期、不能主動(dòng)調(diào)起天氣工具、也沒有結(jié)合出行建議的指令它可能會(huì)憑訓(xùn)練知識(shí)瞎猜一個(gè)答案。這種問題在評(píng)測(cè)通用問答時(shí)不會(huì)被發(fā)現(xiàn)但在 Agent 任務(wù)里幾乎必然出現(xiàn)。所以我在選模型時(shí)一定會(huì)構(gòu)造一批帶明確流程要求的用例去做指令遵循測(cè)試而不是只看印象。2.2 工具調(diào)用能力Agent 能不能“動(dòng)手做事”的關(guān)鍵工具調(diào)用是模型層的核心能力之一也是 Agent 技術(shù)棧跟普通 Chatbot 最大的區(qū)別。模型需要判斷什么時(shí)候該調(diào)用工具、調(diào)用哪個(gè)工具、傳什么參數(shù)然后返回結(jié)構(gòu)化的調(diào)用請(qǐng)求由外部系統(tǒng)真正執(zhí)行。一個(gè)標(biāo)準(zhǔn)工具調(diào)用的返回結(jié)果大致長(zhǎng)這樣{ name: search_weather, arguments: { city: 上海, date: 明天 } }這段 JSON 不是模型生成的最終回答而是“模型想要調(diào)用工具的意圖”。拿到它之后程序才會(huì)真正去查天氣把結(jié)果帶回給模型繼續(xù)生成回答。如果模型在這步不穩(wěn)定Agent 的整個(gè)鏈路就會(huì)斷掉。所以我測(cè)試模型時(shí)有個(gè)習(xí)慣把工具描述和期望參數(shù)寫成固定用例同一個(gè)問題跑十次統(tǒng)計(jì)工具調(diào)用成功率和參數(shù)命中率低于我心理預(yù)期的模型直接不進(jìn)入下一輪評(píng)估。2.3 長(zhǎng)上下文、成本與響應(yīng)速度的三角權(quán)衡Agent 的每一次回答往往都要帶上歷史摘要、檢索片段、工具結(jié)果這些內(nèi)容疊在一起很容易超過上下文窗口。長(zhǎng)上下文模型確實(shí)能減少一部分 RAG 開發(fā)量但代價(jià)是更高的成本和更長(zhǎng)的響應(yīng)時(shí)間。我的經(jīng)驗(yàn)是不要試圖讓模型“全記住”。哪怕是支持超長(zhǎng)上下文的模型在 Agent 鏈路里也不適合無限塞數(shù)據(jù)因?yàn)槟Ｐ蛯?duì)中段內(nèi)容的注意力會(huì)衰減而且每次調(diào)用都在燒錢。實(shí)踐中更推薦用摘要機(jī)制把歷史對(duì)話壓成幾百個(gè) token 的要點(diǎn)檢索結(jié)果只保留最相關(guān)的 Top 5。這樣上下文短、響應(yīng)快、成本低還更容易穩(wěn)定。2.4 模型選型的最小驗(yàn)證清單在正式動(dòng)工之前我會(huì)做一個(gè)低成本驗(yàn)證流程固定下來大概是這樣的挑 5 到 10 個(gè)最真實(shí)的用戶問題覆蓋正常提問、歧義提問、缺參數(shù)提問。把每個(gè)問題期望的行為寫清楚包括要不要調(diào)用工具、要調(diào)用哪個(gè)工具、最終回答的格式。用候選模型各跑 20 遍統(tǒng)計(jì)指令遵循率、工具調(diào)用成功率和答案格式合規(guī)率。記錄平均響應(yīng)時(shí)間和單次成本結(jié)合預(yù)算做取舍。另外有一點(diǎn)很重要不要一上來就自建模型。Agent 技術(shù)棧的演化速度決定了底座模型本身也在快速迭代自建模型的成本非常高而收益未必能跑贏直接用成熟 API。更合理的策略是把模型層設(shè)計(jì)成可替換的Prompt 和工具盡量與具體模型解耦這樣以后更好的模型出來你只需要切換底座而不是推倒重來。3. 記憶與上下文工程Agent“忘事”的根因大多藏在這一層我在很多 Agent 項(xiàng)目里排查“答非所問”“前后矛盾”時(shí)發(fā)現(xiàn)問題往往不在模型而在記憶層。記憶不是簡(jiǎn)單地把對(duì)話歷史存下來它需要區(qū)分不同類型并且用不同的策略管理。項(xiàng)目越做越復(fù)雜記憶層的設(shè)計(jì)就越關(guān)鍵。3.1 三種記憶要分開別混在一個(gè)變量里我把 Agent 的記憶粗略分成三類。第一類是工作記憶對(duì)應(yīng)當(dāng)前會(huì)話里模型正在處理的上下文通常直接放在 Prompt 里。第二類是長(zhǎng)期記憶對(duì)應(yīng)跨會(huì)話保存的用戶偏好、歷史結(jié)論、知識(shí)摘要通常放在向量庫或摘要庫中。第三類是事實(shí)記憶對(duì)應(yīng)業(yè)務(wù)系統(tǒng)中的真實(shí)數(shù)據(jù)比如訂單狀態(tài)、庫存數(shù)量這些不應(yīng)該讓模型靠猜而是通過工具實(shí)時(shí)查詢。不少項(xiàng)目的問題就在于把三類記憶混在一起。比如把幾周前的對(duì)話原文也塞進(jìn)當(dāng)前 Prompt模型看到一堆“過期”信息之后自然就答錯(cuò)了。正確的做法是讓每一類記憶各司其職長(zhǎng)期記憶做摘要和查詢事實(shí)記憶靠工具獲取工作記憶只保留當(dāng)下這次回答真正需要的片段。3.2 向量庫只是記憶的一種實(shí)現(xiàn)不是銀彈提到記憶層很多人第一反應(yīng)是向量庫。但向量庫解決的問題只是“相似語義召回”它不等于記憶本身。常見的誤區(qū)有兩個(gè)一是把所有文檔無腦切片、向量化之后就丟進(jìn)去二是只依賴向量相似度做檢索完全不考慮關(guān)鍵詞匹配和排序優(yōu)化。以知識(shí)庫問答為例按固定 500 字硬切會(huì)讓一個(gè)完整的問題和答案被拆到兩個(gè)片段里導(dǎo)致檢索時(shí)召回不完整。更合理的做法是按語義單位切FAQ 類型以“一問一答”作為一個(gè)最小單元產(chǎn)品手冊(cè)按章節(jié)和標(biāo)題切表格單獨(dú)處理并保留來源、時(shí)間、分類等元數(shù)據(jù)方便后續(xù)過濾。同時(shí)在檢索策略上我不建議只用向量召回。更穩(wěn)的方案是混合檢索向量召回 Top 20關(guān)鍵詞召回 Top 10然后通過重排模型或者規(guī)則融合最終只取 Top 3 到 5 個(gè)片段喂給模型。這樣既能抓住語義相近的表達(dá)也不會(huì)漏掉精確匹配的關(guān)鍵詞。3.3 上下文組裝順序比想象中更重要同樣一堆信息放在上下文里的順序不同效果可能差別很大。這跟模型注意力機(jī)制有關(guān)模型對(duì)越靠后的內(nèi)容往往越敏感而對(duì)中間大段內(nèi)容容易“視而不見”。我常用的組裝模板是這樣的系統(tǒng)指令與安全邊界告訴模型它是誰、能做什么、不能做什么。長(zhǎng)期記憶摘要比如用戶的歷史偏好和之前達(dá)成的結(jié)論。本次檢索到的知識(shí)片段按相關(guān)度排序。最近對(duì)話的壓縮摘要保留事件脈絡(luò)而不是逐字粘貼。當(dāng)前用戶問題放在最末尾確保模型注意力聚焦在最新任務(wù)上。這套順序我調(diào)過很多次比較穩(wěn)定。尤其是“當(dāng)前問題放最后”這條很多新手實(shí)現(xiàn)時(shí)會(huì)把用戶問題放在最早結(jié)果模型越往后越偏最后的回答往往丟掉了用戶真正的訴求。3.4 三個(gè)容易忽略的翻車細(xì)節(jié)時(shí)間依賴問題是我踩過最多的一個(gè)坑。模型自身并不知道當(dāng)前日期如果 Agent 涉及“今天”“本周”“最近一個(gè)月”這類時(shí)間判斷必須在系統(tǒng)指令里注入當(dāng)前日期。另一個(gè)問題是來源引用檢索片段最好帶編號(hào)模型在回答時(shí)能標(biāo)注“根據(jù)資料 2 的內(nèi)容”這樣既增強(qiáng)可信度也方便用戶復(fù)查。還有一個(gè)是清理機(jī)制長(zhǎng)時(shí)間運(yùn)行的會(huì)話不可能一直疊上下文超過一定輪數(shù)后要把舊內(nèi)容做成摘要只保留摘要和新一輪對(duì)話防止上下文窗口被慢慢耗干。4. 編排層四種框架風(fēng)格和一套選型判斷邏輯編排層是整個(gè) Agent 技術(shù)棧里最熱鬧、也最容易讓人眼花繚亂的地方。市面上有數(shù)不清的框架和平臺(tái)每個(gè)都說自己能解決 Agent 編排問題。但仔細(xì)觀察會(huì)發(fā)現(xiàn)它們底層只有四種風(fēng)格每種風(fēng)格適合不同的場(chǎng)景。把風(fēng)格認(rèn)清選型就不會(huì)太糾結(jié)。4.1 編排到底在編排什么編排層實(shí)際做三件事控制流、提示詞組裝、工具掛載?？刂屏鹘鉀Q的是 Agent 下一步該做什么是按順序執(zhí)行還是分支選擇是循環(huán)重試還是跳到結(jié)束提示詞組裝決定模型每次收到什么樣的上下文工具掛載則決定模型在什么條件下能調(diào)用什么工具。換句話說框架不是“寫好了 Agent”而是幫你管理 Agent 執(zhí)行過程中的狀態(tài)和流程。4.2 四種常見框架風(fēng)格對(duì)比框架風(fēng)格適合場(chǎng)景優(yōu)點(diǎn)潛在問題代碼優(yōu)先編排型復(fù)雜業(yè)務(wù)邏輯、精細(xì)控制靈活度高狀態(tài)管理清晰學(xué)習(xí)成本高迭代速度慢可視化工流型快速迭代、運(yùn)營(yíng)人員參與上手快流程直觀復(fù)雜邏輯容易受限自主探索型原型驗(yàn)證、開放任務(wù)演示效果好路徑靈活生產(chǎn)環(huán)境不穩(wěn)定成本不可控多智能體協(xié)作型復(fù)雜任務(wù)拆解、多人協(xié)同角色分工清晰適合專項(xiàng)任務(wù)鏈路長(zhǎng)調(diào)試復(fù)雜度高代碼優(yōu)先型適合團(tuán)隊(duì)里以工程師為主、流程復(fù)雜的項(xiàng)目最大優(yōu)勢(shì)是可以一行行控制每一層邏輯出問題容易定位?？梢暬ち餍蛣t更接近傳統(tǒng)業(yè)務(wù)系統(tǒng)的流程設(shè)計(jì)器你拖拽節(jié)點(diǎn)就能搭一個(gè) Agent適合運(yùn)營(yíng)配置和快速驗(yàn)證。自主探索型讓模型自己拆任務(wù)、自己決定調(diào)用順序Demo 看起來很智能但一旦遇到線上真實(shí)輸入很容易陷入死循環(huán)或偏離目標(biāo)。多智能體協(xié)作型則把任務(wù)拆給多個(gè)角色 Agent比如一個(gè)負(fù)責(zé)規(guī)劃、一個(gè)負(fù)責(zé)執(zhí)行、一個(gè)負(fù)責(zé)質(zhì)檢適合流程邊界清晰的復(fù)雜任務(wù)。4.3 選型三問我判斷該用哪種風(fēng)格通常會(huì)問三個(gè)問題。第一流程是確定的還是開放的。如果業(yè)務(wù)規(guī)則明確比如“先查訂單狀態(tài)再判斷退款資格”優(yōu)先選工作流如果任務(wù)本身沒有固定路徑比如一個(gè)研究型 Agent 要自己決定查哪些資料才需要考慮自主探索或多智能體。第二團(tuán)隊(duì)是工程優(yōu)先還是運(yùn)營(yíng)優(yōu)先。工程師為主的團(tuán)隊(duì)可以直接用代碼優(yōu)先寫代碼本身就是表達(dá)流程最快的方式如果運(yùn)營(yíng)經(jīng)常改流程可視化工流平臺(tái)會(huì)省很多溝通成本。第三項(xiàng)目要長(zhǎng)期演化還是快速驗(yàn)證。長(zhǎng)期產(chǎn)品我更推薦代碼優(yōu)先因?yàn)榭蓽y(cè)試、可審查、可沉淀快速 Demo 或一次性活動(dòng)用可視化平臺(tái)效率高得多。4.4 我在編排層踩過的幾個(gè)坑早期我做 Agent 時(shí)犯過一個(gè)錯(cuò)誤一上來就引入重量級(jí)編排框架結(jié)果連“讓模型輸出 JSON”這種基礎(chǔ)能力都要花幾天調(diào)試?？蚣鼙旧頉]有錯(cuò)但那是殺雞用牛刀。另一個(gè)常見的坑是把規(guī)劃邏輯完全交給模型看起來好像很聰明但模型一旦編造不存在的工具或來回折騰整個(gè) Agent 就失控了。還有一個(gè)教訓(xùn)是過度嵌套多 Agent本來一個(gè) Agent 能完成的事情非要拆成三個(gè)角色互相傳遞消息Token 成本和延遲都翻倍。我現(xiàn)在做新項(xiàng)目時(shí)會(huì)先用最簡(jiǎn)單的工作流跑通一條路徑確認(rèn)邏輯穩(wěn)定后再評(píng)估是否引入更重的編排框架。5. 工具層讓Agent安全地把“手”伸出去工具層是 Agent 與外部世界交互的橋梁。沒有工具層的 Agent 只能聊天有了工具層的 Agent 可以查數(shù)據(jù)、發(fā)通知、操作業(yè)務(wù)系統(tǒng)。但也正因?yàn)槟堋皠?dòng)手”工具層成了安全隱患和高成本的重災(zāi)區(qū)。5.1 工具調(diào)用不是簡(jiǎn)單發(fā)請(qǐng)求而是“參數(shù)校驗(yàn) 執(zhí)行策略”模型通過 Function Calling 生成結(jié)構(gòu)化調(diào)用請(qǐng)求后真正執(zhí)行動(dòng)作的是工具層代碼。這里最容易忽略的是參數(shù)校驗(yàn)和執(zhí)行策略。模型生成參數(shù)時(shí)可能多字、漏字、格式錯(cuò)誤或者生成了一些不在預(yù)期內(nèi)的值所以在執(zhí)行前必須做校驗(yàn)。舉個(gè)例子如果你的工具是查詢銷售數(shù)據(jù)模型把參數(shù)填成了不存在的省份也沒關(guān)系工具層可以直接攔截并返回“無效參數(shù)”讓模型重新生成一次。執(zhí)行策略也很重要比如數(shù)據(jù)庫查詢必須走只讀賬號(hào)外部 API 請(qǐng)求要加超時(shí)限制敏感操作要加二次確認(rèn)。這些不是模型層能替你完成的只能在工具層硬性約束。5.2 統(tǒng)一工具協(xié)議一次接入多個(gè)模型復(fù)用現(xiàn)在不少團(tuán)隊(duì)會(huì)同時(shí)接多個(gè)大模型不同模型的工具調(diào)用格式不完全一樣。如果每個(gè)模型都單獨(dú)寫一套工具適配維護(hù)成本會(huì)很高。所以工具層設(shè)計(jì)時(shí)我建議采用統(tǒng)一工具協(xié)議和統(tǒng)一工具網(wǎng)關(guān)的思路把工具描述、參數(shù) Schema、執(zhí)行狀態(tài)、錯(cuò)誤信息標(biāo)準(zhǔn)化模型側(cè)只需要按標(biāo)準(zhǔn)協(xié)議輸出調(diào)用意圖工具網(wǎng)關(guān)負(fù)責(zé)翻譯和執(zhí)行。統(tǒng)一工具網(wǎng)關(guān)還有個(gè)額外好處可以集中做鑒權(quán)、限流、審計(jì)。比如所有工具調(diào)用都經(jīng)過同一個(gè)入口日志自動(dòng)記錄誰在什么時(shí)候調(diào)用了哪個(gè)工具、傳了什么參數(shù)、結(jié)果如何盡量全量留存。這些日志對(duì)后續(xù)排障和效果分析非常有用。5.3 工具執(zhí)行的安全邊界工具層安全是 Agent 能不能真正進(jìn)入生產(chǎn)環(huán)境的重要前提。我把幾條硬性邊界列一下每一條都是項(xiàng)目里驗(yàn)證過很有必要的數(shù)據(jù)類工具只給只讀權(quán)限嚴(yán)禁讓模型直接執(zhí)行寫操作。工具返回結(jié)果要裁剪只保留模型需要的字段避免超長(zhǎng)響應(yīng)塞爆上下文。涉及刪除、轉(zhuǎn)賬、審批這類敏感動(dòng)作必須走人工確認(rèn)流程。所有工具調(diào)用必須埋點(diǎn)日志至少記錄調(diào)用時(shí)間、參數(shù)、返回狀態(tài)。已下線的工具要及時(shí)從工具列表中移除避免模型調(diào)用到過期接口。5.4 工具不是越多越好我建議控制在 7 個(gè)以內(nèi)剛開始搭建工具層時(shí)我總想把所有能力都暴露給模型結(jié)果效果反而更差。工具一多模型經(jīng)常選錯(cuò)工具或者在兩個(gè)相似工具之間來回糾結(jié)白白消耗 Token。后來我把相似功能合并原來三個(gè)不同粒度的查詢工具合并成一個(gè)帶參數(shù)區(qū)分的工具之后調(diào)用準(zhǔn)確率立竿見影地上升了。經(jīng)驗(yàn)是單個(gè) Agent 暴露的工具最好控制在 7 個(gè)左右不要超過認(rèn)知負(fù)荷的臨界值。每個(gè)工具的描述要寫清楚三件事這個(gè)工具適合什么場(chǎng)景、參數(shù)格式是什么、執(zhí)行失敗時(shí)可能返回什么錯(cuò)誤。描述寫得越準(zhǔn)確模型選錯(cuò)的概率越低。6. 可觀測(cè)與評(píng)測(cè)決定Agent能不能上線的兩件事一個(gè) Agent 在測(cè)試環(huán)境跑得挺好不代表能上線。真正決定它能不能扛住真實(shí)流量的是可觀測(cè)能力和評(píng)測(cè)體系。這兩件事在我接觸的團(tuán)隊(duì)里經(jīng)常被拖到最后一刻然后被迫補(bǔ)課。6.1 從 Trace 開始一次回答背后是一串不可見調(diào)用Agent 的回答很少是一步生成出來的它可能經(jīng)歷了“意圖識(shí)別、工具調(diào)用、檢索召回、結(jié)果重排、最終生成”多個(gè)環(huán)節(jié)。任何一個(gè)環(huán)節(jié)出錯(cuò)最終結(jié)果都會(huì)偏。所以可觀測(cè)性是 Agent 技術(shù)棧里不能省的一層。我的做法是至少記錄每次 LLM 調(diào)用的輸入、輸出、耗時(shí)、Token 數(shù)記錄每條工具調(diào)用的參數(shù)、返回狀態(tài)、錯(cuò)誤信息并把完整鏈路串成一個(gè) Trace。排查問題時(shí)先看 Trace 里哪一步異常如果工具返回了錯(cuò)誤就到工具層找原因如果檢索結(jié)果為空就到記憶層看分段策略如果每一步都正常但最終回答不符合要求那問題多半出在 Prompt 或模型選擇上。6.2 評(píng)測(cè)集是 Agent 的“驗(yàn)收單”沒有評(píng)測(cè)集Agent 項(xiàng)目的改進(jìn)就是打地鼠修好一個(gè) Bug又冒出新 Bug。我通常會(huì)準(zhǔn)備 20 到 30 個(gè)固定用例覆蓋正常問題、邊界問題、缺參數(shù)問題、惡意輸入和空結(jié)果場(chǎng)景同時(shí)寫下每個(gè)用例的期望行為。每次修改 Prompt、切換模型、調(diào)整工具之后這批用例都會(huì)完整重跑一遍。評(píng)測(cè)維度我會(huì)拆成幾個(gè)方面回答是否達(dá)到預(yù)期、格式是否符合要求、工具調(diào)用是否必要和正確、是否在不確定時(shí)主動(dòng)說明而不是瞎編。第一次可以人工打分跑熟之后可以腳本自動(dòng)比對(duì)關(guān)鍵字段只有自動(dòng)分和人工抽查都過了才允許上線。這個(gè)環(huán)節(jié)的意義不是追求分?jǐn)?shù)好看而是防止“修好的問題在下一次改動(dòng)里復(fù)發(fā)”。6.3 一套最小可行的評(píng)測(cè)流程我的最小評(píng)測(cè)流程大概是這樣先定義評(píng)測(cè)集把每個(gè)用例的期望行為寫清楚然后用批量腳本跑一遍自動(dòng)記錄結(jié)果接著人工抽檢一部分典型 case重點(diǎn)看模型判斷和工具調(diào)用質(zhì)量最后把 Bad Case 整理出來分析問題是模型層、記憶層還是工具層修復(fù)后全量回歸一遍。這套流程不需要一開始就用復(fù)雜平臺(tái)一個(gè)腳本加一張表就能跑起來。但一旦項(xiàng)目進(jìn)入持續(xù)迭代階段評(píng)測(cè)集就是唯一能讓你放心改動(dòng)的基礎(chǔ)設(shè)施。7. 落地避坑與我的最小起步路徑前面講完五層的拆解最后說說整體落地時(shí)最容易踩的坑以及我自己的最小起步路徑。7.1 五個(gè)最容易讓 Agent 項(xiàng)目胎死腹中的問題常見癥狀背后原因建議方向Prompt 寫了一長(zhǎng)串模型仍不按預(yù)期執(zhí)行指令遵循能力不足或結(jié)構(gòu)混亂拆解指令加入示例分步驗(yàn)證回答引用了不存在的資料檢索片段沒有來源標(biāo)注給片段編號(hào)要求模型引用編號(hào)工具調(diào)用經(jīng)常失敗或選錯(cuò)工具工具描述不清或工具數(shù)量過多合并相似工具優(yōu)化描述Token 成本快速失控上下文無限堆疊工具調(diào)用反復(fù)失敗摘要壓縮限制上下文長(zhǎng)度改了 Prompt 后舊問題復(fù)發(fā)缺少評(píng)測(cè)集和回歸流程建立最小評(píng)測(cè)集每次改動(dòng)全量回歸7.2 從 0 到 1 的最小技術(shù)棧很多團(tuán)隊(duì)想把 Agent 一步到位結(jié)果把技術(shù)棧搭得很重項(xiàng)目卻遲遲跑不起來。我的建議是反過來先做一個(gè)最小的閉環(huán)能夠處理一條最簡(jiǎn)單的業(yè)務(wù)線就夠了。Model 用成熟 API 接入記憶層先用會(huì)話摘要加簡(jiǎn)單檢索工具層只接一個(gè)核心工具編排層先用工作流把固定步驟寫死再加一份基礎(chǔ)日志。先把這條鏈路跑通驗(yàn)證業(yè)務(wù)價(jià)值和用戶反饋然后再逐步擴(kuò)展加第二個(gè)工具、引入向量檢索、嘗試更復(fù)雜的編排策略。這樣做的最大好處是你每一步的改動(dòng)都有基準(zhǔn)出了問題知道影響面在哪里。7.3 我對(duì)技術(shù)棧迭代的態(tài)度遇到新框架我現(xiàn)在的習(xí)慣是先冷靜看幾件事它替代的是哪一層它跟當(dāng)前實(shí)現(xiàn)的差異是什么它能不能解決我此刻真正在痛的痛點(diǎn)如果答案不夠明確就在隔離環(huán)境里把舊實(shí)現(xiàn)重寫一遍做對(duì)比而不是直接割接。技術(shù)棧本身是工具不是信仰適合當(dāng)前階段的就是最好的。如果只讓我留一條建議給剛接觸 Agent 技術(shù)棧的人先找一個(gè)足夠小的場(chǎng)景把一個(gè)最小的 Agent 完整跑通再回來看這張全景圖。全景圖能幫你理解全貌但真正讓你把每一層記住的永遠(yuǎn)是那些線上出了 Bug 之后順著 Trace 一層層往回定位的夜晚。