用 CLI Agent 跑 TDD 工作流
用 CLI Agent 跑"红 - 绿 - 重构"循环:先写测试 → 让 Agent 写实现 → 自动跑测试 → 验证通过 → 重构的完整工作流
理解 agent loop 的 5 步循环架构,以及为什么 2026 年最好的 AI agent 都被设计成 loop,而不是被人不断 prompt
内容摘要
设想你正在用 Claude Code 改一个 bug:你写一段提示 → 看它输出 → 复制错误信息再问一遍 → 看新输出 → 让它跑测试 → 帮你 commit。一上午下来你大概打了 20 次回车,每一次都是"你"在驱动 AI 往前走。
设想你正在用 Claude Code 改一个 bug:你写一段提示 → 看它输出 → 复制错误信息再问一遍 → 看新输出 → 让它跑测试 → 帮你 commit。一上午下来你大概打了 20 次回车,每一次都是"你"在驱动 AI 往前走。
Loop Engineering 在 2026 年成为热词,描述的就是另一种工作姿态:你不再是不断给 AI 写 prompt 的人,而是设计一个能自己把活干完的循环。这个想法被 Anthropic Claude Code 负责人 Boris Cherny 一句话说透:「I don't prompt Claude anymore. I have loops running that prompt Claude.」
这两种姿态的根本差别如下表。表里每一行不是术语对术语,而是对你这个使用者意味着什么:
| 维度 | 写 Prompt(旧姿态) | 设计 Loop(新姿态) |
|---|---|---|
| 谁在推进任务 | 你(每一步都要按回车) | 系统(自己跑、自己看、自己决定下一步) |
| 你在哪里花脑力 | 每条提示怎么措辞 | 循环的边界、终止条件、失败兜底 |
| AI 的角色 | 你的对话对象 | 你设计的系统里的一个执行模块 |
| 典型节奏 | 几分钟到几十分钟一轮 | 几小时到几天后回头看结果 |
| 失败的样子 | 你看到错就改提示再问 | loop 自己重试,或停在你设定的失败边界等你审 |
要走到右边那列,你得先理解一个概念:agent loop——AI agent 自己跑的那个"输入 → 思考 → 调工具 → 看结果 → 再思考"的内循环。它不是个新发明,但 2026 年随着 Claude Code、Codex CLI、Gemini CLI 把它做成了可以直接在终端里调度的产品,普通工程师第一次可以亲手设计这种 loop,而不只是在论文里看它的图示。
Anthropic 在 Agent SDK 文档 里把 loop 拆成 5 步。这 5 步是所有 Claude Code 类工具的内核——你给一句 prompt,背后跑的就是它:
| 步骤 | 发生了什么 | 对你意味着什么 |
|---|---|---|
| 1. 接收 Prompt | SDK 把你的提示 + 系统提示 + 工具定义 + 历史对话打包给 Claude | 你提供的提示只占整个上下文的一小部分 |
| 2. 模型评估 | Claude 判断现在需要回文字、调工具,或两者都做 | "Claude 怎么知道要调 grep"——它就在这一步决策 |
| 3. 执行工具 | SDK 帮 Claude 跑工具(Bash / Read / Edit 等),把结果收回来 | 这一步在你的电脑上真正"发生事情" |
| 4. 回到第 2 步循环 | 工具结果作为新输入再喂给 Claude,让它决定下一步 | 一次任务通常是 N 次这样的小循环,称为 N 个 "turn" |
| 5. 返回结果 | Claude 输出一段没有工具调用的纯文本,loop 结束 | 你看到的"任务完成"消息就是循环的出口 |
一句简单的 prompt(「这个目录有什么文件?」)通常 1-2 个 turn 结束;一个复杂任务(「重构 auth 模块并把测试跑过」)可能跑几十个 turn,每一个都包含模型决策 + 工具执行 + 结果回灌。
这 5 步并没有定时器,loop 默认一直跑到 Claude 自己说"完了"为止。这就引出了 loop 设计里第一个工程问题:怎么让它不要无限跑下去——见下面「基础用法」段的实操。
Claude Code 已经把"设计 loop"暴露成 3 种用法,从最轻量到最重量依次是 /loop、/goal、Agent SDK。下面用同一个例子("每 30 分钟检查一次 deploy 状态,失败就提示我")演示三种方式怎么实现,让你看清它们的层级关系。
/loop —— 定时跑同一件事最简单的 loop 工具,2026 年下半年随 Claude Code 内置。语法:
/loop <间隔> <prompt 或 slash command>
间隔单位是 m(分钟)/ h(小时)/ d(天),最小 1 分钟(因为底层是 cron)。任务会自动 3 天后过期,这是安全机制——防止你忘了关一个跑了一年的循环烧 API 费用。
实例:
# 每 30 分钟检查一次 deploy 状态
/loop 30m 跑 ./scripts/check-deploy.sh,如果输出含 FAILED 就用 notify-send 提醒我
# 每天早上让 Claude 帮你扫一遍待办
/loop 1d /todo summarize
# 让模型自己决定节奏(不传间隔,由 Claude 用 ScheduleWakeup 工具决定下一次什么时候跑)
/loop 跟踪这个 CI run,跑完了告诉我
适合的场景:固定节奏 + 简单单次任务(巡检 / 状态轮询 / 日报)。
不适合:需要"跑到某条件达成"的任务——/loop 只会傻傻按时间触发,不会判断"任务完成了"。
/goal —— 跑到「条件达成」为止2026-05 起加入的命令(v2.1.139+)。语法:
/goal <自然语言条件> <一开始要做什么>
/goal 跟 /loop 的根本差别是 /goal 自带评估器:每一轮跑完后,一个独立的小模型会看输出,判断"条件达成了没"。没达成就让 Claude 继续;达成了 loop 就结束。
实例:
/goal 直到 npm test 全绿 跑测试,定位失败原因,改源码,再跑测试
/goal 直到这个 PR 没有未解决的 review 留言 读 review、改代码、回复留言、推新 commit
这是 Plan-Generate-Evaluate 模式的内置实现,也是「设计 loop」最直接的入门方式——你只需要把"我想要的样子"说清楚,工具帮你处理循环。
适合的场景:有明确"完成"信号的任务(测试全绿、PR 干净、文件夹清空、订阅队列处理完)。
不适合:开放式任务("优化这个代码库"——没有可判断的"完成"信号,会跑到预算上限或被你叫停)。
如果你要把 loop 嵌进自己的 app(不只是终端命令),用 Agent SDK:
import { query } from "@anthropic-ai/claude-agent-sdk";
for await (const message of query({
prompt: "修复 auth 模块的失败测试",
options: {
allowedTools: ["Read", "Edit", "Bash", "Glob", "Grep"],
maxTurns: 30, // 防止无限循环
maxBudgetUsd: 2.0, // 防止账单失控
effort: "high", // 给复杂调试任务多想点
}
})) {
if (message.type === "result") {
console.log(message.subtype === "success" ? message.result : `Stopped: ${message.subtype}`);
}
}
maxTurns 和 maxBudgetUsd 是 loop 设计的两条护栏:分别按"循环次数"和"花了多少钱"兜底。 没护栏的 loop 在开放式任务上能跑到天荒地老,生产环境的 loop 一定要设这两条。
适合:把 agent 能力做成产品的开发者(你的 SaaS / CLI 工具 / GitHub Action)。
对比一句话:/loop = 定时器;/goal = 自动判完没完;SDK = 你自己写所有控制流。复杂度从左到右递增。
光会用 /loop /goal 还不够,真正能跑通的 loop 通常由 5 个部件组成。Addy Osmani 在 Loop Engineering 里总结的清单:
| 部件 | 干什么 | 缺了它会怎样 |
|---|---|---|
| Automations | 定时发现工作(cron / webhook / 队列) | loop 不会自己启动,每次都要你手动 trigger |
| Worktrees | 用 git worktree 让多个 loop 在不同分支并行跑 | 多 loop 互相踩对方的 working tree,commit 全乱 |
| Skills | SKILL.md 文件存项目知识(怎么改这个模块、跑测试要哪条命令) | loop 每次都得从零摸索,token 烧爆 |
| Plugins / MCP Connectors | 通过 MCP 接外部服务(数据库、Jira、Slack) | loop 只能在你这台电脑里干活,碰不到外部状态 |
| Sub-agents | 把"生成"和"审核"分给两个 agent 做 | 同一个模型既写又审,倾向自己说自己对,质量打折 |
典型完整 loop(Addy 给的例子):"每天早上 9 点自动化读 CI 失败 → 在隔离 worktree 里生成修复 → sub-agent 审核 → 通过 MCP 连接器开 PR + 更新 Jira ticket"。你睡觉它在跑,你看到的是早晨邮箱里几条 PR。
把 Loop Engineering 放在更大的 AI 工作方式光谱里看,能看出它跟前后两代的关系:
| 维度 | Prompt Engineering | Loop Engineering | 多 Agent / Swarm |
|---|---|---|---|
| 核心动作 | 写更好的提示 | 设计循环 + 兜底机制 | 编排多个 agent 协作 |
| 谁推进任务 | 你 | loop 自己 | orchestrator agent |
| 时间尺度 | 几分钟 | 几小时-几天 | 通常更长 |
| 典型工具 | ChatGPT / Claude.ai | Claude Code /loop /goal / Agent SDK | Mastra / AutoGen / CrewAI |
| 学习门槛 | 低(会打字就行) | 中(要懂 cron / git / 失败处理) | 高(要懂并发 / 一致性) |
| 失败成本 | 低(你看到就改) | 中(loop 跑错一阵子才发现) | 高(多 agent 一起跑错) |
| 适合什么人 | 所有用 AI 的人 | 个人开发者 / 小团队 | 平台型团队 / 高级架构师 |
核心区别一句话:Prompt Engineering 是「让 AI 答得更准」,Loop Engineering 是「让 AI 自己干完」,多 Agent 是「让多个 AI 协作干一件大事」。三层是递进关系,不是替代——Loop Engineering 内部还是要写好 prompt,多 Agent 内部还是要设计 loop。
| 误区 | 准确理解 |
|---|---|
以为 loop 就是写个 while True 套个 prompt | loop 是带状态、带验证、带边界的系统:要存进度文件、要 sub-agent 校验、要 maxTurns / maxBudget 兜底。少了任何一项都会出问题——空循环烧钱、自循环跑到崩溃、没记录无法 resume |
| 觉得 loop 跑得越多越省事 | Addy Osmani 警告过 "cognitive surrender"——loop 顺了之后你倾向于停止理解 AI 干了什么,结果一旦它做错,你已经没有能力调试它了。这叫理解债务,跟技术债一样会复利 |
| 以为只要会写 prompt 就能写 loop | 这是另一种工种。Loop Engineering 的难点是"失败了怎么 graceful 退出""跨会话怎么传状态""检测条件怎么写得不会误判"——这些是工程问题,跟措辞无关 |
以为 /loop 跟 /goal 是同义词 | 关键差别是终止条件:/loop 按时间,/goal 按状态。轮询用 /loop,做事用 /goal |
| 担心 loop 跑着跑着烧爆 API 账单 | 这正是 maxBudgetUsd 存在的理由。所有生产 loop 都应该设它——5 美元 / 10 美元都行,至少有个上限 |
| 优势 | 劣势 |
|---|---|
| 你睡觉它也在跑:定时任务 / 失败重试 / 状态轮询都不再占你白天的注意力 | token 成本得自己兜:没 maxBudgetUsd 的开放式 loop 能跑到三位数美金账单 |
| 多任务真并行:worktree 隔离让多个 loop 在不同分支同时跑互不踩 | 调试难度上一个台阶:loop 跑了 2 小时报错,你得重放 / 看 transcript / 还原现场,比一次性 prompt 重 |
| 生成和审核可以解耦:sub-agent 双盲让结果质量比单 agent 高很多 | 设计错了 evaluator,loop 跑得越快错得越远:评估器把"看起来对"当"真的对",loop 会自信地完成错的活 |
| 从"问问题"升级到"交活":你下达更大粒度的任务,AI 自己拆解执行 | 观感不直观:loop 跑半天你看不到中间,要主动 tail log / 查进度文件才知道 |
| 被工具方主动适配:cron / git worktree / MCP / Skills 这些都是为 loop 做的基础设施 | 生态早期:/goal 半年内还在迭代,Plan-Generate-Evaluate 模式没有完全收敛的最佳实践 |
读完这张卡,你应该能回答:
/loop 和 /goal 在终止条件上的根本差别? /loop 按时间间隔;/goal 按你写的状态条件,由独立小模型每轮评估是否达成。maxTurns(循环次数上限)和 maxBudgetUsd(花费上限)。如果其中有任何一条答不上来,回到对应段落再读一次。要继续深入,推荐看:
优先展示同分类且标签更接近的内容,方便继续串联学习。
用 CLI Agent 跑"红 - 绿 - 重构"循环:先写测试 → 让 Agent 写实现 → 自动跑测试 → 验证通过 → 重构的完整工作流
用 CLI Agent 审查 PR 的提示词模板、产出格式、严重度分级与 GitHub PR 的衔接,含本地 diff 与远程 PR 两种场景
用 CLI Agent 系统化定位 bug 的五步走 —— 复现 → 隔离 → root cause → fix → 回归,附 prompt 模板与避坑