AI 自我进化，先改的可能不是模型，而是 Harness

AI 自我进化，先改的可能不是模型，而是 Harness

最近 Lilian Weng 写了一篇很长的文章，叫《Harness Engineering for Self-Improvement》。28 分钟阅读量，里面串了不少 2025 到 2026 年的研究。

我读完后，第一个反应是：我们可能太习惯盯着模型排行榜了。

模型当然重要。但一个 Agent 最后能不能把事情做完，还取决于它怎么拿上下文、怎么调工具、把状态放在哪里、出了错会不会回退，以及谁有权判定它真的完成了。

这些东西合在一起，就是 Harness。

我的判断很明确：AI 自我进化的近期入口，大概率先出现在模型外面。先改工作流，再改工作流的改法。至于模型自己重写权重，那是更后面的事。

唐斩角色正在为模型装配 Harness 运行系统

为模型装配 Harness 运行系统

1. Harness 不是外壳，它更像 Agent 的运行系统

Lilian Weng 给的定义很完整：Harness 围绕基础模型工作，决定模型怎么规划、怎么调用工具、怎么感知和管理上下文、怎么保存产物，以及怎么检查结果。

这也解释了一个很常见的体验：同一个模型，放在不同产品里，能力表现会差很多。

差别可能来自工具接口，也可能来自上下文压缩、文件权限、任务循环和验证方式。我们以为自己在比较模型，很多时候其实在比较“模型加 Harness”这套组合。

早期 Agent 框架喜欢写成一个公式：LLM 加记忆、工具、规划和行动。现在这还不够。工作流、评估、权限和持久状态也得算进去。它已经很接近软件系统设计，而不是一组 Prompt 技巧。

2. 长任务的关键，是别把所有东西都塞进上下文

文章里有三个设计模式，我觉得最值得程序员马上拿来用。

第一个是循环。

让 Agent 按“计划、执行、观察或测试、改进、再执行”推进，直到达到目标。重点不在流程图画得多漂亮，而在每一轮都有可观察结果，下一轮知道该改什么。

唐斩角色把溢出的上下文整理成可持续读取的文件状态

把溢出的上下文整理成可持续读取的文件状态

第二个是文件系统。

长任务会不断产生实验日志、代码差异、错误轨迹、论文摘要和中间产物。全部塞进对话，早晚会把上下文撑爆。把这些状态写进文件，需要时再读，反而更稳。

这点我很认同。文件不只是存档，它是 Agent 可以持续接手的工作现场。会话断了，状态还在；换一个 Agent，也能从产物和日志继续干。

第三个是子 Agent 和后台任务。

并行本身不难，难的是可见。谁在跑、跑到哪、为什么失败、最后留下了什么，都要能检查。子 Agent 的结果如果只留在一次聊天里，多开几个反而更乱。

所以多 Agent 的价值，不是数量，而是并行之后还能合并、恢复和追责。

3. 自我改进，不是把同一道题再答一遍

Lilian Weng 在文章里给出一条很有意思的演进路径：Prompt，结构化上下文，工作流，Harness 代码，最后到优化器代码。

越往后，系统改的越不是某个答案，而是“以后怎么产生答案”。

唐斩角色用保留集和未见集校验 Harness 修改

用保留集和未见集校验 Harness 修改

Self-Harness 的做法很典型。它先从失败轨迹里找反复出现的问题，再提出范围受限的修改，最后用测试决定接不接受。

这里有两个细节很重要。

一是修改面要有限。系统不能想改哪里就改哪里。

二是既要看这次暴露出来的问题有没有解决，也要看没参与修改的任务有没有退步。通过了，修改才进入下一版；没通过，记录下来并回退。

这才像工程。一个“会自我改进”的 Agent，首先应该会承认这次修改没用。

唐斩角色把评估、权限、回归测试和人工复核固定在自改进循环之外

把评估、权限、回归测试和人工复核固定在自改进循环之外

4. 最危险的做法，是让它连裁判一起改

自改进听起来很兴奋，落到工程里却有一个朴素问题：谁来判断它真的变好了？

如果答案是“它自己”，麻烦就来了。

测试可能太窄，Judge 模型可能有偏好，Benchmark 也可能被钻空子。系统会优化你给它的信号，但不保证那个信号等于你真正想要的结果。

原文把评估器和权限控制放在自改进循环之外，我赞同这个边界。保留集、未见集、轨迹审计和关键节点的人工复核，都不该被改进器随手重写。

还有长期问题。一个 Coding Agent 今天把任务做完，不代表它没有给仓库埋下迁移成本、兼容性问题和未来调试负担。短期通过测试，和半年后仍然好维护，中间隔着一大段工程判断。

Lilian Weng 引用的一组自动研究尝试也很说明问题：四个被选中的想法，最后只有一个完整执行成论文。能生成一篇像样的论文，和真的完成科学发现，不是一回事。

5. 程序员现在就能做的五件事

不需要等一个“全自动进化 Agent”发布，今天就能开始改自己的 Harness。

先选一个结果容易验证的任务

例如构建是否通过、测试是否全绿、页面关键字段是否存在、数据转换前后是否一致。评价越模糊，自改进越容易变成自我感觉良好。

把循环写清楚

至少有计划、执行、测试、修正和停止条件。没有停止条件的循环，往往只是持续消耗时间和 Token。

把状态留在文件里

任务清单、失败原因、实验记录、代码差异、产物路径和回退点都落盘。不要指望下一次会话自动记得一切。

允许它只改一小块

先开放 Prompt、上下文选择规则或某个工作流节点，不要一开始就让 Agent 重写整个运行环境。可编辑面越小，失败越容易定位。

把裁判和高权限动作留在环外

验证器、权限边界、保留测试和关键人工确认，应该比自改进循环更稳定。它们负责说“不”。

6. 我的选择：先把 Harness 做稳，再谈自我进化

我会推荐做 AI 编程、Agent 产品、内部自动化和一人公司工作流的人读这篇文章。

它最有价值的地方，不是告诉我们 AI 已经会自己升级了。它给了一个更现实的方向：把 Agent 外面的系统做成代码，留下状态，记录失败，用评估决定改动是否生效。

当这套系统能被观察、测试和回退之后，自我改进才不是一句口号。

如果你现在正用 Codex、Claude Code 或其他 Coding Agent，下一步可以先做一件小事：选一个每周都会重复的任务，把它改造成有文件状态、有验证器、有停止条件的循环。

先让 Harness 能稳定变好。模型的下一次升级来了，你也接得住。

原文：Harness Engineering for Self-Improvement