ModularRSI：智能体框架模块化自进化

研究背景与问题

命令行智能体的能力并不只由基础模型决定。模型负责生成推理与动作，但真正决定“如何调用工具、如何读取终端反馈、何时压缩上下文、何时结束任务”的是外层运行框架。论文把这一层称为智能体运行框架，也就是包围模型的执行机制。它把模型输出解析成动作，把环境反馈整理成下一轮可见的观测，还负责保存状态、限制迭代和处理错误。

递归自改进试图让智能体根据执行经验修改自己的运行框架。已有的编码智能体和终端智能体已经证明，这种修改可以改善长程任务表现。不过，论文指出，现有方法通常直接在评测基准或其子集上进化运行框架，这会产生一个难以回答的问题：性能提升究竟来自可复用的执行机制，还是来自对评测任务的记忆与适配？

第二个问题是轨迹层面的归因歧义。单个成功轨迹可能包含有利于当前实例的偶然技巧，单个失败轨迹也可能同时混入框架缺陷、模型推理错误和任务特有的实现细节。如果直接根据一侧轨迹修改整套框架，系统很容易把实例解法写入通用机制，导致在新任务上失效。

第三个问题是机制层面的信用分配。即使诊断发现“智能体过早宣布完成”，修改仍然可能落在代理循环、工具调用、上下文管理或完成检测等多个位置。整体重写运行框架会同时改变大量行为，最终既无法确认是哪项修改产生收益，也无法判断模块之间是否互相干扰。ModularRSI 的三个核心设计正对应这三类问题：基准不相交的进化数据、成功失败成对对照、以及受范围约束的模块化演化。

基准不相交的进化数据与协议

论文没有把下游基准中的题目拿来反复训练运行框架，而是只从 Terminal-Bench 和 SWE-Bench 两大任务家族中抽取高层任务类别，例如数据处理、机器学习、系统与操作系统、数据库、网络安全和算法。标注人员再依据这些类别，从公开 GitHub 仓库、Hugging Face、Kaggle 和 Linux 内核文档等外部资源中寻找原始材料，并重新构建可执行任务。

最终数据池包含 2000 个任务，其中终端任务 1000 个、软件工程任务 1000 个。任务构造后还要经过三重质量筛选：第一，环境完整性，确认依赖、文件、工具和运行时都可用；第二，实用性与非平凡性，排除过于简单或缺少环境交互的任务；第三，评测器有效性，要求测试能够验证功能正确性，而不是只检查文件是否存在或输出字符串是否匹配。

每个候选任务还必须满足两项执行条件：参考解法能够通过全部测试，空操作提交不能获得正奖励。最后再由人工检查任务描述、环境和评测逻辑，并用语义相似度过滤掉与下游基准高度重叠的实例。这样得到的数据池不是“训练集”意义上的监督样本，而是用于收集执行经验并验证机制修改的进化环境。

领域	软件工程任务	终端任务	总计	占比
数据处理	219	162	381	19.1%
机器学习与科学计算	104	168	272	13.6%
构建与依赖	133	111	244	12.2%
系统与操作系统	102	134	236	11.8%
语言与应用程序接口	186	41	227	11.3%
网络	136	53	189	9.4%
算法	162	14	176	8.8%
安全与密码学	49	101	150	7.5%
数据库	57	68	125	6.2%

表1的数据来自论文 Figure 2。类别分布并不追求完全均匀，而是覆盖终端交互和仓库级软件工程两类差异明显的任务。论文强调，下游基准只提供高层类别方向，不提供题目、轨迹或任务特定奖励，进化阶段与评测阶段因此保持数据隔离。这个协议是全文最重要的方法论基础：如果进化结果只记住一组题目，迁移到另一套基准时应当迅速退化；只有机制级改进才可能跨域保持。

五个功能模块与运行框架分解

论文把初始运行框架设为 Harbor 中的 Terminus-2，但只允许演化直接影响智能体与环境交互的行为机制。沙箱初始化、并行执行和模型通信等基础设施不属于可编辑范围，因为它们的正确性主要属于系统工程问题，而不是任务求解策略。

