Claude Code Loop Engineering: 从提示工程到循环工程

你不再应该向编程代理输入提示，而应该设计提示代理的循环系统。

2026 年，AI 编程领域出现了一个关键转折点。Anthropic 的 Boris Cherny（Claude Code 的创建者和负责人）在采访中说了一句引发广泛讨论的话：

“我不再直接向 Claude 输入提示了。我有多个循环在运行，它们负责提示 Claude 并决定下一步做什么。我的工作变成了编写这些循环。”

这句话与 OpenAI 工程师 Peter Steinberger 的帖子、Google 工程师 Addy Osmani 的结构化文章一起，定义了一个新范式——循环工程（Loop Engineering）。

这篇文章将带你深入理解 Loop Engineering 是什么、为什么重要，以及如何在 Claude Code 中实践它。

一、什么是 Loop Engineering？

从 ReAct 到自主循环

Loop Engineering 的核心思想源于 2022 年 Princeton 和 Google 研究人员提出的 ReAct 框架——将推理（Reasoning）和行动（Action）交织在一个重复循环中：

1. 思考：模型分析当前状态，决定需要什么
2. 行动：调用工具（读文件、运行测试、编辑代码）
3. 观察：获取行动结果
4. 重复：回到思考阶段，直到任务完成

Claude Code 的代理循环（Agentic Loop）正是这一模式的生产级实现。

四层技术栈

大多数团队将以下四个层次混为一谈，但它们是独立且层层嵌套的：

层次	关注点	问题表现
提示工程	单次提示的质量	回答不够好
上下文工程	模型看到什么信息	回答与项目不相关
循环工程	行动/验证/重复的节奏	代理无法完成任务
框架工程	运行环境与工具链	代理无法安全执行

Loop Engineering 位于第三层——它关心的是：当开发者不在场时，什么系统将决定下一步行动？

二、为什么需要 Loop Engineering？

大语言模型的核心约束

LLM 本质上是无状态的——它们会忘记会话之间的所有内容。每一次持久上下文——每个项目规则、每个之前的决定、每个任务的中间结果——都必须存在于模型之外：在磁盘文件中、在 git 仓库里、在结构化的记忆文档中。

Loop Engineering 就是针对这一约束的系统设计响应：构建一个小型系统来外部持有上下文，决定何时提示，调度代理，并检查工作是否完成。

从手动到自动的转变

交互模式	适合场景	局限
单次提示	写一个函数、修一个 bug	复杂度有上限
手动多轮对话	需要几步推理的任务	开发者必须全程在场
自主循环	多步骤、需适应的长时间任务	需要精心设计约束条件

对于需要超过几步、需要根据反馈调整、或者希望在开发者做其他事时自动运行的任务，手动的一轮轮交互模式会因自身开销而崩溃。

三、Claude Code Loop Engineering 六要素

Addy Osmani 在 2026 年 6 月的文章中识别出六个核心构建块，它们几乎完美映射到 Claude Code 的当前功能集：

1. 调度触发器（Scheduling / /loop）

循环需要自主启动——定时器、git 事件、CI 信号。Claude Code 的 /loop 命令运行在指定间隔上；如果不指定间隔，它会根据输出自我调节节奏。

# 每5分钟检查并修复构建问题
/loop 5m 检查构建状态并修复任何失败

2. 工作隔离（Isolation / worktrees）

并行代理不能互相覆盖工作。两个代理编辑同一个文件产生的冲突，就像两个工程师在同一行代码上提交。Claude Code 的 worktree 设置为每个子代理创建一个干净的 git 检出版本，任务完成后自动清理。

3. 技能库（Skills / SKILL.md）

技能是保存的项目知识库，让代理不需要在每个会话中重新学习同样的上下文。SKILL.md 文件可以包含：

---
name: api-conventions
description: REST API 设计约定
---

# API 约定
- 使用 kebab-case 作为 URL 路径
- 使用 camelCase 作为 JSON 属性
- 列表端点始终包含分页

4. MCP 连接器（Model Context Protocol）

MCP 服务器给循环提供真实工具的访问权限：GitHub、Slack、Linear、外部 API。没有连接器，循环只能看到本地文件系统。

5. 制造-检查分离（Maker-Checker Separation）

