免费Token不等于盲目重试：AI编程智能体的止损法则

当AI编程智能体可以免费重试时，很多人默认重试没有成本。但这篇文章提出一个值得警惕的观点：免费的只是账单，而不是证据。一次重试仍然是你自己做出的决定，廉价的token并不能抹掉一个反复出现的错误。

核心主张：重试需要新证据，而不是便宜的额度

文章的立论很直接——不要只因为调用是免费的就重试一个智能体。免费的额度改变的是花销，而不是你手头的证据。证据，才是第二次调用存在的唯一理由。

这个论点并非基于某个模型的跑分，也不排名任何厂商或托管服务，而是从**失败分类（failure classes）**出发。换句话说，判断是否要重试，应该看错误本身属于哪一类，而不是看额度还剩多少。作者甚至鼓励读者在数完自己的日志后再决定是否认同这个观点。

**失败分类（failure classes）**是一种将错误按根本原因归入预定义桶的工程实践，起源于电信与分布式系统领域的故障管理框架。其核心思想是：同一表面现象（如"任务失败"）可能由截然不同的根因导致，而不同根因需要完全不同的修复路径。将错误按类别处理，而非逐条即兴应对，可以将调试从"反复试探"变成"按图索骥"。在AI编程智能体的语境下，失败分类的意义在于：它要求操作者在发起下一次网络调用之前，先对本次失败的性质做出明确断言——这个断言本身就是一种元认知检查，防止人在"感觉卡住了"的焦虑状态下用重试代替思考。

为什么“重试万能论”是一种错误的安慰

近期的技术讨论总在围绕重试（retry）和换模型（swap）打转。文章提醒把这些标题当作不可信的信号，而非事实。

更关键的逻辑在于：更好的推理能力无法解开本地的锁。 缺失的文件、错误的路径，这些问题仍然停留在你自己的机器上。一个远程模型不可能凭空发明出你从未上传过的文件。再强的模型也救不了一个本质上是本地环境的问题。

付费计量过去其实在替你做一件事——它强迫你在再次花钱前停顿一下，读一读错误信息。而免费额度移除了这个停顿。那次停顿实际上在为你做分类工作：它逼你用清晰的语言为失败命名。没有命名，你就会一次又一次地重发同样的提示词。

哪些“借口”不配消耗一次调用

作者列出了几种常见但站不住脚的重试理由，建议把借口写下来后直接丢弃这次调用：

• 上一次的回复看起来“差不多对”；
• 日志太长了，感觉再总结一次才合理；
• 额度很大，浪费一点无所谓。

这些借口的共同点是：没有一个指向了新的事实。一次没有新事实的重试就是噪声，而当计量归零时，制造噪声的成本变得更低——这恰恰是危险所在。

在联网之前先给失败分类

文章给出了一张实用的失败分类表，建议先在本地读懂失败、归入某一类，再决定是否“欠”这次网络调用：

类别	你看到的现象	是否重试	原因
本地锁	依赖或文件被锁	否	再调用也不会释放它
输入缺失	空diff或文件不存在	否	先修复fixture再调一次
工具不匹配	命令不在PATH中	否	先修复主机再谈改写
不稳定检查	本地重跑已通过	一次	记录flake并设上限
改错文件	编辑落在任务范围外	否	先收窄路径列表
新的编译器事实	真实编辑后出现新错误	是	错误文本是新证据

作者特别强调，这张表只是一个起点提案，而非来自生产流量的记录结果，需要根据自己的仓库逐行修改。真正值得重试的，只有最后一类——出现了全新的错误文本，意味着证据确实变化了。

用一个“裁判”脚本把规则固化

文章提供了一个本地的“重试裁判”（retry referee）示例，核心是一个 classify 函数，根据失败类别、证据是否变化、已尝试次数返回三种裁决：stop（停止）、once（允许一次）、allow（允许）。

其逻辑清晰：本地类（锁、缺失输入、工具不匹配、改错文件）一律停止；flake类允许本地重跑一次；只有 new_compiler_fact 且证据确实变化、尝试次数未超限时才允许。而对于未知类别，裁判必须停止——未知不是去发明新类别的理由，而是提示你去手动添加一行分类并重新验证。