第一，代理循环控制推理、动作和观测之间的迭代过程。它维护运行状态，安排各模块调用，处理重试，并根据完成检测结果决定是否继续。第二，观测管理负责把终端输出整理成模型可读的反馈，过滤噪声、保留任务相关信息，并在输出过长时压缩。第三，工具使用模块把模型文本解析成命令和完成信号，负责选择、调用并验证外部工具。

第四，上下文管理维护跨步骤的对话历史，决定哪些信息保留、压缩或重新检索。第五，任务完成检测根据最近的反馈和执行状态，判断任务是否真的结束，并返回停止建议和理由。代理循环协调另外四个模块，但模块之间的箭头表示调用关系，并不规定唯一固定的执行顺序。

模块	核心输入	核心输出	典型失败
代理循环	任务、对话、另外四个模块	执行状态、最终文本、失败标签	重复动作、错误恢复差、过早结束
观测管理	终端状态和环境句柄	可读的观测文本	丢失长日志、只看到增量短片段
工具使用	模型响应和工具调用	命令、完成信号、执行结果	解析失败、多行内容被误判为 shell
上下文管理	对话历史与原始任务	更新后的历史和交接提示	关键约束被压缩掉、上下文溢出
完成检测	循环状态、近期反馈与信号	停止建议与理由	接受没有证据的完成声明

表2对应论文 Table 8 之前的模块定义。这里的分解不是按文件目录切分，而是按行为职责切分。完成检测只提供建议，代理循环保留最终控制权；这样的接口设计允许某个模块演化后改变建议逻辑，同时仍由循环统一维护状态。论文还通过函数库管理控制复杂度：函数合并会移除功能重叠的实现，任务感知函数组合器则根据任务描述选择一个较小的函数子集，使底层函数库扩张时，单次执行激活的框架仍然保持紧凑。

对照轨迹采样与诊断

对每个进化任务，系统重复执行 K 次并获得二值奖励。设第 i 个任务第 k 次执行的奖励为 $r_{ik}$，当全部轨迹成功时任务进入正例组，当全部轨迹失败时进入负例组，当同一任务既有成功又有失败时进入对照组。论文的原始分组定义可以写成如下形式：

$$ G_i= \begin{cases} \mathrm{Positive}, & \sum_{k=1}^{K}r_{ik}=K,\\ \mathrm{Contrastive}, & 0<\sum_{k=1}^{K}r_{ik}<K,\\ \mathrm{Negative}, & \sum_{k=1}^{K}r_{ik}=0. \end{cases} $$

这个公式不是普通的奖励平均，而是在任务级别判断是否存在可比轨迹。只要同一任务同时出现成功和失败，系统就能把“相同任务、相同初始框架、不同采样结果”作为天然对照，比较两种执行过程在何处发生分歧。对全失败任务，系统还会查询轨迹记忆，寻找该任务在更早演化轮次中的成功轨迹；如果没有历史成功，才退化为对失败轨迹做单侧诊断。

正例组同样有价值。系统不会因为任务已经成功就停止分析，而是检查是否存在重复探索、无效工具调用、过长执行链或没有实际作用的步骤。分析器最终输出结构化发现，每条发现包含目标任务、被锁定的模块、轨迹分歧、反事实判断以及建议修改。反事实条件非常严格：只有当某个模块的合理改动有可能把失败轨迹推向成功时，才允许提出修改。

轨迹记忆把历史结果保留下来，使当前轮次的失败可以与过去成功形成跨轮次对照。论文统计了五个演化批次和回放轨迹：732 组即 40.67% 能直接由当前成功与失败轨迹组成对照，另有 150 组即 8.33% 的全失败任务可以通过历史成功补足对照；262 组没有历史成功，只能进行单侧分析；648 组即 36.00% 的轨迹全部成功。这个分布说明，成功与失败同时出现的样本是高质量信号，但绝不是唯一信号。

轨迹证据类型	数量	占比	分析方式
当前轮次包含成功与失败配对	732	40.67%	直接对照同一任务的执行分歧
当前全失败，历史回放存在成功	150	8.33%	用历史成功补足跨轮次对照
当前全失败且没有历史成功	262	14.56%	单侧识别明确缺陷，避免强行归因
当前全部成功	648	36.00%	分析冗余步骤与交互效率

