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