账单先从行为里找
很多团队一开始盯着模型单价：每百万 Token 多少钱、哪家 API 更便宜。但 Agent 真正容易失控的地方，往往藏在流程里。
一次用户请求，Agent 可能先读历史上下文，再查向量库，调用业务 API，判断结果是否可用，失败后重试，最后再写入记忆。每一步都可能产生费用。账单看起来是一串模型调用、数据库访问和云资源消耗，回到业务侧却很难说清：到底是哪一个 Agent、哪一段流程、哪一次决策把钱花掉了。
这里说的“幽灵消费”，指的就是这些没有被用户直接感知、却持续发生的成本：重复拉取数据、工具循环调用、上下文越滚越长、空闲时段还在推理。它不一定来自模型太贵，更常见的原因是 Agent 没有被当成一个可审计的生产系统来管理。
AWS 的 FinOps Agent 案例给了一个参照
FinOps 原本处理的是云成本问题，核心是看得见、归得清、能优化。放到 Agent 上，难点没有变，只是对象换了：从 EC2、存储、网络，变成了模型 API、向量数据库、中间件、业务工具和后台任务。
AWS 官方博客《FinOps + DevOps 双Agent — AI驱动的云成本优化实战》里给了一个清晰样板。AWS 在 2026 年 6 月 Preview 的 FinOps Agent 与 DevOps Agent 协作方案中，让 FinOps Agent 发现费用异常、分析标签和 CloudTrail 日志，再把处理动作交给 DevOps Agent 执行。案例中，系统定位到一个开发环境里长期运行、未被终止的资源，最终节省每月约 4,100 美元的不必要支出。
这件事对 Agent 成本治理的启发很直接：不要只等月底账单出来再复盘，要把 Agent 的每次调用、每个工具动作、每段上下文和对应成本提前记录下来。否则，Agent 越自动化，成本越难追。
第一处：上下文越滚越长
Token 费用最容易被低估。团队选型时常看模型报价，却很少把真实调用模式算进去。Agent 与普通聊天机器人不同，它常常需要携带历史对话、系统提示词、工具说明、检索结果和中间推理材料。一次看似简单的请求，实际输入可能比用户问题长得多。
审计时，至少要在模型调用日志里记录这些字段：agent_id、session_id、prompt_tokens、completion_tokens、cached_tokens、model_name。如果缓存机制存在，也要把缓存命中情况单独记下来，不能只看总 Token。
一个实用判断是：同一类任务跑了多轮之后，Token 消耗是否持续上涨。如果上涨来自必要上下文，那可以接受；如果只是历史记忆不断堆积，就要做摘要、裁剪或分层记忆。Agent 不需要永远记住所有东西，尤其不该把无效中间结果一轮轮带进下一次调用。
第二处：工具调用开始打转
Agent 的成本不只在模型上。它调用搜索、数据库、CRM、ERP、工单系统、代码执行器，每次都可能有费用，也可能放大延迟和错误。
更麻烦的是重试。工具超时、返回空结果、字段不匹配，Agent 可能会再试一次；提示词写得含糊时，它还可能换一种说法继续调用同一个工具。表面上看，它在努力完成任务；从账单看，就是同一段逻辑反复烧钱。
这里要记录的字段包括：request_id、tool_name、input_hash、duration、status、retry_count、cost_estimation。其中 input_hash 很有用，它能帮助发现同一参数被连续调用的情况。
生产环境里建议给单次会话设工具调用上限。上限是多少，取决于业务流程本身，不要拍脑袋写死。客服查询、报表生成、代码修复、采购审批的合理调用次数完全不同。关键是先建立基线，再对明显偏离基线的会话告警。
第三处：没人用，它还在跑
有些 Agent 被设计成轮询模式，定时查消息队列、数据库变更或外部 API。这个设计不一定错，但如果没有空闲控制，就会在低峰期继续消耗推理资源。
审计方式也很直接：把用户请求量、Agent 活跃时间、Token 消耗和后台任务次数放在同一张图里看。如果没有用户交互，Token 仍然稳定产生，就要追问这部分推理是否必要。
可以考虑把常驻进程拆成按需触发。使用云服务时，可结合事件触发、队列和 Serverless 架构减少空转。使用 AWS 体系的团队，也可以把 CloudWatch 告警、Webhook 和 Bedrock 调用日志串起来，先做最小版本的监控闭环。
先把标签打对，否则什么都归不了因
Agent 成本治理的第一步不是买工具，而是统一标签。
至少需要这几类标识：agent_id、environment、project、owner、session_id。它们要贯穿模型 API、业务工具、向量数据库、日志系统和云资源。少了这一步，后面所有仪表盘都会变成总量曲线：知道花多了，却不知道是谁花的。
AWS Cost Explorer 支持按标签做成本分析和预算告警。开源体系里，也可以用 Prometheus 一类监控系统收集指标，再按标签聚合。工具选择不是重点，重点是成本数据必须能回到具体 Agent 和具体场景。
FinOps Foundation 在 2026 年 3 月发布的《AI for FinOps: Agentic Use Cases in FinOps》中提到，随着组织从生成式 AI 的早期尝试走向更主动、自主的 Agent，用 Agent 处理 FinOps 场景正在出现。反过来看，Agent 自身也需要被 FinOps 化管理。
仪表盘别做成摆设
Agent 级成本仪表盘不需要一开始就复杂，先盯住几项指标：
- 每个 Agent 的总 Token 消耗
- 单会话平均 Token 数
- 工具调用次数
- 重试次数和失败率
- 空闲时段消耗
- 按项目、环境、负责人拆分的成本
这些指标要能触发动作。比如某个 Agent 的单会话 Token 突然升高，就自动创建工单；某个工具连续失败并重试，就暂停后续调用；某个开发环境 Agent 在非工作时段持续产生费用，就通知负责人确认是否需要关闭。
成本治理最怕只展示不处理。仪表盘做得再漂亮，如果没有告警、限流、暂停和人工确认机制，最后还是月底开会解释账单。
权限越大，浪费面越大
Agent 接入业务系统后，成本问题会和权限问题混在一起。一个只能查询库存的 Agent，最多多查几次；一个能修改采购订单、触发云资源创建、调用外部付费接口的 Agent，一旦进入循环，损失范围就大得多。
比较稳妥的做法是按动作分级：查询类操作可以自动执行；写入、删除、采购、扩容等动作要加审批；高成本 API 要有频率限制和预算限制。对企业系统来说，最小权限原则仍然适用，只是执行对象从人扩展到了 Agent。
这也能减少“幻觉循环”的后果。Agent 判断错了并不可怕，可怕的是它在没有边界的权限里连续执行。
做一个成本看门狗
可以参考 AWS FinOps Agent 与 DevOps Agent 的分工，给内部 Agent 系统加一个轻量的成本看门狗。它不处理业务，只负责盯成本和异常行为。
它可以做几件事：
- 定期扫描各 Agent 的会话消耗
- 发现 Token、工具调用或重试异常时发出告警
- 对超过预算的会话限流或中断
- 保存异常上下文，方便工程团队复盘
- 把问题分派给对应项目或负责人
这个看门狗不一定也要做成复杂 Agent。很多场景下，CloudWatch、Prometheus Alertmanager、Webhook、工单系统就能搭出第一版。先把发现到止损的链路跑通，比追求自动决策更重要。
上线前先做成本压测
Agent 上线前，除了功能测试，也要做成本压测。选几类高频场景、失败场景、长对话场景和异常输入场景，观察 Token、工具调用和重试次数。很多账单问题，压测时就能看出来。
例如，一个客服 Agent 在正常问答里表现稳定，但遇到规则冲突、库存缺失或用户反复追问时，可能会频繁调用知识库和工单接口。问题不在它能不能回答，而在它为回答付出了多少成本。
Agent 成本控制的目标很朴素：每一次推理、每一次工具调用都要能解释。解释不了的，就先标出来；持续解释不了的，就该限流、裁剪或重构。
