上個(gè)月我把一個(gè)壓了很久的需求徹底重做了讓一個(gè)AI Agent獨(dú)立完成“監(jiān)控指標(biāo)→生成日?qǐng)?bào)→推送到企業(yè)群”整條流水線。第一版我圖省事把查數(shù)據(jù)庫(kù)、算聚合、做圖表、組織文案四件事全塞進(jìn)同一個(gè)Agent的System Prompt里結(jié)果最直觀的表現(xiàn)是——任務(wù)越長(zhǎng)越容易在某一個(gè)中間步驟上崩盤。后來改成多Agent分工新問題立刻冒出來這幾個(gè)Agent彼此根本不認(rèn)識(shí)更不知道誰擅長(zhǎng)什么讓A去找BB反而把請(qǐng)求推回給A。我折騰了一周最終沉淀下來的就是一套叫Agent-Reach的觸達(dá)層。Agent-Reach這個(gè)名字里的“Reach”說的從來不是Agent有多聰明而是它能不能在整個(gè)工作流里“夠得著”正確的協(xié)作對(duì)象和正確的上下文。它的核心價(jià)值可以拆成三件事把Agent的能力變成可見、可查、可校驗(yàn)的列表讓請(qǐng)求按照語義和約束路由到正確的接收者在Agent之間做顯式的上下文對(duì)齊而不是靠模型臨場(chǎng)發(fā)揮。這篇文章我打算把整套思路和代碼級(jí)實(shí)現(xiàn)完整寫出來包括我是怎么設(shè)計(jì)注冊(cè)中心、消息總線和能力描述協(xié)議的也把跑起來之后踩過的四個(gè)深坑原原本本交代一遍。無論你是正在糾結(jié)“單Agent還是多Agent”還是已經(jīng)拆了多個(gè)Agent但發(fā)現(xiàn)它們根本沒法穩(wěn)定協(xié)作這篇都應(yīng)該能給你一個(gè)可以直接落地的參考框架。1. 為什么說“Agent-Reach”解決的是連接而不是智商1.1 單體Agent跑全流程本質(zhì)上是在賭上下文不失控先說說我為什么要把單體Agent拆掉。用單Agent執(zhí)行完整業(yè)務(wù)鏈路時(shí)最容易踩的坑就是System Prompt越來越長(zhǎng)。你把查詢引擎怎么用、分析規(guī)則是什么、報(bào)告模板長(zhǎng)什么樣全部塞進(jìn)去隨著任務(wù)推進(jìn)上下文里塞滿了各階段的中間結(jié)果。每次工具調(diào)用返回的數(shù)據(jù)都完整拼在對(duì)話尾部上下文總量就不再由信息價(jià)值決定而是由中間步驟的數(shù)量決定。我實(shí)際項(xiàng)目里有一個(gè)指標(biāo)單Agent處理一份包含12個(gè)SKU的日?qǐng)?bào)生成任務(wù)到了第八個(gè)SKU數(shù)字開始張冠李戴把A倉(cāng)的銷售額填到了B倉(cāng)的報(bào)告里。當(dāng)時(shí)我根本分不清是提示詞問題還是數(shù)據(jù)問題因?yàn)檎麄€(gè)上下文已經(jīng)膨脹到快5萬token模型注意力的分配早就是一團(tuán)漿糊了。這里要澄清一下我并不是否定單體Agent的價(jià)值。對(duì)于“總結(jié)會(huì)議記錄”這類上下文封閉的任務(wù)單Agent依然是最好的選擇因?yàn)樗妮斎胼敵鲞吔绶浅Ｇ逦?。但跨環(huán)節(jié)業(yè)務(wù)是狀態(tài)開放的你需要把狀態(tài)經(jīng)過多個(gè)工具、多個(gè)職責(zé)節(jié)點(diǎn)傳遞這時(shí)候把所有狀態(tài)都堆在一個(gè)上下文里本身就是瓶頸。拆分責(zé)任是工程選擇而不是模型能力不夠的妥協(xié)。1.2 協(xié)作的瓶頸發(fā)現(xiàn)、路由、上下文對(duì)齊多Agent化之后第一個(gè)真實(shí)沖突點(diǎn)就是“我不知道該找誰”。我在代碼里創(chuàng)建了一堆Agent實(shí)例每個(gè)都很能干但它們?cè)谶\(yùn)行時(shí)完全不知道彼此的存在。你可以在Coordinator的提示詞里寫“你有以下子Agent可用”但這就把協(xié)作完全押在了模型的理解力上。后來我把“觸達(dá)”這件事拆成三個(gè)層面能力發(fā)現(xiàn)每個(gè)Agent提供一份結(jié)構(gòu)化的“自我介紹”包括name、description、input_schema、output_schema注冊(cè)到一個(gè)統(tǒng)一列表里。這個(gè)過程和搜索引擎爬蟲提交站點(diǎn)地圖沒什么區(qū)別核心是讓能力可以被檢索。路由調(diào)度收到一個(gè)請(qǐng)求后決策模塊需要判斷這個(gè)請(qǐng)求該交給哪個(gè)Agent處理。這里既可以用規(guī)則匹配也可以用LLM做語義判斷但關(guān)鍵在于必須有一個(gè)確定性的兜底不能純靠模型猜。上下文對(duì)齊不同Agent對(duì)字段名、時(shí)間格式、單位、分頁(yè)規(guī)則的預(yù)期往往不一樣。比如一個(gè)Agent輸出的date是“2024-08-01”另一個(gè)Agent接收時(shí)要求的是時(shí)間戳。對(duì)齊這件事必須顯式做不能指望Agent自己猜出來。打個(gè)比方這套東西跟企業(yè)總機(jī)的分機(jī)表加前臺(tái)轉(zhuǎn)接沒什么區(qū)別能力發(fā)現(xiàn)就是電話簿路由調(diào)度就是前臺(tái)上下文對(duì)齊就是接線翻譯。Agent-Reach做的不是訓(xùn)練Agent本身而是在協(xié)作體系里把這張電話網(wǎng)搭好讓每個(gè)分機(jī)都?jí)虻弥搲虻弥娜恕?.3 為什么要做成顯式協(xié)議而不是靠提示詞約定有人可能會(huì)問我直接在Coordinator的提示詞里寫“你有以下Agent可用”不也能實(shí)現(xiàn)觸達(dá)嗎表面看能但這里有個(gè)致命問題提示詞約定是不可觀測(cè)的。Agent什么時(shí)候選錯(cuò)了路由、選了之后有沒有調(diào)用成功、調(diào)用失敗之后有沒有按預(yù)期降級(jí)這些過程全都藏在黑盒里出了問題只能靠猜。顯式協(xié)議的價(jià)值在于每個(gè)協(xié)作動(dòng)作都對(duì)應(yīng)一條可查的日志誰提交了注冊(cè)、路由是按什么規(guī)則匹配的、消息在哪個(gè)入站隊(duì)列等了多久、上下文在哪一步做了字段轉(zhuǎn)換。故障定位從“猜模型在想什么”變成了“查記錄”。這也是我把Agent-Reach定位成基礎(chǔ)設(shè)施而不是業(yè)務(wù)代碼的原因它不需要任何Agent變聰明只需要讓每個(gè)協(xié)作動(dòng)作變成可觀察、可追蹤、可控制的操作。2. 一版就跑通的MVP注冊(cè)中心、消息總線與能力描述協(xié)議技術(shù)選型上我用了Python加asyncio沒有引入任何重量級(jí)框架。選它的原因很樸素asyncio的隊(duì)列天然適合做Agent間的消息傳遞每個(gè)Agent的輸入輸出就是JSON消息調(diào)試起來特別直觀。什么分布式消息中間件、服務(wù)網(wǎng)格在MVP階段都不需要。2.1 能力描述文件讓每個(gè)Agent先寫“自我介紹”在Agent-Reach里注冊(cè)的是能力不是Agent實(shí)例本身。每個(gè)Agent在啟動(dòng)時(shí)必須先向注冊(cè)中心提交一份能力描述我用的格式大概長(zhǎng)這樣name: report_agent description: 根據(jù)指標(biāo)數(shù)據(jù)生成日?qǐng)?bào)/周報(bào)支持Markdown和HTML輸出 version: 0.3.1 owner:>import asyncio import time from dataclasses import dataclass, field from typing import Optional, List dataclass class AgentInfo: name: str description: str input_schema: dict output_schema: dict tags: List[str] timeout_hint: int 60 last_heartbeat: float field(default_factorytime.time) healthy: bool True class Registry: def __init__(self): self._agents {} async def register(self, info: AgentInfo): self._agents[info.name] info async def unregister(self, name: str): self._agents.pop(name, None) async def heartbeats(self, name: str): if name in self._agents: self._agents[name].last_heartbeat time.time() self._agents[name].healthy True async def find_by_tag(self, tag: str) - Optional[str]: for info in self._agents.values(): if tag in info.tags: return info.name return None async def find_by_description(self, text: str) - Optional[str]: score_max, name_selected 0, None for info in self._agents.values(): hit sum(word in info.description for word in text.split()) if hit score_max: score_max, name_selected hit, info.name return name_selected if score_max 0 else None async def healthcheck(self, max_stale: int 30): now time.time() for name, info in self._agents.items(): info.healthy (now - info.last_heartbeat) max_stalefind_by_description的實(shí)現(xiàn)方式是把請(qǐng)求文本和每個(gè)Agent的description按詞匹配計(jì)算命中數(shù)取最高分。有人看到這種簡(jiǎn)單做法可能會(huì)覺得太原始但我要強(qiáng)調(diào)它不依賴LLM結(jié)果完全可復(fù)現(xiàn)速度快到可以忽略不計(jì)。我在實(shí)際配置里讓規(guī)則路由先跑如果規(guī)則找不到結(jié)果再讓Coordinator用LLM做一次模糊匹配并且對(duì)LLM選出的結(jié)果做schema校驗(yàn)。規(guī)則兜底永遠(yuǎn)比直接推理更可靠這是多Agent架構(gòu)里最值得堅(jiān)持的原則。2.3 消息總線其實(shí)只需要一個(gè)能超時(shí)和重試的緩沖為了不讓Agent之間直接互相調(diào)用搞出網(wǎng)狀耦合我在中間加了一條簡(jiǎn)單的消息總線。每一條消息統(tǒng)一包成envelope格式如下{ msg_id: 2f9a4f00-1234-abcd-1234, from: coordinator, to: report_agent, trace_id: a1b2c3, type: request, payload: { ... }, credentials: { scope: [read:metrics, write:report] } }失敗時(shí)type變?yōu)閑rror在payload里帶code和message。總線入口邏輯很單一接收消息、檢查目標(biāo)Agent是否注冊(cè)且健康、放入對(duì)應(yīng)隊(duì)列、等待Agent完成或超時(shí)、寫日志。超時(shí)判斷不復(fù)雜用asyncio.wait_for包在響應(yīng)隊(duì)列的get()上超時(shí)后自動(dòng)重試一次。但重試必須小心一個(gè)陷阱不是所有操作都冪等。比如report_agent生成報(bào)告第一次可能已經(jīng)生成了半份結(jié)果你無腦重試對(duì)方就要面對(duì)兩份半成品。我的做法是在payload里帶msg_id目標(biāo)Agent會(huì)先檢查msg_id是否處理過處理過就直接返回上一次結(jié)果這比用各種分布式事務(wù)方案簡(jiǎn)單得多。3. 打通一條完整鏈路數(shù)據(jù)查詢Agent與日?qǐng)?bào)生成Agent的真實(shí)協(xié)作理論說得再多不如直接看一個(gè)真實(shí)鏈路。我拿業(yè)務(wù)方的一個(gè)典型需求舉例每天想看到“銷售額低于閾值10%的分倉(cāng)SKU”然后基于這些數(shù)據(jù)生成一份日?qǐng)?bào)并推送出去。3.1 場(chǎng)景拆解與角色分配以前在單體Agent里處理這個(gè)需求一個(gè)Prompt從頭寫到尾中間橫跨查詢、計(jì)算、報(bào)告生成、發(fā)送四個(gè)環(huán)節(jié)。現(xiàn)在我拆成兩個(gè)Agentdata_query_agent只負(fù)責(zé)查詢數(shù)倉(cāng)返回固定字段的原始指標(biāo)不做判斷不組織文案。report_agent接收指標(biāo)和日期字段負(fù)責(zé)寫報(bào)告、生成圖表、組裝最終輸出。拆分的理由很明確數(shù)據(jù)查詢是強(qiáng)約束操作最好用規(guī)則或API完成結(jié)果必須可復(fù)驗(yàn)而報(bào)告生成是一次模型調(diào)用允許失敗重試。兩者混在一起模型在中間步驟稍微失一下真整個(gè)數(shù)據(jù)鏈路的可信度就完蛋了。3.2 路由鏈路與上下文轉(zhuǎn)換用戶從統(tǒng)一入口說了一句“生成昨天的日?qǐng)?bào)”。Coordinator的處理流程是先用tags里的daily精確找到report_agent。report_agent發(fā)現(xiàn)自己需要原始數(shù)據(jù)但它不知道數(shù)據(jù)API在哪兒于是通過注冊(cè)中心找到data_query_agent。report_agent發(fā)出一條request并在payload里帶上明確的上下文約束timezone8、interval[昨天開始, 昨天結(jié)束)、granularitydaily、min_sales_threshold0.1。上下文轉(zhuǎn)換的核心動(dòng)作發(fā)生在這條request里把自然語言里的“昨天”解析成精確的start_date/end_date把“低于閾值10%”翻譯成API能識(shí)別的min_sales_threshold0.1把返回值統(tǒng)一成雙方約定的字段名sku, warehouse, sales_amount, threshold_ratio。轉(zhuǎn)換必須是顯式步驟不能依賴Agent自己發(fā)揮。我在實(shí)際操作中發(fā)現(xiàn)如果這里不顯式傳時(shí)區(qū)一個(gè)在北京早上九點(diǎn)跑的任務(wù)和一個(gè)在UTC時(shí)間跑的任務(wù)算出來的“昨天”可能差出整整一天。3.3 超時(shí)、降級(jí)與部分失敗的處理數(shù)據(jù)查詢Agent返回之后report_agent開始寫報(bào)告寫完要推送到企業(yè)群于是它再請(qǐng)求notifier_agent。這一步看起來很順但真正考驗(yàn)系統(tǒng)的是失敗場(chǎng)景。我在第2版里設(shè)置過查詢Agent返回超時(shí)并重試仍失敗時(shí)report_agent不再無限等下去而是直接生成一份降級(jí)報(bào)告明確標(biāo)注“XX時(shí)段的銷售數(shù)據(jù)缺失”流程繼續(xù)向前走。這個(gè)設(shè)計(jì)在最初遭到了質(zhì)疑有人說數(shù)據(jù)都不全了還生成什么報(bào)告我的看法是多Agent編排里的每一個(gè)環(huán)節(jié)都是可以獨(dú)立降級(jí)的你追求的不應(yīng)該是“所有環(huán)節(jié)都成功”而是“鏈路走到最后一定會(huì)有一個(gè)結(jié)論哪怕這個(gè)結(jié)論是部分失敗”。當(dāng)業(yè)務(wù)方半夜三點(diǎn)等著看報(bào)告時(shí)一份帶缺失標(biāo)注的報(bào)告比一個(gè)卡死到天亮的任務(wù)有價(jià)值得多。另外一個(gè)經(jīng)驗(yàn)是編排鏈路高度盡量控制在三層以內(nèi)——協(xié)調(diào)層、能力Agent層、數(shù)據(jù)服務(wù)層。層數(shù)一旦到四層以上trace信息形態(tài)就很容易失控每次排查問題都像在一團(tuán)亂麻里找線頭。4. 踩坑實(shí)錄我在這套架構(gòu)里翻過的四個(gè)大坑寫這塊之前我先聲明Agent-Reach這版設(shè)計(jì)不是一次就穩(wěn)的。我前后跑了兩個(gè)月翻了四個(gè)讓我印象非常深的坑每一個(gè)都值得單獨(dú)拿出來說。4.1 死循環(huán)調(diào)用A做不了就推給BB又推回A第一個(gè)版本的System Prompt里我給每個(gè)Agent都加了一句“如果你不確定可以請(qǐng)求其他Agent幫助”。這句看似無害的話實(shí)際運(yùn)行起來差點(diǎn)把系統(tǒng)拖垮。某天日志里出現(xiàn)了一條消息在兩個(gè)Agent之間來回傳播trace_id完全一樣from和to交替出現(xiàn)直到我手動(dòng)把它終止。跑了一會(huì)兒定位到根因report_agent要做一個(gè)翻譯功能它不會(huì)于是調(diào)用assistant_agentassistant_agent也不知道數(shù)據(jù)準(zhǔn)確抓取又推回給report_agent。兩個(gè)Agent都沒有處理能力但提示詞給了它們“可以求助”的權(quán)限于是形成了死循環(huán)。修改方案是兩個(gè)約束一起上第一注冊(cè)中心路由時(shí)禁止“環(huán)形轉(zhuǎn)包”即一個(gè)Agent只能響應(yīng)tags和能力描述匹配的請(qǐng)求不能把屬于自己職責(zé)的請(qǐng)求再推給其他同類Agent第二消息里強(qiáng)制帶max_hop3超過跳數(shù)直接返回錯(cuò)誤。從那以后我把系統(tǒng)里所有Prompt中的“盡量”“你可以嘗試”這類模糊措辭全部清理了一遍——在多Agent架構(gòu)里模糊的授權(quán)就是故障的溫床。4.2 假死比崩潰更麻煩隊(duì)列積壓與重試風(fēng)暴第二個(gè)大坑是假死。某天鏈路突然停下來所有消息都卡在隊(duì)列里不報(bào)錯(cuò)、不返回、也沒崩潰。一開始很難判斷是LLM API在“思考”還是真的卡住了直到我查了API調(diào)用日志發(fā)現(xiàn)一個(gè)Agent在調(diào)用LLM時(shí)超時(shí)了拋了一個(gè)普通異?？蚣芏挷徽f按“失敗重試”處理。結(jié)果多個(gè)Agent同時(shí)交互都沒有退避機(jī)制重試請(qǐng)求被放大成了三倍流量每個(gè)Agent都在反復(fù)撞同一個(gè)失敗點(diǎn)。解決辦法分兩層第一層是給每個(gè)Agent的重試都加上指數(shù)退避和隨機(jī)抖動(dòng)比如第一次等3秒、第二次等9秒、第三次等27秒第二層是全局限制重試次數(shù)不能每個(gè)節(jié)點(diǎn)各自無限重試。假死的另一個(gè)表現(xiàn)是Agent內(nèi)部在跑一個(gè)很長(zhǎng)的工具調(diào)用隊(duì)列遲遲等不到響應(yīng)。后來我在Agent里增加了心跳機(jī)制它每隔30秒?yún)R報(bào)一次當(dāng)前階段狀態(tài)如果心跳停了才判定真死這個(gè)設(shè)計(jì)類似排隊(duì)時(shí)服務(wù)員喊一句“還在辦理請(qǐng)稍等”至少讓你知道系統(tǒng)不是無響應(yīng)。4.3 上下文在鏈路里無限膨脹這是讓我最頭疼的坑。第一版的時(shí)候每條消息都保存完整payload數(shù)據(jù)查詢Agent返回了幾千行結(jié)果report_agent拿到結(jié)果后把整份表格又寫進(jìn)了自己的chain日志然后再原封不動(dòng)地傳給notifier_agent。最后notifier的上下文里躺著三份重復(fù)的原始數(shù)據(jù)表模型已經(jīng)完全分不清哪一份是最新的了。解決方法是做截?cái)嘈鸵?guī)則核心就一句話每個(gè)Agent收到中間結(jié)果后只保留“結(jié)論摘要加結(jié)果引用”原始數(shù)據(jù)統(tǒng)一存在對(duì)象存儲(chǔ)里消息里只放一個(gè)指向原文的鏈接。換句話說鏈路中的上下文像一個(gè)接力棒傳出去的同時(shí)處理串就要縮短。我還在消息封包里加了token預(yù)算字段超過預(yù)算時(shí)原始payload替換為摘要再做一次語義壓縮。舉個(gè)具體例子原來傳給notifier的payload是5000行原始銷售數(shù)據(jù)現(xiàn)在變成{ summary: 銷售額低于閾值10%的分倉(cāng)共3個(gè)主要集中華南區(qū)最大缺口為華南-01倉(cāng), data_ref: s3://report-data/20240801/summary.json }這一改整條鏈路的token開銷直接下降了70%以上而且每個(gè)環(huán)節(jié)要處理的噪音少了很多上下文灌入不正確數(shù)據(jù)的概率也降下來了。4.4 權(quán)限邊界被忽略任何Agent都能調(diào)用所有能力Agent-Reach有一個(gè)隱含假設(shè)“只要Agent能發(fā)現(xiàn)就能調(diào)用”。這個(gè)假設(shè)在內(nèi)網(wǎng)單租戶環(huán)境跑著沒毛病一旦放到多租戶環(huán)境或者涉及用戶數(shù)據(jù)風(fēng)險(xiǎn)立刻冒頭。我遇到的實(shí)際案例是報(bào)表Agent用read:report的scope請(qǐng)求了write:user的能力結(jié)果真的調(diào)用成功了因?yàn)樽?cè)中心只校驗(yàn)了Agent名稱沒有校驗(yàn)scope。后來我改成每個(gè)能力描述里聲明所需scope注冊(cè)中心在路由階段同時(shí)檢查調(diào)用方的scope集合是否覆蓋目標(biāo)能力的scope要求不滿足直接返回403。這里有個(gè)細(xì)節(jié)權(quán)限校驗(yàn)一定不要放在Agent內(nèi)部代碼里。Agent的代碼邏輯可以被提示詞影響你沒法保證模型在運(yùn)行過程中不會(huì)自主“繞過”一段看似多余的校驗(yàn)。放在注冊(cè)中心和消息總線入口的強(qiáng)制過濾才是最可靠的因?yàn)槟且欢问羌円?guī)則判斷不涉及推理。5. 什么時(shí)候真正適合引入Agent-Reach寫到最后我必須說一句常被忽略的話并不是所有場(chǎng)景都該上多Agent架構(gòu)Agent-Reach也不例外。如果你根本不需要多個(gè)Agent分工這個(gè)框架只會(huì)白白增加復(fù)雜度。5.1 用這把尺子決定任務(wù)能否被切分中間狀態(tài)能否被顯式傳遞如果出現(xiàn)下面兩種情況之一你多半不需要Agent-Reach任務(wù)高度連貫、無法拆分。比如一段需要全局上下文才能做好的創(chuàng)意寫作拆給多個(gè)Agent反而會(huì)丟失整體風(fēng)格。中間狀態(tài)很難用JSON表達(dá)。比如一個(gè)依賴實(shí)時(shí)交互和視覺反饋的復(fù)雜任務(wù)硬拆開會(huì)讓進(jìn)度和狀態(tài)都無法傳遞。真正適合的場(chǎng)景是任務(wù)流相對(duì)固定中間狀態(tài)可以結(jié)構(gòu)化且每個(gè)環(huán)節(jié)允許獨(dú)立重試和降級(jí)。拿數(shù)據(jù)分析加報(bào)告推送來說數(shù)據(jù)查詢的結(jié)果是標(biāo)準(zhǔn)JSON報(bào)告生成的輸出是字符串推送動(dòng)作就一個(gè)回調(diào)——這種結(jié)構(gòu)天然適合多Agent協(xié)作。5.2 三檔接入方案不是所有團(tuán)隊(duì)第一步就要上完整的注冊(cè)中心加LLM路由我建議按下面三檔逐步演進(jìn)方案接入改動(dòng)適合團(tuán)隊(duì)路由確定性排查成本人肉路由只做分工腳本請(qǐng)求人工轉(zhuǎn)發(fā)剛接觸多Agent想驗(yàn)證分工收益100%人判斷低因?yàn)椴襟E少規(guī)則路由MVP注冊(cè)中心tags匹配規(guī)則兜底分工已明確希望減少人工介入中等依賴描述質(zhì)量中日志可查L(zhǎng)LM路由權(quán)限控制完整注冊(cè)中心LLM模糊匹配scope校驗(yàn)請(qǐng)求語義多樣需要靈活分發(fā)高但引入不確定性高需要品牌級(jí)追蹤我個(gè)人的建議是先從人肉路由開始大概跑兩周看清楚每個(gè)Agent的真實(shí)分工邊界再升級(jí)到規(guī)則路由。直接跳到LLM路由是非常容易踩坑的你可能連路由錯(cuò)了都不知道。5.3 效果度量與回滾方法引入框架后我主要盯這幾個(gè)指標(biāo)端到端任務(wù)成功率。平均鏈路跳數(shù)與p95時(shí)延。失敗定位時(shí)間也就是從故障發(fā)生到定位到具體環(huán)節(jié)需要多久。上下文字均值對(duì)比拆分前降了多少。重試率與降級(jí)率。這幾項(xiàng)指標(biāo)里失敗定位時(shí)間是最能體現(xiàn)Agent-Reach價(jià)值的指標(biāo)。以前單Agent出了問題我要靠反復(fù)調(diào)提示詞去猜現(xiàn)在多Agent鏈路上出了問題我打開trace日志就能看到是哪一環(huán)返回了錯(cuò)誤碼。排查時(shí)間從小時(shí)級(jí)降到了分鐘級(jí)這本身就是拆分最大的回報(bào)。另外架構(gòu)上要保留回滾能力。一旦發(fā)現(xiàn)拆分后的端到端成功率反而不如原來的單體Agent我會(huì)一鍵把路由規(guī)則改成直連單個(gè)Agent。Agent-Reach存在的意義是讓系統(tǒng)具備“按需協(xié)作”的能力而不是強(qiáng)迫你永遠(yuǎn)處在一個(gè)復(fù)雜的協(xié)作模式里。我現(xiàn)在的習(xí)慣是先在固定結(jié)構(gòu)任務(wù)里用Agent-Reach比如周報(bào)、數(shù)據(jù)校驗(yàn)、定時(shí)巡檢這類邊界清晰、狀態(tài)可傳遞的場(chǎng)景暫時(shí)不讓它碰開放性特別強(qiáng)、錯(cuò)誤代價(jià)特別高的動(dòng)作。連接能力落地之后如果模型業(yè)務(wù)確實(shí)處理得不好至少我們能在幾秒鐘之內(nèi)定位到問題出在哪一環(huán)而不是在漆黑一片里到處亂猜。這種“可定位”的價(jià)值說真的比多Agent本身還要值錢。