大模型跑得再聰明落到實(shí)際業(yè)務(wù)里也經(jīng)常讓人抓狂你問它“幫我查一下深圳明天會(huì)不會(huì)下雨”它給你回一段“根據(jù)氣象數(shù)據(jù)深圳明天有雨”但并沒有真的去調(diào)用任何天氣接口。問題出在哪出在智能體缺少一條“夠得著外部世界”的鏈路。我最近在做的一個(gè)項(xiàng)目代號(hào)叫 Agent-Reach核心就是解決這件事——讓大模型從“會(huì)說話”進(jìn)化為“會(huì)辦事”真正觸達(dá)工具、接口、數(shù)據(jù)庫和業(yè)務(wù)系統(tǒng)。這篇文章是我對(duì)這套方案的完整復(fù)盤從架構(gòu)設(shè)計(jì)到工具注冊(cè)從權(quán)限管控到死循環(huán)排查盡量把每個(gè)“為什么這么做”都講透適合正在做Agent應(yīng)用開發(fā)、接入MCP工具鏈或者被“大模型只會(huì)聊不會(huì)做”困擾的團(tuán)隊(duì)參考。1. Agent-Reach整體設(shè)計(jì)與思路拆解1.1 為什么智能體需要一套“Reach”能力先打個(gè)比方。一個(gè)剛從名校畢業(yè)的分析師腦子再靈、口才再好如果工位上沒有電腦、沒有電話、沒有數(shù)據(jù)終端他很難產(chǎn)出真正的商業(yè)決策頂多給你寫一篇小作文。大模型就是這個(gè)分析師Reach能力就是它桌面上的那臺(tái)連了網(wǎng)的電腦和電話線。我最早做Agent demo的時(shí)候犯過一個(gè)特別典型的錯(cuò)誤模型選的是當(dāng)時(shí)能力最強(qiáng)的商用款Prompt也打磨得自認(rèn)為完美結(jié)果發(fā)現(xiàn)它在大部分真實(shí)任務(wù)上都是“口嗨”——用戶問完它它給出一大段“理論正確”的話但沒有任何一個(gè)動(dòng)作發(fā)生。原因很簡(jiǎn)單模型只是一個(gè)在概率空間里生成文本的系統(tǒng)它不知道你系統(tǒng)里有沒有“查詢訂單”這個(gè)函數(shù)也不知道該用哪個(gè)字段去調(diào)用它。而Agent-Reach項(xiàng)目做的就是把“模型知道該做什么”和“系統(tǒng)真正執(zhí)行了”之間的斷裂補(bǔ)上。這個(gè)斷裂在技術(shù)圈有個(gè)專門的詞叫“行動(dòng)力缺口”。主要表現(xiàn)有三個(gè)層面模型沒有感知到外部工具的邊界和入口。即使感知到了也不知道工具需要的參數(shù)格式。即使格式對(duì)了也沒有一套安全可靠的執(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ì)比過各有各的合適場(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有向無環(huán)圖把節(jié)點(diǎn)和跳轉(zhuǎn)條件寫死模型只能按圖行走。這種方案穩(wěn)定性極高但靈活性基本為零——用戶的問法稍微變化一下流程就斷了。第三種是ReAct式的模型動(dòng)態(tài)決策路線。模型每輪根據(jù)“系統(tǒng)里有哪些可用工具、每個(gè)工具需要什么參數(shù)、歷史對(duì)話里已經(jīng)發(fā)生了什么”來決定要不要調(diào)用工具、調(diào)用哪個(gè)、傳什么參數(shù)。Agent-Reach采用的就是這個(gè)思路。ReAct模式之所以成為我的首選核心原因是擴(kuò)展成本和靈活性性價(jià)比最好。每加一個(gè)新能力只需要往注冊(cè)中心塞一個(gè)新的工具描述文件不需要改模型、不需要重新訓(xùn)練。工具描述寫得越好模型就越容易“發(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ù)庫、操作文件系統(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)。用戶說一句話從進(jìn)入系統(tǒng)到最后收到回復(fù)中間可能經(jīng)歷多次工具調(diào)用但用戶是無感的。我在部署這套架構(gòu)時(shí)還有一個(gè)心得模塊拆分寧可細(xì)一點(diǎn)也別圖省事揉在一起。因?yàn)锳gent鏈條上出問題排查天然比傳統(tǒng)后端復(fù)雜模塊邊界越清晰定位問題越快。2. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)2.1 工具描述的質(zhì)量決定模型會(huì)不會(huì)用這是Agent-Reach項(xiàng)目里我收獲最大的一個(gè)教訓(xùn)。一開始我以為工具描述隨便寫寫就行結(jié)果模型就是“看不見”那些工具要么不調(diào)用要么亂調(diào)用。后來我把工具描述改成了“面向API的說明書”寫法調(diào)用準(zhǔn)確率直接翻了一倍多。一個(gè)合格的工具描述必須包含五個(gè)要素工具名稱英文短橫線風(fēng)格、一句話用途說明必須包含觸發(fā)場(chǎng)景和業(yè)務(wù)關(guān)鍵詞、參數(shù)定義JSON Schema、返回結(jié)果說明、錯(cuò)誤碼說明。這五個(gè)缺哪個(gè)模型都可能產(chǎn)生幻覺參數(shù)或者直接放棄調(diào)用。拿查詢天氣工具舉例我第一次寫的是{ name: get_weather, description: 獲取天氣信息, parameters: { type: object, properties: { city: { type: string } } } }模型經(jīng)常不知道city該傳中文還是拼音也不知道返回什么樣的數(shù)據(jù)。后來我改成{ name: get_weather_info, description: 根據(jù)城市名查詢指定日期天氣。僅當(dāng)用戶詢問未來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] } }效果天差地別。核心邏輯在于大模型沒有“常識(shí)”知道你的城市字段應(yīng)該傳什么格式你描述得越具體模型輸出的參數(shù)就越規(guī)范。這個(gè)細(xì)節(jié)放在任何Agent項(xiàng)目里都通用——工具描述的本質(zhì)是給模型看的API文檔。2.2 工具注冊(cè)中心的版本管理與下架策略隨著接入的工具數(shù)量增長(zhǎng)注冊(cè)中心會(huì)從一道開胃菜變成一頭大象。我遇到過兩個(gè)具體問題一是同名工具不同版本導(dǎo)致路由錯(cuò)亂二是下架了某個(gè)工具但舊會(huì)話仍在引用它導(dǎo)致模型反復(fù)嘗試無效調(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)別信模型也別不信模型我遇到過的真實(shí)場(chǎng)景模型把日期傳成“明天”把城市傳成“shenzhen”把金額字段填成“未知”五花八門。所以參數(shù)校驗(yàn)必須用“可信執(zhí)行容錯(cuò)修正”的雙層策略。第一層是嚴(yán)格Schema校驗(yàn)。用jsonschema庫或者Pydantic強(qiáng)校驗(yàn)類型不對(duì)就拒絕。第二層是容錯(cuò)修正模塊。這一步容易被忽略但對(duì)用戶體驗(yàn)影響非常大當(dāng)日期的值是“明天”這種相對(duì)詞時(shí)寫一個(gè)小的解析函數(shù)把它換算成具體日期當(dāng)城市名是拼音時(shí)用一個(gè)映射表轉(zhuǎn)成中文。這兩個(gè)邏輯看起來只是“小聰明”但在實(shí)際業(yè)務(wù)里能省掉大量用戶重新輸入的麻煩。有一點(diǎn)要特別注意不要把容錯(cuò)規(guī)則寫進(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里面最容易翻車的不是AI能力不足而是權(quán)限管得太松。我在Agent-Reach早期版本里讓Agent直接持有數(shù)據(jù)庫的管理員連接串結(jié)果它在一次測(cè)試中對(duì)線上一個(gè)表執(zhí)行了全量更新。那次事故讓我定下了一條鐵律Agent訪問外部系統(tǒng)必須使用專門的、最小權(quán)限的、可審計(jì)的服務(wù)賬號(hào)。具體操作上有幾點(diǎn)實(shí)操建議網(wǎng)絡(luò)隔離Agent執(zhí)行環(huán)境單獨(dú)劃分網(wǎng)段出網(wǎng)請(qǐng)求只能訪問白名單域名和端口。憑證隔離不在Agent進(jìn)程里放數(shù)據(jù)庫賬號(hào)或云廠商AK/SK改成在執(zhí)行沙箱層統(tǒng)一注入。操作分級(jí)讀操作直接執(zhí)行寫操作和刪除操作默認(rèn)加人工確認(rèn)。敏感系統(tǒng)熔斷現(xiàn)金類、通知類、批量類接口每個(gè)用戶每天有調(diào)用上限。這套權(quán)限設(shè)計(jì)本質(zhì)上就是在“讓Agent靈活干活”和“防止Agent闖禍”之間找一個(gè)平衡點(diǎn)。我的建議就一句話剛上線的時(shí)候權(quán)限寧可收得比設(shè)計(jì)得更緊也別一開始就全部放開。出一次事故的代價(jià)足以抵掉幾個(gè)月的人工確認(rèn)成本。3. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)3.1 快速搭一個(gè)最小的Agent-Reach循環(huán)我不太建議直接一上來就上重型框架先把最小的ReAct循環(huán)跑通后面加工具、加權(quán)限都水到渠成。我用Python寫了一個(gè)精簡(jiǎn)版核心依賴只有兩個(gè)一個(gè)openai客戶端、一個(gè)requests庫。主循環(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這段代碼看起來簡(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)用戶詢問訂單是否發(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ì)話來演示整個(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)無 最終回答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)用。整套流程跑下來用戶只感知到一次對(duì)話背后卻可能發(fā)生了多次循環(huán)推理。3.4 部署與穩(wěn)定性配置要點(diǎn)代碼寫好后部署階段還有很多隱蔽的坑。以下是我反復(fù)踩過之后總結(jié)出的部署配置清單超時(shí)設(shè)置單次工具調(diào)用默認(rèn)超時(shí)3秒LLM調(diào)用超時(shí)30秒整個(gè)Agent循環(huán)最長(zhǎng)60秒。寧可超時(shí)中斷也不要無限等下去。并發(fā)控制所有工具調(diào)用走異步Asyncio防止IO阻塞拖死進(jìn)程。同時(shí)限制單會(huì)話并發(fā)調(diào)用數(shù)不超過5。流式輸出模型決策階段適合用流式輸出把“思考中”的狀態(tài)透給用戶否則用戶等超過3秒就會(huì)疑心系統(tǒng)卡死。持久化會(huì)話每次循環(huán)后的完整消息列表要落庫不然后端進(jìn)程重啟用戶后續(xù)消息會(huì)因?yàn)闆]有上下文而讓Agent“失憶”?？捎^測(cè)性埋點(diǎn)每一輪工具調(diào)用都要記錄tool名稱、入?yún)?、出參、耗時(shí)、token數(shù)。這是排查Agent問題最依賴的數(shù)據(jù)。4. 常見問題與排查技巧實(shí)錄4.1 模型就是不調(diào)用工具怎么排查這是剛開始接入Agent-Reach時(shí)出現(xiàn)頻率最高的問題?，F(xiàn)象是模型回答得挺好但就是不產(chǎn)生tool_calls。排查順序按以下三步來第一步查工具描述是否被模型“看見”。在后臺(tái)日志里看每次請(qǐng)求的tool列表如果工具根本沒出現(xiàn)在請(qǐng)求的tools字段里那就是注冊(cè)中心或路由的問題。第二步查工具描述是否足夠明確。常見病是工具描述寫得像“給人類看的產(chǎn)品說明”而不是“給模型看的調(diào)用條件”。比如“獲取天氣”這種描述模型不知道什么時(shí)候該用。要改成“當(dāng)用戶詢問天氣情況、溫度、降雨概率時(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解析”把常見的格式錯(cuò)誤修掉修不掉的情況下把錯(cuò)誤信息作為tool結(jié)果回傳給模型讓模型自己重寫參數(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)遇到過一次模型反復(fù)調(diào)用同一個(gè)工具的情況它查了一遍庫存發(fā)現(xiàn)庫存不足又查一遍供應(yīng)商庫存還是不足又回頭查訂單……最后token燒了一大半。核心原因是循環(huán)里沒有退出條件。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)做下來死循環(huán)再?zèng)]出現(xiàn)過。4.4 權(quán)限過寬導(dǎo)致的誤操作與審計(jì)最后說一個(gè)管理層面的問題權(quán)限過寬通常不是技術(shù)缺陷而是工程規(guī)范缺失。Agent日志里必須完整記錄“誰在什么時(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)用說明query_order_status允許允許只讀無害update_order_address需要確認(rèn)允許寫操作cancel_order禁止需要雙重確認(rèn)高影響操作batch_import_products禁止禁止改走專門后臺(tái)這張表看起來樸素但它給團(tuán)隊(duì)提供了很清晰的“什么能跑什么不能跑”的共識(shí)。權(quán)限模型寧可一開始粗糙但覆蓋全面也不要精雕細(xì)琢卻漏掉關(guān)鍵路徑。4.5 排查工具失效時(shí)“日志優(yōu)先”心態(tài)最后分享一個(gè)工作習(xí)慣。Agent系統(tǒng)排查問題最大的敵人是“猜”。很多時(shí)候模型不調(diào)用工具、參數(shù)報(bào)錯(cuò)、執(zhí)行超時(shí)表象都非常相似。我的做法是遇到任何異常先翻工具調(diào)用日志確認(rèn)是模型決策問題還是后端執(zhí)行問題再?zèng)Q定改Prompt還是改代碼。如果發(fā)現(xiàn)模型決策問題優(yōu)先改工具描述如果發(fā)現(xiàn)參數(shù)校驗(yàn)問題優(yōu)先改Schema或容錯(cuò)解析如果發(fā)現(xiàn)執(zhí)行超時(shí)優(yōu)先查后端接口耗時(shí)而不是責(zé)怪模型。這樣排查方向清晰效率也高得多。5. 寫在最后的一些實(shí)在建議Agent-Reach這個(gè)項(xiàng)目做下來我最大的感受是智能體的上限不取決于模型有多聰明而取決于它“手里握著多少條可靠的鏈路”。你把工具注冊(cè)做好、參數(shù)校驗(yàn)做嚴(yán)、權(quán)限邊界畫清一個(gè)中型模型也能穩(wěn)定處理復(fù)雜的多步驟任務(wù)反過來工具描述一團(tuán)糟、權(quán)限放太開再強(qiáng)的模型也只會(huì)給你惹禍。如果你也想從零搭一套Agent能力延伸層我的建議是不要急著追求大而全的框架先把“一個(gè)用戶問題→觸發(fā)一次工具調(diào)用→返回可驗(yàn)證結(jié)果”的最小閉環(huán)跑通然后逐步加工具、加權(quán)限、加觀測(cè)。第一批工具控制在10個(gè)以內(nèi)覆蓋業(yè)務(wù)中最高頻的讀寫場(chǎng)景就夠了。最后送大家一個(gè)我在實(shí)際項(xiàng)目中驗(yàn)證過的小技巧每加一個(gè)新工具都去找兩三個(gè)真實(shí)用戶問法測(cè)試而不是只看工具描述文件本身。工具描述寫得再好模型“發(fā)現(xiàn)不了”就等于不存在。測(cè)試通過后把用戶問法沉淀成回歸用例——這套用例會(huì)成為你這個(gè)Agent項(xiàng)目未來最有價(jià)值的資產(chǎn)之一。