三个智能体一起干活，功劳怎么算
11 月 5 日提交的 arXiv 2611.07495，作者是 Kaixuan Liu 与 Guojun Xiong，归在机器学习类。它处理的是多智能体系统里一个很容易被跳过的问题：训练编排器的时候，功劳该怎么分。所谓学习型编排，是由一个中央编排器决定这一轮挑哪些智能体、以及每个智能体能看到哪些信息。眼下常见的训练办法，是给每一步决策各算各的优势值——这个写法默认了一件事：这一轮里其余决定都固定不动。
论文说这个默认在编排场景里站不住。后面那步的价值，取决于前面选了谁、传了什么；一次联合更新带来的收益，并不等于把每一步的单独效应加起来。团队提出的 IAPO 做的事，就是把两个策略之间的性能差精确拆成「单个决策的效应」与「决策之间的交互效应」，并证明交互项可以占到可达增益的一半；接着从采样轨迹里同时优化这两项，还给每次更新都带来改进提供了形式上的保证。换成大白话：排班表上换掉第二个人值不值，得看头一个人是谁，不能三格各打各的分。
少算那一项，代码题掉 7 到 17 分
实验口径也交代得比较齐：在长输入版的 GSM8K、MATH、DROP、MBPP 与 HumanEval 上，与 15 个已发表的多智能体和工作流搜索系统对照，统一用同一个 7B 执行器。结果是 IAPO 部署出来的方案用更少的词元，达到了对照里表现最好的那个系统的准确率；而把交互项从目标里拿掉，代码类任务的准确率掉 7 到 17 分。这个落差比「又涨了几个点」更有意思——同题、同底座、同样的数据，只改功劳怎么分，结果就拉开一截。
对不上论文也能用的一点，是评估口径：离线评编排策略时，如果只报「每步增益之和」，会系统性错估一次联合调整的收益，因为它把步骤之间互相改写价值的那部分当成了噪声。更靠谱的做法是看整条轨迹的闭环指标，并且把词元预算摆在同一条基准线上比。这和 2206 号那篇有个隐约的呼应：一篇说运行时预测器把题目难度误当成了运行信号，一篇说训练目标把联合收益误拆成了单步收益，毛病都出在「评价单位选错了」，只是一个在推理时、一个在训练时，别混成一件事。
和站内几篇谈「加人」的稿不在一层
1462 号讲多智能体扩队为何有时白扩，落点是共享模型偏差让加人变成重复同一个错；1260 号讲测试时通信，说会聊天的 k 个智能体能顶四倍规模的各自为战；1744 号处理并行时的气泡。这些都在问团队规模与协作方式有没有用。本篇不劝你加人也不劝你减人，问的是编排策略训练时的归因方式——是策略优化层，不是团队规模层。真要串起来读，顺序大概是：先决定怎么分工，再决定怎么给每次分工记功。
冷水：统一 7B 底座上的一个自报结果
该压的地方还是要压。数字全部来自作者自报，摘要里没提第三方复现；所有对照都压在同一个 7B 执行器上，换成更大或不同家族的底座，交互项还占不占得到那么大比重，论文没有给答案。「可占可达增益的一半」来自策略差的分解证明，不是说每个任务上都实测到五成；五个基准都是长输入版的学术题集，与真实业务里多轮工具调用、带外部状态和失败的编排工作流仍有距离。作者提到用更少词元达到对照水平，但没给出生产环境下的延迟、调度开销与稳定性数据。
所以更值得带走的不是那 7 到 17 分，而是别把编排当成一串独立决策去评估。至于 IAPO 在企业级多智能体平台上的部署成本、以及交互项在长程任务里会不会随步数放大，目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。