去年 11 月，Claude Code 的作者 Boris Cherny 提到把自己的 IDE 删了。一个月没打开过，干脆卸载。那一个月里他提了 259 个 PR，没一行代码是自己敲的。

        今年 6 月初，Boris 在 X 上发了一系列帖子，中心意思被很多人概括成一句话，"我不再给 Claude 写提示词了，是循环在跑，是它们在提示 Claude、自己琢磨该干什么。我的工作就是写循环。"

        几天后，OpenClaw 之父、如今在 OpenAI 的 Peter Steinberger 在 X 上跟了一句，别再给编程智能体写提示词了，你该去设计那些替你提示智能体的循环。

        Google 的 Addy Osmani 紧接着写了篇博客，给这套东西起了个名字，循环工程。

        但你先别给吓到，因为其实循环这个东西呢，只是 harness 的一部分。而且大家现在喊的“循环工程”，其实是在 harness 里找了一个特别的零件来喊。但他也只是零件，单个零件好不代表整车都造好了。

        所以我也想接着这个的机会和大家聊一件事，harness 到底是什么？

harness engineering 的由来

        首先 harness engineering（下面就全部简称 harness 了）这个词是 HashiCorp 的创始人 Mitchell Hashimoto 在今年 2 月提出来的。差不多同一个时间 OpenAI 也发了一篇同名文章。现在这个词在 AI 编程圈已经开始到处刷了。

        harness 的定义说得特别直白，模型外面的一切，都是 harness。

        工具、权限、反馈、护栏、验收、状态、重试、日志，全是。模型是引擎，harness 就是引擎外面的整辆车。方向盘、刹车、车道线、仪表盘、安全气囊，所以呢，我们能够控制模型行为的所有东西，加起来才是叫 harness。

        按这个定义，Claude Code、Codex、pi，这些 AI 编程工具本身就是 harness。它们给了模型读文件的权限，给了跑命令的工具，给了各种 hook 和护栏。这些全都是 harness。

        所以 harness 不是什么新概念要你去学，你早就在用了。你用 Claude Code 的时候，你就在用一套别人造好的 harness。

        那问题来了。既然 Claude Code 本身就是 harness，为什么大家还要喊"循环工程"呢？

        因为循环这个零件最爽。你给它一个目标，它就自己朝着目标一直跑，不用你按 enter。你睡觉的时候 agent 在跑，醒来看代码改好了，PR 提了，测试过了。这个体验太上头了。

        但 harness 里还有别的零件，没那么爽，却更重要。

我的探索

        去年 7 月有个程序员叫 Geoffrey Huntley，写了一行 bash，把同一个提示词反复喂给 Claude Code，让它自己一直跑。他起名叫 Ralph loop。当时一堆人都在挂这个跑夜班。

        但 Ralph loop 挂在 Claude Code 上有个很烦的问题，跑着跑着会断连。我想要的是睡觉的时候继续跑，结果半夜断了，醒来一看啥也没干成。

        我去试了 gsd，一个 spec-driven 的开发框架。也试了 superpowers，Jesse Vincent 做的那套 agentic skills 框架。都是好东西，但都没达到我要的。

        我自己也写了一套 Claude Code 的插件，叫 diwu-workflow。当时是想用强约束状态机管住 agent，PRD、架构决策、验收条件全部前置，还有个独立 verifier 角色专门验收，不让写代码的给自己打分。后来又重写了一版叫 diwu-flow，跨平台了，加了退化检测和连续执行。都是自己在用，但一直觉得不理想。

        后来 Codex 在 4 月底上线了 /goal 命令。agent 确实不会跑一下就停了，会朝着目标一直逼近。但 Codex 本身比较贵，自己开账号或者走中转站都很麻烦，没法日常跑。

        但不管用哪个工具，只要 agent 真的跑起来了，就会发现一个潜在的问题——

        它理解的目标，跟我给它的目标，根本不是一件事。它一直很认真地在帮我跑一个我不想要的活。而且因为跑的时间长了，越跑越远。

        我得全程盯着它。提醒它方向跑偏了，帮它重新对齐我到底要什么。

        虽然不是每一个任务都会这样，但是次数多了，那我还不如自己上手。

循环的三个坑

        Anthropic 自己点名过循环最容易栽的三个坑。

        让它做 50 项安全检查，它做了 20 项就说搞定了——偷懒。

        给自己的活打高分——自夸。

        跑了很多轮之后，你当初写的"别做某件事"，在第 47 轮悄悄消失了——漂移。

        偷懒是没人告诉 agent 什么算完。它自己说了算。缺的是一个能独立判定到底完成没有的信号，测试过没过、编译报错没报、行为对不对。这种信号有个名字叫 oracle。不能让 agent 自己给自己打分。

        自夸是写代码的和检查代码的是同一个 agent。它当然觉得自己写的是对的。得把制造和检查分开。有个技术博主 Gerald Chen 说了一句话挺直接的，sub-agent 比 prompt 重要 10 倍。

        漂移则是跑得越久，一开始的约束越容易被忘掉。

        这几个坑，都是 harness 的事。循环只管别停，不管偷不偷懒、自不自夸、漂不漂移。

        而且这几个坑里，漂移是最难受的。Claude Code 本身的系统提示词就非常臃肿，一大堆内置的约束和规则全塞在上下文里。在之前 200k 上下文的模型里，这个问题更突出。我自己写的约束，跟 Claude Code 内置的那一大堆东西挤在一起，跑着跑着就被挤掉了。系统上下文过多，偏移就越发明显。

        这就是我转到 pi 的原因。pi 的上下文干净得多，没有那么多内置的东西跟我的约束抢空间。转到 pi 之后，我为这件事造了个东西，叫 dgoal。核心就一件事，完成不自证。agent 说"我做完了"不算，要另开一个干净的子进程，只带读、查、跑命令这些受限工具，独立核验到底做完了没有，过不了就打回去重做。写代码的那个模型，不可能是检查代码的那个模型。

        dgoal 干的事就是还债。循环自己报"完成"，只是它自己的说法，不是真做对了的证明。Addy Osmani 把这个叫验证债。他还提了理解债，循环写的代码越堆越高，你真读懂的没跟上。还有认知投降，循环越跑越爽，你就越不想自己想。

        这三个债都没法靠循环自己还。验证债得靠独立子代理。理解债得靠你自己读代码。认知投降得靠你不退判断。

