Claude Code循环工程：超越一次性提示的四种自动化工作方式

切勿仅凭编辑成功就宣称UI变更已完成。

1. 启动开发服务器并打开已编辑页面。
2. 与修改后的控件交互，确认预期状态。
3. 必要时截取前后对比截图。
4. 检查浏览器控制台是否存在新的错误或警告信息。
5. 运行性能追踪并审查核心网页指标。

若任何检查失败，需修复问题并从步骤1重新执行。

核心思想不在于措辞本身，而在于该技能能让Claude获取与人工审核员相同的证据依据。

定量检查尤为有效：

• 控制台零错误
• 所有测试通过
• Lighthouse评分超过阈值
• 指定区域外无视觉差异变化
• 响应时间低于限制值
• 完成特定数量的验收标准

验证过程越可量化，人工干预的频率就越低。

2. 基于目标的循环机制（/goal指令）

当单轮操作可能不足但能清晰描述终点时，基于目标的循环机制尤为实用。

Claude Code不会让操作代理自行判断结果是否"足够好"，而是在每轮操作后使用独立的评估器。

触发条件

用户在当前会话中启动一个目标。

停止条件

当出现以下情况时循环结束：

• 评估器确认条件已满足，或
• 达到配置的轮次限制。

最佳应用场景

基于目标的循环适用于具有可验证终点的任务，例如：

• 通过所有身份验证测试
• 达到特定性能评分
• 将所有调用点迁移至新API
• 清空标记的问题队列
• 将每个文件控制在预设大小范围内
• 完成设计文档中的所有验收标准

基础语法

Anthropic的官方示例如下：

/goal 让首页Lighthouse评分达到90分或以上，尝试5次后停止。

另一个实用示例：

/goal test/auth目录下所有测试通过且lint步骤无报错

根据当前Claude Code文档，/goal指令需要Claude Code版本2.1.139或更高。

评估器如何改变循环机制

当Claude完成一轮操作后，一个轻量快速评估器模型会检查条件是否达成。

若条件未满足，自动开始新一轮操作；若条件满足，则清除当前目标并将会话控制权交还给用户。

这种分离之所以重要，是因为工作模型不应成为自身输出的唯一评判者。

一个有效的完成条件应具备：

• 可观察性
• 具体性
• 难以被偶然满足
• 与真实用户或系统结果相关联
• 具有最大尝试次数或其他硬性限制

弱目标与强目标条件

弱目标：

/goal 改进主页

“改进”一词未定义可衡量的终点。

强目标：

/goal 将移动端 Lighthouse 性能得分提升至至少90分，
保持可访问性在95分或以上，并在尝试5次后停止

弱目标：

/goal 修复测试

强目标：

/goal test/payments 目录下的所有测试均通过，无跳过测试，
且 npm run lint 命令退出码为0

模型不应猜测成功的含义。

/goal 不会改变权限

目标会贯穿多个回合，但它不会自动批准所有工具调用。

在默认权限模式下，Claude 仍可能对尚未允许的命令进行暂停确认。

对于无人值守的目标，Anthropic 建议在可用且适当时，将 /goal 与自动模式结合使用。这应在审查允许的工具、仓库边界及可能的副作用之后进行。

3. 基于时间的循环：/loop 和 /schedule

某些工作并非由上一回合的完成触发，而是由时间触发。

任务保持相似，但输入发生变化：

• 新的 Slack 消息到达。
• 拉取请求收到评审意见。
• CI 状态从通过变为失败。
• 依赖项发布新版本。
• 运维仪表板报告新事件。

触发条件

每次运行由配置的时间间隔或调度启动。

停止条件

本地循环在您取消、关闭环境或监控工作完成时停止。

云端例程会根据其配置继续运行，直到暂停或禁用。

最佳使用场景

基于时间的循环适用于：

