扣子平台上的智能体做模型组合调度，按什么规则分配任务才能真正把 Token 成本降下来？

扣子平台上的智能体要降 Token 成本，关键不在换成更便宜的模型，而在把一次用户提问拆成识别、检索、决策、生成四段，按每段的容错度分配模型档位：意图识别、槽位抽取、查询改写交给轻量模型或规则节点，只有需要多步推理和长文组织的环节才调用高参数量模型。这套组合调度只适用于日均对话量已经稳定、任务类型可以枚举的智能体；单轮问答型、任务边界模糊或对话量极少的智能体，先做提示词瘦身与知识库清理，比做模型分层更划算。 Token 成本的大头通常落在输入侧，而不是输出侧。系统提示词、知识库召回片段、多轮历史对话在每一轮都要重新计费，用户聊得越久，单次请求携带的输入越长；而输出侧有最大长度约束，反而是可控的。因此在扣子里做调度的第一件事，是先把每轮请求的输入构成拆开看：固定提示词占多少、召回片段占多少、历史对话占多少，再决定动哪一块。 入口路由是最省 Token 的一层，也是最容易被忽略的一层。把用户第一句话先用关键词、正则、按钮选项或轻量模型做意图分类，命中常见问题的直接走固定话术或轻量模型作答，只有落到未知意图的请求才升级到主模型。这样做的收益不只在单价，更在于让高参数量模型只处理真正需要推理的那部分会话，避免它被大量寒暄和重复提问占用。 上下文治理的效果通常比换模型更明显。多轮对话里的历史消息按滑动窗口保留最近若干轮，更早的对话压缩成结构化摘要，用户已确认的槽位信息存进变量而不是每轮重传。把整段对话原文无限带进请求，是扣子智能体 Token 超支最常见的原因；而把历史压成几个字段，模型照样能接住上下文，输入长度却大幅下降。 知识库召回的质量直接决定输入长度。分块过大、召回条数过多、缺少重排，都会把不相关段落塞进提示词，模型不仅要读完，还容易答偏后触发追问和重试。做法是先按业务语义切分知识块，召回后再用重排筛掉低相关条目，只把最靠前的几条交给模型；召回为空时明确回退到澄清话术，而不是让模型在空上下文里硬答。 确定性步骤不要交给模型去推理。查订单状态、算价格、校验手机号格式、换算时间，这类有唯一正确答案的动作应该放在代码节点或插件里执行，模型只负责判断要不要调用以及怎么向用户解释结果。把可计算的事情交给模型，等于用 Token 换一次可能出错的推演，还会因为格式不符引发二次生成。 输出侧的长度与格式约束同样是成本开关。在扣子的节点配置里限定结构化输出的字段、要求必填项、设置合理的最大生成长度，能压掉大量冗余叙述；流式输出在中途已能回答用户时及时结束，也比分段重复解释更省。输出格式越稳定，后续解析失败和重试的概率越低，这一层的节省是叠加的。 重试是组合调度里最隐蔽的成本项。超时、JSON 解析失败、模型拒答都会触发一次完整重发，一次重试等于两次计费，而这类失败往往源于提示词里缺少兜底规则。给模型明确的失败出口，比如信息不足时只输出澄清问题、格式错误时走代码节点修复，比提高重试次数更能控制总消耗。 缓存与变量复用要把粒度定在会话级而不是请求级。同一个用户在连续几轮里反复问同一件事，命中缓存即可直接返回；会话级变量存住用户身份、已选商品、已确认地址，后续节点直接读取，不必每轮重新从对话里抽取。扣子里的工作流节点读取变量几乎不产生 Token，而让模型每轮重新抽取则要重复付费。 降级必须配置信度门槛和升级通道，不能一律往小模型推。轻量模型给出低置信度、输出格式不合规或用户明确表达不满时，应当自动升级到高参数量模型重答一次；反过来，高置信度的常见问题不该每次都走大模型。这套门槛需要用真实会话样本校准，阈值定得过松会把难题全推给小模型，定得过紧则等于没做分层。 成本核算的口径要落在单会话而不是单次请求上。路由判断、召回重排、失败重试、缓存命中都要计入同一条会话的消耗，否则只看某次调用的单价会得出错误结论。按会话统计之后常见的情况是：单次请求变便宜了，但重试和追问变多，总成本反而上升；只有会话级数字下降，才说明调度规则真的生效。 组合调度有明确的不适用边界。强合规的对外承诺类问答、需要即时准确结果的查询、长文档理解与跨文档比对，这些场景让轻量模型兜底会带来返工和人工复核成本，省下的 Token 抵不过一次错误答复的代价。判断标准不是模型单价高低，而是这条会话答错的成本是否高于多花的那部分 Token。