内容
别再直接向 AI 代理下提示词了。要设计的是那些给它们发提示的循环！
Anthropic 的 Claude Code 负责人 Boris Cherny 说得很直接：“我不再直接提示 Claude 了。我在运行一些循环，由这些循环去提示 Claude 并判断下一步该做什么。我的工作就是编写这些循环。”
AI 编码代理一直以来的工作流都差不多：写一个提示词，读输出，再提示一次让它继续。整个过程里，你始终在手动操控代理，一轮接一轮。
问题在于，你才是瓶颈。每一步都依赖你出现、阅读结果，并决定下一步发生什么。整个系统只能以你坐在那儿执行的速度前进。
循环工程就是为了改变这一点。Claude Code 负责人 Boris Cherny 直接描述了这种转变：他不再亲自提示 Claude，而是运行循环，由循环来提示并判断下一步怎么做。他的工作是编写这些循环。
OpenClaw 的创建者 Peter Steinberger 也独立表达了同样的观点：不要再提示你的编码代理，而是开始设计能够替你提示它的循环。
那么，循环工程在实践中到底是什么意思？
它是如何运作的
循环工程的核心，是用系统替代你来完成“提示代理”的工作。你不再手动管理每一轮，而是构建一个小型系统：它先找到工作，把工作交给代理，检查返回结果，然后决定下一步，直到目标达成。
不过，在动手搭建之前，先弄清楚一个循环到底由什么组成会更有帮助。一个循环由五个组件和一层记忆构成。它们单独看都不复杂，真正的价值来自它们协同运作。
五个基础构件
每个构件都承担着特定角色。漏掉任何一个，循环就会失效，或者你最终还是得自己补上那个空缺。
- 自动化
自动化让循环能够自行运行。你给它一个提示词、一个项目和一个时间表：每天早上、每小时，或任何合适的频率。它会运行，找到需要处理的内容，并把它呈现出来。没有发现问题的运行会自动归档；发现问题的运行会来找你。
更重要的是循环如何判断自己已经完成。例如在 Claude Code 中，/goal 会持续运行，直到你定义的条件真正为真，并且每一轮后都有一个更小的模型进行检查。
真正执行工作的代理，并不是决定何时停止的那个。你写下类似“持续运行，直到这个文件夹里的所有测试都通过且 linter 通过”为止，然后就可以离开。你自动化的，本质上是对“工作是否完成”的判断，而不只是工作本身。
- 工作树
一旦同时运行多个代理，它们就会开始冲突。两个代理同时写同一个文件，本质上和两个工程师在没有沟通的情况下同时提交同一段代码是同一个问题。
git worktree 会为每个代理提供自己独立的工作目录和分支，同时共享同一个仓库历史。一个代理的改动不会影响另一个代理的文件。冲突只会在合并时暴露出来，由标准的 git 工具来捕捉，而不是在实际工作过程中悄无声息地发生。
- 技能
每次会话开始时，代理都是“冷启动”的。它不知道你的规范、构建步骤，也不知道你们团队上个月做过什么决定。遇到缺口时，它只能猜。
技能（skill）就是一个包含 SKILL.md 文件的文件夹。它把你的项目知识保存在代理每次运行都会读取的地方。写一次就够了。代理不再猜测，而是基于你项目中真实有效的信息来工作。
- 插件与连接器
只能看到文件系统的循环，自己做不了多少事。基于 MCP 构建的连接器，能让代理接触到你真正开展工作的工具：问题跟踪系统、数据库、测试环境 API、Slack。
能把修复方案交给你，和能自动打开 PR、关联工单并在团队频道发消息的循环之间，差别就在于连接器。没有它们，代理只能描述它会做什么，却无法完成它已经开始的事情。
- 子代理
循环中最重要的结构决策，是把“执行工作”的代理和“检查工作”的代理分开。模型自己评估自己的输出时，往往会过于宽松，并在真正完成之前就说“完成了”。
第二个代理会被赋予不同的指令，有时甚至用不同的模型，它的任务是假定工作是有问题的，并找出问题所在。在 Claude Code 中，/goal 也把同样的逻辑应用到停止条件上。由独立模型来判断循环是否结束，这样执行工作的代理就不能自己给自己宣布通过。
而把这一切串起来的，是记忆。
没有记忆的循环，每次运行都会完全重置。模型会在上下文窗口关闭后忘掉一切，因此下一次运行完全不知道上一次尝试了什么、哪些已经通过、还有哪些未完成。
在仓库里放一个 Markdown 文件、一个 Linear 看板、一个并排的 JSON 文件，任何位于对话之外、能保存当前状态的东西，都能解决这个问题。下一次运行开始时读取它，就能接着上一次继续。
一个循环长什么样
假设你希望每天早上醒来时，就能清楚知道昨晚出了什么问题，而且修复方案已经起草好，PR 也已经准备好供你审阅。下面就是这样一个循环在五个基础构件连接起来之后的样子。
早上 7 点，一个自动化任务在你的仓库上触发，并启动以下流程：
- 一个技能读取昨天失败的测试、未关闭的问题和最近的提交
- 结果被写入一个记忆文件
- 对于每个值得处理的问题，循环都会打开一个独立的工作树，让各个代理并行工作而不互相碰到对方的文件
- 一个子代理为每个问题起草修复方案
- 第二个子代理根据你的项目技能和现有测试审查每个草案
- 如果修复通过，连接器会自动打开 Pull Request 并更新关联工单
- 任何过于模糊、无法处理的内容都会被标记出来，留在你的收件箱里
等你坐下来时，杂务已经处理完了。你在审阅，而不是在分流。
记忆文件会记录尝试过什么、哪些通过了、还有哪些未完成。第二天早上，循环会精准地从上次停下的地方继续。
你只设计了一次这个系统。之后的每一步都无需你参与。
从哪里开始
目前做循环工程的两个主要工具是 Claude Code 和 OpenAI Codex。两者都提供了这五个基础构件。如果你已经在用 Claude Code，那么今天就已经具备搭建第一个循环所需的一切。
先从一个你已经会反复用代理处理的任务开始：每天的分诊、夜间测试运行、定期代码审查。选择一个风险较低的任务，这样循环即便出错，也不会造成严重影响。
下面是一个实用的第一个循环配置：
- 在仓库中创建
.claude/skills/文件夹，并添加一个SKILL.md文件，写入你的项目规范：测试如何运行、命名规则，以及任何代理本来可能会猜错的内容 - 在根目录创建一个
progress.md文件。这就是你的记忆文件。每次运行都应在开始时读取它，并在结束时更新它 - 在 Claude Code 中运行
/goal "review open issues, identify the top three worth fixing, and write your findings to progress.md"。这就是你的第一个循环：一个目标明确且停止条件可验证的流程 - 一旦你熟悉了这一点，就用
/loop按计划运行它，让它自动触发，而不必你亲自启动
在规模扩大之前，还有几点需要记住。先从只读开始。先让循环运行几次，做摘要和汇报，再赋予它打开 PR 或更新工单的权限。在让任何无人值守的运行开始前，先设置 token 预算。只要循环会碰到生产代码，就要加入一个验证子代理。
直接提示词仍然有效，也仍然有它的用武之地。循环不是它的替代品。它更适合那些重复性的、并行的，或者需要在你不在场时运行的工作。
容易出问题的地方
循环会改变你的工作方式，但不会把你从图景中移除。开始运行之后，一些问题往往会暴露出来。
- 无人值守的错误。一个不受你直接监督的循环，也是在无人监督下犯错。把验证者和执行者分开，能让循环的判断更可信，但“完成”仍然只是一个声明，不是证明。最终交付什么，责任仍在你。
- 理解债务。循环写代码越快，而这些代码又不是你自己写的，你对代码库里真实存在的内容与自己实际理解之间的差距就会越大。如果放任不管，这个差距会迅速扩大。
- token 成本。无人值守的循环也会消耗无人值守的 token。停止条件紧、目标清晰的循环通常很便宜，因为它会很快结束。目标模糊、标准松散的循环可能会跑上几个小时，而你却毫不知情。在离开之前先设定预算上限。
- 把循环设计成逃避思考。两个开发者可以构建完全相同的循环，却得到截然不同的结果。一个用它来更快推进自己真正理解的工作；另一个则用它来逃避理解工作本身。循环无法分辨这两者。你可以。
最后想法
直接提示词仍然有效，也仍然有它的位置。循环工程不是替代它，而是把重心转移了。
设计一个你真正能够信任、能够在你不在场时运行的循环，本质上是系统工程问题，而不是写作问题。它提高了你能完成事情的上限，也提高了你对以自己名义运行的内容所承担的责任。