冻结模型权重，Agent还能持续进化：ModularRSI探索Harness自我改进

近日，IQuest Research 同北京航空航天大学、曼彻斯特大学等合作伙伴发布 ModularRSI，尝试让 Agent 根据自身执行经验，持续修改模型外围的运行机制——Harness。

在基础模型全程冻结的情况下，经过 Harness 演化，系统在 Terminal-Bench 2.0 上的准确率从47.57 提升至 52.43。更关键的是，这些改进还能迁移到未参与演化的任务、不同领域乃至不同基础模型。

• arXiv：https://arxiv.org/abs/2609.14857
• Code: https://github.com/IQuestLab/ModularRSI
• Blog: https://recursive-self-improvement.notion.site/blog-1-modularrsi-toward-generalizable-harness-rsi

这项工作的核心问题很直接：当模型本身不再变化，Agent 能否通过改造“模型如何工作”，获得持续的自我改进能力？

研究团队把一个 Agent 写成：

A=(M,H)

其中，(M) 是基础模型，(H) 是 Harness。

对于今天的 Agent 来说，最终表现已经越来越依赖模型外围的系统机制。模型能够看到哪些环境信息，怎样维护上下文，什么时候调用工具，失败后如何恢复，以及什么情况下可以宣布任务完成，都会影响最终结果。

这些机制共同构成了 Harness。

ModularRSI 进一步把变化对象放到了 Harness 上：

模型 (M) 始终冻结，Harness 则随着执行经验不断发生变化。

Agent 每完成一批任务，都会留下执行轨迹；系统从轨迹中寻找反复出现的缺陷，再修改自身运行代码，让下一轮执行建立在上一轮经验之上。

这构成了 Harness Recursive Self-Improvement，也就是Harness RSI

视频链接：https://mp.weixin.qq.com/s/AU_oX_YrnUJ4HYfmctwL3A

视频 1｜Performance of the harness across different evolution generations on Terminal-Bench 2.0

视频 1 展示的正是这一现象：基础模型保持冻结，外围 Harness 随着演化代次推进，Terminal-Bench 2.0 表现持续提高。作者据此提出，Agent 的迭代式能力提升并不必然伴随模型权重更新，改善智能被组织和调用的方式，同样可能带来性能增长。

不过，只看一条不断上涨的 benchmark 曲线，还很难证明真正的“自我改进”已经发生。

Figure 2｜A case showing that the overfitting issue of modern agents is much more in disguise than traditional machine learning

如果一个 Agent 反复在同一类任务上执行，并不断针对失败修改代码，它很容易逐渐熟悉特定 benchmark 的任务结构、工具约定和常见失败模式。此时分数依然会上涨，但 Harness 学到的可能只是局部策略。因此，研究团队给 Harness RSI 设置了一个更严格的判断标准：只有当改进能够泛化到产生这些改进的经验之外，自我改进才真正具有意义。

围绕这一标准，ModularRSI 将 Harness 演化与最终评测严格隔离。团队构建了一个包含 2000 个高质量实例的数据池，从中抽取两个互不重叠的演化集：120 个 Terminal-Bench 相关实例和 120 个 SWE-Bench 相关实例，并分别演化出 TB-evolved 和 SWE-evolved Harness。演化结束之后，Harness 被冻结，再放到 Terminal-Bench 2.0 和 SWE-Bench Verified 上进行评估。整个演化和模型选择过程中，都不会使用最终 benchmark 的评测数据或反馈。

研究关注的重点由此从“能不能把当前任务做得更高”，转向“Agent 究竟有没有学到可以重复利用的执行机制”。

先拆开 Harness，再让它学习

直接让一个 LLM 阅读完整 Agent 代码库，然后同时诊断、修改所有逻辑，搜索空间会迅速变大。一次失败也可能来自多个位置：工具调用错误、环境反馈处理不当、上下文丢失、循环逻辑异常，或者任务尚未完成时就提前退出。因此，ModularRSI 先将 Harness 拆成五个相对独立的模块：

• Agent Loop：负责“推理—行动—观测”的迭代过程；
• Observation Management：处理和筛选环境反馈；
• Tool Use：负责工具选择、调用和参数构造；
• Context Management：维护历史信息、任务约束和中间结果；
• Task Completion Detection：判断任务是否已经真正完成。

框架图｜Overview of ModularRSI：五个 Harness 模块、轨迹分析、Harness Evolution 与 Validation Gate

每个模块从同一个初始 Harness 出发独立演化。一次任务执行结束后，ModularRSI 不会根据单条失败轨迹立即修改代码。对于同一个任务，它会进行多次 rollout，并根据执行结果形成几类不同的比较：

1、如果所有轨迹都成功，系统继续检查其中是否存在重复操作、多余工具调用或低效交互。

