多智能体编排有个老毛病：团队组好了，跑完一圈发现某几步「看似合理却走不通」，只能等整段轨迹结束再回过头复盘改结构。一篇 10 月 1 日挂出的论文（arXiv 2609.38661）提出 EvoSteer，把这个时序颠倒了过来——编排器不等收工，而是在运行时就地组队、就地修。它把「自演化图编排」从事后补救，变成了执行中的实时自愈。
信用分配才是真难题
EvoSteer 的核心不止「边跑边改」这么简单，更难的是给每一步「记功过」。多智能体里一个动作的好坏，往往要等后面几步才知道，而传统做法常把终端奖励平摊给所有动作，结果每个动作都分到差不多的虚假优势，根本分不清谁该背锅、谁该立功。作者提出锚定轨迹平衡（AnchorTB），用一种回归式的流匹配损失，把每个编排动作的系数，对照一条冻结的参考轨迹来标定——子轨迹和参考越对得上，系数越可信，从而把信用精确地安到真正起作用的动作上。这在数学上把「谁的贡献被稀释了」这件事量化了出来，也让编排器自此有了「可以信赖的账本」。
技能不是进来就晋升
另一个容易被忽略的设计，是「验证式技能准入」。多智能体系统常犯一个错：学到的新技能直接进常用库，良莠不齐地参与后续任务。EvoSteer 的做法是反过来的——一个候选技能必须先被试用，而且只有在配对证据通过一道共享名义测试预算下的序贯检验后，才被正式晋升、纳入可调用集合。这相当于给技能库加了一道「试用期」，避免错误经验悄悄污染团队。论文在十二个数据集上覆盖问答、数学推理、代码生成与交互式决策，报告称全面优于基线，但具体数值来自作者自报，独立复现仍有待后续验证。
把编排从玄学拉回工程
EvoSteer 给落地团队的启示，比「又一篇编排论文」更实在：多智能体不可靠，通常不是因为模型不够强，而是因为「组队结构」和「信用怎么算」这两件事长期被拍脑袋。它把编排器的进化权，从「跑完再复盘」挪到「执行中自检」，把技能准入从「来者不拒」改成「先试后晋」，本质上是把工程里「可观测、可回滚、可准入」的老办法，搬进了智能体协作。它和近期一批关于共享状态污染、全局连贯性、记忆治理的研究是同一主线的不同切面——大家都意识到，多智能体的瓶颈早已不是单点智能，而是「一群智能体怎么可信地一起把事干完」。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态；但 AnchorTB 与验证式准入这套组合，足够给正在自建多智能体编排的团队提供一份可借鉴的施工图。
举个能感知的例子：一个负责写代码的子 Agent 改完文件，真正让测试通过的可能是一段它顺手做的环境配置，而不是被记功的那次代码改动。静态做法会把成功归功于「最后一步」，于是下次只复用那次改动、丢掉了真正关键的环境处理。AnchorTB 这类方法想做的，正是把「哪一步才是有效动作」从终端奖励里剥离出来，让编排器学会把信用安到对的地方。这听着抽象，落到产品里就是「为什么这次成了、下次还能不能成」的可解释性，而这恰是多智能体上生产前绕不开的一道关。
值得补充一句辩证视角：在线自演化听着很美，也带来新的治理负担。一个能在运行时改写自己团队结构的编排器，一旦改错了方向，后果会比静态编排更难追溯——因为它连「当时为什么这么组队」都可能只留在一串动态系数里。所以 EvoSteer 这类方法的真正落地门槛，不只是算法本身，而是配套的「演化可审计」：每一次组队调整、每一次技能晋升，都得能回放、能问责。否则自愈能力越强，失控时的盲区也越大。对想把多智能体推上生产的团队，这或许才是比选哪篇论文更该先想清楚的前提。