AI 自我改进的 harness 工程新帖

同一个底层模型，放在普通聊天窗口里，可能只会给出几段建议；放进 Codex、Claude Code 这类编程环境里，却能规划任务、读文件、改代码、跑测试、看报错，再继续修。能力差距不只来自模型本身，还来自模型外面那套让它能行动的系统。

Lilian Weng 在《Harness Engineering for Self-Improvement》里讨论的就是这层系统。她把递归自我改进（RSI）的近期路径，更多押在 Harness 工程上，而不是模型直接重写自己的权重。换句话说，AI 自我改进的第一批现实突破，可能先发生在文件系统、工具协议、评估器、工作流和 agent 运行时里。

这个判断也和作者背景有关。Lilian Weng（Thinking Machines Lab 联合创始人她此前是 OpenAI VP，方向包括 AI Safety、robotics 和 applied research）。所以这篇文章不是单纯讲“怎么把 agent 做得更强”，还一直把工程系统、评估边界和权限控制放在同一条主线上。

Harness不是提示词，而是模型的运行时

递归自我改进这个概念可以追溯到 I. J. Good 和 Yudkowsky：一个系统利用当前能力，去改进产生这种能力的机器或机制。放到今天，它既可以指模型改自己的权重，也可以指模型改进训练管线和部署系统，进而帮助下一代模型变得更强。

Lilian Weng 特意强调“部署系统”，因为原始模型和真实任务之间还有一层很厚的工程外壳。Harness 就是这个外壳的核心：它决定模型怎么规划、怎么调用工具、怎么管理上下文、怎么保存中间产物、怎么评估结果。早期 agent 常被概括成“LLM + memory + tools + planning + action”，Harness 则多了工作流设计、评估、权限控制和持久状态管理。

[图1：简化版 Codex agent 循环] agent 调用工具，工具响应会影响模型的下一轮生成。

这也是为什么“提示词写得好”已经不够解释现代编程 agent 的能力。真正起作用的是一套运行时设计：什么时候让模型思考，什么时候让它读文件，什么时候执行命令，什么时候停下来验证，什么时候把结果写进可恢复的状态里。它更像操作系统之于应用进程，而不是一段更长的 prompt。

三个模式撑起编程agent的长程任务

第一种模式是工作流自动化。常见循环是“计划 -> 执行 -> 观察/测试 -> 改进 -> 再执行”。agent 不是一次性回答完就结束，而是在执行结果和失败轨迹里继续调整。对编程任务来说，这个循环很关键：代码能不能跑、测试过不过、错误日志写了什么，都会反过来影响下一步动作。

[图2：编码 agent 的 Harness 循环] 有了工具访问能力后，编码 agent 能在给定代码仓库中开发和调试问题，类似开发者使用 IDE。

第二种模式是把文件系统当成持久 memory。长程任务里的实验日志、代码 diff、错误追踪、论文摘要和 rollout 轨迹，很快会超过模型上下文窗口。Harness 不应该把所有东西都塞回上下文，而是让 agent 用读写文件、编辑文件、执行 bash 等方式保存和检索状态。这样中断后还能恢复，也更接近工程师真实工作的方式。

第三种模式是子 agent 和后台任务。主 agent 可以并行验证多个假设、运行多个实验，或把隔离子任务委派出去。父 agent 的角色像一个小型进程管理器：启动任务、查看日志、取消失败运行，再把结果合并回主线。关键不是“并发”本身，而是并发过程必须显式、可检查、可恢复。

Claude Code、Codex、OpenCode 和 Cursor 风格的 agent 已经逐渐收敛到类似接口：文件发现、文件读取、补丁修改、shell 执行、LSP、git、Web 搜索、MCP、后台进程和 agent 委派。这些工具组合起来，才让模型从“会说”变成“能做”。

优化对象从上下文走向Harness代码

Harness 优化有一条清晰递进：先是改提示词，再到结构化上下文，再到工作流设计，再到 Harness 代码，最后连优化器代码本身也能被优化。模型越强，能操作的对象就越复杂。

上下文工程是一个典型起点。Agentic Context Engineering（ACE）不再把所有响应和工具输出追加成一个越来越长的 prompt，而是维护一本结构化的“上下文手册”。生成器产生任务轨迹，反射器从成功和失败里提炼经验，策展器把这些经验增量写进日志。

[图3：Agentic Context Engineering 框架] ACE 把上下文当作不断演化的手册，而不是越来越长的提示词。

ACE 的弱点在于规则和整体流程仍然是手工设计的。Meta Context Engineering（MCE）再往前走一步，把“如何管理上下文”的机制和“上下文里有什么”的内容分开。机制被封装成 skill，里面包含静态组件，比如提示、知识库、代码库，也包含动态操作，比如搜索、选择、过滤和格式化。外层 agent 搜索更好的 skill，内层上下文工程师根据 rollout 反馈更新任务上下文。

[图4：Meta Context Engineering 框架] 元层面做 skill 进化，搜索上下文管理机制；基础层面优化具体任务上下文。

Meta-Harness 则把优化对象推到 Harness 代码本身。一个编码 agent 会读取已有 Harness 的执行历史，生成新的 Harness 候选，并在文件系统里保存源码、得分、rollout 轨迹和状态更新。表现足够好的候选被保留下来，进入下一轮搜索。

[图5：Meta-Harness 外层优化算法] 编码 agent 生成新的 Harness 候选，评估后保留 Pareto 前沿上的版本。

在 TerminalBench-2 的实验里，Meta-Harness 从 Terminus-KIRA 和 Terminus-2 这两个很强的 Harness 出发，仍能继续搜索出更好的变体。这里的重点不是某个技巧，而是设计空间变了：一旦 Harness 成为可执行、可评估、可修改的代码，模型就能进入原本人类工程师手工调系统的区域。

