在多智能體協作系統里，信息像潮水一樣涌來，每個代理都在說話、檢索、推理，歷史對話和外部知識不斷堆積。若不加甄別地把“所有上下文”一股腦兒塞給所有代理，你得到的往往不是更聰明的系統，而是更貴、更慢、更亂的系統。

冗余信息增加了噪音，token 成本飆升，模型注意力被牽扯，真正關鍵的證據反而被淹沒。尤其在多輪互動中，任務焦點會遷移——如果路由策略不跟著任務階段變化而調整，協作效率就會被拖垮。

RCR-Router 把這件事做“對”了！一句話總結，它在結構化共享記憶之上，按“角色 × 任務階段 × 預算”動態路由最相關的上下文，并用迭代式反饋不斷凈化記憶與路由，讓每個代理在合適的時刻只看到對自己最有價值的內容。少而精，才是真正的聰明。

結果很務實：在 HotPotQA、MuSiQue、2Wiki等多跳基準上，RCR 同時提升答案質量并降低 token 使用與時延，相比全上下文更高效，相比靜態路由更準確。經驗上，最佳的“性價比”落點大約是每代理 2048 token 的預算、3 輪迭代，這個組合既穩又省。

這項工作是跨國合作，以美國高校為主導的八家科研機構聯合研發：卡內基梅隆大學，波士頓東北大學，哈佛大學，富士通美國研究院，麻省理工，北京大學，佐治亞大學，佛羅里達國際大學（Carnegie Mellon University、Northeastern University、Harvard、MIT、Florida International University、University of Georgia等），兼具中國高校參與（Peking University），并引入產業研究力量（Fujitsu Research of America）。學術前沿與工程落地的結合，使他們既能提出一套結構化、可解釋的框架，也能把效率與成本的細節打磨到位。

1.主要貢獻

研究的“硬核”在于，研究團隊把多智能體協作中最易被忽視卻最致命的部分——上下文的供給側改革——做成了一個可通用、可插拔、可度量的系統層。

RCR-Router提出了一個真正意義上的動態上下文路由層。它不是簡單的檢索或緩存，而是把“角色感知”“階段感知”“Token 預算”三件事一次性拉通：誰在做什么、現在任務處在哪個階段、他最多能帶多少上下文。路由不再依賴靜態模板，也不再向所有代理廣播冗余記憶，而是在結構化共享記憶上，按需切片、定向投喂。

研究團隊給系統裝上了“循環凈化器”。每一輪協作后，代理的輸出都會被抽取、過濾、結構化、沖突處理，再寫回共享記憶。下一個回合的路由據此更新。這條迭代式反饋閉環，讓上下文越跑越“干凈”：不但更相關、更新鮮，也更可審計。

再者，選擇機制務實而靈巧。重要性打分是輕量級的：角色相關性、階段優先級、時序新鮮度等信號綜合，既可啟發式配置，也可演進為可學習評分器。路由采用貪心策略，在嚴格的 Token 預算下最大化整體重要性評分，工程上易實現、行為上可解釋。

評測維度也被補齊。除了標準的 QA 指標，研究團隊引入 Answer Quality Score（AQS），用強模型對“答案+解釋”打分，兼顧正確性、相關性、完整性與清晰度，避免只看最終答案而忽略推理質量的偏差。

最后，實證結果給足了說服力。在 HotPotQA、MuSiQue、2WikiMultihop三個多跳基準上，RCR 在提升答案質量的同時顯著降低token 消耗與時延，相比全上下文更省、更穩，相比靜態路由更準、更強。消融實驗進一步揭示了“預算—性能”和“迭代—性能”的拐點：每代理約 2048 token、3 輪迭代是一個兼顧成本與質量的甜蜜點。

2.方法總覽與問題表述（Problem Formulation）

把鏡頭拉遠一點，這是一個由多個專職代理協同完成復雜任務的系統。系統里有一套共享記憶，像是大家共用的“白板+檔案柜”，寫著歷史對話、外部事實、檢索片段，還有結構化的狀態與計劃。

