多智能体系统最大的时间小偷，不是模型推理太慢，而是下游 Agent 傻等着上游把整段话说完。StreamMA 团队抓住了这个痛点的命门——他们取消了“全部生成完毕再传输”的古典礼仪，让每个推理步骤像流水线上的零件一样，生成一个就扔给下一个智能体。这种流式通信范式在数学、科学和代码任务上砍掉了端到端延迟，同时把准确率平均拔高了 7.3 个百分点，在 HMMT 2026 基准上甚至飙到 22.4 个百分点。更狠的是，他们发现了一条步骤级缩放定律：让单个 Agent 多思考几步，系统不仅不会变慢，反而能同时收获更高的精度与效率。
别再等它想完了
流水线是芯片的老智慧，Agent 系统才学会
计算机体系结构里有个常识：指令级并行靠流水线，一个周期内各阶段同时干活。但奇怪的是，多智能体协作长期沿用“批处理”思维——上游模型吭哧吭哧生成完整回答，下游模型干瞪眼。StreamMA 把这层窗户纸捅破了。它采用的流式通信机制，让每个推理步骤一旦出炉，立刻通过管道滑向下游，无需等待整段文本杀青。端到端延迟因此显著下降，因为下游 Agent 可以边读边想，甚至边读边预热自己的推理状态。对工程团队来说，这意味着延迟的度量单位从“整段生成时间”变成了“步骤间隔时间”。这不是简单的异步调用，而是通信范式的根本切换：从“文件传输”变成了“直播推流”。
错误像病毒，越早隔离越好
传统多智能体链还有一个隐性代价：错误累积。上游 Agent 如果在中间某一步产生了幻觉或逻辑漏洞，下游 Agent 基于这份“完整但带毒”的输出继续发挥，只会让偏差像滚雪球一样膨胀。StreamMA 的流式传输在这里展现出第二层优势——早期步骤通常比后期步骤更可靠、更稳定。当这些高质量片段被优先传送给下游时，下游智能体得到更干净的上下文锚点，而不是被后期可能出现的胡言乱语带偏方向。换句话说，流式通信把信息流动从迟钝的批处理变成了高速通路，同时还在传播路径上设置了错误防火墙。等上游彻底说完再行动，等于把修正窗口留到了最后；边传边处理，则把纠错权交还给了每一个接收节点。这种机制在数学证明或代码调试中尤其致命——一步错，步步错，越早发现，回滚成本越低。
数字不说谎，但也不讲客气
八项基准，两种模型，全面飘红
实验设计本身就很能打。研究团队没有挑软柿子，而是覆盖了数学、科学推理和代码生成三类硬核任务，总计八项基准测试。更关键的是，他们用了 Claude Opus 4.6 和 GPT-5.4 两款当前顶尖的大语言模型分别做主干，又把 Chain、Tree、Graph 三种拓扑结构全部测了一遍。在这种严苛的交叉验证下，StreamMA 的平均胜率仍然达到 +7.3 个百分点。这意味着流式通信带来的增益不是某个模型的“甜蜜点”，也不是某种特定拓扑的偶然产物，而是跨模型、跨任务、跨架构的系统性优势。当基线方法还在精雕细琢单点提示词时，StreamMA 直接从通信层改写了游戏规则。它不依赖某个秘密的提示词模板，也不要求模型具备某种特殊能力，只是把数据流的方向和时机做了调整，收益就如此显著。
HMMT 2026 那场 22.4 分的突袭
7.3 个百分点已经够刺眼，但 HMMT 2026 上的表现才是真正的耳光。在这个高难度的数学推理基准上，StreamMA 相对基线轰出了 +22.4 个百分点的差距。这不是误差，这是代差。HMMT 的题目向来以长链条、多步骤著称，传统方法里每个 Agent 都得等前一位把整道题的推导过程写完，才能接棒。StreamMA 的流水线策略在这里如鱼得水：前几个正确的推导步骤一经流出，下游 Agent 就能立刻沿着正确的几何或代数路径继续深挖，而不是等到最后才发现前半段已经证错了方向。在需要严密逻辑递进的场景里，流式传输把“早发现、早纠偏”变成了结构优势，而不是后期补救。传统批处理模式下，下游 Agent 只能对着一堵完整的推理墙做二次加工；而 StreamMA 让用户能够在一堵墙砌到一半时就介入，甚至把歪掉的砖直接敲掉重砌。
步骤级缩放定律：反直觉的杠杆
加量不加价，还多送速度
这项研究最违背直觉的发现，是所谓的步骤级缩放定律。按照常规理解，让每个 Agent 多执行几步推理，系统总耗时应变长，毕竟计算量上去了。但 StreamMA 的数据显示，适当增加每智能体的步骤数，居然能同时提升最终效果与端到端效率。这怎么解释？因为流式管道里，步骤的增加并没有变成串行的“阻塞点”，而是被流水线的并行性消化掉了。上游在推第 N+1 步时，下游已经在消化第 N 步。更长的单 Agent 推理链反而让每一步的粒度更细、语义更清晰，下游更容易消费，减少了反复请求澄清或修正的额外轮次。你可以把它理解为工厂里的精益生产：单件流消除了库存积压，每个工序只处理当下必需的信息量，系统整体吞吐反而上升。最终呈现出一种罕见的双赢：深度和速度不再打架。
从通信范式到系统架构的连锁反应
步骤级缩放定律的深层含义在于，它指出了多智能体系统优化的主战场应该在哪里。过去社区热衷于在单点能力上堆参数、刷提示词，或者设计越来越复杂的调度器。StreamMA 暗示，通信层本身才是最大的未开发油田。一旦步骤可以像水流一样被即时消费，整个系统的瓶颈就从“模型有多强”转移到了“管道有多顺畅”。这会对工程实现提出新要求：智能体之间需要支持增量式上下文更新，而不是每次都在完整历史记录上做 KV Cache 重建；拓扑调度器也得学会在步骤粒度上做动态路由，而非在整段消息层面做粗粒度分发。缓存策略、重试机制、错误回溯逻辑，全都要为增量数据重新设计。谁先把这套流式基础设施做出来，谁就能吃到下一代多智能体架构的红利。
拓扑无关，这才是关键
链、树、图，谁用谁爽
多智能体系统的拓扑选择向来是架构师的头号纠结：链式简单但脆弱，树状能分叉但难同步，图结构灵活却容易死锁。StreamMA 的实验结果给出了一个解放性的答案——在 Chain、Tree、Graph 三种拓扑上，流式通信都取得了稳定增益。这意味着流式范式不是为某一种协作模式量身定制的小技巧，而是一种底层通信原语。链式结构里，它自然退化为经典流水线；树状结构里，父节点的中间推理可以更早广播给多个子节点，减少分支等待；图结构里，有向边之间的增量更新能缓解环状依赖带来的同步噩梦。换句话说，StreamMA 的流式原语就像 TCP/IP 协议栈里的数据报，不关心上层跑的是 HTTP 还是 FTP，只管把 packet 尽快送到。当通信方式不再被拓扑绑架，架构师才能真正根据问题本身的结构去选型，而不是为了迁就通信限制削足适履。
多智能体通信层需要一次底层重写
说到底，StreamMA 的价值不在于某个具体分数，而在于它指出了一个行业盲区：我们花大力气打磨了单模型能力，却长期用批处理时代的思维去连接它们。今天的 Agent 框架大多还建立在“请求-响应”的 HTTP 心智模型上，一个智能体调另一个，等完整响应回来再解析。这种范式在人与人聊天时成立，但在机器与机器协作时显得笨重且低效。机器不需要等对方说完礼貌用语，它们需要的是比特级的即时流动。把 StreamMA 的思路推向极致，未来的多智能体通信层可能会更像视频编解码的帧管道，或者金融交易市场的行情推送——低延迟、增量式、无阻塞。流式多智能体不是要微调现有框架，而是在提示工程、路由策略、缓存机制等各个层面发起一次底层重写。等到这波重写完成，回头再看今天的“等全说完再传”，大概会像看拨号上网一样怀旧。
