如何使用 Claude Code构建智能体循环：验证、成本与停止条件

公众号名称：奇点先锋

作者名称：扶苏

发布时间：2026-07-01 08:00

很多开发者用 Claude Code 搞自动化任务，觉得”给它个 Prompt 不就完事了吗？” 太天真了。Agent 循环一旦失控，那就是一台没有刹车的跑车——跑得越快，撞得越狠。这篇文章把验证机制、成本预算、停止条件这三件套讲得透透的。

🚀 太长不看（TL;DR）

💰 不设预算上限 = 裸奔：一个停不下来的 Agent 循环，一晚上能烧掉 400 刀，真不是开玩笑。
✅ 别让 Agent 自己给自己打分：验证必须用外部测试脚本，Agent 的”我觉得搞定了”不算数。
🛑 三种停止条件缺一不可：成功条件、失败条件、预算条件——少任何一个都是在埋雷。

一、Agent 循环到底是啥？为啥能翻车？

用 Claude Code 搭个 Agent 循环，听起来挺简单的，对吧？

直到某天凌晨 3 点，你的终端开始疯狂滚动，第二天醒来一看——API 账单 400 刀。

这不是吓你，这是真实发生的翻车现场。

问题的根源在于：Agent 循环和普通的单次 AI 调用完全是两码事。

普通调用是什么？你发个 Prompt，拿个回复，完事。

但 Agent 循环不一样——模型先执行一个动作，然后观察结果，接着决定下一步干什么，然后再来一轮。这个循环可以跑几十轮甚至上百轮。

如果你没在循环里埋好验证检查点、花费上限和停止条件，那一个边界情况就能让你的进程彻底放飞自我。

这篇指南就带你搭一个真正能在生产环境用的 Agent 循环，涵盖：

如何设计验证检查点 🔍
如何控制 Token 花费 💵
如何在跑第一轮之前就定义好退出条件 🚪

二、Claude Code 的循环架构，搞懂它在干嘛

Claude Code 是 Anthropic 出品的 Agent 编程工具，跑在你自己的终端里。它能读文件、写代码、跑命令行、执行测试，甚至能迭代自己的输出。

听起来很强大对吧？但这也意味着——模型手里握着真实的工具，而工具是有真实后果的。

📐 基础循环结构

往高了说，每个 Agent 循环都有三个阶段：

Plan（规划） —— Agent 评估任务，决定下一步干什么
Act（执行） —— Agent 采取动作（写代码、跑命令、读文件）
Observe（观察） —— Agent 读取动作结果，更新计划

然后这个过程不断循环，直到任务完成或者有什么东西把它停下来。

问题来了：“有什么东西把它停下来”这件事，几乎不会自动发生。

没有明确的停止条件，Claude Code 就会一直规划、一直执行——只要它觉得任务还没完，或者直到撞上 API 的硬限制。

⚠️ 循环为什么会失控？

Agent 循环跑得比预期长，通常是这几个原因：

🎯 成功条件模糊：Agent 没法判断任务是不是做完了，就只能一直试。
🔄 级联失败：一个测试挂了 → 改代码 → 另一个测试挂了 → 再改 → 无限套娃。
🌍 任务范围太大：“重构整个代码库”——这种任务压根没有天然的停止点。
💸 没有错误预算：Agent 不知道什么时候该停下来求助，只会死磕。

好消息是——这些问题都可以通过提前设计来解决。

三、开跑之前，先把任务范围钉死

最有效成本控制手段，就是一个范围明确的任务。

听起来像废话，但大多数 Agent 循环翻车的问题，都能追溯到一句模糊的、开放式的指令。

✅ 写一个具体的成功条件

在调用 Claude Code 之前，把”完成”长啥样写清楚。

不是”修好那些 bug” ❌

而是”/tests/unit/ 目录下所有测试以退出码 0 通过，且在 /src/ 目录外不新建任何文件” ✅

一个好的成功条件有三个特征：

可观测 —— 你可以用代码去检查它
二值化 —— 要么通过，要么失败，没有”差不多搞定了”
有边界 —— 描述的是一个有限的结果，不是一个持续的过程

如果你写不出这样的成功条件，说明这个任务的范围还不够收敛，不适合直接扔给 Agent 自己跑。

🔪 把大任务拆小

跑很久的循环比短小精悍的循环难控制得多。

与其一次性给 Claude Code 塞一个多步骤的大任务，不如拆成一个个独立的子任务。每个子任务单独跑一轮循环，验证通过了，再跑下一个。

这就是**“检查点 + 继续”模式**——第 3 步失败了，你不用替第 4 步到第 10 步的 Token 买单。

四、每一轮循环都要有验证机制

验证，是把”受控的 Agent 循环”和”黑盒”区分开的关键。

你需要在每一轮迭代中知道两件事：

