上個(gè)月我在后臺(tái)看到一條留言問(wèn)的是“為什么我們團(tuán)隊(duì)把 Agent 從 3 個(gè)加到 30 個(gè)交付速度反而變慢了” 這個(gè)問(wèn)題我太熟了——我們自己就踩過(guò)一個(gè)更深的版本早期在某條業(yè)務(wù)鏈路里Agent 數(shù)量翻了幾倍之后線上任務(wù)的平均完成時(shí)間非但沒(méi)有縮短反而增加了將近一倍。當(dāng)時(shí)大家的第一反應(yīng)都是模型不夠強(qiáng)換更強(qiáng)的模型、調(diào)更高的上下文上限結(jié)果沒(méi)多大用。后來(lái)靜下來(lái)把調(diào)用鏈拆開(kāi)逐段分析才意識(shí)到問(wèn)題根本不在單個(gè) Agent 的“智力”而在工程側(cè)對(duì)多 Agent 協(xié)作的組織方式。這篇文章想把這些踩過(guò)的坑一次說(shuō)透為什么 Agent 一多效率反而不升反降哪些瓶頸是必然會(huì)出現(xiàn)的哪些其實(shí)是設(shè)計(jì)失誤造成的以及我們后來(lái)用什么手段把這個(gè)問(wèn)題逐步控制住。內(nèi)容會(huì)貼近真實(shí)生產(chǎn)環(huán)境那些“看起來(lái)能跑”的 Demo 里發(fā)現(xiàn)不了的細(xì)節(jié)很多得靠線上數(shù)據(jù)才能暴露。如果你已經(jīng)過(guò)了“跑通單個(gè) Agent”的階段開(kāi)始嘗試讓多個(gè) Agent 協(xié)作完成任務(wù)這篇應(yīng)該能幫你少走不少?gòu)澛贰?. 效率衰減的根源拆解為什么理論上的并行沒(méi)有兌現(xiàn)1.1 非線性增長(zhǎng)的溝通成本先說(shuō)最根本的數(shù)學(xué)模型。假設(shè)一個(gè)任務(wù)被拆給 N 個(gè) Agent 協(xié)作完成每個(gè) Agent 之間需要兩兩同步狀態(tài)和信息那么需要管理的連接數(shù)就是 N×(N-1)/2。當(dāng) N 從 3 變成 10連接數(shù)從 3 變成 45當(dāng) N 變成 30連接數(shù)是 435。這是 O(N2) 的增長(zhǎng)而單 Agent 的吞吐能力基本是線性的甚至還會(huì)因?yàn)樯舷挛淖冮L(zhǎng)而下降。這個(gè)曲線在真實(shí)系統(tǒng)里會(huì)轉(zhuǎn)化為一種肉眼可見(jiàn)的“協(xié)調(diào)稅”——每一個(gè) Agent 都要等待其他 Agent 的輸出、驗(yàn)證中間結(jié)果、處理狀態(tài)沖突這些等待時(shí)間不會(huì)讓模型跑得更快反而會(huì)把本來(lái)就有限的推理時(shí)間切成碎片。我見(jiàn)過(guò)一個(gè)典型的案例某個(gè)任務(wù)本來(lái)單個(gè) Agent 能干完硬拆成 5 個(gè) Agent 并行做結(jié)果因?yàn)榉磸?fù)同步和校正總耗時(shí)翻了 3 倍。所以第一個(gè)要記住的公式是Agent 的數(shù)量增加一倍協(xié)調(diào)成本可能變成原來(lái)的四倍而不是兩倍。1.2 注意力機(jī)制與上下文窗口的隱性消耗很多人忽略的是多個(gè) Agent 協(xié)作時(shí)上下文窗口變成了一種共享但極其稀缺的資源。每個(gè) Agent 都要把自己負(fù)責(zé)部分的背景信息寫(xiě)進(jìn)上下文還要讀取其他 Agent 的輸出摘要這部分 token 的膨脹速度非常驚人。我見(jiàn)過(guò)一個(gè)實(shí)際數(shù)據(jù)在某個(gè) 8-Agent 的任務(wù)鏈里因互相傳遞上下文token 總量比單 Agent 方案多了 5 倍其中很多是重復(fù)的背景介紹和狀態(tài)描述。更麻煩的是大模型的注意力機(jī)制對(duì)長(zhǎng)上下文的利用不是均勻的——相關(guān)研究表明中間位置的信息最容易被忽略這個(gè)現(xiàn)象常被俗稱為“l(fā)ost in the middle”。當(dāng)多個(gè) Agent 的輸出擠在同一段上下文里關(guān)鍵決策點(diǎn)往往被淹沒(méi)在中間位置模型會(huì)做出錯(cuò)誤的加權(quán)判斷。這不是換個(gè)更強(qiáng)的模型就能解決的它本質(zhì)上是信息組織和壓縮的問(wèn)題。我們后面會(huì)上上下文固化與裁剪機(jī)制就是為了對(duì)抗這個(gè)注意力損耗。1.3 單點(diǎn)依賴與木桶效應(yīng)多 Agent 系統(tǒng)的整體吞吐不是由最快那個(gè) Agent 決定的而是由最慢的那個(gè)決定。這句聽(tīng)起來(lái)像廢話但實(shí)際操作中極容易被忽視。Agent 們共享底座模型服務(wù)的并發(fā)上限每個(gè) Agent 內(nèi)部還有多輪工具調(diào)用只要有一個(gè)環(huán)節(jié)出現(xiàn)高延遲重試或排隊(duì)后面所有的 Agent 都會(huì)陷入等待。我在一次復(fù)盤中發(fā)現(xiàn)一條 12 個(gè) Agent 的并行鏈路里其中有 2 個(gè) Agent 承擔(dān)了約 70% 的任務(wù)量它們?cè)诜磸?fù)調(diào)用同一個(gè)外部接口而這個(gè)接口單次響應(yīng)時(shí)間超過(guò) 5 秒。結(jié)果整個(gè)系統(tǒng)完成率看起來(lái)不錯(cuò)但延遲的可達(dá)性已經(jīng)崩了。簡(jiǎn)單說(shuō)加 Agent 之前得先想清楚有沒(méi)有能力給它們做負(fù)載協(xié)調(diào)否則加得越多越是在排隊(duì)鏈上疊磚頭。2. 實(shí)操中常見(jiàn)的效率殺手四個(gè)大家都會(huì)踩的場(chǎng)景2.1 群體踩踏式的失敗重試多 Agent 系統(tǒng)最容易被忽視的穩(wěn)定性問(wèn)題是“重試風(fēng)暴”。單個(gè) Agent 在調(diào)用外部工具或模型接口時(shí)遇到超時(shí)或失敗會(huì)選擇重試這個(gè)機(jī)制本身沒(méi)問(wèn)題。但當(dāng)多個(gè) Agent 共享同一個(gè)薄弱服務(wù)且彼此之間的任務(wù)有順序依賴時(shí)某一個(gè)服務(wù)的抖動(dòng)會(huì)被層層放大。A 重試B 等待 A 的結(jié)果所以也拉長(zhǎng)C 因?yàn)?B 超時(shí)也開(kāi)始重試……最后看起來(lái)就像是所有 Agent 都在瘋狂重試系統(tǒng)吞吐跌到接近 0。我們踩過(guò)的一次典型事故是這樣的某個(gè) Agent 調(diào)用一個(gè)數(shù)據(jù)庫(kù)接口這個(gè)接口偶發(fā) 2 秒的慢查詢本來(lái)不至于出大問(wèn)題。但因?yàn)橄掠斡?5 個(gè) Agent 都依賴這個(gè)接口返回的數(shù)據(jù)它們各自啟動(dòng)了自己的超時(shí)重試邏輯等慢查詢過(guò)去后接口瞬間收到 5 倍的重試請(qǐng)求直接被打垮。之后整個(gè)任務(wù)鏈持續(xù)失敗了接近 40 分鐘。后來(lái)我們定了一條硬規(guī)則所有重試必須加指數(shù)退避和隨機(jī)抖動(dòng)且每個(gè)任務(wù)鏈必須有全局重試總次數(shù)上限。2.2 上下文漂移帶來(lái)的信息失真上下文漂移這個(gè)詞可能聽(tīng)著陌生但現(xiàn)象大家一定見(jiàn)過(guò)一個(gè) Agent 在執(zhí)行任務(wù)時(shí)原本應(yīng)該參考的信息被新信息擠掉了或者它記住了早期錯(cuò)誤的中間結(jié)果后續(xù)整個(gè)流程跟著錯(cuò)下去。多個(gè) Agent 協(xié)作時(shí)這個(gè)問(wèn)題的概率會(huì)成倍上升因?yàn)槊總€(gè) Agent 都會(huì)改寫(xiě)上下文信息在 Agent 之間傳遞時(shí)會(huì)發(fā)生“損耗失真”。舉一個(gè)實(shí)際例在某個(gè)文檔處理任務(wù)里Agent A 負(fù)責(zé)提取原始數(shù)據(jù)Agent B 負(fù)責(zé)數(shù)據(jù)修正Agent C 負(fù)責(zé)生成報(bào)告。A 在提取時(shí)漏掉了一條數(shù)據(jù)B 沒(méi)意識(shí)到缺失直接在修正后的數(shù)據(jù)集上做了計(jì)算C 基于計(jì)算結(jié)果輸出了報(bào)告。最終報(bào)告看起來(lái)完整但里面已經(jīng)有一處隱性錯(cuò)誤而且很難追溯是哪一步丟的。整個(gè)系統(tǒng)缺少“不變量校驗(yàn)”機(jī)制這樣的錯(cuò)誤就會(huì)成為常態(tài)。我們的解決方式是在關(guān)鍵節(jié)點(diǎn)插入數(shù)據(jù)校驗(yàn) Agent專門負(fù)責(zé)核對(duì)上游輸出是否完整這種“冗余”反而是保證系統(tǒng)可信度最必要的投入。2.3 工具調(diào)用鏈的餓死與死鎖工具調(diào)用是 Agent 干活的手腳但多 Agent 環(huán)境下工具調(diào)用很容易發(fā)生餓死或死鎖。餓死的典型場(chǎng)景是多個(gè) Agent 排隊(duì)等待同一個(gè)被占用的工具資源但由于等待隊(duì)列太長(zhǎng)部分 Agent 被餓死——不報(bào)錯(cuò)也不執(zhí)行就是干等。死鎖則更隱蔽Agent A 需要 Agent B 的輸出才能繼續(xù)Agent B 又在等待 Agent A 的另一個(gè)中間結(jié)果兩邊互相等待沒(méi)有任何一個(gè)會(huì)主動(dòng)退出。我在排查線上任務(wù)時(shí)遇到過(guò)典型的死鎖現(xiàn)象任務(wù)狀態(tài)卡在“運(yùn)行中”但實(shí)際已經(jīng)沒(méi)有任何 Agent 在推進(jìn)日志里只看得到兩個(gè) Agent 在反復(fù)轉(zhuǎn)發(fā)空狀態(tài)。這個(gè)問(wèn)題的根因在于Agent 之間的依賴沒(méi)有設(shè)計(jì)成有向無(wú)環(huán)圖而是一個(gè)回環(huán)。后來(lái)我們給所有編排層加了依賴檢測(cè)一旦檢測(cè)到循環(huán)依賴直接中斷任務(wù)并報(bào)警寧可失敗重跑也不能卡死浪費(fèi)資源。2.4 重復(fù)勞動(dòng)與無(wú)效計(jì)算多 Agent 系統(tǒng)的另一個(gè)隱性浪費(fèi)是重復(fù)勞動(dòng)。表面上看有不同的分工但落到具體執(zhí)行時(shí)幾個(gè) Agent 常常在做同一件事只是各自帶著不同的參數(shù)和上下文。比如多個(gè) Agent 各自維護(hù)一份相同的狀態(tài)快照、各自重新調(diào)用同一個(gè)數(shù)據(jù)接口、各自做同一段文檔解析。這種重復(fù)不是 bug而是任務(wù)分配粒度過(guò)粗的結(jié)果。系統(tǒng)設(shè)計(jì)者把職責(zé)劃分成“A 管數(shù)據(jù)、B 管校驗(yàn)、C 管報(bào)告”但實(shí)際執(zhí)行時(shí)每個(gè) Agent 都需要訪問(wèn)原始數(shù)據(jù)來(lái)完成自己的部分于是同樣的讀取和解析被重復(fù)執(zhí)行了三遍。修復(fù)方式是在編排層做結(jié)果復(fù)用建立一個(gè)共享的中間結(jié)果緩存誰(shuí)需要誰(shuí)去取而不是誰(shuí)都要重新算一遍。這一步做完之后我們某條鏈路的 token 消耗直接下降了 40%。3. 用數(shù)據(jù)說(shuō)話如何定位效率瓶頸的根因3.1 從“憑感覺(jué)”到“可量化”的診斷路徑遇到多 Agent 效率衰減的問(wèn)題第一步要做的是畫(huà)現(xiàn)狀拓?fù)鋱D把每個(gè) Agent 的輸入、輸出、依賴工具、上下游關(guān)系全部梳理出來(lái)。拓?fù)鋱D不用追求美觀但必須能回答三個(gè)問(wèn)題每個(gè) Agent 在等什么每個(gè) Agent 產(chǎn)出的東西被誰(shuí)消費(fèi)哪個(gè)環(huán)節(jié)是可以并行但實(shí)際串行的畫(huà)完拓?fù)鋱D就該上埋點(diǎn)數(shù)據(jù)。每個(gè) Agent 至少需要記錄四個(gè)指標(biāo)單次調(diào)用耗時(shí)包括模型響應(yīng)時(shí)間和工具響應(yīng)時(shí)間、token 消耗量輸入 輸出、重試次數(shù)、等待時(shí)間。這組數(shù)據(jù)不需要復(fù)雜的 APM 系統(tǒng)簡(jiǎn)單的日志聚合就能跑起來(lái)。重點(diǎn)不是收集而是看分布——我建議按 P50、P95、P99 三個(gè)分位去切分而不是看平均值因?yàn)槠骄禃?huì)把偶發(fā)拖慢和常態(tài)慢混在一起導(dǎo)致誤判。3.2 四個(gè)關(guān)鍵指標(biāo)配置監(jiān)控前先看懂它們指標(biāo)定義異常信號(hào)常見(jiàn)根因等待時(shí)間占比Agent 等待上游或工具返回的時(shí)間 / 總耗時(shí)大于 60%串行依賴過(guò)多或外部接口過(guò)慢重試率重試次數(shù) / 總調(diào)用次數(shù)大于 10%接口不穩(wěn)定或并發(fā)超限Token 重復(fù)率多個(gè) Agent 重復(fù)讀取相同內(nèi)容的 token / 總 token大于 30%缺乏中間結(jié)果緩存與共享上下文命中率關(guān)鍵指令在最終決策中的保留程度可抽樣評(píng)估低于 70%中間層信息壓縮過(guò)度注意力偏移這四個(gè)指標(biāo)的厲害之處在于它們能幫我們把“感覺(jué)不對(duì)”的癥狀翻譯成具體的工程問(wèn)題。比如你看到一個(gè)任務(wù)鏈整體很慢但每個(gè) Agent 的模型推理時(shí)間都不高那么問(wèn)題大概率在等待時(shí)間占比上——說(shuō)明編排結(jié)構(gòu)有問(wèn)題如果你看到重試率高那就得去查外部依賴的健康度而不是一味優(yōu)化 prompt。3.3 分段計(jì)時(shí)法半小時(shí)內(nèi)定位瓶頸我自己最常用的定位手段是分段計(jì)時(shí)。把整個(gè)任務(wù)鏈切成幾段接收輸入、規(guī)劃拆分、Agent 間同步、外部工具調(diào)用、結(jié)果合并、輸出生成然后在每一段標(biāo)記時(shí)間戳。這個(gè)方法聽(tīng)起來(lái)土但比任何 profiling 工具都好使。比如有一次排查一個(gè) 8-Agent 任務(wù)鏈發(fā)現(xiàn)整體耗時(shí) 120 秒單看模型推理只花了 30 秒剩下的 90 秒都耗在了“同步”上。順著時(shí)間戳找到最大的同步阻塞點(diǎn)發(fā)現(xiàn)是兩個(gè) Agent 在循環(huán)等待同一個(gè)外部接口的返回而接口本身只有 2 秒的響應(yīng)時(shí)間——問(wèn)題是它們的調(diào)用時(shí)間段完全錯(cuò)開(kāi)了等于一個(gè)干等另一個(gè)釋放連接。最后把調(diào)用順序從串行改為并行總耗時(shí)直接從 120 秒降到了 45 秒。很多時(shí)候慢的根本不是算力而是編排邏輯。4. 落地方案給多 Agent 系統(tǒng)裝上“效率護(hù)欄”4.1 控制單鏈 Agent 數(shù)量為什么“越少越好”是硬規(guī)則在排查完所有問(wèn)題后我們最終總結(jié)出一條反常識(shí)的經(jīng)驗(yàn)單條任務(wù)鏈里的 Agent 數(shù)量最好控制在 5 個(gè)以內(nèi)。不是說(shuō)不能超過(guò) 5而是超過(guò) 5 之后要做到同樣的效率需要投入的工程治理成本會(huì)急劇上升。這里有一個(gè)經(jīng)驗(yàn)公式可以分享假設(shè)單個(gè) Agent 在理想狀態(tài)下的處理能力是 1它能拿到的有效上下文比例約等于 0.7因?yàn)橛凶⒁饬p耗和上下文膨脹那 5 個(gè) Agent 協(xié)作的總有效輸出大約是 3.5但因?yàn)閰f(xié)調(diào)成本和傳遞損耗要打一個(gè)約 0.6 的折扣實(shí)際只有 2.1——可能還不如把任務(wù)給 2 個(gè)更強(qiáng)的 Agent讓它們專注完成各自的部分來(lái)得高效。所以我們?cè)谠O(shè)計(jì)任務(wù)拆分時(shí)會(huì)先問(wèn)一個(gè)問(wèn)題這個(gè) Agent 是否是必需的如果刪掉它讓另一個(gè) Agent 多走一步能否覆蓋大多數(shù)時(shí)候答案是能。4.2 層級(jí)編排與專注化設(shè)計(jì)多 Agent 效率問(wèn)題的另一條解藥是把“平級(jí)協(xié)作”改成“層級(jí)編排”。平級(jí)協(xié)作是 30 個(gè) Agent 互相商量誰(shuí)先做誰(shuí)后做什么都靠模型自己判斷層級(jí)編排則是引入一個(gè)主控制 Agent它不負(fù)責(zé)具體干活只負(fù)責(zé)任務(wù)拆分、結(jié)果驗(yàn)收、異常分發(fā)。業(yè)內(nèi)通常會(huì)把這個(gè)角色稱為“規(guī)劃器”或“調(diào)度器”。主控制 Agent 的意義在于它將原本的 O(N2) 溝通成本降成了 O(N)。因?yàn)槊恳粋€(gè)執(zhí)行 Agent 只需要跟主控制 Agent 溝通不需要兩兩之間建立連接。實(shí)際使用中這個(gè)主控制 Agent 的模型能力不需要比執(zhí)行 Agent 強(qiáng)很多反而更看重它的指令遵循和結(jié)構(gòu)化輸出能力因?yàn)樗饕漠a(chǎn)出是一份機(jī)器可讀的任務(wù)清單而不是長(zhǎng)篇大論。我們目前的實(shí)踐是把主控制 Agent 的任務(wù)清單定義成嚴(yán)格 JSON 結(jié)構(gòu)里面包含每個(gè)執(zhí)行 Agent 的輸入路徑、目標(biāo)描述、依賴輸出、完成標(biāo)準(zhǔn)。執(zhí)行 Agent 之間的數(shù)據(jù)交換不直接進(jìn)行全部通過(guò)一個(gè)共享緩沖區(qū)中轉(zhuǎn)。這個(gè)模式讓系統(tǒng)變穩(wěn)了很多即使某個(gè) Agent 掛了主控制也能快速感知并把任務(wù)分給備用 Agent而不是像平級(jí)協(xié)作那樣整條鏈等一個(gè)超時(shí)。4.3 上下文固化與壓縮策略上下文管理是讓多 Agent 系統(tǒng)持續(xù)高效的關(guān)鍵。我們總結(jié)了一套“三明治”策略固定頂部和底部、壓縮中間。固定頂部是指在系統(tǒng)提示詞里放一份“不變量”區(qū)塊里面寫(xiě)死任務(wù)的終極目標(biāo)、關(guān)鍵約束、行業(yè)常識(shí)這塊內(nèi)容不允許任何 Agent 改寫(xiě)。壓縮中間是指 Agent 之間傳遞上下文時(shí)不要直接丟原始輸出而是先用一個(gè)小模型做結(jié)構(gòu)化提取——只保留實(shí)體、決策、結(jié)論和必需的過(guò)程數(shù)據(jù)丟棄寒暄和重復(fù)內(nèi)容。固定底部則是讓最新的執(zhí)行狀態(tài)和待辦列表保持在上下文的末尾方便模型在生成時(shí)優(yōu)先“看到”它們。這套策略實(shí)測(cè)下來(lái)8-Agent 場(chǎng)景的 token 消耗減少了 55%任務(wù)成功率反而提升了接近 20%。原理很簡(jiǎn)單模型在上下文有限的情況下越是重要的信息越需要被放在它更容易注意到的位置。上下文固定和裁剪本質(zhì)上是在幫模型做注意力管理。4.4 引入結(jié)果緩存與任務(wù)去重結(jié)果緩存聽(tīng)起來(lái)像老生常談但在 Agent 系統(tǒng)里特別容易被遺漏。原因是大家默認(rèn) Agent 是“有狀態(tài)的智能體”每次輸出都是新的不做緩存。但實(shí)際上很多 Agent 的工具調(diào)用是對(duì)同一份數(shù)據(jù)源的重復(fù)讀取緩存的價(jià)值極高。我們實(shí)現(xiàn)了一個(gè)中間結(jié)果緩存層以工具調(diào)用參數(shù)為 key以返回結(jié)果為 value。任何一個(gè) Agent 要調(diào)用工具時(shí)先查緩存命中就直接用不命中才發(fā)起真實(shí)調(diào)用。這個(gè)在數(shù)據(jù)讀取類任務(wù)里收益最大實(shí)測(cè)某些鏈路里緩存命中率能達(dá)到 60% 到 70%整體響應(yīng)時(shí)間減半。再配合任務(wù)去重也就是在任務(wù)分配前檢查這個(gè)子任務(wù)是不是已經(jīng)由其他 Agent 完成過(guò)如果完成過(guò)而且結(jié)果可用直接復(fù)用結(jié)果就不需要再派一個(gè)新的 Agent 去做了。這兩招組合用下來(lái)臟活累活少了很多效率自然也就上來(lái)了。5. 常見(jiàn)問(wèn)題速查效率衰減的快速排查清單癥狀可能原因排查手段應(yīng)對(duì)策略任務(wù)整體耗時(shí)拉長(zhǎng)但單個(gè) Agent 推理時(shí)間正常串行依賴過(guò)多等待時(shí)間占比高查看每個(gè) Agent 的等待時(shí)間統(tǒng)計(jì)調(diào)整依賴關(guān)系改為并行或異步模型頻繁給出“已放棄”或“錯(cuò)誤”結(jié)果上下文被中間信息淹沒(méi)關(guān)鍵指令漂移檢查上下文固化情況抽樣閱讀最終決策前的上下文壓縮中間層內(nèi)容固定頂部關(guān)鍵信息外部接口 QPS 暴漲部分請(qǐng)求超時(shí)多個(gè) Agent 重復(fù)調(diào)用同一接口且重試無(wú)退避看工具調(diào)用日志統(tǒng)計(jì)相同參數(shù)的調(diào)用次數(shù)加緩存加全局限流與退避重試某幾個(gè) Agent 很閑其他幾個(gè)忙不過(guò)來(lái)任務(wù)分配粒度不均負(fù)載不均衡查看各 Agent 的執(zhí)行任務(wù)量和耗時(shí)分布細(xì)化任務(wù)拆分或改用動(dòng)態(tài)分配鏈路的 token 消耗漲得離譜上下文重復(fù)傳遞缺乏壓縮機(jī)制統(tǒng)計(jì) token 消耗占比找重復(fù)度最高的段落增加結(jié)構(gòu)化提取與裁剪層這套速查表在我們內(nèi)部是貼墻的排查問(wèn)題的時(shí)候直接按癥狀對(duì)號(hào)入座能省掉很多靠猜的時(shí)間。如果你正被某一個(gè)多 Agent 場(chǎng)景折磨可以先從表格的第一行開(kāi)始查絕大多數(shù)效率問(wèn)題都逃不開(kāi)“等待時(shí)間占比過(guò)高”這一個(gè)根因。6. 一些值得內(nèi)化的原則說(shuō)到底多 Agent 不是越多越好而是一個(gè)需要精細(xì)治理的工程系統(tǒng)。我們團(tuán)隊(duì)現(xiàn)在設(shè)計(jì)任何一條 Agent 鏈路都遵循三條硬原則一是單鏈不超過(guò) 5 個(gè)執(zhí)行 Agent二是所有交互走結(jié)構(gòu)化數(shù)據(jù)不走自然語(yǔ)言三是每個(gè)環(huán)節(jié)都有可量化的監(jiān)控指標(biāo)不允許出現(xiàn)不可觀測(cè)的隱性環(huán)節(jié)。這三條看著簡(jiǎn)單但每一條都是用線上事故換來(lái)的教訓(xùn)。我們后來(lái)在復(fù)盤那起“3 個(gè)加到 30 個(gè)效率反而下降”的問(wèn)題時(shí)得到的最深的體會(huì)是加 Agent 之前先想想這些 Agent 之間要怎么說(shuō)話、怎么避免重復(fù)勞動(dòng)、怎么共享信息。如果這些問(wèn)題想不清楚加多少 Agent 都只是在放大混亂而已。真正高效的系統(tǒng)往往不是 Agent 最多的而是每個(gè) Agent 都清楚自己該干什么、做完之后該把結(jié)果交給誰(shuí)的。現(xiàn)在每當(dāng)我聽(tīng)到“多加幾個(gè) Agent 就能提效”的說(shuō)法都會(huì)忍不住提醒一句冷啟動(dòng)跑通一個(gè) Agent 很容易但把 30 個(gè) Agent 組織成一支高效隊(duì)伍難的是工程不是模型。如果你現(xiàn)在也卡在“加了 Agent 反而更慢”的困境里建議先別急著換更大的模型回到拓?fù)鋱D和監(jiān)控?cái)?shù)據(jù)上看一看大概率能找到比模型更值得優(yōu)化的瓶頸。等這輪梳理做完再回頭看看是不是真的需要那么多 Agent也許會(huì)有完全不一樣的答案。