这是最关键的设计模式。一个子代理写代码，另一个独立的子代理运行测试、读取 lint 输出、报告失败。写代码的代理不应该给自己打分。

# 在 Claude Code 中使用 /goal 自动实现制造-检查分离
/goal 所有测试通过且 lint 干净

Claude Code 的 /goal 命令（2026年5月在 2.1.139 版本中引入）使用一个独立的、更快的模型来检查完成条件——生成代码的模型和评估工作的模型是不同的实例。

6. 持久状态（Persistent State / CLAUDE.md）

循环之间需要穿过会话边界的知识。最常用的实现是 CLAUDE.md——项目级别的 Markdown 文件，Claude Code 在每个会话开始时自动读取。

当代理反复犯同一个错误时，正确做法是让代理将教训写入 CLAUDE.md，这样修正会传播到所有未来会话，而不是停留在一次对话中。

四、实操：七个最佳实践

根据 Anthropic 官方文档和社区经验，以下是提升 Claude Code 使用效果的核心技巧：

1. 给 Claude 可验证的检查点

这是最重要的一个技巧。给 Claude 一个它可以运行并检查的测试、构建命令、或截图对比——你就不用守着它。

场景	差的做法	好的做法
实现函数	“实现一个邮箱验证函数”	“写一个 validateEmail 函数。测试用例：user@example.com 为 true，invalid 为 false。实现后运行测试”
UI 修改	“让仪表盘更好看”	“[粘贴截图] 实现这个设计。截屏并将结果与原图对比，列出差异并修正”
修复构建	“构建失败了”	“构建失败原因：[粘贴错误]。修复并验证构建成功。定位根本原因，不要屏蔽错误”

2. 先探索，后计划，最后编码

使用 Claude Code 的计划模式（plan mode） 将探索和执行分离：

四阶段工作流：

1. 探索（计划模式）：Claude 读取文件，回答问题，但不做修改
2. 计划（计划模式）：Claude 创建详细实施计划，按 Ctrl+G 编辑计划
3. 实现（默认模式）：Claude 按计划编码，编写并运行测试
4. 提交（默认模式）：Claude 提交并创建 PR

对于小改动（修复拼写、添加日志、重命名变量），直接跳过计划阶段，效率更高。

3. 提供丰富的上下文

• 使用 @ 引用文件而不是口头描述路径
• 直接粘贴截图或拖放图片
• 给出文档 URL（使用 /permissions 添加域名白名单）
• 通过管道传入数据：cat error.log | claude

4. 写好 CLAUDE.md

运行 /init 生成初始文件，然后持续迭代优化。

好 CLAUDE.md 的法则： 对每一行问：“删除这一行会导致 Claude 犯错吗？” 如果不会，删掉它。

应该包含	不应该包含
Claude 猜不到的 Bash 命令	Claude 能从代码读出的信息
与默认不同的代码风格	已知的语言规范
测试指令和首选测试框架	详细的 API 文档（用链接代替）
仓库规范（分支命名、PR 约定）	频繁变化的信息
开发者环境特殊配置（必需的环境变量）	文件级代码描述
常见陷阱和非明显行为	自明之理（如"写干净的代码"）

5. 使用子代理（Subagents）进行调研

在 CLAUDE.md 中定义专用子代理：

# .claude/agents/security-reviewer.md
---
name: security-reviewer
description: 审查代码安全漏洞
tools: Read, Grep, Glob, Bash
---

你是一名高级安全工程师。审查代码中的：
- 注入漏洞（SQL、XSS、命令注入）
- 认证和授权缺陷
- 代码中的密钥或凭证
- 不安全的数据处理
提供具体的行引用和修复建议。

使用时：“使用子代理审查这段代码的安全性问题。”

6. 使用非交互模式（-p）进行自动化

# 一次性查询
claude -p "解释这个项目是做什么的"

# 结构化输出用于脚本
claude -p "列出所有 API 端点" --output-format json

# 流式 JSON 输出
claude -p "分析这个日志文件" --output-format stream-json --verbose

7. 引入对抗性审查（Adversarial Review）

在任务完成前，让一个独立的子代理在全新的上下文中审查 diff：

