财务总监周一早上把 IT 负责人叫进办公室，桌上摊着上个月的悟空账单：「比上上个月多了三倍，谁授权的？」IT 负责人翻了半天后台日志，发现是市场部上周把过去三年的产品手册、客户案例、内部 wiki 全部喂进了一个知识库，然后给销售开了一个「随便问」的入口。销售们用得不亦乐乎，每天人均几十轮对话，每轮都把那个超大知识库召回的几千字段落塞进上下文——Token 就是这么烧起来的。
这不是个案。开通悟空容易，把 Token 预算管住难。这篇文章不讲悟空的功能清单（官方文档已经写得很全），只回答一个问题：作为给老板报预算的人，怎么把悟空的钱花在明面上、花得有逻辑、不会下个月被反向问责。下面从计费口径讲到月度估算公式，再到 6 个真正能省 Token 的工程动作，最后给一份成本失控的自检清单。
一、悟空的四个计费口径：算力、Token、调用、席位
很多人第一次看悟空的计费说明会蒙，因为它同时出现了「算力 OPT」「Token 消耗」「调用次数」「席位数」四个词，像是在用不同的尺子量同一桶水。理一下关系就清楚了。
Token 是最底层的计量单位，对应大语言模型实际处理的输入 + 输出字数（中文一个汉字大致 1-2 个 Token）。调用次数是上层动作的计数器，一次问答、一次工具触发、一次知识库检索都算一次调用。算力 OPT 是悟空把不同模型、不同调用类型折算后的统一结算单位，可以理解为「悟空版本的 Token 等价物」，方便企业按月份算总账。席位则是按使用人头收的基础费，类似传统 SaaS 的 seat 模式，决定谁有资格用、不直接决定用多少。
| 计费口径 | 计量对象 | 受什么影响最大 | 谁该盯这个数 |
|---|---|---|---|
| 算力 OPT | 综合折算后的总消耗 | 月度总账 | 财务、IT 总负责人 |
| Token | 模型实际处理的输入输出 | 上下文长度、知识库召回量 | 工程团队、Prompt 维护人 |
| 调用次数 | 每次问答/工具/检索 | 用户活跃度、自动化任务数 | 业务部门管理员 |
| 席位 | 有权使用的人头 | 开通范围 | HR、行政、IT 采购 |
四个口径的钱不是相加关系，而是相互嵌套：席位决定了「最多多少人能用」，调用次数决定了「他们用得多频繁」，Token 决定了「每次用得多重」，OPT 是最后的结算总账。预算失控通常不是席位买多了，而是某个场景的单次 Token 量超出预期，再乘以高频调用，瞬间放大。
理解这层嵌套关系，再去看官方计费说明就顺了。具体的单价会随产品迭代调整，不在这里写死，建议每季度让 IT 拉一次官方最新报价表，做一遍滚动校准。这种「机制讲清楚、数字按时点查」的思路，和我们在 企业 AI 成本失控的真实路径 那篇里梳理的成本管理框架是一致的。
二、哪些场景会把 Token 烧爆
预算爆炸的根源，几乎都来自三类场景的叠加。
第一类是知识库问答的 RAG 段落量。 RAG 的核心动作是从知识库里召回相关段落、塞进模型上下文。问题在于，召回多少段落、每段多长，往往一开始没人定。默认配置下，召回 5-10 段、每段 500-1000 字是常见配置，意味着每次问答光是上下文输入就 5000-10000 Token。如果知识库切片做得粗，召回的段落里夹了大量无关内容，Token 还会进一步膨胀。
第二类是多轮对话的上下文累积。 多轮对话默认会把历史记录拼进上下文，让模型「记得」前面聊过什么。一轮对话 1000 Token，到第十轮上下文就累计到 10000+ Token，每轮都重新跑一遍这十轮的历史。用户聊得越深，单次成本越高。这就是为什么「随便问」的入口最烧钱——销售不会在用了五轮之后主动开新会话，他们会一直追问下去。
第三类是 Agent 工具调用的递归深度。 当悟空被搭成 Agent，能调外部 API、查数据库、跨系统取数，每一步调用都会把上一步的结果作为输入继续往下走。如果工具调用链路设计得长（比如「先查 CRM、再查 ERP、再核对库存、再生成回复」），单次任务可能触发 5-10 次模型调用，每次调用都带着越来越长的上下文。一个看起来简单的「帮我看看这个客户的情况」，背后可能跑掉几万 Token。
这三类场景不是问题本身——它们恰好是悟空最有价值的用法。问题在于一开始没人估算量级、没人设限。下面这张表是开沿在 AI Agent 项目里反复看到的 Token 消耗结构，供做横向对比。
| 场景类型 | 单次平均 Token 量级 | 主要消耗在哪 | 容易踩的坑 |
|---|---|---|---|
| 单轮智能搜索 | 1000-3000 | 知识库召回 | 切片过粗 |
| 多轮咨询对话 | 3000-15000/轮 | 历史上下文累积 | 不限制轮次 |
| 文档总结生成 | 5000-30000 | 长文档输入 | 整篇硬塞 |
| 简单 Agent 任务 | 5000-20000 | 多步骤工具调用 | 递归调用 |
| 复杂 Agent 任务 | 20000-80000+ | 多工具+长上下文 | 链路过长 |
这五行不是说「悟空就这么贵」，而是说「不同场景的成本敏感度差几十倍」。预算管理的第一步，是先知道自己主要在哪一行。
二、月度预算怎么估：用户活跃度 × 场景复杂度 × 知识库规模
报预算最怕的是拍脑袋。给一个可以落到表格里的初步公式：
月度 Token 量级 ≈ 月活用户数 × 人均日均调用次数 × 单次平均 Token 量 × 月工作日数
每一个变量都按下面的思路去取值。
月活用户数（MAU）： 不是席位数，是真正会用的人数。一般在采购前可以按 30%-60% 估算；运行三个月后用真实数据校准。
人均日均调用次数： 区分三档。轻度（查个知识、问个流程）2-5 次/天；中度（写个材料、做个汇总）5-15 次/天；重度（销售/客服全程用）15-50 次/天。
单次平均 Token 量： 用上一节那张表对照自己最主流的场景，取一个中位数。
月工作日数： 20-22 天。
举个例子：100 人公司，月活 40 人（40%），人均中度使用 10 次/天，单次平均 5000 Token，22 个工作日，月 Token 量级约 4400 万 Token。配合悟空的 OPT 折算单价做一次乘法，就得到预算下限。
这个数字只是「裸算」，还要加上三个修正系数：
- 知识库规模系数：知识库总字数每翻一倍，RAG 召回的平均长度会上升 20%-40%，Token 量跟着上浮。
- 自动化任务系数：如果接入了定时任务、审批流自动总结、邮件自动回复等无人值守场景，单独按调用频率加一行预算，不混在人均里。
- 季节性峰值系数：促销季、年终结算、月初汇报这类高峰，留 30%-50% 缓冲。
这套估算逻辑，和 企业 AI Agent 项目落地路线图 里讲的「先小场景试点、用真实数据校准、再扩到全量」是同一套方法论：先做一个不太离谱的初估，再用前两个月的真实账单回校，比一开始就追求精确更靠谱。
三、省 Token 的 6 个工程动作
聊到「怎么省」，多数人想的是换便宜模型。这其实是末位优化，前面还有六件事更有效。
1. 知识库切片要细、要带语义边界。 不要按固定字符数硬切。把每个切片控制在 200-500 字，按段落、按章节自然边界切，召回的时候才能既相关又不冗长。粗切片是 Token 浪费的头号原因。
2. 用便宜模型做粗筛、好模型做精答。 先用轻量模型从知识库里筛出最相关的 2-3 段，再交给强模型生成回答。这种「两级流水线」对 RAG 场景能省 30%-60% 的总 Token，体验几乎不掉。
3. 严格控制上下文长度。 多轮对话设上限，超过 10 轮自动摘要前文、丢弃细节；单次输入设上限，超长文档强制分段处理。这条最容易做，也最容易被忽略。
4. 规则化场景做成模板，不要走 Prompt。 比如「生成客户拜访纪要」「整理周报」这种结构固定的任务，模板填空 + 小段 LLM 润色，比让模型从零写要省一个数量级。把 LLM 当万能锤子，是 Token 账单失控的常见原因。
5. 高频问答缓存起来。 同一个问题，第二个人问的时候应该走缓存，不要重新走模型。哪怕只缓存最 Top 100 个高频问题，也能省下相当一块。
6. 按部门、按场景设 Token 额度。 这是「治标也治本」的动作。给市场部、销售部、客服部分别设月度上限，超额预警、超额停服或限速。没有额度的池子，永远是先发先得、用完再说，无法管理。
这六个动作不需要等到出问题才做。新开通悟空的第一个月，就该把这六件事列成清单，逐项落实。它们的效果会在第二、第三个月的账单上明显体现。这套「先把工程动作做到位、再谈模型替换」的思路，在 AI Coding 让企业定制开发的成本结构变了 那篇里也聊过——很多看起来「贵」的 AI 应用，其实是工程粗糙拖出来的，而不是模型本身的问题。
四、AI 成本失控的早期信号
预算定好了，不代表就稳了。下面这些信号一旦出现，必须停下来调，而不是等月底账单出来再反应。
| 信号 | 触发条件 | 应该做什么 |
|---|---|---|
| 日 Token 量突破均值 1.5 倍 | 连续 3 天 | 拉调用日志找异常用户/场景 |
| 单用户日调用 > 200 次 | 出现 | 排查是不是自动化任务在跑 |
| 平均上下文长度上涨 30%+ | 跨周 | 检查知识库切片和召回参数 |
| 新接入知识库后单次 Token 翻倍 | 接入后 1 周 | 调切片粒度、压缩段落数 |
| Agent 任务失败率上升 | 跨周 | 检查工具调用链路是否过长 |
| 缓存命中率 < 10% | 持续 | 重做高频问题归类 |
这套信号体系不需要复杂的监控系统，悟空后台的统计报表加一张自己维护的 Excel 就能跑。关键是要有人定期看，而不是只在出账单的时候才打开。
更深层的失控逻辑，企业 AI 成本失控的真实路径 那篇文章里拆得更细，建议同步看一遍。短期的预算管理是看后台数字，长期的成本治理还要看组织怎么用、用的人有没有动力省。
五、Token 预算自检清单
如果你正在做悟空的月度预算审批，按下面这份清单过一遍。每条都能答上来，预算大概率不会跑偏。
- 我们的悟空席位数、月活用户数、人均调用次数各是多少？（前三个数据决定大盘）
- 我们的主要使用场景属于上面五类中的哪一类？（决定单次成本量级）
- 我们接入了多少个知识库？最大那个有多少字？切片粒度是多少？（决定 RAG 成本）
- 多轮对话有没有设最大轮数？长文档输入有没有强制分段？（决定上下文成本）
- 有没有部门级或场景级的 Token 额度？谁负责审批超额？（决定治理边界）
- 高频问答有没有做缓存？命中率多少？（决定可优化空间）
- 后台日 Token 量的预警阈值是多少？谁会收到告警？（决定响应速度）
- 接入新知识库或新 Agent 场景，有没有上线前的成本预估流程？（决定增量风险）
- 我们的悟空账单是按部门分摊、还是 IT 总盘子吃下？（决定使用者有没有省的动力）
- 每月的 AI 成本汇报，是不是把「替代了多少人力工时」一起摆出来？（决定 ROI 怎么说清楚）
这十条不是 KPI，是判断「这件事到底有没有人在管」的尺子。一家公司能答上 7 条以上，预算基本可控；答不上 3 条以上，再多预算也不够烧。我们在帮一些规模在 80 人到 3000+ 门店量级的客户做 AI Agent 治理时，第一步都是这份清单——不是先做新功能，而是先看老账。
六、把 ROI 算成「每元 Token 替代多少人力工时」
最后一个绕不开的问题：怎么向老板证明这笔钱值得花。
「值得」的口径不能只是「员工觉得好用」。建议统一一个可解释的算法：每元 Token 支出 ÷ 节省的人力工时单价 = 替代率。
举个例子。一个客服坐席每天用悟空写回复、查知识，假设每天节省 1 小时，按 100 元/小时人力单价算，节省价值 100 元；当天他消耗的 Token 折算成本是 20 元，那么这一天的「每元 Token 替代人力」= 100/20 = 5 元。这个比例稳定大于 1，说明 AI 是赚的；如果连续多月低于 1，要么是用法不对、要么是场景不合适，需要复盘。
这套口径的好处是把 AI 投入说成生意话，而不是技术话。财务能看懂、HR 能复用、老板能拍板。具体每个岗位的「节省工时」怎么估，可以参考 AI 数字员工到底能做哪些事 那篇里按岗位拆解的清单。
这一套不需要复杂的 BI 工具，每月做一次抽样测算就够。重要的是这个口径要在公司内部统一，避免不同部门用不同算法各说各话，最后变成「市场说 AI 真香、财务说账单吓人」的对立局面。
七、写在最后
悟空贵不贵，不取决于官方价目表，取决于用的人有没有边界感、做的人有没有把工程动作做到位、管的人有没有把账算到部门头上。同样一套悟空，在某 80 人鞋服批发企业可能一个月几千块就够用，在某千人级集团也可能因为一个失控的「全员随便问」入口一个月烧掉几十万。差的不是产品本身，是治理。
预算这件事的本质是「先讲清逻辑、再填数字」。把 OPT、Token、调用、席位四个口径拆清楚，把场景与单次成本的对应关系画出来，把月活、调用频率、上下文长度三个变量盯住，把六个工程动作落实下去——做完这些再去报预算，老板问什么你都能答上来。AI 在企业里的样子，从来都不是「上不上」的判断题，而是「怎么用、怎么管、怎么算」的连续答题。这道题答得越早，下个月的账单越平稳。
