编码智能体框架持续自我进化中的灾难性遗忘研究 Can Coding Agents Sustain Continual Evolution without Forgetting?
实证表明框架跨任务持续自我进化会灾难性遗忘，并归纳三类框架冲突成因
前置知识
Agent Harness（智能体框架）
编码智能体由基座模型与 harness 组成，形式化为 $A=\langle M,H\rangle$。harness 是模型之外的运行时系统，涵盖系统提示词、控制流、工具定义与执行环境配置，决定智能体如何感知任务、调用工具与提交结果。本文的初始 harness 是 Mini-SWE-Agent，核心仅约 100 行 Python 却在 SWE-bench Verified 上超过 74%，而同一模型配不同 harness 成绩可从 82.0% 拉开到 96.0%。
本文研究的进化与遗忘都发生在 harness 层而非模型权重，不理解 harness 的构成（提示、工具、控制流、验证逻辑）就无法理解冲突从何而来。
框架自进化（Harness Self-Evolution）
在不修改基座模型参数的前提下，让智能体从自身执行轨迹中学习：在任务集上 rollout 产生轨迹，进化算子 $\Omega$ 分析成败根因后更新 harness，即 $H'=\Omega(H,\mathcal{T})$。本文评估的 AHE 用调试智能体总结轨迹、再用进化智能体修改 harness 代码形成闭环；Meta-Harness 则维护 harness 的 Pareto 前沿，参考既有 harness 与积累经验提出新修改并评测。
论文的核心问题正是这种进化过程跨任务连续进行时会不会失忆，必须先理解自进化闭环机制才能看懂两阶段实验协议。
灾难性遗忘与稳定性-可塑性困境
源自持续学习文献：模型学习新任务时覆盖旧任务所需的知识，导致旧任务性能骤降，即灾难性遗忘，其根源是吸收新经验（可塑性）与保留旧能力（稳定性）的矛盾。本文把该概念迁移到不改参数的 harness 层，定义绝对下降 $\Delta_{\text{forget}}$ 与相对降幅 $\rho_{\text{forget}}$ 来量化源任务在后续进化后的性能衰减。
论文标题与 RQ1 都围绕这一概念展开，两组理想条件式（新任务提升、旧任务不降）就是稳定性-可塑性困境在 harness 场景的具体化。
软件工程基准：SWE-Bench / SWT-Bench / FeatureBench
SWE-Bench Verified 含 500 个人工核验的真实 GitHub issue，要求修改仓库代码修复问题；SWT-Bench 要求为 issue 生成测试用例，测试需在原实现上失败、修复后通过（fail-to-pass）；FeatureBench 给定功能需求与接口描述，要求实现新功能，用 F2P（功能正确实现）与 P2P（不破坏既有功能）双重评分。三者分别对应代码修复、测试生成、功能开发。
任务类型差异是遗忘程度差异（SWE 与 Feature 相关、与 SWT 疏远）的解释变量，也是 artifact 冲突（交付物是源码补丁还是测试补丁）产生的土壤。
数据集捷径与提示词模板依赖
当基准所有任务的提示词共享同一句式模板时，进化器可能学到依赖表面字符串的判断逻辑而非任务语义。附录 B 显示，未改写 SWT 模板时进化出的 harness 用 implement a test case 等固定短语做关键词匹配来决定交付物类型；对 SWT 提示词做语义保持改写后，这种模板依赖的条件分支不再出现。
理解这一现象才能明白作者为何改写 SWT-Bench 提示词，以及为什么进化器学到的任务判别条件本身可能非常脆弱。
研究动机
现有 harness 自进化研究几乎都在单一任务类型上独立进化：例如 AHE 在 Terminal-Bench 2 上十轮进化把种子 harness 从 69.7% 提到 77.0%，Meta-Harness 也只针对单一数据集维护 Pareto 前沿。但真实开发场景中任务类型高度混合，Stack Overflow 2026 开发者调查显示 72.9% 的开发者用 AI 智能体编写或生成代码、62.2% 用于调试排错、50.6% 用于编写或维护测试，用户完全可能先让智能体加功能、再让它写测试。另一个现实因素是 harness 影响巨大：固定同一基座模型，不同 harness 在 SWE-Bench 上成绩可以从 82.0% 拉开到 96.0%。问题在于：当一个为任务 A 进化到最佳的 harness 继续在任务 B 上进化时，为 B 学到的提示词、验证逻辑、工作流约束会不会覆盖掉为 A 学到的能力，造成灾难性遗忘？此前没有任何工作系统回答过这个问题。
本文的目标是本文的目标是对『框架能否在多任务间持续自我进化而不遗忘』给出首个系统性实证回答，并定位遗忘根因。具体拆成两个研究问题：RQ1 检验现有自进化方法在连续进化设置下能否在新任务上继续提升、同时保住旧任务能力；RQ2 追问灾难性遗忘到底由 harness 的哪些修改引起、各类型冲突的危害有多大。为此作者把 SWE-Bench Verified（代码修复）、SWT-Bench（测试生成）、FeatureBench（功能实现）三个数据集组织成六个两阶段连续进化方向，用 AHE 和 Meta-Harness 两种代表性方法做连续进化，量化旧任务性能的绝对与相对下降，并通过分析 520 条执行轨迹提炼冲突类型学，最后用受控消融把每类冲突单独注入最佳 harness 来隔离其对性能与耗时的影响。
与已有工作不同的是，本文的独特之处在于把持续学习领域的灾难性遗忘概念从参数微调迁移到不改参数的 harness 层。智能体被形式化为 $A=\langle M,H\rangle$，自进化只更新 $H$，因此遗忘不是发生在权重里，而是发生在提示词、控制流、工具与验证逻辑这些可读代码上——作者认为这种 harness 级遗忘此前被完全忽视。与已有的智能体持续学习工作（Voyager、CER、LifeMem、SWE-Bench-CL 等关注记忆与技能积累）不同，本文研究的是 harness 作为整体被联合修改时的失稳；与 harness 自进化工作（AHE、Meta-Harness、Self-Harness、HarnessX 等）不同，本文第一次让进化跨越任务类型序列，并给出可量化的遗忘度量。三个数据集、六个方向、两种方法的矩阵式设计在该领域也是首创。
核心方法
论文先把持续 harness 自进化形式化：给定数据集序列 $\mathcal{D}=(D_0,D_1,\dots,D_K)$，harness 依次按 $H_{i+1}=\Omega(H_i,\mathcal{T}_i)$ 更新，其中 $\mathcal{T}_i$ 是在 $D_i$ 上采集的执行轨迹。理想情况需同时满足适应条件 $\text{Eval}(H_{i+1},D_i)>\text{Eval}(H_i,D_i)$ 与保持条件 $\text{Eval}(H_{i+1},D_j)\ge\text{Eval}(H_{j+1},D_j)$，遗忘量用 $\Delta_{\text{forget}}$ 与相对降幅 $\rho_{\text{forget}}=\frac{\text{Eval}(H_{j+1},D_j)-\text{Eval}(H_{i+1},D_j)}{\text{Eval}(H_{j+1},D_j)}$ 度量。实验以 Mini-SWE-Agent v2.4.6（约 100 行 Python）为初始 harness，限定可进化面为系统提示、执行逻辑与工具；基座模型统一用 DeepSeek-V4-Flash-0731，温度 0，E2B 沙箱单任务限时 1 小时；AHE 跑 9 轮、Meta-Harness 跑 5 轮，每轮每任务执行 2 次以采集轨迹。
核心设计是『先单任务进化到最佳、再跨任务继续进化并回测旧任务』的两阶段协议：先在源数据集上独立进化，选出过程中的最佳 harness（同分取首次达到者），再把它放到目标数据集上继续进化，在 Initial、Iter 3、Iter 5 三个时点回评源数据集性能，从而把『新任务涨分』与『旧任务掉分』解耦观察。根因分析同样有巧思：先对初始与连续进化 5 轮后的 harness 做代码 diff 并人工归类修改，再从 520 条轨迹中找出 pass-to-fail 案例，把每例失败关联到冲突类型，统计各类型在失败中的占比；最后做受控消融——把某一类冲突的代表性修改单独注入源任务最佳 harness，量化其对 SWE-Bench 成绩与执行时间的净效应，从而区分『出现频率』与『实际危害』这两个常被混为一谈的维度。
方法步骤详情
具体步骤为：第一步，准备数据——从 SWE-Bench Verified、SWT-Bench、FeatureBench 分别采样 50、50、30 个实例，并对 SWT-Bench 固定句式模板做语义保持改写以防捷径。第二步，单数据集进化——用 AHE（9 轮）与 Meta-Harness（5 轮）在三个数据集上分别进化，记录每一代 harness 及其分数。第三步，连续进化——按 SWE→SWT、SWE→Feature、SWT→SWE、SWT→Feature、Feature→SWT、Feature→SWE 六个方向，把源任务最佳 harness 作为起点在目标任务上再进化 5 轮并回测源任务。第四步，冲突归因——提取初始与终态 harness 的 diff，人工归类为 verification、workflow、budget 三类冲突；分析 520 条轨迹中所有 pass-to-fail 案例，统计占比为 87.1%、8.2%、0.6%。第五步，消融验证——以 AHE 的 SWE→Feature 与 SWE→SWT 进化为修改来源，把各类修改分别加入 SWE 最佳 harness 后回测 SWE-Bench，测量成绩与平均耗时变化。
技术新颖性
技术新颖性体现在三方面。其一，问题定义本身是贡献：continual harness self-evolution 此前无人提出，论文还给出理想条件式与遗忘度量 $\Delta_{\text{forget}}$、$\rho_{\text{forget}}$，使后续工作可比较。其二，冲突类型学是新的分析框架：把 harness 修改归纳为 verification（证据门、交付物门等定制校验）、workflow（提示词与硬约束强加的解题流程）与 budget（时间/步数预算策略）三类，并指出 verification 中的 artifact 冲突最致命。其三，方法论上区分了流行度与危害度：87.1% 的 pass-to-fail 由 verification 冲突引起，而消融显示 artifact 约束一项就能把 SWE 成绩从 96.0% 打到 0.0%，workflow 冲突降到 66.0% 且耗时增加 235%，budget 策略几乎不伤成绩只拖慢 79%——这种逐类隔离的归因实验在自进化文献中少见。附录 B 还用 SWT 模板改写实验证明表面语言模式会被进化器当捷径利用。
实验结果
核心发现有四条。第一，单数据集进化确实有效：AHE 把 SWE-Bench 从 82.0% 提到 96.0%（9 轮），Meta-Harness 达 94.0%；两者把 SWT-Bench 从 82.0% 提到 100.0%；FeatureBench 上均提升超过 10 个百分点（AHE 第 3 轮达 30.0%）。第二，连续进化普遍触发灾难性遗忘：SWE→SWT 方向 5 轮后 AHE 与 Meta 在 SWE 上相对降幅达 100% 和 98%，近乎完全失能；Meta 在 SWT 进化到 100.0% 后再于 FeatureBench 进化即跌到 62.0%；摘要的标志性数字是 Meta 在 SWE 达 94.0% 后经 Feature 方向第 5 轮跌至 32.0%（$\rho_{\text{forget}}=66\%$）。第三，遗忘程度与任务相关性相关：SWE 与 Feature 同属改源码，互进化遗忘较小；涉及 SWT（只写测试）的方向遗忘最重。第四，三类冲突危害悬殊：pass-to-fail 案例中 verification 占 87.1%、workflow 占 8.2%、budget 仅 0.6%；消融（Table 1）显示 artifact 约束使 SWE 归零、workflow 冲突降至 66.0% 且平均耗时从 245.5 秒涨到 821.5 秒（+235%）、budget 策略成绩不变但耗时增加 79%（439.7 秒）。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 单数据集进化：SWE-Bench Verified | 解决率 (%) | AHE 96.0（9 轮） | 初始 Mini-SWE-Agent 82.0 | +14.0 个百分点（Meta-Harness 亦达 94.0） |
| 单数据集进化：SWT-Bench | 解决率 (%) | AHE 与 Meta-Harness 均达 100.0 | 初始 82.0 | +18.0 个百分点 |
| 单数据集进化：FeatureBench | 解决率 (%) | AHE 第 3 轮达 30.0 | 初始成绩未单独报告 | 两种方法均提升超过 10 个百分点 |
| 连续进化 SWE→SWT（5 轮后回测 SWE） | 相对遗忘 ρ (%) | AHE 100、Meta-Harness 98 | 源任务最佳 harness | 负向：灾难性遗忘，SWE 能力近乎归零 |
| 连续进化 SWE→Feature（5 轮后回测 SWE） | 相对遗忘 ρ (%) / 解决率 (%) | AHE 29、Meta-Harness 66（94.0→32.0） | 源任务最佳 harness 94.0 | 负向：遗忘程度与任务相关性正相关 |
| 连续进化 Feature→SWT（5 轮后回测 SWT） | 解决率 (%) | Meta-Harness 62.0 | SWT 单任务进化最佳 100.0 | 负向：下降 38.0 个百分点 |
| 冲突消融：注入 artifact（verification）冲突 | SWE-Bench 解决率 (%) | 0.0 | SWE 最佳 harness 96.0 | 相对下降 100%，平均耗时升至 415.7 秒（+69%） |
| 冲突消融：注入 workflow 冲突 | SWE-Bench 解决率 (%) | 66.0 | SWE 最佳 harness 96.0 | 相对下降 31%，平均耗时 245.5→821.5 秒（+235%） |
| 冲突消融：注入 budget 策略 | SWE-Bench 解决率 (%) | 96.0 | SWE 最佳 harness 96.0 | 成绩不变（↓0%），平均耗时升至 439.7 秒（+79%） |
局限与改进
作者承认的局限：受资源限制每个数据集只采样 50/50/30 个实例，统计功效有限；连续进化只做了两阶段序列，未验证更长任务链；只测试了 DeepSeek-V4-Flash-0731 一个基座模型、Mini-SWE-Agent 一个初始 harness 和 AHE/Meta-Harness 两种进化方法；为防捷径改写了 SWT-Bench 提示词，与原基准设置有偏差。我的补充观察：其一，论文只诊断不开药方，没有提出冲突感知的进化算法，缓解手段只能靠读者推演；其二，520 条轨迹的冲突归因依赖人工判读，类别边界（如 verification 与 workflow 交织的修改）存在主观性；其三，采样子集上能进化到 100% 说明题目偏易，遗忘幅度在更难分布上可能不同；其四，artifact 门控这类硬闸门冲突理论上只需任务类型检测即可绕开，但论文未量化加入任务路由的修复成本与可靠性，也未探索回放旧任务等持续学习标准对策在 harness 层的可行性。
独立分析的弱点
独立分析的弱点：第一，进化器对任务类型只有隐式感知，附录 B 显示它曾用 SWT 提示词的固定字符串（如 implement a test case）构造 test_deliverable 判断，一旦任务表述变化就会误判——改进方向是给 harness 引入显式任务元数据或语义路由，而非表面模式匹配。第二，单数据集最佳点直接迁移，旧任务能力没有任何保留机制——可以在进化循环中加入旧任务小规模回放回归测试，一旦旧任务掉分即拒绝该修改；持续学习中的 EWC 思想也可移植为对关键 harness 模块的修改冻结。第三，评测矩阵较小且只测一个模型——DeepSeek-V4-Flash-0731 较强，若换弱模型或不同家族模型，冲突类型占比可能改变，值得做敏感性分析。第四，人工 diff 归类不可扩展——可构建自动冲突检测器，在每次 harness 提交前静态分析 diff 是否触碰验证门、网络拦截、预算策略等敏感区域并告警。
未来方向
作者在结论中呼吁社区重视这一被忽视的问题，并希望冲突分类学能指导设计冲突感知的自进化方法。基于本文成果可直接延伸的方向包括：其一，模块化 harness——把验证门、工作流、预算策略按任务类型组织成可切换模块，进化只修改当前任务的模块，从结构上隔离冲突；其二，harness 层正则化——借鉴 EWC/L2 思想，对旧任务依赖的关键 harness 代码区域施加修改惩罚；其三，把两阶段设置扩展为 $K>2$ 的长任务序列，研究遗忘是否累积、多任务均衡是否存在；其四，建立连续 harness 进化的公开基准，纳入重构、代码评审、文档生成等更多任务类型；其五，自动化回归守护——每次进化迭代附带旧任务回归套件，把式 (3) 的保持条件 $\text{Eval}(H_{i+1},D_j)\ge\text{Eval}(H_{j+1},D_j)$ 变成进化循环内的硬约束；其六，研究任务相关性的定量度量，预测任意两个数据集间互进化的遗忘风险。
复现评估
复现友好度较高。代码已开源（github.com/THU-Agent/continual-harness-evolution），附录 Table 2 给出完整配置：初始 harness 为 Mini-SWE-Agent v2.4.6 加工具注册表，可进化面限定在 prompts（mini.yaml）、agents 控制流与 models/utils 的工具与解析器；模型 DeepSeek-V4-Flash-0731、温度 0；每任务每轮 2 次 rollout；E2B 沙箱生命周期 1 小时；AHE 9 轮（共 10 个被评测 harness）、Meta-Harness 5 轮；数据集为 SWE-bench Verified 50、SWT-bench 改写版 50、FeatureBench 30。主要成本在算力与费用：每个方向需上百次沙箱执行，六方向加单数据集进化共计数千次 E2B 调用，外加持续的 LLM API 开销，个人复现建议缩小采样或减轮次。整体难度中等偏高：管道代码可复用，但 AHE/Meta 的自实现与原论文的对齐程度、以及 520 条轨迹的人工归因环节无法完全自动复刻，三类冲突占比等结论可能存在一定方差。
论文图表
分左右两半概括全文：(a) 以 Mini-SWE-Agent 为初始 harness，在 SWE-Bench、SWT-Bench、FeatureBench 三个基准上用 AHE 与 Meta-Harness 两种方法沿六个方向做连续进化，观察到新任务适应的同时旧任务性能大幅下滑，即灾难性遗忘；右侧说明基于 520 条执行轨迹的人工分析，把 harness 修改冲突归为 verification（证据门/交付物门）、workflow（任务解题流程）、budget（超时收敛等资源策略）三类。(b) 展示冲突分类的归纳流程与各类示意。
一图看懂论文的问题设定（连续进化协议）与分析路线（轨迹→冲突分类），是理解 RQ1 与 RQ2 如何衔接的总览图。
附录 B 案例：(a) SWT-Bench 改写前的固定提示词模板；(b) 进化出的 test_deliverable 判断完全依赖模板字符串提示（如 implement a test case、don't try to fix the issue）做关键词匹配；(c) 据此生成的提交条件分支——判定为测试任务时注解源码修改、否则注解测试修改。对 SWT 提示词语义保持改写后，这类模板依赖的条件分支不再出现。
证明进化器会利用数据集的表面语言模式走捷径，同时验证了本文改写 SWT 提示词这一实验设置的必要性，关乎结论有效性。