做AI Agent開發(fā)這幾年我越來越覺得“分類”這個詞被嚴重低估了。很多人一看“功能型AI Agent分類”以為是教科書式的概念梳理實際工作中根本用不上。但我的真實體驗恰恰相反如果你在動手寫第一行Agent代碼之前沒有先想清楚這個Agent到底屬于什么功能類型、應(yīng)該按什么模式工作后期返工的概率幾乎百分之百。這篇是系列第18篇專門把功能型AI Agent的分類這件事掰開揉碎講清楚包括我踩過的坑、驗證過的選型方法以及每種分類背后的技術(shù)實現(xiàn)差異。1. 為什么必須先談“分類”再談“開發(fā)”先講一個我自己的教訓(xùn)。早先做一個內(nèi)部工單處理系統(tǒng)我一上來就套用了當時很流行的ReAct模式讓大模型自由調(diào)用工具處理每一個工單。demo階段看著很驚艷大模型能自己查知識庫、寫回復(fù)、開工單。但一上真實業(yè)務(wù)就崩了工單處理流程有明確的合規(guī)分支大模型每跑一次走的路徑都不一樣有的工單直接被模型跳過審核就提交了。最后不得不推翻重做。問題就出在沒有提前分類。工單處理本質(zhì)上是“規(guī)則驅(qū)動流程型”它需要的是流程引擎加有限分支決策而不是完全開放式的模型自由發(fā)揮。如果當時先進行分類判斷我根本不會選ReAct方案。功能型AI Agent的分類本質(zhì)上不是學(xué)術(shù)研究而是開發(fā)前的設(shè)計方案選擇。分類的核心價值有三個第一選型不同功能類型的Agent對應(yīng)不同的提示詞結(jié)構(gòu)、記憶策略和工具調(diào)用方式第二評估你只有知道Agent屬于哪個類型才知道該用什么樣的指標去衡量它好不好用第三排查系統(tǒng)出問題的時候分類能幫你快速鎖定問題層是規(guī)劃層、工具層還是決策層。需要說明的是我這里說的“功能型Agent”是指那些要解決具體業(yè)務(wù)任務(wù)、跑在生產(chǎn)環(huán)境里的Agent不是實驗室里研究通用智能的那種。所以分類的維度也完全是實用導(dǎo)向。我常用的分類維度有四個任務(wù)粒度、決策機制、交互方式、功能定位。任何一個真實的Agent都可以用這四個維度去刻畫而且大概率會同時屬于多個類別。這正是分類真正有用的地方——它不是一個標簽而是一組設(shè)計約束。2. 按任務(wù)粒度單體執(zhí)行型與復(fù)合規(guī)劃型2.1 單任務(wù)執(zhí)行型Agent單任務(wù)執(zhí)行型Agent是指一次只完成一件明確事情的Agent。典型的例子包括文本摘要Agent、敏感詞審核Agent、格式轉(zhuǎn)換Agent、翻譯Agent。這類Agent的實現(xiàn)通常非常直接一個模型調(diào)用加上輸入輸出校驗和失敗重試邏輯。很多人覺得這種“一個小功能”不算Agent因為它太簡單了。但我恰恰認為單任務(wù)執(zhí)行型是功能型Agent里數(shù)量最多、也最容易被做砸的一類。做過生產(chǎn)環(huán)境的都知道一個翻譯Agent跑在內(nèi)部系統(tǒng)里用戶傳上來一個幾百MB的文檔你怎么切分、怎么保持上下文、怎么處理模型超時這里面坑多得很。雖然任務(wù)單步但工程復(fù)雜度一點不少。實現(xiàn)這類Agent的關(guān)鍵不在模型而在工程兜底。輸入檢查要前置格式不對直接拒絕別讓模型處理臟數(shù)據(jù)輸出要做結(jié)構(gòu)化校驗讓模型輸出JSON就嚴格校驗字段缺了就重試還要預(yù)留降級方案模型服務(wù)不可用的時候至少要返回一個明確錯誤而不是讓用戶干等。我見過太多團隊把精力放在調(diào)prompt上結(jié)果真正救命的卻是這些看起來不性感的工程邏輯。2.2 復(fù)合規(guī)劃型Agent復(fù)合規(guī)劃型Agent面對的是一個大目標需要自己拆解成多個子任務(wù)再依次執(zhí)行。典型場景包括自動生成調(diào)研報告、智能排期、故障根因分析。這類Agent才算真正用上了“規(guī)劃”能力也是目前最容易翻車的類型。實現(xiàn)路線主要有兩條。一條是ReAct風(fēng)格的循環(huán)讓模型在“思考-行動-觀察”之間反復(fù)迭代另一條是Plan-and-Execute先讓模型生成一份任務(wù)清單然后逐個執(zhí)行。我的使用感受是ReAct靈活但不可控每一步都依賴模型判斷token消耗大且容易跑偏Plan-and-Execute前期可控但一旦計劃第一條就錯了后面全跟著錯而且缺乏動態(tài)修正能力。所以實際項目里我更傾向兩種結(jié)合先生成計劃把計劃交給一個執(zhí)行器執(zhí)行過程中如果遇到計劃外的情況再回到規(guī)劃器做局部重置。復(fù)合規(guī)劃型Agent的難點有三個任務(wù)拆分粒度、子任務(wù)依賴關(guān)系、部分失敗回滾。任務(wù)拆分太粗子任務(wù)本身還是一個大問題拆分太細規(guī)劃開銷又過大。子任務(wù)之間如果有依賴執(zhí)行順序錯了整個流程就廢了。部分失敗回滾更是硬骨頭頭幾個子任務(wù)成功了、后面失敗了怎么處理中間狀態(tài)這需要非常嚴謹?shù)臓顟B(tài)設(shè)計。注意在任務(wù)粒度上我的經(jīng)驗是“能單步不復(fù)合”。如果一個任務(wù)不需要動態(tài)規(guī)劃就能完成就老老實實用單任務(wù)Agent。很多人為了技術(shù)炫技硬把簡單任務(wù)搞成多步規(guī)劃結(jié)果成本和風(fēng)險都翻倍。對比項單任務(wù)執(zhí)行型復(fù)合規(guī)劃型任務(wù)特征目標單一、邊界清晰目標開放、需要拆解實現(xiàn)復(fù)雜度低工程兜底為主高需要規(guī)劃與狀態(tài)管理穩(wěn)定性高容易測試低路徑不確定性大適用場景翻譯、審核、格式轉(zhuǎn)換調(diào)研、排期、診斷典型成本一次模型調(diào)用多次模型調(diào)用工具調(diào)用3. 按決策機制規(guī)則驅(qū)動、模型驅(qū)動與混合決策3.1 規(guī)則驅(qū)動型Agent規(guī)則驅(qū)動型Agent的決策不是模型做的而是由預(yù)定義的規(guī)則、狀態(tài)機或工作流引擎控制。它的特點是穩(wěn)定、可解釋、成本低。模型在里面的角色往往是執(zhí)行某個節(jié)點上的具體任務(wù)而不是決定下一步做什么。典型場景包括流程審批Agent、定時任務(wù)Agent、有明確分支導(dǎo)向的自動化流程。打個比方一個合同歸檔Agent它的流程可能是“收到合同→檢查是否帶簽章→帶簽章走歸檔→不帶簽章通知補充”這個流程里的分支判斷完全可以由規(guī)則完成模型只需要在“識別簽章位置”這一步出力。這種Agent的優(yōu)點是出問題好排查每一步都有日志、有明確狀態(tài)缺點是僵化流程一變就得改代碼。如果你發(fā)現(xiàn)業(yè)務(wù)流程三個月一小改、半年一大改那純規(guī)則驅(qū)動會讓維護者想罵人。合理的做法是把規(guī)則做成可配置的甚至用可視化的工作流編輯器去管理。3.2 模型驅(qū)動型Agent模型驅(qū)動型Agent的決策核心是大模型系統(tǒng)只提供工具集和約束條件具體走哪條路徑完全由模型根據(jù)上下文判斷。這種類型適合任務(wù)開放、沒有固定流程的場景比如開放域問答、創(chuàng)意生成、復(fù)雜問題探索。技術(shù)實現(xiàn)上常見的模式有三種。第一種是ReAct模型循環(huán)推理決策第二種是反思機制讓模型先做一次再自己對輸出做批評修正第三種是樹狀搜索讓模型展開多條路徑再評估取舍。聽起來很像是AI Agent的標準玩法實際落地時要意識到模型驅(qū)動的代價是極高的不確定性同一輸入兩次運行可能走完全不同的路徑這對生產(chǎn)系統(tǒng)是很頭痛的。線上環(huán)境用模型驅(qū)動型Agent必須有預(yù)算控制、步驟上限和時間限制否則一個失控循環(huán)可能讓賬戶余額歸零。3.3 混合決策型Agent第三種類型是我個人最推薦在真實業(yè)務(wù)里用的混合決策型。它的核心思想非常簡單——能用規(guī)則判定的就不讓模型決定規(guī)則覆蓋不了的場景再讓模型兜底。這樣做的好處非常明顯。第一成本低大部分簡單流量走規(guī)則只有少數(shù)復(fù)雜情況才調(diào)用模型第二穩(wěn)定規(guī)則分支的行為是可以預(yù)先測試的第三可控模型出錯時規(guī)則層可以作為安全網(wǎng)攔截。舉一個我做過的問題分類Agent實例。用戶提交一個技術(shù)工單系統(tǒng)先做關(guān)鍵詞和正則匹配能命中已知問題類型就直接打標簽命中不了再交給大模型做語義理解。實測下來這個Agent的準確率比純模型高因為它天然減少了模型幻覺的機會同時成本降了60%因為大多數(shù)工單根本不需要進模型?；旌蠜Q策的關(guān)鍵在于設(shè)計好“交給模型”的觸發(fā)條件。我的建議是如果規(guī)則判定置信度很低或者規(guī)則覆蓋范圍外才調(diào)用模型。這個置信度閾值需要在真實數(shù)據(jù)上反復(fù)校準太嚴格會把本該規(guī)則處理的拉去模型成本降不下來太寬松又會讓很多模型能處理的簡單任務(wù)進規(guī)則層準確率受影響。一般我會習(xí)慣設(shè)兩個閾值高閾值直接采用規(guī)則結(jié)果低閾值直接給人工兜底中間地帶留給模型。決策機制優(yōu)點缺點適合場景規(guī)則驅(qū)動穩(wěn)定、便宜、可解釋僵化、維護成本高流程固定的業(yè)務(wù)模型驅(qū)動靈活、適應(yīng)開放任務(wù)不可控、成本高探索型、開放型任務(wù)混合決策平衡成本與靈活需要設(shè)計觸發(fā)邏輯大部分生產(chǎn)環(huán)境4. 按交互方式工具調(diào)用、知識檢索與系統(tǒng)操作4.1 工具調(diào)用型Agent工具調(diào)用型Agent的核心特征是它能通過函數(shù)調(diào)用機制去使用外部工具。你給模型一個工具清單每個工具都有名稱、描述、參數(shù)結(jié)構(gòu)模型在需要時自主選擇調(diào)用哪個工具、傳什么參數(shù)。這就是目前大模型平臺普遍支持的函數(shù)調(diào)用機制。這類Agent最常見的應(yīng)用場景是信息聚合和操作執(zhí)行。比如一個出行助手Agent它需要同時查天氣、查車票、查酒店就可以分別封裝成三個工具模型根據(jù)用戶需求決定調(diào)用順序。實現(xiàn)工具調(diào)用型Agent的時候最容易出問題的其實是參數(shù)校驗。模型給出的參數(shù)經(jīng)常“像模像樣但細節(jié)錯誤”前端一個時間參數(shù)可能差一天文件名可能多了個空格。所以工具調(diào)用層必須做參數(shù)強校驗不能直接把模型返回的參數(shù)透傳給外部系統(tǒng)。另外工具的描述要寫清楚。很多開發(fā)者隨便寫一句描述模型就無法準確理解工具能力和邊界。我的習(xí)慣是每個工具描述里說明它能做什么、不能做什么、有哪些限制條件甚至給一兩個使用范例。描述寫得好工具調(diào)用的準確率能明顯提升。4.2 知識檢索型Agent知識檢索型Agent致力于解決一個核心問題讓模型回答基于特定知識庫而不是憑空編造。實現(xiàn)上就是完整的RAG管線包括文檔解析、文本切分、向量化、召回、重排、生成。這類Agent在企業(yè)內(nèi)部特別常見比如制度問答Agent、產(chǎn)品手冊客服Agent、技術(shù)文檔助手。RAG管線的坑集中在中間環(huán)節(jié)。文檔切分粒度不對語義就被切斷向量化模型選得不對召回質(zhì)量直接崩召回條數(shù)設(shè)得太少上下文不足設(shè)得太多又可能把噪聲引入生成。我個人的經(jīng)驗是重排這個環(huán)節(jié)別省。第一輪向量召回可以寬一點召回二三十條然后用重排模型精排取前三到五條效果比單純提高向量模型分數(shù)來得實在。知識檢索型Agent還有一個容易忽略的評估維度答對是及格線答不出來才是加分項。很多Agent為了不冷場強行從知識庫里拽一堆弱相關(guān)內(nèi)容來編答案。這比直接說“不知道”還要糟糕。所以生產(chǎn)環(huán)境的檢索Agent我強烈建議加一個“相關(guān)性閾值”召回內(nèi)容得分過低就直接輸出“當前知識庫中暫無對應(yīng)內(nèi)容”同時把這個查詢記錄下來供人工補充知識。4.3 系統(tǒng)操作型Agent系統(tǒng)操作型Agent不只是調(diào)用幾個API它實際上是在操作一個業(yè)務(wù)系統(tǒng)往往帶有狀態(tài)變更。典型場景包括自動化測試Agent、數(shù)據(jù)遷移Agent、批量狀態(tài)更新Agent。這類Agent執(zhí)行的動作是不可逆的所以安全設(shè)計是它的第一優(yōu)先級。我對系統(tǒng)操作型Agent的最低要求是所有操作必須有審計日志所有變更類操作必須有確認步驟所有工具必須有權(quán)限邊界。也就是說一個Agent可以查詢訂單不代表它可以修改訂單它在測試環(huán)境可以刪除數(shù)據(jù)但生產(chǎn)環(huán)境的刪除工具壓根不暴露給模型。操作型Agent還特別依賴“冪等性”設(shè)計。因為模型可能因為超時重復(fù)調(diào)用同一個工具如果這個工具不是冪等的就可能產(chǎn)生重復(fù)訂單、重復(fù)扣費。做這類Agent時最好給關(guān)鍵工具增加冪等鍵機制同一任務(wù)的操作只允許執(zhí)行一次。這不是錦上添花而是保命用的。4.4 三種交互方式的組合實際產(chǎn)品里三種交互方式往往同時存在。一個成熟的AI助手很可能同時具備工具調(diào)用能力查天氣、建日程、知識檢索能力翻文檔找答案、系統(tǒng)操作能力幫你改配置。分類的意義在于搞清楚主從關(guān)系。我的建議是確定一個主導(dǎo)交互方式其他作為輔助。主導(dǎo)方式?jīng)Q定了核心架構(gòu)。如果主導(dǎo)是知識檢索那重心就在知識管線的質(zhì)量如果主導(dǎo)是工具調(diào)用那重心就在工具體系的穩(wěn)定和權(quán)限。把主導(dǎo)方式定下來團隊的開發(fā)重心、測試用例設(shè)計、監(jiān)控指標就都清晰了。5. 按功能定位內(nèi)容生產(chǎn)、數(shù)據(jù)分析、流程協(xié)同與對話服務(wù)5.1 內(nèi)容生產(chǎn)型Agent內(nèi)容生產(chǎn)型Agent的輸入和輸出都是內(nèi)容。這類Agent不負責(zé)決策業(yè)務(wù)邏輯不操作業(yè)務(wù)系統(tǒng)它的產(chǎn)物就是文字、代碼、圖片、音視頻。典型應(yīng)用包括文案生成Agent、代碼生成Agent、報告撰寫Agent。這類Agent的核心矛盾是“速度與質(zhì)量”。用大模型直接生成的內(nèi)容速度快但容易模板化要讓內(nèi)容真正可用必須加入大量后處理。以營銷文案為例我的做法是先生成多個候選版本再用一個評審Agent做質(zhì)量打分最后按分數(shù)篩出最佳同時還要加敏感詞、品牌詞合規(guī)校驗。內(nèi)容型Agent的評估方式也很直接主要看生成內(nèi)容的可用率而不是好不好看。如果10篇里能直接用的只有2篇那這個Agent在業(yè)務(wù)上沒有價值。5.2 數(shù)據(jù)分析型Agent數(shù)據(jù)分析型Agent的定位是幫助用戶從數(shù)據(jù)里拿到結(jié)論。它的工作模式一般是理解用戶的問題、生成查詢比如SQL、執(zhí)行查詢、解讀結(jié)果、輸出結(jié)論。典型應(yīng)用場景包括經(jīng)營日報Agent、數(shù)據(jù)問答Agent、異常指標歸因Agent。這里要區(qū)分兩種形態(tài)。一種是只做“查詢生成”模型負責(zé)寫SQL交給查詢引擎執(zhí)行結(jié)果直接給用戶另一種是“全鏈路解讀”模型不僅要查詢還要結(jié)合上下文業(yè)務(wù)知識做歸因分析比如“為什么昨日轉(zhuǎn)化率下降”。后者的技術(shù)難度高很多需要融合業(yè)務(wù)元數(shù)據(jù)、歷史基線數(shù)據(jù)和知識庫。實現(xiàn)數(shù)據(jù)分析型Agent時我最看重的是查詢準確性。這里的一個現(xiàn)實問題是模型生成的SQL經(jīng)常跑不通或者跑通了但結(jié)果偏離問題本意。建議先在測試庫上做SQL正確性驗證通過后再在生產(chǎn)庫執(zhí)行同時對用戶的模糊問題要做澄清比如“這個季度的銷售額”到底指的是訂單金額還是實收金額不澄清就瞎猜的結(jié)果一定不準。5.3 流程協(xié)同型Agent流程協(xié)同型Agent更像是一個“編排者”它不直接完成所有工作而是把不同的人和系統(tǒng)拉到一個流程里推動事情往前走。典型場景包括項目管理Agent、工單流轉(zhuǎn)Agent、跨部門協(xié)作Agent。這類Agent的設(shè)計核心是“狀態(tài)機”。一個流程的每個節(jié)點有明確的狀態(tài)待處理、處理中、已完成、已駁回。Agent的職責(zé)是根據(jù)當前狀態(tài)決定下一步動作可能調(diào)用模型可能在系統(tǒng)間同步數(shù)據(jù)可能通知對應(yīng)負責(zé)人。我之前踩過一個大坑就是沒有把狀態(tài)機設(shè)計清楚導(dǎo)致一個訂單卡在“已支付”和“待審核”兩個狀態(tài)里用戶支付了但系統(tǒng)遲遲不推進。后來每次做流程協(xié)同型Agent第一件事就是畫出狀態(tài)流轉(zhuǎn)圖用代碼嚴格約束每個狀態(tài)能發(fā)生什么動作。流程協(xié)同型Agent的評估指標也很特殊主要看“流轉(zhuǎn)有效率”也就是工單在Agent介入后平均處理時長下降了沒卡單率降低了沒。這類Agent根本不在于聰明不聰明而在于流程治理是否嚴密。5.4 對話服務(wù)型Agent對話服務(wù)型Agent是用戶感知最強的一類大家平時聊的客服Agent、銷售助手、閑聊伴侶都是這一類。它的核心特征是多輪對話、上下文管理、用戶意圖識別和情感識別。對話服務(wù)型Agent的技術(shù)重點和前幾類不一樣。第一多輪狀態(tài)管理用戶可能在第四輪才說出真實需求Agent要能結(jié)合前三輪的上下文理解不能每輪都當新對話處理第二上下文長度管理多輪對話累計的token增長很快需要做滑窗式摘要壓縮第三兜底策略用戶問了一個Agent無法回答的問題時怎么自然過渡而不讓對話死掉。我做過一個客服類型的Agent印象最深的教訓(xùn)是“過度承諾”。模型在對話里容易輸出“好的我已為您退費”這種話但實際上系統(tǒng)根本沒有執(zhí)行退費。這類問題的解決方案是對話服務(wù)型Agent的每一條承諾都必須綁定到具體的工具執(zhí)行結(jié)果上工具沒成功對話里就不能主動宣告成功。模型生成回復(fù)前要把“是否已執(zhí)行成功”作為關(guān)鍵信息注入提示詞。功能定位輸入輸出特征核心技術(shù)點主要評估指標內(nèi)容生產(chǎn)型內(nèi)容到內(nèi)容多版本生成、評審過濾內(nèi)容可用率數(shù)據(jù)分析型問題到結(jié)論查詢生成、歸因分析查詢準確率、結(jié)論正確率流程協(xié)同型狀態(tài)到動作狀態(tài)機、流程治理流轉(zhuǎn)有效率、卡單率對話服務(wù)型對話到對話多輪記憶、承諾控制任務(wù)完成率、用戶滿意度6. 實操選型一套可落地的分類決策方法前面講的都是分類維度現(xiàn)在說怎么落地。我把自己的選型過程整理成一套方法每次做新Agent都按這個順序走一遍。第一步明確任務(wù)目標。用一句話說清楚這個Agent要完成什么業(yè)務(wù)目標寫不出來就說明需求本身不清晰。第二步判斷任務(wù)粒度。這個任務(wù)能否在一個步驟內(nèi)完成如果可以直接走單任務(wù)執(zhí)行型如果不能畫一下子任務(wù)清單準備做復(fù)合規(guī)劃型。第三步分析決策確定性。問自己任務(wù)的每一步是否都有明確規(guī)定如果有走規(guī)則驅(qū)動如果完全沒有走模型驅(qū)動如果部分明確、部分開放走混合決策。大多數(shù)業(yè)務(wù)場景都落在混合決策上。第四步確定主導(dǎo)交互方式。任務(wù)是否需要調(diào)用外部工具是否需要訪問知識庫是否需要修改系統(tǒng)狀態(tài)按優(yōu)先級排一排序哪個是核心能力哪個就是主導(dǎo)交互方式。第五步歸類功能定位。任務(wù)的核心產(chǎn)物是內(nèi)容、結(jié)論、流程推進還是對話體驗功能定位決定了你的評估指標和驗收標準。第六步評估資源約束。算一下模型調(diào)用預(yù)算、響應(yīng)時間要求、權(quán)限邊界這些制約因素會反過來調(diào)整前面的分類決策。我拿一個“合同審查Agent”舉例。它的目標一句話是“自動檢查合同文本的風(fēng)險點并輸出審查意見”。任務(wù)粒度上它需要讀合同、抽條款、比對規(guī)則庫、輸出報告是復(fù)合任務(wù)決策機制上條款識別用模型風(fēng)險判定有明確的合規(guī)規(guī)則是混合決策交互方式上它需要檢索合同模板庫和法規(guī)庫主導(dǎo)是知識檢索加內(nèi)容生成功能定位上它產(chǎn)出的是審查報告屬于內(nèi)容生產(chǎn)型。經(jīng)過這一套分類架構(gòu)就非常清楚了一個單入口接收合同先做文本解析關(guān)鍵條款走檢索增強生成從規(guī)則庫召回匹配規(guī)則風(fēng)險判定部分走規(guī)則引擎過濾確定性條款最后模型輸出審查意見整個流程有節(jié)點回滾機制。這個Agent我實際搭過運行穩(wěn)定性和可維護性都比直接讓模型自由審查好太多。在做這套分類決策的時候要特別注意一點分類不是終點而是溝通工具。架構(gòu)師、開發(fā)者、業(yè)務(wù)方對齊需求時只要把分類維度和結(jié)論擺出來很多潛在的誤解在早期就能暴露。比如業(yè)務(wù)方說要“智能客服”技術(shù)方上來就設(shè)計了一堆花哨的對話策略但按分類方法一聊才發(fā)現(xiàn)業(yè)務(wù)方真正需要的是工單自動分類加知識庫應(yīng)答壓根不需要閑聊能力。這一下就省了三分之一的開發(fā)量。7. 常見誤區(qū)與排查技巧實錄做Agent項目久了遇到的典型問題其實高度重復(fù)。我整理幾個出現(xiàn)頻率最高的連同排查思路一起分享。7.1 所有Agent都做成大模型自由發(fā)揮這幾乎是新手團隊的通病。一提到AI Agent就認為必須讓大模型主導(dǎo)決策否則就不是Agent。真上了生產(chǎn)成本高、不穩(wěn)定、難排查然后回過頭來罵模型不行。排查思路很簡單如果某個環(huán)節(jié)有固定規(guī)則就把它從模型手里拿出來放進規(guī)則層。模型只負責(zé)那些規(guī)則覆蓋不到的部分。7.2 忽視工具接口穩(wěn)定性工具調(diào)用型Agent跑得好不好和模型的聰明程度關(guān)系沒有想象中那么大大部分時間取決于工具本身穩(wěn)不穩(wěn)。工具超時、參數(shù)格式?jīng)]對齊、接口返回結(jié)構(gòu)變化任何一個問題都會直接把Agent打掛。排查時要分清楚到底是模型選錯了工具還是工具本身出錯了。建議給每個工具加獨立的日志埋點記錄調(diào)用時間、入?yún)?、出參、錯誤碼這樣Agent出錯時能快速定位到是哪個環(huán)節(jié)。7.3 知識庫Agent不做效果評估很多人上RAG只顧著把文檔灌進去就完事完全不建評測集。等上線了用戶反饋答得差又開始逐條調(diào)整提示詞這屬于瞎貓碰死耗子。我的建議是知識庫Agent上線前至少準備50到100條真實用戶問題作為評測集每條標注參考答案和期望的回答來源。所有對管線或提示詞的改動都先跑一遍評測集拿指標說話再上線。7.4 沒有超時、重試和熔斷機制Agent是有外部依賴的復(fù)雜分布式系統(tǒng)模型的響應(yīng)時間本身就不穩(wěn)定。現(xiàn)實環(huán)境里模型服務(wù)可能晚了幾秒用戶的請求就被前端斷開了又或者工具服務(wù)臨時故障Agent沒有重試就直接放棄。排查這類問題一是所有外部調(diào)用都要設(shè)超時和重試二是關(guān)鍵下游連續(xù)失敗時要有熔斷路子別讓故障連續(xù)打爆整個流程三是所有Agent入口最好加一層服務(wù)質(zhì)量檢測任何一個節(jié)點長時間高錯誤率都要能自動觸發(fā)降級方案。7.5 權(quán)限與安全邊界收緊不夠系統(tǒng)操作型Agent的權(quán)限如果設(shè)計不好后果要比普通程序嚴重得多。因為模型可能被用戶的提示詞誘導(dǎo)去調(diào)用不該調(diào)用的工具。這里的原則是用“最小權(quán)限”約束Agent模型能看到和調(diào)用的工具集在全流程中動態(tài)收窄。比如用戶問“幫我查一下訂單”Agent只需要查詢權(quán)限那寫操作類工具在這個上下文里就不應(yīng)該出現(xiàn)在工具清單里。動態(tài)工具過濾是成本最低、效果最好的安全策略。另外補一個排查技巧Agent類系統(tǒng)的日志記錄要比普通系統(tǒng)更詳細。因為模型決策的中間過程不可復(fù)現(xiàn)所以必須把每一輪的模型輸入、輸出、工具調(diào)用結(jié)果、token消耗全部記錄在案。出了問題回放日志就能看到模型當時的決策路徑快速定位是提示詞問題還是狀態(tài)傳遞問題。這個習(xí)慣在排查復(fù)合規(guī)劃型Agent時尤其重要否則模型跑偏了你連怎么偏的都看不到。8. 實操總結(jié)與個人體會我自己做功能型Agent的感受一句話總結(jié)就是好的分類勝過好的框架。很多人關(guān)心選哪個框架、用哪個模型但真正決定項目成敗的是你有沒有在動手前想清楚這六個維度——任務(wù)粒度、決策機制、交互方式、功能定位、資源約束和評估指標。框架只是工具分類才是方向。另一個體會是分類不是一成不變的。同一個Agent隨著業(yè)務(wù)演化會從單任務(wù)變成復(fù)合任務(wù)從規(guī)則驅(qū)動變成混合決策。比如最初我只做了一個簡單的合同條款識別單步Agent后來業(yè)務(wù)方要求加上風(fēng)險歸因分析這個Agent就自然演變成了復(fù)合規(guī)劃型。所以分類決策不是一次性的每階段迭代都要重新過一遍這套分類方法。最后一句話給新入門的朋友別急著寫代碼先拿一張紙把分類表的四個維度填一遍。填完你就知道該用什么架構(gòu)、該買什么服務(wù)、該找什么資源了。分類這件事花半小時做可能給你省下后面一個月的重構(gòu)時間。