循环工程（Loop Engineering）调研：从写提示词到设计自循环系统，2W1H + 五种模式 + 何时该用

51次阅读
循环工程（Loop Engineering）调研：从写提示词到设计自循环系统，2W1H + 五种模式 + 何时该用

2026 年 6 月 AI 编程圈最热新概念——Google 工程师 Addy Osmani 系统整理，Boris Cherny 和 Peter Steinberger 引爆，三个人的共识：你不该再手动提示 Agent 了。

写在前面

过去两年 AI 工程的演进路径非常清晰：

怎么写提示词（Prompt）↓
给 AI 什么上下文（Context）↓
如何编排工具链（Harness）↓
如何让 AI 自己持续跑（Loop）

每一层都没有否定前一层，而是在它上面多了一个维度。Prompt Engineering 没有死，但它已经不够用了——当你的 Agent 能自己规划、自己执行、自己验证的时候，你写再好的单条提示词也只是整个系统里的一个齿轮。

循环工程就是关于那个齿轮之上的系统：你怎么设计它、让它什么时候跑、跑多久、怎么判断完成了、失败了怎么办。

这篇文章用 2W1H 拆清楚这个概念，然后告诉你什么时候该用它、什么时候不该。

一、它是什么（What）

循环工程（Loop Engineering）是设计、运营和持续改进 反馈循环系统 的工程实践——这些循环让 AI 编程 Agent 能够自主完成规划 → 执行代码修改 → 观察结果 → 调整计划 → 直到任务真正完成。

一句话概括：

循环工程是把你从 ” 提示 Agent 的人 ” 变成 ” 设计让 Agent 自己提示自己的系统 ” 的工程师。

核心概念：内循环 vs 外循环

每个 Agent 内部已经有一个基础的内循环：

感知（Perceive）→ 推理（Reason）→ 行动（Act）→ 观察（Observe）→ 再次循环

循环工程工作在内循环的 上一层——你设计一个外部系统去驱动内循环，而不是你亲自坐在旁边打下一条指令。

层级 谁在驱动 做什么
内循环（Agent 内置） Agent 自身 读文件 → 修改代码 → 运行测试 → 读错误 → 再修改
外循环（你设计的） 自动化系统 发现任务 → 分派 Agent → 验证结果 → 记录状态 → 开启下一轮

你不坐在 Agent 旁边。你设计一套外部系统，它替你驾驶内循环。

二、为什么需要它（Why）

2.1 提示词工程的天花板

第一代 AI 编程工具（GitHub Copilot 早期）：补全当前行，人类主导所有决策。

第二代（ChatGPT / Claude.ai）：问一句答一句，人类手动推进每一步——人类成了速度瓶颈。

第三代（Claude Code / Codex）：Agent 自己规划、执行、验证。但 如何设计让 Loop 可靠运行的系统 成了新的瓶颈。

Boris Cherny（Anthropic Claude Code 负责人）的原话：

“I don’t prompt Claude anymore. I have loops running. They’re the ones prompting Claude and figuring out what to do. My job is to write loops.”

Peter Steinberger（OpenClaw 作者）的推文：

“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”

关键转折：瓶颈从 ” 写提示词的能力 ” 转移到了 ” 设计循环系统的能力 ”。

2.2 循环 vs 提示词：本质区别

维度 Prompt Engineering Loop Engineering
优化对象 单条指令 自运行的完整系统
工作单位 一次手动输入 跨越多轮自动工作流
成功衡量 第一个回复质量 最终输出结果质量
失败模式 模型给出差劲回答 循环设计不良：停太早 / 忽视错误 / 无法验证
对 Agent 视角 手持的工具 调度的长期运行进程

三层技术栈完整关系：

Prompt Engineering  ── 怎么措辞一条指令
       ↑
Context Engineering ── 放什么进上下文窗口
       ↑
Loop Engineering   ── 决定提示什么、何时提示、结果是否可接受

Loop Engineering 包含 Prompt Engineering，但远不止于此。

2.3 内循环的五个阶段

一个 Agent Loop 的基础结构，五个阶段首尾相连：

阶段 做什么 信号来源
意图（Intent） 定义目标：成功是什么、约束是什么 开发者 / Issue / CI 报告
上下文（Context） 收集相关代码、文档、报错、规范 代码库、测试输出、历史对话
行动（Action） 编辑文件、运行命令、调用工具 Agent 自主执行
观察（Observation） 获取测试结果、编译错误、运行时输出 测试框架、CI、人工 Review
调整（Adjustment） 根据观察更新计划，再次循环 下一轮内循环

