大模型客服预算为什么不能只看软件费？Token、流程编排和运营维护如何一起估算？

企业采购传统客服系统时，预算通常比较容易理解：多少坐席、开通哪些模块、采用SaaS还是私有化部署，再加上实施和接口费用，基本可以形成一张相对稳定的报价单。

大模型客服改变了这种估算方式。

除了软件许可或平台订阅，企业还要承担模型调用、知识检索、流程编排、系统集成、测试验证和持续运营等成本。部分费用与咨询量直接相关，部分取决于业务复杂度，还有一些会在系统上线后持续发生。

因此，两家月咨询量相近的企业，最终预算可能相差很大；同一家企业使用同一款软件，随着客服Agent从知识问答进入查询、预约和工单处理，成本结构也会发生变化。

评估大模型客服预算时，首先需要把“买一套软件”改成“运行一套持续处理业务的AI服务”。

一、软件费为什么不能代表大模型客服的总预算？

传统软件的成本通常以账号数、坐席数、功能模块或部署规模为基础。企业购买之后，只要业务量没有发生明显变化，年度支出相对稳定。

大模型客服则同时包含固定成本和可变成本。

固定成本包括平台订阅、软件许可、基础实施和部署资源；可变成本可能包括Token、语音识别与合成、消息调用、知识检索以及第三方服务；项目建设成本则来自流程梳理、接口开发、测试和上线；系统运行后，还需要持续维护知识、分析异常对话并调整Agent。

不同厂商的计费单位也并不统一。模型服务通常区分输入Token、输出Token和缓存Token，部分产品还会根据上下文长度、模型类型或思考模式采用不同单价。联络中心AI服务则可能按照消息数、会话数或语音分钟数收费。Google Cloud的Agent Assist就分别采用按聊天消息和语音时长计费的方式。

因此，大模型客服的年度预算至少要包含五部分：

年度总预算＝软件与平台费用＋模型及第三方调用费用＋实施与集成费用＋运营维护费用＋基础设施及安全投入

对于采用公有云SaaS的企业，基础设施成本可能已经包含在服务费中；采用混合云或私有化部署时，则还需要估算服务器、模型部署、高可用、监控、安全和运维资源。

二、Token成本不能按“问题数量”简单计算

Token可以理解为模型处理文本时使用的计量单位，但一次客户提问消耗的Token，远不止客户输入的那句话。

一个完整的模型请求可能包含：

• Agent的角色定义和回复规则；

• 当前客户的问题；

• 历史对话上下文；

• 从知识库检索出的参考资料；

• 可调用工具的说明和参数；

• CRM、订单或工单系统返回的数据；

• 模型生成的回复或结构化指令；

• 异常重试、二次判断和结果校验。

例如，客户只问了一句“我的订单什么时候到”，系统实际可能需要完成意图识别、订单号确认、身份验证、订单系统调用、物流状态解释和异常判断。对于客户而言，这是一个问题；对于后台模型而言，可能产生多次调用。

因此，Token预算更适合采用下面的方式估算：

月度模型成本＝各类场景会话量 × 单次会话平均模型调用次数 × 单次调用平均Token成本

单次调用的成本还需要继续拆分：

单次调用成本＝未缓存输入Token × 输入单价＋缓存输入Token × 缓存单价＋输出Token × 输出单价

部分模型平台会对缓存命中的输入内容采用较低价格，目的是避免重复处理相同的系统提示、工具说明和固定知识。OpenAI、Anthropic和阿里云的官方计费说明均将普通输入、缓存输入或缓存读写、模型输出分别核算。

这意味着，企业不能只问“每百万Token多少钱”，还需要了解Token是如何产生的。

1. 会话轮次

客户咨询平均是两轮还是十轮，会直接影响历史上下文和模型调用次数。

2. 检索内容长度

每次把整份产品手册交给模型，和只检索三段相关知识，Token消耗会有明显差异。知识切片、召回数量和上下文压缩策略都会影响成本。

3. Agent调用链路

简单问答可能只调用一次模型；需要查询订单、判断条件、创建工单并生成回复的流程，可能包含多次模型判断和工具调用。

4. 模型选择

高性能模型、轻量模型和本地模型的单位成本不同。所有问题都使用能力最强的模型，未必是最合理的方案。常见做法是按照场景难度进行模型路由：简单分类和信息提取使用轻量模型，复杂判断再调用能力更强的模型。

