2026年玩AI必备技能：不是提示词，是循环工程

2026 年，会不会用 AI 不再看 Prompt（提示词）能力了，而是要看会不会设计循环。

上周，谷歌云 AI 总监 Addy Osmani 的一篇博客文章《Loop Engineering》引发了社区的讨论。

Addy Osmani 是一位在前端开发、Web 性能优化以及 AI 开发者工具领域都有影响力的工程师和技术领导者。他最广为人知的身份是曾任 Chrome 开发者体验团队的领导人。

他所讨论的「循环工程」概念有关设计代码智能体实行循环验证提升的方式。Addy Osmani 表示，就算是使用同样的大模型，会不会用这种思路，产生的结果将会完全不同。

让我们看看这篇文章是怎么说的：

「循环工程」（Loop engineering）指的是不再由你亲自向编程智能体（coding agent）发送指令，而是设计一套系统来自动执行这一过程。这里的「循环」可以理解为一种递归式目标：你设定一个意图，AI 则不断迭代直至任务完成。这一模式大致包含五个核心组件，而 Claude Code 和 Codex 目前都已具备了这全部五个要素。

我相信，这很可能就是我们未来与编程智能体协作的主流方式。不过，目前尚处于早期阶段，我对此持保留态度；此外，你必须格外关注 Token 成本问题（根据 Token 预算的充裕程度，使用模式可能会有天壤之别）。同时，如何确保代码质量不下滑也是个问题，人们对于产出低质量代码的担忧不无道理。话虽如此，让我们深入探讨一下这究竟是怎么一回事。

龙虾作者 Peter Steinberger 最近指出：「你不应再直接向编程智能体发送指令，而应设计能够自动向智能体发送指令的『循环』。」

Anthropic 旗下 Claude Code 的负责人 Boris Cherny 也表达了类似的观点：「我不再直接向 Claude 发送指令了。我运行着一些循环程序，由它们负责向 Claude 发送指令并决定下一步做什么。我的工作变成了编写这些循环程序。」

那么，这一切具体意味着什么呢？

过去大约两年里，利用编程智能体完成任务的方式通常是：编写高质量的提示词（prompt）并提供充足的上下文信息。你输入指令，查看反馈，再输入下一条指令。智能体就像一件工具，你始终握着它，进行着一轮又一轮的交互。那种模式某种程度上已经过时了 —— 至少许多人认为它即将成为过去式。

如今，你需要构建一个小系统来发现任务、分配任务、检查结果、记录进度并决定下一步行动；由这个系统去驱动智能体，而不是由你亲自动手。我之前写过关于「智能体支撑框架工程」（agent harness engineering）的内容 —— 即构建单个智能体运行的环境，以及「工厂模型」（即构建软件的系统）。「循环工程」则处于支撑框架之上：它基于定时器运行，能生成小型辅助程序，并能实现自我驱动。

令我惊讶的是，这已不再仅仅是关于「工具」的问题了。一年前，如果你想要实现这种循环，往往需要编写一大堆 Bash 脚本，并长期维护这堆代码 —— 那是完全属于你个人的东西。如今，这些组件已直接内置于产品之中。

Steinberger 提出的要素清单几乎完全对应于 Codex 应用，同时也基本适用于 Claude Code。一旦你发现两者的模式如出一辙，便无需再纠结于选择哪款工具；你只需设计一套工作闭环，无论身处哪个平台，这套流程都能顺畅运行。

五大要素及相关说明

一个完整的工作闭环需要五个要素，外加一个用于存储信息的载体：

1. 按预定计划自动运行，并能自主进行任务发现与分拣的自动化机制。
2. 支持多工作树（worktrees）机制，能确保并行工作的智能体互不干扰。
3. 用于记录项目知识的 skill 模块，避免智能体在缺乏信息时只能靠「猜」来行事。
4. 插件与连接器，用于将智能体接入你现有的工具链中。
5. 子智能体机制，实现由一个智能体构思方案，而由另一个进行验证的协作模式。

