44.3% → 53.6%。一个 9B 模型，冻结权重不动，只改它外面的运行时逻辑，成功率涨了 9.3 个百分点。这个数字超过了让 GPT-5.5 当编辑器去改，超过了 GLM-5.2，超过了 DeepSeek-V4-Pro。
这不是模型进步，是 Harness 进步。
上海交大、小红书、东南大学的 Harness-R1 论文，第一次把"改 Harness"这件事从请专家看一眼变成了一种可以被训练的能力。问题随之而来：一个 9B 模型学到手的是一套可以迁移的手艺，还是几段恰好好用的代码？
这个问题的答案，决定了 AI Agent 的进化路径是走模型层还是走 harness 层。
一、为什么以前不行
在 Harness-R1 之前，改 harness 有两条主流路线，都有硬伤。
固定规则：一刀切不如不改
最直觉的方法是给所有 Agent 统一加上某种策略，比如 Self-Refine（让模型自己检查一遍自己的输出）。这种方法在 Harness-R1 的实验中验证了：在三个 benchmark（WebShop、ALFWorld、DBBench）上，固定加 Self-Refine 规则的 reward 全部为负。一次性的全局策略不仅没有改善，反而降低了原始性能。
原因不复杂。不同 Agent 的弱点不同：一个 Agent 可能在工具调用格式上频繁出错，另一个可能在错误恢复策略上过于激进。统一加自验证对一个 Agent 是修补，对另一个是噪声。Harness 没有 universal optimum。
强模型当编辑器：聪明但没有梯度
第二条路线是让一个更强的模型来当"编辑器"，读完 Agent 的失败轨迹后给出修改建议。GPT-5.5、GLM-5.2、DeepSeek-V4-Pro 都被试过。结果有涨有跌——WebShop 上甚至是反效果。
三个结构性缺陷导致了这条路走不通：
编辑器本身从没被训练过怎么改 harness。它擅长写代码和推理，但"读一组失败轨迹 → 定位 harness 层的问题 → 写出修复补丁"是一条独立的技能链，通用推理能力不等于 harness 工程能力。
编辑器写完补丁就走人了。没有把改完的 Agent 拿去重新跑一遍任务，验证修改是否真的有效。优化的是"这段修改看上去合不合理"，不是"改完之后到底管不管用"。
反馈信号只用来筛选和回滚，从没落到编辑器的参数上。第一轮改了不管用，第二轮编辑器还是同一个编辑器，没有从失败中学到任何东西。
真正的问题：反馈信号没有梯度
三条路线的失败指向同一个根因：反馈信号里没有梯度。
固定规则的反馈是"安上去试试好不好"——好就留着，不好就撤，规则本身不变。强模型编辑器的反馈是"这个建议行不行"——行就采纳，不行就换一条，编辑器本身不变。两种情况下，反馈都没有形成对修改者自身能力的梯度提升。
类比一下：这像一个评审专家每次看完代码给意见，但从不根据意见的对错调整自己的判断标准。给了一百次意见之后，他还是同一个评审水平。判据不硬，迭代就成了在噪声上做梯度上升——每一步看着都在涨，几轮之后不知道涨到哪去了。
要让"改 harness"变成一种可以被训练的能力，需要满足三个条件：修改者本身被训练、修改效果可以被客观度量、反馈信号可以落到修改者的参数上。Harness-R1 的设计就是围绕这三个条件搭建的。
二、Harness-R1 怎么做到的
核心架构：分离训练 + 闭环验证
Harness-R1 的系统有三个角色：
目标 Agent（如 Qwen3.5-9B）：被测试和被改进的对象，权重全程冻结。它不知道自己的 harness 正在被改。
Harness 工程师：被训练的对象。初始是一个 9B 模型，通过强化学习逐步学会读写 harness 补丁。
四个生命周期 hook：挂在 Agent 运行周期中的四个时间点，每个 hook 是一段可执行的 Python 函数，工程师模型可以重写它的逻辑：
- pre-action：Agent 每次执行动作前触发。可修改的包括上下文组装方式（给 Agent 看什么历史）、工具调用格式约束（输出怎么被解析成动作）、以及动作前的前置校验逻辑。
- post-feedback：Agent 收到环境返回的执行结果后触发。可修改的是错误分类策略（区分可重试错误和致命错误）和恢复指令生成（告诉 Agent 下一步怎么补救）。
- pre-action + reflection：在 pre-action 基础上额外插入一轮反思步骤。可修改的是反思提示词的结构（引导 Agent 先诊断再行动）和反思结果的过滤规则。
- terminal：判断一轮交互是否应该终止。可修改的是停止条件（连续失败几次该停）和最终输出的质量检查逻辑。
训练循环使用 GRPO（Group Relative Policy Optimization，一种在线强化学习算法），流程是：
- 工程师读一批目标 Agent 的失败轨迹（每个环境 10 条）
- 写出一段 Python 补丁，修改某个 hook 的行为（通常几十行）
- 补丁装回冻结的目标 Agent，用原来的任务集重新跑一遍
- 前后成功率差值就是奖励——改好了正分，改坏了负分，装不上或空转直接 0 分
- 补丁先过 AST 沙箱（抽象语法树解析 + 安全执行环境），有语法错误或危险操作直接拒绝
三个设计决策以及它们背后的底层逻辑
补丁是可执行代码，不是自然语言建议。 自然语言建议的问题在于不可验证——"建议增加一步自检查"这句话，十个模型有十种实现方式，效果天差地别。代码是确定性的：AST 可以解析结构，沙箱可以执行验证，通过就是通过，不通过就是不通过。Harness-R1 的每一次修改都是一段精确的 Python 函数，装进 hook 就能跑。
奖励是前后差值，不是绝对分数。 绝对分数混入了任务难度噪声——难的任务不管 harness 怎么改都是低分。前后差值控制了这个变量：同一个 Agent 在同一个任务集上，改了 harness 之后的成功率减去改之前的成功率。这个差值纯净地反映了"这次修改的效果"。
编辑器是被训练的，不是被提示的。 这是三条中最重要的。旧方法的修改者——无论是固定规则的设计者还是强模型编辑器——都不随经验增长。Harness-R1 的编辑器用 GRPO 在线训练，每一次失败和成功都更新它的参数。第一轮可能写出粗糙的补丁，第一百轮已经能精确定位失败模式并控制修改幅度。反馈落到了参数上，形成了真正的梯度。
实验数据
冻结 Qwen3.5-9B 作为目标 Agent，Harness-R1 训练后的工程师将其成功率从 44.3% 提升到 53.6%（+9.3 个百分点）。
跨 Agent 泛化：在 20 个训练时没见过的目标 Agent 上测试，平均提升 +7.06 个百分点。每一个都是正的。21 个 Agent × 3 个 benchmark 的完整矩阵（共 63 格）：56 格改善、4 格持平、3 格小幅回退（回退幅度均不超过 2.0 个百分点）——这是全文最有说服力的单组数据。
与 GPT-5.5 编辑器对比：Harness-R1 平均改善 +8.9±1.5，GPT-5.5 在三个随机种子上的改善值横跨零点——有时帮忙，有时帮倒忙。
与模型提升交替进行：先把 Agent 通过 SFT（监督微调）从 53.6% 提升到 59.2%，再用 Harness-R1 改一轮 harness，进一步提升到 64.2%。两轮收益不互相吞噬——模型层和 harness 层的改善是正交的。
三、学到的是能力，不是几段好代码
这是全文最关键的判断。
如果 Harness-R1 的工程师模型只学到了几段恰好好用的代码，换个 Agent、换批任务就该失效。实验结果是：它换到 20 个从没见过的 Agent 上，每一个都改善了。每个环境只看 10 条失败轨迹，就能写出对该环境剩余几百个任务都成立的修改规则。
留在工程师模型参数里的不是某一段具体的补丁代码，而是一套手艺：读失败轨迹 → 定位 harness 层的问题 → 控制修改幅度。这套手艺的迁移性证明了训练信号已经从"记住某个特定修改"上升到了"理解什么样的修改有效"。
三个反直觉发现
改进者不必比被改进者强。 一个 9B 模型改赢了 70B 模型的 harness，也改赢了 GPT-5.5 当编辑器的效果。改 harness 的能力是练出来的，不是从模型规模里溢出来的。通用推理能力强不等于 harness 工程能力强——后者是一条独立的技能链，需要专门的训练才能建立。
Agent 和 Harness 可以交替上升。 先改 harness（+9.3pp），再 SFT 模型（→59.2%），再改 harness（→64.2%）。三轮提升逐级叠加，没有互相吃掉收益。这意味着模型层进步和 harness 层进步是两条独立的改善维度，可以沿着各自的方向交替推进。交替会收敛到哪，论文列为开放问题。
改动是可读的、可被拒绝的。 每次改进是几十行 Python 代码，不是权重更新。补丁过 AST 沙箱，装不上判 0 分，改差了给负奖励。模型写的代码从没绕过检查直接进入运行时。可进化和可控不矛盾——前提是改动通过代码而非权重，有确定性的安全边界。
四、新的 Harness 应该怎么设计
Harness-R1 证明了一件事：harness 是可以被训练去改的。但论文测的三个 benchmark 的 harness 是事后才被挂上 hook 的——先有 Agent，再有人写 harness，最后才有人想办法改 harness。
如果反过来呢？如果一开始就为可进化而设计 harness？
Harness-R1 的成功不是因为它发明了什么全新的架构组件，而是因为它恰好满足了四个条件。把四个条件提炼出来，就是 harness 架构面向"可进化"的设计原则。
原则一：模型和 Harness 必须可干净分离
这是整条路线的物理前提。Harness-R1 的训练假设是冻结模型权重，只改外层逻辑。如果 harness 代码和模型推理深度耦合，分离训练就不成立。
WebShop 的 harness 是一个正面案例。它包含三层：上下文组装（把历史交互整理成模型输入）、工具调用格式（规定模型输出怎么被解析成动作）、错误恢复策略（动作失败后怎么反馈给模型）。三层都独立于模型的内部推理过程。改 harness 不需要理解模型在"想"什么，只需要理解模型在"做"什么。
反面情况是 harness 逻辑和模型推理深度交织。比如一个 Agent 的推理质量依赖 prompt 中嵌入的特定 CoT 引导结构——这个结构既是 harness 配置又影响了模型推理行为。动它等于同时改了模型和 harness，改进效果无法归因。
设计含义是：harness 应该暴露声明式接口。接口说的是"这里需要上下文"、"这里需要工具调用"、"这里需要错误处理"，而不是"让模型这样思考"。声明式接口让修改者可以替换实现而不触碰模型推理边界。
这一点对应 Agent Harness Engineering 综述（CMU + Yale + Amazon 等，2026.05）提出的 ETCLOVG 七层分类中的 C 层（Context Management）和 L 层（Lifecycle Orchestration）。这两层天然处于模型推理之外，是分离训练可以触及的区域。
原则二：必须暴露生命周期 hook
Harness-R1 的训练在 Agent 运行周期的四个时间点挂了 hook。这些 hook 不是事后打补丁加上去的——如果 Agent 运行时没有预留修改点，训练过程中工程师模型写的补丁就没有地方插入。
HarnessX（小米 AI 团队，2026）把这个思路系统化了。它定义了 9 个独立维度——模型选择、上下文组装、记忆管理、工具生态、执行环境、评估奖励、控制安全、可观测性、训练桥接——每个维度有 Typed Processor（类型化处理器），挂在 Agent 运行周期的 8 个时间点上。每个处理器可以独立替换、独立优化。
hook 的粒度是关键设计决策。太少（比如只有一个系统提示词可以改），优化空间窄，训练信号不够丰富。太细（比如每一步推理都有 hook），运行时开销和训练复杂度同时爆炸。Harness-R1 的 4 个 hook 是目前在论文中验证过的最小可用集——足够让工程师模型学到可迁移的修改能力，又不至于让训练 pipeline 失控。
Claude Code 的生产架构也走这条路。根据 Anthropic 工程团队的拆解，Claude Code 的 harness 中 98.4% 是 Operational Harness——权限系统、五层上下文压缩流水线、工具路由、安全护栏、生命周期钩子——只有 1.6% 是模型直接推理。hook 不是附加品，是 Agent 的主体。模型反而只是其中一个组件。
原则三：反馈信号必须可归因
Harness-R1 训练成功的直接原因，是它的奖励信号能纯净地归因到 harness 改动的效果。同一个 Agent，同一批任务，改前跑一遍，改后跑一遍，成功率差值就是修改的净效果。任务难度这个噪声变量被控制住了。
旧方法做不到这一点。绝对分数混着任务难度——难的任务不管怎么改 harness 都是低分，容易的任务不改也高。用绝对分数当奖励，编辑器学到的是"哪些任务容易"而不是"哪些修改有效"。
把可归因反馈作为设计原则，意味着 harness 应该内置 A/B 对照能力。同一个 Agent 跑两遍——一遍用旧 harness，一遍用新 harness——同样的任务集，同样的随机种子。差值就是结论。这不是奢侈品，是 harness 可进化的基础设施。缺了它，所有修改都是在没有刻度尺的情况下盲调。归因依赖的前提是改动可被精确度量（见原则四）——如果改动不是代码而是模糊的自然语言建议，前后差值就失去了对照基准。
对应到 ETCLOVG 七层分类，这是 V 层（Verification）和 O 层（Observability）的职责。验证层不只检查"Agent 做对了没有"，还要检查"harness 改了之后有没有变好"。可观测性层记录每次修改的 diff、运行轨迹、前后指标，让对比可审计。
原则四：改动必须是可执行、可检查、可拒绝的代码
Harness-R1 的每一次修改都是一段 Python 函数。这意味着可以被 AST 解析检查语法、被沙箱执行验证安全性、在装不上或改坏了的时候被直接拒绝。每一步改动都有一个确定性的 gate：通过就装，不通过就退回。
Code as Agent Harness 综述（UIUC + Meta + Stanford，2026）把这一点上升为理论。代码在 harness 中有三个自然语言建议不具备的属性：可执行（意图变成真实操作而不是待解读的描述）、可检查（可以审计验证，通过测试确认行为）、有状态（可以保存任务进度和运行上下文）。自然语言建议一个都不满足。
设计含义是 harness 的配置层应该是代码。不是 YAML，不是 JSON，不是 prompt 字符串。代码可以被版本管理追踪每一次变更，可以被单元测试覆盖，可以被沙箱安全执行。配置文件和 prompt 字符串改了之后你不知道到底改了什么——它们是声明式的，行为依赖于解释器的实现。代码改了之后你知道确切改了什么——它是命令式的，行为由自身定义。
安全边界也依赖于此。Harness-R1 的 AST 沙箱加上负奖励机制证明了一件事：Agent（工程师模型）写的代码从没绕过检查直接进入运行时。每次修改都经过结构检查、沙箱执行、效果验证三道 gate。可进化和可控不矛盾，前提是改动通过代码而非权重——因为代码可以被检查，权重不能。
四条原则的统一逻辑
分离让改动可以被独立评估——如果模型和 harness 耦在一起，改了之后不知道归谁的功。Hook 给改动提供挂载点——如果没有预定义的插入位置，补丁无处可去。归因给改动提供梯度——如果反馈信号混着噪声，训练就失去了方向。代码化给改动提供安全边界——如果不是代码，就无法被检查和拒绝。
四条缺一条，harness 自进化就卡住。不分离就分不清改了谁，没 hook 就没地方改，不可归因就没有学习信号，不是代码就无法安全控制。
这四条原则也框定了 harness 层的设计空间。ETCLOVG 七层分类中的 C（上下文管理）、L（生命周期编排）、V（验证）、O（可观测性）四层，恰好对应这四条原则的落地点。E（执行环境）、T（工具接口）、G（治理）三层是支撑性基础设施——没有它们 Agent 无法运行，但它们不直接参与"可进化"这一命题。一个面向可进化设计的 harness，重心应该在 C/L/V/O 四层上，而不是均匀分布在七层。
五、这条路的边界在哪
Harness-R1 的方法不是万能的。边界清楚才值得认真对待。
Harness 和模型深度耦合的场景
论文测的三个 benchmark 的 harness 相对独立，三层都可以干净地从模型推理中剥离。但如果 harness 逻辑和模型推理深度交织——例如推理质量高度依赖 CoT 的特定引导结构——分离训练的假设就不成立（详见 §4 原则一的反面讨论）。这条边界是整个方法论的物理前提：不满足分离条件的场景自然不适用。
训练数据极度稀疏的场景
Harness-R1 每个环境只需要 10 条失败轨迹。这在三个 benchmark 上够用，因为失败模式相对集中——WebShop 上的失败主要是搜索策略不当，ALFWorld 上的失败主要是动作序列规划偏差。
如果失败模式高度异质——100 个任务有 100 种不同的失败原因——10 条轨迹不足以覆盖。工程师模型读 10 条失败，写出的规则可能只对这 10 种情况有效，对剩余 90 种无效甚至有害。异质性越高，需要的失败轨迹越多，训练成本也随之上升。
架构级重构
当前补丁修改的是运行时行为：加一步自验证、改工具调用的输出格式、调整错误恢复策略。这些是在现有架构内的局部修改。
补丁不涉及架构级重构——从单 Agent 变多 Agent、从线性流水线变图结构、从无状态变有状态。这类重构的代码量和复杂度远超几十行 Python 函数，当前的补丁粒度和训练框架无法承载。
与 ADAS/Meta-Harness 的对比定位
三条路线目前是互补而非替代关系：
ADAS（Automated Design of Agentic Systems，UBC + Vector Institute，ICLR 2025）搜索整个 Agent 系统的设计空间，从零开始编程出新架构。粒度粗，覆盖广，但不保证每个修改都有正面效果。
Harness-R1 精确训练 harness 编辑能力，只在已有的 hook 框架内修改。粒度细，效果可控，但范围窄。
Meta-Harness（Lee et al., 2026）介于两者之间：不训练独立的编辑器，而是通过自动化搜索修改系统提示词、中间件上下文注入和自验证钩子。Trivedy（2026）仅这三项改动，就把 GPT-5.2-Codex 在 Terminal-Bench 上的成绩从 52.8% 提升到 66.5%。Bölük（2026a）仅修改编辑工具格式和外围 tool harness，跨 15 个模型实现最高 10 倍提升。
三者的关系是：ADAS 搭架构，Meta-Harness 调配置，Harness-R1 训能力。当一个 Agent 系统从零开始建时走 ADAS，架构稳定后用 Meta-Harness 快速调优，需要可迁移的深度修改能力时用 Harness-R1。
六、如果 Harness 可以自己进化，下一步是什么
Harness-R1 还是需要离线训练一个独立的工程师模型。训练完了，工程师模型的参数就冻结了，不再随着线上任务变化。
下一步是把训练搬到线上。
Agent 跑任务 → 遇到失败 → 自己分析失败模式 → 自己写 harness 补丁 → 重跑验证 → 有效就留下，无效就回滚。整个过程不需要离线训练轮，不需要独立的工程师模型，harness 的修改能力随着 Agent 的运行经验持续增长。
这就是 SkillHone（腾讯 WeChat AI，2026.06）和 EvolveR（ICML 2026）探索的方向。SkillHone 维护一份持久化的决策历史——每次 skill 修订都记录诊断、修订方案、评估证据和最终结果，形成可追溯的进化轨迹。候选修订在练习探针上试跑，报告经过脱敏处理，基于先前决策提出新修订。不需要预集成搜索栈，在 GAIA 基准上超过商业深度研究 Agent 15.8 分。EvolveR 的贡献则在于提出了从成功轨迹中自动蒸馏可复用经验的框架——不再需要显式的失败-修复循环，而是让 Agent 从自己的成功行为中提取通用化的策略模板，在后续任务中直接复用。
在线自进化相比离线训练的优势是反馈延迟更短——修改立刻可以验证，不需要等一轮完整的训练周期。劣势是探索空间受限——线上运行只能基于当前遇到的任务做修改，不像离线训练可以系统性地覆盖各种失败模式。
一个可证伪预判
12 个月内会出现"在线 harness 自进化"的完整方案：Agent 在执行任务的同时实时修改自己的 harness，不需要离线训练轮。验证标志是在 SWE-bench 或 Terminal-Bench 上，自进化 harness 的 Agent 成绩超过固定 harness 加手工调优的上限。
如果这个预判成立，意味着 Agent 的进化重心从模型层进一步转移到 harness 层。模型提供基础推理能力，harness 提供可累积的工程经验。模型迭代以月为单位（一次训练几个月），harness 进化以天为单位（线上持续学习）。两者的时间尺度差异，会让 harness 层成为 AI Agent 差异化的主战场。
回到开头那个问题：9B 模型学到的是手艺还是代码？答案是手艺。但更重要的问题是：接下来谁的手艺增长得更快——模型的参数，还是 harness 的代码？如果 Harness-R1 和 SkillHone 指出的方向成立，答案已经在写了。
声明： 本文基于 Harness-R1 论文（上海交大/小红书/东南大学，2026.08）、Agent Harness Engineering: A Survey（CMU/Yale/Amazon 等，2026.05）、Code as Agent Harness（UIUC/Meta/Stanford，2026）、ADAS（UBC/Vector Institute，ICLR 2025）、HarnessX（小米 AI，2026）、SkillHone（腾讯 WeChat AI，2026.06）及 Anthropic/OpenAI 工程实践公开资料撰写。不构成投资建议。文中实验数据截至 2026 年 8 月。