自动续费至少有固定周期，Agent 账单却可能在一次任务里层层叠加。用户只发出一个请求，后台可能依次发生 RAG 检索、模型推理、工具调用、失败重试和再次规划。即便单次 Token 更便宜，整条链路也未必便宜。
2026 年谈 Agent，演示能跑通只是第一关。上线后，财务和工程团队很快会追问：这笔调用属于哪个业务？一次任务跑了多少轮？工具失败后为什么还在继续？预算触顶时系统会不会停？
最典型的漏洞，是 Agent 没有 max_iterations、超时和明确退出条件。数据库查询或 Python 执行持续报错时，系统可能反复进入“尝试—失败—再尝试”。月底总账能看到花了多少钱，却很难说明钱花在哪一步。
Agent FinOps 要补的正是这段空白。借用 FinOps Foundation 推动的云成本管理思路，可以把工作拆成分配、治理、优化和预测。每一步都要落到请求日志和执行规则上。
一条请求，为什么会长成一串账单
Agent 的成本通常藏在三段链路里。
长上下文是第一段。多轮对话不断携带历史消息，RAG 又把检索结果塞进提示词。如果每轮都发送完整上下文，输入 Token 会持续累积。
第二段是重复推理。多路并发、投票机制和自我反思循环可以提高部分任务的稳定性，也会增加模型调用。审计时不能只看最终答案，还要看到一次任务实际触发了多少轮推理。
第三段是工具失败后的重试。Agent 调用数据库、代码执行器或外部接口失败后，如果没有终止条件，重试次数可能比正常推理更值得关注。
因此，成本审计的对象应当是完整任务轨迹，包括模型调用、输入与输出 Token、迭代次数、工具结果、错误类型和路由变化，而非最后一次模型返回。
先把钱记到具体业务
所谓 Token 级归属，落地时通常从给每次请求添加业务标签开始。team_id、project_id 和 feature_id 应跟随请求进入模型代理层，并写入成本记录。
| 审计视角 | 建议记录 | 要回答的问题 |
|---|---|---|
| 财务归属 | team_id、project_id |
哪个团队和项目承担成本 |
| 产品归属 | feature_id |
哪项功能产生了调用 |
| 执行轨迹 | 模型、输入与输出 Token、迭代次数 | 链路在哪一步变长 |
| 工具调用 | 工具名称、返回状态、错误记录 | 是否存在连续失败和重复尝试 |
这样拆开以后，账单才能落到具体场景。自动对账 Agent、采购比价 Agent 和合规初审 Agent 即便属于同一部门，也可能有完全不同的调用模式和预算边界。
腾讯 SkillHub 的相关材料把这些任务列为 Agent 与工作流融合的典型场景，同时强调人工在环（HITL）和审计。对会影响业务结果的流程，人工接管应放在预算触发、连续工具失败和模型降级等节点上，防止 Agent 无休止地自行重试。
上限要离执行链路足够近
月底对账只能发现问题，无法阻止正在发生的循环。预算控制需要进入 Agent 的运行链路。
单次任务层面，至少应设置最大迭代次数、总 Token 上限、执行超时和工具失败上限。任何一项触发后，都要明确终止、降级或转人工，不能只记录告警。
用户和团队层面，可以按用户、项目或团队分配预算。这样既能避免单个异常请求持续消耗，也能让业务负责人看到自己的实际用量。
全局层面，应监控调用量、成本和失败重试是否明显偏离历史基线。出现异常时，可以暂停高消耗任务、切换到低成本模型或进入人工审核。
这些阈值不宜照搬统一比例。订单查询、自动对账和合规初审的任务长度不同，预算应来自各自的历史数据和业务容错要求。
省钱之前，先看链路里哪一段最贵
模型路由是最直接的优化手段。分类、格式转换等规则明确的任务，可以优先交给轻量模型；多步规划和复杂推理再调用能力更强的模型。路由结果也要进入日志，否则模型切换后很难判断省下了多少成本、是否影响任务结果。
上下文同样需要约束。重复出现的系统指令和知识库片段可以使用 Prompt Caching；多轮任务则应避免每次都携带完整历史。RAG 检索返回多少内容、其中多少真正参与回答，也值得单独记录。
多路并发、自我反思和失败重试则要算投入产出。如果增加调用没有带来可观察的成功率改善，这些架构复杂度最终只会留在账单上。
预测可以从一个简单公式开始：
预计周期成本 = 预计任务量 × 单任务平均成本
单任务平均成本不能只统计最后一次模型调用，还应覆盖整条链路中的输入与输出 Token、工具重试、模型路由和降级调用。业务扩容前先按历史任务计算一次，比月底面对总账更有用。
LiteLLM适合放在模型入口
第一版工具链不必堆很多产品。可以由 LiteLLM 负责统一模型入口和预算，企业现有日志系统保留执行轨迹，业务系统提供团队、项目和功能标签。
作为开源代理层，LiteLLM 可以放在业务 Agent 与模型 API 之间，用于统一调用接口、记录用量、按团队归集成本和设置预算。团队还可以通过虚拟 Key 隔离不同项目，并根据策略进行模型路由或故障切换。
当系统同时调用 OpenAI、Anthropic，或接入昇腾环境中的本地模型时，统一入口能减少散落在业务代码中的适配和计费逻辑。需要注意的是，本地模型没有现成的 API 账单，企业仍要自行确定算力成本口径。
LiteLLM 更像入口处的水表。它无法判断一次调用是否真的创造了业务价值，也不会自动修复 Agent 的逻辑死循环。退出条件要写在 Agent 中，预算策略要配置在代理层，人工接管要进入业务流程，三者缺一不可。
比较稳妥的落地顺序是：先让所有模型调用经过统一代理层，再强制写入 team_id、project_id 和 feature_id；随后补上任务预算与终止规则，最后再做模型路由、缓存和成本预测。
审计表至少要回答这些问题
- 每笔调用属于哪个团队、项目和功能？
- 一次任务触发了多少次模型与工具调用？
- 哪类错误最容易引发重复尝试？
- 预算触发后，系统会终止、降级还是转人工？
- 业务量扩大前，能否根据历史任务估算成本？
这些问题有了稳定答案，Agent 成本才会从月底的一笔总账，变成可以追踪、限制和复盘的运营指标。
Agent FinOps 要做的，是让每笔开销有归属、有上限、能解释。自动续费可以靠关闭开关，Agent 账单则要在请求进入模型前就装好水表和刹车。
编辑说明：现有素材中的 72%、60%、22%、11% 和 9% 未能追溯到原始报告，统计口径也不明确，因此未作为行业事实写入正文。自动对账、采购比价、合规初审及 HITL 场景参考腾讯 SkillHub 的 B 端产品经理超级工作台。