ModularRSI:面向长时序编码与终端任务的模块化、可泛化递归框架自我改进

  • 关联论文：2609.14857
  • 作者：flyP
  • 更新：2026-09-17

一句话结论

ModularRSI 把「让 Agent Harness 学会自己变好」这件事从「整块黑盒单轨迹微调」拆成「对比成功/失败轨迹 → 定位模块缺陷 → 在受限范围内独立进化 → 集成回归」的四段流水线，并用一份与下游评测基准不相交的 2,000 任务进化集抑制基准特化拟合，从而在 TB2.0 与 SWE-Bench Verified 的未见任务、以及跨底座模型迁移上都取得稳定提升。

解决的真问题

近期 Agent 研究把「递归自我改进（Recursive Self-Improvement, RSI）」从模型权重层扩展到了 Agent Harness 层——即让「Agent Loop、工具调用、观测处理、上下文管理、任务完成判定」这些执行机制本身在跑任务的过程中持续被改写，并在 SWE-Bench、TerminalBench 这类长时序编码与终端基准上刷新了 SOTA。但这条路有三条硬骨头，ModularRSI 论文把它们点得很清楚：

  1. 基准特化 vs. 真正可复用的进化：直接在某个评测集或其子集上跑进化，会让 Harness 演化成「针对该评测分布」的特例，工程上看起来涨点，但换个基准就垮。
  2. 单轨迹更新的归因混淆：拿一条成功的轨迹反推「为什么这次跑通」，常常把系统性的 Harness 缺陷和这一题的特殊推理路径 / 解题细节缠在一起，得到的修改很可能迁移不到下一道题。
  3. 单体 Harness 的局部化困难：现有 Harness 多是单体（monolithic）实现，错误往往藏在某个角落，全局优化又会牵动无关机制，导致归因与验证都很麻烦。

简单说：过去 Harness RSI 的主要风险是「自己骗自己」——涨分是涨了，但涨的是对评测集的过拟合，而不是 Harness 本身变好。

核心方法

ModularRSI 的整体框架可以拆成「对比聚合 → 模块化解构 → 受限进化 → 集成回归」四个环节：

1. 对比聚合：成功 vs. 失败的轨迹对比

对同一个任务，ModularRSI 让基座 Agent 同时收集「成功轨迹」与「失败轨迹」，然后在更广的任务集合上对这两类轨迹做逐任务配对的对比，聚合出反复出现的行为缺陷（recurring behavioral deficiencies）。这一步的关键词是 contrastive 和 aggregate：单次对比噪声大，必须跨任务聚合才能把「这道题特有的小聪明」与「这个 Harness 真正缺的能力」分开。

2. 模块化解构：把 Harness 切成 5 个功能模块

论文明确把可进化的 Harness 解构成五个功能模块，每个模块承担一类独立的执行职责：

  • Agent Loop：主循环的步进、轮次控制、状态机推进；
  • Tool Use：工具选择、参数生成、错误处理、调用协议；
  • Observation Management：对环境/工具返回值的清洗、截断、归一化、结构化；
  • Context Management：上下文的滑窗、压缩、检索、记忆与回放策略；
  • Task Completion Detection：判定「任务是否真的做完了 / 是否陷入死循环 / 是否需要重规划」。

这个 5 模块划分本身就是一个可借鉴的工程抽象——它把「Harness」从一段神秘 prompt + 一段神秘代码，落到了一张可以单独讨论、单独 A/B、单独回归的接口图。

3. 受限进化：在每个模块的「允许范围」内独立演化

针对每个模块，ModularRSI 限定一个restricted modification scope：例如对 Context Management，可能允许动的是「压缩策略」「回放窗口大小」「记忆召回阈值」；对 Tool Use，可能允许动的是「错误重试次数」「参数校验规则」「工具选择打分函数」。模块间彼此隔离地进化，这一步切断了「改 A 模块时顺带把 B 模块带偏」这条传统痛点，也让归因回到了「这次涨点是 X 模块的 Y 改动贡献的」这种可证伪陈述。

4. 集成回归：拼装 + 冲突解决

各模块独立进化完成后，ModularRSI 进入一个集成阶段：把 5 个被改过的模块拼回完整 Harness，并显式做冲突解决（resolve potential conflicts）——例如 Tool Use 改完后要求 Observation Management 提供新的字段、但 Context Management 还在按旧字段裁剪，就要在集成阶段统一修订。集成完还要在进化集（注意是独立的 2,000 任务，不是下游评测基准）上做回归，避免拼装时破坏单模块效果。