• 拉取请求监控。
• 每日或每周总结。
• 定期问题分类。
• 依赖项检查。
• 定期测试运行。
• 文档漂移检查。
• 不提供事件触发的监控系统。

本地间隔循环

官方示例使用 /loop：

/loop 5m 检查我的拉取请求，处理评审意见，并修复失败的 CI

此提示按配置的间隔重新运行。

本地循环依赖于当前机器和会话。如果计算机关闭或进程停止，循环也会停止。

云端调度

对于需要在笔记本电脑合上后继续运行的工作，Claude Code 可以使用 /schedule 创建云端例程。

一个主动例程可能以如下方式开始：

/schedule 每小时：检查 #project-feedback 中的新错误报告

Claude Code 例程在 Anthropic 管理的云基础设施上运行，可由以下方式触发：

• 循环调度。
• 单次未来调度。
• API 调用。
• 支持的 GitHub 事件。

在撰写本文时，例程处于研究预览阶段，因此行为、限制和 API 界面可能会变化。可用性还取决于相关的 Claude 计划、组织策略以及是否启用了网页版 Claude Code。

谨慎选择间隔时间

一个常见错误是运行循环的频率远高于外部系统变化的速度。

如果新问题每天只出现几次，那么每分钟检查一次问题队列并无帮助。这会增加令牌使用量、工具调用次数和——

不增加噪音而影响结果。

将轮询间隔与预期变化频率相匹配：

外部变化模式	合理的起始轮询频率
活跃推送后的CI状态	每5–10分钟
团队反馈渠道	每30–60分钟
每日Slack摘要	每天上午一次
依赖项更新	每日或每周
文档偏离	每晚或每周

这些是起始建议，并非通用规则。当外部系统支持时，事件触发通常优于轮询。

4. 主动循环

主动循环是前面基本元素的组合。

它在无人值守的情况下运行，响应计划中的或传入的工作，并将每个任务项贯穿于一个定义的流程中。

触发器

一个计划任务、API请求、GitHub事件、消息、问题或其他外部信号会启动工作。

停止条件

每个独立任务在达成目标后退出。

周围的例行程序会继续接收未来的工作，直到有人将其禁用。

最佳用例

主动循环适用于定义明确的重复性工作流：

• Bug报告分类。
• 问题分类。
• 依赖项升级。
• 常规迁移。
• 重复性代码审查。
• 告警调查。
• 部署验证。
• 积压工作维护。

一个完整的主动模式示例

Anthropic的示例结合了Claude Code的几个功能：

1. /schedule 检查新的报告。
2. /goal 定义在一次运行中必须完成的内容。
3. 技能描述每个任务应如何验证。
4. 动态工作流协调多个代理。
5. 自动模式减少了交互式权限暂停。

组合指令可能如下所示：

/schedule 每小时一次：检查 #project-feedback 中的bug报告。

/goal：在此次运行中找到的每个报告
在分类、处理和答复之前，不得停止。

修复bug时，使用工作流在并行工作树中
探索三种解决方案，并由一个独立的评审员进行审查。

这不再只是一个重复的提示。它是一个针对狭窄工作流的小型操作系统。

动态工作流

动态工作流是用于大规模协调子代理的脚本。

Claude编写一个JavaScript编排脚本，运行环境在后台执行它。中间结果可以保留在脚本变量中，而不会填满主对话上下文。

Anthropic将工作流定位用于以下任务：

• 审计许多文件是否存在相同问题。
• 迁移数百个文件。
• 运行独立的研究遍历。
• 比较多个提出的解决方案。
• 审查每个更改的文件并生成一份最终报告。

当前文档说明动态工作流需要Claude Code版本2.1.154或更高。它们可以协调数十或数百个代理，因此在执行大规模生产任务之前，应先进行小规模试点。

实际改变之处：验证与停止条件

定时任务、编排、反馈循环和工作队列并非新的工程概念。

真正的转变在于，编码代理现在可以更多地参与到循环之中：