“使用子代理对照 PLAN.md 审查 rate limiter 的 diff。检查所有需求是否都已实现，列出的边界情况是否都有测试，任务范围之外的内容是否未改动。报告差距，不是风格偏好。”

五、Loop Engineering 的进阶模式

动态工作流（Dynamic Workflows）

2026年5月28日，Anthropic 推出了 Dynamic Workflows（研究预览版）。其架构变化是将编排计划完全移出模型的上下文窗口：

• Claude 为当前任务编写 JavaScript 编排脚本
• 后台运行时执行该脚本
• 编排逻辑（循环、分支、代理数量决策、验证轮次）存在于脚本变量中，而非模型的工作内存中
• 每个子代理获得干净、聚焦的上下文窗口
• 一个工作流最多支持 1000 个代理，16 个并发运行
• Salesforce 报告使用该功能将原本需 231 天的迁移在 13 天内完成

Writer/Reviewer 模式

这是一种不需要 Dynamic Workflows 也能使用的简单并行模式：

会话 A（Writer）：为我们的 API 端点实现速率限制器

会话 B（Reviewer）：审查 @src/middleware/rateLimiter.ts 中的速率限制器实现。
查找边界情况、竞争条件以及与现有中间件模式的一致性。

然后答复：将审查反馈发回会话 A。

技能 + 循环组合

“如果你重复做某件事超过一次，把它变成技能。如果某件事很难，做完后也把它变成技能，这样下次就免费了。”

有价值的循环调用一个精心打磨的、经过测试的、有名字的技能库。循环是路由器；技能是完成工作的人。

六、成本管理的冷思考

Loop Engineering 的讨论中常常被低估的是成本问题：

• 循环中的每个工具调用都会增加上下文，这些上下文会在后续的所有调用中重新发送
• 到第 20 次迭代时，单次输入可能超过 50,000 tokens
• 以 Opus 4.8 的 $5/百万输入 tokens 计算，一次后期循环步骤约 $0.25
• 一个 200 次迭代的自主会话可能花费 $80 以上
• 有开发者反馈在单次周末自主重构中产生了 $4,200 的 API 费用

企业应用的数据更为明确：

• Uber 在四个月内烧光了 2026 年全年的 Claude Code AI 预算
• Microsoft 的体验与设备部门在 2026 年 6 月终止了大多数 Claude Code 许可
• 大规模团队的每开发者月均成本在 $150-$250（优化前）

2026 年 6 月 15 日起，Anthropic 将自动化工作负载划入独立的月度积分池（Pro 用户 $20，Max 用户 $200），超额后自动停止。

七、常见失败模式

模式	症状	解决方案
厨房水槽会话	在一个会话中掺入多个不相关任务，上下文充满噪音	在无关任务间使用 /clear
反复修正	Claude 做错了，你纠正，它继续错，你再纠正	两次纠正后 /clear，用更精准的提示重新开始
过于冗长的 CLAUDE.md	文件太长，Claude 忽略了一半内容	坚决精简，只保留如果删除就会导致 Claude 犯错的内容
信任-验证差距	Claude 产出看起来合理的实现，但不处理边界情况	始终提供可验证的检查（测试、脚本、截图）
无限探索	你要求 Claude 无范围地"调查"某事，它读了数百个文件	精确界定调研范围，或使用子代理

八、结语

Loop Engineering 不是提示工程的替代品——它是它的下一个进化阶段。

值得构建的第一个 Claude Code 循环不是完全自主的工程师替代品，而是一个针对某个反复出现的痛点的有限修复器：

• 把重复的迁移检查清单变成 goal 文件加 hooks
• 在狭窄的测试边界内重构核心子系统

LLM 是无状态的——每个持久上下文必须存在于模型之外。写代码的代理不应该评估自己的工作。循环的好坏取决于它收到的反馈信号，而反馈信号的好坏取决于你设计的验证器。

真正的杠杆来自精确的验证器和具体的完成条件。

---

本文参考了以下来源：

• Anthropic Claude Code 官方文档 - Best Practices
• Anthropic Claude Code 官方文档 - How Claude Code Works
• Addy Osmani - Loop Engineering
• TechTimes - Claude Code Loop Engineering
• Explainx.ai - Loop Engineering Guide