AI Agent烧钱三大教训：Schema校验、熔断机制与重试策略实战

一位独立开发者构建了一个 Chrome 扩展：用户只需输入一句话，比如「帮我做一个 10 道题的入职调查问卷」，背后的 AI Agent 就会通过 Google Forms API 自动写出完整的表单。Chrome 扩展是基于 Web 技术构建的浏览器插件，能够访问 Chrome 提供的特殊 API 来增强浏览体验；而 Google Forms API 是 Google Workspace 开发者平台的一部分，允许以编程方式创建和管理表单。将 AI Agent 嵌入 Chrome 扩展意味着整个推理-执行链条都在浏览器环境中运行，Agent 需要将自然语言指令转化为符合 API 规范的结构化请求——而这个过程中，每一次模型调用都会消耗 API token 并产生费用。

听起来很酷，但在把它推向生产的过程中，作者踩了三个坑——而每一个坑，都在他察觉之前实实在在地烧掉了 API 预算。

这三个教训看似琐碎，却揭示了当下 AI Agent 工程化中最容易被忽视的现实：当模型陷入某种失败循环时，它并不知道自己错在哪里，只会不断重试并持续消耗 token。 下面我们逐一拆解。

教训一：严格Schema校验反而让AI Agent烧光预算

在 AI Agent 架构中，Tool Schema（工具模式定义）是连接大语言模型与外部 API 的核心桥梁。OpenAI、Anthropic 等主流模型提供商都支持 Function Calling（函数调用）机制：开发者用 JSON Schema 格式定义工具的名称、参数类型和结构约束，模型在推理时会生成符合该 Schema 的结构化输出来调用工具。但大语言模型本质上是 token 序列生成器，它对 JSON 结构的理解是概率性的而非确定性的，在处理复杂或冗长的结构时，容易出现类型退化。

作者的工具 Schema 定义中，requests 字段应当是一个数组。但在处理较长的批量任务时，模型会「犯懒」——它把整个数组序列化成一个 JSON 字符串发过来，而不是真正的数组结构。

作者的做法是直接拒绝这个不合法的请求。从纯粹的校验逻辑看，这完全正确。但正是这个「正确」，成了最大的错误。

模型看不到自己错在哪

问题的核心在于：模型无法理解它为什么被拒绝。 它只知道请求失败了，于是会本能地重写 payload——把请求拆得越来越小，试图「绕过」这个它根本不理解的障碍。

结果是灾难性的：一次「添加 20 道题」的操作，模型连续折腾了 9 轮，烧掉约 15 万 token，最终放弃并告诉用户「API 坏了」。大语言模型的 API 计费通常基于 token 数量，分为输入 token 和输出 token 两部分。在 Agent 循环场景中，每一轮对话都需要将完整的上下文——包括系统提示、历史消息、工具定义和之前所有轮次的交互记录——作为输入发送给模型。随着轮次增加，每轮的输入 token 数量会线性甚至超线性增长。15 万 token 的消耗正是因为每一轮都携带了前面所有轮次的失败记录，上下文像滚雪球一样膨胀。用户体验和成本控制双双崩盘。

两个关键修复方案

作者给出了两个成本极低但效果显著的修复方案：

• 如果收到的是字符串，就直接解析它。 既然模型发来的字符串内容是无歧义的合法 JSON，那么解析它不会带来任何风险，也几乎不产生成本。与其教条地拒绝，不如宽容地接受。
• 拒绝时，要指出模型真正犯的错误，而不是抛出解析器的原始报错。 「Expected double-quoted property name at position 827」这种信息对模型毫无价值——它无法据此采取任何行动。而「检查 location 是否位于 createItem 内部、紧挨着 item」则把问题说得清清楚楚，模型立刻就能修正。

这个细节点出了 AI Agent 工程的一个通用原则：错误信息是写给模型看的，必须是「可操作的」，而非「技术正确的」。 这与 Prompt Engineering 的核心思想一脉相承——对模型的指令应当具体、可执行且不产生歧义。Google DeepMind 和 Anthropic 的研究都表明，当错误反馈包含明确的修复方向时，模型的自我纠正成功率可以提高数倍。

教训二：AI Agent的轮次上限不等于熔断机制

作者原本设置了一个「最大轮次」上限来防止无限循环，但这个上限设得太宽，根本无法及时捕捉到一个已经卡住的模型。

为什么固定轮次上限不够用

这里有一个反直觉的洞察：第四次相同的失败，并不比第三次提供更多信息。 当模型陷入重复失败时，继续给它机会不会带来任何转机，只会持续烧钱。一个宽松的轮次上限，本质上是在为无意义的重试买单。

基于「连续失败」的熔断策略

