Agentic Loop 的残酷现实：外部拒绝门禁才是成败关键，而非“睡醒后代理自动发货”-深圳市維司達科技有限公司

现在几乎所有人都在讨论构建 Agentic Loop。
大 V 们不再写提示词了，他们在建循环。每个星期都有新帖子告诉你“为什么你也应该这么做”。

但那些帖子几乎都漏掉了最重要的一点。

大多数人构建的循环，其实只是在烧钱。

Human-in-the-Loop vs 真正的 Agentic Loop

目前大多数人使用 AI 的方式，本质上还是人一直在循环里：

你提示 → 代理构建 → 你审查 → 你再提示 → ……
你就是那个发动机。一旦你停止输入，工作就停了。

这叫 Human-in-the-Loop。它有效，但有硬性上限。

而一个真正的 Agentic Loop，会把人从大部分循环中移除：
你只在最开始扔一个规格文档（spec），然后代理自己构建、自我检查、把结果喂回自己，继续迭代，直到完成。你只需要在最后回来验收。

理论上：你睡觉，代理发货。
现实中：你醒来，看到几百美元的账单和一堆破损的构建。

真实成本远比想象中高

一个中等复杂度的编码任务，每次迭代大约消耗 3 万输入 token（Claude Sonnet 4.6 定价）。一次迭代约 0.09 美元。

听起来还可以接受。
但问题在于：上下文窗口会随着迭代不断膨胀。到第 5 次迭代时，输入可能已经涨到 8 万 token。

一个任务跑几次就可能花掉几美元。十个任务下来，一早上的花费就能达到 10-20 美元。

对 20 美元/月的订阅来说，这几乎是整个月的额度。
对 100 美元/月的订阅来说，也就够用一周。

真正大规模跑循环的人（比如 Peter），一个月能烧掉 130 万美元的 token。
你不需要达到那个量级，就能明显感受到账单的压力。

规格文档无法解决的根本问题

即使你愿意承担成本，还有一个更深层的问题：规格文档永远写不全你脑子里的假设。

你给代理一个 spec，让它从头到尾把东西做完，它就会自己做假设。
有时候这些假设是对的，但大多数时候是错的。

你拿到的结果往往不是你真正想要的。
代理会以极快的速度、在极大规模上犯这些假设错误，并且让你为每一次错误的尝试付费。

如果你要用 spec，就必须把重点放在消除假设上，而不是描述功能：

明确约束（agent 绝对不能做什么）
视觉/交互参考（链接或明确描述你想要的模式，而不是“像我脑子里想的那样”）
每个功能的验收标准（具体到什么情况下你会说“这个完成了”）

大多数 spec 只告诉代理“要做什么”，而代理真正需要的是“怎么知道自己做完了，以及绝对不能改动什么”。

没有外部拒绝机制的循环 = 老虎机

没有硬性反馈机制的循环，本质上就是一个老虎机：

你拉一下拉杆，有时出来一个还不错的结果，大多数时候出来一个“差不多但细节不对、基于你从未说过的假设”的东西。

循环自己并不知道它做错了。
它没有办法知道。
只有你知道。

而一旦你不在循环里，这个信息就永远无法反馈给代理。

这不是技术 bug，而是结构性限制：把创造性判断委托给一个无法访问你脑子里真实想法的系统。

循环之所以像老虎机，不是偶然，而是因为它本来就是老虎机——直到你给它一个能自动拒绝坏输出的外部机制。

真正能跑通的循环：必须有外部二元拒绝门禁

循环从烧钱机器变成有用工具的转折点，是拥有一个固定、自动、且不需要你主观判断的拒绝机制。

代码审查是目前最清晰的例子。

作者把 AI 生成的代码推送到 GitHub 后，由 Greptile 自动进行代码审查。它不是总结代码，而是给出一个 1-5 分的评分，并给出具体问题。

规则非常简单：评分低于 4 分就不能上生产。

具体循环流程：

Cursor 读取 GitHub 上的 Greptile 审查结果
Cursor 根据审查指出的问题进行修改
Cursor 把更新后的代码推送到 GitHub
Greptile 自动运行新的审查
如果评分仍低于 4 分，循环继续
直到评分达到 4 或 5 分，或达到最大尝试次数后停止

这个循环能工作的核心原因在于：反馈是二元的。Greptile 要么通过，要么不通过。没有灰色地带，也没有“差不多就行”的主观判断。

这才是区分“帮你省时间”和“帮你烧钱”的关键。

循环真正适用的三种场景

代码审查（目前最成熟）
大规模二元输出任务（例如按固定模板生成 300 篇 SEO 页面，可以用简单脚本检查字数、标题结构、关键词出现等，失败就自动打回）
低风险实验（你只想要一个粗糙可用的形状，不在乎细节是否完美）

除此之外，对于需要体现产品愿景、细节很重要的工作，Human-in-the-Loop 仍然是目前最好的选择。

构建循环前必须回答的 4 个问题

一个任务是否值得做成循环，只需要回答下面这个问题：

有没有什么机制能自动拒绝坏输出，而不需要你主观判断？

（测试套件通过/失败、类型检查零错误、评分超过阈值、构建能否编译等）

如果答案是 Yes，才有可能值得构建循环。

如果答案是 No，你就是在建造一台一边花你的钱，一边自己给自己打分的机器。

更完整的判断标准是同时满足以下 4 点：

任务至少每周重复一次
存在能自动拒绝坏输出的外部机制（不需要你的判断）
代理能端到端完成整个工作
“完成”的定义是客观的，而不是主观品味

缺一条，就先保持手动提示。

先把手动版跑稳，再考虑自动化

如果你决定要做循环，先把手动版本做可靠。

先用手跑一次，把流程调到你满意的程度。把它做成可复用的技能，加入门禁和停止条件，最后再放到定时器上。

直接跳到自动化，是大多数循环在半夜崩溃的主要原因。

此外，对于无人值守的循环，CLAUDE.md 文件比手动模式下重要得多。因为循环里没有中途纠正的机会，代理只能依赖启动前上下文里的所有约束和标准。

一个可立即使用的自检循环提示词

你将以循环方式工作，直到任务达到标准。 TASK: [精确描述你要产出的东西] SUCCESS CRITERIA: - [标准 1] - [标准 2] 循环协议（每轮重复）： 1. PLAN: 说明下一步唯一要做的动作 2. DO: 产出或改进工作 3. VERIFY: 按每个标准打 1-10 分，并列出具体还差在哪里 4. DECIDE: 如果所有标准都 ≥8 分，输出 FINAL 并停止；否则输出 ITERATING 并修复最弱的一项 永远不要在所有标准都达到 8 分以上之前宣布完成。不要提问，做合理假设并记录下来，继续推进。

这个提示词可以直接丢进 Claude 或 ChatGPT 使用，无需任何额外设置，就能先体验一个带自检的循环。