Agent 有没有在取得真实进展？
它的方向对不对？

🔍 三种验证类型

值得做这三种级别的验证：

1️⃣ 动作验证（Action Verification）

每次单独动作（写文件、跑命令）之后，检查这个动作是否成功了。

Claude Code 通常会自动读取 stdout/stderr 的输出，但你可以加额外的断言——比如在 Agent 声称写完文件之后，检查文件是否真的存在，或者命令的退出码是不是 0。

2️⃣ 迭代验证（Iteration Verification）

每一轮循环结束，跑一个轻量级的检查，看看整体任务是不是更接近完成了。

对于代码任务，可能是跑某个测试文件；对于数据任务，可能是检查行数或者 Schema 合法性。

3️⃣ 终局验证（Terminal Verification）

在接受”循环完成”之前，跑一遍你一开始定义的那个完整的成功条件。这是你的最终门禁。

🧪 用验证脚本，别只信 Agent 的自我评价

一个常见错误是让 Agent 用”自己的判断”来验证自己的工作。

模型可能会说”我觉得任务完成了”——它不是在骗你，而是它真的看不到问题在哪。

尽量用外部脚本或测试套件让 Agent 去调用，Agent 只负责报告脚本的输出结果，而不是自己下结论。这样验证就锚定在客观输出上，而不是主观感觉。

举个简单例子，如果 Claude Code 在写一个 Python 函数，在你的 System Prompt 里加上这段：

```
每次改完代码之后，执行 `python -m pytest tests/test_function.py -v`，
并报告完整的输出结果。在所有测试通过之前，不要进入下一步。
```

这样 Agent 就被迫用测试结果来判断任务状态，而不是用”自我感觉”。

🔁 限制重试深度

动作失败了，Agent 应该重试——但不能无限重试。

给每个动作设一个最大重试次数，通常是 2～3 次。3 次还不行，就停下来报错，而不是一直死磕。

这对命令行调用和 API 请求尤其重要——连续失败通常说明问题是系统性的（环境不对、凭证错误、逻辑有 Bug），再重试多少次也解决不了。

五、设好花费上限和 Token 预算

Token 花费是 Agent 循环里最容易量化的风险。好消息是，它也是最容易控制的。

🧮 跑之前，先估算成本

Claude 的 API 定价是公开的，也是可预测的。跑循环之前，先估算一下预期成本区间：

预估任务需要多少轮迭代
每轮大概消耗多少 Token（输入 + 输出）
乘以你选用模型的单价

以 Claude Sonnet 为例，截至 2025 年中，大约是：

输入：$3 / 百万 Token
输出：$15 / 百万 Token

一个 20 轮的循环，每轮平均 5000 输入 Token + 1000 输出 Token，成本约 $3.30——完全可以接受。

但如果停止条件没设好，循环跑了 500 轮，成本就可能飙到 $80+。

提前算这笔账，就是给自己设一个基准线。如果实际花费大幅偏离，说明循环设计出了问题。

🔒 在 Prompt 里设硬性的轮次上限

Claude Code 支持 --max-turns 参数，限制一次 Session 最多跑多少轮。一定要用它，这是最简单的硬刹车：

```bash
# 限制最多跑 25 轮，任务是修复 /tests/unit/ 下所有挂掉的测试
claude --max-turns 25 "Fix all failing tests in /tests/unit/"
```

把这个值设得比你预期的轮数稍高一些——既给 Agent 留够发挥空间，又能防止彻底失控。

📊 分层用模型，省钱不降质

循环里不是每一步都需要最强（也最贵）的模型。

Claude Haiku 的成本比 Claude Sonnet 便宜很多，而对于读文件、看 Diff、跑已知命令这类常规操作，小模型完全够用。

考虑这种分层策略：

🪶 轻量模型：用在规划（Planning）和观察（Observation）步骤
🏋️ 强力模型：只用在核心的代码生成或复杂推理步骤

这一招可以把每轮成本降低 60%～80%，而简单操作的输出质量几乎不受影响。

📈 实时监控花费

对于跑在生产环境或自动化流水线里的循环，要把成本追踪接入你的循环控制器。

大多数团队的做法：

通过 API 响应的元数据统计 Token 数量
累加一个运行中的总花费
一旦总花费超过阈值，立刻停掉循环

这和 --max-turns 是两码事——--max-turns 管的是”轮数太多”，成本阈值管的是”每轮出乎意料地贵”。两个都要有。

六、定义清晰的停止条件

停止条件是你的循环在每轮结束时检查的退出条件。

必须在循环开始之前就定义好，不能跑到一半临时拍脑袋。

📋 三类停止条件

✅ 成功停止（Success Stopping）

任务完成了。你的终局验证通过了。Agent 返回一个成功信号，循环干净退出。

❌ 失败停止（Failure Stopping）