在形式化上，系統包含一個代理集合 A={A1,…,AN}，每個代理都帶有明確的角色標簽（planner、searcher、summarizer、verifier…），并在離散的輪次中互動推進。

每一輪都有一個任務階段 St，標記當前是在規劃、檢索、綜合還是驗證；同時有一個共享記憶 Mt，承載著三類關鍵信息：代理交互歷史、外部知識與工具回執、以及通過 YAML/圖/表組織的結構化狀態。

每個代理不會“讀全庫”，而是接收一份被路由過的上下文C^it ? Mt。這份上下文由 RCR-Router 根據角色、階段與該代理的 token 預算定制挑選。代理據此構造提示，發起 LLM 調用，產出 LLM output^it = LLM(Prompt(C^it))，輸出再被抽取、過濾、結構化后寫回，為下一輪打地基。

這一切圍繞一個樸素而關鍵的目標展開：在不犧牲任務質量的前提下，把上下文成本壓到更合理的區間。研究把它寫成了一個期望最大化問題：在所有可能的路由策略里，尋找那條能讓 TaskSuccess 最大化、同時對累計 TokenCost 征收“懲罰”的最優策略。具體來說，就是最大化E[TaskSuccess ? λ ∑_{t,i} TokenCost(C^it)]。λ 是權衡旋鈕：往左，性能優先；往右，成本優先。通過這個目標，系統被迫學會做艱難但必要的取舍，把有限的 token 用在刀刃上。

從工程視角看，RCR-Router把“誰要看什么、此刻最該看什么、最多能看多少”三連問，轉化成了可執行的路由決策；從科學視角看，它把多代理協作的上下文經濟學，納入了一個可優化、可證實的框架。接下來，重要性評分、預算分配、語義過濾與迭代更新的細節，構成了這臺“上下文路由引擎”的四缸馬達。

3.RCR-Router 架構與核心組件

讓我們先看“地基”——結構化共享記憶層。這里不是一堆難以索引的長文本，而是被規整成 YAML 片段、圖結構、表格條目等可查詢、可組合的語義單元。這樣的抽象有兩個現實好處：一是檢索高效，二是為“按需切片”提供了天然的邊界。信息不是漫無目的地堆放，而是帶著來源、時間、實體、關系與階段標簽“有序呼吸”。

圖1：具有自適應反饋環路的迭代RCR路由器架構。在每個交互輪t，RCR路由器根據每個代理的角色和任務階段動態地將語義過濾后的內存路由到每個代理。通過內存更新步驟，代理輸出被結構化并集成到更新的共享內存Mt+1中，從而能夠逐步細化代理上下文和自適應多代理協調。這種迭代循環支持高效的多輪推理，并提高了整體任務性能。

在這塊地基上，第一位“調度員”是 Token 預算分配器。它把每個代理的上下文額度先定出來：Bi = βbase + βrole(Ri)。可以把 βbase 理解為“人人都有的基本盤”，βrole 則是根據角色差異進行的偏置加成。規劃者可能需要更多結構化計劃與依賴關系；執行者則更吃“當前步驟的關鍵指令”。預算不是裝飾，而是硬約束——所有后續路由決策，都必須在它的邊界內完成取舍。

第二位“調度員”是重要性評分器。它是整個系統的“價值感知器”，綜合三類主信號：

角色相關性：記憶項與當前角色的關鍵詞、職責匹配度；

階段優先級：項目正處于規劃/檢索/綜合/驗證的哪一環，貼合當前階段的內容權重更高；

時序新鮮度：越新的、越接近當前回合的證據，越應該被看到。 這套評分器是輕量的，可以用啟發式規則快速起步，也可以在有數據時進化為可學習打分模型。進一步的去重與覆蓋增益（marginal coverage）也能接入，以避免“同義反復”擠占寶貴預算。

第三位“調度員”是語義過濾與路由器。它的目標直白而苛刻：在不超過 B_i 的前提下，讓總重要性最大。形式上，就是在 C′ ? Mt 上求 argmax ∑{m∈C′} α(m; Ri, St)，約束 ∑ TokenLength(m) ≤ Bi。實現層面，采用貪心 top-k 選擇：先按分數降序，再按預算順序拾取，直到剛好卡住。策略本身是無狀態的，但它被“角色與階段”條件化，因此每一輪都會生成不同的上下文切片。這種“簡單而足夠好”的選擇邏輯，成就了工程上的穩定與可復現。

