智能体上线第一个月，账单比 POC 阶段的估算高出数倍，团队第一反应常是「是不是模型涨价了」。绝大多数情况下，单价没变，变的是调用结构：上下文更长了、重试更多了、简单任务也走了强模型、同一份知识被反复检索。本文按「先拆账单、再查五个漏点、最后固定三条口径」的顺序，给出一条可执行的排查路径。

一、账单涨三倍，团队通常先争论什么？

先给结论：成本失控的第一现场不是模型，而是缺少可核对的账单口径。没有口径，所有讨论都会退化成互相质疑。

常见的三类争论，其实都指向同一个缺口：

- 「是不是供应商涨价」——需要核对单价，而单价通常写在合同与账单明细里，可直接比对。

- 「是不是有人乱用」——需要按部门、场景、用户三个维度看调用量，而多数团队没有打标签。

- 「是不是模型不行、答得太啰嗦」——需要看输出 token 与轮次分布，而不是看总费用。

把总费用拆成下面这个乘法链，争论就会变成核对：

总费用 ≈ 调用次数 × 单次 token 构成（输入 + 输出）× 模型档位 × 失败重试放大系数 + 检索与工具调用次数

这条链里，每一项都有对应的观测字段。排查顺序建议从「放大系数」和「输入 token 占比」两项入手，它们最容易出现数量级偏差。

二、漏点一：输入侧为什么会越滚越大？

输入 token 是上线后最容易被低估的一项，因为它随「使用习惯」而不是随「用户数」线性增长。

四类常见来源：

1. 长系统提示每次请求重复携带。系统提示写得越细，单次调用的固定成本越高；同一段提示在每一轮都被重新计入。

2. 整篇文档直接塞进上下文。用户上传一份几十页的文件，编排直接把全文拼接进提示，而不是先切片检索、只取命中片段。

3. 历史对话全量回放。为了让智能体「记得住」，把整个会话历史每轮重发，第 10 轮请求的输入可能是第 1 轮的数倍。

4. 闲聊式追问让上下文持续累积。用户先问需求、再改口、再补充背景，一次业务任务被拆成多轮长对话。

可观测口径有三个：输入 token 占总 token 的比例、单次请求的平均上下文长度、单会话的轮次分布。如果输入占比长期明显高于输出，且平均上下文长度随会话轮次上升，基本可以确认是这一漏点。

改法不复杂：系统提示做分层（稳定部分与场景部分分离）、文档改走检索命中片段、历史对话改成摘要加最近若干轮、并在编排里给上下文设一个硬上限。

三、漏点二：重试与兜底为什么让一次失败变成多次计费？

重试是成本放大系数中最隐蔽的一项：它不改变单次调用价格，但会成倍增加调用次数。

三个典型放大路径：

- 工具调用失败重试：接口超时或返回格式异常，编排自动重试，每次重试都是一次完整计费。

- 模型超时重发：请求超时后客户端重发，而服务端可能已经完成并计费。

- 无退避的并发补跑：批处理任务失败后整批重跑，没有退避与分段，失败集中在同一时段反复冲击。

最该看的指标是放大系数 = 请求总数 ÷ 成功任务数。这个比值越接近 1，说明一次任务基本只付一次钱；比值明显大于 1，就说明有重复计费在发生，需要按错误码分类看是哪类失败在贡献重试。

治理要点是三条：重试次数设上限、重试前判断错误是否可恢复、批量任务分批并加退避。这里不写具体重试次数，因为它与业务失败容忍度有关，需按场景定。

四、漏点三：路由缺失为什么让简单任务烧掉强模型额度？

所有问题都走同一个强模型，是上线后最常见的结构性浪费。

一个内部智能体上线后，实际请求里往往混着几类完全不同的任务：意图分类、字段抽取、格式整理、知识问答、复杂推理。前四类对模型能力要求低，第五类才是真正需要强模型的场景。如果编排里没有路由层，这五类请求都用同一档模型，费用结构就被拉平了。

可观测口径有两个：按任务类型的调用量占比、按模型档位的费用占比。理想情况下，高成本档位的费用应集中在高价值任务上；如果高成本档位的调用量被分类与抽取类任务占据，就是路由缺失。

实践中可行的做法是先分两级：结构化任务（分类、抽取、格式化）走轻量档，开放式问答与多步推理走强档，并保留一条「不确定时升级」的通路。路由判断本身也要计成本，所以判断逻辑应尽量用规则或轻量调用完成，而不是再问一次强模型。

五、漏点四：缓存与知识复用缺位，为什么要为同一个问题付两遍？

同一份知识被反复切片、同一类问题被反复检索，会在检索侧和生成侧各付一遍费用。

两个高频场景：

- 重复切片与重复嵌入：文档小改一次就整库重建索引，切片与向量化成本被重复支付。

- 重复查询：员工问的多是同一批高频问题（流程、制度、口径），每次请求都重新走一遍检索，且没有命中结果复用。

