StreamMA 讓多代理推理邊想邊傳

StreamMA 把多代理推理改成即時串流傳遞，平均提升 7.3 個百分點，並降低層層接力造成的延遲。

• 研究機構：arXiv 摘要未明確標註
• 核心數據：八個 benchmark 平均 +7.3 個百分點
• 突破點：逐步串流下傳

多代理系統常見的做法，是上一個代理先把整段推理寫完，再交給下一個代理。這種接力很直覺，但代價也很明顯：越多層，等待越久；而且後面的代理只能在最後才看到前面的完整內容。StreamMA 想改掉的，就是這個「等全部做完才傳」的老習慣。

這篇論文的核心主張很直接：多代理推理不一定要用串行接力。只要把每一步推理一產生就往下游送，代理之間就能重疊工作，延遲也不必跟著管線深度線性膨脹。對做 agent workflow 的開發者來說，這是很實際的問題，因為速度和效果常常要一起考慮，不能只看其中一個。

這篇論文要解什麼痛點

作者鎖定的是多代理推理裡常見的「generate-then-transfer」模式。也就是說，每個代理都先完成完整的推理鏈，再把結果交給下一個代理。這種設計雖然簡單，但每多一層就多一段等待。論文認為，這會讓端到端延遲隨著 stage 數量線性增加，對想要堆更多代理、做更深推理的系統來說，很不划算。

更麻煩的是，延遲問題背後還藏著品質問題。摘要指出，推理品質在不同步驟之間並不平均，前面的步驟通常比後面的步驟更可靠。若下游代理一定要等整條推理鏈結束，反而會被較不穩定的後段內容拖累。換句話說，傳統接力不只慢，還可能把錯誤一路放大。

這很像開發者在串 LLM 做數學、科學或程式任務時會遇到的瓶頸。你可以加更多代理做驗證、補強覆蓋，但協調成本很快就吃掉好處。StreamMA 的目標，就是在不犧牲多代理拆解優勢的前提下，把這些額外成本壓低。

StreamMA 到底怎麼運作

StreamMA 的做法是：每個推理步驟一生成，就立刻往下游傳。這代表相鄰代理不必等完整 transcript 才開始工作，而是可以邊收邊算。整體上，它把多代理系統從「串行接力」改成「管線化處理」。

從概念上看，這個改動不複雜，但它改的是通訊協議。不是等上一個代理完全結束才轉交，而是讓下游代理直接消化部分推理。這樣下一個 stage 可以更早啟動，也可能先利用較可靠的前段步驟，再去處理後面可能比較雜訊的內容。

論文也不是只看單一路徑。摘要提到它評估了三種拓樸：Chain、Tree、Graph。這點很重要，因為多代理系統在實務上不只一種長相。有些是線性鏈，有些是分支樹，有些則有更多交叉驗證。不同拓樸下，串流傳遞的效果不一定一樣。

另一個值得注意的地方，是作者把這件事提升到理論層次。摘要說，他們做了第一個 closed-form 的 joint analysis，分別比較 stream、serial 和 single 三種 protocol。這表示論文不只是報一個工程技巧，而是想解釋為什麼串流會贏，並把品質、延遲和成本放在同一個分析框架裡看。

論文實際證明了什麼

這篇摘要公開的評估範圍包括八個推理 benchmark，涵蓋數學、科學和程式。測試模型是 Claude Opus 4.6 和 GPT-5.4，拓樸則包含 Chain、Tree、Graph。這些資訊至少說明了一件事：作者不是只在單一模型或單一任務上試水溫，而是想把方法放到較廣的多代理設定裡看。

結果方面，摘要給出的明確數字是：StreamMA 相較 baseline 平均提升 7.3 個百分點。最大增幅出現在 HMMT 2026，使用 Claude Opus 4.6-high 時，提升達 22.4 個百分點。摘要沒有公開完整 benchmark 表格，所以目前能確定的只有這些數字。

除了 benchmark 分數，作者還聲稱他們的 closed-form 分析導出了三個東西：effectiveness ordering、speedup upper bound，以及 cost ratio。摘要沒有把公式完整列出，但從這三個輸出可以看出，這篇論文想處理的不是單純「有沒有比較準」，而是想把效能、速度和成本的取捨關係一起講清楚。

摘要還提到一個叫做「step-level scaling law」的概念。意思是，增加每個代理內部的步數，會持續提升 effectiveness 和 efficiency。這很有意思，因為它多了一個和 agent 數量不同的調整旋鈕。實務上不只是看你有幾個代理，還要看每個代理要想幾步、傳幾步。

對開發者有什麼影響

如果你在做 agentic workflow，這篇論文最直接的提醒是：通訊協議本身就是性能的一部分。很多多代理系統預設都是「先做完，再交棒」，因為實作簡單。但 StreamMA 的論點是，這種預設會白白浪費時間，因為每一層都在等前一層完全結束。

在低延遲場景裡，串流中間推理可能特別有用。像是驗證、規劃、修正這類工作，不一定要等上游完全收尾才開始。只要下游能提早看到前面的步驟，就能更早介入。若前段推理本來就比較可靠，這種做法也有機會讓下游先抓住較穩的訊號，而不是被後段錯誤一路帶偏。

不過，摘要也留下不少實作層面的空白。它沒有說清楚部署複雜度、排程細節、失敗模式，也沒有交代串流和 prompt 設計、tool use 之間怎麼配合。再加上摘要沒有完整 benchmark 明細，所以目前比較適合把它看成一個方向明確、但仍需要更多實作驗證的方法。

如果把這篇論文濃縮成一句話，就是：多代理系統不一定要「等、再傳」，也可以「邊想、邊傳」。對開發者來說，這代表 multi-agent 的可調參數，不只是在加幾個 agent，還包括每一步的粒度要多細、什麼時候把資訊往下游放。

這篇研究的限制與後續觀察

先講限制。這份來源是 arXiv 摘要，因此很多關鍵資訊都還沒公開完整。像是完整 benchmark 表、實作方式、排程邏輯、以及不同拓樸下的具體差異，摘要都沒有展開。也就是說，目前看到的是方向和結果，不是完整可重現的工程手冊。

另外，摘要雖然提到三種拓樸與兩個 frontier LLM，但沒有提供更多細節去說明哪些設定最穩、哪些設定最容易受益。對實務團隊來說，這會影響導入判斷。因為一個方法在 paper 裡有效，不代表在你的 agent 架構裡就能直接套用。

但即使如此，這篇研究還是有一個很清楚的訊號：多代理系統的瓶頸，不一定只在模型能力，也可能在「資訊怎麼流」。如果未來 agent 系統越做越大，這種 protocol-level 的設計，可能會和模型選型一樣重要。

總結來看，StreamMA 提供的是一種很務實的改寫方式：把多代理推理從完整交棒，改成逐步串流。摘要顯示它不只降低延遲，也能把準確率往上推，但具體怎麼落地、成本多高、對不同系統是否穩定，還要等完整論文細看。

• 多代理推理可以從「等全部做完再傳」改成「每步生成就下傳」。
• 摘要公開的結果是八個 benchmark 平均提升 7.3 個百分點，最高提升 22.4 個百分點。
• 目前最大限制是摘要資訊不完整，部署細節與完整 benchmark 表都還沒公開。

論文網址：https://arxiv.org/abs/2606.05158