简短回答
Loop engineering 是设计一套替你向编码智能体下指令的系统，让你不再是那个敲下一条提示的人。这套系统发现工作、分派任务、检查结果、写下已完成的事项，并决定下一步。Addy Osmani 在 2026 年 6 月的文章让这个词在编码智能体圈子里流行起来，他说这些构件现在已经内置在产品里：定时自动化、worktree、skills、connectors 和 subagents，再加一个记住状态的文件。Claude Code 与 Codex 都文档化了其中大部分。
我们读过的每个来源都有三点提醒。第一，无人值守运行的循环也会无人值守地犯错，所以验证仍然是你的工作。第二，循环消耗 token 的方式与单条提示不同，Osmani 本人也说他持怀疑态度，并且必须留意成本。第三，这个词还很年轻：它来自 2026 年 6 月到 7 月的几篇文章、一门 DeepLearning.AI 课程和 IBM 的一篇解释文章，而不是来自某个标准或厂商规范。凡是 Osmani、IBM 或 LangChain 的观点，我们都会注明；凡是厂商文档确认的功能，我们都会链接到文档。
本文依据 Osmani 的文章（2026 年 6 月 7 日）、LangChain 的《The Art of Loop Engineering》（2026 年 6 月 16 日）、IBM 的解释文章（2026 年 7 月 17 日）和 DeepLearning.AI 课程（2026 年 10 月 29 日更新）写成，并对照了 Claude Code、Claude Agent SDK、Codex、OpenAI Agents SDK 与 LangGraph 的文档。除阅读文档之外，我们没有对下文的命令做上手测试，也不给出美元成本，因为我们没有测量过。以下一切均截至 2026 年 10 月 30 日。
什么是 loop engineering
Osmani 的开场一句就是最短的定义：loop engineering 就是取代你自己这个给智能体下提示的人，转而设计去做这件事的系统。他引用了 Peter Steinberger 的话（“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”）和 Anthropic 的 Claude Code 负责人 Boris Cherny 的话（“I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops”）。这两句引文都经由 Osmani 的文章转述，我们没有找到原始出处。
他写道，大约两年来，使用编码智能体的价值来自写一条好提示、读回结果、再敲下一条，整个过程你都得握着工具。循环用一套小系统取代这种手把手的方式：它发现工作、分派任务、检查结果、写下已完成的事项，并决定下一件事。用他的话说，循环可以被看作一个递归的目标：你定义一个目的，AI 不断迭代直到完成。
IBM 的解释文章给了同一个想法更学术的形式。它把 loop engineering 定义为设计智能体工作流的实践，以最少的人工干预，迭代地引导 AI 智能体走向用户定义的目标，并描述了一个由四个阶段组成的标准周期：
| 阶段 | 发生什么 | IBM 页面中的示例 |
|---|---|---|
| 1. Goal（目标） | 每次迭代都检查一个递归目标，并带有清晰、可验证的停止条件 | 当代码通过所有单元测试并满足所要求的需求时停止迭代 |
| 2. Action（行动） | 智能体采取行动，向目标靠近 | 生成代码、运行单元测试、修复 bug |
| 3. Observation（观察） | 系统评估行动的结果 | 运行 CI 测试，看它通过还是失败 |
| 4. Adjustment（调整） | 反馈在循环重新开始前改变做法 | 修改方案，再试一次 |
IBM 还补充了一点值得强调的话：好的目标同时控制 token 成本，因为它避免了不必要的迭代。“让我的网站加载更快”很模糊，而一个可度量的停止条件才给智能体一个可以自行验证的东西。这句话是下面大多数实用建议的种子。
Loop 与 prompt、context、harness、spec-driven 的对比
围绕这个话题的搜索常把 loop engineering 与四个相邻术语放在一起。它们不是对手，而是处在不同的高度。下表按工作单元从小到大排列。
| 实践 | 你设计什么 | 工作单元 | 谁向模型下指令 | 典型产物 |
|---|---|---|---|---|
| Prompt engineering | 一条指令 | 一次模型调用 | 你，每一轮 | 一条提示 |
| Context engineering | 模型每个周期看到哪些数据 | 一个步骤的输入 | 你或系统 | 摘要、markdown 结构、检索到的文件 |
| Harness engineering | 单个智能体运行其中的环境 | 一次智能体会话 | 你启动会话 | 工具、沙箱、权限、指令 |
| Loop engineering | 发现、分派、检查并记录工作的系统 | 随时间发生的多次运行 | 循环本身 | 调度、目标条件、验证器、状态文件 |
| Spec-driven development | 在编码开始前定义“完成”的书面规格 | 一个功能或一次变更 | 你写规格，智能体按规格执行 | 规格、计划、验收标准 |
这些关系来自各来源。IBM 划出了 prompt 这条线：prompt engineering 适合一次性交互或单次模型调用，而 loop engineering 适合处理自主代码生成、维护或多步骤工作的长时间运行智能体。IBM 还把 context engineering 列为循环内部的一个组成部分，因为每个周期产生的数据会喂给下一个周期，并警告说上下文过多会降低相关性、推高成本。Osmani 把 loop engineering 放在 harness 的上一层，把循环描述为按定时器运行、派生帮手并自我喂养的 harness。IBM 提到 agent harness engineering，指围绕智能体设计完整执行环境的实践。
Spec-driven development 是四个一手来源都没有定义的一行，所以请把这一行当作我们自己的归纳。自然的对应关系是：规格提供了循环所需的“完成的定义”，目标条件的质量取决于它背后的验收标准。我们的 spec-first 开发文章讲的是规划这一侧；Codex 自己的用例页面也说，好的目标要告诉智能体要达成什么、不要改动什么、如何验证以及何时停止，这就是一个浓缩版的规格。
LangChain 的四个循环
LangChain 的文章由 Sydney Runkle 撰写，它从构建智能体而不是使用编码助手的角度切入。文章引用了 swyx 的“loopcraft”概念，并堆叠了四个循环，每一个都包裹着内层那个。同一套框架也在 DeepLearning.AI 课程里讲授，授课人是 Runkle 和 Esmaeil Gargari。
| 循环 | 做什么 | 文中点名的 LangChain 原语 |
|---|---|---|
| 1. Agent loop | 模型反复调用工具，直到任务完成 | create_agent |
| 2. Verification loop | 按评分标准给输出打分，不合格就带着反馈重试 | RubricMiddleware，或 after_agent hook |
| 3. Event-driven loop | 定时、webhook 或新文档等事件触发智能体运行 | LangSmith Deployment 的 cron 触发器与 webhook，或 Fleet channels |
| 4. Hill-climbing loop | 来自大量运行的 trace 喂给分析智能体，由它改写 harness 配置 | LangSmith Engine |
有两个细节很有用。验证循环中的打分器可以是确定性的（跑测试、检查链接能否打开），也可以是智能体式的，例如让 LLM 当评审，LangChain 明确说验证会增加每次运行的延迟和成本。第四个循环是大多数编码智能体用户还没有搭过的：它分析跨运行的 trace，并针对提示、工具或打分器提出修改，使每一轮外层循环都让内层循环变得更好。LangChain 的建议是把重心从循环 1 和 2 移向循环 3 和 4，价值在那里累积。这是厂商的观点，LangChain 销售它所点名的工具。
DeepLearning.AI 课程列为八节课、四个代码示例，它把这些循环用在一个需求评审智能体上，而不是编码智能体上。它的学习目标与这套堆叠相对应：构建智能体循环，用评估器和明确标准加上验证循环，由 Slack 消息或 Jira 工单等事件触发智能体，并分析 trace 来改进 harness。
五个构件对应 Claude Code 与 Codex
Osmani 的版本是为编码助手这个位置设计的。一个循环需要五样东西，外加一个存放记忆的地方：自动化、worktree、skills、plugins 与 connectors、subagents，以及 memory。他的表格把它们对应到 Codex 应用和 Claude Code。我们对照厂商自己的文档重新核对了每一项对应，只保留文档能证实的部分。凡是 Osmani 的措辞与当前文档不同，最后一列都会注明。
| 构件 | 在循环中的作用 | Claude Code（依其文档） | Codex（依其文档） | 核对结果 |
|---|---|---|---|---|
| Automations（自动化） | 按计划或直到条件成立，发现并分流工作 | 会话内的 /loop 与 cron 工具；云端和桌面端定时任务；/goal；hooks；带 schedule 触发器的 GitHub Actions | ChatGPT 桌面应用中的定时任务，可在项目内或后台 worktree 运行；受 features.goals 控制的 /goal | 已证实。OpenAI 文档现在把该功能称为 scheduled tasks，收件箱称为 Scheduled；Osmani 的说法是 Automations tab 和 Triage inbox |
| Worktrees | 避免并行的智能体在文件上相互冲突 | claude --worktree <name>；subagent frontmatter 中的 isolation: worktree | ChatGPT 桌面应用中 Codex 的 worktree，可在 Local 与 Worktree 之间 Handoff；定时任务可使用后台 worktree | 已证实。OpenAI 说明 worktree 仅在桌面应用中可用 |
| Skills | 把智能体否则只能猜的项目知识写下来 | .claude/skills/<name>/ 中的 SKILL.md，以 /skill-name 调用或在相关时自动加载；/loop 可以运行一个 skill | 在 .agents/skills 中发现的 SKILL.md 文件夹，用 $ 调用，或按描述隐式匹配；定时任务可以使用 skills | 两边都已证实 |
| Plugins 与 connectors | 把智能体连到你已经在用的工具 | MCP 服务器；会话 /loop 继承它们，云端任务使用已配置的 connectors | 定时任务可使用 plugins；自定义智能体文件接受 mcp_servers | 部分证实。我们没有验证为其中一个写的 connector 能否原样用于另一个 |
| Subagents | 把做事的和检查的分开 | .claude/agents/ 中带 frontmatter 字段的 subagents；用于协同会话的 agent teams | .codex/agents/ 中的 TOML 自定义智能体，含 model、model_reasoning_effort、sandbox_mode、mcp_servers 和 skills.config | 两边都已证实 |
| State（记忆） | 把已完成和下一步的事项存放在对话之外 | 文档中没有内置的循环台账；用 markdown 文件或你接入的任务追踪器 | 文档中没有内置的循环台账；同上 | 这是 Osmani 的模式，不是产品功能。文件由你自己维护 |
逐个看这些构件
Automations：心跳
在 Claude Code 中，调度页面列出了三种运行重复性工作的方式。云端任务运行在 Anthropic 托管的基础设施上，不依赖你的机器，最小间隔为一小时。桌面端任务在你的机器上运行，可访问本地文件。/loop 在打开的会话内运行，最小间隔一分钟，并继承该会话的权限和 MCP 服务器。不带参数的 /loop 会运行一个内置的维护提示，它会继续未完成的工作、照看当前分支的 pull request（评审意见、失败的 CI、合并冲突），并运行清理步骤；你可以用自己的 .claude/loop.md 替换它。会话内循环不是持久的：重复任务在七天后过期，任务只会在 Claude Code 运行且空闲时触发。对于无人值守的工作，该页面指向云端定时任务、GitHub Actions 或桌面端定时任务。
在 Codex 中，定时任务在 ChatGPT 桌面应用里于后台运行。对于 Git 仓库，你可以在本地项目和新的 worktree 之间选择；文档警告说，本地模式可能修改你仍在处理的文件。有发现的运行结果会进入一个起到收件箱作用的 Scheduled 视图。它们以你默认的沙箱设置无人值守运行，文档建议从能让任务成功的最窄权限开始。项目范围的任务需要机器开机且应用在运行。定时任务可以调用一个 skill，所以你把重复性指令保存在一个便于维护的地方，而不是把一长段提示贴进一个没人更新的计划里。
两个工具还各有一个会话内原语，对循环设计来说比定时器更重要：一个运行到条件为真的 goal。Claude Code 的 /goal 设置一个完成条件，每一轮之后由另一个独立模型检查它是否成立。文档强调完成与否由一个全新的模型判定，而不是由干活的那个模型。Codex 的 /goal 朝一个长期目标工作，并支持暂停、恢复和清除。Osmani 指出两个工具以相同的名字提供了同一个原语，这正是他整篇文章的模式。
Worktrees：并行而不冲突
两个智能体写同一个文件，与两位工程师提交同样的几行是同一类问题。Git worktree 给每个智能体一个独立的工作目录和自己的分支，同时共享一份仓库历史。Claude Code 的 common-workflows 指南展示了 claude --worktree feature-auth，而 subagents 文档说 isolation: worktree 会让 subagent 在临时 worktree 中运行，如果 subagent 没有做任何改动，该 worktree 会被自动清理。Codex 的 worktree 文档描述了同样的 Git 机制，并提供一个把对话在本地检出与 worktree 之间移动的 Handoff 流程，同时注明 Git 一次只允许一个分支在一个地方被检出。
Osmani 的提醒来自人的一面：worktree 消除了机械层面的冲突，但真正决定你能同时运行多少个并行智能体的是你的评审带宽。这是他的观点，厂商文档没有涉及。
Skills：别再向智能体重复解释项目
Skill 是一个带 SKILL.md 的文件夹，外加可选的脚本和参考资料。Claude Code 只在使用某个 skill 时才加载它的正文，所以冗长的参考资料在需要之前几乎不占成本，你也可以用 /skill-name 调用。Codex 一开始只载入每个 skill 的名称、描述和路径，直到决定使用该 skill 时才加载完整指令。因为隐式匹配依赖描述，Codex 文档建议描述要简短、范围清晰，并把触发词放在前面。对循环而言，好处在于每个周期都从你写下的约定出发，而不是重新推导。我们的 agent skills 指南更深入地讲了如何编写。
Plugins 与 connectors：触达你真正的工具
只能看到文件系统的循环是个小循环。Osmani 说 connectors 建立在 MCP 之上，让智能体能读取问题追踪器、查询数据库、调用预发布 API 或向 Slack 发消息，而 plugins 把 connectors 和 skills 打包起来便于分享。我们读到的文档分别证实了其中的管线：Claude Code 的定时任务继承或配置 MCP 服务器，Codex 的定时任务可以使用 plugins 和 skills，Codex 的自定义智能体文件可以携带 mcp_servers。IBM 把 MCP 服务器与其他 API 并列为循环获得工具访问的常见方式，并指出没有工具的智能体只能描述它打算做什么。至于给循环真实系统的写权限会带来什么审批问题，请看下面关于 human-in-the-loop 的章节。
Subagents：让做事的远离检查的
整个方法里最有用的结构性想法，是把写代码的和检查代码的分开。Osmani 认为写代码的模型给自己的作业打分太宽松，而第二个指令不同、有时模型也不同的智能体，能发现第一个自我说服过去的问题。Claude Code 在 .claude/agents/ 中定义 subagents，frontmatter 包括 tools、model、permissionMode、hooks、skills、background 和 isolation。Codex 把自定义智能体定义为 .codex/agents/ 下独立的 TOML 文件，允许 model、model_reasoning_effort、sandbox_mode、mcp_servers 和 skills.config 等键，使评审者可以用比探索者更强的模型运行。常见的分工是一个智能体探索、一个实现、一个对照规格验证。/goal 的评估器则把同样的“做事与检查分离”用在了停止条件本身上。
如果你想看另一个工具里的多智能体做法，我们的 Antigravity 智能体编排指南讲了如何在 Google 的编辑器里编排多个智能体。
State：记住事情的那个文件
Osmani 把第六个构件称为 memory：一个 markdown 文件、一块 Linear 看板，任何存在于单次对话之外、记录已完成和下一步事项的东西。他的理由是模型在两次运行之间会忘掉一切，所以记忆必须放在磁盘上，用他的话说就是：智能体会忘，仓库不会。这是两家厂商都没有作为循环功能文档化的唯一一块，所以没有什么可查的：格式由你选，并保持足够短，以便在每次运行开始时读完。
一个循环长什么样
Osmani 的实例是对一个仓库运行的晨间循环。一个自动化每天早上运行。它的提示调用一个分流 skill，该 skill 读取昨天的 CI 失败、未关闭的 issue 和最近的提交，并把发现写进一个 markdown 文件或 Linear 看板。对每个值得处理的发现，该线程打开一个隔离的 worktree，派一个 subagent 起草修复，再派第二个对照项目 skills 和现有测试评审草稿。Connectors 负责开 PR 并更新工单。循环处理不了的内容进入你的收件箱。状态文件记录尝试过什么、什么通过了、什么仍未解决，所以明天的运行从今天停下的地方接着走。
有价值的观察是你做了什么：你只设计了一次循环，并没有提示其中任何一步。因为这些构件在 Codex 和 Claude Code 里是相同的，他认为循环可以在更换工具之后依然成立。我们没有运行过这个具体的循环，所以请把它当作一种设计模式，而不是经过基准测试的配方。
搭建你的第一个循环
下面是根据上述文档拼出的、保守的第一个循环路径。从小处开始，给一切设界，并亲自阅读输出。
- 先写停止条件。一个可度量的终态，一项能证明它的检查，以及任何不能改动的约束。Claude Code 的文档给出了形状：一个可度量的终态、一项明确的检查（例如
npm test以 0 退出），以及诸如不修改其他测试文件之类的约束。Codex 的页面也是同样的说法：只指定一个目标和一个停止条件。 - 选与工作相匹配的触发器。时间间隔适合轮询部署或 pull request。条件适合带测试的迁移或重构。事件适合 CI 失败或工单。cron 计划适合每日分流。
- 隔离每一次运行。使用 worktree，使循环永远不会编辑你正在工作的检出目录。Codex 文档说 worktree 能让定时任务的改动与你未完成的本地工作分开。
- 把重复性指令放进 skill，并在计划中调用这个 skill，这样提示保持一行，知识仍可编辑。
- 把做事的和检查的分开。使用 subagent、第二个模型，或测试、lint 之类的确定性检查。Claude Code 的 Stop hook 可以在每一轮之后运行脚本，完成确定性检查。
- 选定一个状态文件，告诉循环先读它、最后更新它。
- 在走开之前设定审批姿态和花费上限。决定哪些动作需要暂停等人，哪些被允许；见后面的章节。在 goal 里写入轮数或时间上限。
- 按固定节奏复查。自己阅读 diff 和状态文件，开始时每天一次。
两个会话内原语的示例，使用文档中展示的语法：
# Claude Code: run until a condition holds, with a turn bound
/goal all tests in test/auth pass and the lint step is clean, or stop after 20 turns
# Claude Code: poll on an interval inside a session
/loop 15m check CI on this branch and address new review comments
# Codex: enable the goal command if it is missing, then set a goal
[features]
goals = true
# or: codex features enable goals在 Claude Code 中，goal 不会改变你的权限模式。goal 文档说，要让 goal 的各轮无人值守地运行，你需要在 auto 模式下运行 /goal；在 Manual 模式下，对于你的设置尚未允许的工具调用，Claude 仍然会先询问。这一句话正好衔接下一节。
Human-in-the-loop 与 human-on-the-loop
Loop engineering 并没有把人去掉，只是改变了人所处的位置。我们使用两个标签。Human-in-the-loop 指运行在某个具体动作处暂停，直到有人批准、修改或拒绝。Human-on-the-loop 指有人在运行之外监督，事后阅读 diff、状态文件和报告，并在循环跑偏时叫停它。第二个标签是我们自己的简称；一手来源没有定义它，不过 IBM 主张即便是稳健的循环也需要人的参与，LangChain 则列出了四个应当放置监督的位置。
| Human-in-the-loop（审批关卡） | Human-on-the-loop（监督） | |
|---|---|---|
| 人何时介入 | 在某个具体动作运行之前 | 在运行之后，或发现异常时 |
| 什么会阻塞智能体 | 一个待处理的审批或问题 | 没有，直到你停止或清除循环 |
| 最适合 | 不可逆或敏感的动作：删除文件、金融交易、数据库写入、推送 | 隔离 worktree 中可逆的工作：草稿、重构、测试修复 |
| 代价 | 你的注意力和延迟；无人值守的运行会卡住 | 错误未被察觉的风险，以及理解债务 |
| 文档中的例子 | Claude canUseTool 回调；OpenAI needs_approval；LangGraph interrupt() | Claude auto 模式配合 /goal；在收件箱中复查的定时任务；hooks 与日志 |
Claude Code：权限模式与 SDK 回调
权限文档列出了这些模式：default（在 CLI 中标为 Manual）在首次使用每个工具时询问；acceptEdits 接受工作目录内的文件编辑和常见文件系统命令；plan 只探索而不编辑源文件；auto 无需例行提示即可运行，同时由后台分类器对照你的请求检查 shell 命令和网络请求等动作；dontAsk 自动拒绝任何会触发提示的操作；bypassPermissions 跳过提示，只有没有任何模式会自动批准的动作除外。沿着这个列表每走一步，你就从 in-the-loop 更靠近 on-the-loop，如果循环出错，风险也更大。
如果你在 Agent SDK 上构建自己的应用，审批文档描述了一个 canUseTool 回调，当 Claude 需要某个工具的权限，或通过 AskUserQuestion 提出澄清问题时触发。执行会保持暂停，直到你的回调返回，回调可以无限期地处于挂起状态。如果人可能需要比你的进程存活更久的时间，文档建议使用返回 defer 决定的 PreToolUse hook，让进程退出，之后从持久化的会话恢复。文档还指出，对于自动批准的工具，回调永远不会触发，所以必须对每次调用都生效的逻辑应放在 PreToolUse hook 里；另外，PermissionRequest hook 可以在 Claude 等待时发送 Slack、邮件或推送通知。最后这一点是个实用的办法，让无人值守的循环只在需要你做决定时才通知你。
OpenAI：把审批当作中断
OpenAI Agents SDK 把 human-in-the-loop 建模为一次暂停。工具把 needs_approval 声明为 True，或声明为一个逐次调用做决定的异步函数。需要审批时，执行暂停，运行结果中包含 interruptions；你把结果转换为 RunState，调用 state.approve(...) 或 state.reject(...)，再恢复原来的运行。状态可以序列化，所以一次运行可以跨进程重启等待人。在循环里有两个细节值得注意。可调用的审批规则默认失败即关闭：如果参数缺失或格式错误，该调用需要人工审批。此外，对于本地 shell 和 apply_patch 工具，用 always_approve=True 做出的粘性决定是按工具类型和名称匹配的，而不是按所属智能体，所以在 handoff 之后，一个智能体的全面批准可能适用于另一个智能体的同名工具。在多智能体循环中，请避免对 shell 和文件编辑使用粘性审批。我们的 OpenAI Agents Python SDK 指南把该 SDK 与 LangGraph 和 CrewAI 做了比较。
一条实用规则
对于无法撤销或会触及共享系统的动作，让人处在循环之中；对于所有落在 worktree 和你会评审的 pull request 里的内容，让人处在循环之上。如果你说不清某一步属于哪一类，在弄清楚之前就按 in-the-loop 处理。如果你想在循环运行时用手机回应审批提示，我们的 Claude Code Remote Control 指南与此相关。
LangGraph 的位置
Claude Code 和 Codex 给你现成的循环构件。LangGraph 针对的是另一种情形：你用 Python 自己编写智能体，并需要可持久的暂停与恢复。它并不取代上面的想法，只是实现这些想法的一种方式。
LangGraph 的 interrupts 在你选定的位置暂停图的执行，并等待外部输入。当你在某个节点里调用 interrupt() 时，LangGraph 通过其持久化层保存图状态，向调用方返回一个可 JSON 序列化的值，并无限期等待，直到你用 Command(resume=...) 恢复。你需要一个 checkpointer（生产环境中用持久化的）和一个 thread_id，文档把后者称为你的持久游标。有一个行为需要在设计时考虑：恢复时，节点会从头重新开始，所以 interrupt() 之前的代码会再次运行。与在特定节点之前或之后暂停的静态断点不同，interrupts 可以放在任何地方，并且可以是有条件的。
在此之上，LangChain 的 human-in-the-loop 中间件按策略检查每次工具调用，并提供四种决定：approve、edit、reject 和 respond。文档说要用 reject 拒绝某个动作，只有当人在充当工具时（例如回答 ask-user 提示）才用 respond，因为 respond 的消息会被当作一次成功的工具结果。interrupt_on 映射决定哪些工具会暂停，when 谓词可以根据调用参数来控制是否中断，例如只在写入工作区之外时才暂停。
把它对应回 LangChain 的四个循环：LangGraph 的持久化支撑着智能体循环的审批点，以及验证循环中由人当评分者的变体；事件驱动循环和 hill-climbing 循环使用的是 LangSmith 的工具。对于智能体之外的编排，例如定时数据管道，请看我们的 AI 与 ML 编排工具对比。如果你直接驱动 Claude Code 或 Codex，第一个循环很可能用不到 LangGraph。
Token 成本警告
Osmani 说你必须留意 token 成本，用量会因为你是 token 富裕还是匮乏而差别巨大。我们没有找到关于典型循环成本的公开数字，也没有自己测量，所以下表列的是来源和文档里真正点名的成本杠杆，而不是美元数字。
| 成本杠杆 | 来源怎么说 | 该怎么做 |
|---|---|---|
| 没有停止条件 | Claude 的 /goal 可以一直运行，直到某个模型确认条件成立；条件中可以包含轮数或时间子句，例如 stop after 20 turns | 始终在条件中写入上限 |
| Goal 状态 | 运行 /goal 会显示条件、时间、已评估轮数和当前 token 花费 | 早期运行时多检查 |
| 被遗忘的循环 | 会话内的重复任务 7 天后过期；一个会话最多容纳 50 个任务 | 依靠过期机制，并取消不再需要的循环 |
| 轮询间隔 | 不带间隔的 /loop 会在一分钟到一小时之间选择延迟；Monitor 工具可以避免轮询，通常更省 token | 优先用事件驱动的检查，而不是短间隔轮询 |
| Prompt cache | */5 任务会提前 15 秒启动，以便在五分钟的 prompt cache 过期之前落地 | 不要以为奇怪的间隔是免费的 |
| Subagents | Claude 的文档说每个 subagent 都会消耗自己的 token，许多详细结果会占用大量上下文；Codex 说 subagent 工作流比同等的单智能体运行消耗更多 token | 只在第二意见值回成本的地方使用 |
| 验证循环 | LangChain 说验证会增加每次运行的延迟和成本 | 尽量让打分器便宜且确定 |
| 上下文增长 | IBM 说多余的上下文会降低相关性并推高成本；建议总结早前的迭代并用 markdown 组织结构 | 把状态总结进状态文件 |
| 智能体内的治理 | IBM 说 hooks 把治理和质量检查移出智能体，减少 token 使用 | 对不需要判断的检查使用 hooks 和脚本 |
注意其中的规律。最便宜的控制手段是那些完全不运行模型的：停止条件、过期时间、确定性测试、hook。昂贵的手段，例如全新模型评估器、subagents 和扇出，买的是质量。请有意识地在那里花钱。如果你的套餐或订阅有用量上限，那么在你睡觉时运行的循环，也可能在你醒来之前耗尽配额，所以在安排任何任务之前，先搞清楚你的套餐如何计量用量。
循环不会替你做的事
Osmani 列出了随着循环变好而愈发尖锐的三个问题。验证仍然是你的事：无人值守运行的循环会无人值守地犯错，即便是独立验证者说的“完成”，也只是一种声称，而不是证明。理解会腐烂：循环交付你没写的代码越快，现存之物与你所理解之物之间的差距就越大。IBM 把这称为理解债务（comprehension debt），即系统中的代码量与人们对其理解程度之间的差距，并指出当代码通过自动化测试时，它会悄无声息地累积。舒适的姿态是危险的：Osmani 把照单全收循环返回的一切称为认知投降（cognitive surrender）。IBM 补充了意图债务（intent debt），即记录下来的理由的丢失，agents.md 和 skill 文件正是为防止这一点而设。
他的结束语适用于本文的每一项实践：两个人可以搭出同一个循环，却得到相反的结果，一个人在自己理解的工作上更快，另一个人则回避去理解工作。循环并不知道其中的区别。他还说，直接提示智能体仍然有效，目标是平衡，而不是全自动。
论断与证据对照表
| 论断 | 出处 | 状态 |
|---|---|---|
| Loop engineering 是设计向智能体下指令的系统 | Osmani，2026 年 6 月 7 日；IBM，2026 年 7 月 17 日 | 两个来源的定义一致；这是一个年轻的术语，不是标准 |
| Steinberger 与 Cherny 说过上述引文 | 引自 Osmani 的文章 | 二手转述；未找到原始出处 |
| 循环遵循目标、行动、观察、调整 | IBM | IBM 的框架 |
| 四个循环：agent、verification、event-driven、hill-climbing | LangChain 文章；DeepLearning.AI 课程页 | 厂商框架；LangChain 销售所点名的工具 |
| Claude Code 有 /loop、cron 工具和 7 天过期 | Claude Code 定时任务文档 | 已在厂商文档中证实 |
| Claude Code 的 /goal 使用独立的评估模型 | Claude Code goal 文档 | 已在厂商文档中证实 |
| Codex 有 /goal，支持暂停、恢复和清除 | OpenAI Codex 用例页面 | 已在厂商文档中证实；可能需要 features.goals |
| 两个工具都支持 worktree | Claude Code common-workflows 与 subagents 文档；Codex worktree 文档 | 已证实；Codex worktree 仅限桌面应用 |
| 两个工具都使用 SKILL.md 技能 | Claude Code 与 Codex 的 skills 文档 | 已在厂商文档中证实 |
| Codex subagents 是 .codex/agents/ 中的 TOML 文件 | Codex subagents 文档 | 已在厂商文档中证实 |
| Subagents 消耗更多 token | Codex subagents 文档；Claude Code subagents 文档 | 定性证实；未公布数字 |
| Human-on-the-loop 作为一个已定义的术语 | 不在四个一手来源中 | 我们自己的简称，已如实标注 |
| 为一个工具写的 connector 能原样用于另一个 | Osmani | 未验证 |
| 循环的质量与成本结果 | Osmani、IBM | 没有公布基准或实测成本 |
本文的局限
- 我们阅读了文档和文章，没有运行这些循环，所以这里没有任何性能、质量或成本结果是实测的。
- Loop engineering 没有标准定义。各来源强调的重点不同：Osmani 强调编码助手的原语，LangChain 强调构建智能体的技术栈，IBM 强调周期与治理。
- LangChain 与 DeepLearning.AI 呈现的框架会通向 LangChain 的产品。我们如实报告这套框架，并把工具名称标注为厂商的选择。
- 厂商文档变化很快。Osmani 的表格使用了 Automations tab 和 Triage inbox 这样的名称，而 OpenAI 当前页面写作 scheduled tasks 和 Scheduled。命令是否可用可能取决于版本、套餐和功能开关，请检查你自己的安装。
- 我们没有找到 Steinberger 或 Cherny 的一手帖子，所以没有嵌入 X 帖子，那两句引文也是二手的。
- Subagent 和循环的 token 成本只做了定性描述。我们没有找到公布的每个循环的数字，所以不给出任何数字。
结论
Loop engineering 是一个有用的名字，指的是开发者早已用脚本和 cron 任务在做的事：把控制点从提示移到它周围的系统上。实际价值在于那份检查清单。为每个循环配上可度量的停止条件、触发器、隔离的工作空间、写下来的项目知识、独立的检查者、状态文件，并决定在哪里由人批准、在哪里人只是复查。
从一个低风险的循环开始，例如在 worktree 里带 goal 上限的测试修复，或只写报告的定时分流。观察 token 花费，阅读它产出的东西，只有当输出赢得信任时才扩大范围。Osmani 自己的结论是最好的收尾：搭起循环，但要像一个打算继续当工程师的人那样去搭。
常见问题
什么是 loop engineering？
Loop engineering 是设计一套替你向编码智能体下指令的系统，而不是每一轮都自己手动提示。这套系统负责发现工作、分派任务、检查结果、记录已完成的事项，并决定下一步做什么。Addy Osmani 把它描述为取代你自己这个“给智能体下提示的人”；IBM 则把它定义为设计智能体工作流，以最少的人工干预，迭代地引导智能体走向用户定义的目标。
Loop engineering 与 prompt engineering 有什么区别？
Prompt engineering 优化的是针对一次模型调用的一条指令。Loop engineering 设计的是一套系统，它生成、发送并评估许多条提示，直到目标达成。IBM 的说法是：前者由人写好每一条提示，后者由自动化系统自行改进内部提示；提示链结构固定，而循环是动态的。
Loop engineering 和 harness engineering 是一回事吗？
不是。Osmani 把 loop engineering 放在 harness 的上一层：harness 是单个智能体运行其中的环境，而循环会按定时器运行、派生帮手并自我喂养。实际使用中循环要用到 harness，所以两者都需要。
Claude Code 支持 loop engineering 吗？
Claude Code 的文档描述了这些构件：会话内的 /loop 与 cron 调度、云端与桌面端的定时任务、带独立评估模型的 /goal、hooks、可选 worktree 隔离的 subagents、--worktree 参数，以及 SKILL.md 技能。Osmani 提到 GitHub Actions 可以让循环在合上笔记本之后继续运行，这与调度文档一致，文档确实列出了带 schedule 触发器的 GitHub Actions。文档并没有把这些统称为 loop engineering，循环要由你自己组装。
Codex 有 /goal 命令吗？
有。OpenAI 的 Codex 用例页面写明，/goal 让 Codex 持续朝一个长期目标工作，并提供 /goal pause、/goal resume 和 /goal clear。如果命令没有出现，页面说明要在 config.toml 中启用 features.goals，或运行 codex features enable goals。截至 2026 年 10 月 30 日，这一说法见于该用例页面。
Human-in-the-loop 与 human-on-the-loop 有什么区别？
在本文中，human-in-the-loop 指运行会暂停，直到有人对某个具体动作批准、修改或拒绝，例如 LangGraph 的 interrupt、OpenAI Agents SDK 的 needs_approval 标志，或 Claude 的 canUseTool 回调。Human-on-the-loop 指人在运行之外监督，事后查看日志、diff 和报告。第二个术语是我们自己的简称；四个一手的 loop engineering 来源都没有定义它，不过 IBM 和 LangChain 都主张人要持续参与。
LangGraph 在 loop engineering 中处于什么位置？
LangGraph 提供持久化与暂停恢复这一层。它的 interrupt() 函数通过 checkpointer 保存图状态，并一直等到你用 Command(resume=...) 恢复；LangChain 的 human-in-the-loop 中间件在此基础上提供 approve、edit、reject 和 respond 四种决定。它适用于你用 Python 自己构建智能体、而不是直接驱动 Claude Code 或 Codex 的场景。
循环会很烧钱吗？
会，Osmani 也说要留意 token 成本。每多一轮、每多一次验证、每多一个 subagent 都会消耗 token。用停止条件、过期时间或轮数上限为每个循环设界，在工具的状态视图里观察用量，只在值得为第二意见付费的地方使用 subagents。我们没有实测成本，所以本文不给出美元数字。
来源
来源核对于 2026 年 10 月 30 日。
- Loop Engineering，Addy Osmani，2026 年 6 月 7 日（五个构件、Codex 与 Claude Code 对应、风险）
- The Art of Loop Engineering，Sydney Runkle，LangChain，2026 年 6 月 16 日（四个循环、人工监督点）
- What is loop engineering? IBM，2026 年 7 月 17 日（定义、循环阶段、组成部分、风险）
- Loop Engineering with LangChain Deep Agents，DeepLearning.AI（课程大纲，2026 年 10 月 29 日更新）
- Claude Code 文档：定时任务与 /loop、/goal、subagents、权限、skills、常见工作流和 hooks
- Claude Agent SDK：处理审批与用户输入
- OpenAI Codex 文档：跟进一个目标、定时任务、worktrees、skills 和 subagents
- OpenAI Agents SDK：human-in-the-loop
- LangGraph interrupts 与 LangChain human-in-the-loop 中间件
延伸阅读：Claude Code 最佳实践指南、Antigravity 中的智能体编排、OpenAI Agents Python SDK 深度解析和 AI 与 ML 编排工具对比。