最后是第六个要素：记忆存储。这可以是一个 Markdown 文件、一块 Linear 看板，或是任何独立于单次对话之外、用于记录已完成工作及后续计划的载体。这听起来似乎微不足道，但这正是所有长期运行的智能体所依赖的关键机制 —— 正如我在探讨「长期运行智能体」时所分析的，模型在两次运行之间会遗忘所有信息，因此记忆必须存储在磁盘上，而不能仅依赖上下文（context）。智能体会遗忘，但代码仓库（repo）会保留记录。

如今，Claude Code 与 Codex 已具备了上述全部五个要素。

虽然各处的命名略有差异，但核心功能是一样的。让我们逐一探讨，因为说实话，细节往往决定了一个循环（loop）是能稳健运行，还是会悄无声息地出现各种问题。

自动化（Automations）

核心驱动力

正是自动化让「循环」名副其实，使其不仅仅是一次性的单次运行。在 Codex 应用中，你可以在「自动化」标签页创建一个任务，指定项目、要运行的提示词、执行频率，以及是在本地检出（local checkout）的代码上运行，还是在后台工作树（background worktree）上运行。发现问题的运行结果会进入「分类收件箱」（Triage inbox），而未发现问题的运行则会自动归档 —— 这非常方便。OpenAI 内部利用它来处理一些枯燥琐碎的任务，比如每日问题分类、总结 CI 失败情况、撰写提交摘要，或是查找上周有人引入的 Bug。

此外，自动化任务还可以调用 skill，从而保证重复性任务的可维护性：你只需触发 $skill-name，而无需将一大段冗长的指令硬塞进一个没人会去更新的调度配置里。

Claude Code 实现了同样的目标，但采用的是调度（scheduling）和 hooks 机制。你可以使用 /loop 按固定间隔运行提示词或命令，可以设置 cron 任务，可以通过钩子在智能体生命周期的特定节点触发 Shell 命令，或者将其推送到 GitHub Actions，以便在你合上笔记本电脑后任务仍能继续运行。理念完全一致：定义一个自主任务，设定执行节奏，让结果自动反馈给你，而无需你亲自四处检查。

还有一个值得了解的会话内原语（primitive），它更贴近本文的主题。/loop 是按节奏重复运行的；而 /goal 则会持续运行，直到满足你设定的条件为止。在每一轮运行结束后，会有一个独立的小型模型来检查任务是否完成，这意味着编写代码的智能体并不负责评估结果。你只需设定类似「test/auth 目录下的所有测试通过且代码检查（lint）无误」这样的目标，然后就可以去做别的事了。

Codex 也有同样的功能，同样称为 /goal：它跨轮次持续工作，直到满足可验证的停止条件，并支持暂停、恢复和清除操作。同样的机制，同样的工具 —— 这正是贯穿整篇文章的模式。

这就是将工作成果呈现出来的环节。循环的其余部分负责对它进行操作。

Worktree（工作树）

避免并行操作引发混乱

一旦运行多个智能体，文件冲突就会导致失败。两个智能体写入同一个文件，就像两个工程师在未沟通的情况下修改同一行代码一样令人头疼。Git Worktree 解决了这个问题：它是在同一仓库历史基础上、位于独立分支上的独立工作目录，因此一个智能体的修改绝对不会影响另一个智能体的检出（checkout）内容。

Codex 内置了对 Worktree 的支持，允许多个线程同时访问同一个仓库而互不干扰。Claude Code 也通过 Git Worktree 提供了同样的隔离机制：使用 –worktree 标志可以在独立检出环境中开启会话，或者在子智能体上设置 isolation: worktree，让每个辅助智能体获得一个全新的检出环境，并在任务结束后自动清理。我在「编排成本」（orchestration tax）一文中探讨了其中的人为因素：Worktree 解决了机械性的冲突问题，但人依然是瓶颈所在 —— 决定你能实际运行多少个智能体的是你的代码审查能力，而不是工具本身。

