我之前在帶一個(gè)多Agent協(xié)作項(xiàng)目的時(shí)候最大的感受不是模型不夠聰明而是Agent之間根本“夠不著”。團(tuán)隊(duì)里每個(gè)Agent都能完成自己的子任務(wù)但真正要把它們串成一條完整業(yè)務(wù)鏈路時(shí)到處都在碰壁。有的Agent沒有對(duì)外服務(wù)接口有的Agent能力描述寫得模棱兩可調(diào)用方根本不知道它到底能干什么還有的Agent在高峰期直接超時(shí)整個(gè)流程跟著雪崩。后來(lái)我把這套觸達(dá)和路由機(jī)制單獨(dú)抽出來(lái)做成了一個(gè)獨(dú)立的運(yùn)行時(shí)組件取名叫Agent-Reach。這個(gè)項(xiàng)目做的事情并不復(fù)雜把所有Agent的能力注冊(cè)成一個(gè)可檢索的目錄上層調(diào)用方只發(fā)自然語(yǔ)言請(qǐng)求由Agent-Reach負(fù)責(zé)意圖識(shí)別、能力匹配、路由轉(zhuǎn)發(fā)和結(jié)果回傳。相當(dāng)于給整個(gè)Agent體系裝了一個(gè)“調(diào)度中樞服務(wù)網(wǎng)關(guān)”。我現(xiàn)在把完整的方案、實(shí)現(xiàn)思路和踩過(guò)的坑整理出來(lái)希望對(duì)正在搞Agent工程化的朋友有幫助尤其是卡在“多個(gè)Agent不知道怎么連起來(lái)”這個(gè)階段的團(tuán)隊(duì)。1. Agent-Reach是什么先解決“夠不著”的問(wèn)題要理解Agent-Reach得先看看Agent落地時(shí)普遍存在的三個(gè)痛點(diǎn)。不是說(shuō)模型能力不行而是工程側(cè)的基礎(chǔ)設(shè)施完全沒跟上。1.1 Agent落地時(shí)最讓人頭疼的三件事第一個(gè)痛點(diǎn)是能力孤島。每個(gè)Agent都是獨(dú)立開發(fā)的有的用FastAPI起了HTTP服務(wù)有的接的是消息隊(duì)列還有的干脆是腳本定時(shí)跑。對(duì)外暴露的接口風(fēng)格千奇百怪有的接受JSON有的要form-data有的甚至要傳復(fù)雜的嵌套結(jié)構(gòu)。調(diào)用方每對(duì)接一個(gè)Agent就要讀一遍它的文檔寫一套定制化調(diào)用邏輯。這個(gè)成本在小規(guī)模試點(diǎn)時(shí)還能忍一旦Agent數(shù)量超過(guò)五個(gè)基本就是維護(hù)噩夢(mèng)。第二個(gè)痛點(diǎn)是能力描述缺失。大多數(shù)Agent沒有標(biāo)準(zhǔn)化的“能力說(shuō)明”你不知道它擅長(zhǎng)什么、不擅長(zhǎng)什么、期望什么輸入、返回什么結(jié)構(gòu)。這導(dǎo)致上層在編排任務(wù)時(shí)只能靠硬編碼寫死“這個(gè)需求找天氣Agent那個(gè)需求找訂單Agent”一旦Agent接口變了或者新增了一個(gè)Agent所有編排邏輯都要跟著改。第三個(gè)痛點(diǎn)是運(yùn)行狀態(tài)不可見。調(diào)用方發(fā)了一個(gè)請(qǐng)求過(guò)去Agent到底收到?jīng)]有是還在處理還是已經(jīng)掛了為什么這個(gè)Agent響應(yīng)要3秒那個(gè)只要300毫秒全鏈路沒有任何觀測(cè)手段。出了問(wèn)題只能一個(gè)一個(gè)Agent日志翻效率極低。這三個(gè)痛點(diǎn)單拎出來(lái)每個(gè)都好解決但放到一起就成了系統(tǒng)工程。Agent-Reach正是沖著這三個(gè)問(wèn)題去的。1.2 Reach不是Connect從設(shè)計(jì)理念看項(xiàng)目定位項(xiàng)目取名“Reach”不是隨手起的。Connect強(qiáng)調(diào)建立連接而Reach強(qiáng)調(diào)的是“觸達(dá)”這個(gè)結(jié)果——你要調(diào)用一個(gè)Agent最終的目標(biāo)不是把請(qǐng)求發(fā)出去而是讓對(duì)方真正處理并拿到結(jié)果。這中間涉及三層語(yǔ)義找得到目錄發(fā)現(xiàn)、到得了路由可用、有反饋結(jié)果回傳與狀態(tài)感知。很多團(tuán)隊(duì)在這一步會(huì)走偏一上來(lái)就做復(fù)雜的多Agent協(xié)商框架讓Agent之間互相討論、互相傳遞消息。這個(gè)方向當(dāng)然是終極形態(tài)但在實(shí)際生產(chǎn)環(huán)境里大部分業(yè)務(wù)根本不需要Agent之間有太多自主對(duì)話它們只需要被可靠地調(diào)度和觸達(dá)。Agent-Reach的定位是反過(guò)來(lái)的先保證每一次觸達(dá)都是確定性的、可控的、可觀測(cè)的再談智能協(xié)作。這個(gè)定位直接決定了技術(shù)架構(gòu)目錄服務(wù)、路由匹配和調(diào)用網(wǎng)關(guān)就是三個(gè)最核心的模塊本質(zhì)是一個(gè)面向Agent場(chǎng)景的“服務(wù)注冊(cè)中心API網(wǎng)關(guān)”只不過(guò)它的服務(wù)描述變成了Agent能力描述路由規(guī)則從配置表變成了大模型語(yǔ)義匹配。2. 整體架構(gòu)與核心設(shè)計(jì)四層搞定Agent觸達(dá)2.1 分層架構(gòu)目錄、路由、調(diào)用、觀測(cè)各司其職Agent-Reach的整體架構(gòu)分四層每一層只做一件事層與層之間通過(guò)標(biāo)準(zhǔn)數(shù)據(jù)模型交互這樣任何一個(gè)層都能獨(dú)立替換和擴(kuò)展。第一層是Agent目錄層。這一層負(fù)責(zé)所有Agent的能力注冊(cè)和發(fā)現(xiàn)。每個(gè)Agent上線時(shí)必須向目錄服務(wù)提交一份能力描述文檔說(shuō)明自己叫什么、有哪些能力、每個(gè)能力接受什么參數(shù)、返回什么結(jié)構(gòu)、有什么標(biāo)簽。目錄層會(huì)把這份描述存起來(lái)并提供檢索接口。第二層是路由匹配層。這一層接收用戶的自然語(yǔ)言請(qǐng)求先做意圖識(shí)別再把意圖和目錄里的能力描述做匹配找到最合適的Agent。這里不是簡(jiǎn)單查表而是結(jié)合了規(guī)則過(guò)濾和語(yǔ)義匹配保證準(zhǔn)確率的同時(shí)留了兜底策略。第三層是調(diào)用網(wǎng)關(guān)層。這一層負(fù)責(zé)真實(shí)的請(qǐng)求轉(zhuǎn)發(fā)。匹配到Agent之后網(wǎng)關(guān)把用戶的請(qǐng)求轉(zhuǎn)換成目標(biāo)Agent期望的協(xié)議格式發(fā)起調(diào)用處理超時(shí)、重試、熔斷最后把結(jié)果標(biāo)準(zhǔn)化回傳給上層。第四層是觀測(cè)審計(jì)層。這一層記錄每一次觸達(dá)的全過(guò)程請(qǐng)求內(nèi)容、匹配過(guò)程、選中了哪個(gè)Agent、耗時(shí)多少、成功還是失敗。方便后續(xù)做質(zhì)量分析和問(wèn)題排查。四層設(shè)計(jì)算是參考了微服務(wù)領(lǐng)域成熟的服務(wù)網(wǎng)格方案Agent本質(zhì)上是一種更智能的微服務(wù)與其從零發(fā)明一套理論不如把已經(jīng)被驗(yàn)證過(guò)的架構(gòu)模式平移過(guò)來(lái)。2.2 能力注冊(cè)機(jī)制Agent怎么被“看見”能力注冊(cè)是整個(gè)系統(tǒng)的數(shù)據(jù)底座沒有一份好用的注冊(cè)表匹配和調(diào)用都無(wú)從談起。我管理的Agent-Reach項(xiàng)目里能力注冊(cè)表最終落成了一個(gè)JSON文檔結(jié)構(gòu)每個(gè)Agent提交自己的一套能力描述系統(tǒng)校驗(yàn)格式后寫入目錄。注冊(cè)的核心字段包括agent_id、name、version、description、capabilities數(shù)組、endpoint、state、tags。capabilities數(shù)組是關(guān)鍵它拆分了這個(gè)Agent能做的每一件事而不是籠統(tǒng)地描述整個(gè)Agent。比如一個(gè)客服Agent它會(huì)注冊(cè)“查詢訂單狀態(tài)”“修改收貨地址”“申請(qǐng)售后”三個(gè)獨(dú)立能力每個(gè)能力有自己的描述、參數(shù)結(jié)構(gòu)和返回結(jié)構(gòu)。這樣拆的好處是意圖匹配的粒度更細(xì)。用戶說(shuō)“幫我看看快遞到哪了”匹配引擎可以在所有Agent的所有能力里精確找到“查詢物流狀態(tài)”這個(gè)能力而不是只能粗粒度定位到物流Agent然后把請(qǐng)求扔過(guò)去。注冊(cè)表還額外設(shè)計(jì)了一個(gè)健康字段Agent可以上報(bào)自己當(dāng)前的狀態(tài)——healthy忙碌、draining下線維護(hù)。網(wǎng)關(guān)路由時(shí)會(huì)把狀態(tài)納入考量不會(huì)往一個(gè)正在重啟的Agent上發(fā)流量。2.3 元數(shù)據(jù)驅(qū)動(dòng)的能力描述光有名字遠(yuǎn)遠(yuǎn)不夠項(xiàng)目里最花時(shí)間的不是寫代碼而是設(shè)計(jì)能力描述文檔的標(biāo)準(zhǔn)。字段定得太粗下游匹配和參數(shù)轉(zhuǎn)換就沒法做定得太細(xì)Agent方又不愿意填。最終版本我寫了以下核心元數(shù)據(jù)字段字段用途示例name能力短名稱query_order_statusdescription自然語(yǔ)言描述供語(yǔ)義匹配根據(jù)訂單號(hào)查詢訂單的實(shí)時(shí)狀態(tài)tags標(biāo)簽用于規(guī)則過(guò)濾[order, query, user]parameters參數(shù)Schema描述期望輸入{order_id: string}returns返回Schema{status: string, eta: datetime}endpoint實(shí)際調(diào)用地址/agents/order-agent/invoke參數(shù)這套Schema值得展開講講。剛開始我只是用自然語(yǔ)言描述參數(shù)后來(lái)發(fā)現(xiàn)網(wǎng)關(guān)做參數(shù)轉(zhuǎn)換時(shí)根本沒法解析于是改成JSON Schema格式字段名、類型、是否必須、默認(rèn)值都寫清楚這樣網(wǎng)關(guān)可以直接做校驗(yàn)和格式轉(zhuǎn)換。雖然Agent方填寫的門檻變高了但換來(lái)的是后續(xù)全鏈路自動(dòng)化這步投入非常值得。3. 核心機(jī)制實(shí)現(xiàn)從注冊(cè)到觸達(dá)的全鏈路3.1 環(huán)境準(zhǔn)備與工程結(jié)構(gòu)Agent-Reach核心邏輯我用的Python 3.11實(shí)現(xiàn)FastAPI做網(wǎng)關(guān)HTTP服務(wù)SQLite做目錄存儲(chǔ)。選這套組合主要是圖省事Python生態(tài)做語(yǔ)義匹配方便FastAPI寫異步接口利落SQLite零部署成本適合項(xiàng)目初期demo。工程結(jié)構(gòu)上我拆成五個(gè)模塊models數(shù)據(jù)模型、registry目錄服務(wù)、matcher路由匹配、gateway調(diào)用網(wǎng)關(guān)、observer觀測(cè)模塊。目錄服務(wù)存儲(chǔ)能力描述路由匹配器讀取目錄做意圖匹配網(wǎng)關(guān)負(fù)責(zé)真實(shí)調(diào)用觀測(cè)模塊記錄調(diào)用日志。這個(gè)結(jié)構(gòu)約定好了就算后面要把SQLite換MySQL、把本地匹配換成遠(yuǎn)程向量庫(kù)改一個(gè)模塊就行不會(huì)牽一發(fā)動(dòng)全身。3.2 能力注冊(cè)與Agent目錄服務(wù)實(shí)現(xiàn)目錄服務(wù)我提供了一個(gè)/register接口Agent上線后調(diào)用這個(gè)接口提交能力描述。服務(wù)端拿到描述后先做格式校驗(yàn)然后生成能力索引最后返回一個(gè)agent_id和secret后續(xù)Agent上報(bào)狀態(tài)、下線、更新都要帶上身份憑證。這個(gè)注冊(cè)接口的實(shí)現(xiàn)比我預(yù)想的簡(jiǎn)單核心邏輯就是存儲(chǔ)和校驗(yàn)沒有什么高深算法。關(guān)鍵在于數(shù)據(jù)模型設(shè)計(jì)得合理JSON Schema里我把capability定義成嵌套對(duì)象這樣一次注冊(cè)就把Agent的所有能力全部提交上來(lái)。校驗(yàn)用了jsonschema庫(kù)這個(gè)庫(kù)在Python生態(tài)里已經(jīng)很成熟直接拿過(guò)來(lái)用不需要自己寫輪子。注冊(cè)之后還有一個(gè)心跳機(jī)制Agent每30秒上報(bào)一次狀態(tài)。這個(gè)設(shè)計(jì)參考了分布式系統(tǒng)里的節(jié)點(diǎn)健康檢查一開始我偷懶沒做結(jié)果一個(gè)Agent已經(jīng)因?yàn)閮?nèi)存泄漏半死不活請(qǐng)求依然被路由過(guò)去所有任務(wù)全部超時(shí)。后來(lái)加了心跳和狀態(tài)上報(bào)路由前先檢查狀態(tài)問(wèn)題直接消掉了一多半。3.3 意圖識(shí)別與路由匹配實(shí)現(xiàn)路由匹配是Agent-Reach最核心的智能環(huán)節(jié)。系統(tǒng)收到用戶的自然語(yǔ)言請(qǐng)求后先對(duì)請(qǐng)求做意圖抽取再把抽取的結(jié)果和目錄里的能力描述逐一比對(duì)選出最合適的候選。匹配分三步走。第一步是規(guī)則硬過(guò)濾用請(qǐng)求文本里出現(xiàn)的keyword匹配能力描述里的tags。比如用戶消息里出現(xiàn)了“訂單”“物流”就優(yōu)先在帶有這些tags的能力里找。這一步能快速縮小候選集而且結(jié)果確定不會(huì)出現(xiàn)離譜的匹配。第二步是語(yǔ)義匹配把請(qǐng)求文本和剩余候選能力的description用向量模型做相似度計(jì)算按得分排序。這一步我用的一個(gè)輕量文本embedding模型把兩段文本映射成向量計(jì)算余弦距離。相似度超過(guò)閾值的進(jìn)入下一輪全部低于閾值就直接打回告訴用戶“暫時(shí)沒有能處理這個(gè)需求的能力”。第三步是可用性檢查檢查候選Agent是否在healthy狀態(tài)、當(dāng)前QPS是否打滿、是否處于資源保護(hù)期。過(guò)濾掉不可用的Agent后最終返回得分最高的目標(biāo)能力。這套匹配鏈路用下來(lái)準(zhǔn)確率明顯比單一方法高。純規(guī)則匹配遇到?jīng)]有完全對(duì)應(yīng)的詞就抓瞎純語(yǔ)義詞匹配容易在相近描述之間漂移規(guī)則語(yǔ)義狀態(tài)三層配合既穩(wěn)又準(zhǔn)。3.4 調(diào)用網(wǎng)關(guān)與可靠性機(jī)制實(shí)現(xiàn)匹配完成后請(qǐng)求進(jìn)入調(diào)用網(wǎng)關(guān)。網(wǎng)關(guān)做得比較重因?yàn)樗幚碚鎸?shí)生產(chǎn)環(huán)境里的各種意外。首先是協(xié)議轉(zhuǎn)換。能力描述里有parameters的JSON Schema網(wǎng)關(guān)根據(jù)這個(gè)Schema把用戶請(qǐng)求轉(zhuǎn)成目標(biāo)Agent期望的格式。用戶傳的是一個(gè)寬松的自然語(yǔ)言請(qǐng)求Agent期望的是一個(gè)結(jié)構(gòu)化的JSON轉(zhuǎn)換規(guī)則基于Schema定義的可選必選字段來(lái)做。這一步解決了調(diào)用方和Agent之間的協(xié)議對(duì)齊問(wèn)題也讓Agent方可以不關(guān)心上游傳過(guò)來(lái)的原始格式長(zhǎng)什么樣。然后是超時(shí)控制。網(wǎng)關(guān)為每一次調(diào)用設(shè)置超時(shí)閾值默認(rèn)2秒超時(shí)就中斷等待并標(biāo)記一次失敗。同時(shí)做了一個(gè)熔斷器設(shè)計(jì)統(tǒng)計(jì)每個(gè)Agent過(guò)去一分鐘內(nèi)連續(xù)失敗的次數(shù)超過(guò)閾值就開啟熔斷之后的請(qǐng)求不再轉(zhuǎn)發(fā)到這個(gè)Agent并直接快速失敗返回。熔斷狀態(tài)持續(xù)一段時(shí)間后會(huì)進(jìn)入半開狀態(tài)放一部分探測(cè)流量驗(yàn)證Agent是否恢復(fù)恢復(fù)就關(guān)熔斷還是不行就繼續(xù)斷。最后是結(jié)果標(biāo)準(zhǔn)化。Agent返回的原始結(jié)果被包裝成統(tǒng)一的消息結(jié)構(gòu)里面包含調(diào)用狀態(tài)、業(yè)務(wù)數(shù)據(jù)、Agent信息、耗時(shí)信息。上層業(yè)務(wù)不需要關(guān)心目標(biāo)Agent的返回格式直接處理標(biāo)準(zhǔn)結(jié)構(gòu)就行這大大降低了調(diào)用方的接入成本。3.5 完整調(diào)用鏈路演示用一個(gè)實(shí)例把整條鏈路串起來(lái)。假設(shè)系統(tǒng)里注冊(cè)了三個(gè)Agent一個(gè)客服Agent、一個(gè)物流Agent、一個(gè)外呼Agent。我作為調(diào)用方向Agent-Reach發(fā)了一個(gè)請(qǐng)求“查一下訂單號(hào)20240901的包裹到哪了”。請(qǐng)求先進(jìn)入路由匹配層規(guī)則匹配確認(rèn)“包裹”的tag和物流Agent的能力描述撞上語(yǔ)義匹配計(jì)算“查詢物流”“包裹位置”和物流能力描述的相似度得分最高可用性檢查確認(rèn)物流Agent健康最終路由到物流Agent。網(wǎng)關(guān)按物流Agent的能力Schema解析出order_id20240901發(fā)起調(diào)用。物流Agent返回結(jié)果網(wǎng)關(guān)包裝成標(biāo)準(zhǔn)結(jié)構(gòu)回傳給我。我拿到的不只是一個(gè)冷冰冰的包裹狀態(tài)還有這次調(diào)用鏈路信息Agent身份、路由匹配分?jǐn)?shù)、響應(yīng)耗時(shí)這些對(duì)調(diào)試優(yōu)化都很有價(jià)值。這個(gè)鏈路保證了上層業(yè)務(wù)只和Agent-Reach打交道不直接關(guān)心底層Agent的變化。4. 踩過(guò)的坑與后續(xù)改造方向真正把Agent-Reach跑進(jìn)真實(shí)項(xiàng)目之后踩的坑比想象中多。有些坑靠仔細(xì)想想就能避開有些只有壓力測(cè)試才能暴露出來(lái)。4.1 語(yǔ)義匹配會(huì)“漂”必須加兜底策略第一次上線的時(shí)候語(yǔ)義匹配單獨(dú)挑大梁結(jié)果經(jīng)常出現(xiàn)一個(gè)用戶請(qǐng)求被匹配到多個(gè)Agent的情況。比如“幫我修改地址”這個(gè)請(qǐng)求客服Agent的能力里有“修改收貨地址”訂單Agent的能力里有“修改配送地址”語(yǔ)義上的邊界本來(lái)就模糊向量相似度差距極小模型偶爾會(huì)選錯(cuò)。后來(lái)加了硬規(guī)則過(guò)濾和權(quán)重打分把Agent狀態(tài)和實(shí)時(shí)負(fù)載也納入權(quán)重這個(gè)問(wèn)題才算穩(wěn)定下來(lái)。另一個(gè)經(jīng)驗(yàn)是匹配閾值不能拍腦袋。閾值太高用戶請(qǐng)求經(jīng)常匹配不到任何Agent全被拒了閾值太低牛頭不對(duì)馬嘴的能力被匹配上下游處理全錯(cuò)。我的做法是用歷史調(diào)用數(shù)據(jù)看成功率選了讓整體成功率最高的那個(gè)臨界值然后用兜底策略應(yīng)對(duì)低于閾值的情況。4.2 Agent狀態(tài)不一致導(dǎo)致的級(jí)聯(lián)奔潰這是壓測(cè)時(shí)暴露的單個(gè)Agent響應(yīng)變慢網(wǎng)關(guān)層面的重試機(jī)制瘋狂觸發(fā)重試請(qǐng)求占滿了Agent的線程池Agent處理能力進(jìn)一步下降形成惡性循環(huán)。重試本是用來(lái)提高成功率的反而成了雪崩的放大器。后來(lái)給重試做了一套明確規(guī)則只在超時(shí)錯(cuò)誤和網(wǎng)絡(luò)錯(cuò)誤時(shí)重試業(yè)務(wù)邏輯錯(cuò)誤不重試。最多允許重試一次且重試必須在第一個(gè)請(qǐng)求發(fā)出后的600毫秒后啟動(dòng)。同時(shí)熔斷器參數(shù)也做了調(diào)整讓它可以更早介入中斷故障Agent的后續(xù)流量。4.3 調(diào)用鏈觀測(cè)要前置設(shè)計(jì)別事后補(bǔ)項(xiàng)目初期觀測(cè)模塊只做了請(qǐng)求日志等出問(wèn)題排查時(shí)發(fā)現(xiàn)自己傻眼了日志散落在各個(gè)服務(wù)里沒有一個(gè)統(tǒng)一的trace_id把一次調(diào)用的全鏈路串起來(lái)。后來(lái)我在網(wǎng)關(guān)層做了標(biāo)準(zhǔn)化處理請(qǐng)求進(jìn)來(lái)就生成一個(gè)trace_id從入口到匹配到調(diào)用到結(jié)果返回全程攜帶并使用它記錄日志。暫時(shí)用的本地文件存儲(chǔ)生產(chǎn)環(huán)境可以換ES或ClickHouse做檢索。4.4 Agent-Reach的三個(gè)擴(kuò)展方向項(xiàng)目穩(wěn)定運(yùn)行之后我開始琢磨還能往哪些方向延展。最想做的是多租戶隔離目前目錄和路由是所有Agent共享的一旦接入的Agent數(shù)量變多權(quán)限控制和安全審計(jì)就必須跟上每個(gè)租戶只能看到和調(diào)用自己有權(quán)限的Agent能力。另外還計(jì)劃加一個(gè)效率優(yōu)先模式路由匹配時(shí)更傾向于選擇歷史響應(yīng)更快、成功率更高的Agent避免冷門Agent一直被冷落、熱門Agent長(zhǎng)時(shí)間繁忙。我還發(fā)現(xiàn)了一個(gè)有意思的擴(kuò)展點(diǎn)把Agent-Reach從“觸達(dá)”升級(jí)成“編排”網(wǎng)關(guān)層不止轉(zhuǎn)發(fā)單個(gè)請(qǐng)求還能把一個(gè)復(fù)雜需求拆成多個(gè)子任務(wù)、路由給多個(gè)Agent、最后聚合結(jié)果。但是這條路線我不會(huì)輕率做編排的失敗處理比單純觸達(dá)復(fù)雜得多先把觸達(dá)這層做扎實(shí)再說(shuō)。5. 這套方案的設(shè)計(jì)復(fù)盤與心得寫到這里回頭看看Agent-Reach這個(gè)項(xiàng)目的完整歷程我最想留下的不是代碼而是一套思考方式做多Agent系統(tǒng)時(shí)觸達(dá)層是整個(gè)體系的地基這個(gè)地基不牢靠上層任何花哨的智能都會(huì)崩塌。老老實(shí)實(shí)把注冊(cè)表、匹配策略、調(diào)用鏈路這“老三樣”打磨好比追新鮮概念重要得多。從數(shù)據(jù)上看引入了Agent-Reach之后整個(gè)Agent體系的集成時(shí)間從原來(lái)的兩三天縮短到一個(gè)小時(shí)左右新接入一個(gè)Agent只需要通過(guò)注冊(cè)接口提交描述并部署好服務(wù)。調(diào)用成功率從原來(lái)的87%提升到了96.8%。這個(gè)提升主要來(lái)自三個(gè)地方超時(shí)重試策略改對(duì)了、熔斷機(jī)制擋住了故障擴(kuò)散、路由匹配的置信度閾值調(diào)到了合理區(qū)間。另外從個(gè)人的實(shí)操經(jīng)驗(yàn)來(lái)看一個(gè)很容易忽視但后期回報(bào)極高的決策是我在項(xiàng)目啟動(dòng)的第一天就把指標(biāo)埋點(diǎn)寫在了代碼里而不是等到快要上線才想起來(lái)。每個(gè)模塊的關(guān)鍵路徑上都有start_time和end_time的記錄最終審計(jì)回溯時(shí)省了無(wú)數(shù)翻舊賬的時(shí)間。如果你準(zhǔn)備復(fù)刻這套方案我建議你也從第一天就做好觀測(cè)設(shè)施否則后面補(bǔ)的概率通常很低。最后再分享一個(gè)小技巧能力描述文檔一定要寫實(shí)不要為了讓自己開發(fā)的Agent顯得全能而堆一堆做不到的描述。描述越具體匹配越準(zhǔn)下游Agent處理越順利整體鏈路容錯(cuò)性就會(huì)越好。保持誠(chéng)實(shí)Agent-Reach這樣的路由系統(tǒng)才能發(fā)揮出應(yīng)有的效果。