2、如果同一个任务同时出现成功和失败轨迹，价值更高。任务和环境保持一致，结果却不同，系统可以直接对比两条轨迹，判断究竟哪些决策改变了执行结果。

3、如果所有轨迹都失败，系统则进一步寻找历史迭代中有没有成功版本；如果依然找不到，再分析死循环、错误工具调用、薄弱的错误恢复或提前终止等问题。

之后，这些轨迹会被整理成结构化 findings：哪个 Harness 函数可能存在问题、证据来自哪里，以及应该进行怎样的修改。只有当类似缺陷在多个任务和多条轨迹中反复出现，它才会获得更高的修改优先级。因此，ModularRSI 的目的是把“某一次任务失败”逐渐抽象成“某一种系统性缺陷”。

此外，代码写回 Harness 之前，还要连续通过三道验证：第一道是Program Check，检查语法、import、接口契约等基本程序正确性；第二道是Diff Review，重点寻找任务特定常量、面向单个实例的解决方案，以及可能只对当前 batch 有效的启发式规则。出现明显特化倾向，修改会被回滚；第三道是Execution Validation，让修改后的 Harness 重新实际执行任务。出现新的运行时错误，同样无法保留。

最后，ModularRSI 会分别获得五个模块的独立进化结果，并通过 Cross-Module Integration 机制在进化集上进一步执行一个 epoch 的联合进化，将各模块的改进进行整合，从而得到最终的 evolved harness。与此同时，研究团队还引入了 Function Merge 和 Task-Aware Function Composition 两个机制：前者用于合并功能相近或存在冗余的 functions，以减少功能重复与潜在冲突；后者则根据不同任务的需求，从各模块中动态选择并组合合适的 functions，使最终 harness 能够针对具体任务调用更适配的执行能力。

这套机制让 Harness 的演化更接近一套受约束的软件迭代流程：执行产生经验，经验形成诊断，诊断进入代码；并且，代码只有经过验证才能成为下一代系统的一部分。

模型没变，能力还能迁移

最终实验验证了 Harness 本身具有相当大的优化空间。

在 Terminal-Bench 2.0 上，原始 Harness 的准确率为，经过 ModularRSI 演化后提高到，提升4.86 个百分点

单独观察不同模块，还能看到明显的功能分工。其中，Agent Loop 带来的单模块准确率提升最大，约为2.99 个百分点；Observation Management 对执行效率的改善更加明显，平均交互步数下降约35%

值得注意的是，把所有模块直接放在一起联合演化，结果反而下降。Joint All-Module Evolution 的准确率只有。而先让各模块独立演化，再将有效能力合并，最终可以达到 52.43。

这说明 Harness 内部存在很强的耦合关系。局部有效的改动进入整个系统之后，可能改变其他模块的工作条件，甚至产生新的冲突。

研究团队除了在in-domain的setting下验证了演化后的Harness在TerminalBench和SWE-Bench Verified上都有提升之外，随后又把测试范围从单一 benchmark 推向了跨领域。在 Terminal-Bench 相关任务上演化得到的 Harness，放到 SWE-Bench Verified 上后，准确率比原始 Harness提高2.40个百分点。反过来，在 SWE 相关任务上演化得到的 Harness，用于 Terminal-Bench 2.0，也获得了1.83个百分点的提升。领域内迁移的收益更高，但跨领域的两个方向都出现了正向增益。

随后，研究团队进一步替换基础模型。Harness 最初基于 DeepSeek-V4-Flash Preview 完成演化，冻结之后，再分别与 GLM-5.2、MiniMax-2.5 搭配。在 Terminal-Bench 2.0 上：GLM-5.2 的准确率从59.55 提高到 61.80；MiniMax-2.5 从41.57 提高到 44.94；DeepSeek-V4-Flash 则从47.57 提高到 52.43

这意味着，一部分 Harness 层经验并没有和某一个基础模型完全绑定。减少无意义循环、改善错误恢复、提高任务完成判断可靠性，这类机制本身并不完全由模型决定。对 Harness RSI 来说，这种迁移能力比单一 benchmark 上的性能上涨更加重要，因为它直接对应了研究最初提出的那条判断标准：优化能不能脱离产生它的经验继续成立。

Agent 能力提升最快的，

恰好是补足“半会不会”的任务

在实验中，团队还发现了另一个有意思的现象：用于演化的数据难度，会直接影响 Harness 能从中学到多少东西。

研究人员构建了两种数据分布：一组以中等难度任务为主，约一半实例成功率位于 40%—60%；另一组则主要由极简单和极困难任务组成。结果差异显著：在 medium-centered 设置下，演化集得分从58.4% 提升到 65.0%，增加 6.6 个百分点；而 Hard & Easy 设置只提高了0.6 个百分点

Figure 3｜Medium-difficulty evolution compounds; Hard & Easy stalls：不同难度分布下的 Harness 演化曲线

