Agent 换个框架就崩？人大团队把"执行框架"做成了新的缩放轴
一、先说结论
做 Agent 强化学习的人大概都踩过这个坑：在自家 harness 上训出来的模型，换到 Claude Code 或另一个框架里，分数直接掉一大截。
原因不神秘。现有 Agentic RL 几乎都是在单一固定 harness 上训练策略——一套系统提示词、一套工具接口、一套上下文管理方式、一套执行流程。模型很快学会的不是"怎么解决任务"，而是"怎么用这套特定界面解决任务"。一旦界面变了，学到的那些隐式假设全部失效。
中国人民大学文继荣团队（联合 IQuest Research、北航）提出的 Harness Scaling，换了个思路：不再挑一个更好的 harness，而是把 harness 本身当成一个新的缩放维度。
一句话概括做法：把执行框架拆成 5 个因子、组合出 243 种配置，用正交设计精选 18 种做跨框架训练，让模型学会"在不同界面下都能干活"。
效果（Qwen3-4B，GRPO，Pass@1 三基准平均）：29.81 → 39.04，涨 9.23 分。迁移到训练中从未见过的 Claude Code 上：37.22，高于直接在 OpenClaw 上做 SFT（35.08）和 RL（33.38）。
论文在 arXiv（编号 2610.29458），10 月 24 日公开。
二、问题到底出在哪：Agentic RL 的"特化税"
先把这个坑讲清楚，因为它决定后面所有设计为什么长这样。
Agent 系统和普通 LLM 任务的差别在于中间隔了一层 harness。这一层决定了四件事：
Harness 的四项职责
├─ 怎么调工具 —— 工具叫什么名字、schema 长什么样、有没有干扰项
├─ 怎么看结果 —— 原始输出？还是带元数据的输出？
├─ 怎么管上下文 —— 全量保留？摘要压缩？保留最近几轮？
└─ 怎么走流程 —— 自由执行？先规划？还是规划+定期验证？
同一句话"把这个文件里的 bug 修掉"，在不同 harness 下需要模型做出的动作序列完全不同。工具叫 execute_bash 还是叫 run_cmd，返回的是裸输出还是带 pod 名和退出码的 XML，历史压缩到 3 轮还是 5 轮——每一个差异都会改变最优策略。
于是出现了特化税：单 harness 训练把能力全押在一套界面上，绝对分可能很高，但泛化能力被悄悄抵押掉了。
论文里有一组数据把这件事量化得非常干净（30B-A3B，GRPO，ClawGym-Bench）：
| 方法 | 在训练用的 Base Harness | 未见过的 In-Space 配置 | Claude Code |
|---|---|---|---|
| 单 harness 训练 | 59.82 | 48.12 | 46.02 |
| Harness Scaling | 59.63 | 58.60 | 49.62 |
| 差值 | −0.19 | +10.48 | +3.60 |
请注意第一列：在自己训练用的那套 harness 上，两者几乎打平（59.82 对 59.63，差 0.19 分，在噪声范围内）。
这意味着 Harness Scaling 不是把模型的绝对能力做强了，它是把"离了特定界面就废"这个依赖拆掉了。这个区别很重要——它说明你不需要在"专精"和"泛化"之间二选一，跨 harness 训练几乎不收专精的税。
三、核心视角：第三个缩放维度
论文对现有 Agentic RL 的 scaling 维度做了一个很清晰的切分：
| 维度 | 在扩什么 | 典型做法 |
|---|---|---|
| What to solve | 任务 | 扩任务集、加难度分层 |
| Where to operate | 环境 | 扩环境、扩工具生态、扩沙箱 |
| How to interact & execute | 执行方式（这篇的重点） | 扩 harness 配置 |
前两个维度大家已经很熟了，第三个长期是空白。原因也很实在：任务和环境至少还能枚举、能标注，harness 是个"整体风格"，很难描述成可操作的变量。
Harness Scaling 的第一步就是把这件模糊的事变得可枚举、可组合。
四、把 harness 拆成 5 个因子：243 种配置
团队把 harness 分解为 5 个组件，每个组件给 3 个实现（Base / Variant I / Variant II），于是有 3⁵ = 243 种完整配置。
| 因子 | Base（0） | Variant I（1） | Variant II（2） |
|---|---|---|---|
| S 系统提示词 | 直接的系统指令，说明角色与执行规则 | 同样的要求嵌进模拟产品上下文，附平台与 UI 描述 | 用叙事和角色设定重新表述要求 |
| T 工具接口 | 原始工具名 + schema（execute_bash、file_editor），无干扰项 |
功能工具用语义相关别名，加入非功能性干扰工具 | 功能工具用不透明标识符，配干扰项，基本消除词汇线索 |
| O 观测结果 | 原始工具输出，无前后缀 | 附加模拟基础设施元数据（pod 名、命名空间、调度信息） | 附加结构化 XML 式元数据（工具名、退出码、PID、耗时、执行节点） |
| C 上下文管理 | 完整交互历史全保留 | LLM 摘要压缩，最近 5 轮留在上下文 | 更激进：最近 3 轮，摘要外化到辅助文件 |
| W 工作流 | 标准自由形式执行 | 计划优先：执行前要求显式规划 | 规划 + 每 3 步一次进度验证 |
三个细节值得注意：
1）变体是模型生成的，但只改目标组件。
变体由 Opus-4.7 驱动生成，生成时约束"只修改目标组件，任务语义、环境、其他组件功能保持不变"。这道约束很关键——否则你没法确认分差是 harness 差异带来的，还是任务被改难了。
2）三个变体的难度刻意做了阶梯。
拿工具接口这维举例：Base 是"诚实命名"，Variant I 是"同名同义但加干扰项"，Variant II 是"名字完全不透明 + 干扰项"。这实际上是信息可得性的三级削弱，逼模型学会靠工具描述而不是靠名字猜功能。
3）243 不是随便定的。
3 个实现是"能定义出有意义差异"的最小数量（2 个只能测"有无"，4 个会让组合爆炸且变体质量下降）。5 个因子则对应 harness 的模块化边界。
五、设计一：为什么只选 18 个，而且必须"正交"
243 种配置，全跑一遍训练预算扛不住，而且没必要。但随便挑 18 个也不行。团队用的是强度 2 的正交设计。
目标：保住一阶和二阶结构
- 一阶（组件平衡）：每个组件的每个实现，出现次数一样；
- 二阶（成对平衡）：任意两个组件之间，每一对实现组合出现次数一样。
换句话说，你要保证模型见过"S 的三种写法 × T 的三种接口"的所有 9 种组合，而且见得一样多。这样它学到的是组件之间的关系，而不是某个特定组合的运气。
数量推导：18 是被数学逼出来的
设组件数 M=5，每个组件实现数 L=3，每对组合出现 λ 次：
N = λ · L² = 9λ
Rao 界：N ≥ 1 + M(L−1) = 1 + 5×2 = 11
N 必须是 9 的倍数，同时要 ≥ 11，那么最小可行规模就是 N = 18，对应 λ = 2。
这个 18 配置集的性质：
- 每个组件的每个实现出现 6 次；
- 任意两个组件的任一实现对，恰好出现 2 次；
- 大量高阶（完整）组合在训练中从未出现——这正好留下评估空间。
具体 18 个配置（S/T/O/C/W 五元组）：
S0T0O0C0W0 S0T1O1C1W1 S0T2O2C2W2
S1T0O0C1W1 S1T1O1C2W2 S1T2O2C0W0
S2T0O1C0W2 S2T1O2C1W0 S2T2O0C2W1
S0T0O2C2W1 S0T1O0C0W2 S0T2O1C1W0
S1T0O1C2W0 S1T1O2C0W1 S1T2O0C1W2
S2T0O2C1W2 S2T1O0C2W0 S2T2O1C0W1
只用了全空间的 约 7%，却保住了关键的组合结构。
这一步的收益有多大
同等预算下的消融（Qwen3-4B，In-Space / Claude Code）：
| 训练集 | ClawGym-Bench | PinchBench |
|---|---|---|
| 随机选 18 个 | 47.90 / 42.78 | 51.28 / 48.74 |
| 结构化 18 个（本方法） | 52.78 / 45.37 | 56.24 / 51.47 |
同样的数量、同样的预算，只因为选法不同，就差 4.9 分和 5.0 分。这是全篇最实用的一个结论。
六、设计二：局部性感知分配，让"对比"发生
光有正交的训练集还不够。同一批任务怎么和 harness 配对，决定了模型能不能学到东西。
汉明距离与"邻居"
把每个配置看成一个 5 维坐标，两配置之间的距离 = 有几个组件不同（汉明距离）。距离 1 = 只有一个组件不同，就是"邻居"。
S0T0O0C0W0 ←──距离1──→ S1T0O0C0W0 (只换了系统提示词)
│ │
距离1 距离1
│ │
S0T1O0C0W0 S1T1O0C0W0
在 H(5,3) 里，一个配置最多有 5×(3−1) = 10 个距离 1 的邻居。
分配规则
对每个任务 x：
1. 从训练集 H_tr 里均匀随机抽一个锚点 h_x
→ 保证全局覆盖（不同任务散落在整个空间）
2. 从 H_tr 剩余配置中，选 K−1 个汉明距离最小的
→ 保证任务内受控变化（同任务、相邻 harness）
3. 得到任务 x 的 harness 集合 H_x，在 K 个连续训练步里依次使用
K=2 就是"锚点 + 最近邻"两个配置。
为什么这样设计：同一个任务、只换一个组件，等于给模型提供了一组直接可比的对照实验——任务没变、目标没变，唯一变的是界面。这种对照经验会逼策略把能力沉淀在任务本身，而不是绑定在某个界面的具体形式上。
对比一下"随机分配"（任务和 harness 随机配对）：虽然覆盖也不差，但模型看不到"同任务换界面"的对照，只能各自独立地学。
消融数字（4B）：
| 分配方式 | ClawGym-Bench | PinchBench |
|---|---|---|
| 随机分配 | 50.46 / 43.17 | 53.20 / 50.23 |
| 局部性感知（本方法） | 52.78 / 45.37 | 56.24 / 51.47 |
差 2.32 / 2.20 分和 3.04 / 1.24 分。
七、结果：白盒泛化、黑盒迁移、模型规模三重验证
实验设置（供复现参考）：主干 Qwen3-4B-Instruct 与 Qwen3-30B-A3B-Instruct，RL 用 GRPO 和 PPO，框架为 veRL + 异步 vLLM rollout，H20 卡（4B 用 16 卡、30B-A3B 用 32 卡），训练数据 ClawGym-Task 共 13.5K 任务，训练 300 步。评估基准三个：ClawGym-Bench、JobBench-Easy、PinchBench，指标 Pass@1，三次独立评估取平均，rubric 判定用 GPT-5.4。
白盒泛化（In-Space：18 个从未完整出现过的留出配置）
| 模型 | 算法 | 单 harness | Harness Scaling | 增益 |
|---|---|---|---|---|
| Qwen3-4B | GRPO | 29.81 | 39.04 | +9.23 |
| Qwen3-4B | PPO | 33.91 | 36.93 | +3.02 |
| Qwen3-30B-A3B | GRPO | 37.29 | 42.78 | +5.49 |
| Qwen3-30B-A3B | PPO | 36.31 | 41.89 | +5.58 |
三基准平均的 In-Space 增益：4B 上 GRPO +9.80、PPO +3.57；30B-A3B 上 GRPO +5.21、PPO +4.90。
训练曲线显示这个优势贯穿训练全程，且随训练推进持续扩大——不是某个 checkpoint 的偶然波动。
黑盒迁移（训练中从未接触的 Claude Code）
| 模型 | 黑盒 SFT | 黑盒 RL | Harness Scaling |
|---|---|---|---|
| Qwen3-4B | 35.08 | 33.38 | 37.22 |
| Qwen3-30B-A3B | 38.08 | 36.28 | 41.20 |
这里有个很反直觉的结论：在两个黑盒框架上都做过 SFT 和 RL，还不如在白盒空间里做结构化训练迁移得好。
原因不难理解——直接在黑盒上训练，你只能看到"一个点"，学不到这个点周围的结构；在白盒空间里训练，你学到的是"界面变化的规律"，换到没见过的黑盒时，这个规律还能用。
额外的 OpenClaw 验证也一致：4B 36.07、30B-A3B 41.20，都高于单 harness 基线。
八、三个反直觉发现（这部分最值得抄）
发现 1：全 243 个都训，反而不如 18 个
固定预算下，把 243 种配置全用上，仍然不如结构化的 18 种。
论文的解释：穷举覆盖会带来大量冗余，单位预算的有效多样性反而下降。而且维度一多，组合爆炸先吃掉的是算力，不是收益。
结论："多样性"本身不值钱，"多样性的组织方式"才值钱。
发现 2：K=4 反而不如 K=2
每个任务配几个 harness？直觉是越多越好。实际结果（4B，GRPO，In-Space / Claude Code）：
| 设置 | ClawGym-Bench | PinchBench |
|---|---|---|
| 单 harness | 37.33 / 38.96 | 45.60 / 40.95 |
| K=1（只有锚点） | 48.21 / 43.17 | 54.23 / 49.26 |
| Repeat-2（同锚点跑两遍） | 49.76 / 43.60 | 50.34 / 48.64 |
| K=2（锚点+最近邻） | 52.78 / 45.37 | 56.24 / 51.47 |
| K=4 | 49.56 / 41.99 | 53.90 / 50.04 |
两个信息点：
- K=2 > Repeat-2（+3.02/+1.77 和 +5.90/+2.83）：同样的预算，换一个邻近 harness 比同一 harness 重跑两遍有用得多。这说明收益来自"受控变化"，不是来自"多条轨迹"。
- K=2 > K=4：再往上加，单个任务拿到的样本被稀释，反而变差。
发现 3：换个"更好的" harness 也没用
有人会想：那我挑一个设计得最好的 harness 训不就行了？论文测了四个单独配置（4B，GRPO，三基准平均）：
| 训练配置 | In-Space | Claude Code |
|---|---|---|
| h_base = (0,0,0,0,0) | 31.06 | 28.57 |
| h₁ = (1,1,1,2,2) | 35.79 | 36.11 |
| h₂ = (2,1,2,1,0) | 33.52 | 33.11 |
| h₃ = (2,2,1,0,1) | 35.15 | 32.72 |
| Harness Scaling（18 配置） | 40.86 | 37.22 |
最好的单个配置能到 35.79，但跨 harness 训练能到 40.86。“选一个最优界面"这条路的天花板，明显低于"跨多个界面”。
九、能力到底提升在哪：六维行为分析
论文用 GPT-5.4 按 6 个维度打分（5 分制归一化），每个配置取 200 条完整轨迹：
| 能力维度 | 提升幅度 |
|---|---|
| state tracking（状态跟踪） | 增益最大 |
| workflow compliance（流程遵循） | 增益最大 |
| error recovery（错误恢复） | 增益最大 |
| instruction following（指令遵循） | 有提升 |
| interface handling（接口处理） | 有提升 |
| observation reading（观测解读） | 相对较小 |
这个分布很能说明问题。提升最大的三项，恰好都是**"跨界面稳定"的能力**：
- 状态跟踪——不管历史怎么压缩，脑子里的进度不能丢；
- 流程遵循——不管提示词怎么换说法，该走的步骤不能少；
- 错误恢复——不管报错长什么样，得知道下一步干什么。
而 observation reading 提升最小，因为它本来就是最依赖具体格式的能力——换个输出格式，读法就得重学，跨 harness 训练帮不上太多。
这条结论对做 Agent 产品的人也有用：如果你要做一个能适配多个客户端/多个模型的 Agent，优先投在状态管理和错误恢复上，而不是在解析各种输出格式上死磕。
十、可复现路径与五条可抄建议
复现所需的关键配置
| 项目 | 设置 |
|---|---|
| RL 框架 | veRL + 异步 vLLM rollout |
| 硬件 | H20，4B 用 16 卡 / 30B-A3B 用 32 卡 |
| 训练数据 | ClawGym-Task，13.5K 任务 |
| GRPO batch | 每步 16 任务 × 每任务 8 rollouts |
| PPO batch | 128 任务 × 每任务 1 rollout |
| 训练步数 | 300 |
| 学习率 | actor 1e-6；PPO critic 1e-5 |
| 裁剪 | 非对称 0.20 / 0.28 |
| 正则 | 无 KL、无熵正则 |
| 最大长度 | 4B：prompt 8K / response 32K；30B：prompt 4K / response 60K |
| PPO 细节 | GAE γ=λ=1.0；critic 对观测 token 做 mask；value head 零初始化；value clipping 4B=0.5 / 30B=1.0 |
五条可以直接抄的建议
1）先给你的 harness 建一个因子表，哪怕只有 3 个维度。
不用一上来就凑 5×3。先把你系统里"会变的部分"列出来——提示词风格、工具命名方式、输出格式、历史保留策略、是否强制规划。每一项给出 2-3 个实现，你就有了一个可训练的配置空间。
2）选配置用正交，不要随机。
如果凑不出严格的正交设计，退一步的做法是：保证每个组件的每个实现出现次数相同，且任意两组件的主要组合都至少出现过一次。实测这一条比"多跑几个配置"收益大得多。
3）每个任务配 2 个邻近配置，别配 4 个。
锚点 + 一个只差单个组件的邻居。预算花在"换一个组件"上，而不是"同一配置多跑几遍"。
4）训完必须做三类测：训练配置内、留出配置、外部黑盒。
只测第一类会严重高估——论文里单 harness 训练在自己那套配置上能到 59.82，看起来比跨 harness 的 59.63 还好。泛化能力只有后两类测试能测出来。
5）评估别只看一次通过。
这条虽不是论文重点，但和 Agent 类任务的方差特性高度相关：Agent 任务的单次结果波动极大，Pass@1 建议至少三次独立评估取平均（论文就是这么做的）。
十一、边界与没解决的问题
诚实地说清楚这篇论文不覆盖什么：
1）外部黑盒只测了两个。
out-of-space 主要是 Claude Code v2.1.205，加 OpenClaw 作为补充。两个样本能说明趋势，但不足以断言"任意框架都能迁移"。
2）harness 空间是靠模型生成的。
243 种配置的变体由 Opus-4.7 生成。这意味着空间的代表性和多样性受生成模型影响——换一个模型生成变体，结论可能变化。
3）"全 243 不如 18"只能当固定预算下的结论。
全量设置里包含了部分评估配置，严格说它不是干净的 held-out 泛化实验，更像是"预算压力测试"。如果你的算力不受限，这个结论未必成立。
4）没有解决"harness 与任务不匹配"的问题。
它保证的是"模型会适应不同界面"，不是"界面本身设计得好"。如果某个 harness 的工具集根本不足以完成任务，跨 harness 训练也救不了。
5）方法有前置成本。
建空间、生成变体、跑 18 配置 × K 个邻居，总 rollout 量比单 harness 训练高不少。小团队要先算这笔账。
十二、更大的意义：Agent 训练开始"往中间层投资"
这篇论文的价值，可能不在那 9 分。
过去一年 Agent 的竞争焦点一直在两头：底层模型能力（谁的模型强）和上层产品形态（谁的 Agent 好用）。中间那层——harness，也就是模型和世界之间的接口——长期被当成"工程实现细节"，各家自己写一套，写完就固定不动。
Harness Scaling 说的是：这一层也是可以训练、可以优化的对象，而且它的多样性本身就是一种能力来源。
往下推一步，会得到几个比较现实的判断：
- 模型供应商：如果你的模型要在别人的框架里跑（Claude Code、Cursor、各种 CLI Agent），那"跨 harness 泛化"就是产品指标，不是学术指标；
- Agent 产品团队：你的 harness 设计会持续变化（加工具、改提示词、调上下文策略）。如果每次改都导致模型表现下降，说明你缺的不是模型，是跨 harness 训练；
- 做垂直 Agent 的团队：你最终要交付到客户的私有环境里，那里的界面你控制不了。"在陌生界面下还能干活"这件事，值得单独投一轮训练。
最后留一句论文自己的定位，值得记住：
它把 Agentic RL 的缩放范围，从"Agent 解决什么问题、在何种环境中运行"，扩展到"Agent 如何交互与执行"。
前两个维度已经卷得很厉害了。第三个维度，才刚刚开始。
- 点赞
- 收藏
- 关注作者
评论（0）