• 读取当前状态
• 选择工具
• 进行更改
• 解读错误
• 将结果与目标对比
• 尝试另一种方法
• 仅在系统无法安全运行时才升级处理

提示词并未消失。它已成为更大控制系统中一个组成部分。

如今更重要的设计问题变成了：

• "完成"意味着什么？
• 由谁来决定条件已满足？
• 哪些检查是确定性的？
• 代理能检查哪些证据？
• 最大尝试次数是多少？
• 令牌或成本预算是多少？
• 如何检测到缺乏进展？
• 哪些操作需要人工批准？
• 运行失败后该如何处理？

精心编写的提示词无法弥补缺失的停止条件。

验证是影响力最大的改进

Anthropic 反复强调验证：让 Claude 能够检查和衡量自身的输出。

如果人类工程师在没有浏览器访问权限的情况下被要求构建一个页面，就等于在盲目工作。代理的情况也类似。

有用的验证工具包括：

• 测试套件
• 类型检查器
• 代码检查工具
• 构建命令
• 浏览器自动化
• 截图与视觉对比
• 性能追踪
• 数据库查询
• API 响应断言
• 安全扫描器
• 静态分析
• 可复现的验收脚本

尽可能优先采用确定性检查

一个返回退出码0或1的脚本通常比要求模型从头推理某个需求是否已满足更加便宜且可靠。

例如：

npm test
npm run lint
npm run typecheck

一个组合的验证脚本可以是：

#!/usr/bin/env bash
set -euo pipefail

npm run typecheck
npm run lint
npm test

Claude 可以在每次更改后运行此脚本。该循环无需每次都重新解释整个验收过程。

使用第二个代理进行审查

Anthropic 还建议使用具有新上下文的审查者。

实施代理已经看到了自己的推理过程，可能会重复相同的假设。独立的审查者不那么受限于该路径，可以从另一个角度检查结果。

对于高价值的更改，系统可以使用：

• 一个代理负责实施
• 一个代理负责检查正确性
• 一个代理负责检查安全性
• 一个确定性测试套件作为最终把关

代理并非越多越好。只有当审查价值能证明额外成本合理时，才添加它们。

无防护门循环的危险性

可以无限持续下去的循环既强大又危险。

存在三种主要的故障模式。

1. 成本失控

每轮循环都可能消耗输入令牌、输出令牌、工具调用和付费模型使用量。

如果没有轮次或预算上限，开放式的循环可能会持续消耗费用，同时只产生很少的额外价值。

Claude Agent SDK 同时支持：

• max_turns / maxTurns
• max_budget_usd / maxBudgetUsd

官方 SDK 文档指出：

默认情况下，两种限制均未设置。

对于生产环境中的智能体，明确限制是合理的基准。

2. 虚假进展

智能体可能反复编辑相同文件，却未产生新的通过测试或可衡量的改进。

即使系统在循环尝试同一失败方案的不同变体，记录日志可能仍显得活跃。

有用的无进展信号包括：

• 连续多轮运行中相同的测试始终失败。
• 没有新的验收标准得到满足。
• 相同文件被反复回退或重写。
• 评分保持不变。
• 队列大小未减少。
• 智能体返回先前已拒绝的解决方案。

当进展停滞时，稳健的循环应停止运行或升级处理。

3. 对错误方案的自信心增长

迭代可能使有缺陷的解决方案变得更复杂而非更正确。

智能体可能在错误假设周围添加层级，生成的代码看似日趋完整，实则与预期行为渐行渐远。

独立审查、确定性测试和清晰的回滚路径有助于防止此类失败。

每个循环应设立的三道关卡

实用循环应至少包含三种关卡。

1. 机器可验证的完成条件

完成状态应可通过测试、脚本、评估器或外部状态观测。

示例：

• 所有测试通过。
• 队列为空。
• 拉取请求已合并。
• 评分至少达到90。
• 检查清单中所有项目标记为完成。
• 无遗留的高严重性问题。