Skills

无需每次都重新解释项目

「技能」机制能让你摆脱那种像金鱼一样、在每次会话中都要反复解释项目背景的困境。这两种工具采用相同的格式：一个包含 SKILL.md 文件的文件夹（其中存有指令和元数据），以及可选的脚本、参考资料和资源文件。Codex 会在用户通过 $ 或 /skills 调用时，或者当任务与技能描述匹配时自动运行该技能 —— 这正是精准、平实的描述要优于花哨描述的原因。Claude Code 的运作方式也如出一辙，我在「智能体技能」一文中详细阐述了这一模式。

「技能」也是解决「意图成本」反复消耗问题的关键。智能体每次会话都是从零开始的，它会自信地填补你意图中的任何空白。而「skill」就是将这些意图（如约定俗成的规范、构建步骤、诸如「因为某次事故所以我们不这么做」之类的经验教训）显式地记录下来；只需编写一次，智能体每次运行时都会读取。如果没有技能，循环会在每个周期从零开始重新推导整个项目；有了技能，知识积累就能产生叠加效应。首先要明确一点：Skill 指的是创作格式，而 Plugin 则是交付它的方式。当你需要在不同代码仓库间共享 Skill，或者将多个 Skill 组合在一起时，就可以把它们打包成 Plugin。这一逻辑在 Codex 和 Claude Code 中均适用。

Plugins 与 Connector

让「循环」能够与你的实际工具交互

如果一个「循环」只能访问文件系统，那它的能力将非常有限。基于 MCP 构建的连接器（Connectors）则打破了这一局限，让智能体能够读取 Issue 追踪系统、查询数据库、调用预发布环境（staging）的 API，甚至在 Slack 上发送消息。由于 Codex 和 Claude Code 都支持 MCP 标准，因此你为其中一个编写的连接器，通常也能直接在另一个中运行。此外，插件将连接器和 Skill 整合在一起，方便你的团队成员一键安装并使用整套配置。

而不是完全凭记忆从头重建。

这就是「只会说『修复方案如下』的智能体」与「能自动提交 PR、关联 Linear 工单并在 CI 通过后在频道通知的循环」之间的区别。正是因为有了连接器，循环才能在你的实际环境中采取行动，而不只是空谈它「如果能操作的话」会做什么。

子智能体

将「执行者」与「检查者」分离

在循环机制中，最有用的结构性设计莫过于将编写代码的角色与检查代码的角色分离开来。负责写代码的模型在评估自己的「作业」时往往过于宽容；而另一个拥有不同指令（有时甚至使用不同模型）的智能体，则能发现第一个智能体因自我合理化而忽略的问题。

Codex 仅在你明确要求时才会启动子智能体，让它们并行运行，最后将结果汇总为一个答案。你可以通过 .codex/agents/ 目录下的 TOML 文件定义自己的智能体，每个智能体包含名称、描述、指令以及可选的模型和推理强度设置；这样，你的安全审查员可以是高推理强度的强大模型，而负责探索任务的智能体则可以是快速、只读的轻量级模型。Claude Code 也有类似机制，利用 .claude/agents/ 中的子智能体和智能体团队在彼此间传递任务。在这两种工具中，常见的角色分工通常是：一个负责探索，一个负责实现，另一个根据规范进行验证。

我之前曾两次阐述过这一理念：一次是将其称为「代码智能体编排（orchestra）」，另一次则称之为「对抗式代码审查」。之所以在循环机制中这一点尤为重要，是因为循环是在你无人值守的情况下运行的；只有拥有一个你真正信任的验证者，你才能放心地离开。子智能体确实会消耗更多 Token（因为每个智能体都要独立进行模型调用和工具操作），因此应将资源投入到那些值得获取「第二意见」的环节中。这其实也是 Claude Code 的 /goal 命令在底层运作的原理：由一个全新的模型（而非执行任务的那个模型）来判断循环是否结束 —— 即将「执行者」与「检查者」分离的原则应用到了终止条件的判定上。

