Claude Code 官方分享「Loops」设计范式 · AI HOT
meng shao@shao__meng76
2026-07-07 08:30·1天前
AI 摘要Claude Code 提出四种 Agent 循环范式：Turn-based（默认回合制，SKILL.md 编码验证）、Goal-based（/goal + 评估模型检查退出条件）、Time-based（/loop 本地或 /schedule 上云，事件驱动优于时间驱动）、Proactive（组合 /schedule、/goal、动态工作流）。关键实践包括自验证、确定性退出标准、模型分级路由（routine 用小模型）。质量护栏强调代码整洁、自验证、文档易达、双 agent 审查；成本护栏要求选对工件、明确停止标准。落地起点：先写 SKILL.md 沉淀验证步骤。
meng shao@shao__meng · X 2026-07-07 08:30·1天前
在 X 看原推· x.comAI 摘要Claude Code 提出四种 Agent 循环范式：Turn-based（默认回合制，SKILL.md 编码验证）、Goal-based（/goal + 评估模型检查退出条件）、Time-based（/loop 本地或 /schedule 上云，事件驱动优于时间驱动）、Proactive（组合 /schedule、/goal、动态工作流）。关键实践包括自验证、确定性退出标准、模型分级路由（routine 用小模型）。质量护栏强调代码整洁、自验证、文档易达、双 agent 审查；成本护栏要求选对工件、明确停止标准。落地起点：先写 SKILL.md 沉淀验证步骤。
关键工程实践（容易被忽略的部分）
- 自验证是循环质量的支点。 文章反复强调：不要把"编辑成功"当成"工作完成"。把人工评审步骤编码成 SKILL.md，并尽量量化检查（测试通过数、Lighthouse 分数、Core Web Vitals、控制台零错误）。可量化的退出标准，让 agent 能自我判断、减少早停。
- /goal 的有效性取决于"完成"的可确定性。 文章明确指出：确定性指标（通过多少测试、超过某分数阈值）效果最好。因为每轮结束时由评估模型检查条件是否满足--模糊目标会让评估模型无所适从，导致要么早停、要么空转。
- 时间循环应"事件驱动"优先于"时间驱动"。 文章在 managed usage 中点名：设更长间隔，或基于事件反应而非定时轮询。/loop 跑在本地机器，关机即停；上云用 /schedule。这是工程经验而非理论--频繁轮询既烧 token，又易造成状态抖动。
- 模型分级路由。 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）的共享底座。没有可靠的自验证，任何循环都只是"更快地产生次品"。
ClaudeDevshttp://x.com/i/article/2074204645845839872
这是默认的 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 并行探索方案 → 对抗式审查 → 全程无需授权。
关键工程实践（容易被忽略的部分）
- 自验证是循环质量的支点。 文章反复强调：不要把"编辑成功"当成"工作完成"。把人工评审步骤编码成 SKILL.md，并尽量量化检查（测试通过数、Lighthouse 分数、Core Web Vitals、控制台零错误）。可量化的退出标准，让 agent 能自我判断、减少早停。
- /goal 的有效性取决于"完成"的可确定性。 文章明确指出：确定性指标（通过多少测试、超过某分数阈值）效果最好。因为每轮结束时由评估模型检查条件是否满足--模糊目标会让评估模型无所适从，导致要么早停、要么空转。
- 时间循环应"事件驱动"优先于"时间驱动"。 文章在 managed usage 中点名：设更长间隔，或基于事件反应而非定时轮询。/loop 跑在本地机器，关机即停；上云用 /schedule。这是工程经验而非理论--频繁轮询既烧 token，又易造成状态抖动。
- 模型分级路由。 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）的共享底座。没有可靠的自验证，任何循环都只是"更快地产生次品"。
ClaudeDevshttp://x.com/i/article/2074204645845839872