2. 硬性限制

至少设置一个硬性上限：

• 最大运行轮次。
• 最大尝试次数。
• 最长耗时。
• 最大令牌使用量。
• 最高货币成本。
• 最大修改文件数。
• 最大并行智能体数量。

一个限制能将无限失败转化为有限失败。

3. 无进展检测

当系统不再向目标推进时停止运行。

例如：

若连续三次尝试未产生新的通过测试
且修改了相同文件，则停止运行并报告阻碍。

生产级实现可通过脚本或工作流状态追踪此情况，而不仅依赖指令。

管理令牌使用量

循环应设计为将推理资源投入最高价值环节。

Anthropic 推荐以下成本控制措施。

使用最简单的原语

小任务无需多智能体工作流。

从以下方式开始：

1. 常规轮次操作。
2. 可重复验证的技能模块。
3. 需要更多轮次时使用 /goal。
4. 需按时间触发工作时使用 /loop 或 /schedule。
5. 仅当任务流为周期性且定义明确时才使用主动工作流。

常规工作使用小模型

快速、低成本模型可处理：

• 文件发现。
• 简单分类。
• 重复性编辑。
• 格式化。
• 执行确定性检查。
• 汇总结构化结果。

将最强模型保留用于：

• 架构决策。
• 模糊错误定位。
• 安全判断。
• 对抗性审查。
• 评估冲突解决方案。

先试点后扩展

动态工作流可能创建大量智能体。

先在小范围内运行：

• 先处理十个文件再扩展到五百个。
• 先解决一个问题类别再全面展开。

整个积压事项。

• 每个仓库之前先处理一个仓库。
• 一个月消息之前先处理一天的消息。

试点项目揭示了代币消耗、工具瓶颈、常见故障和缺失的管控环节。

用脚本替代推理

当流程是确定性的，只需编写一次代码，让 Claude 运行即可。

例如：

• 解析日志。
• 检查文件数量。
• 比较输出结构。
• 填写已知表单。
• 查找符合规则的文件。
• 测试 URL 列表。
• 计算性能阈值。

避免过度轮询

基于时间的循环应反映底层系统变化的速度。

间隔过短会增加成本，却不会带来更好的结果。

运行期间检查使用情况

Anthropic 提供了几个用于检查消耗的命令：

/usage

该命令可显示技能、子代理和 MCP 集成等领域的近期使用情况。

不带参数运行 /goal 可显示当前目标的轮次和代币消耗，而 /workflows 可显示工作流代理的使用情况，并提供停止代理的控制选项。

可用性可能因 Claude Code 版本和已启用功能而异。

权限与安全

自动化不应与无限制访问混为一谈。

Claude Code 支持权限模式，可控制哪些工具和命令可以运行。

对于开发机器上的自主工作，Anthropic 建议保留明确的允许规则，或使用一种模式，该模式可自动批准有限的常见操作，同时仍对高风险命令进行管控。

绕过权限的模式应仅用于隔离环境，例如：

• 一次性容器。
• 沙箱化的 CI 工作器。
• 临时虚拟机。
• 没有敏感凭据或重要挂载数据的环境。

一个能够编辑文件、运行 shell 命令、访问外部系统并创建拉取请求的主动循环还应具备：

• 狭窄的仓库权限。
• 尽可能限制网络访问。
• 可审计的工具允许列表。
• 版本控制检查点。
• 独立且范围有限的凭据。
• 对生产部署或破坏性操作需人工审批。

目标不是消除所有人工决策，而是将人力保留在真正需要判断的决策上。

如何选择合适的循环

请参考以下决策流程。

选择基于轮次的循环当：

• 你仍在探索问题。
• 下一步取决于人工判断。
• 任务规模小且不规律。
• 完成标准具有主观性。
• 失败的变更易于手动检查。

选择基于目标的循环当：

