Harness² 深度解读及其与 RSI 的关系

Harness² 让智能体在执行任务时修改自己的工作框架，并把修改过程中的经验留给后续任务。模型权重保持不变，变化发生在提示词、技能、脚本、工具指导和调度等外围系统。它属于系统层面的递归自我改进（Recursive Self-Improvement，RSI），重点研究没有标准答案反馈时，怎样让这种改进持续发生。(Xu et al., 2026)

原论文由 Ruiyao Xu 等人提出，作者来自 Northwestern University 与 Google Cloud AI Research。本文依据 2026 年 10 月 9 日提交的 arXiv v1、官方项目主页及公开代码解读；论文当前为预印本。源码说明限定于上方所列提交版本。

从一个没有交付好的任务开始

论文图 9 的 JobBench 案例要求智能体核对排期、人员和预算文件，再生成相互一致的成果。基础智能体获得 43.1 分。执行记录暴露出两个具体问题，多个文件中的数字没有核对，写出的成果也没有重新打开检查。

Harness² 针对这些行为修改框架。一组修改要求先清点输入文件、将数字追溯到来源，再用脚本重新打开成果；另一组加入排期、场地、人力与预算核对技能，以及处理字符串金额的工具指导。合成后的框架重新执行任务，作者事后评分为 77.8。

这里增加的是可执行的工作方法。它把一次任务中的失误转成下一次运行可以调用的技能和检查程序。但 43.1 与 77.8 是实验评估时获得的分数，改进过程看不到这些评分。它必须从轨迹和成果本身判断修改是否有帮助。这正是方法需要解决的困难。（原文 §4、图 9，第 11–12 页）

Harness 到底包括什么

可以将 agent 理解为模型与执行框架的组合。

A (q; M, H)

$q$ 是任务， $M$ 是模型， $H$ 是 harness。模型负责生成判断和行动，harness 决定模型看到什么、能够调用什么，以及行动怎样被组织和约束。更换 harness 可以改变系统能力，而不需要重新训练模型。

论文开放八类文件级组件。一次修改对应这些文件的差异，随后可以实际运行。（原文 §2.1、图 2、附录 D.3）

组件	实际改变什么	何时生效
系统提示词	角色与总体工作程序	每次模型调用
Guardrails	写入上下文的约束和完成要求	每次模型调用
Memory	当前框架携带的领域事实与记忆	每次模型调用
工具指导	已有工具应在何时、怎样使用	每次模型调用
子代理	将工作委派给拥有独立上下文的执行者	被调用时
Skills	某类任务的专门工作程序	触发并加载时
Scripts	抽取、转换、计算和检查等确定性操作	通过工具执行时
Plugins	工具调用或回合边界上的中间件行为	运行时钩子触发时

Guardrails 在这里首先是提供给模型阅读的规则，不能直接等同于权限隔离。Plugins 可以在工具循环中执行操作，但一个提示性质的钩子也不自动成为安全边界。论文图 19 的插件会在长时间没有成果时追加提醒，它仍然只是提醒。

文件形态还影响成本。把一套专门流程放进常驻提示词，每次调用都要携带；放进按需加载的技能，只在相关任务中进入上下文。因此，改进不只是“加一句提示”，还包括选择规则应当放在哪个组件中。

两层递归分别改进什么

任务级递归改进当前任务的执行框架 $H$ 。框架改进级递归则更新指导后续修改的状态 $R_{t}$ ，论文称之为 improvement harness。

一个任务完成后，更新可写成原文的式（4）。

R_{t + 1} = Update (R_{t}, H_{t}^{⋆}, D_{t})

$t$ 表示任务序号， $H_{t}^{⋆}$ 是本次采用的框架， $D_{t}$ 是改进过程的完整记录，包括基础执行、候选修改、试跑、合成决定与最终选择。星号表示“被采用”，并不表示已证明最优。

具体实现是一套按领域组织的改进库，保存框架文件、EXPERIENCE.md 和检索索引。经验需要说明适用情境、应修改的组件以及执行证据；依据不足时可以不新增条目。未来的编辑过程按需读取并改写这些组件。

每个新任务仍从共同的基础框架 $H_{0}$ 开始。上一个任务的框架不会整套自动继承。过去发现的字段映射、金额或领域结论，需要针对当前材料重新核实。这样可以减少把旧任务的事实误当成新任务规则的风险。（原文 §2.3、附录 D.2 与 H）

两层更新有不同时间尺度。在同一个任务中， $R_{t}$ 固定；完成任务后才更新库。模型权重、阶段提示词、改进算法与选择规则仍然固定。因此，本方法的第二层“学会改进”主要通过可检索的经验和组件实现，尚未开放整个改进程序的自我重写。

