先纠正一个常见误读：Harness 并没有过时。 Loop Engineering 不是 Harness 的替代品，而是叠在它之上的一层。Harness 负责单次 agent 运行的环境，Loop 让这个环境定时跑起来、自我喂料、派生子 agent。本文把这层关系、五块构件，以及 Claude Code 与 OpenAI Codex 的具体落地讲清楚。
一、它在说什么
过去约两年，从一个 coding agent 拿到价值的方式很简单：写一个好的 prompt，给足上下文，读返回，再敲下一句。你全程握着这个工具，一轮接一轮。你是回路里的那个调度器。
2026 年 6 月，这个姿势开始变化。Peter Steinberger 的说法是:"你不该再去 prompt coding agent 了，你该去设计那些 prompt agent 的 loop。"Anthropic Claude Code 负责人 Boris Cherny 说得更直接:"我已经不 prompt Claude 了。我有一堆 loop 在跑、在 prompt Claude、在判断下一步该做什么。我的工作是写 loop。"Google 工程师 Addy Osmani 在 6 月 7 日的博文里把这件事命名为 Loop Engineering，由此这个词开始流行。
一句话定义：
Loop Engineering 是把"那个不停 prompt agent 的人"换成"一个不停 prompt agent 的系统"，而你负责设计这个系统。
这里的 loop 是一个递归目标（recursive goal）：你定义一次目的，agent 自行迭代直到任务真正完成。不再是你在每次响应后敲下一条指令，而是一个小系统去发现工作、分派工作、校验结果、记录已完成项、决定下一步------然后由这个系统去戳 agent，而不是你。
二、和 Prompt / Context Engineering 的关系：三层叠加
把它放进一个已经积累了几年的技术栈里看最清楚。每一层都包裹住内层，杠杆点逐层向远离裸模型调用的方向移动。
| 层级 | 你优化的对象 | 工作单元 |
|---|---|---|
| Prompt Engineering | 单条指令怎么措辞 | 你手敲的一个 turn |
| Context Engineering | 窗口里还放什么：文档、历史、工具定义 | 一次回答的周边条件 |
| Loop Engineering | 决定 prompt 什么、何时 prompt、结果是否可接受的那个系统 | 跨多个 turn 的自运行周期 |
三层不是互相取代的关系。Prompt Engineering 不会消失------loop 由 prompt 构成，loop 里一个糟糕的 prompt 只会更快地产出糟糕的工作。Context Engineering 也不会消失------loop 每一个 turn 仍要把对的文件、历史、工具定义摆到模型面前。Loop Engineering 增加的是包裹在这一切之上的自主控制结构。
这正是 Harness 没有过时的原因。用 Osmani 的原话：Harness 是单个 agent 运行所处的那个环境，Loop 比 Harness 高一层------它让 Harness 跑在定时器上、派生小助手、自我喂料。 杠杆点移动了，但工作没有变简单。一个设计良好的 loop 会放大一个好工程师；一个设计糟糕的 loop 会同样快地放大一个坏决定，而且你盯着的时间更少。
三、五块构件（外加一块记忆）
一个能用的 loop 需要五样东西，再加一处存放状态的地方。不同工具叫法略有差别，能力是同一个。
- Automations（自动化）：按计划触发，自行做发现与分诊（triage）。
- Worktrees（工作树）：让并行的两个 agent 不会改到同一份文件。
- Skills（技能）：把项目知识写下来，省得 agent 每次都靠猜。
- Plugins / Connectors（插件 / 连接器）：把 agent 接进你已经在用的工具。
- Sub-agents（子 agent）：一个出主意，另一个来检查。
第六块是 Memory（记忆） ：一个 markdown 文件、一块 Linear 看板、一份 GitHub issue 列表------任何活在单次会话之外、记录"做了什么、下一步是什么"的载体。它听上去简单到不值一提，却是所有长期运行 agent 都依赖的那个把戏。模型在两次运行之间会忘掉一切，所以状态必须落在磁盘上，而不是上下文窗口里。Agent 会忘，仓库不会。
2026 年中真正让人安心的一点是：你不再需要从零拼装这套东西。一年前，一个 loop 意味着一堆只有你自己看得懂、还得永远维护的 bash 脚本。如今这些构件直接随产品发货------Steinberger 列的清单几乎逐项对得上 Codex app，也几乎一样对得上 Claude Code。一旦你发现两个工具的形状是相同的，就不再纠结哪个 agent 更强，而是去设计一个无论坐在哪个工具里都能用的 loop。
两大工具的能力映射
| 构件 | 在 loop 里的职责 | OpenAI Codex | Claude Code |
|---|---|---|---|
| Automations | 按计划做发现 + 分诊 | Automations 标签页：选项目、prompt、节奏、环境；结果落入 Triage 收件箱；/goal 跑到完成 |
定时任务与 cron、/loop、/goal、hooks、GitHub Actions |
| Worktrees | 隔离并行任务 | 每个 thread 内建 worktree | git worktree、--worktree、子 agent 上的 isolation: worktree |
| Skills | 固化项目知识 | Agent Skills（SKILL.md），$name 或隐式触发 |
Agent Skills（SKILL.md） |
| Plugins / Connectors | 接入你的工具 | 基于 MCP 的 Connectors + 用于分发的 Plugins | MCP servers + Plugins |
| Sub-agents | 构思与校验 | .codex/agents/ 下的 TOML 定义 |
.claude/agents/ 下的子 agent、agent teams |
| State | 追踪进度 | Markdown 或经 connector 接入的 Linear | Markdown（AGENTS.md、进度文件）或经 MCP 接入的 Linear |
四、Automations：loop 的心跳
Automations 是让一个 loop 真正成为 loop、而不只是"跑过一次"的东西。它是心跳：一个反复触发、无需你开口就把工作浮现出来的机制，loop 里其余部分都对它发现的东西做反应。
在 Codex 里，你在 Automations 标签页创建一个：选项目、选要跑的 prompt、选节奏、选在本地 checkout 还是后台 worktree 上跑。有发现的运行落入 Triage 收件箱，没发现的自行归档。OpenAI 内部用它做 issue 分诊、告警监控、汇总 CI 失败、写 commit 简报这类例行活。Automation 可以调用一个 skill，于是反复执行的指令保持可维护------你触发一个具名 skill，而不是把一大段指令贴进一个没人会再更新的计划任务里。
在 Claude Code 里 ，同样的目标通过调度与 hooks 达成。/loop 把一条 prompt 按间隔排成 cron 任务并回一个 job ID；hooks 在 agent 生命周期的特定节点触发 shell 命令；你也可以把整件事推到 GitHub Actions，合上笔记本它照跑。
还有一个更贴近本文主题的会话内原语：/goal 会跨多个 turn 一直跑，直到你写下的条件被可验证地 满足；而且每个 turn 之后，由一个独立的、更小的模型来判断是否完成------也就是说，写代码的 agent 不是给自己打分的那个 。Codex 也有同名的 /goal（在 Codex CLI 0.128.0、2026-04-30 加入）。
bash
# Claude Code：每个工作日 9 点跑一条分诊 prompt
/loop "读取昨天的 CI 失败和未关闭 issue，把发现写进 TODO.md，
并为标了 quick-win 的项起草修复" --schedule "0 9 * * 1-5"
# Claude Code：跑到可验证的停止条件成立为止
/goal "test/auth 下所有测试通过，且 lint 干净"
# OpenAI Codex：持久化的长期目标（CLI 0.128.0+）
codex /goal "把 billing 模块迁移到新计价 API，保持现有测试全绿"⚠️ 盯紧 token 账单。 一个带"每 turn 后跑校验模型"的定时 loop 烧 token 很快，用量随触发频率和派生子 agent 数量剧烈波动。先用慢节奏 + 紧目标条件起步，观察几天成本，确认 loop 真在产出你会 merge 的工作后再放大。
五、Worktrees：让并行不变成混乱
一旦你跑超过一个 agent，文件就开始打架。两个 agent 写同一个文件，和两个工程师没打招呼就往同几行代码上提交，是同一种头疼。git worktree 解决它：一个独立的工作目录、自己的分支、共享同一份仓库历史，于是一个 agent 的改动在物理上碰不到另一个的 checkout。
Codex 把 worktree 直接内建，多个 thread 同时打同一个仓库而不相撞。Claude Code 用 git worktree、--worktree 开关，以及挂在子 agent 上的 isolation: worktree（每个助手拿到一份用完自清理的全新 checkout）提供同样的隔离。
💡 你才是天花板。 Worktree 消除的是机械层面的碰撞，消除不了 review 瓶颈。你能读懂、批准已合并工作的带宽，才决定你实际能跑几个并行 agent------不是工具能拉起多少个 worktree。十个你 review 不过来的 agent，比两个你能 review 的更糟。
六、Skills 与 Memory：别每次都重新解释你的项目
Skill 是你不必每个会话都重新解释同一份项目上下文的办法。两个工具用同一种格式：一个含 SKILL.md 的文件夹，放指令与元数据，外加可选的脚本、引用、资产。Codex 在你用 $ 或 /skills 调用、或任务匹配 skill 描述时自动触发------这也是为什么一个朴素精确的描述胜过一个聪明的描述 。Claude Code 一样。要跨仓库共享或打包多个 skill 时，你把它们封成 plugin：skill 是创作格式，plugin 是分发方式。
Skill 是让 intent（意图）不再反复花钱的地方。Agent 每个会话都从零冷启动，会用一个自信的猜测填补你意图里的任何空缺。Skill 就是把那份意图写在外面：约定、构建步骤、"我们不这么做，因为上次那个事故"。没有 skill，loop 每个周期都把整个项目从零重新推导；有 skill，知识跨运行复利累积。
Memory 是 skill 的近亲，是任何跑得比单次会话长的 loop 的脊柱。Skill 装持久知识 （怎么构建、约定是什么）；Memory 装变化的状态（试过什么、过了什么、还开着什么）。
| 机制 | 装什么 | 活在哪 |
|---|---|---|
| Skill | 持久的项目知识与约定 | 仓库里的 SKILL.md |
| Memory | 变化的状态：做了什么、下一步什么 | markdown 文件或 issue 看板 |
| Connector | 对外部工具与数据的访问 | MCP server 配置 |
Plugins 与 Connectors：让 loop 碰到你真实的工具
一个只看得见文件系统的 loop 是个很小的 loop。Connectors（构建在 MCP 之上）让 agent 读你的 issue tracker、查数据库、打 staging API、往 Slack 丢消息。Codex 和 Claude Code 都讲 MCP，所以你为其中一个写的 connector 通常在另一个上直接能用。这就是"这是修复方案"的 agent，和"CI 一绿就自己开 PR、关联工单、在频道里 @ 一声"的 loop 之间的区别。
七、Sub-agents：让"造"的和"验"的分开
loop 里单条最有用的结构性动作，是把写代码的 agent 和检查的 agent分开。写代码的模型给自己批改作业时太宽容了。一个带不同指令、有时还是不同模型的第二 agent，能逮住第一个自我说服过去的东西。
Codex 里你用 .codex/agents/ 下的 TOML 定义子 agent，各有 name、description、instructions，以及可选的 model 和 reasoning effort------你的安全 reviewer 可以是强模型 + 高强度，explorer 则是个快速只读的。Codex 在你要求时派生子 agent、并行跑、再把结果折回一个答案。Claude Code 用 .claude/agents/ 下的子 agent 与互相传活的 agent teams 做同样的事。两者常见的切分是：一个探索、一个实现、一个对照规格校验。
💡 为什么在 loop 里这个切分尤其重要。 loop 在你没盯着的时候跑，所以一个你真信得过的 verifier，是你敢走开的唯一理由。Claude Code 的
/goal底层做的正是这件事：由一个全新模型、而非干活那个，来判断 loop 是否完成------把"造/验分离"应用到停止条件本身。子 agent 确实更费 token（各自跑自己的模型和工具调用），所以把它们花在第二意见值这个钱的地方。
八、一个完整的 loop 长什么样
把这些拼起来，一个 thread 就变成了一块小控制面板。下面这个形状适合做第一个 loop，且在 Codex 和 Claude Code 上同构，因为原语是同一套：
- 一个 automation 每个工作日早上在仓库上跑，它的 prompt 调一个分诊 skill。
- skill 读昨天的 CI 失败、未关闭 issue、近期 commit，把发现写进一个 memory 文件或 Linear 看板。
- 对每个值得做的发现，thread 开一个隔离的 worktree ，派一个 sub-agent 起草修复。
- 第二个 sub-agent 对照项目 skills 和既有测试 review 这份草稿。
- Connectors 开 PR、更新工单。loop 处理不了的，落进 triage 收件箱给你。
yaml
# .claude/agents/reviewer.md ------ 检查者，与造者分离
---
name: spec-reviewer
description: 对照项目 skills 与测试，review 一份改动草稿。
model: opus # 校验者用强模型
isolation: worktree # 全新 checkout，零碰撞
---
你是一个对抗性 reviewer。跑测试套件，对照 CONVENTIONS.md 检查 diff，
任何无法被可验证地判定为"完成"的，一律驳回。
markdown
# TODO.md ------ memory，跨每次运行存活
## Open
- [ ] test/auth/login.spec.ts 里的 flaky 测试（CI run #4821）
## Done
- [x] axios 升到已打补丁版本（PR #312，已 merge）状态文件是整件事的脊柱：它记得试过什么、过了什么、还开着什么，所以明早的运行从今天停下的地方接着跑。看清楚你实际做了什么------你把这套系统设计了一次，没有手动 prompt 其中任何一步。 这就是 Loop Engineering 的全部要点，而且在 Codex 还是 Claude Code 里都是同一个 loop。
如果是你的第一个 loop，请起步得更小：一个每天早上把 CI 失败分诊进 markdown 文件、不自动 merge 的 automation，已经能拿掉一件例行琐事，让你在信任它去开 PR 之前先看清它的行为。
九、loop 不替你解决的那些问题
loop 改变了工作，没有把你从工作里删掉。有三个问题随着 loop 变好而更尖锐，不是更轻松。
一、验证仍然落在你头上。 无人值守地跑的 loop，也是无人值守地犯错的 loop。把 verifier 子 agent 从 maker 拆出来，正是为了让 loop 的"完成了"有分量。即便如此,"完成"是一个声明，不是一个证明。你的职责是发布你确认能跑的代码------这也是为什么无论 verifier 多好，对已合并改动的人工 review 都留在回路里。
二、理解债（comprehension debt）增长更快。 loop 越快地发布你没写的代码，仓库里实际存在的东西和你真正理解的东西之间的鸿沟就越大。一个顺滑的 loop 只会让这道鸿沟长得更快------除非你去读 loop 产出的东西。
三、认知投降（cognitive surrender）是那个舒适的失败。 当 loop 自己跑起来，停止持有观点、照单全收它给的东西，很有诱惑力。带着判断去设计 loop，它是解药；为了逃避思考去设计 loop，它是助燃剂。同一个动作，相反的结果。两个人搭出一模一样的 loop，可以得到完全相反的结局：一个用它在自己深刻理解的工作上跑得更快，另一个用它来逃避理解工作。loop 分不清这两者，你分得清。
⚠️ 搭 loop，但继续做那个工程师。 Loop Engineering 仍在早期，手动直接 prompt agent 依然有效。目标是平衡：把反复的、可验证的工作交给 loop，把你的判断才是价值所在的部分留给直接控制。像一个打算继续做工程师、而不只是按下启动键的人那样去搭你的 loop。
小结
Loop Engineering 不是"Harness 过时了"，而是杠杆点的一次上移：从写 prompt 的质量，移到设计"生成并校验 prompt 的系统"。Prompt、Context、Harness、Loop 是四层叠加，逐层包裹，谁都没退场。Cherny 的意思从来不是工作变简单了，而是最高价值的事情变了------从写 prompt，变成设计 loop。
搭好你的 loop。但要像一个打算继续当工程师的人那样搭它。
参考来源
- Addy Osmani, Loop Engineering （2026-06-07）--- addyosmani.com/blog/loop-e...
- Addy Osmani, Agent Harness Engineering --- addyosmani.com/blog/agent-...
- Peter Steinberger（X / Twitter 原始论述）--- x.com/steipete/st...
- Boris Cherny 引述（via @rohanpaul_ai）--- x.com/rohanpaul_a...
- OpenAI Codex（Automations、Skills、Sub-agents）--- openai.com/codex/
- Anthropic Claude Code 文档 --- docs.anthropic.com/en/docs/cla...
- Model Context Protocol 官方文档 --- modelcontextprotocol.io/
注：命令、价格与产品能力可能随时变化，依赖某项具体能力前请以厂商官网为准。