一个循环的典型形态

将这些组件组合起来，单一的执行流就变成了一个小型控制面板。以下是我经常采用的一种模式。

针对代码仓库，每天早上运行一次自动化任务。它的提示词（prompt）会调用一个「分诊」技能（triage skill），该技能读取昨天的 CI 失败记录、未解决的问题（open issues）和最近的代码提交，并将分析结果写入 Markdown 文件或 Linear 看板中。对于每一项值得处理的问题，流程会创建一个独立的工作树（worktree），并派遣一个子智能体（sub-agent）起草修复方案，随后由第二个子智能体根据项目的既有技能和现有测试用例对该草案进行审查。

通过连接器（connectors），该循环能够自动创建 PR 并更新工单状态。凡是循环无法处理的事项，都会进入「分诊收件箱」等待我亲自处理。状态文件是整个系统的核心，它记录了已尝试的操作、已通过的任务以及未完成的工作，确保明早的运行能从今天中断的地方继续进行。

回想一下你实际做了什么：你只进行了一次设计，而无需针对后续的每一步骤单独下达指令。这正是 Steinberger 观点的具体实现；无论是在 Codex 还是 Claude Code 中，其循环逻辑都是一样的，因为底层的组件是相同的。

循环仍然无法代劳的事项

循环改变了工作方式，但并未将你从工作中剔除。事实上，随着循环能力的提升，有三个问题反而会变得更加棘手，而非变得简单。

验证工作依然由你负责。一个无人值守运行的循环，也可能在无人监督的情况下犯错。将验证子智能体与执行子智能体分离开来，其目的正是为了赋予循环所宣称的「已完成」状态以实质意义 —— 即便如此，「已完成」也只是一种声明，而非确凿的证明。有句适用于 AI 时代代码审查的话：你的职责是交付那些经你确认可正常运行的代码。

如果你疏于维护，你对代码的理解就会逐渐退化。循环交付非你亲手编写代码的速度越快，现有代码与你实际掌握情况之间的鸿沟就越大。这就是「理解债务」（comprehension debt）；除非你亲自阅读循环生成的代码，否则高效的循环只会让这种债务积累得更快。

没错，那种看似舒适的状态往往伴随着风险。当循环自动运行时，人很容易放弃独立思考，转而全盘接受它给出的结果。我称之为「认知投降」（cognitive surrender）。设计循环时，若能保持判断力，它便是良方；若仅仅为了逃避思考而设计，它便成了加速恶化的催化剂 —— 同样的动作，结果却截然不同。

构建循环，坚守工程师本色。我认为这预示了我们工作方式的演变方向。话虽如此，如果我不亲自审查代码，或者完全依赖自动化循环来修复问题，产品的质量就会受损。我恐怕会陷入恶性循环，越陷越深。

当然，你可以着手构建这些循环，但别忘了，直接向智能体下达指令依然行之有效。关键在于找到合适的平衡点。

同样的循环机制，因使用者不同，结果也可能截然不同。两个人构建完全相同的循环，可能会得出完全相反的结论：一个人利用它来加速处理自己深刻理解的工作，而另一个人则利用它来彻底回避对工作的理解。循环本身无法区分这两者，但你能。

正因如此，设计循环比编写提示词更具挑战性。

这是工程工作，并未变得更轻松。并非工作本身变简单了，而是关键的杠杆点发生了转移。

去构建这个循环吧。但构建时，要怀着一种「立志深耕工程领域」的心态，而不仅仅是做一个只会按下启动键的人。

参考内容：

https://x.com/addyosmani/status/2064127981161959567

文章来自于”机器之心”，作者 “泽南”。