熔断器（Circuit Breaker）是微服务架构中的经典容错模式，最早由 Michael Nygard 在《Release It!》一书中系统阐述，后来 Netflix 的 Hystrix 库使其广为人知。其核心思想来自电路中的断路器：当下游服务连续失败达到阈值时，熔断器跳闸，后续请求直接快速失败而不再发送。传统熔断器通常基于时间窗口内的失败率来触发，但在 AI Agent 场景中，作者提出了一种更精准的变体。

作者的新策略更聪明：

• 连续 3 次工具调用失败即停止。 关键在于「连续」——任何一次成功都会重置计数器。这样一个正确执行了很多步的长任务，不会因为累计触发上限而被误伤。这种设计特别适合 Agent 的工作特征：一个复杂任务可能包含几十个步骤，偶尔失败一两次是正常的，但连续三次相同类型的失败则高度表明模型已陷入无法自行恢复的死循环。
• 在最后一轮明确告知模型这是最后一轮。 这样模型会向用户解释发生了什么，而不是「悄无声息地死掉」，留给用户一个莫名其妙的中断。

从「固定轮次」到「连续失败计数」，本质上是从「限制总量」升级到「识别状态」——真正的熔断器关心的是系统是否卡死，而不是跑了多少圈。

教训三：API重试策略——重试失败请求几乎总是错的

第三个教训涉及网络请求的重试策略，作者的结论相当明确且值得所有 AI Agent 开发者记住。

永远不要重试HTTP错误响应

HTTP 协议定义了明确的状态码体系：4xx 表示客户端错误（如 400 Bad Request、429 Rate Limited），5xx 表示服务器错误（如 500 Internal Server Error、503 Service Unavailable）。在传统 Web 开发中，对 5xx 错误进行带指数退避（Exponential Backoff）的重试是标准做法，因为服务器错误通常是暂时性的。但 AI 模型 API 的计费逻辑彻底改变了这个等式。

当你收到一个 HTTP 错误响应（比如 4xx、5xx）时，这意味着模型已经运行过、你已经付过费了。 即使返回 500 错误，模型推理可能已经完成并产生了计费。如果此时盲目重试，你只会被双重计费。请求已经到达服务器并被处理，重试没有任何安全保障。

唯一值得重试的例外：连接未建立

但有一个例外至关重要：当 fetch 抛出 TypeError 拒绝时，意味着没有任何响应头抵达——也就是说请求根本没有到达服务器，什么都没有被计费。在 JavaScript 的 fetch API 中，当网络连接本身失败（DNS 解析失败、TCP 连接超时、TLS 握手失败等），fetch 会抛出 TypeError 而不是返回 Response 对象。这个区别至关重要：TypeError 意味着 HTTP 请求根本没有离开客户端或没有到达服务器的应用层，因此不可能产生任何服务端处理或计费。

这正是「连接中断」在用户端的表现形式。对用户来说，这才是最常见、最需要被优雅处理的场景。因此，唯独这一种情况可以安全重试，也正是这一种情况最值得重试。这也是幂等性（Idempotency）概念在 AI API 场景下的实际应用——只有确认请求未被处理时，重试才是安全的。

判断标准非常清晰：请求是否真正到达了服务器？ 到达了就别重试，没到达才重试。这条简单的分界线，避免了双重计费的同时，又保证了对真实网络抖动的容错。

对AI Agent开发者的核心启示

把这三个教训串起来看，会发现它们指向同一个更深层的主题：AI Agent 与传统软件的错误处理逻辑截然不同。

在传统程序里，严格校验、固定重试上限、失败即报错，都是无可指摘的最佳实践。错误处理建立在「调用者能理解错误」的假设之上：开发者看到堆栈跟踪能定位问题，程序收到错误码能执行对应的恢复逻辑。但 AI Agent 引入了一个根本性的变量：调用链中的决策者是一个概率模型，它通过自然语言理解错误信息，并基于统计模式生成修复策略。在 Agent 场景下：

1. 模型是一个「看不见上下文」的黑盒。 你的错误处理策略必须假设模型无法理解技术细节，因此错误信息要「翻译」成模型能行动的语言。这正是越来越多的 Agent 框架（如 LangChain、CrewAI）开始内置结构化错误反馈机制的原因——将原始异常信息转译为模型友好的自然语言描述。
2. 每一次循环都在花钱。 失控的重试不是性能问题，而是直接的财务损失。熔断必须基于「是否卡死」的状态判断，而非粗糙的次数上限。
3. 宽容比严格更划算。 能无歧义解析的输入就接受它，不要为了校验的纯粹性去付出昂贵的重试代价。

对于任何正在构建生产级 AI Agent 的团队来说，这三个来自真实生产环境、且「先烧了真金白银才发现」的教训，都值得写进工程 checklist 里。Agent 的可靠性，往往不取决于模型有多聪明，而取决于你如何设计它失败时的行为。