表3来自论文 Table 9。随着演化推进，可用的即时对照配对比例从第 1 轮的 38% 降到第 3 轮的 34.17%，总降幅为 7.50 个百分点。论文把这一趋势解释为：框架逐步吸收了对照样本反复揭示的通用改进，因此同一任务再次出现“一条成功、一条失败”的概率下降。

模块级修改、验证门控与集成

结构化发现不能直接变成代码。系统先合并指向同一函数、语义相近的诊断，再按支持该修改的不同任务数量投票。若候选修改集合为 C，支撑它的任务集合为 S(C)，其证据强度可以形式化写为：

$$ \operatorname{Vote}(C)=|\{x_i\mid x_i\text{ supports }C\}|. $$

这个投票数的作用不是取代诊断，而是降低单一实例对演化的支配。某项修改如果只修复一个任务中的偶然错误，很难获得多个独立任务的共同支持。系统还为每个函数维护演化历史，记录过去的代码变化和新增能力，以减少反复修改或互相抵消。这样做等于把信用分配从“任务级结果”下沉到“被多个任务共同指向的函数级机制”。

修改之后要经过三道验证门。程序检查包括抽象语法树解析、导入检查、协议兼容、发现契约和静态属性审计；任何失败都会回滚到修改前版本。差异审查要求代码修改代理在不看奖励的情况下判断改动是否包含任务名、任务专属文件或只对单题有效的常量。最后，执行验证会从当前批次随机抽取两个任务运行修改后的框架；若出现运行错误或协议违规，同样回滚。

$$ A(m)=P(m)\cdot D(m)\cdot E(m),\qquad A(m)\in\{0,1\}. $$

这里 $P(m)$、$D(m)$、$E(m)$ 分别表示程序检查、差异审查和执行验证是否通过。这个公式是对论文三道门控的文字定义所做的直接形式化。只有当三个条件同时成立时，修改才被保留。门控并非只检查代码能否运行，它还要阻止“能运行但对训练实例过拟合”的修改进入函数库。

五个模块独立演化后，系统执行跨模块集成。独立优化可能产生重复函数、职责重叠或调用顺序冲突，因此集成阶段会重新运行进化任务，分析跨模块冲突，优先删除冗余，其次合并功能重叠的变体，再尝试小范围修复。集成完成后函数库被冻结，后续评测不再允许修改框架。

函数合并和任务感知组合器解决的是复杂度增长问题。前者通过比较函数描述和行为，把高度相似的实现合并；后者根据任务描述和候选函数描述，只激活任务相关子集。若候选函数集合为 $\mathcal F$，组合器实际选择的是 $\mathcal S(x)\subseteq\mathcal F$，目标是让函数库可以继续增长，但单次任务的提示和工具集合保持精简。

flowchart LR
  A[Evolution pool
2000 disjoint tasks] --> B[K rollouts per task]
  B --> C{Reward group}
  C -->|all pass| D[Efficiency diagnosis]
  C -->|mixed| E[Paired success-failure contrast]
  C -->|all fail| F[Historical success or single-sided diagnosis]
  D --> G[Structured findings]
  E --> G
  F --> G
  G --> H[Five independently evolved modules]
  H --> I[Program check
Diff review
Execution validation]
  I --> J[Cross-module integration]
  J --> K[Frozen harness]
  K --> L[Terminal-Bench 2.0]
  K --> M[SWE-Bench Verified]

实验设置与评价指标

论文在 Terminal-Bench 2.0 和 SWE-Bench Verified 上评测。前者包含 89 个长程终端任务，覆盖命令行交互、系统操作和构建流程；后者包含 500 个经人工验证的真实软件工程任务。进化与评测使用 Harbor 执行框架，主要进化模型为 DeepSeek-V4-Flash-Preview 和 DeepSeek-V4-Flash-0731，部署模型限速为每分钟 200 万 token，进化批大小为 10。

由于完整 2000 个任务的计算成本较高，实验从终端子集和软件工程子集中各选 120 个任务，并分别进行三轮单模块或联合模块演化。评测同时报告平均成功率、三次采样至少一次成功的比例、三次采样全部成功的比例，以及平均交互步数。它们分别关注平均能力、搜索广度、稳定性和执行效率。

平均成功率可以写成所有任务、所有执行轨迹成功指示量的平均：