[图6：Meta-Harness 在文本分类和 TerminalBench-2 上的表现] TerminalBench-2 实验从 Terminus-KIRA 和 Terminus-2 两个强 Harness 初始化搜索。

工作流搜索能做什么，也不能做什么

工作流也可以成为搜索对象。AI Scientist 把自动科研拆成提出想法、写代码、跑实验、分析结果、写论文和同行评审。ScientistOne 把可验证性放在中心位置，要求每条引用、数字、方法和结论都能追溯到证据来源，并用 Chain-of-Evidence 做审计。

[图7：AI Scientist 自动化研究管线] 系统从想法生成、实验执行、论文写作到评审，串起自动科研流程。

Autodata 的角度更像“让 AI 当数据科学家”。它安排挑战者出题，弱求解器和强求解器答题，再由 verifier/judge 判断结果，目标是合成“刚好有难度”的训练和评估数据：弱模型解不出，强模型能解出。不过 Lilian Weng 也提醒，这条循环主要用合成任务微调弱求解器，不能迭代改进强求解器，因此更接近间接蒸馏，还不是完整 RSI 闭环。

[图8：Autodata 的 agentic 工作流设计] 通过 challenger、solver 和 verifier 角色，生成合成训练与评估数据。

ADAS 和 AFlow 则把 agent 工作流本身做成搜索问题。ADAS 让 meta-agent 观察已有 agent 设计，用代码生成新的工作流；AFlow 把工作流表示成图，用蒙特卡洛树搜索改进节点和边，在问答、编程和数学任务上，相比手工设计工作流和 ADAS 都有改进。

[图9：AFlow 在工作流候选树上的优化过程] AFlow 用搜索树表示工作流候选，并根据评估结果扩展和保留更好的方案。

这些结果说明，Harness 工程不只是“写一套更漂亮的流程”。当流程、上下文、工具和权限都能代码化，系统就有机会自动探索更大的设计空间。限制也很清楚：只有当候选方案能被快速、客观地评估时，搜索才比较高效；如果评估慢、模糊、依赖人类品味，自动化会明显吃力。

DGM把自我改进落到代码仓库

进化搜索适合搜索空间大、形状奇怪、难以用梯度优化但容易评估的任务。Harness 搜索正好符合这个特点。AlphaEvolve 把候选程序和 prompt 放进池子里，让固定 LLM 生成 diff，评估后保留成功子代。

[图10：AlphaEvolve 的工作方式] 系统保存候选程序池，由编码 agent 生成改进 diff，并通过评估保留更好的版本。

Darwin Gödel Machine（DGM）更贴近“自我改进 Harness”这个主题。它让一个基于 LLM 的 coding agent 修改自己的 Harness 代码仓库：先选一个父 agent，查看自己的 benchmark 评估日志，再用 bash 和 editor 工具改代码，生成新版本，评估通过的新 agent 回到池中。

在 Claude 3.5 Sonnet 作为固定底层模型、初始 Harness 配置较简单的实验里，DGM 搜索出的 agent 在 SWE-bench Verified 上从 20% 到 50%，在 Polyglot 上从 14.2% 到 30.7%，表现可与手工设计 agent 相比或超过它们。这里的数字不是模型权重更新带来的，而是 Harness 演化带来的。

[图11：AlphaEvolve 中多项设计的消融结果] 消融实验展示了演化流程、上下文、meta-prompt、完整文件演化和更强 LLM 的作用。

这也是这篇文章最值得关注的地方：自我改进未必一开始就表现为模型改神经网络参数，也可能先表现为 agent 改自己的运行方式、工具使用方式和评估循环。对工程实践来说，这条路更近，也更容易被现有软件系统承接。

评估器、memory和权限仍是硬边界

Lilian Weng 没把 Harness 工程写成万能钥匙。第一个瓶颈是评估器。编程题、单元测试、benchmark 容易给出分数，但研究直觉、新颖性和长期科学价值很难快速量化。自动科研系统可以写出看起来像论文的稿子，却仍可能有编造引用、实现偏移、实验结果弱的问题。

[图12：Self-Harness 使用弱点挖掘、有界 Harness 提案和验证循环来更新 Harness] Self-Harness 通过 propose-evaluate-accept 循环改进 Harness。

第二个瓶颈是长期 memory。文件系统能让 agent 保存状态，但它还不是人类那种贯穿长期工作的记忆能力。真正可靠的自我改进系统，需要知道哪些失败值得保留，哪些经验应该压缩，哪些旧规则该被淘汰。

第三个瓶颈是多样性和奖励黑客。进化和强化学习循环容易奔向已知高收益模式，如果没有刻意维持多样性的机制，种群会坍缩成同一解法的变体。奖励来自单元测试时，agent 可能过拟合测试；奖励来自裁判模型时，agent 可能学会讨好裁判，而不是解决真实问题。

[图13：SIA 中的 Feedback-Agent 决定下一轮迭代类型] Feedback-Agent 根据近期轨迹选择更新 Harness 还是更新模型权重。

最后是人的位置。Lilian Weng 的判断很务实：人不应该被移出循环，而是要上移到更高抽象层，负责目标、边界、权限和关键审查。尤其当系统被允许修改自己的 Harness 时，权限控制和安全层必须放在优化循环之外。

这篇长文真正想说的，不是“AI 已经可以自己进化”。更准确的说法是：近期更现实的自我改进，可能先从 Harness 工程开始。先让 agent 学会改进自己的上下文、工作流、工具调用和评估机制，再逐步接近更完整的 RSI。对关注 AI 工程化和 agent 系统的人来说，这比单纯讨论模型参数更务实，也更值得盯紧。