如果你在用强化学习训练多步骤的 LLM agent，大概率撞过这堵墙：一条轨迹跑完，环境只给你一个标量奖励——成了，或者没成。它不会告诉你究竟是第几步把方向带歪的，也不会告诉你哪一步其实做得很漂亮。这种"只看结果不看过程"的信号，让信用分配（credit assignment，把最终成败归因到具体步骤）变得极其困难，尤其在动辄十几步的 agent 任务里。 为缓解这点，社区这两年转向 rubric 奖励：不再只给一个数，而是用自然语言写一套评判标准，让裁判照着标准评。可解释性确实上来了。但 ARCO 这篇指出既有 rubric 方法有两个没解开的结。其一，它们只在整条轨迹层面打分，落不到单步，步级信用分配还是悬着的。其二，那个打分的裁判通常是一个闭源、外部、固定的模型——它不随训练改进，也无法和被训练的策略一起适配任务，整个评判体系是静态的。 ARCO（Adaptive Rubric CO-evolution，自适应评判标准协同进化）针对这两点重新设计。核心是引入一个与策略同尺度的模型 μ，它和策略共享同一个主干网络，但分出两个头：一个是生成头，负责逐步产出该步该用什么评判标准；另一个是打分头，负责在这些标准的条件下预测每一步的奖励。换句话说，"该怎么评"和"评几分"由同一个模型内部协同完成，而不是外包给一个黑盒裁判。 那么没有人工标注的步级标签，怎么保证这些步级奖励是靠谱的？ARCO 用了一条轨迹分解约束：强制所有步级奖励之和等于这条轨迹的终局结果。终局结果是有客观信号的（任务成没成），于是这条约束相当于用一个可验证的总账，去约束内部那本"分步明细账"——让步级奖励既细到每一步，又不至于自由发挥到脱离实际成败。这是它实现"无步级标注的信用分配"的关键。 还有一层是协同进化。μ 和策略 π 在同策略（on-policy）数据上联合更新，意味着评判标准的内容和打分函数会随着策略一起在参数层面演化，而不是策略在变、裁判却钉死不动。这正是名字里 co-evolution 的由来，也直接回应了前面说的"裁判静态"的毛病。 实验放在三个经典的多跳问答基准上——HotpotQA、2WikiMultiHopQA、MuSiQue，这些任务都需要跨多个文档、多步推理才能得出答案，正好考验过程级的信用分配。作者用了两个开源底座模型，并报告 ARCO 在每一个设置下都刷新了最佳 EM（exact match，精确匹配率），并且超过了三类对照基线：只看结果的 outcome 奖励、整轨打分的 rubric 奖励、以及 process 奖励。需要诚实说明的是，原文摘要未给出具体的 EM 数值，所以"赢多少"无法量化，这里只能转述其"每个设置都更好"的定性说法。 对做 agent 后训练、RLHF/RL 流程的人，这条的看点在于它把"过程奖励"和"裁判同源、可进化"这两件常被分开处理的事放进了一个共享主干的统一框架，且不依赖闭源裁判、不需要逐步人工标注。保留也清楚：当前证据集中在多跳问答这一类任务上，是否能迁移到工具调用、代码、终端等更长程的 agent 场景，以及到底领先多少，都还要等完整论文的数字和更广的评测。