我的立场：这篇论文的工程贡献是真实的——把「不可观测的手工调参」变成「可观测、可回滚的结构化编辑」，这个思路本身值得肯定。但「自我改进」这个词暗示的是一个可以无监督持续运转、越改越好的闭环，而论文数据显示的是：这个循环能可靠地识别「哪里该修」，却几乎无法预见「这次修改会在哪里捅出新的窟窿」。一个没有能力预见自己会造成什么新问题的系统，谈不上真正意义上的自我改进，只能叫「在人类持续巡检下的半自动调优」。

结果确实亮眼：10 轮迭代跑赢人工设计的 Harness

AHE 的做法是把 Coding Agent 的"外围组件"——系统提示词、工具实现、中间件、长期记忆——都暴露成可编辑的文件，让一个"进化 Agent"读取失败轨迹分析报告，自主决定要改哪个组件、怎么改，每次编辑都要写明预测会修复哪些任务、可能会牵连哪些任务的回归风险，下一轮再核验这个预测对不对。跑了 10 轮迭代之后，在 Terminal-Bench 2 的 89 个任务上，pass@1 从种子版本的 69.7% 提升到 77.0%，超过了三个人工设计的 Harness（opencode 47.2%、terminus-2 62.9%、Codex CLI 71.9%），也超过了两个同样从种子版本自我进化的对比方法 ACE（68.9%）和 TF-GRPO（72.3%）。跨任务迁移测试里，这套进化出来的 Harness 不需要重新训练，直接搬到 SWE-bench-verified 上还能小幅提升（75.2%→75.6%），换到另外三个不同厂商的基座模型上也都有正向收益（+2.3 到 +10.1 个百分点）。这些数字是扎实的，我不否认。

被忽略的关键数据：组件不是简单加总，回归预测几乎是瞎猜

论文自己做的消融实验（拆开看每个组件单独的贡献）暴露了两个问题，恰恰是这些细节没有被大多数转述提及：

  • 组件效果不能线性叠加。把长期记忆、工具、中间件三个组件分别单独换进种子版本，各自带来 +5.6、+3.3、+2.2 个百分点的提升，加起来应该有 +11.1 个百分点，但把三者都用上的完整版本，实际提升只有 +7.3 个百分点。论文对此的解释是"组件之间存在非加性交互"——记忆、中间件、系统提示词都倾向于推动同一种收尾验证行为，叠在一起之后，Agent 会把回合数浪费在重复的自我核查上。这说明"多加几个自我改进的模块"不是免费的，模块之间会互相争抢同一份任务预算。
  • 修复预测靠谱，回归预测几乎是瞎猜。这是我认为最该被放大的数字：进化 Agent 对"这次编辑会修好哪些任务"的预测，精确率 33.7%、召回率 51.4%，大约是随机瞎猜基线的 5 倍，说明它确实是有依据地在下判断。但对"这次编辑可能会搞坏哪些任务"的预测，精确率只有 11.8%、召回率只有 11.1%，只比随机瞎猜基线高出约 2 倍——论文原话把这个现象叫做"回归盲区"（regression blindness）：这个 Agent 能讲清楚一次修改为什么应该有帮助，但几乎说不出这次修改会在别的地方捅出什么新问题，这正是整个进化曲线在图上会忽上忽下、不是单调上升的根本原因。
评论员视角

我想直接指出这个问题的严重性：一个只能事后归因、无法提前预见自己会造成什么新损害的系统，用在需要持续、无监督运行的生产场景里是危险的。论文的实验设置本身也承认了这一点——研究者全程盯着攻击面（哪些文件能改、哪些不能改）、每一轮都有明确的评测基准告诉系统对错，任何"进化"方向錯了都能立刻被下一轮的评测打回去。这是一个有安全网、有裁判、迭代速度可控的受控实验环境，跟"扔给它一个真实生产系统，让它自己连续跑几周"完全是两件事。论文在 Limitations 章节里也主动说了这句实话：这套系统应该被当作"受控的研究原型"，不是"成熟的自主自我改进系统"。

「自我改进」这个词本身没问题，但它经常被不加限定地传播成"AI 已经能在没有人盯着的情况下持续变强"，这个推论论文的数据并不支持。真正准确的说法应该是：在有裁判、有回滚机制、迭代节奏被人为控制的环境里，让一个 Agent 系统性地识别并修复另一个 Agent 的缺陷，比纯手工调参更高效——这仍然是一个了不起的工程结果，但和"自主自我改进"之间，还差着"能不能预见自己造成的新问题"这一整层能力。