如何避免 AI 智能体超支
作者 Théo P. 和 Inès L.8 分钟阅读
绝大多数 AI 账单上的意外都出自同一个原因：一个没有上限的智能体。它循环、重试、拖着越来越长的对话，直到账单来了才有人知道。
解决办法不是更好的模型或更好的提示词，而是一个能拒绝下一次调用的限制，而多数被叫作「预算」的东西并不会拒绝。
一句话要点
- 告警告诉你已经花了多少，它不是限制。
- 服务商的支出上限通常只是一条通知，而不是硬停。
- 没有任何预算能拦住正在进行的那次调用。真实的最坏情况是「预算加一次调用」。
- 多数智能体框架根本没有成本限制，或者只限制调用次数而不是钱。
- 真正该做的检验：你的上限有没有拒绝过任何东西？
告警不是限制
监控在钱花掉之后运行；限制在下一次调用之前运行并说不。两者都有用，但只有一个是控制手段。
| 监控 | 真正的限制 | |
|---|---|---|
| 何时生效 | 调用结束之后 | 下一次调用开始之前 |
| 能做什么 | 通知你 | 拒绝 |
| 最坏情况 | 无上限 | 再多一次调用 |
| 用途 | 确定上限、发现漂移 | 停止运行 |
这里有个今天就能做、且不需要任何阈值的检验：把当前上限记录下来的拒绝取出来看。它拒绝过任何东西吗？一个从未拒绝过任何调用的数字不是控制，而是一条注释。
按智能体统计的事后花费。这正是用来决定上限该定多少的视图，也正是不该用来停止运行的东西。
服务商的支出上限到底做了什么
人们以为服务商后台里的那个数字是一堵墙，它多半只是一个门铃。
| 服务商的控制项 | 它其实是什么 |
|---|---|
| OpenAI 的项目或组织支出上限 | 默认是软预算：只通知，请求照常通过。硬停止存在，但要单独开启，开启后会拒绝调用直到你调高上限 |
| Anthropic 的 Spend Limits API | 仅限 Enterprise，仅支持按月，且覆盖的是人员席位用量而不是智能体的 API 花费 |
| Anthropic 按等级的月度上限 | 一个真实的天花板，但作用于整个组织且按月：一次失控运行会把成本问题变成所有人的服务中断 |
来源：OpenAI 的 spend limits 指南、Anthropic 的 Spend Limits API 和速率限制。Anthropic 自己的文档说得更远：不要用它的花费数字来做门禁，因为读数不可用时它可能显示为零，应当只当作参考信息。
由此得出两点。服务商上限是兜底，不是第一道防线。而按月、按组织的天花板在形状上根本不适合拦住一次异常运行：等它触发时，会把其他所有东西一起带下水。
你拦不住正在进行的那次调用
这是任何诚实的预算文章都必须说出口的部分。
一次调用花了多少，只有在它结束之后才知道。所以任何运行中的预算都无法阻止一次昂贵的调用冲破上限，它只能阻止下一次。你真实的最坏情况是预算加一次调用。
这有一个实际后果。如果单次调用有可能花掉你一半的预算，这个预算就不可能起作用。只有当上限明显大于该智能体可能发出的最大单次调用时，它才表现得像个上限，而三倍是一个合理的经验下限。把这个数定好本身是另一个话题：每个智能体该给多少预算 把账算了出来。
这也意味着好的实现会在花钱之前先预测：它会看最近几步花了多少、增长有多快，以及这个模型物理上能发出的最大一次调用，然后在预测会冲破上限时拒绝。预测就是全部窍门，因为测量永远来得太晚。
常见工具到底限制了什么
如果你默认框架会保护你，请去核实。多数框架限制的不是钱，而且多数默认没有限制。
| 工具 | 限制什么 | 默认值 |
|---|---|---|
| Claude Agent SDK | 每次运行的美元额度，以及轮数 | 两者都不限 |
| Anthropic Messages API | 每次回复的 token 数 | 没有默认值，必须自己设 |
| OpenAI 账户 | 每月美元额度 | 软性，仅通知 |
| OpenAI Agents SDK | 轮数 | 10 |
| LangGraph | 步数 | 有的文档写 25，有的写 1000 |
| LangChain 中间件 | 调用次数，没有成本或 token 预算 | 无限制 |
| Pydantic AI | token、请求数、工具调用 | 50 次请求，无 token 限制 |
| CrewAI | 迭代次数 | 20 或 25，取决于看哪一页文档 |
从这张表里要拎出三点。
几乎所有东西默认无上限。 安全的假设是：在你亲手设置之前，你没有任何天花板。
数调用次数不是预算。 十次调用可能是一美分，也可能是十美元，取决于每次携带多少文本。LangChain 的中间件限制的是调用次数，完全没有 token 或成本预算。
够不到子智能体的限制只是装饰。 这是天花板变成假象的最常见方式：父级配置了限制，它派生出子级，而子级用默认值运行。在被广泛使用的框架里，这类情况都有记录。如果这篇文章你只执行一件事，就执行这件：给父级设一个限制，派生一个子级，并证明它继承了。
让预算真正生效的四条规则
- 限制钱或 token，不要限制步数。 一步的价格是浮动的，一块钱不是。
- 给每一步一个上限，也给整次运行一个上限。 一次分成五十条并行分支的运行，可能每一步都不超预算，总额却是预期的五十倍。
- 在派生前预留，不要中途打断。 半路砍掉分支，留下的是一份随机的半成品；拒绝启动则是明确的，而且可以重试。
- 上限触发时，保住已完成的工作。 一次把已产出内容全部丢弃的停止，会把成本问题变成全损，而这正是运维人员关掉上限的原因。
最后一点值得单独一行。预算触发的停止应当返回智能体已经产出的内容，加上花费明细和停止原因，并说明是哪个上限触发的。只说「超出预算」的停止不给你任何可执行的信息。
实际上会糟到什么程度？
关于生产环境中智能体失控的频率，没有任何公开的基础数据，所以对任何言之凿凿的频率都要保持怀疑。有据可查的是量级，而它比传说朴素得多。
被记录的事故大多在几百到几千美元之间：某个案例约 2150 美元的意外花费，某个单一用户四天 235 美元，某次比设定预算超出 70%。与此同时，业内被转载最多的故事，一篇匿名的「我们在 AI 智能体上花了 47000 美元」，没有点名任何公司，没有出示任何账单，而它自己的周度数字加起来是 25658 美元，不是 47000。
真正的风险不是一张惊人的账单，而是一笔安静、反复、四位数的漏损，月复一月却没人把它归因于任何事。
常见问题
设置 token 上限能控制成本吗？
只能控制每次回复的长度。它对智能体循环多少轮毫无作用，而失控的成本正是从那里来的。
该用服务商的支出上限吗？
该用，作为兜底，如果服务商提供硬性版本就打开它。只是别把它当作你的控制手段：它通常按月、按组织，而且默认是软性的。
合理的起步预算是多少？
至少是该智能体可能发出的最大单次调用的三倍，否则它可能在有机会拒绝之前就被撑破。从这里起步，再用真实运行去调。
我的上限从未触发过，是好事吗？
那说明它没被测试过，而不是说明它有效。给一个测试用智能体设一个刻意极小的预算，确认你会收到一个干净、有类型、并指明触发了哪个限制的拒绝。
循环检测能替代预算吗？
不能，它们回答的是不同问题。循环检测限制的是重复多少次，预算限制的是这些重复可以花多少钱。两者都要有。
下一步
这周检查三件事：你的上限限制的是钱而不是调用次数吗、它能不能到达子智能体、以及它有没有拒绝过任何东西。然后用 每个 AI 智能体该给多少预算 来确定那个数字。