當結構化記憶、預算分配、重要性打分、語義路由四件套聯動起來，你會看到一個不同以往的多代理系統：每個角色看見的，不再是碎片化的全局歷史，而是為它當下職責量身裁切的證據包。上下文驟然“安靜”下來，推理開始“聚焦”起來。

4.迭代式路由與反饋閉環

真正的巧思在于，這個系統不是“一次性路由”，而是呼吸式的。每一輪都經歷同樣的節律：路由 → 推理 → 結構化輸出 → 記憶更新 M_{t+1} → 再路由。代理在聚焦上下文上完成思考，產出的事實、子計劃、工具結果被“抽取—過濾—結構化—沖突處理”后寫回共享記憶。下一輪路由就會把這些最新、最有信息增益的內容優先送達給最需要它們的角色。

這條更新流水線很講究。Output Extraction 確保我們抓住了有用的“硬貨”；Relevance Filtering 阻止記憶無節制膨脹，把冗余與低價值內容擋在門外；Semantic Structuring 把自然語言轉成規范化的 YAML 塊、圖三元組或表格條目，提升可檢索性與復用性；Conflict Resolution 則在新舊證據沖突時給出一致性答案，或替換，或合并，避免“多版本事實”污染后續推理。

優勢由此自然流出。首先，新事實、新子計劃、新的工具結果不再需要“靠運氣被看見”，而是被可靠地輸送給關鍵角色；其次，路由會隨著互動動態自適應，減少無謂的反復搜索與解釋；最后，通過對陳舊信息的抑制，系統避免了“在同一把舊草上反復打轉”，把token 花在真正改變決策的地方。

這樣的閉環讓多輪推理具備了“自凈能力”。你會發現，三輪往往足夠：第一輪鋪開證據面，第二輪校正與補充，第三輪收斂與定稿。在這個節奏里，RCR-Router 更像一位懂行的總編輯——刪繁就簡，去偽存真，把上下文從“信息洪水”剪成“高密度文摘”，讓每個代理都能在自己的版面上寫出關鍵的那一段。

5.實驗設計

研究的實驗像一場三重奏：數據、指標、基線相互呼應，既考察多跳推理的硬實力，也檢驗“上下文經濟學”的精打細算。

先看數據集的選型。HotPotQA、MuSiQue、2WikiMultihop是多跳問答里的“三駕馬車”，分別強調跨段落證據聚合、由單跳組合成多跳的復雜性、以及顯式的推理鏈與證據路徑構建。把多跳 QA 改寫為多代理分工（Planner/Searcher/Recommender 等）后，它們能充分暴露“誰需要看什么”的路由難題，也最能體現結構化記憶與階段感知的價值。

指標設計也很講究。傳統的 Precision/Recall/F1 繼續扮演“答案對不對”的裁判。但研究團隊不滿足于此，他們引入 AQS（Answer Quality Score）作為“解釋力”的裁判，由強模型在 1–5 分區間對正確性、相關性、完整性、清晰度進行聯合打分。它像是一面照妖鏡：不僅看你有沒有答對，還看你“為什么這樣答”。

基線選擇兩端壓陣。Full-Context 是信息上界：每輪把整庫上下文端給每個代理，簡單粗暴但成本最高；Static Routing 則是模板派：上下文切片為每個角色靜態配置，省 token、卻對階段與歷史“無感”。RCR-Router立在兩者之間，主打“按需投喂+嚴格預算”。

另外一個關鍵維度是迭代設置。研究團隊區分 One-shot（K=1）和Iterative（K>1）。前者像“一錘定音”，后者允許“邊干邊改”，讓反饋推動路由與記憶更新。這是檢驗“迭代式凈化”是否真的有用的觸發器。

6.主要結果與分析

