AI 自我进化，先改模型外面的外壳：Lilian Weng 讲透 harness 工程
- 前 OpenAI 安全系统负责人 Lilian Weng 发文提出「harness 工程」：包在 AI 模型外面、负责工具调用、上下文管理、记忆和评估的那层运行系统，是通向 AI 递归自我改进（RSI）的关键、却常被忽视的一环。
- 她把 harness 里被优化的对象归纳成一条进阶阶梯：提示词，结构化上下文，工作流，harness 代码本身，再到优化器代码；越往上，可搜索的设计空间越大。
- 文章梳理了 ACE、MCE、Meta-Harness、STOP、Self-Harness、AlphaEvolve、DGM 等 20 多项 2023 至 2026 年的研究，展示 AI 已经能自己给自己的「外壳」提改动、跑测试、留下更强的版本。
- 实测证据显示自我进化确实有效：DGM 让编程 agent 在 SWE-bench Verified 上从 20% 进化到 50%；但 STOP 的实验也表明这套机制只有底层模型足够强时才管用，弱模型反而会退化。
- 文章最后列出这条路目前撞到的 7 个卡点：评估标准太弱太模糊、奖励黑客、多样性坍缩等等，并强调人类要留在关键节点做监督，而不是被移出循环。
为什么模型外面那层东西突然重要了
OpenAI 前安全系统负责人 Lilian Weng，在个人博客 Lil'Log 上发表长文，提出「harness 工程」这一命题，把它和 AI 递归自我改进（RSI）的研究方向系统地连接起来。
她的核心论点很简单：模型与真实世界之间的那层系统，和模型本身的原始智能同样重要。人们习惯盯着模型有多聪明，却常常低估了包在它外面、负责调度一切的那层外壳。
为什么值得看：RSI 这个想法可以追到 1965 年 I.J. Good 提出的「超级智能机器」（一台能造出比自己更强机器的机器），2008 年 Yudkowsky 给它起名叫「递归自我改进」。现代版本可以是模型直接改写自己的权重，也可以是模型去改进训练管线和部署系统，这条更间接、但更现实的路。Weng 指出，Anthropic 和 OpenAI 都已观测到前沿实验室的研究速度明显加快。
Weng 的判断是：近期的 RSI，不太可能一上来就是模型直接改自己的权重。更可能先落在「部署系统」这一层，而部署系统里最关键的部件，就是 harness，也就是 Claude Code、Codex 这类成功编程 agent 产品背后的那套系统。这篇文章聚焦的正是围绕 harness 工程的研究，以及它怎么一步步通向自我改进。
Harness 到底是个什么东西
harness 是包在一个基础模型外面的整套系统，它负责编排整个执行过程，决定模型怎么思考和规划、怎么调工具去行动、怎么感知和管理上下文、把产物存到哪、以及怎么检验结果对不对。
早期讲 agent，公式是「agent = 模型 + 记忆 + 工具 + 规划 + 行动」。harness 工程在这之上又多包了几层：工作流设计（比如怎么设计那个循环）、评估、权限控制、持久状态管理。它已经很接近运行时和软件系统的设计，讲的是模型怎么观察、怎么行动、怎么记忆、怎么自查、怎么改进这一整套。
harness 和模型的关系，很像操作系统和 CPU：模型是那颗提供原始算力的 CPU，harness 是围着它跑的操作系统，负责调度、权限管理、文件存储这些「脏活」。跟操作系统一样，好的 harness 会把复杂逻辑都藏在里面，对外的接口却保持简单。Weng 也提到，随着行业发展，配置、工具接口这些协议会慢慢走向标准化。
让模型自己规划、记忆、还能分身干活
Weng 先给出三个具体、可操作的 harness 设计模式。它们回答的是同一个问题：一个能长时间自己干活的系统，最底层需要哪几块拼图。
范式一：给模型一个能反复迭代的工作流
关键是先划定一个模型可以在里面「动手、测试、再改」的流程。常见的做法是一个目标导向的循环：先规划，再执行，然后观察或测试结果，接着改进，再执行，一圈圈转下去，直到达成目标。过程中它也可以主动回头问用户，把任务说清楚。Karpathy 的 autoresearch 仓库就是这种工作流的一个干净范例。这个循环特别强调一点：模型要去分析自己跑过的轨迹和失败案例，然后基于这些去迭代，而不是死守一个固定的提示词模板。
范式二：把文件系统当成模型的长期记忆
长时间干活的 agent，实验日志、代码 diff、论文摘要、报错记录、过往的执行轨迹，很快就会长得比模型训练时见过的上下文窗口还长。所以 harness 不该把整个流程和所有日志都硬塞进上下文里，而是把这些持久状态写进文件，需要时再读回来。读、写、改文件（一般靠 bash 命令）本来就是 AI 模型的基础技能，用文件这种最朴素的形式来管理长期记忆，天然会随着模型本身能力的提升而变好。
范式三：派出子 agent 并行干活，还得管得住
一个 harness 可以派生出多个子 agent 并行执行，再盯着这些后台任务。当主 agent 需要同时试好几个假设、并行跑实验、或者把一些独立的子任务甩出去、又不想污染主线上下文时，这招很有用。这时主 agent 需要一个小型的进程管理器：能启动任务、查看日志、取消失败的运行、再把结果合并回主线。
这里最关键的设计是：让并行这件事变得可检查、可留痕。如果子 agent 的产出只活在易失的对话上下文里，它们很快就会过时、被淹没；只有把它们存成文件、日志和状态记录，模型才能在中断后恢复，并回过头去梳理自己的执行历史。
把这三块拼起来，就是当下主流编程 agent 的样子。Weng 指出，Claude Code、Codex、OpenCode、Cursor 这类产品的核心接口已经趋同，都用类似的一套工具在跑：
