反复修改 Prompt 让 Claude Code 多干一点活，是很多人用 Agent 的常态。Anthropic 官方给出的答案是：与其不断写 Prompt，不如直接设计一个"循环（Loop）"，让 Agent 按照既定规则自动跑下去，直到达成目标或触发停止条件。这是从"写指令"到"设计系统"的范式升级。本文把官方提出的 4 种 Loop 类型、每个循环必备的 5 个要素、以及省 token 的工程技巧一次讲清楚，适合已经在用 Claude Code、想把日常任务工程化的开发者。

4 种 Agentic Loop 类型

Loop 的本质是给 Agent 加上触发方式和停止条件，让它从"对话"变成"流程"。按触发机制可分为 4 类。

1. 回合制循环（Turn-based）

最常见的形态：用户发一条指令，Agent 回一段，用户决定要不要继续。

• 触发方式：用户每一轮输入
• 停止条件：用户主动结束
• 适用场景：日常开发、问答式协作、代码 review

这是默认模式，几乎所有人在用的都是 Turn-based。它的优点是可控，缺点是离不开人，无法做到真正的自动化。

2. 目标驱动循环（Goal-driven）

通过 /goal 这类命令启动。你给一个明确的验收标准，Agent 会持续迭代、自检，直到目标达成才停。

• 触发方式：一次性下达的命令 + 验收标准
• 停止条件：目标达成 / 超出预算
• 适用场景：有清晰"完成定义"（Definition of Done）的任务，比如"让所有测试通过"、"把文档翻译成英文并校对"

💡 提示：目标驱动循环成败完全取决于验收标准是否可验证。不要给"把代码写好一点"这种模糊目标，要给"通过 pytest 全绿、无 lint 警告"这种可执行检查。

3. 时间驱动循环（Time-driven）

用 /loop、/schedule 这类命令，或结合 cron / heartbeat 定时触发。Agent 按周期醒来执行任务。

• 触发方式：固定时间间隔（每小时、每天、每周）
• 停止条件：手动取消 / 达到次数上限
• 适用场景：定期巡检（依赖漏洞扫描、日志监控）、定时报告（每日站会摘要）、周期性维护（清理死代码）

这类循环最适合接 CI/CD 和运维场景，是 Agent 进入"后台常驻"的关键形态。

4. 事件驱动循环（Event/Hook-driven）

由 Git commit、Pull Request、文件变更等外部事件触发。

• 触发方式：webhook、文件系统事件、CI 事件
• 停止条件：事件处理完成
• 适用场景：提交后自动跑测试、PR 自动 review、配置文件变更后自动 reload

事件驱动是工程化最彻底的一种，相当于把 Agent 编排进现有的 DevOps 流水线里。

每个有效循环必备的 5 个要素

无论选哪种 Loop，官方都强调要显式设计下面 5 件事，否则循环要么失控、要么死循环。

这 5 项里，支出上限和验证步骤是最容易被忽略的。前者保护钱包，后者保护正确性——Agent 跑出来的结果必须能用脚本或测试自动验证，不能"看起来对"就算完成。

省 token 的 4 个工程技巧

Loop 跑起来后最大的成本是上下文。官方和社区给出的优化路径几乎都围绕"怎么少喂 token"。

1. 用 Dynamic Workflows 编排并行 Agent

不要让一个 Agent 串行干所有事，而是拆成多个并行 sub-agent：一个分类、一个修复、一个审查。每个 sub-agent 只在自己的小上下文里干活，主循环只收集结果。

2. 开启 Auto Mode

让流程无需人工介入。配合明确的停止条件，Agent 可以连跑多轮不打扰你。

3. 收紧上下文，按需加载

不要把整个 codebase 灌进去。用 Claude Code 的工具按需读文件、按需 grep，让上下文里只留当下任务相关的部分。

4. 用 sub-agent 隔离上下文

主循环只保留摘要，细节交给 sub-agent 在独立上下文里处理完返回结果。这是控制主 Agent 上下文膨胀的核心手段。

配套理论：Anthropic 的 5 种 Agent 工作流

设计 Loop 时，底层可以套用 Anthropic 在《Building Effective Agents》里总结的 5 种工作流模式：

• Prompt Chaining（提示链）：把大任务拆成固定顺序的小步骤
• Routing（路由分发）：先分类，再交给对应处理器
• Parallelization（并行化）：多个子任务同时跑
• Orchestrator-Workers（编排者-工人）：中央 LLM 拆解任务、分派给 worker、汇总结果
• Evaluator-Optimizer（评估-优化）：一个评估、一个改进，形成反馈闭环

这 5 种模式可以组合嵌套，构成复杂 Loop 的骨架。

验证结果

一个设计良好的 Loop 应该满足三个验证标准：

1. 可观测：每一步的输入、输出、token 消耗都能看到
2. 可中断：随时能停下来，不会因为一个错误状态无限重试
3. 可验证：产出能用脚本或测试自动判定对错

如果跑完一轮你还得人工确认结果对不对，说明验证步骤没设计好——回去补上。

常见问题

• Loop 一直不停怎么办：90% 是验收标准太模糊或没有 spend limit。先加上硬性预算上限，再把"完成"写成可执行的测试命令。
• 上下文越来越长、越来越慢：上 sub-agent 隔离。主 Agent 只拿摘要，原始内容在子 Agent 里处理完即丢弃。
• 事件驱动 Loop 在 CI 里触发不了：检查 webhook 鉴权和事件 payload 格式，Claude Code 的事件钩子对 payload schema 有严格要求。

参考来源

• Claude Code 官方文档：Agent Loop
• Anthropic：Building Effective Agents
• Claude Cookbook：Orchestrator-Workers 模式