5. 缓存与重试

缓存命中可以降低重复上下文的推理成本，但动态内容较多、提示词频繁变化或会话间隔较长时，实际命中率可能下降。接口超时、模型输出不符合格式、工具执行失败，也可能触发重试。

因此，Token预算最好来自真实场景测试，而不是按照文字数量进行静态换算。

企业可以先选择售前问答、订单查询、售后建单等典型场景，采集一段时间的实际调用数据，再分别统计平均值和高位值。使用平均值预测日常支出，使用P90或高峰数据评估预算上限，会比单一平均数更接近真实运行情况。

三、流程编排为什么可能比Token更贵？

Token属于可量化的运行成本，而流程编排属于把业务变成可执行Agent的建设成本。

一个大模型客服回答产品价格时，通常只需要检索知识并组织答案。但如果企业要求它完成退换货申请，系统还要明确：

• 哪些订单符合退换货条件；

• 不同商品适用什么规则；

• 需要采集哪些客户信息；

• 是否需要上传图片或视频；

• 应该调用哪个订单或工单接口；

• 库存、物流和退款状态如何判断；

• 哪些情况必须转人工；

• 接口失败后怎样告知客户；

• 敏感操作是否需要二次确认。

这些规则原本分散在制度文件、客服经验和业务系统中。要让Agent稳定执行，需要经过业务调研、流程拆解、字段设计、工具配置、接口联调、异常路径设计和测试验证。

预算不能只按“有多少个客服场景”计算，还要看每个场景的深度。

可以把大模型客服场景分为四个层级：

暂时无法在飞书文档外展示此内容

场景越接近业务执行，流程编排和系统集成占比通常越高。

即使两个项目都叫“售后客服Agent”，成本也可能完全不同。一个项目只回答保修政策，另一个项目需要识别设备型号、查询购买记录、判断保修状态、采集故障信息并自动派单。两者的咨询量可以相同，但实施工作量并不在同一水平。

因此，流程预算更适合按照以下因素估算：

流程建设成本＝业务场景数量 × 单场景复杂度＋系统接口数量＋异常路径数量＋测试与验收工作量

这里的“场景数量”不应以一句需求描述为单位，而应落实到一条条可以验收的业务流程。

四、为什么上线之后仍然需要运营维护？

传统规则机器人上线后，主要维护关键词、问答库和固定流程。大模型客服具备更强的泛化能力，但并不意味着上线后可以长期无人管理。

客服业务本身就在持续变化：

• 产品、价格和活动会更新；

• 售后政策和服务范围会调整；

• 新问题会不断出现；

• 业务系统接口可能升级；

• 模型版本和输出特征会变化；

• 客户会用新的表达方式提出问题；

• 企业对权限、合规和服务口径的要求也会变化。

因此，大模型客服需要一套持续运营机制。

1. 知识运营

定期更新产品资料、制度文件、服务政策和FAQ，处理失效知识、冲突知识和知识缺口。

2. Badcase复盘

分析答非所问、错误拒答、流程中断、工具调用失败、异常转人工等对话，判断问题来自知识、模型、提示词、流程还是接口。

3. 流程优化

根据实际咨询情况调整追问顺序、判断条件、字段校验、人工接管和异常提示，减少客户重复表达和无效对话。

4. 效果评估

除了统计咨询量和Token，还要持续观察任务完成率、一次解决率、转人工率、错误执行率、客户满意度和单次有效解决成本。

5. 风险治理

涉及退款、账户、个人信息、投诉和敏感业务时，需要定期检查权限、日志、操作记录和人工复核机制。

NIST的生成式AI风险管理框架将测试、评估、验证和确认视为贯穿AI生命周期的持续活动，并建议组织定期评估风险管理流程、指标和实际效果。这也说明，AI系统的运营治理不能被视为一次性交付工作。

运营预算可以根据项目规模采用专职人员、企业与服务商联合运营或购买运营服务等方式，但不宜在初期报价中完全忽略。

五、怎样把三类成本放进同一套预算模型？

企业可以通过“场景—用量—建设—运营”四层模型进行估算。

第一步：确定业务范围

先明确AI客服准备处理哪些渠道、用户和业务，而不是直接从产品功能开始报价。