配合裁判的还有一个薄薄的 shell 门禁脚本 retry_gate.sh，它读取你已经写下的类别，当裁决为 stop 时直接拒绝联网调用（退出码为2）。作者反复提醒：这些脚本都是草图而非成品，在你的代码树上真正跑通之前，都应标注为“未执行”。打印出一句“permitted”并不等于通过了集成测试。

只有在允许之后才动用免费额度

文章坦诚披露：本文是开源编程智能体项目 MonkeyCode 产品外联的一部分。该外联简报提到为读者提供免费模型访问与免费服务器选项，并提及约一千万token的免费额度。但作者反复提醒读者：以项目当前文档为准，不要拿一个被复制的数字去规划一个季度的用量，免费访问随时可能变化，不要把“永久性”当成一项可以依赖的特性。

作者给出了一个务实的使用顺序：

1. 先在自己的机器上为失败分类；
2. 当类别属于本地问题时拒绝调用；
3. 只有证据变化时才发送一个有边界的提示词；
4. 打补丁后重新运行相同的本地检查；
5. 即使token还有剩余，也在两次远程尝试后停止。

两次远程尝试是一条硬性上限。 剩余的token不构成发起第三次调用的理由。

当裁判放行时，继续收窄提示词

即便裁判允许调用，也应该精简提示词：只发送新的错误、相关路径和最近的diff，而不是因为调用免费就把整个仓库都发过去。文章给出的提示词模板包含失败类别、尝试次数、变化的证据、涉及路径、新的编译器文本以及明确约束（只编辑涉及的路径、不要加重试循环、打完一个补丁就停）。

一句话点破关键：充裕（abundance）不等于上下文（context）。 上下文指的是自上次以来发生变化的那个事实。如果你指不出一行新的内容，就不该发送。

**上下文窗口（context window）**是大语言模型单次能处理的最大文本量，通常以token数衡量。token是模型分词后的最小处理单元，一个汉字约对应1-2个token，一个英文单词约对应1-1.5个token。上下文窗口越大，单次能放入的代码、日志和指令就越多，但这并不意味着放入越多越好——模型在长上下文中的注意力会发生稀释，关键信息可能被淹没在冗余内容里，反而导致输出质量下降。文章所说的"充裕不等于上下文"正是指向这一点：免费额度或大token池让人产生"不妨把所有东西都发过去"的冲动，但真正有效的提示词是外科手术式的——只包含自上次调用以来发生变化的那一个新事实。

这套工作流的边界与适用人群

作者没有回避局限：这套流程完全不衡量模型质量，不比较托管服务、价格或延迟，也不证明免费层会一直存在。脚本只知道你传入的类别，错误的分类会产生一个“自信的错误停止”——你终究还是要自己去读日志。网络抖动、部分写入等情况需要补充自己的分类行，且绝不能把密钥或客户日志粘贴进样例。

至于哪些人应该跳过这套工作流：

• 当编辑只是一个你一眼能看出的拼写错误时——人眼足够，无需裁判；
• 如果你不打算维护分类表——被废弃的表格一周内就会沦为“表演”；
• 如果公司政策禁止第三方智能体服务器——免费选项仍是远程服务，发送源码前请先读条款；
• 如果你需要可审计的数据来做决策——本文提供的是规则，不是研究，不能当作性能结论引用。

文章最后给出一个简单的自检：用上面的表格标注最近五个失败，先对这些标注跑一遍裁判，只有在裁决为 allow 时才去调用免费模型。这个观点毫不含糊——当重试感觉免费时，止损规则反而最重要。免费服务器压不过你的工作区，庞大的token池压不过一个缺失的文件，又一次改写压不过一个被持有的锁。

背景补充

这里的裁判（referee）模式本质上是一种决策表驱动的守门人（gatekeeper）设计，常见于需要将业务规则与执行逻辑解耦的场景。classify 函数充当规则引擎：输入是对失败的结构化描述（类别、证据是否变化、已尝试次数），输出是有限状态机中的一个裁决值（stop / once / allow）。将判断逻辑独立成函数而非内联在流程脚本中，有两个工程价值：一是规则可以被单独测试和版本控制；二是"未知类别一律停止"这条缺省分支可以防止分类表过期后系统静默地放行所有调用。retry_gate.sh 则是这个规则引擎的执行边界，其退出码 2 可以被 CI 流水线或 Makefile 捕获，从而将"是否允许联网"这个决策硬编码进构建过程，而不依赖操作者每次手动判断。