循环和约束

        讲到这里，harness 里有两种零件，一个管让 agent 别停下来，这是循环。一个管让 agent 别乱跑，这是约束。

        大家现在喊"写循环"，是在 harness 里挑了那个最爽的零件来喊。

        但没有约束的循环，不是自动化，是自动出错。agent 不停了，但它停在哪里、跑向哪、做的对不对，全都没人管。你睡觉的时候它在跑，醒来看代码改好了，但改的是你以为要改的那个东西吗？

harness 的不同实践

        造 harness 这件事，现在有很多不同的路子在走。

        有个叫 Pliny 的人，把 Fable 5 的系统提示词提取出来了。12 万字符，1585 行，72 个段落。他拿这副东西灌进一个原生模型里，同一个脑子，只差这 12 万字符，做出来的东西"完全是两个物种"。

        这个差别就是 harness 的差别。同样的模型，harness 不一样，产出完全不同。这 12 万字符是人手写的，一个字一个字填进去的。

        然后 OpenRouter 做了 Fusion，把一个问题并行分发给好几个模型，再让一个判定模型综合输出。这个分发和判定的流程也是 harness，还是人手写的，但已经是多模型协作了，比一个人填 12 万字符更复杂。

        再然后，日本的 Sakana AI 做了 Fugu，思路变了。他们用强化学习训了一个 7B 的小模型当协调器，让它自己学会调度一池 frontier 模型。该调谁、分几步、要不要验证，全是它自己决定的。后面有两篇 ICLR 2026 的论文撑着。

        Fugu 里那个 7B 协调器，它本身也是 harness 的一个零件。只不过这个零件不是人手写的了，是模型自己学出来的。

        所以不是 harness 在进化。harness 就是模型外面的一切，这个定义没变。变的是，harness 里的某些零件，开始能被模型自己学了。

        我去看 Fugu 的 demo，展示的全是二值任务。魔方解没解开、CAD 能不能转、盲棋下没下赢。都有标准答案，都能明确判定对错。这些任务有可学习的信号，做对了就是做对了，做错了就是做错了，模型能从里面学。

        但"该不该做"这件事，没有信号。一个任务值不值得做、该不该现在做、做完之后接下来做什么，这些东西没有标准答案，长在人的意图里。Fugu 能学会调度模型，但它学不会为什么要调度。

循环时代，你的判断力才重要

        Boris 传达了一个想法，"我不再写提示词了，我写循环"。这听着像人在退场。但看看他到底退了什么，他退的是一轮轮给 agent 派活、看回复、再按 enter 这个动作。他没退的是定目标、定边界、看 agent 到底做完了没、看它写的代码自己看不看得懂。

        Addy Osmani 说了一句挺实在的，worktree 解决了机械冲突，但真正决定能跑几个 agent 的，是你的上下文够不够。循环跑得越多，验证债、理解债、认知投降三个债就堆得越多，如果你的上下文窗口不够用了，再多的循环也是白搭，产出不是变成真正可用的内容，是变成灾难。还有句话更不好听，如果每个动作都要自己审一遍，那没有 agent，只是用更慢的方式做同一件事。

        循环替代的不是工程师，是那个一天按一百次 enter 的人。

        AI 接管了价值链中间那一截，写代码、跑测试、改 bug，这些都不用人了。但瓶颈没有消失，它上移了。以前瓶颈是怎么写，现在瓶颈是写什么。以前是会不会用工具，现在是你知不知道自己要什么。

        harness 里的零件能学了，循环能跑了，但有一件事始终学不了，就是判断一个任务值不值得做。Fugu 能学会调谁回答，但它学不会该不该问这个问题。这个判断没有 reward signal，长在人的意图里。

        所以循环时代真正稀缺的不是会用更多工具，是判断力。判断什么值得做，什么该尽早放弃，什么该交给循环，什么必须自己盯着。

        如果连判断也一起退了，循环带来的就不是杠杆，是前面说的认知投降。越跑越爽，越跑越不懂自己在跑什么，等真出事的时候，站在自己的代码面前，连一行都不敢删。

        所以回到开头那个问题，能不能让 agent 在我睡觉的时候继续干。

        我认为是能的，但循环替我按得了 enter，替不了我判断。