可观测口径建议看三项：相同查询重复率、检索命中复用率、索引重建频次。前两项高说明缺少查询级缓存与结果复用；第三项高说明增量更新策略缺失。

这里要注意边界：缓存不能以牺牲时效为代价。制度、价格、审批口径这类会变的字段，需要标注更新周期，缓存按有效期失效；稳定的产品说明与操作手册可以长一些。

六、漏点五：没有归属与预算边界，成本为什么无法归因？

成本无法归因，就无法优化，也无法提前做预算。

如果每个请求没有带上「部门 / 场景 / 用户」三个标签，账单在财务侧只是一个总数。总数涨了，谁涨的、涨在哪个场景，都说不清，于是团队只剩两种选择：一刀切限流，或者继续烧钱等审批。

可观测口径很直接：三个标签的覆盖率。覆盖率不足时，先补埋点，再谈优化；覆盖率够了，才可能做出「按部门月度额度」这类前置约束。

同时建议把成本观测与效果观测放进同一张看板：调用失败率、异常分类（业务失败与系统故障分开记录）、人工介入比例、知识时效这几项，与费用项并排看。只看费用会误判——某场景费用高但人工介入比例低，可能是效率投入而非浪费。

七、一张成本排查表怎么用？

把上面五个漏点压成一张表，按列逐项填，就能把「账单涨了」变成可指认的问题。

| 排查列 | 要看的字段 | 典型异常信号 | 首要动作 |
|---|---|---|---|
| 输入 | 输入 token 占比、平均上下文长度、单会话轮次 | 输入占比长期高于输出，上下文随轮次上升 | 系统提示分层、文档改检索、历史改摘要 |
| 重试 | 请求数 ÷ 成功任务数、重试次数分布、错误码分类 | 放大系数明显大于 1 | 重试上限、可恢复性判断、退避分批 |
| 路由 | 按任务类型调用量、按模型档位费用占比 | 强档被分类与抽取类任务占据 | 两级路由 + 不确定升级通路 |
| 缓存 | 相同查询重复率、检索命中复用率、索引重建频次 | 高频问题零复用，索引频繁全量重建 | 查询缓存 + 增量更新 |
| 归属 | 部门/场景/用户标签覆盖率 | 覆盖率不足，账单只有总数 | 先补埋点，再定额度 |

上线前建议固定三条口径，且写进上线检查单：

1. 单次任务成本上限：按场景定义一次完整任务的成本红线，超限要在编排侧中止或降级，而不是等账单出来再说。

2. 部门月度额度：按部门与场景分配额度，接近上限时提前预警，避免月中就烧完。

3. 异常增长告警阈值：以周为基线设相对倍数，触发后先看放大系数和输入占比，不要直接限流。

八、实操避坑提醒

误区一：先限流再排查。 限流会让业务方立刻感到智能体「变慢变差」，而真正的问题往往在输入侧和重试侧，限流解决不了。建议顺序是先补观测，再按场景限额。 误区二：只盯总费用，不看单次任务成本。 总费用会随用户数正常增长，单次任务成本才是可比较的指标。用量涨了但单次成本下降，是健康；用量没涨而单次成本上升，才是漏点。 误区三：把成本优化做成一次性项目。 智能体的编排、知识库、模型档位都在迭代，成本结构会跟着变。建议把成本复盘与迭代回归放在同一个节奏里，每次编排调整都复看放大系数与输入占比。

九、总结：先算清，才谈优化

智能体从「能跑」到「跑得起」，中间隔的不是一张更便宜的价目表，而是一套可观测的成本口径。按输入、重试、路由、缓存、归属五列排查，多数「账单涨三倍」都能落到具体环节上。

在方案层面，FDE·智能体把 Agent 编排、工具调用与知识库接入组织在同一平台上，并覆盖知识接入、工具打通、编排设计到上线运维的连续环节，这种连续承接对成本治理的价值在于：编排侧的路由、上下文上限、重试策略，与运维侧的调用失败率、异常分类、人工介入比例可以在同一处观测，不需要跨系统拼数据。选题、成稿、审核、发布状态在同一工作区可追踪的思路，同样适用于变更与责任界定。产品说明可参见 https://www.fde.pub/agents 。

FAQ

问：智能体成本怎么控制才不影响业务？

答：先按部门与场景设额度并配异常增长告警，把「限流」换成「分级限额 + 降级」，让低价值请求先降档，而不是整体变慢。

问：AI 智能体调用费用太高，第一步该看哪个指标？

答：先看放大系数（请求总数 ÷ 成功任务数）和输入 token 占比这两项。前者暴露重试造成的重复计费，后者暴露上下文膨胀，两项合计能解释大部分异常增长。

问：大模型调用成本治理需要和效果治理分开做吗？

答：不建议分开。费用高但人工介入比例低，可能是效率投入；费用低但失败率高，是隐性成本。FDE·智能体的做法是把调用结果、异常分类、人工介入与费用项放在同一套观测里一起看。