> 来源：UsefulAI（实用 AI / Useful AI）— https://usefulai.cloud/insights/harness-self-improvement-skepticism/
> 作者：CarryChang · 最近更新：2026-09-13 · 语言：zh-CN

[实用 AI 指南](https://usefulai.cloud/) › [深度阅读](https://usefulai.cloud/insights/)

Agent Harness
自我改进
AHE

# 当所有人都在聊 Harness 能"自我改进"时，我想泼一盆冷水

最近一篇论文（Agentic Harness Engineering，简称 AHE）演示了让一个 Agent 自动读取失败日志、修改另一个 Coding Agent 的工具、中间件和系统提示词，十轮迭代后把 Terminal-Bench 2 的 pass@1 从 69.7% 提到 77.0%，超过了人工精心设计的 Codex CLI（71.9%）。这个结果被不少人解读成"Agent 已经能自我改进了"。我认真读完论文本身的消融实验和局限章节后，认为这个解读过于乐观——论文自己给出的数据里，藏着一个被大多数转述忽略的"回归盲区"问题。

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

### 结果确实亮眼：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 的缺陷，比纯手工调参更高效**——这仍然是一个了不起的工程结果，但和"自主自我改进"之间，还差着"能不能预见自己造成的新问题"这一整层能力。

#### 关键数据

- 10 轮迭代：Terminal-Bench 2 pass@1 从 69.7% 提升到 77.0%

- 超过人工设计的 Codex CLI（71.9%）与两个自我进化基线

- 三组件单独贡献加总 +11.1pp，实际叠加只有 +7.3pp

- 修复预测精确率/召回率 33.7%/51.4%，回归预测仅 11.8%/11.1%

#### 我的判断

- 「回归盲区」是这篇论文最该被关注、却最常被忽略的数据

- 实验环境有裁判、有回滚机制，不等于无监督生产场景可用

- 论文自己也承认这是「受控研究原型」，不是成熟自主系统

- 真正的能力缺口：能不能预见自己这次修改会造成什么新问题

## 继续阅读

[如何从零构建你自己的大语言模型：GPT 和 Claude 背后的 5 阶段流水线 → 所有前沿模型都由同样的五个阶段构建：数据 → 预训练 → 监督微调 → 奖励建模 → 强化学习。学会这套骨架，你就不会再把模型当作魔法。](https://usefulai.cloud/insights/how-llms-are-built/)
[Anthropic 工程师：我们日常如何使用 Claude Code → 用一个真实 repo 演示 Anthropic 工程师怎样配置 Claude Code、让它问问题、生成 HTML 规格稿，再把验证流程做进 React 组件和浏览器。](https://usefulai.cloud/insights/anthropic-how-we-use-claude-code/)
[深度阅读 → 15 篇 AI 长文的完整中文解读：Claude Code、Skill、Agent、大模型原理、LLM 资源地图。](https://usefulai.cloud/insights/)