ModularRSI：模块化且可泛化的递归式智能体框架自我改进 ModularRSI: Modular and Generalizable Recursive Harness Self-Improvement
用同任务成败轨迹对比与五模块受限演化，让智能体框架在不接触评测基准的前提下实现可泛化自我改进
前置知识
Agent Harness（智能体执行框架）
指包裹在大模型之外、决定智能体如何行动的整套代码：执行循环、工具调用解析、上下文与历史管理、环境反馈处理、终止判断等。同一个模型配上不同 harness，在终端与代码任务上的成绩可以相差十几个百分点。本文把 harness 视为可被代码化改写的对象，而非固定的脚手架。
全文的演化对象是 harness 而非模型权重，读者必须先分清'模型能力'与'框架机制'这两条不同的改进路线。
递归自我改进（RSI）
指系统利用自己的执行经验来改进自身组件，改进后的系统再产出新的经验，形成闭环。应用于 harness 时，模型既是被改进智能体的'大脑'，也是执行改进的'工程师'——本文中两者由同一个模型充当，称为 Code-Modify Agent。
本文的核心问题是让这种闭环产生可泛化而非过拟合的改进，这是理解其评测协议设计（基准隔离、演化后冻结）的前提。
轨迹与二值奖励
轨迹（trajectory）是智能体完成一个任务的完整执行记录：每步的提示、动作、工具输出与观察。奖励 $r_i^k \in \{0,1\}$ 由任务专属评估器给出，1 表示通过全部测试。轨迹与其奖励共同构成演化信号的基本单元。
对比轨迹分析、Positive/Contrastive/Negative 分组、Pass@k 指标全部建立在'轨迹+奖励'这组概念之上。
对比轨迹分析（contrastive trajectory analysis）
对同一任务用同一框架独立采样多次，成功轨迹与失败轨迹在行为上的分歧点，能把失败原因从'任务本身难'中剥离出来——因为任务难度、环境、框架代码全部相同，唯一变量是采样随机性。这类似对照实验中通过控制变量寻找因果。
这是 ModularRSI 把任务级成败转化为框架级修改信号的核心机制，也是论文标题中 contrastive 一词的含义。
信用分配（credit assignment）
强化学习与智能体系统中的经典问题：只知道最终结果好坏时，如何把功劳或责任分配到具体决策或组件上。本文场景下即：任务失败了，究竟是上下文压缩丢了关键信息、工具解析出错，还是终止判断过早？
作者明确把 harness RSI 的难点框定为信用分配问题，模块化分解与对比分析都是针对它的解法，这是全文的问题主线。
Pass@k 与 Pass^k 指标
Pass@3 表示 3 次独立尝试中至少 1 次成功的任务占比，衡量能力上限；Pass^3（本文写作 Pass3）表示 3 次尝试全部成功的任务占比，衡量稳定性与可靠性。两者差距越大，说明智能体表现越不稳定。
论文用 TerminalBench 2.0 上 Pass3 从 30.34 升到 35.96 来论证 harness 演化改善的是执行可靠性，而不只是单次解题能力。
TerminalBench 2.0 与 SWE-Bench Verified
TerminalBench 2.0 包含 89 个长程真实终端任务，需在容器内通过命令行完成目标；SWE-Bench Verified 包含 500 个人工校验的真实 GitHub 仓库 issue 修复任务。两者都需要多步环境交互，并由任务专属测试判定正确性。
它们是本文的两个下游评测基准，演化数据刻意与其完全隔离，所有泛化性结论都建立在这两个基准的成绩上。
Harbor 与 Terminus-2
Harbor 是终端类智能体评测的统一框架，提供容器化环境、评估器与执行接口；Terminus-2 是其中官方实现的基础 harness。ModularRSI 以 Terminus-2 为共同起点，把它的行为机制重组为五个功能模块后再进行演化。
所有实验（基线、演化、对比方法）都从同一个 Terminus-2 出发，这保证了各方法对比的公平性，也是复现实验的入口。
研究动机
智能体在复杂软件工程与终端任务上的表现越来越取决于模型之外的 agent harness——即控制执行流程、工具交互、上下文管理和环境反馈的那层代码。近期工作把递归自我改进（RSI）引入 harness，让智能体从自身执行经验中改写框架，但任务级成败只是极粗糙的监督信号，作者指出三个相互纠缠的问题。其一是数据层面：可执行、带可靠环境与正确性反馈的长程终端任务构建成本极高，已有自动生成方法难以同时保证环境完整性、任务有效性和评估器可靠性，于是 Meta-Harness、AHE、RHO 等方法普遍直接在下游评测基准或其子集上演化，再在同一基准上评估，无法区分框架'学到了可复用的改进'还是'记住了基准的特殊模式'。其二是轨迹层面：单条、单侧的执行轨迹把系统性框架缺陷与任务特定的推理和解法细节纠缠在一起，直接据此优化会引入迁移性很差的任务特定行为。其三是机制层面：即便发现了反复出现的行为缺陷（例如反复声明任务完成却从不验证），也很难在单体式 harness 中定位到应负责的组件，整体重写会把不相关机制搅在一起，改动既难归因也难验证。表1的对比显示，此前的 11 个代表性框架没有一个能同时做到模块化演化、整体演化和不使用基准数据。
本文的目标是本文的目标是构建一个基准隔离、对比式、模块化的 harness 自我演化框架 ModularRSI，使框架改进能泛化到演化时从未见过的任务、领域乃至基础模型。具体拆成三件事：第一，把粗粒度的任务成败转译为定位到模块的局部演化信号——通过对比同一任务的成功与失败轨迹、并在跨任务范围聚合证据，识别反复出现的行为缺陷；第二，把可演化的 harness 分解为 Agent Loop、Tool Use、Observation Management、Context Management、Task Completion Detection 五个功能模块，每个模块在受限修改范围内独立演化，再经跨模块整合合并为统一框架；第三，建立基准隔离的评测协议：从外部来源独立整理 2000 个可执行演化任务，与 TerminalBench 2.0 和 SWE-Bench Verified 完全不相交，演化完成后冻结框架再评估，并用程序检查、diff 审查、执行验证三道闸门过滤不可执行或过拟合的修改。
与已有工作不同的是，本文的独特之处在于把 harness RSI 的核心难点明确框定为'信用分配问题'并给出三层解法。与 GEPA 式的提示词进化、Darwin Gödel Machine 式的整体代码重写不同，ModularRSI 的证据单元不是单条轨迹，而是'同任务成功-失败轨迹对'：同一任务、同一框架、不同采样导致不同结局，其行为差异天然控制了任务难度与模型能力两个变量，使归因能落在框架机制上；再通过跨任务投票（统计支持同一修改方向的不同任务数量）过滤实例特异性。在修改侧，它不像多数现有方法那样重写大块框架，而是把修改空间锁死在单个模块的功能范围内并行演化，随后专门做一轮跨模块整合解决冲突。在评测侧，作者不满足于常规的 held-out 评估，而是从 GitHub、Hugging Face、Kaggle、Linux 内核文档等外部来源独立构建 2000 个任务，并用语义相似度筛除与基准重叠的实例，从数据源头上杜绝'演化集即测试集'的循环论证。
核心方法
直觉上，ModularRSI 像一个带质检流程的闭环改造车间：先大量执行任务攒下成败记录，再对比分析找出框架层面的系统性短板，然后由'修理工'（Code-Modify Agent，即被演化的智能体本身）在各自负责的模块内改代码，每处修改都要过三道质检才能保留，最后把五个独立改造的模块组装调试成一体。技术路线分三阶段：(1) 对比轨迹采样与分析：对每个演化任务 $x_i$ 用当前框架 rollout $K$ 次（实验中 $K=3$），由任务专属评估器打二值奖励 $r_i^k \in \{0,1\}$，按 $\sum_k r_i^k$ 把任务分为 Positive（全成功）、Contrastive（有成功有失败）、Negative（全失败）三组，并维护 Trajectory Memory 保存历史 epoch 的轨迹，供当前 rollout 不足时补配对比对；(2) 模块级框架修改：Code-Modify Agent 对比同任务成败轨迹、对 Negative 组做单侧诊断（重复循环、错误工具调用、无效恢复、过早终止）、对 Positive 组做效率分析（冗余动作、重复探索、不必要调用），把诊断固化为 JSON 结构化 findings，按支持任务数投票排序后修改对应模块函数，修改时参考记录历次变更的 Evolution History；(3) 验证门：程序检查（AST、import、协议合规等静态检查）、reward-blind 的 diff 审查（拒绝任务特定补丁）、执行验证（随机抽 2 个任务实跑），任一失败即按记录的 diff 回滚。五个模块独立演化 3 个 epoch 后做跨模块整合，再用 Function Merge 去冗余、Task-Aware Function Composer 按任务激活函数子集，最后冻结函数库用于下游评测。
核心创新是把'任务级粗奖励'翻译成'模块级局部修改信号'的完整流水线，关键在三个设计。第一，同任务对比：Contrastive 组中成功与失败轨迹共享完全相同的任务、环境与框架代码，唯一不同的是采样，因此两条轨迹的分歧点（divergence）几乎可直接归因于框架的可控行为——例如成功轨迹坚持了任务说明中'过滤 NULL 类别'的要求而失败轨迹跟随了遗留代码的行为；分析提示词明确要求做反事实判断：'改变目标模块是否会把该任务从失败推向成功'，不成立就记 is_culprit=false 并放弃修改，避免为了找茬而找茬。第二，跨任务聚合加受限修改：把语义相似的诊断合并成候选修改方向，按支持它的不同任务数量投票排序，优先采纳多任务共同支持的系统性改进；每条修改被锁定在单一模块的功能范围内，五个模块互不共享中间更新、可并行演化，从机制上避免'改 A 模块误伤 B 模块'。第三，防御性验证：diff 审查是 reward-blind 的（审查者看不到奖励，只检查因果链是否具体、是否出现任务名、任务专属文件或为单个任务调的常量），从源头拦截过拟合。与已有方法的本质区别在于：它们大多'从单侧轨迹直接改整个框架'，ModularRSI 则'从对比证据改单个模块'，把泛化性作为贯穿数据、分析、修改、验证全流程的一等约束。
方法步骤详情
完整流程如下。第一步，准备：以 Harbor 框架中的 Terminus-2 为初始框架，把其行为机制重组为五个模块——Agent Loop 负责推理-行动-观察循环与恢复行为；Observation Management 把终端原始输出转成可读反馈并压缩噪声；Tool Use 负责解析模型响应、执行命令、校验调用；Context Management 负责维护与压缩对话历史；Task Completion Detection 判断任务是否完成；沙箱初始化、并行执行、LLM 通信等基础设施组件明确排除在演化范围外。第二步，轨迹采样：每个 epoch 对 120 个 TB 相关加 120 个 SWE 相关演化任务各 rollout $K=3$ 次；实现层把三组细化为 routing buckets（表8）：Positive 分 all pass efficient / all pass wasteful，Contrastive 即 mixed，Negative 分 fixable fail / stuck fail / unreachable fail，纯基础设施失败不进入框架诊断。第三步，分析：Contrastive 组配对同任务成败轨迹找功能级差异因素；Negative 组先查 Trajectory Memory 找历史成功轨迹配对，找不到才做单侧诊断；Positive 组做效率分析。每任务产出一条 finding，字段含 task、lens、is_culprit、locked_module、divergence、would_change_outcome、fixable_now、suggested_change。第四步，修改：合并相似诊断，按支持任务数投票，取高优先级方向，结合该函数的 Evolution History 生成补丁。第五步，验证门：静态程序检查，reward-blind diff 审查，随机抽 2 个任务执行验证；任一步失败即回滚。第六步，整合与管理：五模块各自演化 3 个 epoch 后在演化集上运行整合框架，识别并修复跨模块冲突（去重、明确职责、调整协调逻辑）；函数库用 Function Merge 合并相似函数、用 Task-Aware Composer 依据函数描述为每个任务选择激活子集；最后冻结函数库，在 TerminalBench 2.0（89 任务）与 SWE-Bench Verified（500 任务）上评测。
技术新颖性
技术新颖性可从四个层面评估。数据层面，2000 任务的基准隔离演化集是专为 harness RSI 泛化性评测设计的资源：下游基准只提供领域类别标签用于检索指导，实例全部从 GitHub、Hugging Face、Kaggle、Linux 内核文档等外部来源构造，经 LLM 三维过滤（环境完整性、实用性/非平凡性、评估器有效性）、可执行验证（参考 solution.sh 必须全过测试、空提交必须拿零分）、人工复核、语义相似度去重四道工序，类别分布均衡：数据处理 381 条（19.1%）、ML 与科学 272（13.6%）、构建与依赖 244（12.2%）、系统与 OS 236（11.8%）、语言与 API 227（11.3%）等，TB 与 SWE 相关任务各 1000 条。方法层面，'同任务对比+跨任务投票+模块锁定+reward-blind diff 审查'的组合是新的，尤其 diff 审查被显式设计为看不到奖励的反过拟合闸门，这在相关工作中少见。工程层面，演化出的函数库通过 Function Merge 与 Task-Aware Composer 保持'库可扩张、激活集精简'，缓解了 RSI 系统常见的库膨胀问题。实证层面，表4 的控制实验直接证明了设计必要性：非模块化演化（46.44）和五模块联合演化（44.19）在 TerminalBench 2.0 上反而低于基线 47.57，而模块独立演化加整合达到 52.43——这是'受限修改优于整体优化'论点的直接证据而不只是直觉。
实验结果
核心结果有七组。(1) 跨基准泛化（表2）：以 DeepSeek-V4-Flash-Preview 为骨干，在 TB 相关 120 任务上演化后，TerminalBench 2.0（in-domain）准确率从 47.57 提到 52.43，Pass@3 从 58.43 到 65.17，Pass3 从 30.34 到 35.96；在 SWE 相关任务上演化后，SWE-Bench Verified 从 73.40 到 76.45。更关键的是跨域迁移：TB 演化的框架把 SWE-Bench 提到 75.80，SWE 演化的框架把 TerminalBench 提到 49.40，说明学到的是可复用的执行机制而非基准特化。(2) 跨模型迁移（表3）：冻结 TB 演化框架后，GLM-5.2 从 59.55 到 61.80，MiniMax-2.5 从 41.57 到 44.94，DeepSeek-V4-Flash 从 47.57 到 52.43，三项指标全线提升。(3) 模块化消融（表4）：联合全模块演化降到 44.19、非模块化演化 46.44，均低于基线 47.57，只有 ModularRSI（52.43）显著超过基线；联合演化的 StepNum 恶化到 44.34 步。(4) 单模块贡献（表5）：五个单模块演化全部超基线，Agent Loop 准确率增益最大（50.56），Observation Management 把平均步数从 34.70 压到 22.50，整合后达 52.43 / 35.96，说明各模块贡献互补。(5) 与现有 RSI 方法对比（表6）：统一协议下（同 Terminus-2 起点、同 120 任务、AHE 与 Meta-Harness 跑 16 epoch 对齐总轮数、禁用 web 搜索、DeepSeek-V4-Flash-0731），基线 61.79，Meta-Harness 62.92、AHE 62.54 仅提升约 1 个点，ModularRSI 达 67.42（+5.63）。(6) 对比分析有效性（图3、表9、附录D）：演化中可用对比轨迹对占比从 epoch 1 的约 41.67% 降到 epoch 3 的 34.17%（Δ=-7.50pp），说明框架逐步吸收了对比例暴露的缺陷；五次演化运行加回放中 40.67% 的任务组有同 epoch 成功-失败对、8.33% 靠历史成功补配、14.56% 无任何对照、36.00% 全成功。案例上：FFmpeg 0.10.16 构建任务（要求 ldd 可见三个库）在 epoch 1 三个 rollout 全失败（只链接 libx264 却两次空声明完成），触发'完成前强制验收检查'修改后 epoch 3 全部通过（10/10 测试）；Go Zip Slip 修复任务在保持全对的同时，三 rollout 步数从 [41,24,43] 降到 [26,18,31]，均值 36 到 25。(7) 数据难度分布（图4、表7、表11）：以中等难度为中心（50% 位于 40-60% 难度段）的演化集训出的框架在 SWE-Bench Verified 达 76.45%，比'难易两端'分布（35%/35%）高 2.20 个百分点。附录F 显示 22 个 generation 上演化曲线基本单调上升，Acc 与 LLM judge（Opus-4.8）评分分别达到约 52.2 和 74.0。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| TerminalBench 2.0（TB 相关演化集，in-domain） | Acc | 52.43 | 47.57（无演化 Terminus-2 基线） | +4.86 |
| TerminalBench 2.0（TB 相关演化集，in-domain） | Pass3（三次全对） | 35.96 | 30.34 | +5.62 |
| SWE-Bench Verified（SWE 相关演化集，in-domain） | Acc | 76.45 | 73.40 | +3.05 |
| SWE-Bench Verified（TB 演化集迁移，out-of-domain） | Acc | 75.80 | 73.40 | +2.40 |
| TerminalBench 2.0（SWE 演化集迁移，out-of-domain） | Acc | 49.40 | 47.57 | +1.83 |
| TerminalBench 2.0 跨模型迁移（GLM-5.2） | Acc | 61.80 | 59.55 | +2.25 |
| TerminalBench 2.0 跨模型迁移（MiniMax-2.5） | Acc | 44.94 | 41.57 | +3.37 |
| TerminalBench 2.0 对比现有 RSI 方法（统一协议） | Acc | 67.42（ModularRSI） | 62.92（Meta-Harness）/ 62.54（AHE）/ 61.79（基线） | +4.50 vs Meta-Harness，+5.63 vs 基线 |
| SWE-Bench Verified（演化数据难度分布对比） | Acc | 76.45（Medium-centered 分布） | 74.25（Hard & Easy 分布） | +2.20 |
| TerminalBench 2.0 执行效率（Observation Management 单模块） | StepNum（平均步数，越低越好） | 22.50 | 34.70 | -12.20 步 |
局限与改进
作者明确承认两点局限：一是没有做隔离对比轨迹分析贡献的专门消融，其有效性只靠轨迹组占比变化（图3）和案例研究（附录D）间接支撑；二是受算力限制，主实验只从 2000 任务中各取 120 条（TB 相关与 SWE 相关各一）做演化，全量数据集的规模化效果未验证。我的补充观察：执行验证门每次只随机抽 2 个任务实跑，统计功效很弱，可能放过引入运行时回归的修改；五模块划分来自作者对现有 harness 的人工分析，是强先验而非从数据中学到的结构，换一种框架形态（如多智能体系统）未必适用；演化与主评测都以 DeepSeek 系模型为主，跨模型迁移只在 TerminalBench 一个基准上验证；ModularRSI 的 StepNum 为 35.57，略高于基线 34.70，可靠性提升伴随轻微效率开销；随演化推进可用对比对占比持续下降（41.67% 到 34.17%），后期演化信号可能变稀；难度估计依赖 4 个基础模型各 8 条轨迹的经验成功率，本身昂贵且带噪声；轨迹质量评分用 Opus-4.8 做 LLM 裁判，存在裁判偏倚风险；最后，演化任务的类别标签取自 TerminalBench/SWE-Bench 家族，虽未用实例，仍存在与基准间接分布对齐的可能。
独立分析的弱点
独立分析四点弱点。第一，验证门太薄：执行验证抽样仅 2 个任务、diff 审查由同一个 LLM 自审自改，二者都难以可靠拦截'在多数任务上通过但破坏少数任务'的回归修改；改进方向是把执行验证扩展为分层抽样并加上与上一代框架的成对比较和显著性检验，同时让 diff 审查由独立模型执行。第二，模块边界是人工先验：五模块划分清晰但不保证完备——跨模块的架构级缺陷被标为 fixable_now=false 后基本被搁置，系统只能做局部修补而非架构升级；改进方向是增设低频'架构提案'通道，用更强的证据门槛（如多 epoch 反复出现）解锁跨模块重构。第三，演化信号统计基础薄弱：每任务每 epoch 只有 $K=3$ 条轨迹，组划分对采样噪声敏感——一个任务 3 次中 2 成 1 败与 1 成 2 败同样进入 Contrastive 组，但证据强度不同；改进方向是按经验成功率自适应分配 rollout 预算，把投票从任务计数改为置信度加权。第四，评估面窄：只有终端与代码两个基准，未覆盖 web agent、多模态等环境；效率指标只看步数，不看 token 成本与墙钟时间，Observation Management 把步数降到 22.50 是否同时降低 token 开销并未报告；改进方向是补充成本维度，并至少在一个非终端环境复验迁移性。
未来方向
作者提出的方向是把演化扩展到 2000 任务全量，并做更大规模的比较研究。基于本文成果还可延伸：其一，补做对比分析的受控消融（同任务对比 vs 随机配对 vs 单侧诊断），量化每种证据机制的边际贡献；其二，把模块演化与模型权重更新（RL 或自蒸馏）结合——本文只改框架代码，框架层面的改进（如完成前验收检查）能否蒸馏进模型本身值得探索；其三，跨模型族演化：用多个异构模型的混合轨迹做演化证据，检验'模型无关框架改进'这一论断的边界；其四，终身或在线 RSI：当前是'演化-冻结-评测'的离线范式，如何结合 Function Merge 与回归测试集在不遗忘旧能力的前提下持续演化是自然延伸；其五，把 reward-blind diff 审查升级为基于模块接口契约的形式化验证；其六，效率方向：Observation Management 单模块即可把步数从 34.70 降到 22.50，说明存在可系统刻画的精度-效率 Pareto 前沿；其七，把五模块分解迁移到 web/GUI agent、科学计算 agent 等其他长程环境，检验其普适性。
复现评估
复现条件总体友好。代码与数据全部开源在 https://github.com/IQuestLab/ModularRSI，2000 个演化任务以 Harbor 格式发布，评测用原版 TerminalBench 2.0（89 任务）与 SWE-Bench Verified（500 任务），统一在 Harbor 框架下运行。算力方面无需训练 GPU：演化是纯 API 驱动的代码改写循环，论文使用 DeepSeek-V4-Flash-Preview 与 0731 两个模型，TPM 限制 2M tokens、batch size 10、3 个 epoch、每子集 120 任务、每任务 $K=3$ 次 rollout——主要成本是长程终端任务的 API 调用费与时间（TerminalBench 任务动辄数十到上百步交互）。难点有三：演化结果对 LLM 采样随机性敏感，论文的 52.43 等数字难以精确复现，只能期望统计意义上相近；2000 任务的构建含人工审查环节（任务清晰度、环境完整性、评估器正确性的人工复核），第三方完整重建这套数据工作量不小；轨迹质量评分依赖 Opus-4.8 做裁判，该模型可获得性会影响这部分评估。总体复现难度评为中等：有代码、有数据、有统一评测框架，复现方向性结论容易，精确复现数字较难。
论文图表
五个单模块独立演化的成绩：Context Management 49.44/61.80/31.40/35.10；Tool Use 50.19/62.92/30.34/41.28；Agent Loop 50.56/64.04/34.83/40.40；Observation Management 49.81/65.17/33.70/22.50；Task Completion Detection 49.44/65.17/31.40/31.06；跨模块整合后 ModularRSI 达 52.43/65.17/35.96/35.57。
揭示各模块的互补贡献：Agent Loop 主攻准确率、Observation Management 主攻效率（步数降 12.20），整合收益大于任何单模块，也说明小预算单模块演化已可超基线。
统一协议下的对比（同 Terminus-2 起点、同 120 演化任务、AHE 与 Meta-Harness 演化 16 epoch 对齐总轮数、禁用 web 搜索、DeepSeek-V4-Flash-0731）：基线 61.79/73.03/50.56，Meta-Harness 62.92/74.16/50.56，AHE 62.54/73.03/51.69，ModularRSI 67.42/78.65/56.18。
说明在基准隔离协议下现有 RSI 方法的提升收窄到约 1 个点，而 ModularRSI 提升 5.63 个点，凸显其泛化优势。
Medium-centered 难度分布演化出的框架在 SWE-Bench Verified 达 76.45%，Hard & Easy 分布为 74.25%，前者高 2.20 个百分点。
量化证明演化数据的难度分布直接影响框架改进的泛化质量，为演化数据工程提供可操作结论。
两种 SWE 相关演化集在 0-20%/20-40%/40-60%/60-80%/80-100% 五个难度段的比例：Medium-centered 为 10/15/50/15/10%，Hard & Easy 为 35/10/10/10/35%。难度由 MiniMax M2.7、GLM-5.2、DeepSeek-V4-Pro、DeepSeek-V4-Flash 四个模型各 8 条轨迹的经验成功率估计。
定义了图 4 与表 7 实验的自变量，说明难度可控的数据构建方法，是复现难度分布实验的必要信息。