聊 Agent FinOps，常见讨论会先落到“让智能体帮忙查云账单”。Vantage FinOps Agent 接入 Slack 后，可以理解云基础设施、回答成本问题，并执行自动化节省动作。AWS 中国博客 展示了另一种分工：FinOps Agent 发现费用异常、分析根因，DevOps Agent 负责运行时验证和安全清理。该案例给出的结果是，每月减少约 4,100 美元的不必要支出。
这些方案解决了云成本治理的执行效率。企业还得管另一笔账：Agent 自己调用模型、占用 GPU、访问外部 API 产生的费用。系统也许很会找闲置资源，却未必管得住一条失败重试链。
FinOps Foundation 的 FinOps for AI 概览 已经把 cost-per-token、费用波动和 GPU 稀缺列为需要持续跟踪的问题，并建议设置配额、标记资源、定期检查成本与用量。Usage.ai 在工具评估文章中也提到，月度云支出超过 10 万美元的团队经常面临同一种困境：看板数据很多，工程团队却没有足够时间逐项处理异常。
看板晚一步，网关先做决定
成本看板适合解释已经发生的支出。真正的止损动作，要放到模型网关和工具网关。
每个 Agent、子 Agent 和工作流都应有独立身份。多个任务共用一个 API Key，限流只能一刀切，账单也很难追到具体业务。一次请求发出前，网关至少要检查这些信息：
agent_id可以使用哪些模型和工具，是否拥有写权限；- 当前 RPM、TPM、并发量以及任务预算；
- Prompt 长度、最大输出、模型价格和外部 API 费用；
- 本次操作是否需要人工审批。
预算判断可以采用“预估成本 → 预占预算 → 执行 → 按实际消耗结算”的流程。接近上限时，系统可以缩短上下文、切换低成本模型、暂停非必要工具调用，或者把任务降为只读。预算耗尽后，网关直接拒绝新的高成本调用，同时保留任务现场，等待后续处理。
RPM、TPM 和预算水位没有一套适用于所有业务的固定阈值。客服问答、代码生成和批量数据处理的成本结构不同，阈值应根据各自基线和风险设定。
自动重试，是最隐蔽的续费按钮
合约自动续费会出现在采购单上，运行时的自动续跑却藏在状态机里。参数错误、鉴权失效、前置依赖未完成，如果都被当成可重试异常，Agent 就会反复读取上下文、调用工具，再生成一次几乎相同的下一步。
状态机里应明确记录：
retry_count：已经重试了多少次；last_error_code：上一次失败原因；next_retry_at：何时允许再次尝试；budget_remaining：当前任务还剩多少预算；parent_task_id：预算来自哪个父任务。
错误也要分类。参数不合法、权限不足等问题通常不应无条件重试；超时或限流可以按策略退避。网关还可以用 tool_name + normalized_args + error_code + next_state 生成调用指纹。同一条 Trace 中反复出现相同指纹时，系统应触发熔断并告警，而不是继续让模型猜下一步。
子 Agent 必须继承父任务的预算和重试状态。否则新建一个子任务或 Session，就可能绕过原来的配额。failed、budget_exhausted 和 waiting_for_approval 也要成为明确状态，不能被模型自行解释成“再试一次”。
真正的套餐续费和自动充值同样需要隔离。Agent 使用的凭证不应拥有升级套餐、开启自动充值或修改续费设置的权限。预算追加由财务或业务负责人从独立审批通道完成，并写入审计日志。
Token 要记到任务，不能只记到模型
只按模型或 API Key 汇总费用，最多能回答“哪个模型花钱多”，回答不了“哪项业务为什么越来越贵”。FinOps Foundation 提到的资源标签和配额，需要继续细化到 Agent 的任务层。
| 建议字段 | 用途 |
|---|---|
agent_id、workflow_id、task_id |
追踪具体智能体、工作流和任务 |
tenant_id、project_id |
将费用归到客户、部门或项目 |
model、tool |
区分模型费用和外部 API 费用 |
prompt_tokens、completion_tokens |
分开观察输入与输出消耗 |
retry_count、status |
找出失败重试和未完成任务 |
estimated_cost、actual_cost |
对比调用前预估与实际支出 |
trace_id、approval_id |
串起调用链和人工审批记录 |
Prompt Token 和 Completion Token 应分列记录，但不必套用统一比例。某个工作流的 Prompt 持续增长、输出基本不变时，再去检查上下文重复、RAG 返回过长或多 Agent 消息反复转抄，会比盯着一个固定比例更有用。
接入 MCP 或更多外部工具后，还要把工具调用次数、失败状态和返回内容规模放进同一条 Trace。模型账单与 API 账单如果分开记录，排查时就很难拼回一次完整任务。自建模型使用的 GPU 资源，也应按项目、模型和工作流打标签，避免只看到集群总成本。
会省钱的 Agent，也不能自己批预算
Vantage 通过 Slack 降低了查询和执行成本优化动作的门槛；AWS 的双 Agent 案例则把费用分析与运行时操作拆给不同角色。这个分工值得保留到权限设计里：
- 查询身份可以读取账单、标签和用量，生成建议或创建工单；
- 执行身份只接受经过校验的操作，并使用范围更窄的权限；
- 预算追加、套餐变更和破坏性清理交给独立审批人。
同一个 Agent 不应同时发现异常、提高额度、批准额度，再执行资源变更。AWS 案例中的每月约 4,100 美元属于该场景的实际结果，不能直接拿来预测其他企业的收益；更值得借鉴的是角色拆分和运行时验证。
企业级审计日志需要串起：谁发起任务、哪个 Agent 执行、命中了哪条策略、预估和实际费用是多少、谁批准了预算、调用了什么工具、最终结果如何。日志只记一行“模型调用成功”，出了问题仍然无法追责。
上线前，先过一遍这些问题
- 子 Agent 能否通过新建身份或 Session 重置预算？
- 预算耗尽后，网关会真正拒绝请求，还是只发送告警？
- 相同参数和错误反复出现时，状态机会不会熔断？
- 每笔 Token 和 API 费用能否追到任务、租户和审批人？
- Agent 是否拥有修改套餐、自动充值或续费设置的权限？
- 高成本调用和写操作是否经过独立审批？
月底账单仍然要看，但那是复盘。Agent 拥有执行权后，API 成本控制的第一道门应放在每次模型调用和工具调用之前；LLM Token 监控则要跟到任务、状态和审批记录。否则 FinOps 最后还是一张事后看板。
