核心观点
Loop Engineering 不是”把提示词重复执行”，而是设计一套替你提示、调度、验证和交接 Agent 的系统。你从直接提示 Agent 的参与者，转为设计 Agent 自运行工作流的系统设计者。
1. Loop Engineering 是什么
过去两年，AI 辅助开发持续变化的底层变量是：AI 可连续自主工作的时长越来越长。每一阶段都对应一个新的工程重点。
| 阶段 | 优化对象 | 工作单位 | 核心命题 | 连续自主时长 | 典型瓶颈 |
|---|---|---|---|---|---|
| Prompt Engineering | 单条指令的措辞 | 一次手动对话 | 措辞更准，单次输出更好 | 一问一答 | 输出质量不佳，需要重问 |
| Context Engineering | 进入上下文窗口的内容 | 围绕一次回答的环境 | 背景给对，难任务也能推理 | 数十步 | 上下文缺失或过载 |
| Harness Engineering | 单个任务的安全、可靠执行环境 | 一个自主会话 | 环境造好，Agent 可长时间自主运行 | 数小时 | 仍是单会话，无人调度 |
| Loop Engineering | 跨会话的自运行工作流 | 多轮、跨会话生命周期 | 系统造好，可无人值守持续交付 | 数天、数十实例并行 | 过早停止、忽略错误、无法验证完成 |
1.1 各层的边界
- Prompt：优化单次模型调用的措辞与指令。
- Context：组织最相关的背景——文档、历史、RAG、知识检索与记忆。
- Harness：为 Agent 单次长会话建立可控沙箱，管理工具、权限、规则、容错、审计与人工介入。业界常写：
Agent = 模型 + Harness。 - Loop：跨多轮甚至跨会话调度任务生命周期，负责发现任务、分配、验证、记录状态，以及决定重试、停止或交接。
Addy Osmani 的概括：“你不再是那个提示 agent 的人；你去设计那个替你提示 agent 的系统。”
1.2 为什么强调 “Engineering”
一个可无人值守的 Loop，不只需要”重复执行”，还必须回答：
- 何时启动 Agent？
- 启动后做什么、启动多少个？
- 谁来验收结果？不通过如何重试？
- 状态存在哪里？
- 什么时候停止或交接？
因此，Loop Engineering 不是一门从零学起的新学科，而是 AI 工程演进到”能跨会话自动执行、调度和验证”的阶段；Claude Code、Codex 的 /loop、/goal 等产品能力让它可以直接落地。
2. 内循环与外循环
2.1 单次会话中的内循环
单次 Coding Agent 运行通常遵循 ReAct 内循环：
| 阶段 | 英文 | 做什么 |
|---|---|---|
| 意图 | Intent | 定义成功结果与约束 |
| 上下文 | Context | 收集代码、文档、报错日志与规范 |
| 行动 | Action | 编辑文件、执行命令、调用工具、起草方案 |
| 观察 | Observation | 获取测试结果、编译错误、运行时输出和 diff |
| 调整 | Adjustment | 根据观察更新计划，持续迭代直至完成或受阻 |
修一个 Bug 时，Claude Code 会读文件 → 修改 → 跑测试 → 看报错 → 再修改。这一循环发生在单个会话内部，由 Harness 管理；CLAUDE.md、Skills、Hooks 与权限约束都服务于它。
2.2 跨会话的外循环
外循环关注：谁启动 Agent、何时启动、派什么任务、如何验证并进入下一轮。
典型场景：每天定时扫描 GitHub 中标记为 Bug 的 Issue，选取最高优先级项，开分支修复、运行测试、创建 PR，再由另一个 Agent 检查结果。此时触发者是定时任务，选题、验收和下一步都由系统编排——人的角色变成系统设计者。
| 维度 | 一次会话内（Harness） | Loop（Loop Engineering 的对象） |
|---|---|---|
| 谁驱动 | Agent 自己 | 你设计的编排系统 |
| 一圈做什么 | 读 → 改 → 测 → 看 → 再改 | 发现任务 → 分派 Agent → 验证结果 → 记录状态 → 开启下一轮 |
| 生命周期 | 一次会话内 | 跨会话、跨时间 |
Loop 的常见触发方式：按时间（定时）、按事件（PR 创建、CI 失败）、按目标（直至条件满足），并配合多 Agent 并行与跨会话状态。
2.3 Loop 的五个构件 + 一个记忆
| 构件 | 职责 | Claude Code 对应能力 |
|---|---|---|
| ① 调度 / 心跳 | 决定何时启动与做什么 | 定时任务 / Cron、/loop、Hooks、GitHub Actions |
| ② 隔离 / Worktrees | 并行 Agent 互不冲突 | git worktree、子代理 isolation: worktree |
| ③ 技能 / Skills | 将技术栈、构建步骤、踩坑写入外部约定 | .claude/skills/SKILL.md、CLAUDE.md、项目 docs/ |
| ④ 连接器 / Connectors | 访问工单、数据库、API、通知系统 | MCP 服务与插件 |
| ⑤ 子代理 / 制作者-检查者分离 | 由独立检查者避免执行者自我说服 | .claude/agents/ 子代理、/goal 独立评估器 |
| ⑥ 记忆 / Memory | 持久化跨会话状态 | Markdown 进度文件、看板 |
两条原则：
- Agent 会忘，仓库不会忘：状态必须落在会话之外的持久化载体中。
- 制作者与检查者分离：独立检查者是可靠停止条件的关键。
3. Claude Code 中的 /loop 与 /goal
3.0 为什么 Automode 不够
/loop 与 /goal 解决的不是”能否完成”，而是：人不在场时，任务能否继续，并知道什么时候算完成。
- 回合自动衔接：无需每轮手动点击”继续”；
- 独立完成判定：由独立判定器而非执行模型决定是否完成；
- 按节奏唤醒：定时或事件触发，不必守着时钟。
3.1 两条命令速览
| 方式 | 下一回合何时开始 | 停止条件 |
|---|---|---|
/goal | 上一回合完成后立即检查 | 独立模型确认用户定义的条件已满足 |
/loop | 到达时间间隔时 | 手动停止，或 Claude 判断工作已完成 |
/loop 管节奏（何时触发），/goal 管收口（做到何种程度才算完成）；可单独或组合使用。
3.2 /loop：定时调度器
/loop 是会话级定时调度器，可以用自然语言指定间隔和任务。
1. 固定间隔 + 指定任务
# 每 5 分钟检查一次部署状态
/loop 5m 看看这次部署完成了吗，把发生了什么告诉我间隔可写在前或后（如 5m、every 5m），单位包括 s、m、h、d；秒会向上取整到分钟，不能整除的间隔会被调整到最近合法值并告知实际值。
2. 自适应间隔
/loop 检查 CI 过了没，并处理新的 review 评论不指定间隔时，Claude 根据变化情况在 1 分钟至 1 小时内动态选择下次执行时间；一般比固定间隔更省 Token。
3. 裸 /loop：维护模式
/loop默认执行：续上未完成工作 → 维护当前分支 PR（评论、构建、冲突）→ 无事可做则清理（找 Bug、简化代码）。可用 .claude/loop.md 或 ~/.claude/loop.md 替换默认清单。
| 规则 | 含义 |
|---|---|
| 会话级安全网 | 循环与当前会话绑定，关闭终端即停止；关机后仍要运行，用桌面 Routines 或 GitHub Actions |
| 7 天自动过期 | 每个循环 7 天后自动停止（最后执行一次再删除） |
| 并发上限 | 单会话最多同时运行 50 个循环 |
| 错过执行 | 忙时错过的轮次，在空闲后最多补一次 |
| 整点抖动 | 整点任务可能随机延迟最多 30 分钟，需精确执行时避开整点（如 09:03） |
| 全局禁用 | 环境变量 CLAUDE_CODE_DISABLE_CRON=1 |
也可嵌套其他命令：
/loop 20m /review-pr 1234适用场景：部署 / CI / 健康检查轮询、定期汇总、PR 看护等真正需要周期性执行的事项。
3.3 /goal：目标导向的自主执行器
/goal 让 Agent 围绕一个可验证完成条件持续多轮执行，直至达标或手动停止。
/goal 把这份调研笔记整理成结构化提纲，每个要点配一句说明，直到没有空标题核心机制：执行与评判分离
- 输入
/goal <条件>后，主模型执行第一轮工作； - 每轮结束，系统把目标条件与对话历史交给独立轻量评估模型（默认 Haiku）；
- 评估器只判断条件是否满足：不满足则返回原因，主模型据此继续下一轮；满足则自动清除目标并结束。
独立评估可避免执行模型把”做了很多”误判为”已经完成”。
好目标的三件套
| 要素 | 要求 | 示例 |
|---|---|---|
| 可测量的终态 | 用测试退出码、文件数、空队列等明确结果 | 不写”优化性能”，而写”API 响应降至 200ms 以内” |
| 明确的验证方式 | 说明如何在对话中呈现验证证据 | npm test 退出码为 0、git status 无修改 |
| 不可触碰的约束 | 划清变更边界 | 只改 test/auth，不删除现有功能 |
评估模型只认主模型在对话中明确呈现的内容，不自行运行命令、也不读文件。所以”写得好不好”这类主观判断，不适合作为
/goal的停止条件。
| 模糊 / 不可验证 | 明确 / 可验证 |
|---|---|
| 优化项目性能 | API 响应降到 200ms 以内，且不改核心业务逻辑 |
| 修复代码 Bug | 修复登录模块 Bug，全部测试通过且 lint 无警告 |
| 整理项目文件 | 将 src 按模块拆分，每个文件不超过 300 行且无未用依赖 |
适合 /goal 的任务包括代码迁移、需求落地、重构、清积压、质量管控。建议加安全阀，如 or stop after 20 turns 或 or stop after 90 minutes。
3.4 分工与组合
/goal：条件驱动；上一回合结束即检查，满足条件才停止。
/loop：时间驱动；按间隔触发下一轮。
Auto Mode：免除每个工具调用的人工确认。结合 Auto Mode、/goal 与 /loop 可实现无人值守运行；前提是目标、验证与安全边界均足够清晰。
4. 日常实践：两个例子
实践 A：每日开发总结
# 定时版：每个工作日 19:00 自动执行
/loop 每个工作日晚上7点，扫一遍 ~/pycode 下所有项目今天的 git 提交和改动，
整理成「今日开发总结」（按项目分组：做了什么 / 为什么 / 影响 / 明天待办），
新建一篇文档发到我的团队文档空间
# 手动版：下班前执行并确保完成
/goal 读 ~/pycode 今天有改动的项目的 git log 和 diff，写一份「今日开发总结」，
新建到我的团队文档空间；直到文档已创建、且每个项目都写清了 做了什么/为什么/影响/待办此例用了三种构件：① 心跳（定时触发）、④ 连接器（写入文档空间）、⑥ 记忆（文档沉淀）。它属于较安全的用法：只读 Git + 新建文档，不修改既有内容。
实践 B：每周周报
/loop 每周四17点，把 ~/pycode 各项目本周提交按「功能 / 修复 / 重构 / 测试 / 文档」归类，
生成周报草稿（本周完成 / 进行中 / 下周计划），发到我的团队文档空间周报是典型的按节奏、可无人值守、产出草稿后再人工微调的任务。
5. 业务实践
5.1 前后端项目：绿灯闭环与 PR 看护
/goal npm test 过、lint 干净、build 成功；直到三个全绿
/loop 5m 看这个 PR 的 CI 过没过，红了就拉日志、定位、推修复
/goal src/ 全部 strict 模式编译、零 error、0 个 any/goal 负责把可验证工作自动跑到绿，/loop 负责持续看护需要轮询的状态。
5.2 十个通用场景模板
| # | 场景 | 方式 | 做什么 |
|---|---|---|---|
| ① | 深度调研 | /loop | 每轮挑一个未覆盖角度，搜关键词、读文章，追加 300–500 字到 report.md，全覆盖后写”调研完成”并停 |
| ② | 官网 / 文档 SEO 体检 | /loop 1h | 逐篇检查 frontmatter、关键词、内链、结构化数据，不合格项写入 seo-audit.md |
| ③ | 竞品 / 动态监控 | /loop 30m | 搜索竞品动态，只追加未记录的新条目，无新增则不写 |
| ④ | 批量任务推进 | /goal | 按顺序处理 tasks.md 的”待处理”条目，卡住的标”需人工”并跳过，直到清空 |
| ⑤ | 文档 / 文件批量生成 | /goal | 逐个创建 file-list.md 里的文件，已存在则跳过，全部标完即停 |
| ⑥ | 通宵代码重构 | /goal | 按关注点拆模块，每拆一个跑一次测试，连续 3 次失败标”需人工” |
| ⑦ | 每日资讯摘要 | /loop 24h | 搜过去 24 小时相关新闻，筛前 10 条写摘要加链接，按重要性排序 |
| ⑧ | 内容创作管线 | .claude/loop.md | 在 loop.md 里定义”选题 → 调研 → 初稿 → 自检 → 待发布”逐级推进 |
| ⑨ | Skill 自改进 | /loop 2m | 每轮只改一处提示词，跑 eval 用例，通过率提升则保存并提交，否则回滚 |
| ⑩ | 全站改进编排 | /loop 10m | 每轮从”修 bug > 补测试 > 更文档 > 清冗余 > 改错误处理”选一件做并提交 |
5.3 成本与安全红线
每个 Loop 都必须考虑两条红线： 缓存窗口约 5 分钟——间隔 ≤ 5 分钟可复用模型缓存，成本低；间隔过大缓存过期，每轮可能按全价重新计算。 提示先做预检查——每轮开头先判断是否存在待办，无任务就零成本退出，否则会在没有工作时仍执行整套流程。
6. 进阶模式
6.1 Checker Agent：双会话互审
同时运行两个 Claude Code 会话：
- 主会话：实现功能、推进项目；
- 检查会话：每 15 分钟通过
/loop审查主会话产出。
二者共享项目文件但对话上下文隔离；检查会话不了解作者意图，只审查文件变化，更容易发现主会话因上下文积累而自我说服、遗漏的问题。这是”制作者 / 检查者分离”的直接实现。
6.2 VISION.md：方向锚定
长程循环可能漂移，尤其在上下文压缩后。解决办法是在项目根目录建立 VISION.md，写明北极星目标和关键约束，并让每轮第一步读取它。
CLAUDE.md：项目记忆，面向 Agent；VISION.md：方向锚，面向长程循环。
当循环超过 10 轮时，建议加入 VISION.md。
7. 它移走的是杠杆点，不是责任
Loop 改变工作方式，但不消除人的责任。随着 Loop 能力增强，下列风险反而更加重要：
| 风险 | 含义 | 应对方式 |
|---|---|---|
| 验证责任 | 无人值守的 Loop 也会无人值守地制造错误；“通过验证”是声明，不是证明 | 合并前人工审查不能取消 |
| 理解债 | Loop 产出越快，“仓库中有什么”和”你真正理解什么”的差距越大 | 主动阅读 Loop 生成的代码 |
| 认知投降 | Loop 自动运行后，最危险的是不加判断地接受所有结果 | 以判断力设计 Loop，不把它当作逃避思考的工具 |
参考文献
- Addy Osmani — Loop Engineering：递归目标、五构件 + 记忆、Harness / Loop 边界与风险。
- Boris Cherny / Peter Steinberger 原始观点（X）：Peter Steinberger、Boris Cherny 转述。
- Claude Code 官方文档：让 Claude 朝着目标工作：
/goal、/loop与调度机制。 - Cobus Greyling — loop-engineering：第三方开源实现，借鉴 Osmani 思路。
- Addy Osmani 相关概念：Agent Harness Engineering、Comprehension Debt、Cognitive Surrender。