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