5. 进化集：benchmark-disjoint 的 2,000 个可执行任务

为了防止「对着评测集进化」造成的基准特化，论文专门从外部来源策划了 2,000 个可执行的进化任务，并强制这些任务与下游评测基准（TB2.0 / SWE-Bench Verified 等）不相交。这一点在方法论上非常重要：等于让进化阶段「不知道」下游要测什么，从而显著提升「涨点可迁移」的概率。

ModularRSI 伪代码（高层）

for epoch in 1..E:
    for task in evolution_pool (size=2000, disjoint from eval):
        succ_traj, fail_traj = base_agent.run_pair(task)
        deficiency_log += diff(succ_traj, fail_traj)
    deficiencies = aggregate(deficiency_log)              # 跨任务聚合
    for module in [Loop, Tool, Obs, Ctx, Done]:
        patch[module] = evolve_within_scope(
            module, deficiencies,
            allowed_ops = module.allowed_modifications    # 受限范围
        )
    harness = integrate(patches, conflict_resolver=rules)  # 集成 + 冲突解决
    if regression(harness, evolution_pool) < threshold:
        rollback(module)                                  # 单模块回滚

关键实验与数据

论文把 ModularRSI 进化出来的 Harness 拿到两个公认较难的长时序编码/终端基准上做评测：

  • TB2.0（TerminalBench 2.0）：覆盖真实终端任务的评测基准；
  • SWE-Bench Verified：经过人工核验的 SWE-Bench 子集，被广泛用于衡量 Agent 在真实软件工程任务上的能力。

实验重点验证三件事：

  1. 未见 in-domain 任务上的稳定提升：进化的进化集与评测集虽然 benchmark-disjoint，但属于同领域，因此能否涨点直接反映 Harness 是否真的学到了「这个领域通用的执行能力」；
  2. 跨领域迁移：把进化出来的 Harness 拿到与进化集领域差异更大的任务上是否仍然有效；
  3. 跨底座模型迁移：同一个进化出来的 Harness 换到不同底座模型上是否仍然有效——这一点是「Harness 改进 ≠ 模型特性」的关键验证。

具体到数字，原文给出的方向是「consistent improvements」与「evolved harness also transferring across different foundation models」，但精确的百分比 / 绝对分差需查 PDF §实验段（原文 abstract 未给出逐项分数）。这里我按论文描述给出框架性结论，不杜撰具体百分点；如果你要做横向对比表，建议打开 PDF 第 5–7 节看完整实验表与消融。

补充一个值得关注的工程细节：ModularRSI 强调 modular + contrastive + benchmark-disjoint 三件套共同作用，任意单件都不是它独创——对比聚合在 RLHF/自我修正里早就有了，模块化 Harness 在 OpenHands、LangGraph、CrewAI 等框架里也有体现，benchmark-disjoint 在 self-play 里也常见。ModularRSI 的贡献在于把这三件事第一次显式组装成一个面向「Harness 自我进化」的完整流水线，并把「基准特化」这种容易被人忽略的风险写进了方法论。

亮点与局限

亮点

  • 方法论诚实：论文把 Harness RSI 的三大风险（基准特化、单轨迹归因混淆、单体归因困难）前置写在 abstract 里，而不是先讲涨点再补限制——这种写法在自我改进类论文里是少见的克制。
  • 可拆解的工程抽象：5 模块划分（Harness 抽象成 Loop / Tool / Obs / Ctx / Done）本身就值得工程团队抄一份进自己的 Agent 框架，把「调试 Harness」变成「调试某个模块」。
  • benchmark-disjoint 进化集：用外部来源 2,000 任务 + 强制与下游评测不相交，是防止自我进化类工作自欺欺人的硬约束，值得作为后续同类工作的默认规范。
  • 跨底座迁移：进化出的 Harness 能跨模型复用，意味着 Harness 本身在逼近一种「模型无关的工程制品」，这对多模型路由/切换的产线很关键。