$$ \mathrm{Acc}=\frac{1}{NK}\sum_{i=1}^{N}\sum_{k=1}^{K}r_{ik}. $$

三次采样至少一次成功，衡量的是任务是否落入了模型的可行解区域；三次采样全部成功，衡量的是相同框架在随机采样下能否稳定复现。它们的定义分别为：

$$ \mathrm{Pass@3}=\frac{1}{N}\sum_{i=1}^{N}\mathbf 1\!\left(\bigvee_{k=1}^{3}r_{ik}=1\right), $$ $$ \mathrm{Pass}_{3}=\frac{1}{N}\sum_{i=1}^{N}\prod_{k=1}^{3}r_{ik}. $$

平均步数则统计每个任务每次轨迹的交互轮数：

$$ \mathrm{StepNum}=\frac{1}{NK}\sum_{i=1}^{N}\sum_{k=1}^{K}T_{ik}. $$

这组指标避免只看单次成功率。如果平均成功率提高，但全部成功比例下降，说明系统可能只是增加了随机命中机会；如果 Pass@3 提高，而 Pass3 不变，说明搜索空间被打开了，但执行稳定性还没有同步改善。ModularRSI 在 Terminus-2 基线上升高了平均成功率、至少一次成功率和全部成功率，平均步数只从 34.70 增加到 35.57，说明主要收益并非来自更少的交互步数。

主要实验结果

论文首先验证跨基准迁移。使用 DeepSeek-V4-Flash-Preview，未进化框架在 Terminal-Bench 2.0 上的平均成功率为 47.57%，在 SWE-Bench Verified 上为 73.40%。如果只在终端任务上进化，冻结后的框架在未见终端任务上达到 52.43%，同时把软件工程任务提高到 75.80%；如果只在软件工程任务上进化，它在 SWE-Bench 上达到 76.45%，并把 Terminal-Bench 提高到 49.40%。

进化集合	评测设置	SWE-Bench 准确率	SWE-Bench Pass@3	SWE-Bench Pass3	TB2.0 准确率	TB2.0 Pass@3	TB2.0 Pass3
不进化	基线	73.40	83.20	62.80	47.57	58.43	30.34
终端任务	跨域与同域	75.80	84.67	66.20	52.43	65.17	35.96
软件工程任务	同域与跨域	76.45	85.30	66.80	49.40	60.67	30.34

表4来自论文 Table 2。最重要的数字不是单点提升，而是两种进化方向都能改善另一类未见任务。终端任务演化带来的跨域软件工程提升为 2.40 个百分点，软件工程演化带来的终端任务提升为 1.83 个百分点。论文据此认为，修改学到的是执行机制，而不是特定基准的答案。Terminal-Bench 的 Pass3 从 30.34% 提升到 35.96%，说明提高不仅体现在平均成功率，也体现在重复执行的一致性上。

跨模型实验冻结在终端数据上进化得到的框架，然后把同一个框架接到不同基础模型上。GLM-5.2 的平均成功率从 59.55% 提升到 61.80%，MiniMax-2.5 从 41.57% 提升到 44.94%，DeepSeek-V4-Flash 从 47.57% 提升到 52.43%。三种模型的 Pass@3 和 Pass3 也都上升。由于模型在工具调用和错误恢复上的偏好不同，如果框架修改只针对原模型，这种同时提升通常很难出现。

模块化是否真的必要由控制实验回答。把运行框架作为整体修改时，平均成功率降到 46.44%；联合修改五个模块时进一步降到 44.19%；分别演化五个模块并集成的版本达到 52.43%。这说明“限制修改范围”比允许代码代理自由重写整个运行框架更可靠。单独演化时，代理循环带来最高的单模块平均成功率 50.56%，观测管理把平均步数降到 22.50，说明不同模块的收益并不相同。

方法	准确率	Pass@3	Pass3	平均步数
基线	47.57	58.43	30.34	34.70
非模块化演化	46.44	64.04	24.72	29.03
五个模块联合演化	44.19	61.80	24.72	44.34
上下文管理单模块	49.44	61.80	31.40	35.10
工具使用单模块	50.19	62.92	30.34	41.28
代理循环单模块	50.56	64.04	34.83	40.40
观测管理单模块	49.81	65.17	33.70	22.50
完成检测单模块	49.44	65.17	31.40	31.06
ModularRSI 集成版本	52.43	65.17	35.96	35.57

