OpenClaw之父说:闭环定胜负

他的原话是这样的：agent 写代码好不好，不在于模型本身有多聪明，在于你有没有给它一个能自我验证的闭环。代码这种东西，能编译、能跑测试、能验证输出，错了模型自己能发现、自己改。创意写作不行，因为没有验证回路，所以模型写代码比写创意文本好得多。

这个判断反过来意思很大。你在纠结「这个模型够不够强」的时候，问题可能根本不在模型，在你没给它闭环。他自己的体感是，Claude Code 快但经常要返工，Codex 慢却几乎一次就能成。要注意这是他在自己工作流里的判断，他 2 月加入了 OpenAI，评自家的 Codex 带立场，而且哪个为什么更适合他，下一篇会细讲。这篇要讲的是后一半：Codex 一次成，一部分靠它自己会先沉默读很多文件，另一部分靠他给它搭的闭环，而闭环是工程师能控制的。

闭环这件事，最容易理解错的一点是：很多人以为闭环是「我帮 agent 检查代码」。他不是这个意思。

他举了个例子。他做一个 Mac 应用，发现一个 bug，Mac 应用里找不到远程网关，但同一段代码在 TypeScript 里能跑。Mac 应用难调试，因为要先编译、再启动、再看。一般人的做法是自己上手调。

他的做法是让 agent 给自己建一个调试用的命令行工具，调用一模一样的代码路径。因为命令行快，agent 自己能一遍遍跑、一遍遍改，跑了一个小时，自己修好了，回来告诉他「这里有个竞态条件、那里有个配置错」。他说，我不需要看那段代码。

更深一层。他发现某个 harness 的工具调用格式有问题，花了很久才意识到该怎么解。他直接让 Codex 设计一套测试：起一个干净的 Docker 容器，装上整个系统，跑一个循环，用他真实的 API key，让模型读一张图、生成一张图、再自己看这张图对不对。他说，它把我所有 API key 的边界情况都测了一遍，从 Anthropic 到 GLM，全修了，因为我把闭环合上了。

核心动作不是「我 debug agent」，是「我给 agent 搭一个它能自己 debug 自己的环境」。

闭环合上之后，他发现 agent 有一个毛病：它会过度防御。

他跑自动审查的时候，agent 会找出一堆「看起来真」但其实在生产里永远不会发生的边界情况，然后为这些不存在的情况写大量防御代码，把 codebase 搞脏。

解法不是让它别这么写，是把项目的不变量明确写进指令里。比如「运行时不会有人编辑插件文件」，告诉它，它就不为这个写兜底了。

他还有一条更反直觉的经验：给 agent 写的指令文件，不要你自己写，让 agent 用自己的话写，然后定期问它「你自己的指令文件哪里自相矛盾」。他说，你不知道 agent 是怎么读 agent 的指令的，它自己写给自己最准。这件事是反过来的：几千年都是人给工具写规则，现在是工具给自己写规则、还比人写得准。

这些都是在做同一件事：不是教 agent 写代码，是给 agent 立一个它能稳定运作的规矩。他靠的几条：

• 把不变量写进指令（比如「运行时不会有人编辑插件文件」），否则 agent 按最坏情况写一堆防御代码
• 指令文件让 agent 自己写、自己查歧义，定期问它「你的指令哪里自相矛盾」
• 测试必须在干净机器上跑（他叫 Crap Box），因为你自己机器被历史配置污染了，跑通不代表别人能跑通

判断闭环有没有合上，他有一个很反直觉的指标：并发数。

模型变快的时候，他把同时跑的 agent 会话从 10 个拉到 56 个。但当他在闭环里又加了端到端测试和自动审查之后，并发数主动降回了 30。原因是单次更慢了，但信任度高了，他「只在最初讨论需求时需要专注一次」。

开得多不一定代表强。开得多可能只是说明你的闭环没合上，每个都不放心，只好同时开一堆对冲。这么看，圈子里那种「我同时开 50 个 agent」的炫耀，不是实力的展示，恰恰是闭环没搭好的露怯。真正闭环搭好的人，不需要开那么多，因为每一个他都信得过。

先说清这里说的 harness 是什么：它指 agent 周围那一整套，工具链、测试设施、审查流程、重试管道。模型是大脑，harness 是大脑周围的工作环境。

把闭环这个逻辑推到极致，会得到一个让模型厂商不太舒服的结论：harness 比模型重要。

他的原话：如果 harness 是垃圾，最好的模型也救不了你多少。但如果你给 harness 配上强大的能力（computer use 只是最新的一个），那即使是三个月前的旧模型也会好得多，因为你把从 prompt 到验证到重试的整条管道都拉通了。

旧模型加强 harness，可以打赢新模型加烂 harness。

这句话和整个 AI 行业的做法是正面对冲的。所有大厂都在拼模型代差、拼参数、拼基准测试分数，他说代差不重要、harness 才重要。而他自己就是 OpenAI 的人，等于在说别太迷信自家公司追的模型代差。推论也很有意思：如果 harness 比模型重要，那拼不起模型的小团队，可以去拼 harness，旧模型配强 harness 照样能赢。

闭环这个理念落地，是一堆具体工具。他挑了两个最值得讲的。

一个叫 auto-review。他用 Codex 的时候发现一个问题：审查一次只能找到一部分毛病，修完再审查又冒出新的，他试过一天审查十轮。解法出乎意料地简单，不需要改 harness，不需要 fork 任何东西，只在指令文件里加一行：「提交前如果没跑过自动审查，就跑一遍」。agent 就会自己一遍遍调 Codex，每次开新上下文，直到没有新发现为止。他说，agent 这四五个月已经非常擅长听指令了。（这是他 agent.md 里的个人配置；OpenClaw repo 里还有个同名的 exec auto-reviewer，但那个是审「命令该不该跑」，不是审代码，别搞混。）

更有画面感的一个叫 Mantis，开源在 OpenClaw 的 qa-lab 扩展里。它的活比「录视频」重得多。在一个 PR 上 @ 它，它会拉起一台干净的 Linux 测试机（他叫 Crabbox，带 VNC），把 PR 改之前和改之后两个版本，分别在真实的 Discord、Slack、Telegram 通道里跑一遍，录下两边的结果，用视觉模型对比，然后把证据存到 Cloudflare R2，在 PR 里发一条评论说明。维护者只需要看一眼对比，点合并。

它先在 Discord 上做通（真实 bot 登录、频道、表情、话题、一个浏览器当目击者），Slack 和 Telegram 也有，WhatsApp 和 Matrix 还没做。行业里谈视觉验证还在论文阶段，他把整条链路跑通了，而且代码就在 repo 里。

工程师的新工作不是写代码，是搭闭环。代码几乎免费了，稀缺的是那个能让 agent 自己验证自己、自己改自己的环境。

这一条体会，是他在 16 场演讲里反复回到的起点。下一篇，我们讲他在一线怎么评判和选择模型，以及为什么他说整个 prompt engineering 领域已经过时了。

（本系列第四篇：他怎么评判模型。）

参考（Steinberger 公开演讲，YouTube）：

• 2026-01-28 Pragmatic Engineer 访谈：https://youtu.be/8lF7HmQ_RgY
• 2026-06-02 Microsoft Build：https://youtu.be/o5IQMijn-Ks
• 2026-06-03 OpenClaw After Hours at GitHub：https://youtu.be/K-pnIgkDxSc
• 2026-07-01 Warp panel：https://youtu.be/Kl8ha1IkjrY

交流群

和我们一起探索

扫码加入