Propose–Probe–Compose 怎样工作

提出两种不同范围的修改

先用当前框架执行任务，取得参考轨迹和成果。编辑器随后产生两类候选。

通用候选（invariant）处理规划、工具调用、上下文和交付程序。例如，输出文件写入成功以后，仍要打开检查内容。领域候选（domain-specific）处理专业流程与约束，例如排期与预算的核对关系。

两种编辑职责分开，有助于区分“模型不会正确操作工具”和“模型缺少该领域的工作程序”。这是一种候选组织方式，不保证两种候选的错误彼此独立。

在同一个任务上试跑

每个候选都用相同的模型和匹配的环境配置执行当前任务。编辑器可以检查原先遗漏的文件是否被读取、数据核对是否发生、输出是否重新打开，以及是否引入新的失败。

这些对照提供行为证据。它们不能给答案盖上“正确”的结论。例如，同一个错误假设可能进入两个候选，也可能进入模型自己写的检查脚本。随机执行差异也会混入修改效果。Probe 因而是一种诊断过程，强度弱于独立的正确性验证。（原文 §2.2.1）

根据证据合成后继框架

Composer 读取候选文件差异、执行轨迹和成果，可以合并有依据的修改、解决冲突、采用单个候选，或保持当前框架。合成以后还要执行一次，形成新的轨迹与交付物。

这一步与直接挑选一个漂亮答案不同。被合成的是能够重新运行的框架；此次没有采用的候选，也可能提供值得保存的失败或改进证据。附录 H 的反思提示词还要求区分有帮助、有损害、未观察到效果与归因混杂，防止把一次成功自动写成长期经验。

预算增加意味着多少额外工作

并行递归扩大搜索宽度，顺序递归增加修改深度。

模式	预算 $k$ 对应的工作	后续修改依据
并行	$k$ 个参考执行、 $k$ 个通用候选、 $k$ 个领域候选、 $k$ 次独立合成	每个 Composer 读取共享候选池与执行证据
顺序	$k$ 个参考执行和 $k$ 轮 Propose–Probe–Compose	上一轮框架，以及累积的候选、检查点和轨迹

公开代码的正常调度为每个任务安排 $4 k$ 次执行 rollout 和 $3 k$ 个改进阶段，另有需要时的选择与任务后的反思。Rollout 指智能体将任务实际跑一遍，不是一次模型调用。 $k = 1$ 已经包含一次参考执行、两次候选试跑和一次合成后执行； $k = 5$ 对应 20 次执行调度，不能理解成“只多想了五次”。重试、失败和缓存还会影响实际开销。递归调度源码

并行版本在论文中只有一次群体更新， $k$ 增加的是宽度，并非循环进化 $k$ 代。顺序版本才是沿上一轮框架继续修改。 $k > 1$ 时，最终选择器从匿名交付物中选出已有结果，不再生成新答案。

源码还有一处值得注意的边界，终选候选池只包含并行合成结果或顺序检查点，不直接包含原始参考执行。编辑器可以通过 KEEP_BASE 保留框架，但终选阶段没有“总能退回原始交付物”的保证。这与附录选择提示词中允许选择基础结果的通用表述需要区别理解。候选池实现

它与 RSI 是包含关系

RSI 描述的是系统参与自身改进，并让留下的变化影响后续改进过程。被修改的对象可以是权重，也可以是代码、工具、记忆或改进程序。Harness² 选择了冻结模型、修改外围系统的路线。

不同研究对“完整 RSI”的用词并不完全一致。STOP 的作者因为语言模型本身没有被修改，谨慎地称其并非 full recursive self-improvement；Harness² 使用更广义的系统级定义。比较时应明确修改对象、反馈来源与持续状态，而不能仅凭名称判断递归程度。(Zelikman et al., 2024)

方法	持久改变的对象	改进依据	改进机制怎样变化
STOP	能修改代码的 improver 程序	给定效用函数	用 improver 修改 improver 自身；语言模型不变
Darwin Gödel Machine	agent 自身代码及变体档案	编程基准的经验评估	更好的代码能力可以支持后续自修改与变体探索
Hyperagents	同一可编辑程序中的任务 agent 和 meta agent	任务域的评估反馈	meta agent 的修改程序本身也可被编辑
Harness²	当前任务框架、跨任务改进库	不含标准答案的执行对照与模型判断	库更新后指导未来编辑；阶段算法与模型参数固定

STOP、DGM 和 Hyperagents 的定位分别依据其原论文记录；表格只比较机制，没有在统一预算下重跑这些系统。(Zelikman et al., 2024; Zhang et al., 2025, 2026)

