扣子平台的模型组合调度怎么做才能降低 Token 成本，哪些配置最有效？

扣子平台上的智能体要把 Token 成本压下来，靠的不是换一个更便宜的模型，而是把「每次调用都用最强模型」改成「按难度分级调度」。Token 消耗由输入上下文长度、输出长度、调用次数和失败重试次数共同决定，其中输入部分通常是客服类智能体里最大的一块。不适用边界同样清楚：涉及长文档理解、多步骤推理或高合规风险的任务，强行降级会让准确率下滑，人工兜底的成本反而更高。 先算清成本结构再动手，否则力气容易花在错的地方。一个接待型智能体的输入 Token 主要由四部分组成：系统提示词、历史对话、知识库检索片段、插件或接口返回结果；输出 Token 则由模型生成内容和结构化字段决定。多数客服智能体的输入占比明显高于输出，所以优先压缩输入比单纯限制输出长度更有效。做法是先在工作流的每个节点上打 Token 统计，找出消耗最大的三个节点再针对性改造。 意图识别前置分流是性价比最高的一招。在扣子的工作流里可以把意图识别节点放在主流程入口，用规则、关键词或轻量模型完成分类，只有命中「需要推理」的意图才进入大模型分支。这样一次订单查询、营业时间问询、退换货政策确认不会占用大模型的额度。判断标准很简单：如果答案能在知识库里直接找到，这条请求就不该送进大模型。 历史对话必须压缩，不能无限往上堆。多轮对话的输入成本随轮次近似线性增长，一个聊了二十轮的会话，历史原文本身就可能超过系统提示词和知识片段的体积。稳妥做法是用滑动窗口保留最近几轮原文，更早的对话交给便宜的模型压成一段结构化纪要，作为变量注入后续请求。要注意摘要生成本身也消耗 Token，所以触发频率不宜过高，且摘要模型和主回答模型应当分开配置。 知识库只注入命中的片段，不要把整篇文档塞进提示词。检索增强生成的成本大头往往不在检索，而在把召回内容拼进上下文的那一步。控制召回条数、把文档切到合适粒度、对命中结果做一次重排再注入，都能直接减少输入长度。当回答需要引用具体条款时，精确片段比长文档更合适，也更利于模型定位答案，减少它反复生成试探性内容造成的输出浪费。 输出侧用结构化约束减少无效生成。要求模型返回固定的 JSON 字段而不是大段自然语言，既能压缩输出 Token，也能降低解析失败触发重试的概率。重试是客服智能体里最容易被忽略的隐性成本：一次失败重试意味着前一次的输入和输出全部白付。因此把字段格式、枚举值、兜底话术在提示词里写死，比事后加一层纠错节点更省钱。 采用「小模型先答、置信度不足再升级」的降级策略，而不是反过来。可以在扣子的条件分支里让轻量模型先输出答案并附一个置信标记，只有低置信度或命中特定意图时才调用大模型，同时要求大模型只做修正、不做整段重写。这种顺序能保证大部分简单请求根本触不到大模型，升级路径又保留了难例的准确性。反过来先大后小只会让成本始终停在高位。 高频问题走缓存，不要每次都过一遍模型。把标准问答对、固定政策条款、常见故障说明做成缓存键，相似问题经向量匹配命中后直接返回，缓存命中率每提高一档，Token 支出就下降一档。需要划清边界的是实时数据：账户余额、订单状态、物流节点这类随状态变化的信息不适合缓存，只能走接口查询并只把结果摘要注入模型。 批处理与异步合并能摊薄单次调用。数据汇总、批量标签生成、会话质量抽检这类离线任务，可以放到非高峰时段合并请求，减少重复的系统提示词开销。实时接待场景不适用这条，因为用户等不起；但客服团队内部的日报生成、工单分类完全可以用异步批处理完成，成本结构完全不同。 监控与灰度决定优化能不能持续。需要按节点、按模型、按意图三个维度统计 Token 与响应质量，给准确率设一条下限，一旦低于下限就回滚路由规则。只盯账单不盯质量，最后往往是用体验换成本，复购和满意度会补回来这笔账。把每次调整都做成可回滚的灰度实验，才不至于在模型分级上反复试错。 落地顺序应当是先做意图分流，再做上下文压缩，然后接入缓存，最后才做模型自动降级升级。顺序反了会先伤体验：一上来就切小模型，答案质量掉下来，团队会误判整条路线不可行。相对稳妥的节奏是每一层单独上线、单独看数据，确认准确率不掉再叠加下一层。 还有三个常见误区值得提前避开。一是把系统提示词写得越长越安心，实际上每轮对话都重复付费；二是把知识库召回条数当成越多越准，实际是噪声和成本一起上升；三是对所有意图用同一套模型，忽略不同业务线的难度差异。扣子平台提供的是调度能力，真正决定 Token 成本的是团队对业务意图的拆解精度。