大模型跑得再聰明落到實(shí)際業(yè)務(wù)里也經(jīng)常讓人抓狂你問(wèn)它“幫我查一下深圳明天會(huì)不會(huì)下雨”它給你回一段“根據(jù)氣象數(shù)據(jù)深圳明天有雨”但并沒(méi)有真的去調(diào)用任何天氣接口。問(wèn)題出在哪出在智能體缺少一條“夠得著外部世界”的鏈路。我最近在做的一個(gè)項(xiàng)目代號(hào)叫 Agent-Reach核心就是解決這件事——讓大模型從“會(huì)說(shuō)話”進(jìn)化為“會(huì)辦事”真正觸達(dá)工具、接口、數(shù)據(jù)庫(kù)和業(yè)務(wù)系統(tǒng)。這篇文章是我對(duì)這套方案的完整復(fù)盤(pán)從架構(gòu)設(shè)計(jì)到工具注冊(cè)從權(quán)限管控到死循環(huán)排查盡量把每個(gè)“為什么這么做”都講透適合正在做Agent應(yīng)用開(kāi)發(fā)、接入MCP工具鏈或者被“大模型只會(huì)聊不會(huì)做”困擾的團(tuán)隊(duì)參考。1. Agent-Reach整體設(shè)計(jì)與思路拆解1.1 為什么智能體需要一套“Reach”能力先打個(gè)比方。一個(gè)剛從名校畢業(yè)的分析師腦子再靈、口才再好如果工位上沒(méi)有電腦、沒(méi)有電話、沒(méi)有數(shù)據(jù)終端他很難產(chǎn)出真正的商業(yè)決策頂多給你寫(xiě)一篇小作文。大模型就是這個(gè)分析師Reach能力就是它桌面上的那臺(tái)連了網(wǎng)的電腦和電話線。我最早做Agent demo的時(shí)候犯過(guò)一個(gè)特別典型的錯(cuò)誤模型選的是當(dāng)時(shí)能力最強(qiáng)的商用款Prompt也打磨得自認(rèn)為完美結(jié)果發(fā)現(xiàn)它在大部分真實(shí)任務(wù)上都是“口嗨”——用戶問(wèn)完它它給出一大段“理論正確”的話但沒(méi)有任何一個(gè)動(dòng)作發(fā)生。原因很簡(jiǎn)單模型只是一個(gè)在概率空間里生成文本的系統(tǒng)它不知道你系統(tǒng)里有沒(méi)有“查詢訂單”這個(gè)函數(shù)也不知道該用哪個(gè)字段去調(diào)用它。而Agent-Reach項(xiàng)目做的就是把“模型知道該做什么”和“系統(tǒng)真正執(zhí)行了”之間的斷裂補(bǔ)上。這個(gè)斷裂在技術(shù)圈有個(gè)專(zhuān)門(mén)的詞叫“行動(dòng)力缺口”。主要表現(xiàn)有三個(gè)層面模型沒(méi)有感知到外部工具的邊界和入口。即使感知到了也不知道工具需要的參數(shù)格式。即使格式對(duì)了也沒(méi)有一套安全可靠的執(zhí)行機(jī)制去跑這個(gè)工具。所以Agent-Reach并不是某一個(gè)模型也不是某一個(gè)工具而是一整套“能力延伸層”。它是夾在LLM推理引擎和外部系統(tǒng)之間的中間層負(fù)責(zé)工具發(fā)現(xiàn)、參數(shù)校驗(yàn)、動(dòng)作執(zhí)行、結(jié)果回傳。一句話總結(jié)Reach決定智能體的能力邊界模型智商決定它的決策質(zhì)量?jī)烧呷币徊豢伞?.2 方案選型為什么選了“模型決策工具執(zhí)行”的模式目前讓模型“觸達(dá)外部世界”主流有三種路線。我把它們放在一起對(duì)比過(guò)各有各的合適場(chǎng)景第一種是端到端微調(diào)路線。直接拿業(yè)務(wù)數(shù)據(jù)去微調(diào)模型讓模型在訓(xùn)練階段就把工具調(diào)用“學(xué)會(huì)”。好處是推理快不用在運(yùn)行時(shí)反復(fù)解析工具描述壞處是每加一個(gè)新工具就得重新訓(xùn)練一輪成本高得離譜而且很多平臺(tái)上你根本碰不到模型權(quán)重。第二種是固定流程編排路線。用DAG有向無(wú)環(huán)圖把節(jié)點(diǎn)和跳轉(zhuǎn)條件寫(xiě)死模型只能按圖行走。這種方案穩(wěn)定性極高但靈活性基本為零——用戶的問(wèn)法稍微變化一下流程就斷了。第三種是ReAct式的模型動(dòng)態(tài)決策路線。模型每輪根據(jù)“系統(tǒng)里有哪些可用工具、每個(gè)工具需要什么參數(shù)、歷史對(duì)話里已經(jīng)發(fā)生了什么”來(lái)決定要不要調(diào)用工具、調(diào)用哪個(gè)、傳什么參數(shù)。Agent-Reach采用的就是這個(gè)思路。ReAct模式之所以成為我的首選核心原因是擴(kuò)展成本和靈活性性價(jià)比最好。每加一個(gè)新能力只需要往注冊(cè)中心塞一個(gè)新的工具描述文件不需要改模型、不需要重新訓(xùn)練。工具描述寫(xiě)得越好模型就越容易“發(fā)現(xiàn)”它。這本質(zhì)上是一種面向模型的API文檔優(yōu)化工作比煉丹改權(quán)重輕量太多了。1.3 Agent-Reach的模塊架構(gòu)總覽整個(gè)Agent-Reach系統(tǒng)我拆成了六個(gè)模塊它們各管一段職責(zé)不重疊交互入口層負(fù)責(zé)接收用戶消息維護(hù)會(huì)話上下文統(tǒng)一處理流式輸出。決策編排層核心是ReAct循環(huán)維護(hù)“思考→行動(dòng)→觀察”的循環(huán)狀態(tài)機(jī)。工具注冊(cè)中心維護(hù)一份“工具能力清單”每個(gè)工具都有名字、描述、參數(shù)Schema和API Endpoint。參數(shù)校驗(yàn)?zāi)K在工具被調(diào)用前先按JSON Schema校驗(yàn)?zāi)Ｐ蜕傻膮?shù)是否合法。執(zhí)行沙箱層真正去調(diào)用外部API、讀取數(shù)據(jù)庫(kù)、操作文件系統(tǒng)的位置所有網(wǎng)絡(luò)請(qǐng)求都從這里發(fā)出統(tǒng)一處理鑒權(quán)、超時(shí)和錯(cuò)誤映射。觀測(cè)審計(jì)模塊記錄每一輪的工具調(diào)用日志、token消耗和錯(cuò)誤原因用于調(diào)試和安全審計(jì)。這六層構(gòu)成了一個(gè)完整的閉環(huán)。用戶說(shuō)一句話從進(jìn)入系統(tǒng)到最后收到回復(fù)中間可能經(jīng)歷多次工具調(diào)用但用戶是無(wú)感的。我在部署這套架構(gòu)時(shí)還有一個(gè)心得模塊拆分寧可細(xì)一點(diǎn)也別圖省事揉在一起。因?yàn)锳gent鏈條上出問(wèn)題排查天然比傳統(tǒng)后端復(fù)雜模塊邊界越清晰定位問(wèn)題越快。2. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)2.1 工具描述的質(zhì)量決定模型會(huì)不會(huì)用這是Agent-Reach項(xiàng)目里我收獲最大的一個(gè)教訓(xùn)。一開(kāi)始我以為工具描述隨便寫(xiě)寫(xiě)就行結(jié)果模型就是“看不見(jiàn)”那些工具要么不調(diào)用要么亂調(diào)用。后來(lái)我把工具描述改成了“面向API的說(shuō)明書(shū)”寫(xiě)法調(diào)用準(zhǔn)確率直接翻了一倍多。一個(gè)合格的工具描述必須包含五個(gè)要素工具名稱(chēng)英文短橫線風(fēng)格、一句話用途說(shuō)明必須包含觸發(fā)場(chǎng)景和業(yè)務(wù)關(guān)鍵詞、參數(shù)定義JSON Schema、返回結(jié)果說(shuō)明、錯(cuò)誤碼說(shuō)明。這五個(gè)缺哪個(gè)模型都可能產(chǎn)生幻覺(jué)參數(shù)或者直接放棄調(diào)用。拿查詢天氣工具舉例我第一次寫(xiě)的是{ name: get_weather, description: 獲取天氣信息, parameters: { type: object, properties: { city: { type: string } } } }模型經(jīng)常不知道city該傳中文還是拼音也不知道返回什么樣的數(shù)據(jù)。后來(lái)我改成{ name: get_weather_info, description: 根據(jù)城市名查詢指定日期天氣。僅當(dāng)用戶詢問(wèn)未來(lái)7天內(nèi)某個(gè)城市的天氣、溫度、降雨概率、風(fēng)力等級(jí)時(shí)使用。城市名需要轉(zhuǎn)換為標(biāo)準(zhǔn)中文城市名例如深圳、廣州。日期格式為YYYY-MM-DD如未指定日期則默認(rèn)今天。, parameters: { type: object, properties: { city: { type: string, description: 標(biāo)準(zhǔn)中文城市名如深圳 }, date: { type: string, description: 查詢?nèi)掌诟袷結(jié)YYY-MM-DD } }, required: [city] } }效果天差地別。核心邏輯在于大模型沒(méi)有“常識(shí)”知道你的城市字段應(yīng)該傳什么格式你描述得越具體模型輸出的參數(shù)就越規(guī)范。這個(gè)細(xì)節(jié)放在任何Agent項(xiàng)目里都通用——工具描述的本質(zhì)是給模型看的API文檔。2.2 工具注冊(cè)中心的版本管理與下架策略隨著接入的工具數(shù)量增長(zhǎng)注冊(cè)中心會(huì)從一道開(kāi)胃菜變成一頭大象。我遇到過(guò)兩個(gè)具體問(wèn)題一是同名工具不同版本導(dǎo)致路由錯(cuò)亂二是下架了某個(gè)工具但舊會(huì)話仍在引用它導(dǎo)致模型反復(fù)嘗試無(wú)效調(diào)用。Agent-Reach的方案是給每個(gè)工具加元數(shù)據(jù)頭版本字段v1、v2每次接口結(jié)構(gòu)變化必須升版本。狀態(tài)字段active可用、deprecated已棄用、removed已下架。生效時(shí)間與失效時(shí)間用于灰度切換和定時(shí)下架?？捎铆h(huán)境標(biāo)簽區(qū)分測(cè)試環(huán)境和生產(chǎn)環(huán)境避免測(cè)試工具誤傷線上數(shù)據(jù)。工具注冊(cè)中心本質(zhì)上是一個(gè)服務(wù)目錄。模型每一輪決策前都會(huì)拉取一次“當(dāng)前可用的工具列表”所以工具的上下線和版本變更在代碼上不會(huì)引入額外復(fù)雜度只要保證接口返回當(dāng)前的快照即可。2.3 參數(shù)校驗(yàn)別信模型也別不信模型我遇到過(guò)的真實(shí)場(chǎng)景模型把日期傳成“明天”把城市傳成“shenzhen”把金額字段填成“未知”五花八門(mén)。所以參數(shù)校驗(yàn)必須用“可信執(zhí)行容錯(cuò)修正”的雙層策略。第一層是嚴(yán)格Schema校驗(yàn)。用jsonschema庫(kù)或者Pydantic強(qiáng)校驗(yàn)類(lèi)型不對(duì)就拒絕。第二層是容錯(cuò)修正模塊。這一步容易被忽略但對(duì)用戶體驗(yàn)影響非常大當(dāng)日期的值是“明天”這種相對(duì)詞時(shí)寫(xiě)一個(gè)小的解析函數(shù)把它換算成具體日期當(dāng)城市名是拼音時(shí)用一個(gè)映射表轉(zhuǎn)成中文。這兩個(gè)邏輯看起來(lái)只是“小聰明”但在實(shí)際業(yè)務(wù)里能省掉大量用戶重新輸入的麻煩。有一點(diǎn)要特別注意不要把容錯(cuò)規(guī)則寫(xiě)進(jìn)主流程要作為旁路修正器。因?yàn)槿蒎e(cuò)規(guī)則本質(zhì)上是不確定的如果混進(jìn)主流程一旦誤判會(huì)波及所有請(qǐng)求。獨(dú)立成模塊、獨(dú)立加日志方便逐步優(yōu)化和灰度放量。2.4 執(zhí)行沙箱與權(quán)限邊界設(shè)計(jì)工具調(diào)用Agent里面最容易翻車(chē)的不是AI能力不足而是權(quán)限管得太松。我在Agent-Reach早期版本里讓Agent直接持有數(shù)據(jù)庫(kù)的管理員連接串結(jié)果它在一次測(cè)試中對(duì)線上一個(gè)表執(zhí)行了全量更新。那次事故讓我定下了一條鐵律Agent訪問(wèn)外部系統(tǒng)必須使用專(zhuān)門(mén)的、最小權(quán)限的、可審計(jì)的服務(wù)賬號(hào)。具體操作上有幾點(diǎn)實(shí)操建議網(wǎng)絡(luò)隔離Agent執(zhí)行環(huán)境單獨(dú)劃分網(wǎng)段出網(wǎng)請(qǐng)求只能訪問(wèn)白名單域名和端口。憑證隔離不在Agent進(jìn)程里放數(shù)據(jù)庫(kù)賬號(hào)或云廠商AK/SK改成在執(zhí)行沙箱層統(tǒng)一注入。操作分級(jí)讀操作直接執(zhí)行寫(xiě)操作和刪除操作默認(rèn)加人工確認(rèn)。敏感系統(tǒng)熔斷現(xiàn)金類(lèi)、通知類(lèi)、批量類(lèi)接口每個(gè)用戶每天有調(diào)用上限。這套權(quán)限設(shè)計(jì)本質(zhì)上就是在“讓Agent靈活干活”和“防止Agent闖禍”之間找一個(gè)平衡點(diǎn)。我的建議就一句話剛上線的時(shí)候權(quán)限寧可收得比設(shè)計(jì)得更緊也別一開(kāi)始就全部放開(kāi)。出一次事故的代價(jià)足以抵掉幾個(gè)月的人工確認(rèn)成本。3. 實(shí)操過(guò)程與核心環(huán)節(jié)實(shí)現(xiàn)3.1 快速搭一個(gè)最小的Agent-Reach循環(huán)我不太建議直接一上來(lái)就上重型框架先把最小的ReAct循環(huán)跑通后面加工具、加權(quán)限都水到渠成。我用Python寫(xiě)了一個(gè)精簡(jiǎn)版核心依賴只有兩個(gè)一個(gè)openai客戶端、一個(gè)requests庫(kù)。主循環(huán)邏輯如下def agent_run(user_input, messages, tools): # 第一步把用戶消息和可用的工具列表一起發(fā)給模型 messages.append({role: user, content: user_input}) response llm.chat(messagesmessages, toolstools, tool_choiceauto) msg response.choices[0].message messages.append(msg) # 第二步如果模型決定調(diào)用工具 while msg.tool_calls: for tool_call in msg.tool_calls: func_name tool_call.function.name args json.loads(tool_call.function.arguments) result execute_tool(func_name, args) messages.append({ role: tool, tool_call_id: tool_call.id, content: json.dumps(result, ensure_asciiFalse) }) # 第三步把工具結(jié)果回傳給模型由模型生成最終回復(fù) response llm.chat(messagesmessages, toolstools, tool_choiceauto) msg response.choices[0].message messages.append(msg) return msg.content這段代碼看起來(lái)簡(jiǎn)單但已經(jīng)包含了一個(gè)Agent的核心骨架模型提出工具調(diào)用請(qǐng)求→系統(tǒng)執(zhí)行→把執(zhí)行結(jié)果回填→模型繼續(xù)決策直到模型認(rèn)為不需要再調(diào)用工具為止。我在實(shí)際項(xiàng)目中就是把這段主循環(huán)外加狀態(tài)持久化、超時(shí)控制、日志埋點(diǎn)就能支撐大部分業(yè)務(wù)場(chǎng)景。3.2 工具注冊(cè)與參數(shù)校驗(yàn)的具體示例工具注冊(cè)我用的是Python的裝飾器風(fēng)格上手成本低團(tuán)隊(duì)小伙伴也容易看懂register_tool( namequery_order_status, description根據(jù)訂單號(hào)查詢訂單當(dāng)前狀態(tài)。僅當(dāng)用戶詢問(wèn)訂單是否發(fā)貨、簽收、退款進(jìn)度時(shí)使用。訂單號(hào)為純數(shù)字。, versionv1, ) def query_order_status(order_id: str) - dict: # 內(nèi)部調(diào)用訂單中心HTTP接口 resp http_client.get(f{ORDER_SERVICE}/v1/orders/{order_id}) return resp.json()啟動(dòng)的時(shí)候注冊(cè)中心會(huì)自動(dòng)掃描所有帶register_tool裝飾器的函數(shù)生成一份工具清單供模型調(diào)用。參數(shù)校驗(yàn)我放在execute_tool里統(tǒng)一做def execute_tool(name, args): tool registry.get(name) errors schema_validator.validate(args, tool.parameters_schema) if errors: return {error: 參數(shù)校驗(yàn)失敗, details: errors} corrected_args autocorrect_args(args, tool) return tool.func(**corrected_args)autocorrect_args就是前面提到的容錯(cuò)修正器。注意這里return的錯(cuò)誤信息會(huì)作為tool結(jié)果回傳給模型模型看到報(bào)錯(cuò)之后通常會(huì)自動(dòng)修正參數(shù)重試。這比直接拋異常讓整個(gè)流程中斷要友好得多。3.3 實(shí)際運(yùn)行效果實(shí)錄我用一個(gè)“查訂單并翻譯為英文”的對(duì)話來(lái)演示整個(gè)Agent-Reach的運(yùn)轉(zhuǎn)軌跡用戶輸入“幫我看看訂單12345678到哪了順便把結(jié)果翻譯成英文?！蹦Ｐ蜎Q策記錄思考用戶需要查詢訂單狀態(tài)并且把結(jié)果翻譯成英文。先調(diào)用query_order_status獲取訂單信息。 行動(dòng)query_order_status({order_id: 12345678}) 觀察{order_id: 12345678, status: shipped, eta: 2025-06-01} 思考訂單已發(fā)貨預(yù)計(jì)6月1日送達(dá)。現(xiàn)在需要用英文回復(fù)用戶。 行動(dòng)無(wú) 最終回答Your order has been shipped and is expected to arrive by June 1, 2025.這個(gè)例子雖然簡(jiǎn)單但把Agent的關(guān)鍵行為展示得很完整模型能發(fā)現(xiàn)工具、傳入合法參數(shù)、觀察執(zhí)行結(jié)果、決定是否繼續(xù)調(diào)用。整套流程跑下來(lái)用戶只感知到一次對(duì)話背后卻可能發(fā)生了多次循環(huán)推理。3.4 部署與穩(wěn)定性配置要點(diǎn)代碼寫(xiě)好后部署階段還有很多隱蔽的坑。以下是我反復(fù)踩過(guò)之后總結(jié)出的部署配置清單超時(shí)設(shè)置單次工具調(diào)用默認(rèn)超時(shí)3秒LLM調(diào)用超時(shí)30秒整個(gè)Agent循環(huán)最長(zhǎng)60秒。寧可超時(shí)中斷也不要無(wú)限等下去。并發(fā)控制所有工具調(diào)用走異步Asyncio防止IO阻塞拖死進(jìn)程。同時(shí)限制單會(huì)話并發(fā)調(diào)用數(shù)不超過(guò)5。流式輸出模型決策階段適合用流式輸出把“思考中”的狀態(tài)透給用戶否則用戶等超過(guò)3秒就會(huì)疑心系統(tǒng)卡死。持久化會(huì)話每次循環(huán)后的完整消息列表要落庫(kù)不然后端進(jìn)程重啟用戶后續(xù)消息會(huì)因?yàn)闆](méi)有上下文而讓Agent“失憶”。可觀測(cè)性埋點(diǎn)每一輪工具調(diào)用都要記錄tool名稱(chēng)、入?yún)?、出參、耗時(shí)、token數(shù)。這是排查Agent問(wèn)題最依賴的數(shù)據(jù)。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄4.1 模型就是不調(diào)用工具怎么排查這是剛開(kāi)始接入Agent-Reach時(shí)出現(xiàn)頻率最高的問(wèn)題。現(xiàn)象是模型回答得挺好但就是不產(chǎn)生tool_calls。排查順序按以下三步來(lái)第一步查工具描述是否被模型“看見(jiàn)”。在后臺(tái)日志里看每次請(qǐng)求的tool列表如果工具根本沒(méi)出現(xiàn)在請(qǐng)求的tools字段里那就是注冊(cè)中心或路由的問(wèn)題。第二步查工具描述是否足夠明確。常見(jiàn)病是工具描述寫(xiě)得像“給人類(lèi)看的產(chǎn)品說(shuō)明”而不是“給模型看的調(diào)用條件”。比如“獲取天氣”這種描述模型不知道什么時(shí)候該用。要改成“當(dāng)用戶詢問(wèn)天氣情況、溫度、降雨概率時(shí)使用該工具”。第三步查模型版本的tool calling能力。部分輕量級(jí)模型對(duì)結(jié)構(gòu)化輸出的支持較弱表現(xiàn)為參數(shù)嚴(yán)重缺省或頻繁空轉(zhuǎn)。如果業(yè)務(wù)對(duì)準(zhǔn)確率要求高商用模型始終是更穩(wěn)的選擇。4.2 模型生成了非法JSON怎么處理偶發(fā)性地模型會(huì)生成不合法JSON比如多了尾逗號(hào)、單引號(hào)、注釋等。我的處理方案分為兩個(gè)層次先做一層“寬容JSON解析”把常見(jiàn)的格式錯(cuò)誤修掉修不掉的情況下把錯(cuò)誤信息作為tool結(jié)果回傳給模型讓模型自己重寫(xiě)參數(shù)。實(shí)測(cè)這兩步配合非法JSON的概率能降到1%以下。需要注意的是不要在不合法JSON出現(xiàn)時(shí)直接拋異常結(jié)束會(huì)話。因?yàn)锳gent的價(jià)值就在于自糾錯(cuò)能力它有時(shí)比直接失敗重試更聰明。4.3 工具調(diào)用死循環(huán)怎么中斷我曾經(jīng)遇到過(guò)一次模型反復(fù)調(diào)用同一個(gè)工具的情況它查了一遍庫(kù)存發(fā)現(xiàn)庫(kù)存不足又查一遍供應(yīng)商庫(kù)存還是不足又回頭查訂單……最后token燒了一大半。核心原因是循環(huán)里沒(méi)有退出條件。Agent-Reach的解決方案是給主循環(huán)加三重保險(xiǎn)單次任務(wù)允許最大工具調(diào)用次數(shù)我默認(rèn)設(shè)10次如果連續(xù)三輪調(diào)用同一個(gè)工具且入?yún)⒉蛔冎苯又袛嗖⑻崾居脩簟肮ぞ邎?zhí)行結(jié)果為空或錯(cuò)誤”時(shí)模型必須切換到其他策略不能原地重試。這三重保險(xiǎn)做下來(lái)死循環(huán)再?zèng)]出現(xiàn)過(guò)。4.4 權(quán)限過(guò)寬導(dǎo)致的誤操作與審計(jì)最后說(shuō)一個(gè)管理層面的問(wèn)題權(quán)限過(guò)寬通常不是技術(shù)缺陷而是工程規(guī)范缺失。Agent日志里必須完整記錄“誰(shuí)在什么時(shí)間調(diào)用了什么工具、傳了什么參數(shù)、返回了什么結(jié)果”哪怕只是內(nèi)部測(cè)試環(huán)境。我在Agent-Reach項(xiàng)目中做了一個(gè)很簡(jiǎn)單的權(quán)限矩陣配置用一張表維護(hù)每個(gè)工具對(duì)不同角色的可用性。如下工具名用戶側(cè)調(diào)用管理員側(cè)調(diào)用說(shuō)明query_order_status允許允許只讀無(wú)害update_order_address需要確認(rèn)允許寫(xiě)操作cancel_order禁止需要雙重確認(rèn)高影響操作batch_import_products禁止禁止改走專(zhuān)門(mén)后臺(tái)這張表看起來(lái)樸素但它給團(tuán)隊(duì)提供了很清晰的“什么能跑什么不能跑”的共識(shí)。權(quán)限模型寧可一開(kāi)始粗糙但覆蓋全面也不要精雕細(xì)琢卻漏掉關(guān)鍵路徑。4.5 排查工具失效時(shí)“日志優(yōu)先”心態(tài)最后分享一個(gè)工作習(xí)慣。Agent系統(tǒng)排查問(wèn)題最大的敵人是“猜”。很多時(shí)候模型不調(diào)用工具、參數(shù)報(bào)錯(cuò)、執(zhí)行超時(shí)表象都非常相似。我的做法是遇到任何異常先翻工具調(diào)用日志確認(rèn)是模型決策問(wèn)題還是后端執(zhí)行問(wèn)題再?zèng)Q定改Prompt還是改代碼。如果發(fā)現(xiàn)模型決策問(wèn)題優(yōu)先改工具描述如果發(fā)現(xiàn)參數(shù)校驗(yàn)問(wèn)題優(yōu)先改Schema或容錯(cuò)解析如果發(fā)現(xiàn)執(zhí)行超時(shí)優(yōu)先查后端接口耗時(shí)而不是責(zé)怪模型。這樣排查方向清晰效率也高得多。5. 寫(xiě)在最后的一些實(shí)在建議Agent-Reach這個(gè)項(xiàng)目做下來(lái)我最大的感受是智能體的上限不取決于模型有多聰明而取決于它“手里握著多少條可靠的鏈路”。你把工具注冊(cè)做好、參數(shù)校驗(yàn)做嚴(yán)、權(quán)限邊界畫(huà)清一個(gè)中型模型也能穩(wěn)定處理復(fù)雜的多步驟任務(wù)反過(guò)來(lái)工具描述一團(tuán)糟、權(quán)限放太開(kāi)再?gòu)?qiáng)的模型也只會(huì)給你惹禍。如果你也想從零搭一套Agent能力延伸層我的建議是不要急著追求大而全的框架先把“一個(gè)用戶問(wèn)題→觸發(fā)一次工具調(diào)用→返回可驗(yàn)證結(jié)果”的最小閉環(huán)跑通然后逐步加工具、加權(quán)限、加觀測(cè)。第一批工具控制在10個(gè)以內(nèi)覆蓋業(yè)務(wù)中最高頻的讀寫(xiě)場(chǎng)景就夠了。最后送大家一個(gè)我在實(shí)際項(xiàng)目中驗(yàn)證過(guò)的小技巧每加一個(gè)新工具都去找兩三個(gè)真實(shí)用戶問(wèn)法測(cè)試而不是只看工具描述文件本身。工具描述寫(xiě)得再好模型“發(fā)現(xiàn)不了”就等于不存在。測(cè)試通過(guò)后把用戶問(wèn)法沉淀成回歸用例——這套用例會(huì)成為你這個(gè)Agent項(xiàng)目未來(lái)最有價(jià)值的資產(chǎn)之一。