Harness² 的问题因而很具体。当新任务没有可调用的标准答案评分器时，怎样在执行中修改框架，并让探索出来的经验有助于下一个任务？相较于可直接获得基准分数的自修改路线，它减少了对外部正确性反馈的依赖，也把更多判断压力交给轨迹分析和模型裁决。它没有证明模型自身获得了持续学习能力，也没有证明改进速度会自我加速。

单纯反复润色同一个答案，改变的是这次输出。只把任务结论写进记忆，改变的是以后可读取的信息。Harness² 进一步保存可执行组件，以及“怎样修改这些组件”的经验。这使改进过程能够积累，但这种积累能否可靠迁移，仍需要实验检验。

实验支持了哪些判断

四种配置都优于自己的基础框架

主要实验使用两个冻结执行模型 GLM-5、Gemini 3.5 Flash，分别配合 OpenCode 与 Codex，构成四种配置。默认编辑器是 Claude Opus 4.8，不能把默认结果理解成较弱模型完全依靠自身完成了改进。论文另外给出了执行器和编辑器使用同一模型的实验。（原文 §3.1、图 8）

以下固定为 Gemini 3.5 Flash 与 OpenCode，列出原表均值；最后一列是从 $k = 1$ 增加到并行 $k = 5$ 的额外变化。

评测与指标	基础框架	Harness²， $k = 1$	增加到 $k = 5$
WorkBuddy-Bench 三领域宏平均	72.4	77.5	再加 3.3 分
JobBench 加权任务得分	31.5	36.0	再加 3.0 分
LAB，Partial 判据通过率	79.9%	81.9%	再加 2.6 个百分点

WorkBuddy 实际测试 Code、Web、Office 各 40、35、25 个任务，三个领域等权计算宏平均；JobBench 使用固定划分中的 34 个测试任务；LAB 使用 100 个保留测试任务，而非整个法律数据集。主要结果为三次打乱任务顺序的运行均值，原表还提供标准差。三种指标不能直接混合平均。（原文表 1、表 2、附录 B）

摘要中的最高增益也有具体配置。例如，WorkBuddy 的 11.5 分来自 GLM-5 与 OpenCode 的宏平均由 64.2 升到 75.7；LAB 的 11.8 个百分点来自同一配置的 Partial 由 59.6% 升到 71.4%。Partial 是判据通过率，不是所有法律任务完整通过的比例，更不代表实际法律服务可靠率。

结果也没有显示它处处超过全部方法。Gemini 3.5 Flash 配 Codex 时，LAB 的单步结果为 75.6%，低于 Meta-Harness 的 76.5%。(Xu et al., 2026)

经验库、职责划分和合成都有作用

在 Gemini 3.5 Flash、OpenCode、 $k = 1$ 的消融中，完整方法的 WorkBuddy 与 JobBench 得分为 77.5 和 36.0。去掉经验库后降为 74.4 和 34.2；把两种职责编辑器换成两个通用编辑器后降为 74.6 和 32.3；跳过合成、直接挑候选后降为 75.9 和 34.1。（原文表 3）

这些对照支持三个机制在该设置下的作用。它们没有证明每个组件的贡献可以相加，也不能将单一设置的消融结果推广到所有任务。

有迁移证据，但需要分清实验协议

图 7 将 JobBench 的经验库用于 WorkBuddy 的单步改进，Code、Web、Office 分别再提高 0.6、0.5、2.9 分。这比只展示“库里保存了很多条经验”更能支持复用价值。

附录 E.2 的留一重跑则属于另一种分析。完整任务流结束后，移除当前任务自己的库条目，再重跑该任务，仍能读取后续任务产生的经验。WorkBuddy 与 JobBench 分别增加 1.9、1.7 分，但作者明确将其作为离线复用分析，不能用作严格在线、只看历史任务的增益证据。

无答案反馈仍然会出错

论文图 14 给出了比平均分更有诊断价值的失败案例。

在一个编程任务中，候选结果事后得分包括 95 和 55，盲选器最终选了 55。生成更好的候选与识别更好的候选是两个不同能力。候选之间一致也可能来自共同错误，另一个案例中，编辑器假定按对象身份缓存已经足够，自己生成的检查脚本连续报告通过，但隐藏测试要求等价内容也能命中缓存。

还有一类失败来自评估过程本身，某个网页任务的裁判多次没有返回有效结论，论文中的该案例将无法解析的裁决计为失败。因此，低分需要区分框架修改、选择错误、执行随机性与裁判故障；仅看一次总分无法完成归因。（附录 E.6、图 14）