任务在当前条件下无法完成。触发条件包括：

某个动作的重试次数超过上限
碰到了不可恢复的错误（文件找不到、环境挂了）
Agent 明确发出”我卡住了”的信号

💰 预算停止（Budget Stopping）

资源耗尽了。触发条件包括：

轮次超过 --max-turns 限制
Token 花费超过成本阈值
墙钟时间超过时间上限

🔥 每个循环至少要有这三类条件各一个。 少了失败停止，循环会在错误状态上反复摩擦；少了预算停止，慢慢失败就变成了烧钱失败。

📝 把停止条件写进 System Prompt

别只靠代码层的控制——在 Claude Code 的指令里也要明确写出停止条件：

```
你最多有 20 轮机会来完成这个任务。
如果所有测试通过，报告 "TASK_COMPLETE"（任务完成）并停止。
如果你遇到了重试 3 次仍然无法解决的错误，报告 "TASK_FAILED: [原因]" 并停止。
不要在 /src/ 或 /tests/ 目录之外创建新文件。
```

明确的指令能让模型知道什么时候该停手、什么时候该上报，而不是闷头死磕。

🧩 处理好”做了一半”的情况

有些任务会在完成 80% 的时候触发停止条件。提前决定好怎么处理这种情况：

Agent 应该提交已完成的半成品吗？
还是应该回滚？
还是留下一份详细报告，说明做了什么、卡在哪里？

最糟的结果是：循环中途停了，代码库处于不一致的状态，而且没有任何记录说明发生了什么。

一定要设计一个清理和汇总步骤，无论循环是成功退出还是失败退出，都要执行。

七、实战中好用的循环设计模式

理解了核心组件之后，有几种模式在大部分 Claude Code Agent 循环场景里都很好用。

🧪 模式一：测试驱动循环（Test-Driven Loop）

这是代码任务里最干净的模式：

在启动 Agent 之前，先写好（或提供）测试用例
Agent 编写或修改代码
Agent 每次改完都跑一遍测试
测试全部通过或者重试上限到达时，循环退出

测试套件同时扮演了”验证机制”和”成功条件”两个角色——Agent 永远不需要”自己觉得自己做得怎么样”，测试说了算。

👀 模式二：Diff 审查循环（Diff-Review Loop）

对于高风险的修改，加一个”人在回路”的检查点：

Agent 提出一个变更（生成 Diff）
人类审查并批准/驳回
批准后，Agent 执行变更并验证
循环继续处理下一个任务

这样虽然慢一点，但在后果严重的决策点保留了人类判断。适合生产代码、数据库迁移，或者任何”一旦出错就很难挽回”的场景。

📝 模式三：检查点 + 汇总循环（Checkpoint-and-Summarize Loop）

对于耗时较长的任务，定期存个快照：

Agent 完成一个子任务
Agent 写一份结构化的汇总——做了什么、接下来做什么
控制器把汇总保存到文件
如果循环中断了，可以从最后一个检查点恢复

这让长循环变得可恢复，也给你留下了一份审计轨迹——Agent 做了什么、为什么这么做。

八、常见翻车现场 & 解药

😵 翻车 1：没有成功条件就开跑

💊 解药： 在写 Prompt 之前先写成功条件。如果一句话说不清，说明任务范围还得再收窄。

😵 翻车 2：没有硬性轮次上限

💊 解药： 跑自主任务时永远带上 --max-turns。先保守点（15～20 轮），有数据证明需要更多再加。

😵 翻车 3：相信 Agent 的”自我评价”

💊 解药： 用外部测试、脚本或校验器来确认任务完成。Agent 说”我觉得搞定了”只是一个信号，不是验证。

😵 翻车 4：每一步都用最贵的模型

💊 解药： 审计你的循环，找出哪些步骤不需要强推理，把它们挪到 Claude Haiku 之类的轻量模型上。

😵 翻车 5：没有失败处理机制

💊 解药： 在指令里明确定义”失败状态”。告诉 Agent “卡住”长什么样，卡住了该怎么办。

😵 翻车 6：让 Agent 自己修改停止条件

💊 解药： 停止逻辑要写在你的控制器代码或 System Prompt 里，放在 Agent 在循环中无法编辑的地方。

九、核心要点总结

🛑 三类停止条件缺一不可：成功条件、失败条件、预算条件——少任何一个都是定时炸弹。
🧪 外部验证（测试、脚本、校验器）永远比让 Agent 自己判断靠谱。
🔢 --max-turns 参数是你最简单的硬刹车——永远不要不用它。
🔪 大任务拆成小任务，每个子任务配独立检查点。短循环 + 清晰的成功条件 >> 一个无底洞式的长循环。
💰 Token 成本是可以提前预测的。绝大多数”账单惊吓”的根源不是模型太贵，而是停止条件没设好。

内容效果不满意？点此反馈