Loop 的力量不在于任何单独步骤，而在于 闭环。测试失败不只是一条错误消息——它是新的上下文；类型错误不只是阻断，它是一个关于错误假设的信号。

三、六大构成要素

一个能真正独立运行的 Loop 需要五个核心组件 + 一个贯穿始终的记忆系统。

要素一：自动触发器（Automations）

循环的心跳。没有自动触发，Loop 就只是 ” 你做了一次的操作 ”。

# Claude Code /loop 命令：每天工作日 9 点运行
/loop " 读取前一天的 CI 失败和 Issue，写入 TODO.md，为 quick-win 问题起草修复 " \
      --schedule "0 9 * * 1-5"

# /goal：持续执行直到条件成立
/goal "test/auth 全部通过且 lint 干净 "

OpenAI Codex 在 Automations 标签页可视化配置，OpenAI 内部用它做日常 issue 分诊、CI 失败总结、commit 简报。

⚠️ Token 成本警告：带验证子 Agent 的定时 Loop 每次触发都消耗 Token。建议先慢节奏（每天一次），观察几天成本后再加快。

要素二：并行隔离（Worktrees）

多个 Agent 同时跑，文件冲突是最大风险。Git Worktree 给每个 Agent 提供独立工作目录，共享同一个 Git 历史但文件改动完全隔离。

# 手动创建
git worktree add ../agent-fix-auth feature/fix-auth-tests
git worktree add ../agent-upgrade-deps feature/upgrade-axios

# Claude Code：在 .claude/agents/ 中设置 isolation: worktree
# Codex：内置 worktree 支持，多个线程互不干扰

Worktree 只消除了机械碰撞。你处理和批准代码变更的速度，才是你能并行运行多少个 Agent 的真正上限。

要素三：技能文件（Skills）

解决 ” 每次新对话 Agent 都要从零推断项目规范 ” 的浪费。

SKILL.md 写明项目约定、构建步骤、” 我们不这样做是因为那次事故 ”。Agent 每次会话开始时加载 Skill，不重新猜测。

# .claude/skills/project-conventions/SKILL.md
name: project-conventions
description: 项目编码规范和构建步骤，凡是涉及代码修改的任务都应加载此技能。# 技术栈
- 后端：Node.js 20 + TypeScript + Fastify
- 数据库：PostgreSQL 16 + Drizzle ORM
- 测试：Vitest（放在 src/ 同级的 __tests__/）# 核心约定
- 所有数据库查询必须经过 src/db/queries/ 封装
- 错误统一使用 AppError 类
- 新增 API 必须同时更新 docs/api.md

Skill 是创作格式，Plugin 是分发方式。跨仓库共享 Skill 时封装为 Plugin。

要素四：连接器（Connectors / MCP）

只能看本地文件系统的 Loop 是一个很小的 Loop。MCP（模型上下文协议） 让 Agent 能读取 Issue 追踪、查询数据库、调用 API、在 Slack 发消息。