如果要用一句話概括結果：RCR 把“更準”和“更省”同時裝進了口袋。

從總體表現看，三個數據集上，RCR 都實現了更高的答案質量和更低的 token 消耗與更短的運行時。相比 Full-Context，RCR 通過過濾與預算控制大幅削減冗余；相比 Static Routing，RCR 憑借角色/階段感知與迭代反饋拿回了適配性與準確度。

圖2：跨數據集：平均運行時比較。

RCR路由器在HotPotQA、MuSiQue和2wikimultihop的運行時性能始終優于全上下文和靜態路由。運行時改進在HotPotQA上最為突出，將延遲從150.65秒減少到93.52秒。這表明RCR路由器在不影響應答質量的情況下實現了更好的效率。

把鏡頭拉到各個數據集。HotPotQA 上，RCR 的 AQS達到 4.91，Token 僅 3.77K，平均時延 93.52 秒，質量和效率雙第一。MuSiQue 上，AQS 4.61、Token 11.89K、45.09 秒，同樣拔尖。2Wiki 上，AQS 4.83、Token 1.24K、82.50 秒，延續領先。你能感到一種穩定的風格：不追求“看得最多”，而是“看得最對”。

預算消融的結果很接地氣。把每代理預算 B 從 512 增到 4096，成本與時延單調上升，質量卻是次線性提升，超過 2048 后收益明顯變緩。換句話說，2048 是一個很好的“拐點”：再喂更多上下文，性價比就開始走下坡路。

迭代消融同樣給出了清晰的答案。在 HotPotQA、MuSiQue 的曲線上，T=3 是質量峰值且 token 使用最低的甜蜜點；繼續加輪次，開始出現邊際遞減甚至輕微回落，可能是因為過度迭代帶來信息震蕩或選擇噪聲。

圖3:HotsPotQa上的迭代路由消融結果。

至于計算開銷，這是很多系統落地的痛點，但 RCR 沒讓人失望。三個數據集上，它都拿下了最低平均運行時，尤其在 HotPotQA 上，把 Full-Context 的 150.65 秒直接壓到 93.52 秒。路由與過濾的成本被“凈省的 LLM 開銷”輕松覆蓋，從而實現了真正的端到端加速。

如果把這些結果拼起來看，會得到一個樸素而可靠的“配置食譜”：每代理 Token 預算約 2048，迭代 3 輪起步；用結構化記憶維持語義接口的穩定性；用輕量評分器與貪心路由穩穩把控預算與相關性。這樣搭出來的多智能體系統，不追求豪華，而是講究“刀法”——把最鋒利的一寸，留給最關鍵的一問。

7.與現有工作的關系（Related Work）

圍繞“多智能體 + 記憶 + 編排”這條主線，生態里早已有一眾玩家：有人擅長把團隊搭建起來，有人擅長把筆記收拾得干干凈凈，但真正把“誰、在什么時候、應當看到多少、看到什么”這一層做成標準化能力的，并不多見。

多代理框架側

X-MAS：強調異構 LLM 的協作，讓“不同腦袋”各顯神通，但對上下文的供給更多依賴外部模塊，缺少細粒度的角色/階段條件化路由。

AutoGen：提供靈活的多代理交互框架，會話與工具調用編排很強，但上下文選擇通常停留在對話歷史或模板層。

MetaGPT：把人類工作流的“元編程”注入到代理協作中，流程感優秀，仍需要一個語義路由層來控制信息劑量與相關性。

AgentScope：開發者友好的消息交換平臺，通信基礎設施扎實，未內建“角色×階段×預算”的上下文挑選策略。

LangChain/LangGraph：復雜任務的圖式控制做得好，提供多樣記憶模塊，但語義路由通常由使用者自行拼裝。

記憶管理側

MM、Memory Sandbox、A-mem、AIOS、HIAGENT：從元數據、沙盒交互、代理化組織、操作系統視角、層級子目標等多個角度改進“記憶存取與形態”，讓記憶更可控、更可視、更結構化。

RoRA、HMMI：一個關注有限內存下的可靠性優化，一個研究分布偏移與記憶受限條件下的代理行為，分別提供“資源層優化”與“需求層動機”。

