设计循环而非反复提示 Claude Code 代理可靠性的真实来源

当你把一个复杂编码任务丢给 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在当前会话内按时间间隔重复执行，适合开发阶段调试；
  • /schedule（research preview）把循环移到云端，即使关闭电脑也能继续运行；
  • 更进一步的 proactive 模式则完全无人值守：事件触发或定时启动，任务内部用 /goal 定义退出，整个 routine 直到你手动关闭才停止。

典型组合是：用/schedule定时检查新 issue → 启动动态工作流（dynamic workflows）派生子代理进行 triage → 用 /goal 确保修复后通过 review → 最后用 reviewer agent 做独立代码审查。

维持代码质量与控制 token 消耗的系统级做法

循环的质量从来不只取决于单次输出，而取决于你为它搭建的外部系统：

  1. 保持代码库本身整洁——代理会遵循已有的模式和约定；
  2. 用 SKILL.md 把“什么叫好”固化成可执行的检查项（包含工具调用、量化指标）；
  3. 让文档易于触达——框架和库的最新最佳实践要放在代理能读到的位置；
  4. 引入第二代理做代码审查——新鲜上下文 + 独立视角，能显著降低主代理的偏见。

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和系统实验。感兴趣可以关注，我们下期见。