表5整理自论文 Table 4 和 Table 5。全部单模块版本都优于基线的 47.57%，但任何单一模块都没有达到集成后的 52.43%。这支持了模块收益互补的判断，也说明最终结果不是某一项“神奇修改”造成的。与此同时，联合演化虽然步数更少，却明显牺牲成功率，说明节省步骤不能替代正确完成验收条件。

在与已有运行框架演化方法的统一对比中，所有方法都使用 120 个进化实例、相同 Terminus-2 起点和 DeepSeek-V4-Flash-0731。基线准确率为 61.79%，Meta-Harness 为 62.92%，AHE 为 62.54%，ModularRSI 为 67.42%。这里的绝对值与前面的 47.57% 不能直接比较，因为基础模型版本和实验协议不同；可比较的是同一张表中的相对变化。

图6显示，随演化代数增加，Terminal-Bench 准确率总体上升并在第 22 代达到 52.2，模型轨迹评分达到 74.0。两个指标并非完全同步，说明任务成功率和执行质量是两个相关但不同的观察面。论文还比较了进化任务的难度分布：中等难度中心的数据在 SWE-Bench Verified 上达到 76.45%，困难与简单任务各占 35% 的分布只有 74.25%，相差 2.20 个百分点。简单任务缺少失败对照，极端困难任务缺少成功对照，两者都削弱了机制诊断信号。

代码实现与论文机制的对应

官方仓库已经公开，并包含一个经过净化、可以运行的合并世代。仓库中有 20 个注册实现，包括 3 个代理循环、2 个观测模块、2 个上下文管理模块、5 个工具模块、2 个验证模块和 6 个求解器辅助工具。论文中的“函数库”在代码里不是抽象概念，而是这些可注册、可组合的变体。

完成完整性守卫对应论文中的任务完成检测与代理循环协调。`generations/merged_active/gen_0/modules/agent_loop/planning_with_guard.py` 会从原始指令中提取要求，在每一步维护完成与待办状态。如果模型宣布任务完成但还有待办要求，循环会重置连续完成信号，并把具体待办项反馈给模型，阻止它直接进入两阶段确认。

# generations/merged_active/gen_0/modules/agent_loop/planning_with_guard.py
if pending_text or (self._acceptance_checklist and zero_cmd):
    self._pending_completion_rejections += 1
    state.consecutive_complete_signals = 0
    prompt_parts = [
        "You declared the task complete, but the following requirements are "
        "still pending:\n\n",
    ]
    return prompt, pending_completion

这与论文的负例案例完全一致。FFmpeg 任务要求终端显示 `libavcodec`、`libavformat` 和 `libx264` 三个动态库，原始轨迹却只看到 `libx264` 就连续两次宣布完成。改进后的循环重复验收清单，促使智能体编写并运行 `verify_ffmpeg.sh`，最终三个库都出现，十项外部测试全部通过。

工具使用模块的鲁棒路由对应论文的正例案例。`combined_robust.py` 把 `write_file` 和 `edit_block` 按首个命令词识别出来，绕过通常用于 shell 命令的元字符检查，并把剩余文本完整作为文件内容传递。这样多行源码不会因为换行符被拒绝，也不会误交给 shell 执行。

# generations/merged_active/gen_0/modules/tools/combined_robust.py
parts = ks.split(maxsplit=1)
cmd_name = parts[0] if parts else ""
if cmd_name in ("write_file", "edit_block"):
    remainder = parts[1]
    path, content = remainder.split(maxsplit=1)
    # helper receives the raw multiline remainder as content
    return helper.run([path, content], ctx)

这段实现解释了 Zip Slip 修复案例为何从 41、24、43 步降到 26、18、31 步。原始工具层把多行 Go 代码交给 shell，得到 `write_file: command not found`；改进后的工具层直接写入 2204 字节文件。三个轨迹仍然全部通过 60 项测试，但平均步数从 36 降到 25。

观测管理同样有直接实现。`terminal_scrollback.py` 不再只读取自上次轮询以来的增量输出，而是读取完整终端回滚，并在面板日志不可用时累积增量内容。它会添加完整历史字节数、shell 空闲或忙碌状态，并在没有新输出时返回尾部而非重复整段陈旧内容。这个实现对应论文 Table 5 中观测管理大幅降低平均步数的结果。

