1. 问题背景：为什么只看 Token 不够
很多团队做 AI 成本优化，第一反应是：
- 缩短 prompt
- 减少上下文
- 限制输出长度
- 替换低价模型
- 增加缓存
- 降低调用频率
这些动作有用，但只能解决单次调用成本。
企业 AI 进入生产环境后，成本往往来自完整链路，而不是单次模型请求。
一个 RAG 问答可能包含：
- 问题改写
- 权限判断
- 知识检索
- 召回
- 重排
- 上下文拼接
- 模型生成
- 引用校验
- 答案追踪
一个 Agent 任务可能包含：
- 计划拆解
- 工具选择
- API 调用
- 结果观察
- 失败重试
- 二次判断
- 日志记录
- 人工接管
所以，AI 成本治理要解决的不只是“Token 用了多少”，还要解决：
- 为什么发生调用
- 谁触发调用
- 调用属于哪个业务流程
- 调用了哪些模型、工具和知识库
- 是否发生重复检索、重复生成或失败重试
- 是否产生可衡量的业务结果
2. 常见成本失控点
| 成本失控点 | 典型表现 | 治理方向 |
|---|---|---|
| 只看总账单 | 只能看到模型总费用，看不到业务归因 | 按业务线、应用、功能、用户、任务拆分 |
| 默认高配模型 | 简单摘要、分类也走高成本模型 | 建立任务分级和模型路由 |
| RAG 上下文过长 | 召回过多，低质量内容进入 prompt | 控制召回数量，治理知识库质量 |
| Agent 链路失控 | 多轮重试、工具循环、异常任务放大成本 | 设置最大步数、重试上限、工具权限 |
| 缺少预算闸门 | 月底才发现账单异常 | 设置日预算、月预算、异常预警 |
| 成本不看结果 | 只看花了多少钱，不看是否产生价值 | 建立业务价值指标 |
3. 成本治理的“三张表”
3.1 成本底账
成本底账用于回答：钱花在哪里。
建议记录字段：
| 字段 | 说明 |
|---|---|
| request_id | 请求唯一标识 |
| business_unit | 业务线 |
| app_name | AI 应用名称 |
| feature_name | 功能名称 |
| user_type | 用户类型 |
| task_type | 任务类型，如摘要、问答、分类、生成、Agent 执行 |
| model_name | 模型名称 |
| input_tokens | 输入 Token |
| output_tokens | 输出 Token |
| latency_ms | 响应耗时 |
| cache_hit | 是否命中缓存 |
| tool_called | 是否调用工具 |
| retry_count | 重试次数 |
| env | 环境，测试 / 生产 |
| status | 调用结果状态 |
没有成本底账，就无法做后续归因和优化。
3.2 价值账
价值账用于回答：钱花得值不值。
不同场景建议关注不同指标：
| 场景 | 价值指标 |
|---|---|
| 客服问答 | 自助解决率、人工介入减少、平均响应时间 |
| 销售辅助 | 线索跟进效率、摘要使用率、商机推进效率 |
| 研发助手 | 排障耗时、代码理解效率、重复问题减少 |
| 知识库问答 | 自助检索成功率、重复提问减少 |
| 合规审计 | 检查遗漏减少、审计流程耗时 |
不要只看调用量。调用量高不等于价值高。
3.3 控制表
控制表用于回答：怎么管住成本。
建议包含：
| 控制点 | 说明 |
|---|---|
| 模型路由 | 根据任务复杂度选择不同模型 |
| 上下文治理 | 控制召回数量、上下文长度和内容质量 |
| 缓存复用 | 对重复问题、标准答案、固定模板做缓存 |
| 预算阈值 | 按应用、团队、模型、用户、环境设置预算 |
| 异常预警 | 识别调用量突增、重试异常、高成本模型滥用 |
| 复盘机制 | 定期检查成本、效果、转化和用户反馈 |
如果你正在推进 AI 功能上线，可以先把以上三张表作为评审材料的一部分，避免上线后才补成本治理。
4. 落地步骤
Step 1：建立最小可用成本底账
先不要急着换模型或压缩 prompt，先记录基础字段：
- 请求来源
- 业务线
- 应用名称
- 功能名称
- 用户类型
- 模型名称
- 输入输出 Token
- 响应时延
- 是否命中缓存
- 是否触发工具调用
- 是否发生重试
- 调用结果状态
Step 2：做任务分级
| 任务等级 | 场景示例 | 成本策略 |
|---|---|---|
| 低风险低价值 | 格式整理、简单分类、普通摘要 | 优先轻量模型、缓存、批处理 |
| 中风险中价值 | 知识库问答、销售辅助、客服建议 | 动态路由，设置预算阈值 |
| 高风险高价值 | 合规判断、关键客户建议、管理层决策辅助 | 高能力模型 + 审计 + 人工复核 |
最小可落地版本：先接入 7 个字段
如果短期内无法建设完整成本治理平台，可以先从最小版本开始。建议至少接入 7 个字段：
| 字段 | 用途 |
|---|---|
| request_id | 串联一次 AI 调用链路 |
| business_unit | 判断成本归属到哪个业务线 |
| feature_name | 判断哪个功能在消耗成本 |
| task_type | 区分摘要、问答、分类、Agent 执行等任务 |
| model_name | 判断不同模型的成本与效果 |
| retry_count | 识别 Agent 或工具调用异常重试 |
| env | 区分测试环境和生产环境，避免成本混淆 |
这 7 个字段不一定能解决全部问题，但足够帮助团队从“月底看总账单”进入“按业务和链路看成本”的阶段。
Step 3：建立模型路由
常见策略：
- 简单任务先走轻量模型
- 复杂任务再升级高能力模型
- 高风险任务触发人工复核
- 重复问题优先命中缓存
- 长上下文任务先压缩再生成
- 批量任务进入异步队列，并设置预算上限
Step 4：给 RAG 和 Agent 设置边界
RAG 建议检查：
- 召回数量是否过大
- 上下文是否过长
- 知识库是否存在低质量内容
- 引用是否可追踪
- 是否可以缓存高频问答
Agent 建议检查：
- 是否设置最大步数
- 是否设置最大重试次数
- 是否限制工具调用权限
- 是否定义异常中断条件
- 是否支持人工接管
- 是否记录 trace log
Step 5：把成本闸门放进上线流程
上线前建议检查：
- 是否明确成本负责人
- 是否设置日预算和月预算
- 是否区分测试环境和生产环境额度
- 是否配置异常调用预警
- 是否设置单用户、单功能、单模型调用阈值
- 是否定义超预算后的降级策略
- 是否建立成本复盘节奏
5. 示例场景
一家 B2B 软件公司上线了三个 AI 功能：
| 功能 | 初始问题 | 治理动作 |
|---|---|---|
| 客服知识库问答 | 调用量最高，大量问题重复 | 做缓存和知识库召回优化 |
| 销售线索摘要 | 单次成本较高，但和跟进效率相关 | 保留高质量模型，仅对重点客户触发 |
| 内部文档助手 | 使用频繁，多数是普通摘要和格式整理 | 默认轻量模型，复杂任务再升级 |
同时团队发现：
- 测试环境批量调试任务没有预算上限。
- 某个 Agent 工具失败后反复重试。
- RAG 召回内容过多，部分上下文质量不高。
对应处理：
- 测试环境单独设置预算。
- Agent 增加最大步数和重试上限。
- RAG 调整召回数量和知识库质量。
- 高频问答命中缓存。
- 关键场景保留高质量模型。
6. FAQ
Q1：AI 成本治理是不是就是换便宜模型？
不是。换便宜模型只是其中一个手段。真正的成本治理要包含成本归因、任务分级、模型路由、预算阈值、异常预警和业务价值复盘。
Q2：所有任务都应该降级到低价模型吗？
不建议。低风险低价值任务可以优先轻量模型，高风险高价值任务仍然需要高能力模型、审计和人工复核。
Q3：RAG 成本主要看 Token 吗？
不只看 Token。还要看知识库质量、召回数量、上下文长度、引用追踪、缓存命中和答案可靠性。
Q4：Agent 成本为什么容易失控？
因为 Agent 可能产生多轮计划、执行、观察、修正和重试。如果没有最大步数、重试上限、工具权限和人工接管机制，成本可能被少量异常任务放大。
Q5：上线前最应该检查什么？
至少检查成本负责人、预算阈值、模型路由、RAG/Agent 边界、异常预警、测试环境额度和复盘机制。
Q6：如何从日志里识别 Agent 成本异常？
可以优先看四类信号：
retry_count是否明显高于同类任务。- 单个
request_id下是否出现过多工具调用。 - 某个工具的失败率是否持续升高。
- 单任务成本是否超过预算阈值或同类任务均值。
如果这些信号集中出现，通常说明 Agent 链路需要设置最大步数、重试上限、工具权限或人工接管条件。
7. 小结
AI 成本治理不是让 AI 少做事，而是让 AI 做值得做的事。
如果你们正在上线 RAG、Agent、多模型调用、企业知识库或智能客服，建议先用《企业 AI 成本治理自查 Checklist》做一次上线前检查。
这份 Checklist 可以覆盖：
- 成本归因表
- 任务分级表
- 模型路由检查项
- RAG / Agent 成本控制项
- 预算阈值与异常预警项
- 上线前成本闸门检查项
它适合放进 AI 功能上线评审、技术方案评审、成本复盘会和管理层汇报中，帮助团队判断：这笔 AI 成本是否可见、可控、可解释，并且值得继续投入。