• 结果有可衡量的验收条件。
• 代理可能需要多次尝试。
• 每次尝试都可被验证。
• 你可以设定硬性轮次或成本限制。
• 工作归属于一个活跃会话。

选择基于时间的循环当：

• 相同任务重复出现。
• 只有输入发生变化。
• 需要定期检查外部系统。
• 使用计划比事件集成更简单。
• 你能容忍轮询带来的延迟。

选择主动循环当：

• 工作持续到达。
• 每个项目遵循稳定流程。
• 结果可以被检查。
• 工作流能够在

有限权限。

• 失败可以被升级，而不是被隐藏。
• 令牌和工具预算已经过测试。

第一个实用循环

Anthropic 建议从一项你目前是瓶颈的任务开始。

问三个问题。

1. 我能编写验证检查吗？

示例：

• 一个测试命令。
• 一次浏览器交互。
• 一个分数阈值。
• 一个队列大小检查。
• 一个模式比较。
• 一个视觉差异规则。

2. 目标是否足够清晰？

一个有用的目标描述的是状态，而不仅仅是活动。

更好的写法：

所有支付测试通过，并且没有 TypeScript 错误遗留。

较弱的写法：

继续改进支付模块。

3. 工作是否以可预测的节奏出现？

如果任务每小时、每天、每周出现，或者在已知事件之后出现，它可能适合一个循环或例行程序。

如果任何一个答案是肯定的，你就有了第一个循环的候选任务。

示例：从手动提示到安全循环

想象一个团队反复修复失败的拉取请求检查。

阶段 1：轮流模式

检查当前的 PR，修复失败的 CI 测试，并解释更改。

开发者在每次 CI 变化时手动重新运行这个操作。

阶段 2：添加验证

创建一个技能，可以：

1. 读取 CI 结果。
2. 在本地复现失败。
3. 运行相关测试。
4. 检查完整的测试套件。
5. 审查最终的差异。

阶段 3：添加目标

/goal 所有必要的 CI 检查通过，尝试 4 次后停止

会话可以继续多次修复尝试。

阶段 4：添加本地时间循环

/loop 10m 检查 PR，处理新的审查评论，
并修复任何失败的必需检查。

代理检查外部变化。

阶段 5：将其移至例行程序

创建一个由拉取请求事件或日程表触发的云例行程序。

将其限制在：

• 相关仓库。
• 一个功能分支。
• 草稿拉取请求。
• 一组定义的命令。
• 最大花费或运行规模。

演变是渐进的。每个阶段只在前一个阶段有了可靠检查之后才添加自动化。

常见错误

为不明确的任务使用循环

“改进代码库”可能会无限继续下去。

将其拆分为可观察的结果。

让工作代理成为唯一的评判者

使用测试、脚本或独立的评估器。

过早增加多代理复杂性

单个代理加上一个强大的验证器可能优于一个协调性差的大型工作流。

过于频繁地调度工作

每分钟轮询在本质上并没有更高的响应性。

忽略成本或轮次限制

没有上限的循环可能导致昂贵的失败。

将提示指令视为硬性安全控制

使用权限、钩子、沙箱和隔离环境进行确定性执行。

手动修复每一个失败

当同一错误重复出现时，改进产生它的技能、规则、验证器或工作流。

常见问题

什么是 Claude Code 中的循环工程？

循环工程是设计重复的代理工作流，直到达到停止条件为止。它侧重于触发器、验证、限制、权限和升级，而不仅仅是提示内容。

一个提示的措辞。

Claude Code 有哪四种循环类型？

Anthropic 将循环分为轮次型、目标型、时间型和主动型。它们的主要区别在于触发新一轮循环的机制，以及决定工作何时停止的主体或因素。

/goal 在 Claude Code 中有什么作用？

/goal 为当前会话设置一个完成条件。每轮结束后，一个独立的评估器会检查该条件是否满足；若未满足，则启动下一轮，直到达到目标或配置的限制为止。

