1. Agent-Reach想解決的問(wèn)題大模型聽(tīng)得懂但夠不著做AI應(yīng)用開(kāi)發(fā)這一年多我最深的體會(huì)是純對(duì)話式的大模型天花板很明顯。你跟它聊方案、聊思路它能說(shuō)得頭頭是道但一旦涉及幫我查一下線上的數(shù)據(jù)把這份報(bào)表發(fā)給運(yùn)營(yíng)調(diào)一下那個(gè)服務(wù)接口它就卡住了。原因很簡(jiǎn)單——模型只有腦子沒(méi)有手和腳。它理解你的意圖但缺乏真正去操作系統(tǒng)、調(diào)用接口、讀取數(shù)據(jù)的能力。Agent-Reach這個(gè)項(xiàng)目我一開(kāi)始就是想解決這個(gè)夠不著的問(wèn)題。所謂的 Agent在業(yè)界通常翻譯成智能體你可以把它理解成一個(gè)擁有決策大腦的操作員——它不僅要聽(tīng)懂你說(shuō)什么還要真的去執(zhí)行、去觸達(dá)外部的工具和系統(tǒng)。這里的觸達(dá)Reach是核心讓智能體能注冊(cè)外部能力、識(shí)別任務(wù)場(chǎng)景、組織調(diào)用參數(shù)、拿到執(zhí)行結(jié)果并反饋閉環(huán)。國(guó)內(nèi)做這類系統(tǒng)的人喜歡叫它智能體調(diào)度中間層我在項(xiàng)目里則給它起了代號(hào) Agent-Reach。如果你正在做智能客服、自動(dòng)化運(yùn)維、企業(yè)內(nèi)部助手或者任何需要讓大模型實(shí)際干活的場(chǎng)景那么Agent-Reach的設(shè)計(jì)思路和踩坑記錄應(yīng)該對(duì)你有參考價(jià)值。下文會(huì)從整體架構(gòu)、工具注冊(cè)、參數(shù)映射、并發(fā)調(diào)度這幾個(gè)維度展開(kāi)最后聊一聊實(shí)際落地時(shí)最容易出問(wèn)題的幾個(gè)點(diǎn)。2. 為什么直接讓模型自由發(fā)揮會(huì)翻車從一次事故說(shuō)起在講架構(gòu)之前我想先講一次比較慘痛的實(shí)測(cè)。最早我天真地以為只要把系統(tǒng)接口的說(shuō)明文檔扔給大模型它就能自己去調(diào)用API完成操作。于是我把公司內(nèi)部一個(gè)訂單查詢接口的OpenAPI文檔喂給了模型并錄制了一段對(duì)話用戶幫我查一下最近三天訂單號(hào)A10023的支付狀態(tài)。 模型好的我將調(diào)用訂單查詢接口完成此操作。{url: http://internal-order/api/v1/orders, params: {order_id: A10023, date_range: 3d}}表面上看模型生成了調(diào)用參數(shù)但實(shí)際請(qǐng)求發(fā)出去之后接口報(bào)了一個(gè) 400 錯(cuò)誤。為什么因?yàn)檎鎸?shí)的接口要求傳start_time和end_time兩個(gè)時(shí)間戳字段而不是date_range。模型在生成參數(shù)時(shí)自以為是地發(fā)明了字段名這在大模型調(diào)用工具的領(lǐng)域里有非常經(jīng)典的名字——工具參數(shù)幻覺(jué)Tool Parameter Hallucination。經(jīng)過(guò)這次排查我才徹底想明白直接讓大模型自由發(fā)揮觸碰外部系統(tǒng)風(fēng)險(xiǎn)集中在三個(gè)層面參數(shù)名稱和類型不匹配。接口文檔描述的是日期范圍但真實(shí)字段是時(shí)間戳或特定格式字符串模型經(jīng)常按直覺(jué)生成。上下文與真實(shí)業(yè)務(wù)規(guī)則脫節(jié)。比如接口要求先鑒權(quán)再查訂單模型不知道這個(gè)前置步驟。失敗后沒(méi)有糾錯(cuò)機(jī)制。模型生成了一次調(diào)用返回報(bào)錯(cuò)后它竟然編造了一個(gè)成功結(jié)果來(lái)回應(yīng)我。這些問(wèn)題不是靠提示詞能完全解決的。你需要一個(gè)中間層把模型的意圖輸出翻譯成系統(tǒng)能夠可靠執(zhí)行的指令并在中間做校驗(yàn)、糾錯(cuò)、反饋。這就是Agent-Reach整個(gè)項(xiàng)目存在的根本理由不讓模型直接面對(duì)混亂的現(xiàn)實(shí)接口而是面對(duì)一套經(jīng)過(guò)設(shè)計(jì)和約束的工具面。3. Agent-Reach 的總體架構(gòu)三層結(jié)構(gòu)怎么分工Agent-Reach 的架構(gòu)設(shè)計(jì)如果只用一句話概括就是把大模型當(dāng)成決策者把中間層當(dāng)成翻譯官把外部系統(tǒng)當(dāng)成執(zhí)行者。我最終落地的是三層結(jié)構(gòu)下面詳細(xì)拆開(kāi)講。3.1 決策層只負(fù)責(zé)決定做什么決策層運(yùn)行的是大模型本體我用的基座是 Qwen 和 DeepSeek 交叉驗(yàn)證后面會(huì)細(xì)說(shuō)原因。這一層不做具體的工具調(diào)用只做兩件事理解用戶意圖、選擇合適的工具。也就是說(shuō)模型輸出的不是直接請(qǐng)求參數(shù)而是一個(gè)結(jié)構(gòu)化動(dòng)作意圖比如{ intent: query_order_status, confidence: 0.92, arguments_slot: { order_no: A10023, time_window: recent_3d } }這一步最大的好處是隔離。模型只需要處理和它認(rèn)知范圍內(nèi)的東西——意圖、槽位、模糊表達(dá)不需要知道后端接口的地址、鑒權(quán)方式、字段細(xì)節(jié)。3.2 調(diào)度層核心的翻譯與校驗(yàn)中樞調(diào)度層是Agent-Reach的心臟它接收決策層輸出的結(jié)構(gòu)化意圖做三件關(guān)鍵的事情工具匹配根據(jù)intent在工具注冊(cè)表中找到對(duì)應(yīng)的處理程序。參數(shù)映射與補(bǔ)全把模型輸出的模糊槽位如recent_3d翻譯成真實(shí)接口需要的參數(shù)格式如start_time2025-06-01T00:00:00Zend_time2025-06-04T00:00:00Z。前置條件檢查檢查鑒權(quán) Token、頻控配額、業(yè)務(wù)白名單等前置條件不滿足就攔截。這三步做完才真正發(fā)起對(duì)目標(biāo)系統(tǒng)的調(diào)用。最終返回的結(jié)果會(huì)先經(jīng)過(guò)調(diào)度層的結(jié)果整理——截取關(guān)鍵字段、補(bǔ)充錯(cuò)誤信息、格式化提示再交還給大模型生成回復(fù)。3.3 執(zhí)行層封裝混沌的外部系統(tǒng)執(zhí)行層就是實(shí)際的外部系統(tǒng)集合包括HTTP API、數(shù)據(jù)庫(kù)、內(nèi)部中間件、腳本工具等。Agent-Reach通過(guò)統(tǒng)一的執(zhí)行適配器來(lái)連接它們。適配器的作用相當(dāng)于翻譯官手里的字典把外部的各種協(xié)議、數(shù)據(jù)結(jié)構(gòu)都?xì)w一化成內(nèi)部的標(biāo)準(zhǔn)調(diào)用形式。有一個(gè)經(jīng)驗(yàn)可以分享執(zhí)行層的適配器一定要做好故障隔離。如果某個(gè)外部服務(wù)掛了不能讓錯(cuò)誤直接炸到上層導(dǎo)致整個(gè)智能體不可用。我專門(mén)寫(xiě)了一個(gè)CircuitBreakerAdapter每個(gè)外部接口獨(dú)立維護(hù)熔斷狀態(tài)連續(xù)失敗超過(guò)閾值就自動(dòng)降級(jí)返回一個(gè)暫時(shí)無(wú)法觸達(dá)該項(xiàng)服務(wù)的兜底響應(yīng)。4. 工具注冊(cè)與能力描述讓模型看得懂工具的關(guān)鍵設(shè)計(jì)Agent-Reach 里工作量最大、也是坑最多的部分就是工具注冊(cè)表。它不像寫(xiě)一套API網(wǎng)關(guān)那樣簡(jiǎn)單因?yàn)榉?wù)對(duì)象不是程序員而是閱讀理解能力很強(qiáng)但紀(jì)律性很差的大模型。你需要把每個(gè)工具描述到讓模型一眼看懂、不胡猜的程度。4.1 工具描述文件的寫(xiě)法不要用一堆OpenAPI JSON硬塞最初我直接把傳統(tǒng) OpenAPI JSON 塞給模型做 Function Calling效果很差。原因很明顯OpenAPI文檔是為工程師準(zhǔn)備的里面有大量的$ref、枚舉、嵌套 schema、鑒權(quán)說(shuō)明模型可能在推理時(shí)迷失在這些細(xì)節(jié)里。后來(lái)我改成了一種人類可讀機(jī)器可解析雙軌制的描述格式核心是每個(gè)工具一份獨(dú)立的 Markdown 風(fēng)格的描述性配置包含以下字段tool_id: query_order_status name: 查詢訂單狀態(tài) description: 根據(jù)訂單號(hào)查詢訂單的當(dāng)前支付、發(fā)貨、售后狀態(tài)。 使用場(chǎng)景用戶詢問(wèn)我的訂單到哪了支付成功了嗎。 注意僅支持查詢近90天內(nèi)的訂單超過(guò)90天請(qǐng)引導(dǎo)用戶聯(lián)系人工客服。 input_schema: order_no: type: string required: true description: 用戶提供的訂單號(hào)通常是字母數(shù)字組合。 time_window: type: enum allowed_values: [recent_3d, recent_7d, recent_30d] default: recent_3d description: 查詢的時(shí)間范圍根據(jù)用戶的模糊表達(dá)進(jìn)行映射。 output_schema: status: string logistics_tracking_no: string | null message_for_user: string error_policy: on_failure: retry_once retry_interval_seconds: 2這份配置有兩個(gè)關(guān)鍵設(shè)定description里明確寫(xiě)了使用場(chǎng)景和注意這等于給模型劃定了觸發(fā)條件與禁區(qū)。實(shí)測(cè)下來(lái)帶負(fù)面約束什么情況不能調(diào)用比只寫(xiě)正面能力的大幅減少誤觸達(dá)。input_schema的字段名不追求和后端接口一致而是采用模型視角的自然命名。真正的映射關(guān)系寫(xiě)在調(diào)度層里。這是最反直覺(jué)的一條經(jīng)驗(yàn)工具注冊(cè)表是給模型看的不是給后端看的字段命名要順著模型的語(yǔ)言直覺(jué)走而不是順著后端工程師的習(xí)慣走。4.2 參數(shù)映射與槽位填充三層映射表為了讓模型輸出的模糊表達(dá)能落到實(shí)處我設(shè)計(jì)了一套三層參數(shù)映射表。這個(gè)概念如果你能領(lǐng)會(huì)后面做自己的Agent時(shí)會(huì)省很多事。第一層是表達(dá)歸一化。用戶可能說(shuō)最近三天這兩三天近幾日模型輸出的槽位值五花八門(mén)你要把這些表達(dá)歸一到內(nèi)部標(biāo)準(zhǔn)的時(shí)間窗口枚舉值recent_3d。第二層是枚舉擴(kuò)展。內(nèi)部標(biāo)準(zhǔn)值要翻譯成后端接口的真實(shí)參數(shù)。比如recent_3d映射為time_range1720108800,1720281600Unix時(shí)間戳recent_7d映射為另一組。這塊邏輯不復(fù)雜但要維護(hù)好映射關(guān)系表別散落在代碼里到處if-else。第三層是默認(rèn)值兜底。模型有時(shí)候會(huì)漏掉某個(gè)非必填槽位調(diào)度層要能填上合理的默認(rèn)值避免請(qǐng)求發(fā)出后因?yàn)槿眳?bào)錯(cuò)。映射表的實(shí)現(xiàn)我放在了調(diào)度層的一個(gè)獨(dú)立模塊中用配置驅(qū)動(dòng)而不是硬編碼。每次加新工具只需往映射表里加一行配置即可不用改任何業(yè)務(wù)代碼。5. 路由與并發(fā)觸達(dá)多個(gè)工具同時(shí)調(diào)用時(shí)的調(diào)度策略當(dāng)智能體的能力變多之后任務(wù)不再是一次只調(diào)一個(gè)工具那么簡(jiǎn)單。用戶一句話可能涉及多個(gè)系統(tǒng)的聯(lián)動(dòng)比如查一下訂單A10023的物流如果已經(jīng)簽收就提醒我確認(rèn)收貨。這在傳統(tǒng)編程里就是個(gè)簡(jiǎn)單的if流控但放在Agent場(chǎng)景里你要處理的是多個(gè)工具并行/串行調(diào)度的決策。5.1 DAG式任務(wù)編排不是線性鏈?zhǔn)秸{(diào)用我第一版實(shí)現(xiàn)使用的是簡(jiǎn)單的鏈?zhǔn)秸{(diào)用模型按順序調(diào)用工具A - 拿結(jié)果 - 調(diào)用工具B - 拿結(jié)果回應(yīng)用戶。但很快暴露了問(wèn)題。如果用戶問(wèn)這周進(jìn)店的客戶里哪些買(mǎi)了優(yōu)惠券但沒(méi)用他們的聯(lián)系方式是什么智能體需要先查詢CRM客戶列表、再查詢優(yōu)惠券使用記錄、再做一次匹配。如果這兩次查詢毫無(wú)依賴關(guān)系完全可以并行鏈?zhǔn)秸{(diào)用會(huì)白白多出一倍以上的響應(yīng)延遲。后來(lái)我把調(diào)度層升級(jí)成基于 DAG有向無(wú)環(huán)圖的任務(wù)編排模型。每次從模型的輸出中解析出所有需要執(zhí)行的工具調(diào)用然后根據(jù)它們的依賴關(guān)系構(gòu)建任務(wù)圖無(wú)依賴的工具節(jié)點(diǎn)放入并行隊(duì)列同時(shí)執(zhí)行。有依賴的節(jié)點(diǎn)等上游執(zhí)行完畢再觸發(fā)下游。某個(gè)節(jié)點(diǎn)失敗時(shí)根據(jù)依賴關(guān)系決定是否可繞過(guò)或整體終止。這里我強(qiáng)烈建議不要自己寫(xiě)DAG引擎直接用現(xiàn)成的異步任務(wù)框架我當(dāng)時(shí)用的asyncio 一個(gè)簡(jiǎn)單的拓?fù)渑判蚬ぞ哳惥蛪蛄?。Agent場(chǎng)景的節(jié)點(diǎn)數(shù)量級(jí)通常在個(gè)位數(shù)到幾十之間根本不需要引入重量級(jí)工作流引擎否則運(yùn)維復(fù)雜度會(huì)蓋過(guò)收益。5.2 并發(fā)控制與資源配額別讓智能體把線上服務(wù)打崩并行是爽但風(fēng)險(xiǎn)也在這。有一次實(shí)測(cè)中智能體在十分鐘內(nèi)并發(fā)觸發(fā)了 200 多次某數(shù)據(jù)報(bào)表服務(wù)直接把那個(gè)服務(wù)的連接池打滿了。原因是我沒(méi)有對(duì)工具調(diào)用做頻控配額。后來(lái)我在調(diào)度層增加了一個(gè)Quota Manager每個(gè)外部服務(wù)在注冊(cè)表里聲明自己的max_concurrency和rate_limit閾值調(diào)度層在發(fā)起觸達(dá)之前先申請(qǐng)令牌申請(qǐng)不到就排隊(duì)等待或降級(jí)。界面效果上沒(méi)有差別但線上服務(wù)的穩(wěn)定性好了很多。quotas 的配置大概是這樣的quota_policies: - tool_id: query_order_status max_concurrency: 5 rate_limit_per_minute: 60 queue_timeout_seconds: 3 - tool_id: get_customer_contacts max_concurrency: 3 rate_limit_per_minute: 30 queue_timeout_seconds: 5這里想提醒一個(gè)細(xì)節(jié)超時(shí)設(shè)置不要統(tǒng)一用一個(gè)值。不同接口的響應(yīng)時(shí)間差別很大訂單查詢一般幾百毫秒報(bào)表導(dǎo)出部門(mén)可能要十幾秒。統(tǒng)一的timeout3會(huì)讓慢接口頻繁誤判失敗統(tǒng)一改為timeout15又會(huì)讓快接口失敗時(shí)等半天。最好在工具注冊(cè)表里為每個(gè)工具單獨(dú)配置超時(shí)時(shí)間。6. 反饋閉環(huán)與結(jié)果整理讓模型有依據(jù)地說(shuō)話調(diào)度層把工具調(diào)完之后拿到的是各種格式的原始結(jié)果。這些結(jié)果不能直接拋給大模型生成回復(fù)否則模型會(huì)原封不動(dòng)地把{code: 0, data: {order_status: paid, pay_time: ...}}翻譯成一大段晦澀的JSON內(nèi)容念給用戶聽(tīng)。這里需要一層結(jié)果整理器Result Refiner。6.1 精簡(jiǎn)與格式化結(jié)果整理器做的事情很簡(jiǎn)單從原始響應(yīng)中提取關(guān)鍵字段把它們組織成半結(jié)構(gòu)化的簡(jiǎn)報(bào)文本。比如訂單查詢接口的原始響應(yīng)是{ code: 0, data: { order_id: A10023, status: paid, pay_time: 2025-06-03 14:22:10, pay_amount: 399.00, logistics: [ {provider: SF, tracking_no: SF1234567890, last_update: 2025-06-05 09:00, current_location: 上海轉(zhuǎn)運(yùn)中心} ] } }整理器會(huì)輸出一段如下的簡(jiǎn)報(bào)給模型訂單A10023狀態(tài)已支付支付金額399元支付時(shí)間2025年6月3日 14:22。 物流信息順豐速運(yùn)單號(hào)SF1234567890最新?tīng)顟B(tài)包裹到達(dá)上海轉(zhuǎn)運(yùn)中心更新于6月5日09:00。這樣模型再生成回復(fù)時(shí)就有了準(zhǔn)確的事實(shí)底稿不會(huì)憑空編造細(xì)節(jié)。這一步對(duì)提升回答的準(zhǔn)確率貢獻(xiàn)巨大——模型看到的是語(yǔ)言而不是數(shù)據(jù)幻覺(jué)率顯著下降。6.2 失敗反饋的誠(chéng)實(shí)原則工具調(diào)用失敗時(shí)還有一個(gè)容易踩的坑模型傾向于給用戶圓一個(gè)結(jié)果。它可能在沒(méi)有真實(shí)數(shù)據(jù)的情況下說(shuō)您的訂單正在配送中來(lái)應(yīng)付用戶。為避免這種情況我在整理器里明確給模型傳遞失敗標(biāo)記[工具調(diào)用失敗] 訂單查詢服務(wù)暫時(shí)不可用。失敗碼timeout。 請(qǐng)明確告知用戶當(dāng)前暫時(shí)無(wú)法查詢不要猜測(cè)訂單狀態(tài)。止損措辭寫(xiě)進(jìn)了系統(tǒng)提示詞里并且在結(jié)果簡(jiǎn)報(bào)中反復(fù)強(qiáng)化基于以下事實(shí)不得推測(cè)這兩個(gè)約束。實(shí)測(cè)下來(lái)模型編造結(jié)果的概率顯著下降。這也說(shuō)明了Agent系統(tǒng)里誠(chéng)實(shí)護(hù)欄的重要性——寧可讓用戶知道暫時(shí)查不到也不能讓用戶基于虛假信息做出決策。7. 實(shí)測(cè)表現(xiàn)與關(guān)鍵坑位排查給想復(fù)現(xiàn)的你一份參考很多朋友問(wèn)Agent-Reach 做成這樣到底好用不好用我會(huì)把實(shí)測(cè)數(shù)據(jù)和踩坑經(jīng)歷分開(kāi)講這樣你復(fù)現(xiàn)的時(shí)候有據(jù)可依。7.1 實(shí)測(cè)數(shù)據(jù)準(zhǔn)確率、延遲和失敗率兩個(gè)場(chǎng)景的實(shí)測(cè)數(shù)據(jù)我比較滿意工具選擇準(zhǔn)確率約 95%。在 200 條測(cè)試對(duì)話樣本中模型選錯(cuò)工具的情況是 10 條其中大半是因?yàn)闇y(cè)試樣本中存在高度相似的工具描述比如查訂單和查物流單。給這兩個(gè)工具的描述里增加使用邊界說(shuō)明后誤選率又降了一半。端到端響應(yīng)延遲平均約 2.8 秒。其中大模型推理占了大頭工具觸達(dá)本身耗時(shí)大約 300-600 毫秒調(diào)度層的映射與校驗(yàn)基本在 10 毫秒以內(nèi)可以忽略。帶熔斷機(jī)制后外部服務(wù)短暫故障時(shí)的答非所問(wèn)率明顯下降。在一次線上模擬故障中訂單服務(wù)連續(xù)返回 500Agent-Reach 自動(dòng)熔斷并回退到提示稍后再試沒(méi)有把錯(cuò)誤信息暴露給用戶。7.2 坑位一模型把同義詞當(dāng)成了兩個(gè)槽位這是早期最容易踩的坑之一。用戶說(shuō)我的iPhone 15訂單發(fā)貨了沒(méi)模型把iPhone 15當(dāng)作商品名槽位把發(fā)貨了沒(méi)當(dāng)作意圖但同一個(gè) Tool 的input_schema里只有order_no一個(gè)必填槽位這就導(dǎo)致模型在生成調(diào)用參數(shù)時(shí)進(jìn)行了過(guò)度補(bǔ)充——它自己發(fā)明了product_name字段并塞進(jìn)參數(shù)里。解決方案是在調(diào)度層的 schema 校驗(yàn)邏輯里做嚴(yán)格的白名單過(guò)濾凡是不在input_schema聲明的字段一律丟棄不發(fā)給后端接口。這一步雖然看起來(lái)是防御性編程但在Agent場(chǎng)景中至關(guān)重要因?yàn)槟Ｐ偷妮敵鲇肋h(yuǎn)不會(huì)像人寫(xiě)代碼那樣嚴(yán)格。7.3 坑位二上下文太長(zhǎng)導(dǎo)致選擇性遺忘工具名當(dāng)系統(tǒng)里注冊(cè)了超過(guò) 15 個(gè)工具后我發(fā)現(xiàn)模型開(kāi)始頻繁忘記某些不太常用的工具轉(zhuǎn)而用一些泛化描述去匹配。一個(gè)直接治本的辦法是把工具注冊(cè)表分成兩層熱工具表每次請(qǐng)求都會(huì)加載到模型上下文里數(shù)量控制在 8-10 個(gè)。冷工具表單獨(dú)存儲(chǔ)只有用戶意圖涉及特定領(lǐng)域時(shí)才通過(guò)一個(gè)領(lǐng)域識(shí)別器臨時(shí)加載進(jìn)上下文。這個(gè)思路很像程序員的局部性原理——讓最常用的信息始終在緩存里不常用的按需拉取。實(shí)現(xiàn)之后工具選擇準(zhǔn)確率又回升并穩(wěn)定在了 95% 以上。7.4 坑位三LLM 的不確定性在異步任務(wù)中放大Agent-Reach 支持異步任務(wù)比如定時(shí)觸發(fā)、消息隊(duì)列觸發(fā)但異步任務(wù)里模型沒(méi)有和用戶實(shí)時(shí)交互的上下文一旦模型輸出的動(dòng)作意圖有歧義錯(cuò)誤會(huì)被直接放大。例如一個(gè)定時(shí)任務(wù)要統(tǒng)計(jì)昨天的退單率并發(fā)送報(bào)告模型可能輸出send_report工具調(diào)用但用戶郵箱地址從哪來(lái)如果決策層未聲明默認(rèn)接收人調(diào)度層就不知道該發(fā)給誰(shuí)。解決方法是給異步任務(wù)設(shè)計(jì)一套參數(shù)完整性校驗(yàn)在校驗(yàn)不通過(guò)時(shí)不執(zhí)行任何操作而是把任務(wù)回退到待確認(rèn)狀態(tài)等待人工或默認(rèn)規(guī)則確認(rèn)。寧可任務(wù)延遲也不要發(fā)給錯(cuò)誤的人。8. Agent-Reach 還能往哪走我看著的三個(gè)方向項(xiàng)目目前基本穩(wěn)定但我心里清楚它還有很多可以擴(kuò)展的余地。如果你準(zhǔn)備基于同樣的思路做自己的Agent系統(tǒng)可以參考下面三個(gè)方向。第一個(gè)方向是多模態(tài)工具的接入。目前 Agent-Reach 觸達(dá)的主要是數(shù)據(jù)型API但實(shí)際業(yè)務(wù)里大量需要觸達(dá)的是圖像識(shí)別、OCR、語(yǔ)音合成這類多模態(tài)能力。接入不難但結(jié)果整理器的設(shè)計(jì)要升級(jí)——因?yàn)檩敵霾辉偈墙Y(jié)構(gòu)化JSON而是圖片或音頻內(nèi)容整理器需要能對(duì)這些非結(jié)構(gòu)化內(nèi)容做摘要和描述才能交給大模型生成自然語(yǔ)言回復(fù)。第二個(gè)方向是自適應(yīng)學(xué)習(xí)工具描述?，F(xiàn)在工具注冊(cè)表是靜態(tài)的如果后端接口升級(jí)了字段需要人工同步更新描述。我在想能不能通過(guò)記錄歷史調(diào)用錯(cuò)誤、失敗原因自動(dòng)生成工具描述修訂建議。比如發(fā)現(xiàn)模型經(jīng)常把order_no寫(xiě)成id就可以自動(dòng)在description中補(bǔ)充一句注意訂單號(hào)字段名是 order_no不是 id。第三個(gè)方向是多智能體協(xié)同觸達(dá)。當(dāng)一個(gè)任務(wù)復(fù)雜到需要多個(gè)智能體協(xié)作時(shí)比如客服機(jī)器人和數(shù)據(jù)分析機(jī)器人共同處理一個(gè)投訴工單Agent-Reach 可以升級(jí)為智能體間的消息路由中樞。架構(gòu)上這不需要推倒重來(lái)只需要在調(diào)度層之上抽象出一個(gè)通信協(xié)議層讓不同智能體之間可以交換觸達(dá)結(jié)果和任務(wù)上下文。我個(gè)人最推薦先做第一個(gè)方向因?yàn)槎嗄B(tài)交互在業(yè)務(wù)側(cè)的收益最直接、反饋也最快。后面兩個(gè)方向更需要想清楚業(yè)務(wù)模型一不小心就容易做成技術(shù)玩具。項(xiàng)目做到現(xiàn)在我最大的體會(huì)是大模型應(yīng)用不能只追求聰明更要追求可靠。而 Agent-Reach 這類觸達(dá)中間層的全部?jī)r(jià)值就是讓系統(tǒng)的可靠性不再依賴于模型本身發(fā)揮的穩(wěn)定性——這正是生產(chǎn)環(huán)境里最稀缺的東西。