1. 這個(gè)項(xiàng)目到底在解決什么問(wèn)題做AI應(yīng)用這行最郁悶的事不是模型不夠聰明而是模型想干活卻夠不著真實(shí)業(yè)務(wù)系統(tǒng)。我在幾個(gè)項(xiàng)目里都遇到過(guò)同一個(gè)怪圈模型對(duì)話能力已經(jīng)很能打了可一旦涉及幫我查個(gè)庫(kù)存把這份報(bào)表發(fā)給財(cái)務(wù)把異常訂單標(biāo)記一下這種具體動(dòng)作大模型就卡住了——它能理解、能規(guī)劃但真的要去調(diào)內(nèi)部系統(tǒng)、寫數(shù)據(jù)庫(kù)、觸發(fā)工作流鏈路全斷。業(yè)內(nèi)把這叫智能體的最后一公里問(wèn)題說(shuō)白了就是Agent能思考但觸達(dá)不到業(yè)務(wù)現(xiàn)場(chǎng)。Agent-Reach這個(gè)項(xiàng)目本質(zhì)上就是解決最后一公里的觸達(dá)問(wèn)題。它是一套面向智能體Agent的通用觸達(dá)中間層把模型決策和真實(shí)業(yè)務(wù)動(dòng)作之間那層薄薄的但極其關(guān)鍵的黏合層做了標(biāo)準(zhǔn)化處理。簡(jiǎn)單說(shuō)它解決了三件事讓Agent能安全地調(diào)外部工具、讓Agent能把一次想法變成一次真實(shí)可回滾的執(zhí)行、讓Agent在執(zhí)行過(guò)程中可以被觀測(cè)和中斷。這個(gè)方向是我從實(shí)際項(xiàng)目里長(zhǎng)出來(lái)的需求。早期做客服機(jī)器人的時(shí)候讓機(jī)器人查訂單狀態(tài)寫死了接口換一個(gè)業(yè)務(wù)線就得重寫一套后來(lái)做大模型自動(dòng)工單系統(tǒng)模型在復(fù)雜場(chǎng)景下自己亂選工具調(diào)錯(cuò)接口的后果很嚴(yán)重。你會(huì)發(fā)現(xiàn)模型的聰明程度反而不是瓶頸瓶頸在于你給它的手到底伸得夠不夠穩(wěn)。Agent-Reach就是這雙手的標(biāo)準(zhǔn)化方案。這篇內(nèi)容適合兩類人一類是正在做AI Agent應(yīng)用、被工具調(diào)用和系統(tǒng)對(duì)接折磨的開發(fā)者另一類是想搞清楚Agent從演示到生產(chǎn)環(huán)境到底差在哪幾步的產(chǎn)品和技術(shù)負(fù)責(zé)人。這篇文章就是我自己從零搭這套觸達(dá)層的全過(guò)程復(fù)盤包含架構(gòu)思路、實(shí)打?qū)嵉拇a細(xì)節(jié)以及線上踩過(guò)的坑。2. 觸達(dá)層設(shè)計(jì)的三個(gè)底層問(wèn)題2.1 不是要連接而是要可管理地連接剛開始做Agent工具接入時(shí)很多人第一反應(yīng)是給Agent寫一堆函數(shù)調(diào)用讓模型去調(diào)。這種方式的毛病在真實(shí)場(chǎng)景里會(huì)很快暴露模型幻覺發(fā)作時(shí)可能把禁用用戶當(dāng)統(tǒng)計(jì)用戶調(diào)了或者一個(gè)流程執(zhí)行到一半因?yàn)槌瑫r(shí)掛了你連它在哪一步掛的都查不到。Agent-Reach在設(shè)計(jì)時(shí)我強(qiáng)制自己回答一個(gè)問(wèn)題這套觸達(dá)層是給誰(shuí)用的答案分兩頭——給Agent用它需要簡(jiǎn)單、確定的接口給開發(fā)者和運(yùn)維用它需要可觀測(cè)、可控制、可回滾。這兩個(gè)需求疊在一起意味著不能簡(jiǎn)單把幾十個(gè)函數(shù)塞給模型而是要有一層注冊(cè)、鑒權(quán)、路由、重試、審計(jì)的中間控制面。打個(gè)比方你家里各種電器直接用電線搭在一起也能轉(zhuǎn)但真正住得安心靠的是配電箱——每個(gè)回路有開關(guān)、有保險(xiǎn)絲、有標(biāo)識(shí)。Agent-Reach就是Agent的配電箱它的核心產(chǎn)出不是通而是安全地通、出了事能知道是哪個(gè)回路出了問(wèn)題。2.2 為什么把工具調(diào)用設(shè)計(jì)成聲明式而不是硬編碼項(xiàng)目里所有工具都不是直接寫死函數(shù)調(diào)用而是用一套標(biāo)準(zhǔn)化的聲明式配置把能力暴露給Agent。每個(gè)工具都有名稱、描述、入?yún)chema、執(zhí)行端點(diǎn)、權(quán)限級(jí)別、超時(shí)時(shí)間、失敗策略這些元信息。這樣做的好處是延遲綁定。你可以在不改Agent代碼的前提下把一個(gè)工具從模擬環(huán)境切到生產(chǎn)環(huán)境或者把某個(gè)危險(xiǎn)操作從允許執(zhí)行降級(jí)為必須人工審批。如果所有工具調(diào)用都寫死在Agent實(shí)現(xiàn)里這些運(yùn)維層面的靈活性全沒了。我用了OpenAPI Schema的子集來(lái)定義每個(gè)觸達(dá)動(dòng)作Agent只讀這份聲明然后通過(guò)統(tǒng)一執(zhí)行通道發(fā)起請(qǐng)求。人說(shuō)Agent像有了手更準(zhǔn)確的說(shuō)法是Agent有了一份能力清單清單后面的執(zhí)行細(xì)節(jié)由觸達(dá)層兜底。這樣做模型不需要知道工具的真實(shí)地址、鑒權(quán)方式、底層實(shí)現(xiàn)它只需要理解這個(gè)工具是干什么的、入?yún)㈤L(zhǎng)什么樣。2.3 設(shè)計(jì)原則寧可讓Agent多問(wèn)一次不讓它瞎調(diào)一次這是我在這套系統(tǒng)里反復(fù)權(quán)衡后定下的最重要原則。Agent自主性再高在觸達(dá)外部系統(tǒng)時(shí)也必須遵守邊界。Agent-Reach里有一個(gè)全局路由策略按工具的風(fēng)險(xiǎn)級(jí)別劃分成三類——只讀類、寫操作類、高危類。只讀類的查詢工具查庫(kù)存、查訂單狀態(tài)允許Agent自由調(diào)用寫操作類創(chuàng)建工單、發(fā)送通知要求Agent在內(nèi)部先把完整的參數(shù)組合好由觸達(dá)層做一次業(yè)務(wù)校驗(yàn)校驗(yàn)不過(guò)直接打回高危類刪除數(shù)據(jù)、批量修改、涉及錢的接口必須走人工審批回調(diào)Agent發(fā)起請(qǐng)求后掛在pending狀態(tài)等審批人確認(rèn)才真正放行。這個(gè)設(shè)計(jì)初看犧牲了一點(diǎn)效率但線上跑起來(lái)你會(huì)發(fā)現(xiàn)它才是讓業(yè)務(wù)方愿意把Agent放上生產(chǎn)環(huán)境的定心丸。沒有這層控制Agent一次錯(cuò)誤調(diào)用可能直接讓你一個(gè)月白干。3. 核心模塊拆解與實(shí)現(xiàn)3.1 能力注冊(cè)中心Agent的能力清單生成流程項(xiàng)目里最基礎(chǔ)的模塊是能力注冊(cè)中心。每接入一個(gè)新工具開發(fā)只需要寫一個(gè)工具描述文件聲明接口地址、方法、入?yún)?、出參和?quán)限等級(jí)。觸達(dá)層啟動(dòng)時(shí)會(huì)掃描這些文件自動(dòng)生成一份聚合后的Agent工具列表。這里面有幾個(gè)關(guān)鍵細(xì)節(jié)。工具描述里的描述字段不能隨便寫。剛開始我吃過(guò)虧描述寫得太模糊比如給用戶發(fā)送消息Agent就會(huì)在模棱兩可時(shí)亂調(diào)用。后來(lái)我把描述改成帶約束條件的句式僅當(dāng)用戶明確要求通知對(duì)方時(shí)調(diào)用需要接收方手機(jī)號(hào)和通知正文。模型再看這份描述誤調(diào)率直線下降。工具描述的撰寫本質(zhì)上是在教模型判斷什么時(shí)候不要用這個(gè)工具這一點(diǎn)很多人會(huì)忽略。另一個(gè)細(xì)節(jié)是入?yún)chema必須做嚴(yán)格校驗(yàn)。千萬(wàn)不要相信模型輸出的參數(shù)一定符合格式。我在Schema校驗(yàn)層用了嚴(yán)格的類型檢查和必填項(xiàng)檢查一旦模型漏傳必填參數(shù)直接返回結(jié)構(gòu)化錯(cuò)誤信息告訴模型缺了什么讓它補(bǔ)全后重試。實(shí)測(cè)下來(lái)這個(gè)策略能讓Agent最終成功調(diào)用的比例穩(wěn)定在95%以上。3.2 統(tǒng)一執(zhí)行引擎一次觸達(dá)請(qǐng)求的完整生命周期觸達(dá)層收到Agent的調(diào)用請(qǐng)求后執(zhí)行引擎按固定管線處理。整個(gè)鏈路依次為請(qǐng)求到達(dá) - 鑒權(quán) - Schema校驗(yàn) - 風(fēng)險(xiǎn)評(píng)估 - 動(dòng)態(tài)路由 - 執(zhí)行適配 - 結(jié)果歸一化 - 審計(jì)落庫(kù)。鑒權(quán)環(huán)節(jié)做兩件事驗(yàn)證Agent身份、校驗(yàn)Agent對(duì)該工具的操作權(quán)限。身份這塊我用了固定的API Key加請(qǐng)求簽名每個(gè)Agent實(shí)例分配獨(dú)立密鑰出了問(wèn)題可以快速定位是哪個(gè)實(shí)例在惹事。風(fēng)險(xiǎn)評(píng)估環(huán)節(jié)會(huì)對(duì)照工具注冊(cè)時(shí)的安全等級(jí)決定請(qǐng)求是直接放行、進(jìn)入審批隊(duì)列還是直接攔下。執(zhí)行適配層是觸達(dá)層和真實(shí)系統(tǒng)交互的地方。每個(gè)工具描述文件里可以指定適配器類型比如HTTP適配器、數(shù)據(jù)庫(kù)適配器、消息隊(duì)列適配器。寫操作統(tǒng)一走異步任務(wù)先返回給Agent一個(gè)任務(wù)已受理的憑證Agent拿著憑證可以輪詢?nèi)蝿?wù)狀態(tài)。這里有個(gè)設(shè)計(jì)取舍為什么不所有動(dòng)作都同步執(zhí)行因?yàn)檎鎸?shí)業(yè)務(wù)系統(tǒng)往往有處理耗時(shí)如果讓Agent和請(qǐng)求方一直掛著等待超時(shí)風(fēng)險(xiǎn)極高。異步化能很好地解耦慢操作。結(jié)果歸一化也很講究。不同工具的返回格式五花八門有的返回JSON數(shù)組有的返回嵌套結(jié)構(gòu)。我在適配器出口做了一層轉(zhuǎn)換統(tǒng)一成成功/失敗結(jié)構(gòu)化數(shù)據(jù)人類可讀摘要的三元組格式。Agent拿到這個(gè)格式不需要再去解析各種奇怪的報(bào)文就能繼續(xù)規(guī)劃下一步動(dòng)作。3.3 執(zhí)行上下文管理讓Agent記得住自己干到哪了Agent執(zhí)行一個(gè)多步驟任務(wù)時(shí)最怕的就是干到一半把前面干過(guò)什么忘了。Agent-Reach引入了執(zhí)行上下文Conversation Context機(jī)制它不只存對(duì)話歷史還把工具調(diào)用的狀態(tài)也一并維護(hù)起來(lái)。比如Agent要在一次任務(wù)里依次調(diào)用查詢用戶信息 - 查詢?cè)撚脩舻挠唵瘟斜?- 給用戶發(fā)送優(yōu)惠券觸達(dá)層會(huì)把每一步的調(diào)用結(jié)果摘要追加到上下文里。每一步執(zhí)行前Agent可以從上下文里拿到前置步驟的結(jié)果不需要自己腦補(bǔ)。這個(gè)機(jī)制在模型上下文窗口有限的情況下尤其救命。上下文管理模塊同時(shí)負(fù)責(zé)設(shè)置時(shí)效。默認(rèn)每個(gè)任務(wù)上下文的存活時(shí)間是30分鐘超時(shí)自動(dòng)歸檔。這在線上很有用——用戶可以上午發(fā)起流程下午回來(lái)說(shuō)繼續(xù)之前那個(gè)事Agent直接把歸檔的任務(wù)重新激活而不是從頭再來(lái)一遍。這一段是我覺得最能讓用戶感知到這Agent有點(diǎn)聰明的地方。4. 實(shí)操過(guò)程記錄從零搭一個(gè)可用的觸達(dá)鏈路4.1 環(huán)境準(zhǔn)備與基礎(chǔ)配置我建議你在開始前準(zhǔn)備一臺(tái)干凈的Linux服務(wù)器我用的是Ubuntu 22.042核4G起步因?yàn)楹竺嬉躊ython服務(wù)加一個(gè)輕量級(jí)的任務(wù)隊(duì)列。裝好Python 3.10以上版本Node.js LTS版本也要裝項(xiàng)目里有部分適配器用Node寫會(huì)更順手?；A(chǔ)依賴我用一個(gè)requirements文件管理核心包括FastAPI做控制面API、Pydantic做Schema校驗(yàn)、Redis做任務(wù)隊(duì)列和上下文緩存、SQLAlchemy做審計(jì)日志存儲(chǔ)。裝依賴時(shí)有一點(diǎn)要注意不要直接裝最新版本FastAPI和Pydantic的版本兼容性偶爾會(huì)鬧脾氣我實(shí)測(cè)用的是FastAPI 0.110系列配Pydantic 2.6系列穩(wěn)定跑了一整個(gè)周期。配置項(xiàng)集中在config.yaml里最關(guān)鍵的是三塊Redis連接串、工具描述文件的掃描路徑、審計(jì)日志的存儲(chǔ)級(jí)別。存儲(chǔ)級(jí)別建議線上開full模式把每次調(diào)用的全量報(bào)文都記錄下來(lái)排查問(wèn)題的時(shí)候翻日志能省半天時(shí)間。4.2 寫一個(gè)真實(shí)的工具描述文件并跑通調(diào)用我拿一個(gè)實(shí)際業(yè)務(wù)場(chǎng)景舉例給Agent接入一個(gè)查詢快遞物流軌跡的工具。工具描述文件的核心長(zhǎng)這樣以YAML為例name: express_tracking_query description: 僅當(dāng)用戶詢問(wèn)快遞物流軌跡時(shí)調(diào)用入?yún)⑽锪鲉翁?hào)需為用戶主動(dòng)提供或從訂單詳情中提取 risk_level: readonly adapter: http endpoint: /api/v1/express/{tracking_no} method: GET timeout: 8 parameters: - name: tracking_no type: string required: true description: 快遞物流單號(hào) output_schema: status: string route: - location: string time: string status_text: string這里description和風(fēng)險(xiǎn)等級(jí)是核心前者決定模型是否在合理時(shí)機(jī)調(diào)用后者決定請(qǐng)求是否進(jìn)入輕量通道。文件放到掃描目錄后重啟觸達(dá)層API文檔里會(huì)自動(dòng)多出這個(gè)工具Agent就能感知到它的存在。跑調(diào)用驗(yàn)證時(shí)我建議先直接用curl測(cè)控制面接口模擬Agent發(fā)起調(diào)用請(qǐng)求curl -X POST http://localhost:8000/v1/agent/reach \ -H X-Agent-Key: your_key_here \ -H Content-Type: application/json \ -d { tool: express_tracking_query, parameters: {tracking_no: SF1234567890} }正常返回應(yīng)該是一個(gè)標(biāo)準(zhǔn)化的結(jié)果結(jié)構(gòu)。如果返回的是參數(shù)校驗(yàn)錯(cuò)誤說(shuō)明模型給的參數(shù)不對(duì)頭需要回看是Schema定義的問(wèn)題還是Agent上下文里壓根沒拿到單號(hào)。這一步我踩過(guò)坑一開始讓模型自己從文本里猜單號(hào)結(jié)果幻覺率很高后來(lái)干脆要求必須先調(diào)用提取實(shí)體工具讓單號(hào)顯式出現(xiàn)在上下文里再調(diào)物流查詢準(zhǔn)確率直接拉滿。4.3 接入異步審批流的配置方式高危操作接入審批流是生產(chǎn)上線前的必修課。審批回調(diào)我接的是企業(yè)微信機(jī)器人原理很簡(jiǎn)單觸達(dá)層檢測(cè)到高危工具請(qǐng)求進(jìn)入pending狀態(tài)同時(shí)往企業(yè)微信群里推送一條審批卡片卡片里帶著同意或拒絕的回調(diào)地址。審批人點(diǎn)了按鈕觸達(dá)層收到回調(diào)要么放行要么終止。配置里需要指定審批人的身份標(biāo)識(shí)列表不在列表里的人點(diǎn)了按鈕不生效。審批超時(shí)時(shí)間我設(shè)置為15分鐘超時(shí)自動(dòng)拒絕。這樣設(shè)計(jì)的理由是高危操作寧可不做也不能拖到業(yè)務(wù)狀態(tài)變化了再執(zhí)行。審批流上線后的一個(gè)月內(nèi)業(yè)務(wù)方提過(guò)不少優(yōu)化建議其中最有價(jià)值的是要求審批卡片顯示Agent規(guī)劃這條操作的完整理由鏈而不只是孤零零的操作參數(shù)。我在審批回調(diào)里把上下文摘要一并帶上這樣審批人能看到Agent是因?yàn)槭裁丛?、看到了什么信息才決定做這個(gè)操作。有了這個(gè)信息審批通過(guò)率反而提高了因?yàn)槿说臎Q策依據(jù)更充分了。4.4 關(guān)鍵參數(shù)計(jì)算超時(shí)與重試策略超時(shí)和重試是觸達(dá)層穩(wěn)定性的基石。我按工具類型分別設(shè)置超時(shí)閾值只讀類工具的默認(rèn)超時(shí)是8秒寫入類工具是20秒異步任務(wù)類的初次提交請(qǐng)求只要3秒確認(rèn)即可。超時(shí)后的重試策略需要考慮冪等性只讀類可以直接重試寫入類要看端點(diǎn)是否支持冪等鍵支持的話帶上相同冪等鍵重試才安全。不要小看這個(gè)細(xì)節(jié)。網(wǎng)上很多教程會(huì)籠統(tǒng)地說(shuō)加個(gè)重試機(jī)制就好了但真實(shí)系統(tǒng)里不帶冪等約束的重試等于給業(yè)務(wù)系統(tǒng)制造重復(fù)數(shù)據(jù)。我在Agent-Reach里給每個(gè)寫請(qǐng)求自動(dòng)附加一個(gè)請(qǐng)求ID冪等鍵在適配器里透?jìng)鹘o下游服務(wù)下游服務(wù)去重后返回原結(jié)果。這套邏輯做完后重試從危險(xiǎn)的補(bǔ)救動(dòng)作變成了安全的保障動(dòng)作。5. 線上運(yùn)行避坑指南問(wèn)題與排查實(shí)錄5.1 模型反復(fù)調(diào)用同一個(gè)工具的循環(huán)問(wèn)題真實(shí)場(chǎng)景里遇到過(guò)Agent在連續(xù)幾次失敗后還是一個(gè)勁地重試同一個(gè)工具不給用戶任何反饋。排查下來(lái)發(fā)現(xiàn)是兩方面的原因一是工具返回的錯(cuò)誤信息太抽象模型沒意識(shí)到自己在原地打轉(zhuǎn)二是Agent沒有嘗試次數(shù)上限的概念。解決方案是在觸達(dá)層做了一次外部干預(yù)當(dāng)同一個(gè)工具在同一次任務(wù)里連續(xù)調(diào)用超過(guò)3次且均為失敗時(shí)觸達(dá)層強(qiáng)制中斷并把控制權(quán)交還給Agent主對(duì)話流程附帶一句提示同一工具連續(xù)失敗已達(dá)上限建議換個(gè)方案或向用戶確認(rèn)。這個(gè)問(wèn)題在Agent應(yīng)用里很有代表性——模型可以聰明但系統(tǒng)需要有護(hù)欄不能把決策都交給模型自己判斷。5.2 上下文里塞了太多無(wú)用信息怎么處理執(zhí)行上下文如果什么都往里塞很快會(huì)撐爆模型的有效注意力。我用的是雙軌上下文一個(gè)高層的任務(wù)狀態(tài)摘要記錄核心信息比如用戶ID、訂單號(hào)、當(dāng)前步驟結(jié)果保持精簡(jiǎn)另一個(gè)是詳細(xì)執(zhí)行記錄全量存Redis但默認(rèn)不隨每次請(qǐng)求發(fā)給模型。只有Agent判定需要追溯細(xì)節(jié)時(shí)才通過(guò)一個(gè)特殊工具去拉詳細(xì)記錄。這個(gè)機(jī)制讓每次發(fā)給模型的消息體積控制在合理范圍內(nèi)同時(shí)保留了問(wèn)題排查時(shí)全量追溯的能力。經(jīng)驗(yàn)是給模型喂信息要像做匯報(bào)一樣給結(jié)論、給關(guān)鍵字段不要一股腦把日志倒給人家。5.3 高頻只讀工具把下游系統(tǒng)打爆怎么辦有一次做性能壓測(cè)發(fā)現(xiàn)Agent在某個(gè)業(yè)務(wù)流程里高頻調(diào)查詢庫(kù)存下游倉(cāng)儲(chǔ)系統(tǒng)的接口被每秒幾十次請(qǐng)求打滿響應(yīng)時(shí)間直線飆升。問(wèn)題的根源是Agent的規(guī)劃里出現(xiàn)了重復(fù)查詢——它自己沒記住剛查過(guò)。觸達(dá)層加了兩層優(yōu)化短時(shí)間內(nèi)的相同查詢直接命中Redis緩存對(duì)于高頻只讀工具配置了輕量級(jí)的并發(fā)限制。每個(gè)Agent實(shí)例對(duì)同一只讀工具的最大并發(fā)數(shù)限制為2超出后請(qǐng)求排隊(duì)等待。這兩層加起來(lái)下游系統(tǒng)的壓力峰值直接降了一個(gè)數(shù)量級(jí)。上線后我的體會(huì)是觸達(dá)層不僅要能調(diào)用還得聰明地調(diào)用緩存和限流必須從第一天就考慮進(jìn)去。5.4 常見問(wèn)題快速排查表現(xiàn)象排查思路處理建議Agent調(diào)用工具返回401檢查Agent實(shí)例的API Key和請(qǐng)求簽名是否過(guò)期重新生成密鑰檢查服務(wù)器時(shí)鐘偏差Schema校驗(yàn)一直提示缺參數(shù)工具描述文件中的必填字段標(biāo)記錯(cuò)誤或模型上下文里就沒有那個(gè)參數(shù)檢查參數(shù)來(lái)源是否在上下文中有記錄Agent總是選錯(cuò)工具工具描述里的description寫得太模糊模型分不清邊界重寫描述明確觸發(fā)條件和禁止觸發(fā)的場(chǎng)景審批回調(diào)收不到通知檢查回調(diào)地址是否公網(wǎng)可達(dá)、審批超時(shí)時(shí)間是否過(guò)短用測(cè)試卡片驗(yàn)證調(diào)大超時(shí)閾值異步任務(wù)狀態(tài)一直不更新下游系統(tǒng)執(zhí)行完成但沒回調(diào)或回調(diào)被網(wǎng)絡(luò)攔截檢查適配器日志確認(rèn)回調(diào)路徑這個(gè)表是我在項(xiàng)目群答疑時(shí)反復(fù)用到的幾乎覆蓋了接手這套系統(tǒng)的人最容易碰到的五個(gè)問(wèn)題。遇到問(wèn)題時(shí)按表排查九成情況能在十分鐘內(nèi)定位根因。6. 項(xiàng)目可復(fù)用的擴(kuò)展方向與心得Agent-Reach的這套模式跑通之后我最大的感觸是它天然可以作為一個(gè)通用基礎(chǔ)件復(fù)用到很多場(chǎng)景。比如你團(tuán)隊(duì)里已經(jīng)有各種業(yè)務(wù)API想快速讓Agent具備調(diào)用能力直接把API封裝成工具描述文件注冊(cè)進(jìn)觸達(dá)層就完事了想給Agent接入一套嚴(yán)謹(jǐn)?shù)膶徟鞒滩挥酶腁gent本身只調(diào)整工具的風(fēng)險(xiǎn)等級(jí)配置。我后來(lái)把觸達(dá)層和一個(gè)內(nèi)部的數(shù)據(jù)分析Agent項(xiàng)目打通Agent從只能聊分析思路升級(jí)成能直接跑預(yù)設(shè)的分析模板并把結(jié)果推送到協(xié)作群里。這個(gè)改造過(guò)程不到一個(gè)下午就完成了因?yàn)锳gent不需要知道數(shù)據(jù)分析是怎么執(zhí)行的它只負(fù)責(zé)在正確時(shí)機(jī)調(diào)用觸達(dá)層提供的run_analysis工具。這件事讓我確信控制面和執(zhí)行面分離的架構(gòu)在Agent應(yīng)用領(lǐng)域有著很大的擴(kuò)展空間。從幾次迭代項(xiàng)目中沉淀下來(lái)的個(gè)人體會(huì)是做Agent應(yīng)用別把全部注意力放在模型的推理能力上更值得投入的是觸達(dá)層的工程化程度。模型再聰明也撐不起一個(gè)沒有護(hù)欄的執(zhí)行環(huán)境。把工具注冊(cè)、風(fēng)險(xiǎn)評(píng)估、執(zhí)行審計(jì)、上下文管理這四件事做好Agent從能聊天到能干活之間的距離其實(shí)沒有想象中那么遠(yuǎn)。最后再分享一個(gè)細(xì)節(jié)這套系統(tǒng)上線后我把Agent調(diào)高危工具的權(quán)限日志單獨(dú)做成周報(bào)發(fā)給業(yè)務(wù)團(tuán)隊(duì)看。這個(gè)動(dòng)作對(duì)建立信任幫助巨大——當(dāng)人們看得到Agent每一步操作的記錄時(shí)讓它去碰核心業(yè)務(wù)這件事就變得沒那么可怕了。