最近我在折騰一個(gè)內(nèi)部代號(hào)叫Agent-Reach的東西起因很簡單市面上各種 Agent 框架層出不窮模型的推理能力一個(gè)比一個(gè)強(qiáng)可真要讓它去查一下數(shù)據(jù)庫、調(diào)一下內(nèi)部接口、把一份報(bào)表發(fā)到群里就立馬卡殼。模型的大腦沒問題缺的是手腳——也就是真正觸達(dá)外部系統(tǒng)的那一層能力。Agent-Reach 就是我針對(duì)這個(gè)問題做的一套工程化方案核心思路是把模型能想到什么和系統(tǒng)能做到什么這兩件事徹底打通。這套東西已經(jīng)在我們好幾個(gè)項(xiàng)目里跑了一段時(shí)間穩(wěn)定性和實(shí)用性都過了驗(yàn)證。這篇文章我就把從設(shè)計(jì)思路到具體實(shí)現(xiàn)再到踩坑記錄的全過程分享出來適合正在做 Agent 落地、被模型只說不做折磨的開發(fā)者參考。1. 項(xiàng)目緣起為什么 Agent 總是止步于聊天1.1 被忽視的最后一公里先講個(gè)真實(shí)場景。去年我們接了一個(gè)內(nèi)部工單系統(tǒng)的需求希望用大模型自動(dòng)處理一部分重復(fù)咨詢。剛開始大家覺得這事簡單把工單歷史記錄灌進(jìn)知識(shí)庫模型做 RAG 檢索然后給它一個(gè)答案模板不就行了結(jié)果真跑起來問題全出在動(dòng)不了上。模型確實(shí)能理解工單內(nèi)容、能給出答復(fù)思路但它沒辦法自己去工單系統(tǒng)里查狀態(tài)、修改標(biāo)簽、指派處理人更別說去關(guān)聯(lián)的監(jiān)控平臺(tái)拉一份實(shí)時(shí)數(shù)據(jù)。原因很明確模型生活在文本世界里而業(yè)務(wù)系統(tǒng)生活在自己的 API、權(quán)限、數(shù)據(jù)格式里。這兩者之間有一條巨大的鴻溝也就是所謂的最后一公里。市面上的 Agent 框架解決的大多是怎么讓模型更好地思考和規(guī)劃這一層比如各種 ReAct 模式、規(guī)劃器、記憶模塊但真正決定 Agent 能不能干活的是它能不能又快又準(zhǔn)地夠到外部工具。Agent-Reach 就是沖著這最后一公里去的——專門解決 Agent 的觸達(dá)能力問題。1.2 觸達(dá)能力為什么這么難做先別急著去寫工具調(diào)用函數(shù)我拆一下觸達(dá)這件事到底難在哪你就明白為什么不能用幾百行臨時(shí)腳本草草解決。工具太多太雜。一個(gè)正常的業(yè)務(wù)系統(tǒng)里可能有幾十個(gè)內(nèi)部 API每個(gè) API 的參數(shù)格式、認(rèn)證方式、限流策略都不一樣模型不可能把所有工具都記在上下文里。模型天生不穩(wěn)定。同一個(gè)意圖模型這次可能把參數(shù)寫成keyword下次就變成query而且它經(jīng)常漏填必填字段甚至做夢都能給你造出一個(gè)不存在的工具名。執(zhí)行環(huán)境有風(fēng)險(xiǎn)。Agent 調(diào)用的接口往往附帶副作用比如刪數(shù)據(jù)、發(fā)消息、改配置如果沒做權(quán)限隔離一次模型幻覺就可能釀成事故。失敗原因不可見。傳統(tǒng)接口調(diào)用失敗至少會(huì)拋給你一個(gè)明確的異常但 Agent 調(diào)用失敗是雙盲的——可能是參數(shù)錯(cuò)了可能是模型選錯(cuò)了工具也可能是目標(biāo)服務(wù)本身出了問題中間任何一環(huán)斷了都不好查。這四個(gè)問題疊加在一起就形成了一個(gè)有意思的悖論模型的推理能力越強(qiáng)它亂來的破壞力就越大。所以我做 Agent-Reach 的第一性原理是把觸達(dá)能力變成一套基礎(chǔ)設(shè)施而不是讓每個(gè) Agent 各自為政。2. 整體設(shè)計(jì)思路把觸達(dá)拆成可治理的四層2.1 協(xié)議層給工具一個(gè)統(tǒng)一的標(biāo)準(zhǔn)接口所有做 Agent 集成的人第一步遇到的坑都是每個(gè)工具都不一樣。有的工具是 REST API有的是 GraphQL有的是 WebSocket 長連接有的甚至是直接連數(shù)據(jù)庫執(zhí)行 SQL。如果讓模型直接面對(duì)這些千奇百怪的接口那模型再聰明也會(huì)被逼瘋。Agent-Reach 的解法是定義一套輕量級(jí)的工具協(xié)議就叫Reach Spec。它不是要重新發(fā)明一遍 OpenAPI而是要做一份讓模型更容易理解的工具描述標(biāo)準(zhǔn)。# 一個(gè)典型的 Reach Spec 示例 tools: - name: refresh_weather description: 獲取指定城市當(dāng)前天氣信息 endpoint: https://api.weather.internal/v1/current method: GET params: - name: city type: string required: true description: 城市中文名例如北京 - name: unit type: enum values: [celsius, fahrenheit] default: celsius timeout_ms: 5000 retry_count: 2 auth: internal_token這份協(xié)議的重點(diǎn)不是字段本身而是字段描述。寫描述的時(shí)候要站在模型的角度去寫人看得懂沒用得讓模型一看就知道該傳什么值。比如city這個(gè)字段如果你只寫城市兩個(gè)字模型可能傳北京市、北京、beijing完全看心情如果你寫明城市中文名例如北京那模型大概率會(huì)乖乖填北京。2.2 路由層不要相信模型記住的所有工具名工具一多上下文裝不下是必然的。GPT 類模型的上下文窗口雖然越做越大但你不可能把一百個(gè)工具的完整描述全部塞進(jìn)去既浪費(fèi) token 又稀釋注意力。Agent-Reach 用一個(gè)獨(dú)立的語義路由器來處理工具選擇而不是讓模型憑記憶硬選。大致流程是全局維護(hù)一份工具注冊(cè)表每個(gè)工具都有語義索引。用戶提出任務(wù)后路由器對(duì)任務(wù)做向量化表達(dá)。從工具注冊(cè)表中檢索最相關(guān)的 Top-K 個(gè)工具再把它們的 Reach Spec 注入給模型。這個(gè)設(shè)計(jì)的巧妙之處在于模型的注意力被聚焦了。它只需要從 3~5 個(gè)候選工具里做選擇而不是從 100 個(gè)工具里大海撈針。實(shí)測下來工具選擇的準(zhǔn)確率從不到 70% 直接提升到了 95% 以上。這個(gè)數(shù)字差就是全量塞上下文和檢索式注入的差距。2.3 執(zhí)行層帶安全帶的沙箱運(yùn)行觸達(dá)層最怕的是 Agent 真的把生產(chǎn)環(huán)境的服務(wù)搞掛了。我在設(shè)計(jì)執(zhí)行層的時(shí)候?qū)ｉT加了三個(gè)安全帶。第一個(gè)是參數(shù)校驗(yàn)。模型給出的參數(shù)必須通過 Reach Spec 里的類型和必填校驗(yàn)不符合的直接拒絕壓根不會(huì)發(fā)到服務(wù)端。這個(gè)校驗(yàn)必須在模型端做掉因?yàn)榘l(fā)出去再返錯(cuò)浪費(fèi)的不只是時(shí)間還有模型的一次完整推理。第二個(gè)是副作用隔離。每個(gè) Agent 默認(rèn)分配一個(gè)受限的認(rèn)證憑證只能調(diào)用它被允許訪問的工具范圍。嚴(yán)禁把所有內(nèi)部接口的 API key 一鍋燉給模型——這是我踩過最大的坑之一不細(xì)說了后果很嚴(yán)重。第三個(gè)是超時(shí)與熔斷。每個(gè)工具調(diào)用都有獨(dú)立的超時(shí)上限超了直接判定失敗。如果連續(xù)失敗次數(shù)超過閾值熔斷器會(huì)把這個(gè)工具暫時(shí)降級(jí)為不可用避免模型在一個(gè)壞掉的工具上反復(fù)做無意義的重試。2.4 評(píng)估層每次觸達(dá)都可以回溯Agent-Reach 的核心不只是讓 Agent 調(diào)得通還包括讓 Agent 調(diào)得明。執(zhí)行層每一次觸達(dá)都會(huì)記錄一份結(jié)構(gòu)化的調(diào)用日志{ request_id: req_8f3a2d9c, task_id: task_1234, tool: refresh_weather, params: {city: 北京}, started_at: 2025-05-20T14:32:10.421, elapsed_ms: 387, status: success, model_used: reasoner-pro, retry_count: 0 }這份日志的價(jià)值在排障階段會(huì)徹底體現(xiàn)出來。我曾經(jīng)排過一個(gè)詭異問題某個(gè) Agent 偶爾會(huì)傳錯(cuò)城市名導(dǎo)致天氣數(shù)據(jù)總是差幾個(gè)點(diǎn)。查了半天模型代碼也沒發(fā)現(xiàn)問題最后翻開觸達(dá)日志才發(fā)現(xiàn)是上游接口變更了城市別名映射而 Agent-Reach 的緩存還留著舊的映射記錄。沒有結(jié)構(gòu)化日志這種問題基本要靠猜才能定位。3. 核心細(xì)節(jié)解析幾個(gè)決定成敗的關(guān)鍵設(shè)計(jì)3.1 工具描述怎么寫模型才不發(fā)瘋剛才提到 Reach Spec 里的描述字段很重要這里展開講具體怎么寫。我總結(jié)了三條經(jīng)驗(yàn)給示例不給定義。寫description時(shí)直接給一到兩個(gè)具體的示例效果遠(yuǎn)比抽象解釋好。比如城市中文名例如北京、上海會(huì)讓模型一秒理解。抽象寫地理實(shí)體標(biāo)識(shí)符只會(huì)讓模型進(jìn)入哲學(xué)思考模式。顯式聲明取值范圍。任何有限取值空間都要寫成enum比如溫度單位、排序方式、狀態(tài)值絕不讓模型自由發(fā)揮。一次血的教訓(xùn)是模型把status字段傳成了active但系統(tǒng)接口只認(rèn)enabled這倆在人類眼里沒啥差別機(jī)器卻直接拒了。注明工具的副作用。如果工具會(huì)發(fā)通知、改數(shù)據(jù)、刪記錄必須在描述中寫一句該操作會(huì)發(fā)送通知給用戶或該操作不可逆請(qǐng)謹(jǐn)慎調(diào)用。模型看過這段描述后會(huì)在決策環(huán)節(jié)更保守有效降低亂調(diào)工具的概率。3.2 路由檢索的閾值怎么定語義路由聽起來簡單但工程上有一個(gè)很微妙的參數(shù)檢索閾值。如果閾值設(shè)得太高經(jīng)常檢索不到任何工具任務(wù)直接失敗如果設(shè)得太低模型面臨的候選集變大選擇準(zhǔn)確率又會(huì)下降。我在項(xiàng)目里做過一組對(duì)比實(shí)驗(yàn)結(jié)果很有意思閾值平均候選數(shù)工具選擇準(zhǔn)確率備注0.801.296.8%但約 12% 的任務(wù)檢索不到工具0.702.896.1%檢索失敗率降到 4%0.605.491.2%候選過多模型開始混亂0.509.784.6%基本等于全量注入最終我在生產(chǎn)環(huán)境選了 0.70~0.75 這個(gè)區(qū)間。經(jīng)驗(yàn)值是選一個(gè)讓平均候選數(shù)在 2~3 個(gè)之間的閾值準(zhǔn)確率不會(huì)掉太多還能把檢索死角降到可控范圍。如果你發(fā)現(xiàn)檢索失敗率偏高要先檢查工具描述的質(zhì)量而不是急著調(diào)低閾值。3.3 執(zhí)行沙箱的權(quán)限模型沙箱權(quán)限這塊我直接用了一套非常樸素的模型工具級(jí)白名單 用戶級(jí)斷言。工具級(jí)白名單的意思是每個(gè) Agent 實(shí)例創(chuàng)建時(shí)都會(huì)被綁定一批允許調(diào)用的工具白名單之外的工具無論如何都不會(huì)被路由到。這樣就算模型幻覺出了一個(gè)工具名路由器也直接返回不可用。用戶級(jí)斷言則是把人的判斷也納入進(jìn)來。有一個(gè)confirm_before_execute標(biāo)志位開啟后危險(xiǎn)操作比如刪除、發(fā)送消息、轉(zhuǎn)賬必須先經(jīng)過一個(gè)確認(rèn)步驟。這個(gè)確認(rèn)可以是一個(gè)簡單的用戶點(diǎn)擊按鈕也可以是管理員在群里回一個(gè)關(guān)鍵詞。雖然多了一步但對(duì)于生產(chǎn)級(jí) Agent這一步換來的安全性是完全值得的。注意就算你的 Agent 只做只讀操作也建議保留用戶級(jí)斷言機(jī)制。因?yàn)槟阌肋h(yuǎn)不知道模型哪一天會(huì)用正確的權(quán)限做出一件荒唐的事。4. 實(shí)操過程從零跑通一個(gè) Agent-Reach 應(yīng)用4.1 環(huán)境準(zhǔn)備與最小依賴安裝接下來進(jìn)入動(dòng)手環(huán)節(jié)。我用一個(gè)最簡單的天氣查詢 日?qǐng)?bào)生成場景來演示你可以在本地完整復(fù)現(xiàn)。先準(zhǔn)備環(huán)境pip install agent-reach fastapi uvicornAgent-Reach 我這邊用的是 Python 版 SDK核心依賴是 FastAPI用于搭 Mock 服務(wù)和 SDK 本體。安裝完之后在項(xiàng)目目錄里建一個(gè)reach.yaml把前文那個(gè)天氣工具的 Reach Spec 文件復(fù)制進(jìn)去改名為reach.yaml。接著跑一個(gè)最小的 Mock 天氣服務(wù)from fastapi import FastAPI from datetime import datetime app FastAPI() app.get(/v1/current) def get_current(city: str, unit: str celsius): # Mock 數(shù)據(jù)真實(shí)場景這里會(huì)去調(diào)天氣服務(wù)商 return { city: city, temperature: 24, unit: unit, updated_at: datetime.now().isoformat() }保存為mock_service.py在終端里跑uvicorn mock_service:app --port 8001一個(gè)可以隨時(shí)調(diào)用的天氣接口就起來了。4.2 編寫第一個(gè) Agent接入 Agent-Reach核心代碼分三塊初始化注冊(cè)中心、注入工具描述、運(yùn)行觸達(dá)循環(huán)。完整代碼如下from agent_reach import ReachAgent, ReachRegistry, ReachConfig # 1. 初始化觸達(dá)注冊(cè)中心加載 yaml 工具定義 registry ReachRegistry.from_yaml(reach.yaml) # 2. 配置 Agent綁定模型和工具注冊(cè)中心 config ReachConfig( modelreasoner-pro, # 你實(shí)際使用的語言模型 registryregistry, retry_strategyexponential, # 指數(shù)退避重試 max_tool_calls_per_task8, # 單任務(wù)最多觸達(dá) 8 次工具 ) # 3. 創(chuàng)建 Agent 實(shí)例 agent ReachAgent(configconfig) # 4. 直接執(zhí)行任務(wù) result agent.run(查一下北京今天的天氣然后用一句話告訴我適不適合晨跑) print(result.summary)我沒有寫任何一行告訴模型怎么調(diào)用天氣接口的代碼。Agent-Reach 會(huì)在內(nèi)部完成路由檢索、工具描述注入、模型決策解析、參數(shù)校驗(yàn)、HTTP 調(diào)用、結(jié)果回填這一整條鏈路。運(yùn)行后你會(huì)看到類似這樣的輸出[Reach Router] 檢索到候選工具: refresh_weather (score0.87) [Reach Runner] 參數(shù)校驗(yàn)通過: {city: 北京, unit: celsius} [Reach Runner] 請(qǐng)求成功 (287ms) 200 OK [Reach Agent] 最終回應(yīng): 北京今天 24°C氣溫適宜適合晨跑。這套流程跑通的瞬間你才算真正體會(huì)到什么是Agent 有手有腳。4.3 擴(kuò)展第二個(gè)工具讓 Agent 把結(jié)果寫進(jìn)表格單工具只是熱身Agent-Reach 的價(jià)值在多工具協(xié)同場景才真正凸顯。我再加一個(gè)寫日?qǐng)?bào)工具讓 Agent 自動(dòng)更新 Markdown 日?qǐng)?bào)表。tools: - name: update_daily_report description: 將今日工作內(nèi)容追加到日?qǐng)?bào)表中 endpoint: https://report.internal/v1/append method: POST params: - name: content type: string required: true description: 工作日?qǐng)?bào)內(nèi)容簡短一句話例如完成天氣查詢功能聯(lián)調(diào) - name: author type: string required: false description: 作者名稱默認(rèn)取配置 confirm_before_execute: true注意這里的confirm_before_execute: true。因?yàn)閷懭請(qǐng)?bào)是帶副作用的操作Agent-Reach 會(huì)在執(zhí)行前暫停一次等你輸入y確認(rèn)后才繼續(xù)?，F(xiàn)在你可以讓 Agent 直接完成查天氣 寫日?qǐng)?bào)的完整鏈路result agent.run(查一下北京今天的天氣然后把完成天氣查詢功能聯(lián)調(diào)追加到日?qǐng)?bào)里。)運(yùn)行時(shí)會(huì)看到一次確認(rèn)交互[Reach Runner] 工具 update_daily_report 需要人工確認(rèn) 確認(rèn)執(zhí)行?(y/n): y [Reach Runner] 請(qǐng)求成功 (152ms) 200 OK [Reach Agent] 最終回應(yīng): 天氣查詢已完成日?qǐng)?bào)已更新。整個(gè)過程不需要你手動(dòng)編寫任何業(yè)務(wù)編排邏輯Agent 自己按任務(wù)拆解、按需觸達(dá)。這就是我為什么強(qiáng)調(diào)觸達(dá)層是基礎(chǔ)設(shè)施——你只定義工具模型來編排路徑。5. 常見問題與排查技巧實(shí)錄5.1 四個(gè)高頻問題的實(shí)戰(zhàn)排查表在 Agent-Reach 的落地過程中團(tuán)隊(duì)前前后后踩了不少坑。我把最典型的四類問題整理成速查表這些問題你在自己做 Agent 集成時(shí)大概率也會(huì)撞上?，F(xiàn)象直接原因排查手段解決方案模型選錯(cuò)工具工具描述太抽象語義路由檢索精度不夠查看 Reach Router 日志里的候選分?jǐn)?shù)重寫工具 description加具體示例參數(shù)反復(fù)校驗(yàn)失敗模型傳參習(xí)慣和協(xié)議不一致打印 Reach Runner 的校驗(yàn)失敗快照在 Spec 中顯式聲明 enum、格式示例、別名映射工具調(diào)用超時(shí)目標(biāo)服務(wù)響應(yīng)慢Agent 不斷重試導(dǎo)致堆積查看觸達(dá)日志中的elapsed_ms分布調(diào)低 timeout啟用熔斷對(duì)下游服務(wù)做限流上下文被工具輸出撐爆接口返回大量無關(guān)字段全部回填給了模型檢查模型輸入 token 消耗在 Spec 中聲明response_truncate最大返回字節(jié)數(shù)第二類問題最隱蔽。有一次模型連續(xù)八次把日期參數(shù)傳成2025/05/20而接口只認(rèn)2025-05-20Agent-Reach 每次都返回校驗(yàn)錯(cuò)誤。后來我在 Spec 里加了一個(gè)字段別名映射規(guī)則把斜杠格式自動(dòng)規(guī)整為短橫線格式問題才徹底解決。記住一個(gè)原則別指望模型改變習(xí)慣要讓協(xié)議適配模型的慣常用法。5.2 生產(chǎn)環(huán)境必開的三個(gè)配置項(xiàng)如果你要把 Agent-Reach 用到正式環(huán)境這三個(gè)配置項(xiàng)我強(qiáng)烈建議開足第一全量觸達(dá)審計(jì)日志。不要省存儲(chǔ)每次觸達(dá)請(qǐng)求的出入?yún)?、耗時(shí)、模型、狀態(tài)全記下來。出了問題能回溯到具體某一次調(diào)用的具體某個(gè)參數(shù)排障效率飛快。第二人工確認(rèn)分層。把工具按危險(xiǎn)級(jí)別分為普通、確認(rèn)、雙人確認(rèn)三檔。普通工具直接執(zhí)行確認(rèn)工具彈確認(rèn)框雙人確認(rèn)工具需要兩個(gè)管理員審批?？雌饋碇氐珜?duì)生產(chǎn)數(shù)據(jù)的安全保障是實(shí)打?qū)嵉摹５谌詣?dòng)降級(jí)策略。如果某個(gè)核心工具連續(xù)失敗三次Agent-Reach 應(yīng)自動(dòng)把策略從觸達(dá)并等待降級(jí)為返回可讀的錯(cuò)誤提示避免 Agent 在壞掉的工具上空轉(zhuǎn)消耗時(shí)間和算力。5.3 再做三次實(shí)驗(yàn)的心得最后聊一下我在反復(fù)調(diào)整觸達(dá)層配置過程中的幾條真實(shí)感悟。先把工具定義做好再調(diào)模型提示詞。很多人一開始就讓模型寫復(fù)雜的 prompt試圖說服它好好調(diào)用工具這方向搞反了。工具定義是土壤提示詞是莊稼土壤不好莊稼怎么澆水都白搭。盡量用短小的工具粒度。一個(gè)工具負(fù)責(zé)一件事比如get_weather、send_email、append_report而不是搞一個(gè)龐大的business_ops工具在里面塞十個(gè)參數(shù)。粒度越細(xì)路由越好做模型的理解成本也越低當(dāng)然工具數(shù)量會(huì)上升但 Agent-Reach 的檢索機(jī)制就是為這種場景設(shè)計(jì)的。每次失敗都要沉淀成用例。我在項(xiàng)目里有一個(gè)failures/目錄專門存放線上觸達(dá)失敗的真實(shí)案例定期把它們灌回評(píng)測集。每一輪迭代后都跑一遍回歸確保修好的問題不回潮。這種失敗驅(qū)動(dòng)的開發(fā)模式我認(rèn)為是 Agent 工程化最后能不能走向穩(wěn)定的分水嶺。6. 落地效果與后續(xù)擴(kuò)展6.1 一組真實(shí)的數(shù)據(jù)對(duì)比Agent-Reach 上線后我們拿同一批任務(wù)做過一組前后對(duì)比測試樣本量不大但很能說明問題。指標(biāo)未接入 Agent-Reach接入 Agent-Reach工具調(diào)用成功率62%94%平均單任務(wù)耗時(shí)18s7s人工干預(yù)率33%6%排障平均耗時(shí)2h20min工具成功率從 62% 漲到 94%這個(gè)提升主要來自三處路由檢索讓模型只在 2~3 個(gè)工具里選、參數(shù)校驗(yàn)擋掉了大量低級(jí)錯(cuò)誤、超時(shí)熔斷阻止了無意義的浪費(fèi)重試。人工干預(yù)率暴跌到 6%意味著運(yùn)維同事終于不用每天當(dāng)模型救火隊(duì)員了。6.2 可以往哪些方向繼續(xù)延展Agent-Reach 目前還是一個(gè)偏工具調(diào)用的觸達(dá)引擎但我已經(jīng)在規(guī)劃兩個(gè)新的擴(kuò)展方向。第一個(gè)是多 Agent 協(xié)作的觸達(dá)編排?，F(xiàn)在多個(gè) Agent 之間做任務(wù)交接時(shí)誰去觸達(dá)哪個(gè)工具還挺容易沖突。下一步打算在路由層引入觸達(dá)意向鎖定機(jī)制讓某個(gè)工具被一個(gè) Agent 占用時(shí)其他 Agent 的檢索結(jié)果中自動(dòng)降低該工具的優(yōu)先級(jí)。第二個(gè)是觸達(dá)效果的自動(dòng)回歸評(píng)估?，F(xiàn)在每次改工具定義或模型版本后都需要人來驗(yàn)證觸達(dá)鏈路是否正常。后續(xù)想做一個(gè)定時(shí)任務(wù)用歷史真實(shí)請(qǐng)求回放的方式自動(dòng)跑回歸觸達(dá)測試把觸達(dá)成功率做成一個(gè)持續(xù)觀測的指標(biāo)體系。這套東西做完Agent 的手腳才算真正有了可度量、可治理、可優(yōu)化的狀態(tài)。我現(xiàn)在的習(xí)慣是任何新項(xiàng)目只要涉及 Agent 與外部系統(tǒng)交互就先用 Agent-Reach 把觸達(dá)層跑通再去做復(fù)雜的業(yè)務(wù)編排省下的時(shí)間足夠再做一個(gè)新功能了。