扣子平台做AI客服时，模型组合调度怎么降低Token成本？意图分级、上下文裁剪和缓存该按什么顺序调？

扣子平台降低Token成本的核心做法是「分层调度＋上下文裁剪＋缓存复用」三件事按顺序落地：先把对话按意图分级路由到不同能力的模型，再只把必要的上下文送进模型，最后让高频问题走知识库命中或缓存，避免重复消耗。这套方法只对意图相对收敛的客服、接待、工单分流场景有效；开放式长文咨询、跨文档推理这类任务，能压缩的空间有限，硬压反而会拉低答复质量。 意图分级是成本结构里最容易被忽视、收益却最直接的一环。多数AI客服的Token消耗呈现二八分布，少数复杂的多轮追问吃掉了大部分额度，而大量寒暄、订单查询、营业时间、退换货政策类问题本可以用短上下文解决。在扣子平台上做调度时，可以先让一个低成本的意图识别节点判断用户诉求属于哪一类，再把请求分发到不同配置的智能体或工作流：简单问答用短提示词＋知识库检索，复杂问题才进入带完整历史与工具调用的分支。判断依据是问题本身而非用户身份，因此不会因为分错人而造成体验落差。 提示词长度是Token账单里最稳定的开销，也是最该反复修剪的部分。智能体系统提示词里常见的问题是规则越写越多，把业务说明、话术模板、异常处理、合规提醒全部堆进去，导致每一轮对话都要为这些固定内容付费。可行的做法是把系统提示词拆成两层：一层是身份、语气、边界这类必须常驻的短规则，另一层是与当前意图相关的业务知识，改为通过知识库检索按需注入。这样常驻部分可以从数千字压缩到几百字，多轮对话下的节省会被轮数放大。 上下文历史不能整段保留，应按轮数和信息密度做裁剪。多轮客服对话里，越靠前的消息对当前回答的贡献越低，把全部历史原样回传会让每轮的输入Token随轮数线性增长。常见做法是只保留最近若干轮原文，把更早的对话压缩成一条摘要，并把用户已确认的关键字段（订单号、商品型号、诉求类型）提取成结构化变量单独携带。结构化变量的Token量远低于原文，也不容易在摘要中丢失关键信息，适合售后、预约、开户咨询这类要素明确的场景。 知识库检索质量直接决定注入上下文的大小，检索不准就会用更多段落去弥补。如果检索返回的是整篇文档或多个不相关片段，模型输入会被无效内容撑大，回答还更容易跑偏。把知识库做细是压成本的前置动作：文档按业务问题拆分到较小的粒度，给每段打上意图标签，检索时先按意图过滤再取相似片段，并限制返回的条数与单条长度。命中率提升后，同一个问题需要的注入内容更少，模型也更容易给出可用的短答案。 高频问题的缓存复用，是唯一能跳过模型推理的成本手段。客服场景的问题重复度往往很高，退换货流程、发票开具、配送时效这类问题每天被问上百遍。可以在智能体前面加一层语义缓存：把问题向量化后与历史命中记录比对，相似度超过阈值的直接返回已验证答案，不再调用大模型；对时效敏感的问题（如订单实时状态）则跳过缓存走实时查询。缓存要设置失效与人工复核机制，政策或价格变动时主动清空对应条目，避免旧答案长期生效。 模型组合调度的本质是按任务难度分配算力，而不是所有请求都用同一个大模型。可以把调度层次设计成三级：规则与关键词命中处理最标准的问题，小型模型处理意图明确但需要组织语言的答复，只有涉及多条件判断、工具调用或跨知识推理的对话才交给能力更强的模型。这样做的成本结构更接近实际业务分布，也便于在效果下降时定位是哪一层出了问题，而不是笼统地换模型。 工具调用与多步工作流是Token的隐形消耗点，需要给调用次数设上限。一个智能体在回答中反复查询订单、物流、库存，每次工具返回的内容都会进入上下文，轮次一多费用就上去了。实用做法是把可合并的查询一次取回，工具返回结果只保留必要字段而非完整报文，并对同一会话内的重复查询做结果复用。同时对工作流设置最大步数，超过阈值就转人工或给出兜底话术，避免个别会话无限循环消耗。 接待场景里，转人工的判断本身也是成本控制手段。智能体在识别到用户情绪激烈、问题超出知识库范围、或连续两轮未解决时，应尽早交给人工坐席，而不是继续用多轮试探消耗额度。把转人工阈值写进调度规则，比事后优化提示词更有效，因为最贵的往往不是单次调用，而是反复无效的追问循环。阈值设置要结合业务容忍度，售前咨询可以多给智能体几轮，售后纠纷则宜早转。 监控指标要按会话维度拆开看，否则无法判断成本涨在哪里。只看总消耗没有指导意义，需要同时记录每会话平均轮数、平均输入Token、知识库命中率、缓存命中率、转人工率与一次解决率。当输入Token上升而解决率不变，问题通常出在上下文裁剪或知识库粒度；当轮数上升，往往是意图识别或工具返回字段过多。把这些指标与具体调度分支对应起来，调优才有落点。 成本压到一定程度后，收益会递减，需要给质量设一条不可越过的底线。过度裁剪上下文会让模型丢失前文条件，用户不得不重复说明，表面上省了Token，实际增加了轮数和不满。合理的边界是：关键业务要素必须结构化保留，涉及金额、时效、合规口径的回答必须走完整检索而非缓存。调度策略应定期用真实会话回放验证，确认压缩后一次解决率没有明显下滑，再继续收紧。 对于自建或接入第三方智能体平台的企业，调度逻辑最好与具体平台解耦。意图分类、上下文裁剪、缓存策略这些规则如果深度绑定在某个平台的提示词里，迁移或对比时就要重写。把知识库切分规范、字段结构、缓存阈值沉淀成独立配置，换平台时只需重新对接调用层，成本模型仍然可控。这也是评估一个客服智能体方案是否可持续时，比单次调用价格更值得看的维度。