案例研究说明归因方式

第一个案例来自 Scala 到 PySpark 的数据管线移植。任务要求排除 `NULL` 类别，但旧 Scala 代码没有对应过滤。成功轨迹在第 6 步加入 `isNotNull()` 并遵循书面要求，输出 47 行且没有空类别；失败轨迹选择跟随旧代码，输出 52 行并保留 5 个空类别。系统从这一对照中提出的不是“给这个任务加过滤器”，而是“让运行框架持续保留任务要求并检查待办项”。

第三个案例是 Go 文件上传服务中的 Zip Slip 漏洞。三条轨迹都能通过 60 项测试，但多行 `write_file` 命令先被错误送入 shell，随后智能体尝试其他写法，浪费大量步骤。这里没有任何失败轨迹，正例组仍通过执行效率分析发现问题。系统把修改落到工具调用层，而不是写死某个 Go 文件路径。

这三个案例分别展示了三种轨迹组的用途：混合组发现必须保留的任务约束，全失败组发现缺失的验收检查，全成功组发现可消除的工具浪费。论文也承认，后续运行同时包含其他更新，因此案例只证明目标行为确实发生，不能把收益单独归给某一项代码差异。这种表述比简单宣称“某模块提升 N 个点”更严格，也暴露了因果隔离不足。

局限性与风险

作者明确列出两项局限。第一，论文没有专门做只移除对照轨迹分析的消融实验，因此对照分析与模块化演化对最终收益的独立贡献缺少完整因果拆分。现有的配对比例变化和案例研究可以提供支持，但不能替代受控消融。第二，完整数据池包含 2000 个任务，主要演化实验却只用了其中 120 个终端任务和 120 个软件工程任务；更大规模、更广泛模型的比较被留给未来工作。

从方法本身看，第一项风险是验证门控的覆盖范围。程序检查、差异审查和两次执行验证能够过滤语法错误、明显过拟合和部分运行时冲突，但不能证明一个函数在生产环境中长期安全。尤其是代码修改代理同时负责诊断、修改和差异审查，虽然审查时不看奖励，仍可能存在共同盲点。

第二项风险是要求完成状态依赖关键词重叠。实现会用命令、工具输出和终端观测中的词匹配待办项，短要求的阈值是一词命中，长要求通常需要两词命中。这个启发式适合推动模型继续检查，却可能把“提到相关词”误判为“已经完成验收”。论文的安全阀在多次拒绝后回退到两阶段确认，避免死循环，但这仍然降低了对完成判断的严格程度。

第三项风险是任务感知函数组合器本身也是模型调用。候选函数只提供自然语言描述，组合器需要据此选择子集；如果描述不完整或任务边界模糊，激活错误函数会引入新的行为漂移。论文报告了最终集成的收益，却没有分别量化组合器错误率、提示 token 成本和函数库增长后的检索延迟。

第四项风险来自评测范围。主要结果集中在 Terminal-Bench 2.0 和 SWE-Bench Verified，基础模型也只有三类左右。论文证明了跨域和跨模型迁移，但尚未覆盖真实生产仓库、长期维护、多智能体协作、安全敏感任务和不同执行预算。平均成功率提升约 5 个百分点具有价值，但还不足以证明递归自改进可以在无人监督下持续部署。

结论与展望

ModularRSI 把运行框架自改进从“整段代码重写”改造成“从多个任务的对照证据中定位模块级缺陷”。它通过基准不相交的数据协议降低记忆评测题的风险，通过成功失败配对把任务结果转化为机制信号，通过五个模块限制修改范围，再用三道验证门阻止不可执行和过拟合的改动。最后，跨模块集成把独立收益组合起来，函数合并与任务感知组合器控制长期复杂度。

实验结果显示，冻结后的框架能够迁移到未见任务、未见领域和不同基础模型。其方法学意义大于单一基准分数：它把递归自改进的可验证性问题显式化，要求先回答“改进是否可迁移”，再讨论“代码是否变强”。未来最值得继续验证的方向，是在更大数据池上做对照分析消融，并把成本、安全、可解释性和长期维护纳入同一套评测协议。