企业使用大模型的成本结构，正在变得越来越具体。
试用阶段，大模型的花费往往被当作一笔实验预算，很少有人细算。等到AI助手接入知识库、Agent开始参与业务流程，调用量从每天几十次变成成千上万次，账单上的Token消耗就成了管理层绕不开的问题。
不少企业到这个阶段才发现，大模型的成本问题很多时候并不出在单价上，而出在使用方式上：大量本不需要大模型参与的工作，也被交给了大模型。
Token是大模型的计费单位，也是企业AI的新成本项
大模型并不直接处理人类语言。输入的文字会先被切分成一串基本单元，再转换为数字交给模型处理，这个基本单元就是Token，也是大模型服务最常见的计费方式。粗略来看，一个汉字通常对应1至2个Token，一个英文Token约相当于0.75个单词，具体数值因模型的分词方式而异。
Token的计费是双向的，用户输入的内容和模型生成的回答都要计费，而且多数服务商的输出单价高于输入。在多轮对话中，历史上下文会被反复带入，任务链条越长、携带的背景资料越多，消耗增长得越快。
对个人用户而言，这可能只是订阅费里的一个数字；对企业而言，Token消耗会随着业务规模持续增长，最终成为一项长期的运营成本。
企业Token浪费，主要出在两个环节
企业使用大模型时，一个普遍的倾向是把它当作万能处理器：业务数据、操作手册、上百页的PDF都直接交给模型，让它总结、判断，甚至执行操作。这种用法在演示阶段效果明显，进入规模化运行后，浪费会集中体现在两个环节。
第一个环节，是让大模型承担确定性工作。固定格式的数据提取、表格搬运、系统间的数据录入，规则明确、结果唯一，传统脚本或RPA几乎不产生边际成本就能完成，却被交给按Token计费的模型处理。
第二个环节，是重复输入背景信息。为了让模型理解一条特定业务流程，每次调用都要重新发送数万字的背景材料，真正与当次任务相关的信息只占其中很小一部分，大量Token消耗在重复阅读上。
Token成本如果不加控制，大模型很难在业务线上大规模铺开。不少AI项目试点效果不错，却在推广阶段因为成本难以预期而放缓。
省Token的核心，是把“理解”和“执行”拆开
控制Token成本，常见的技术手段有几类。一是上下文精简，通过检索增强生成（RAG）只召回与当前问题相关的片段，而不是把整份文档放进上下文；二是缓存复用，不少模型服务商已提供提示词缓存，重复出现的系统提示和背景材料可以按更低的价格计费；三是模型分级，把简单分类、格式转换等任务交给更小、更便宜的模型，复杂推理再交给大模型。
这些手段都能降低单次调用的成本，但在企业业务流程中，更根本的一步是架构层面的分工：大模型只负责需要理解和判断的环节，确定性的操作交给不消耗Token的执行工具。
具体可以分成两步。一是前置过滤，数据进入模型之前，先由系统完成抓取、清洗和结构化，只保留决策所需的关键字段；二是执行剥离，大模型输出的是决策指令，点击、下载、填表、录入这些动作，交给专门的执行工具完成。
RPA加大模型：一种已在业务中跑通的分工
这种分工在金融行业已经有落地实践。国泰海通证券的“金小智”数字员工，基于金智维RPA与大模型的双引擎架构：RPA负责在业务系统中精确执行操作，大模型只在需要理解非结构化信息、做出判断时介入。资金核查时间由此从1小时缩短到8分钟，效率提升85%。
从Token的角度看，这套架构的成本结构也随之改变。RPA先从系统中抓取数据并完成结构化处理，交给大模型的只是精简后的关键变量，输入端的消耗明显下降；大模型输出的是一条简短的决策指令，后续执行全部由不消耗Token的机器人完成，输出端的消耗也被压到很低。
行业里也有其他厂商在走类似路线。UiPath把Agent能力叠加在既有的自动化平台之上，国内的实在智能、弘玑Cyclone等流程自动化厂商也在推进RPA与大模型的结合。各家的实现方式有差异，但共同的思路都是让执行层承接确定性工作，把大模型的算力留给真正需要理解的环节。
哪些业务适合“大模型+RPA”架构
这套架构的收益，取决于业务本身的结构。
如果一项业务包含大量规则清晰、结构化的重复操作，只在少数节点需要语义理解和判断，例如对账、报送、资金核查、单据审核，那么由RPA分流大部分工作量，Token节省会比较明显。
反过来，如果业务本身低频、非结构化，每次都需要模型进行创造性生成，例如方案撰写、营销内容创作，那么RPA能分流的部分有限，这类Token支出本身就是必要成本。
企业评估时，可以先把一条业务流程拆成若干步骤，逐一判断哪些步骤需要理解、哪些只需要执行。需要理解的步骤占比越低，这套架构的成本优势就越明显。
Token成本，正在成为企业AI架构的评价指标
过去评价企业级Agent，关注点大多在模型能力和任务完成率上。随着调用规模扩大，单位任务的Token消耗开始进入评价体系，与稳定性、安全性一起，影响一个AI项目能否长期运行。
单纯的大模型更接近一个负责理解和生成的中枢，要在企业系统里真正完成工作，还需要执行层的配合。判断一套企业级Agent架构是否合理，一个直接的观察角度是：大模型的算力，有没有被消耗在本该由规则和脚本完成的工作上。