局限

  • 绝对数字公开度有限：abstract 没给出 TB2.0 / SWE-Bench Verified 上的逐项对比数字，外部读者只能确认「consistent improvements」与「transfer across models」的方向性结论——这给二次引用带来不便。
  • 「模块边界」本身是个人为划分：5 模块切分是否最优、Tool Use 与 Observation Management 之间的接口是否清晰，仍取决于实现者的工程判断，论文并未给出不同切分下的对照消融。
  • 冲突解决策略的细节未在 abstract 暴露：集成阶段 resolve potential conflicts 的具体规则（启发式 / 规则 / 二次进化？）需查 PDF §方法段（原文未明确）。
  • 2,000 任务进化集的可复现性：外部来源的策划标准、与 SWE-Bench Verified 等基准的实际重叠率、是否覆盖足够多的失败模式，决定了 ModularRSI 的泛化上限——这一点 abstract 没披露。
  • 与 RL 微调路线的对比缺位：当前 LLM Agent 自我改进的另一条主线是直接对模型做 RL 微调（如 RLAIF、Self-Rewarding、STaR 系），ModularRSI 把进化限定在 Harness 层，与模型层进化的协同 / 互补关系 abstract 未讨论。

对工程落地的启发

  1. 把 Harness 当成可独立调试的工程制品：不要再把 Agent 失败归到「模型不够聪明」一档，先看是 Loop / Tool / Obs / Ctx / Done 哪个模块的问题；这条复盘路径比换模型成本低得多。
  2. 建立自家 benchmark-disjoint 的回归集：在做 RAG / Agent / Prompt 优化时，留一份「与线上评测不相交的内部回归集」，避免优化器对评测过拟合——ModularRSI 的 2,000 任务设计可以缩到几百任务的迷你版。
  3. 受限修改范围（restricted modification scope）作为变更纪律：每次只允许改一个模块的一种类型（如 Tool 的重试次数、Ctx 的压缩比），并强制集成阶段做冲突解决+回归；这条纪律可以直接搬进内部 PR 流程。
  4. 跨模型迁移作为 Harness 工程的硬指标：如果一个 Harness 优化只在某个特定模型上有效，那大概率是 Harness 把模型的偏置学进去了；用「换底座是否仍涨」做最终验收，能筛掉很多伪改进。
  5. 失败/成功轨迹配对日志：从今天开始给线上 Agent 跑双轨（同一题两种采样 / 同题两种 prompt 变体），累积 contrastive log，是给未来 Harness 进化留的「训练数据」。

与同方向工作的关系

  • Harness / 框架层 RSI 路线：与近期在 SWE-Agent、OpenHands、AutoCodeRover 等系统上做的「Harness 自我改进」同主线；ModularRSI 的差异点是把改进拆到模块级并显式做 benchmark-disjoint。
  • Agent 自我修正（self-correction / self-refine）：单次反思 vs. 跨任务聚合，ModularRSI 属于后者的工程化版本。
  • RL 微调类自我改进（RLAIF / Self-Rewarding / STaR / RLVR）：ModularRSI 把进化局限在 Harness 层，与「改模型」是平行互补而非替代。
  • Agent 评测方法学：与 TerminalBench、SWE-Bench Verified、GAIA 等长时序评测共享评测对象，但 ModularRSI 不自建评测，而是强调「在已有评测上验证通用性」。
  • 多 Agent / 程序化 Prompt 优化（OPRO、PromptAgent、TextGrad）：ModularRSI 的「受限修改范围」可以视作一种结构化搜索，比纯自然语言 prompt 搜索更易归因。

适合谁读

  • 正在做 Coding Agent / Terminal Agent / DevOps Agent 工程化的团队负责人，需要决定「下一轮投入该改模型、改 prompt 还是改 Harness」；
  • 在 SWE-Bench / TerminalBench / GAIA 这类长时序评测上做 Agent baseline 的研究员，想要一个比「直接调 prompt」更系统的改进框架；
  • 对 Agent Harness 工程抽象（Loop / Tool / Obs / Ctx / Done）感兴趣的架构师，可直接借鉴其模块划分与受限修改纪律；
  • 关心 自我改进类研究的方法论风险（基准特化、归因混淆、单体归因困难）的审稿人/方法学读者，会喜欢 abstract 前置风险讨论的写法。

一段话带走

如果只记一句：ModularRSI 的真正卖点不是「Harness 又涨点了」，而是把 Harness 自我改进这件事，从「对着评测集瞎改 prompt」升级成「对比聚合 → 模块化解构 → 受限进化 → 集成回归」的工程流水线，并用 benchmark-disjoint 的进化集堵住了最常见的自欺路径。 对工程团队来说，这套流水线比任何具体百分比都更值得抄回去。