当你把一个复杂编码任务丢给 Claude Code 时是不是经常出现这样的场景代理先写了一版代码、跑了测试、发现问题、修改、再跑……你手动发几次提示后它突然说“完成了”但实际还有边界 case 没覆盖或者 token 已经悄无声息地消耗了大半Claude Code 团队的实践给出了一个清晰的答案问题不在模型“聪明不够”而在你是否真正设计了循环——而不是只在做提示迭代。循环的本质是代理重复执行“收集上下文 → 执行动作 → 验证结果”这个周期直到满足明确的停止条件。区别于单纯的多轮提示结构化的循环把触发方式、停止边界、验证原语和任务特性显式地工程化了。我起初也以为随着模型上下文窗口和工具调用能力提升只要提示写得够细、例子给得够多就能把代理“调教”得可靠。后来深入看团队对停止条件和验证机制的强调才发现没有外部定义的“完成标准”模型很容易在局部最优上打转或者过早宣布胜利。为什么 turn-based 循环在短任务里高效却在长链依赖上容易失控最基础的模式是 turn-based 循环每一次用户提示启动一个手动循环。代理读取代码、做出修改、运行测试、把结果交给你你再决定下一步。这种模式适合“创建 like button”这类边界清晰、单次迭代就能见效的任务。你可以把自己的手动校验步骤固化到 SKILL.md 里让代理自己完成更多自检。但当任务变成“重构整个认证模块并兼容三套遗留系统”时turn-based 的问题就暴露了停止判断完全依赖模型主观评估容易出现“看起来能跑就行”的提前终止或者因为缺少量化标准而无限回合。Goal-based 循环如何把“完成”从主观判断变成可验证标准这时 /goal 原语就派上用场了。你不再让模型自己决定“好不好”而是给出明确的成功条件/goal 重构用户认证模块满足以下全部条件后停止 - 所有现有单元测试通过 - 新增集成测试覆盖率达到 85% 以上 - 通过 OWASP Top 10 安全扫描 - 性能基准测试登录接口 P95 120ms每次代理尝试停止时都会由评估器模型根据你定义的条件客观判断。确定性标准测试通过数、分数阈值、扫描结果比“代码看起来干净”有效得多。这背后的逻辑其实很简单模型最擅长的是在给定清晰边界内创造解决方案而不是自己发明边界。时间驱动与主动循环让代理接管 recurring 工作有些工作天生是周期性的——每天早上总结 Slack 关键消息、监控老化 PR、处理新提交的 bug report。/loop在当前会话内按时间间隔重复执行适合开发阶段调试/scheduleresearch preview把循环移到云端即使关闭电脑也能继续运行更进一步的 proactive 模式则完全无人值守事件触发或定时启动任务内部用 /goal 定义退出整个 routine 直到你手动关闭才停止。典型组合是用/schedule定时检查新 issue → 启动动态工作流dynamic workflows派生子代理进行 triage → 用 /goal 确保修复后通过 review → 最后用 reviewer agent 做独立代码审查。维持代码质量与控制 token 消耗的系统级做法循环的质量从来不只取决于单次输出而取决于你为它搭建的外部系统保持代码库本身整洁——代理会遵循已有的模式和约定用 SKILL.md 把“什么叫好”固化成可执行的检查项包含工具调用、量化指标让文档易于触达——框架和库的最新最佳实践要放在代理能读到的位置引入第二代理做代码审查——新鲜上下文 独立视角能显著降低主代理的偏见。Token 管理同样需要边界意识小任务别用多代理复杂循环明确成功标准能让代理更快收敛先在小范围 pilot 再大规模运行确定性工作尽量用脚本而不是让模型重新推导。四类循环的对比决策矩阵循环类型触发机制停止条件最适合任务类型Token 与质量控制要点典型风险Turn-based用户手动提示模型判断完成或需更多上下文短平快、探索性任务具体提示 SKILL.md 自检过早终止、主观偏差Goal-based实时手动提示达到明确量化目标或达到最大轮次有可验证退出条件的复杂任务外部评估器 确定性标准目标定义模糊导致死循环Time-based时间间隔/loop 或 /schedule手动取消或工作自然完成例行 recurring 任务匹配变化频率、用脚本替代推理过度运行、成本失控Proactive事件/定时无人值守每个任务内部 goal 达成Bug triage、依赖升级、迁移小模型做执行、大模型做判断 reviewer缺少 stop condition runaway从一个具体任务开始设计你的第一个循环挑一个你目前是瓶颈的任务写验证检查是否清晰目标是否可量化工作是否按固定节奏到来先用最简单的 turn-based SKILL.md 跑起来观察它在哪里卡住、哪里过度发挥再迭代优化停止条件和验证机制。可靠的代理循环本质上是把人类的判断外化成可执行的规则让模型在确定性框架里最大化发挥创造力而不是让它自己当裁判。在代理逐渐成为日常编码伙伴的今天真正的杠杆不再是写出“完美提示”而是设计出能稳定、可观测、可迭代的循环系统。掌握这一点开发者就从“操作员”进化成了“AI 工作流架构师”。你在实际项目里遇到过代理提前结束或无限循环的情况吗欢迎分享你目前使用的 stop condition 或 verification skill 是怎么设计的我们一起把这些实践打磨得更硬核。我是紫微AI在做一个「人格操作系统ZPF」。后面会持续分享AI Agent和系统实验。感兴趣可以关注我们下期见。
