最容易把 Agent 账单推高的，往往不是某次调用选了昂贵模型，而是重试没有出口。
Prompt 里写着“失败后重新规划并执行”，max_iterations 又设得很高。只要外部 API 持续报错，Agent 就可能在“报错 → 重规划 → 再次调用 → 再次报错”之间打转。如果每轮都带回完整历史，输入 Token 会继续增加；模型还要解释错误、重新规划和调用工具，输出 Token 也在累积。
《AI 时代的 FinOps：工作流、RAG、AI Agent 与 Agentic AI 指南》提到，多数模型 API 按输入和输出 Token 计费；自托管模型也不是免费，只是成本转移到了 GPU、CPU 和高性能实例上。《AI烧钱失控？一文读懂 FinOps for AI》也强调，AI 算力的计费方式、资源形态和使用逻辑，与传统云资源并不相同。
所给材料《Token 经济学：智能体 AI 时代的新 FinOps》写到，GitHub Copilot 在 2026 年推出基于 GitHub AI Credits 的按使用量计费模式。对自动执行任务的 Agent 来说，月末看总账已经太晚。系统需要知道某个任务此刻用了多少 Token、为什么还没有停，以及下一次调用是否应该放行。
先把模型调用收进网关
不要让 Agent 在业务代码里直接持有模型厂商的 API Key。更稳妥的链路是：
Agent 请求
→ API Gateway for LLM
→ 配额与频率检查
→ model_mapping 路由
→ 模型调用
→ Token 记账
→ 状态指纹与状态机检查
→ 继续、降级或挂起
《从 AI Agent 到模型推理：端到端 AI 可观测实践》提到，生产环境通常会用 API 网关承担流量防护和 API 管理。放到 Agent 场景里，网关还要多做三件事：统一管理密钥、决定调用哪个模型、在请求前后核算 Token。
模型路由可以按任务难度分成 L1、L2、L3：
- L1： 信息提取、格式转换和初步规划，优先使用本地量化模型或低成本 API，例如 Qwen 3.5 或其他 7B—14B 级轻量模型。
- L2： 需要逻辑推理和多步规划的任务，交给中型专家模型。
- L3： 只有在 L1、L2 失败，并经过人工或高阶 Agent 确认后，才调用 Llama 4、GPT-5 级别的模型。
这份模型名单只是路由样例。真正重要的是把升级条件写进网关配置，而不是让开发者在代码里随手指定高成本模型。model_mapping 还应记录每次升级和回退的原因，方便事后定位是哪类任务把账单推高了。
预算要跟着任务走
只给整个账户设置月度预算并不够。一个失控任务，可能在其他正常任务发现异常前就消耗掉大量额度。路由层至少需要三类限制：
| 控制对象 | 触发条件 | 系统动作 |
|---|---|---|
| 用户或项目配额 | 接近上限或已经触线 | 先告警，触线后返回 429 Too Many Requests |
| 单次任务预算 | budget_id 对应的 Token 用量达到上限 |
终止当前 Task，不再放行后续模型调用 |
| 调用频率 | 短时间内连续请求 | 限速、拒绝或挂起任务 |
任务预算尤其关键。以“法律文书审核”为例，可以为一个 Agent 实例分配独立的 budget_id，并把 50,000 Tokens 设为示例上限。请求进入时先检查剩余额度，模型返回后再更新实际用量。达到阈值后，工作流必须停止，而不是让 Agent 自己决定是否再试一次。
Redis 可以承担项目级和任务级的实时计数。技术选型不是重点，重点是计数必须发生在调用链上，不能等模型厂商出账后再汇总。
自动续费拦截也只能算最后一道兜底。如果异常调用已经发生，关闭续费并不能收回成本。网关配额应先于充值或续费动作触发，让任务在内部预算触线时就停下来。
只设 max_iterations 还不够
max_iterations 能限制总轮数，却不一定能及时识别 Agent 正在原地打转。更有效的办法，是同时检查 Prompt、执行状态和 Token 消耗。
- 检查 Prompt 指纹： 哈希可以抓到完全相同的请求；语义相似度可以识别换了措辞、实际意图没有变化的请求。一组可落地的初始规则是：连续 3 轮中出现 2 次高度相似的 Prompt，
Cosine Similarity > 0.95，同时执行结果没有实质变化，就判定为疑似死循环。 - 检查状态转移： 记录
Planning → Executing → Evaluating的路径。如果状态长期呈现A → B → A → B的重复结构，说明 Agent 没有向目标推进。 - 设置财务断路器： 当单次循环的 Token 消耗超过同类任务历史平均值的 3 倍，立即挂起任务，进入
Human-in-the-loop审核。
这些数字适合作为初始配置，不应被当作所有业务通用的标准。没有足够历史数据时，先用任务预算和 max_iterations 设硬上限；积累样本后，再调整相似度和异常消耗阈值。
告警要告诉人从哪里接手
只弹出一句“Token 超限”没有多少用。触发拦截时，系统至少应留下这些信息：
- 当前项目、用户和
budget_id； - 实际调用的模型及 L1/L2/L3 路由等级；
- 当前迭代次数和最近的状态转移路径；
- 已消耗的 Token 与触发的拦截规则；
- 任务是被限速、终止，还是等待人工处理。
有了这些记录，操作员才能判断应该修改输入、切换工具，还是直接结束任务。否则，人工接管很容易变成另一轮盲目重试。
按结果收费前，先把内部账算明白
在设备预测性检修等场景里，客户通常关心的是有没有准确预测故障，而不是服务商调用了多少 Token。但对服务商来说，每一次模型调用、算力占用和人工介入都要进入成本核算。
可以先按下面的方式计算单次成功交付成本：
（推理成本 + 算力损耗 + 人工干预成本）÷ 成功交付件数
如果同一类任务的成本忽高忽低，又无法说明波动来自模型升级、重试还是人工接管，那么按结果收费就接近押注。只有当每笔成本都能归到具体任务，异常调用也能及时停下，结果定价才有可操作的基础。
上线前逐项核对
- Agent 不再直连模型厂商 API Key，所有请求经过 API Gateway。
- L1/L2/L3 路由规则已经配置，并写明升级与回退条件。
- Redis 中同时记录项目级和任务级 Token 用量。
- 每个 Agent 实例都有独立的
budget_id和预算上限。 -
max_iterations、Prompt 相似度和状态机重复路径同时生效。 - 财务断路器触发后会真正停止调用，而不是自动开启下一轮重试。
- Human-in-the-loop 能看到模型、Token、状态路径和拦截原因。
