這項由伊利諾伊大學厄巴納-香檳分校研究團隊完成的工作，以預印本形式發布於2026年6月，論文編號為arXiv:2606.28187，有興趣深入了解的讀者可通過該編號查詢完整論文。
假設你經營一家大型餐廳，廚房裡分工明確：一個人負責切菜，一個人負責炒菜，一個人負責擺盤，最後一個人負責端給客人。當客人抱怨菜品難吃時，你怎麼知道問題出在哪個環節？是菜切得不好，還是火候不對，還是擺盤時撒了奇怪的調料？如果只是籠統地告訴所有人"菜不好吃，大家都要改進"，效果恐怕非常有限。
這正是當今人工智慧領域一個真實存在的困境。大語言模型（也就是像ChatGPT這類能對話的AI）正在被組成"團隊"來協作完成複雜任務，比如同時處理訂酒店、預約餐廳、查詢火車的綜合旅行規劃需求。這種由多個AI分工協作的系統叫做"多智能體系統"。但問題在於，當整個系統給出一個糟糕的答案時，沒有人知道該怪哪個AI——現有技術只能告訴你"整體結果不好"，無法精確定位是哪個環節出了問題。
伊利諾伊大學厄巴納-香檳分校的研究團隊為此提出了一套名為GBC（梯度基連接，Gradient-Based Connections）的方法，並配套開發了一個叫做AgentChord的實用框架。核心思路是：像追蹤餐廳菜品問題的溯源流程一樣，用數學方法精確計算出多智能體系統中每個AI的每一句輸出，對最終結果到底有多大影響。找到癥結所在後，系統就能有針對性地改進出問題的那個AI的"工作指令"，而不是讓所有AI一起盲目調整。
---
一、多個AI協作為何容易"翻車"
回到餐廳的比喻。單個廚師獨自完成一道菜，哪裡做錯了一目了然。但當五六個人分工合作時，每個人的失誤都會疊加傳遞到下一個人，最終呈現在餐桌上的問題往往是多個環節共同造成的。更麻煩的是，中間某個人的一個小錯誤，可能被後面的人以完全不同的方式放大或者掩蓋，追責起來極為複雜。
多智能體AI系統面臨完全相同的困境。每個AI接收上一個AI的輸出作為自己的輸入，然後產生新的輸出傳遞給下一個AI。這種鏈式結構意味著，哪怕第二個AI說了一句模糊的話，傳遞到第五個AI時可能已經演變成一個完全錯誤的結論。研究人員發現，現實中的多智能體系統經常遭遇"誤協調"問題，各個AI之間資訊傳遞效率低下，出錯時又難以確認責任歸屬。
更根本的問題在於，目前主流的優化方法都依賴"粗粒度反饋"——也就是只告訴系統整體表現好不好，而不說明哪裡具體出了問題。這就好比餐廳老闆每次只對廚房喊一聲"今天菜做得不行"，既不指出是哪道菜，也不說明是什麼問題，廚師們只能憑感覺猜測和調整，效率極低。
正是為了解決這個問題，研究團隊開始思考：能不能建立一種機制，像給每句話標註"影響力分數"一樣，精確追蹤多智能體系統中每個輸出對最終結果的貢獻？
---
二、梯度：這把追責的"解剖刀"是怎麼工作的
要理解GBC的核心機制，先要理解"梯度"這個概念。在數學上，梯度描述的是"當你改變一個因素時，結果會怎樣變化以及變化多大"。想像你在爬山，梯度就是地面的坡度——坡越陡，朝那個方向邁一小步，高度變化就越大。
在AI的世界裡，梯度被用來衡量某個輸入對輸出的"敏感程度"。如果把上一個AI的某句話刪掉或者改寫，下一個AI的輸出會發生多大變化？變化越大，說明那句話的影響力越強。GBC就是利用這種敏感度分析，為多智能體系統中每一對相鄰AI之間的資訊傳遞建立一個"影響力分數"。
具體來說，研究團隊將整個多智能體系統建模成一張"計算圖"——可以把它理解成一張流程圖，每個節點代表一個AI，節點之間的箭頭代表資訊流向。每個AI接收來自前一個AI的輸出，加上自己的任務說明，生成新的輸出。GBC要做的，就是在每條箭頭上標註一個數值，表示這條資訊傳遞有多重要、影響力有多大。
為了計算這個影響力分數，研究團隊設計了四種不同的計算方式。第一種叫"L1範數均值"，它計算上一個AI的輸出中每個詞對下一個AI產生輸出的平均影響力，然後把這些影響力加總平均。第二種叫"L1範數最大值"，類似第一種，但只取所有詞中影響力最大的那個作為代表，這樣能減少無關詞彙的干擾。第三種和第四種則引入了一個更精細的分析維度：不僅看梯度本身，還把梯度和詞語本身的"權重"（即詞向量）相乘，這種方法借鑑自生物資訊學領域的歸因分析技術，能捕捉到更細膩的"第一階貢獻"。四種方式分別對應均值和最大值兩種匯總策略。
計算出所有影響力分數之後，GBC會從中挑選出每個AI的最重要前驅（默認保留影響力最高的一個），由此構建出一張"歸因圖"——只保留那些真正關鍵的資訊傳遞路徑，把那些影響微弱的路徑過濾掉。這張歸因圖，就是後續追責和優化的"地圖"。
---
三、沿著"錯誤地圖"向前追溯
有了歸因圖之後，GBC的下一步是把"錯誤信號"從終點沿著這張地圖向起點傳播。
回到餐廳的比喻：客人抱怨後，服務員把反饋傳遞給擺盤的人，擺盤的人說"我的食材是從炒菜的人那裡拿的"，於是反饋繼續傳遞給炒菜的人，炒菜的人又說"菜是切菜的人切的"……這樣一路追溯下去，就能找到問題的源頭。
GBC做的正是這件事，只不過是用數學方法自動完成的。在系統的最終輸出處，研究團隊首先定義一個"語言損失"——用自然語言描述這次輸出到底哪裡出錯了，比如"酒店的停車場資訊預測錯誤"或者"遺漏了用戶要求的餐廳價格區間"。這個損失信號附著在歸因圖的終點，然後按照圖中的路徑一級一級向前傳播，途經每個節點時記錄下"這個AI的哪次輸出最應該為這個錯誤負責"。
整個回溯過程會生成若干條"歸因軌跡"，每條軌跡就像一條從錯誤終點到某個可疑源頭的麵包屑路徑。收集了足夠多的軌跡之後，優化器就能知道：在這批訓練樣本中，哪些AI出錯最頻繁，哪些錯誤類型最常見，應該優先修改哪個AI的工作說明。
論文中用一個算法（Algorithm 1）詳細描述了這個反向傳播的過程，本質上是一次圖的深度遍歷：從損失節點出發，沿著歸因圖中的路徑遞歸地向前追溯，把每條完整的路徑記錄下來存入對應AI的"軌跡庫"，直到追溯到系統的初始輸入為止。
---
四、AgentChord：讓這一切真正可用的工程框架
理論上再好的方法，如果在實際運行時需要消耗天文數字的計算資源，也很難真正落地。梯度計算本身是非常消耗內存的操作，尤其是對於擁有數百億參數的大型語言模型來說，為每一個詞都計算梯度，內存開銷會急劇膨脹。
研究團隊為此專門設計了一種叫做"前綴梯度計算"的技巧。回想一下多智能體系統中每個AI的工作方式：它接收兩類輸入，一是固定的"工作說明"（也就是任務提示詞），二是來自上游AI的動態輸出。GBC只需要計算動態輸出部分的梯度，工作說明是固定不變的，不需要對它做梯度追蹤。
於是，系統先用不需要記錄梯度的模式處理固定的工作說明，把計算結果緩存起來；然後再用需要記錄梯度的模式處理動態輸入部分。這樣一來，儲存梯度所需的內存量從正比於"總輸入長度"縮減到正比於"動態輸入長度"。如果一段工作說明占了總輸入的一半，內存消耗就直接減少了一半，這在實際工程中是一個非常可觀的優化。
AgentChord整合了GBC的歸因機制和一個以大型語言模型充當優化器的提示詞改寫系統。每輪優化的流程是：讓多智能體系統跑一批訓練樣本，收集歸因軌跡和錯誤資訊，然後把這些資訊連同當前所有AI的工作說明、可用工具列表和歷史優化記錄一起交給優化器，讓它分析問題並給出改進後的工作說明。優化器被要求不改變AI之間的調用順序，只能修改工作說明的內容，並且被要求以特定格式輸出改進建議和理由，以便系統自動解析和應用。
---
五、在真實任務上的表現：兩個不同維度的考驗
研究團隊選擇了兩個公認具有挑戰性的基準測試來驗證GBC的效果，這兩個測試考驗的是完全不同維度的AI能力。
第一個測試叫MultiWOZ 2.4，這是一個任務導向對話基準，模擬的是用戶同時在多個領域（酒店、餐廳、景點、火車、計程車）提出需求時，AI系統需要同時處理這些不同領域的預訂和查詢任務。研究團隊為這個測試設計了一套管理員-工作員架構：一個"管理者AI"負責根據對話內容分配任務，五個"領域專家AI"分別負責酒店、餐廳、景點、火車、計程車的API調用，最後一個"回復者AI"負責將所有資訊整合後生成用戶看到的最終回答。
評估指標包含六個維度：Inform分數（系統是否查詢到了正確的資訊）、Success分數（整個對話是否成功完成了用戶的目標）、JGA（聯合目標準確率，衡量每個對話輪次中系統對用戶意圖的理解是否完全正確）、槽位召回率、槽位精確率和槽位F1分數（後三者衡量系統對用戶需求中各個具體欄位的識別準確程度）。
實驗用了兩種不同的底層模型：Llama-3.3-70B-It和Qwen-3-32B。結果顯示，優化之前，多智能體系統並不比單個AI表現更好——以Qwen-3-32B為例，多智能體系統的Inform分數（95）和Success分數（80）確實高於單智能體（88和40），但JGA（28.9 vs 44.4）和槽位F1（79.3 vs 88.5）卻明顯更差，說明多智能體系統雖然"大方向對了"，但對細節的把握反而更混亂。
經過GBC優化之後，情況發生了顯著變化。以Qwen-3-32B加上"L1範數均值"連接權重的組合為例，JGA從28.9躍升至54.4，槽位F1從79.3上升至91.4，同時Inform達到99.0、Success達到94.0。這個優化後的多智能體系統在所有六個指標上都超越了單智能體基線，說明GBC成功地把一個"亂糟糟"的多AI團隊改造成了一個真正有效的協作體系。
整個優化過程使用了30個訓練樣本，每處理3個樣本更新一次提示詞，共進行10個優化步驟。從優化軌跡來看，Inform分數和槽位召回率在整個過程中始終保持較高水平，而JGA、槽位精確率和槽位F1則呈現出清晰的上升趨勢。Success分數的波動最大，說明完成用戶的完整目標這件事涉及更長鏈路的協調，僅靠提示詞優化改善起來相對困難。
第二個測試叫τ-bench，考驗的是一種完全不同的能力：AI系統需要通過多輪對話、調用各種工具（如查詢訂單、修改商品、處理退換貨等）來完成零售場景下的複雜客服任務。與MultiWOZ的靜態評估不同，τ-bench要求系統動態地與模擬用戶交互，每一步工具調用都會影響後續對話走向，更接近真實的業務場景。
研究團隊同樣設計了管理者-工作員架構，其中專家AI分別負責用戶資訊查詢、商品檢索、訂單修改、售後處理和用戶檔案管理五個子任務。評估指標分為三類：動作獎勵（工具調用序列是否與標準答案一致）、輸出獎勵（最終回答是否包含所有必要資訊）和綜合獎勵（兩者的乘積，要求兩方面都做對才能得分）。
優化之前，Qwen-3-32B多智能體系統的綜合獎勵只有13.0，低於單智能體的22.6。經過GBC優化，以"L1範數最大值"連接權重為例，綜合獎勵提升至24.3，超過了單智能體基線。"輸入乘積均值"策略同樣達到了24.3的綜合獎勵，主要得益於動作獎勵從13.9大幅提升至27.0。對於Llama-3.3-70B-It，所有優化變體都超過了未優化基線，其中"輸入乘積最大值"策略表現最佳，綜合獎勵從6.1提升至9.6。
---
六、歸因質量與優化效果之間的隱藏聯繫
研究團隊還做了一項頗有意思的分析：不同的連接權重計算方式，歸因的準確性有多大差異？這種差異又是否能解釋優化效果的差異？
他們用一種直觀的方式衡量歸因準確性：檢查每條歸因軌跡是否正確地包含了"應該負責"的專家AI。在MultiWOZ中，如果當前對話涉及酒店預訂，那么正確的歸因軌跡應該包含酒店專家AI；如果涉及火車查詢，就應該包含火車專家AI。
分析結果揭示了一個清晰的規律：無論使用哪種底層語言模型（Llama還是Qwen），L1範數均值和L1範數最大值這兩種方式的歸因準確率始終高於基於輸入乘積的兩種方式。而在最終的任務表現上，L1範數類方法的優化效果也確實更好。這表明，歸因越準確，優化器收到的"錯誤定位資訊"就越精確，最終改進提示詞的效果也就越顯著。用研究團隊的話說："更高的歸因質量與更強的優化效果相關聯。"
此外，研究團隊還分析了不同AI在優化過程中被更新的頻率。他們計算了一個叫"歸一化更新頻率"的指標，衡量每個AI在"相關輪次"中被優化器修改的比例。結果發現，領域專家AI（如酒店、餐廳、火車等）的更新頻率明顯高於管理者AI和回復者AI。這與錯誤分析的結果高度吻合：主要的錯誤類型是跨域錯誤（管理者把任務分配給了錯誤的專家AI）、資訊遺漏（專家AI沒有提取到對話中的關鍵資訊）和過度預測（專家AI猜測了用戶沒有明確說出的需求），這些錯誤的根源主要在於各個專家AI自身的工作方式，而不是管理者或回復者的問題。
在τ-bench的錯誤分析中，最常見的錯誤類型是"檢索和識別失敗"，即AI無法在複雜的多輪對話中正確定位到當前正在討論的訂單、用戶或商品。這種基礎資訊定位失敗後，後續所有的工具調用和回復內容都會出錯，屬於"牽一髮而動全身"的關鍵失誤。其次是工具誤用、管理者指令不清、過早放棄任務和錯誤的成功判斷。這些錯誤模式揭示了τ-bench的核心難點：它要求系統在多個回合中維護準確的任務狀態，這對AI之間的資訊傳遞精度要求極高。
---
七、這套方法的邊界與尚未解決的問題
任何方法都有其局限性，研究團隊在論文中坦誠地討論了GBC目前面臨的挑戰。
計算成本是最直接的問題。即便有了前綴梯度計算的優化，每次運行仍然需要對大型語言模型進行多次前向和反向傳播，比那些完全不需要訪問模型內部的"黑盒方法"要慢得多、貴得多。從時間數據來看，使用Llama-3.3-70B-It在MultiWOZ上完成10個優化步驟需要約16至17小時，使用Qwen-3-32B也需要8至9.5小時，這對快速疊代開發來說是一個較大的障礙。
語言損失的設計質量也是關鍵。GBC的優化信號來自於用自然語言描述"錯在哪裡"，但如果這個描述本身不夠準確或者覆蓋了錯誤的方面，就會給後續的歸因和優化帶來誤導。研究團隊指出，不同任務的語言損失需要專門設計，沒有一個通用模板能適應所有場景。
梯度方法本身是一種"一階近似"，它假設各因素之間的影響是線性疊加的。現實中AI系統內部的交互往往是高度非線性的，尤其是在多輪對話場景下，某個AI早期的一句話可能通過複雜的路徑對十幾步之後的輸出產生難以預料的影響，而梯度方法未必能完全捕捉這種長距離的複雜作用。
實驗的範圍也存在局限，目前只驗證了管理者-工作員這一種架構模式，在MultiWOZ（任務型對話）和τ-bench（工具使用型對話）兩個基準上進行了測試。GBC能否同樣有效地應用於代碼生成、開放式推理或者更大規模的自主智能體系統，還有待進一步驗證。
還有一些錯誤類型在優化後仍然存在，比如跨域協調錯誤和資訊遺漏。研究團隊認為這些問題可能部分源於底層語言模型自身的能力上限，並非僅靠優化提示詞就能完全解決的。
---
說到底，這項研究觸碰到了一個長期被忽視的核心問題：多個AI協作時，如何知道誰應該對錯誤負責。就像管理一個大型團隊，精細的績效追蹤比籠統的集體表揚或批評更能幫助每個人找到改進方向。GBC提供的"梯度指紋"機制，本質上就是給多AI團隊建立了一套精確的追責和改進體系。
對於普通用戶來說，這項研究意味著未來那些複雜的AI助手——比如同時幫你規劃旅行、預訂酒店、查詢航班、推薦餐廳的全能助理——將可能變得更加可靠，犯錯時也能更快地自我修正。對於AI開發者來說，這提供了一種比現有方法更精細的調試和優化工具，讓構建可靠的多智能體系統從"憑經驗猜測"變得更接近"有據可查的工程"。
值得繼續追問的是：隨著AI團隊越來越大、任務越來越複雜，這種基於梯度的歸因方法能否跟上擴展的需求？更高階的非線性交互效應是否需要完全不同的追責思路？這些問題的答案，或許正藏在未來幾年的研究進展里。有興趣深入了解這項工作的讀者，可以通過arXiv編號2606.28187查詢完整論文及配套代碼庫。
---
Q&A
Q1：GBC方法和現有的多智能體優化方法（比如DSPy、TextGrad）有什麼本質區別？
A：現有方法主要依賴整體任務表現來優化系統，只知道"整體結果好不好"，無法精確定位是哪個AI的哪次輸出造成了錯誤。GBC的核心區別在於它能在單詞（token）層面計算每個AI輸出對下游AI的影響力，建立精細的歸因圖譜，把"整體批評"轉變為"精準定位"，從而讓優化器能夠針對真正出問題的環節進行修改，而不是讓所有AI一起盲目調整。
Q2：AgentChord框架運行一次需要多少時間和計算資源？
A：實驗在配備四塊NVIDIA A40 GPU、208GB內存的單台伺服器上進行。完成10個優化步驟，使用較大的Llama-3.3-70B-It模型大約需要16至17小時，使用較小的Qwen-3-32B模型需要8至10小時。不同的連接權重計算方式（四種變體）之間的時間差異不大，主要耗時來自底層模型的規模和任務本身的複雜度。
Q3：GBC在MultiWOZ上的實驗結果，優化後多智能體系統比單智能體強多少？
A：以Qwen-3-32B為例，優化前多智能體系統的聯合目標準確率（JGA）只有28.9，遠低於單智能體的44.4。經過GBC優化後，JGA提升至54.4，超過單智能體約10個百分點；槽位F1從79.3提升至91.4，高於單智能體的88.5；Inform和Success分數分別達到99.0和94.0，也均高於單智能體基線。