/loop 和 /schedule 有什么区别？

/loop 在本地机器上按间隔重复执行一个提示，因此当机器或会话停止时，循环也随之停止。/schedule 则创建一个云端的例行任务，可以在 Anthropic 管理的基础设施上继续运行，即使笔记本电脑处于关闭状态也不受影响。

Claude Code 循环会永远运行下去吗？

如果工作流缺乏边界，循环运行的时间可能会超出预期。在允许无人值守执行之前，应定义一个可量化的完成条件、一个硬性的轮次或成本上限，以及一个无进展时的停止规则。

我需要多个智能体来创建循环吗？

不需要。一个普通的 Claude Code 会话加上可复用的验证技能可能就足够了。当任务需要大规模并行处理或独立审查时，动态工作流和多个智能体才更有用武之地。

如何降低智能体循环的成本？

使用最简单的循环类型，为常规工作选择较小的模型，在较小的工作负载上进行试点，用脚本替代确定性推理，减少不必要的轮询，并设置明确的轮次或预算限制。

主动型的 Claude Code 循环安全吗？

只要其权限、仓库、凭证、预算、停止条件和升级路径得到严格控制，它们就可以被负责任地运行。不要在包含敏感或有价值数据的正常机器上使用绕过权限的模式。

相关工具

• Claude Code：Anthropic 的智能体编码环境，用于阅读仓库、编辑文件、运行命令以及自动执行开发工作。
• Claude Agent SDK：一个软件开发工具包，用于在自定义应用程序中嵌入 Claude Code 的使用工具的智能体循环。
• Claude Code Skills：存储在 SKILL.md 中的可复用程序性指令、脚本和资源。
• Dynamic Workflows：基于脚本的编排工具，用于在大型任务中协调众多子智能体。
• Claude Code Hooks：确定性的生命周期自动化工具，用于验证、阻止或响应工具操作。
• Model Context Protocol：一个开放标准，用于将 AI 智能体连接到外部工具和数据源。
• Chrome DevTools MCP：一个用于浏览器调试的 MCP 服务器，对前端验证循环非常有用。

相关链接

• 循环工程：循环入门指南：Anthropic 对四种循环模式的官方定义及其推荐的使用场景。
• [让 Claude 持续工作](

【目标指南】 (https://code.claude.com/docs/en/goal)：官方 /goal 语法、评估行为、状态控制及要求文档。
【定时运行提示】 (https://code.claude.com/docs/en/scheduled-tasks)：本地周期性提示与计划性 Claude Code 任务的说明文档。
【工作自动例程】 (https://code.claude.com/docs/en/routines)：基于计划、API 及 GitHub 事件触发的云端例程官方指导。
【代理循环原理】 (https://code.claude.com/docs/en/agent-sdk/agent-loop)：工具调用、轮次、权限、上下文及预算限制的技术文档。
【动态工作流编排子代理】 (https://code.claude.com/docs/en/workflows)：官方工作流架构、限制、示例及成本控制方案。
【调控Claude Code】 (https://claude.com/blog/steering-claude-code-skills-hooks-rules-subagents-and-more)：Anthropic 关于技能、钩子、规则、子代理及其他控制方式的选型指南。
【原始BAAI社区页面】 (https://hub.baai.ac.cn/view/56414)：作为初始参考文献提供的中文转载文章。

核心要点

Claude Code循环并非简单的重复提示，而是由触发器、工具、验证、权限、预算及停止条件协同运作的受控系统。

基于轮次的循环让人类掌控每个后续步骤；目标循环将完成条件委派给评估器；定时循环则委派触发器。主动循环则将这些基础要素组合为可重复运行的无人值守工作流。

最关键的改进通常不在于增加代理数量，而是赋予现有代理可靠的自我检查机制、明确定义完成标准，并在进度或预算耗尽时及时终止系统。

有用的循环并非能够永远运行——而是能够证明何时应该停止。