原因与 ModularRSI 的学习方式直接相关。任务太简单，大多数轨迹都会成功，系统很难获得有价值的失败证据。任务太难，大多数轨迹又都会失败，系统也缺少成功版本作为参照。真正信息密度高的区域，反而是那些“有时能成功，有时会失败”的任务。“成功”和“失败”结果同时存在时，ModularRSI 才能通过对比轨迹判断，到底是什么机制改变了结果。

这也意味着，如果未来 Harness RSI 进一步发展，数据构建会变成同模型训练一样重要的问题。任务规模之外，难度分布、轨迹多样性以及成功失败比例，都可能直接决定 Agent 最终能够从自身经验中提取出什么。

从“连续八次执行错误命令”，到一个通用恢复机制

Harness 相比模型权重还有一个天然优势：研究人员能够直接看到它究竟学到了什么。研究中给出了一个 Agent Loop 的完整演化案例。

某次失败任务中，Agent 连续八次执行同一条无效命令，随后又不断声称任务已经完成。Verifier 一直拒绝，最终 Agent 耗尽了执行预算。ModularRSI 最初加入了guarded_completion，用来阻止缺乏证据的任务完成声明，同时识别重复命令。后续轨迹又暴露出格式错误，于是系统进一步加入parse_error_recovery，帮助 Agent 识别并修正此前的 malformed output。

再往后，新的失败出现了：Agent 虽然停止了完全重复同一条命令，却可能长时间执行ls、cat、grep等只读操作，看起来一直在工作，实际没有真正推进任务。于是系统继续扩展机制，开始检测这种“长期探索却没有编辑、构建或测试”的状态。之后，Harness 又演化出planning_checklist，追踪哪些需求已经完成、哪些仍待处理，并进一步和此前的错误恢复逻辑结合。

Figure 4｜A case study of the function merge：从 guarded_completion、completion_integrity_guard、planning_checklist 到 planning_with_guard 的模块演化案例

这个过程值得注意的地方在于，一次具体“失败”被抽象成了重复检测、完成判断、错误恢复、停滞识别和规划管理等更加一般的机制。这也是 Harness RSI 与简单经验记忆之间最重要的区别。

不过，模块分别学到有效机制之后，新的问题随之出现：这些能力合在一起，有时会互相打架。

研究团队发现，演化后的 Agent Loop 和 Verification 单独运行时都有收益。但组合之后，两边都包含自己的任务完成判断，相当于系统内部同时出现了两个 completion gate。Agent 可能已经通过其中一层，却又被另一层拦住，随后不断在“完成—验证—再次完成”之间循环，直到任务超时。最终，ModularRSI 保留 Verification 作为唯一的最终完成判断，同时保留 Agent Loop 中有效的错误恢复逻辑。

这也进一步说明，Harness 演化需要优化模块之间的关系。

自我改进开始从模型延伸到整个系统

研究团队最后还尝试回答一个更基础的问题：这些代码变化究竟有没有对应 Agent 行为本身的改善？

他们使用一个 LLM judge，从任务有效性、交互质量、推理过程可靠性、上下文与状态管理、效率和鲁棒性等维度，对不同 Harness 演化代次产生的轨迹进行评分。结果显示，随着 Terminal-Bench 准确率提升，行为评分也呈现出基本一致的增长趋势。

Figure 5｜Consistency between Harness Performance Improvement and LLM-based Behavioral Evaluation during RSI

这类行为评分无法替代跨任务、跨领域和跨模型实验，但它提供了另一层证据：性能变化同时伴随着可观察的执行行为变化。

从这个角度看，ModularRSI 给 Agent 自我改进提供了一种更加具体的工程实现。经典的递归自我改进通常把系统能力增长与模型本身的更新联系在一起；Harness RSI 展示了另一条可能的演化轴。

模型继续决定能力边界，而 Harness 则决定这些能力怎样进入真实执行过程。更强的模型可以带来更好的知识、推理和内部表征；更好的 Harness 则能够改善工具调用、上下文管理、错误恢复、执行效率以及任务完成判断。随着 Agent 开始承担越来越长、越来越复杂的真实任务，这两层优化必然会相辅相成。

ModularRSI 目前仍处于早期阶段。不同模块如何更稳定地共同演化，什么样的数据最适合 Harness RSI，更大规模数据和更多演化轮次能否继续产生稳定收益，以及不同类型模型会怎样影响 Harness 的演化方向，都还有待进一步探索。

但至少这项研究已经展示了一个清晰的现象：模型权重冻结之后，Agent 依然可以从执行经验中发现自己的系统性缺陷，把这些经验重新写回 Harness，并让下一轮执行建立在前一轮的基础上。

当学习对象从模型扩展到模型所处的整个运行系统，Agent 的“自我改进”也开始拥有了新的实现路径。