把這些拼在一起，你會發現一處空白地帶：多數方法聚焦“編排”和“存取”，卻少有把“角色 × 任務階段 × Token 預算”的語義路由機制，沉淀成標準化、可插拔的系統層。RCR-Router 正是用一個輕量而可用的方案補上了這塊短板：把評分、預算、過濾、迭代更新連成閉環，讓多代理系統擁有“按需投喂”的內生能力，而不是靠手工模板或一刀切的全量廣播。

8.工程實現與復現建議

落地這類系統，關鍵在于“數據怎么裝”“分怎么配”“尺子怎么量”。以下是可以直接照做的抓手。

數據模式與治理

給每個記憶項定義統一 schema：包括但不限于來源（source/provenance）、時間戳、置信度、摘要、引用、關聯實體/主題、指派的角色/階段標簽、工具回執、版本號/哈希。

用 YAML/圖/表三種形態承載：YAML便于塊級聚合與批注，圖用于實體/關系推理，表用于指標/事實的對齊與去重。

建立“可追蹤、可審計”的寫回策略：誰寫的、何時寫入、為何覆蓋，日志化保存。

打分與去重

重要性評分建議融合：語義相似度（與當前子任務/指令的匹配）、新穎度（相對已選內容的增量信息）、來源權重（可信度/權威度）、階段匹配度、時序新鮮度（衰減函數）。

做好覆蓋增益控制：避免等義復述擠占預算，可加入多樣性約束或邊際增益閾值。

路由選擇用“預算化貪心”：在∑TokenLength(m)≤Bi\sum \text{TokenLength}(m) \le Bi 的硬約束下，按降序拾取高分項，保證可解釋與可復現。

預算與默認配置

推薦起步配置：每代理B≈2048\,B \approx 2048\,；迭代 T=3\,T = 3\,。先把“七成把握”穩住，再按場景微調。

角色化預算：Planner > Researcher/Summarizer > Executor/Verifier；也可隨輪次遞減（探索 → 收斂的退火式預算）。

風險與注意

策略無狀態可能遺漏跨輪長程依賴：可疊加“長期記憶鉤子”（pin 關鍵事實/約束，跨輪必送），或維護每個代理的小型持久緩存。

沖突合并策略需可審計：保留舊版本快照與合并理由，支持回滾與差異對比。

AQS 的評分偏置：定期抽樣做人評校準，或多評器集成降低單一評器偏移。

工具與檢索可信度：記錄工具版本、參數、返回碼與置信分；對異?；貓淘O置熔斷與降級路徑（回退到靜態路由或最小必要上下文）。

9.應用前景與落地場景

這不是只為學術競賽準備的“花拳繡腿”。任何“任務可拆、角色可分、證據可累”的系統，都能吃到 RCR 的紅利。

多跳檢索問答與研究助理：用結構化記憶保存證據鏈，路由把關鍵片段送到最適合整合與質檢的角色，顯著減少冗余閱讀。

工具使用與 RAG：在固定預算內，優先傳遞高置信的檢索塊與工具回執，避免“為了找一根針，背一座草垛”。

復雜流程編排：規劃—檢索—綜合—驗證—報告的多角色閉環，RCR 讓每個環節既“吃飽”又“不浪費”。

邊緣/嵌入式：結合模型壓縮與輕量路由，把 token 花在刀刃上，算力/延遲都能控。

貼近產業的延展想象：如跨法務—財務—技術的合規/審計/盡調協作，RCR 用“角色×階段×預算”把合規條款、審計證據、IoT 實測與報告片段精確送達，證據鏈更新也能通過迭代記憶自然傳播。

一句話收尾：RCR-Router 把“語義路由”從技巧做成了“層”，把“上下文經濟學”從經驗做成了“制度”。當你的系統不再被信息洪水裹挾，而是學會了在對的時刻，把對的證據，給到對的人，效率和可靠性，往往就一起到了。

參考資料：???https://arxiv.org/pdf/2508.04903??

本文轉載自??波動智能??，作者：FlerkenS