需要确认的基础数据包括：

• 每月咨询量和高峰咨询量；

• 电话、网页、APP、企微等渠道占比；

• 平均会话轮次和平均通话时长；

• 当前人工处理量和主要问题类型；

• 计划由AI独立处理、辅助人工或直接转人工的场景。

第二步：建立场景清单

将需求拆成可以独立测试和验收的业务场景，例如：

• 产品咨询；

• 活动规则解释；

• 订单状态查询；

• 安装预约；

• 售后报修；

• 工单进度查询；

• 投诉识别与转人工。

每个场景标记知识数量、流程节点、业务字段、接口、异常路径和风险级别。

第三步：进行小规模实测

用真实问题和脱敏业务数据运行典型对话，记录：

• 每次会话的输入、缓存和输出Token；

• 每个场景的模型调用次数；

• 知识检索和工具调用次数；

• 重试率和接口失败率；

• 平均响应时间；

• AI独立完成和转人工的比例。

这些数据可以形成不同场景的“单次服务成本”。

第四步：计算年度总拥有成本

企业可以按以下结构编制预算：

暂时无法在飞书文档外展示此内容

年度预算不宜只做一个确定数字，可以同时建立基础、常态和高峰三种情景。

基础情景用于验证最小可行场景；常态情景根据预计业务量计算；高峰情景则考虑促销、节假日、故障事件以及咨询量增长。这样可以避免试点阶段费用较低，上线扩大后预算突然失控。

六、预算评估中常见的四个误区

误区一：选择单价最低的模型，成本就一定最低

低单价模型如果需要更多重试、补充提示或人工接管，单次有效解决成本可能反而更高。

真正需要比较的是：

单次有效解决成本＝模型与系统运行成本÷成功完成的业务量

误区二：Token越少，系统就越经济

过度压缩上下文可能导致知识不足、回答错误或工具参数缺失。降低Token需要与任务完成率一起评估，不能只追求调用量下降。

误区三：流程上线后不再变化

客服政策、商品、组织和系统都在变化。流程编排属于需要版本管理的业务资产，而不是一次完成后永久固定的配置。

误区四：试点费用可以直接代表规模化费用

试点往往只选择少量场景、有限渠道和较低咨询量。进入生产环境后，还会增加并发、高可用、安全、监控、运营和异常处理要求。

七、从产品报价转向场景成本核算

大模型客服的预算透明度，取决于企业能否看清Agent背后的组成部分。

在亿捷云智能客服的客服Agent建设体系中，一项服务通常可以拆为角色、知识、流程、工具、人工协同和运营六个维度。其自研Synerow平台则通过Agent、Flow和Tools，承载角色定义、业务流程编排以及CRM、订单、工单等系统调用，并提供运行监控、日志分析和Badcase管理。

这种拆分方式对于预算估算的价值在于：企业可以明确哪些费用来自软件能力，哪些来自场景实施，哪些来自业务系统，哪些会随着使用量和运营周期持续发生。

例如，同样建设一个在线客服Agent：

• 只回答商品和政策问题，预算重点是知识整理、检索和Token；

• 增加订单查询后，需要计算接口和权限配置；

• 增加退换货申请后，需要建设流程、字段校验和异常分支；

• 增加投诉处理后，还要考虑风险识别、人工接管和持续质检。

亿捷云智能客服支持公有云SaaS、混合云和私有化等部署方式，不同方式对应的软件、资源和运维成本也不同。企业应根据咨询规模、系统基础、数据要求和内部运维能力选择，而不是单独比较某一个软件报价。

结语

大模型客服预算不能只看软件费，也不能只看Token单价。

Token决定运行过程中模型调用的可变成本，流程编排决定Agent能够进入多少业务环节，运营维护则决定系统上线后能否持续保持知识准确、流程稳定和风险可控。

更合理的预算方法，是先拆业务场景，再测算模型调用；先明确流程和接口，再估算实施工作量；最后把知识运营、Badcase复盘、效果评估和风险治理纳入年度成本。

当企业用年度总拥有成本和单次有效解决成本评估大模型客服时，软件价格才会回到它应有的位置：它是预算的一部分，而不是项目总成本。

如需智能客服、AI客服机器人产品，请联系【亿捷云智能客服】，联系电话： 4006-345-690