成本也必须完整计算。表中的 #Steps 是执行器会话的模型回合数，不能代替所有参考执行、试跑、编辑、合成和选择的总费用。论文图 6 另外比较了交付前的总 token 消耗，其结论限于报告的配置和预算范围。并行可以降低有足够资源时的等待时间，额外计算仍然存在。

公开代码的评估隔离值得单独检查

论文要求改进过程看不到答案、评分细则或裁判分数。公开代码会过滤进入编辑工作区的相关文件和裁判结果，但这只是证据文件这一条通道的控制。上下文构造源码

仓库的实验指南进一步说明，公开版本默认不限制执行器联网，Codex 执行时关闭沙箱；JobBench 的评分细则公开可下载。维护者记录过一次验证运行，Codex 在没有被要求这样做时，自行下载了当前任务的 rubric。指南因此要求在获取依赖后设置网络级限制。官方网络访问说明

这条记录说明公开版本存在评分泄漏路径，不能据此断言原论文的全部实验已被污染。复现时需要保存网络限制、数据版本、任务划分与裁判配置，再判断是否真的实现了“改进过程没有访问标准答案反馈”。

论文表格还只评估特定保留集，不能直接用公开工具的全量默认运行替代。当前实验指南列出的全量 LAB 流有 1,143 个任务，与论文的 100 个测试任务不是同一个分母；JobBench 的数据在下载时解析，指南要求记录实际下载版本。源码、任务划分和评估条件都属于结果的一部分。

对智能体系统设计的启示

从这项研究可以提炼出一种有条件的工程路线。先定位一次具体的执行偏差，再修改与该偏差有关的组件，用同一任务的实际执行检查行为变化，最后只保存有依据、带适用条件的经验。

重复的机械操作适合进入脚本；特定任务的程序适合进入按需技能；短而通用的规则才适合常驻上下文。这个分工能够减少无差别增加提示词，同时让修改更容易追溯到实际运行。

对于不可安全重跑的真实任务，还需增加论文基准之外的控制。重复发送邮件、下单或改数据库可能造成多次外部影响，Probe 应在可恢复的副本或隔离环境中运行。独立正确性检查、权限边界和人工决策仍然有其作用，行为对照无法代替这些控制。

更值得继续检验的问题，是经验库增大或任务分布改变后，哪些经验应被修订、合并或淘汰，以及能否根据证据不足程度分配探索预算。论文将库管理与自适应递归列为未来方向，当前方法尚未证明长期持续改进不会退化。（附录 F–G）

原文与延伸阅读

本文重述机制、选取结果并加入比较与实现分析，没有独立重跑基准。主论文为 Xu 等人的 Harness²: Recursive Agent Harnessing for an Open World，arXiv 授权为 CC BY 4.0；本页为中文解读与分析，不是作者原文或官方背书。

主论文与完整附录：arXiv 2610.14224v1 · Trackback 记录。机制见 §2，主要结果见表 1–3，风险和未来工作见附录 E.6、F–G，六组改进提示词见附录 H。
官方项目主页与源码快照。源码采用 Apache 2.0；依赖与基准另按各自许可。
STOP 用于比较可编辑的改进程序与效用反馈：原论文 v3 · Trackback 记录。已发表于 COLM 2024。
Darwin Gödel Machine 用于比较代码自修改、变体档案与经验评估：原论文 v3 · Trackback 记录。
Hyperagents 用于比较可修改的 meta agent：原论文 v1 · Trackback 记录。

返回大语言模型。相关系统结构见Gander 的分层智能体架构。

Xu, R., Chen, Y., CuiZhu, Z., Dalvi Mishra, B., Ming, Y., Yu, H., Han, R., Lee, C.-Y., & Pfister, T. (2026). Harness²: Recursive Agent Harnessing for an Open World. arXiv Preprint arXiv:2610.14224. https://arxiv.org/abs/2610.14224

Zelikman, E., Lorch, E., Mackey, L., & Kalai, A. T. (2024). Self-Taught Optimizer (STOP): Recursively Self-Improving Code Generation. Conference on Language Modeling. https://arxiv.org/abs/2310.02304

Zhang, J., Hu, S., Lu, C., Lange, R., & Clune, J. (2025). Darwin Godel Machine: Open-Ended Evolution of Self-Improving Agents. arXiv Preprint arXiv:2505.22954. https://arxiv.org/abs/2505.22954

Zhang, J., Zhao, B., Yang, W., Foerster, J., Clune, J., Jiang, M., Devlin, S., & Shavrina, T. (2026). Hyperagents. arXiv Preprint arXiv:2603.19461. https://arxiv.org/abs/2603.19461

🌏 GIStudio

Explorer