// .claude/mcp.json
{
  "connectors": [
    {
      "name": "github",
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {"GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    }
  ]
}

这是 ”Agent 说 ’ 这里是修复方案 '” 和 ”Loop 自动开 PR、关联 Ticket、CI 通过后通知频道 ” 之间的核心差异。

要素五：子 Agent（Sub-Agents）

“ 制造者 - 检查者 ”（Maker-Checker）模式：写代码的和检查代码的必须是两个 Agent。

写了代码的模型在评分自己作业时总是倾向宽容。一个有不同指令的独立检查器——有时还使用不同的模型——能抓住第一个 Agent 自圆其说忽略的问题。

# .claude/agents/spec-reviewer.md
name: spec-reviewer
description: 对完成的代码变更进行对抗性审查，验证其符合规范和测试要求。model: opus          # 更强模型做验证
isolation: worktree  # 独立检出，避免污染

Claude Code 的 /goal 命令在每次迭代后会用 单独的模型 判断是否 ” 完成 ”，而不是让做了工作的那个模型来判断。

要素六：持久记忆（Memory）

模型在每次对话之间完全遗忘。解决方案极其简单：把状态写在文件里，文件放在仓库里。

<!-- TODO.md — Loop 的状态文件，随代码一起提交 -->
# Loop 任务状态
## 进行中
- [ ] test/auth/login.spec.ts 中的 flaky test（CI #4821，失败 3 次）- 已尝试：隔离 DB 连接 → 无效
  - 下一步：检查 beforeEach 中的 cleanup 逻辑
## 已完成
- [x] 修复 billing 模块含单引号公司名称导致的 500 错误（PR #312，已合并）

Agent 会遗忘，仓库不会。

四、五种常见 Loop 模式

不同类型的工作需要不同的反馈信号和停止条件。

模式 观察信号 停止条件 典型场景
测试驱动 Loop 测试通过 / 失败 全部测试通过 Bug 修复、回归测试、数据转换
编译器驱动 Loop 类型错误、编译错误列表 零错误 TypeScript 迁移、依赖升级、重构
Review 驱动 Loop 人工 Review 评论 所有评论被处理或记录忽略 PR Review 的机械性跟进
运行时调试 Loop 日志、堆栈跟踪、HTTP 响应 问题可复现 → 修复验证 生产 Bug、性能问题
产品迭代 Loop 截图、浏览器检查、可访问性报告 与设计稿对齐、响应式正常 落地页、UI 调整

五、何时该用（How / When）

5.1 适合用 Loop 的场景

✅ 有明确可验证停止条件的任务

  • “ 让 test/auth 全部通过且 lint 干净 ”——有明确的验证命令
  • “ 修复这个 flaky test，连续跑 5 次不失败 ”——可量化的成功标准
  • “ 升级 axios 到 1.7.x，所有测试通过 ”——有边界、有验收

✅ 日常维护自动化

  • 每天早上自动读取前一天 CI 失败和未关闭 Issue
  • 定时扫描 quick-win 标签的问题，起草修复方案
  • Codex 内部在用的：日常 issue 分诊、commit 简报

✅ 制作者 - 检查者分离有价值的地方

  • 大型 PR 的代码审查跟进
  • 多个独立 Feature 的并行开发（worktree 隔离）
  • 跨项目一致的编码规范执行

5.2 不该用 Loop 的场景

❌ 复杂项目从零开发

从头构建一个有复杂业务逻辑的大型系统，当前 Loop 还不成熟。更适合的是 ” 对已经运转良好的项目进行日常维护自动化 ”。

❌ 没有明确停止条件的任务

“ 优化仪表盘性能 ”——太模糊，Agent 不知道什么时候算完成。改成 ” 将首次加载时间减少 30%，通过 Lighthouse 验证 ”。

❌ 简单的一次性任务

直接写一条好提示词更快、更便宜。给一个小任务套完整的 Loop 基础设施是杀鸡用牛刀。

5.3 三分钟判断清单

任务有明确的验证命令吗？→ 没有 → 直接用提示词
需要循环执行直到条件满足吗？→ 不需要 → 直接用提示词
有可验证的 " 完成 " 标准吗？→ 没有 → 先定义成功条件，再考虑 Loop
任务重复发生或会持续一段时间吗？→ 否 → 直接用提示词
需要多个 Agent 并行互不干扰吗？→ 不需要 → 直接用提示词
5 个问题都 → 是 → 走 Loop Engineering

六、三个尚未解决的问题

即使 Loop 体系设计得再好，有三件事目前仍然只能靠人来处理。

问题 1：验证仍然是你的责任

无人值守运行的循环也是无人值守犯错的循环。拆分验证子 Agent 就是为了让 ” 完成了 ” 有意义，但 ” 完成 ” 是一个声明而不是证明。

你的工作是发布你确认能用的代码。

问题 2：” 理解债 ” 会增长

循环越快地发布你没写过的代码，存在什么和你实际理解什么之间的差距就越大。这是 Comprehension Debt（理解债），顺畅的循环只会让它增长更快，除非你读循环产出的东西。

问题 3：认知投降

当循环自己运行时，很容易停止有自己的意见，照单全收。Addy Osmani 称之为 Cognitive Surrender（认知投降）。

设计循环是解药，当你带着判断去做时；设计循环也是加速剂，当你用它来逃避思考时。同样的动作，相反的结果。

七、现在就可以开始

5 件事，今天就能做：

  1. 用 /goal 替代手动循环——给 Agent 一个可验证的停止条件，让它自己跑到完成
  2. 为项目创建 Skill——把构建步骤、代码约定、历史教训写成 SKILL.md，写一次，Agent 每次运行都读取
  3. 用 Worktree 隔离并行任务——多个 Agent 同时工作时必须隔离，否则文件冲突不可避免
  4. 拆分 ” 制造者 ” 和 ” 检查者 ”——用子 Agent 做代码审查，不要让写代码的自己审查自己
  5. 建立记忆层——用 Markdown 文件记录循环状态，什么做了、什么通过了、什么还开着

参考

正文完
发表至： 技术
2026-06-22
 

近期文章

近期评论

您尚未收到任何评论。