# Claude Code 官方分享「Loops」设计范式

- 来源：meng shao (@shao__meng)
- 发布时间：2026-07-07 08:30
- AIHOT 分数：76
- AIHOT 链接：https://aihot.virxact.com/items/cmr9x6k6g00npih9kjdl5vy8b
- 原文链接：https://x.com/shao__meng/status/2074290011282055656

## AI 摘要

Claude Code 提出四种 Agent 循环范式：Turn-based（默认回合制，SKILL.md 编码验证）、Goal-based（/goal + 评估模型检查退出条件）、Time-based（/loop 本地或 /schedule 上云，事件驱动优于时间驱动）、Proactive（组合 /schedule、/goal、动态工作流）。关键实践包括自验证、确定性退出标准、模型分级路由（routine 用小模型）。质量护栏强调代码整洁、自验证、文档易达、双 agent 审查；成本护栏要求选对工件、明确停止标准。落地起点：先写 SKILL.md 沉淀验证步骤。

## 正文

Claude Code 官方分享「Loops」设计范式

把"Agent 工程"从经验直觉提升为可复用的设计语言：触发、停止、工件、适用场景--四个变量一旦确定，循环的形态就确定了。

# 核心升级：从"提示"到"循环"的范式转换

· 传统用法中，人主导每一轮（turn）：发提示 → agent 执行 → 人检查 → 再发提示。这就是默认的 agentic loop。
· "设计循环"的本质，是把触发、停止、所用工件、适用场景这四个维度显式化，从而让 agent 能在更少人工干预下完成更复杂、更长跨度的工作。判断的关键不是"任务难不难"，而是哪一段工作可以交付出去。

# 四种循环类型：一张可操作的选型表

1. Turn-based（回合制循环）
· 你交付的是：检查这一步
· 触发：用户提示
· 停止：agent 自行判断任务完成，或认为需要更多上下文
· 主要工件：SKILL.md（把人工验证步骤编码进去）
· 适用场景：短期、一次性、不属于周期流程的任务

这是默认的 agentic loop。你发提示、agent 执行、你检查、再发提示。改进空间在于用 SKILL.md 把"你脑子里的验收标准"显式化，让 agent 能自检更多环节，从而压缩每一轮的回合数。

2. Goal-based（/goal）
· 你交付的是：停止条件
· 触发：实时手动提示
· 停止：目标达成，或达到预设轮数上限
· 主要工件：/goal + 评估模型
· 适用场景：有可验证退出标准的任务

当单轮不够、需要 agent 迭代时使用。关键是把"完成长什么样"写死--每轮 agent 想停时，由评估模型核对你的条件，不达标就送回去继续。确定性指标效果最好（通过多少测试、分数超过某阈值），因为评估模型只需比对，无需自行裁量"够不够好"。

3. Time-based（/loop、/schedule）
· 你交付的是：触发时机
· 停止：你取消它，或工作自然完成（PR 合并、队列清空）
· 主要工件：/loop（本地，关机即停）、/schedule（上云）
· 适用场景：周期性工作，或与外部系统交互

适用于"任务不变、只有输入在变"的场景（如每天总结 Slack），或需要定期探查外部状态再反应的场景（如 PR 等待 review、CI 可能失败）。工程经验上，优先事件驱动而非纯时间驱动--设更长间隔、或基于状态变化触发，能同时省 token 与避免抖动。

4. Proactive（主动式循环）
· 你交付的是：提示本身
· 触发：事件或计划，无人实时参与
· 停止：每个子任务达目标即退出；routine 本身持续运行直到关闭
· 主要工件：上述全部 + 动态工作流（research preview）+ auto mode
· 适用场景：持续流入的标准化工作--bug 报告、issue triage、依赖升级、批量迁移

这是最复杂、可组合性最强的形态。文章给出的范例拼装方式：/schedule 定时巡查 → /goal 定义"完成"标准 + SKILL 编码验证方法 → 动态工作流并行探索多方案并对抗式审查 → auto mode 免授权全程执行。

成本控制的关键是模型分级路由：routine 跑在小而快的模型上，判断性决策才调最强模型。循环本身不省钱，分层 + 明确边界才省钱。

四种类型并非互斥，而是可组合的积木。
最复杂的形式（Proactive）就是把 /schedule、/goal、动态工作流、auto mode 拼装起来：定时巡查 → 定义"完成"标准 → 多 agent 并行探索方案 → 对抗式审查 → 全程无需授权。

# 关键工程实践（容易被忽略的部分）

1. 自验证是循环质量的支点。 文章反复强调：不要把"编辑成功"当成"工作完成"。把人工评审步骤编码成 SKILL.md，并尽量量化检查（测试通过数、Lighthouse 分数、Core Web Vitals、控制台零错误）。可量化的退出标准，让 agent 能自我判断、减少早停。

2. /goal 的有效性取决于"完成"的可确定性。 文章明确指出：确定性指标（通过多少测试、超过某分数阈值）效果最好。因为每轮结束时由评估模型检查条件是否满足--模糊目标会让评估模型无所适从，导致要么早停、要么空转。

3. 时间循环应"事件驱动"优先于"时间驱动"。 文章在 managed usage 中点名：设更长间隔，或基于事件反应而非定时轮询。/loop 跑在本地机器，关机即停；上云用 /schedule。这是工程经验而非理论--频繁轮询既烧 token，又易造成状态抖动。

4. 模型分级路由。 Proactive 循环建议：routine 路由到更小更快的模型，判断性决策才用最强模型。这与"循环节省成本"的直觉相悖--循环本身不省钱，模型分层 + 明确边界才省钱。

# 系统设计：质量与成本的两条护栏

质量护栏（四条递进）：
· 保持代码库整洁--agent 跟随既有模式与约定；
· 给 agent 自验证能力--用 SKILL 编码"好"的标准；
· 文档易达--框架/库文档保持最新最佳实践；
· 用第二个 agent 做代码审查--新鲜上下文的审查者不受主 agent 推理路径的"确认偏误"影响。

更进一步的工程纪律：单次结果不达标时，不要只修这一个问题，而应把它编码进系统，让未来所有迭代都受益。 这是把循环当作"可演进的系统"而非"一次性的脚本"来对待。

成本护栏（五条）：
· 选对工件与模型--简单任务不需要多 agent 或循环；
· 明确成功/停止标准--具体到"什么样算完成"；
· 大规模运行前先试点--动态工作流可产生数百 agent；
· 确定性工作用脚本--例如表单填写脚本，比 agent 反复推导代码便宜得多；
· 不要比必要更频繁地运行 routine；

用 /usage、/goal（无参）、/workflows 审查 token 消耗分布，可随时停止 agent。

# 落地起点：一句话的方法论

审视你已在做的工作，找出你自身是瓶颈的那一项，问自己能交付哪一片段：能写出验证检查吗？目标够清晰吗？工作是否按计划流入？

这条建议的精妙之处在于它反向定义了循环的适用边界：
· 写不出量化验证 → 不要用 goal-based；
· 目标说不清"完成长什么样" → 不该自动化；
· 工作不按计划流入 → 不该用 time-based；
· 都不是 → 老老实实用 turn-based，别过度工程化。

对团队而言，最有价值的可执行项是：先写 SKILL.md 把人工验证步骤沉淀下来--它是所有更高阶循环（goal / time / proactive）的共享底座。没有可靠的自验证，任何循环都只是"更快地产生次品"。

### 引用推文

> ClaudeDevs：http://x.com/i/article/2074204645845839872