企业部署智能体如何控制 Token 成本？从一个客服成本路由 Demo 讲清缓存、压缩与模型分级

企业开始部署智能体后，最先遇到的问题往往不是模型能不能回答，而是账单越来越难解释：

• 为什么同一个问题重复调用多次？
• 为什么输入 Token 比输出 Token 高很多？
• 为什么简单 FAQ 也调用了高能力模型？
• 为什么上下文越积越长？
• 为什么接口超时后，系统不断重试？
• 为什么缓存命中率很低？

如果没有成本治理，智能体项目很容易从“提升效率”变成“增加调用支出”。

本次在 Haoee 上搭建了一个最小演示智能体：

连锁零售客服请求成本路由助手。

它不直接调用模型，也不读取真实计费数据，而是先对一条客服请求进行成本与风险预检，输出：

• 是否适合缓存；
• 是否需要压缩上下文；
• 应选择轻量、标准还是高能力模型；
• 输入和输出 Token 预算；
• 超时、重试和并发建议；
• 是否需要人工确认。

一、先建立成本治理链路

生产环境不建议让前端直接调用大模型，而应增加一层模型网关或智能体网关：

客服系统 | 业务后端 | 请求分类与成本路由 | 缓存层 | 模型网关 | 轻量模型 / 标准模型 / 高能力模型

它适合用于智能体搭建、发布、模板复用和持续运营，但它不是企业计费系统，也不是模型网关本身。

实际项目中，调用量统计、Token 计量、模型价格、预算告警和限流，应由客户后端、API Gateway 或统一模型网关负责。

二、实际搭建的 Demo

本次案例面向连锁零售客服场景。

客服系统中常见三类请求：

低风险 FAQ

例如：

商品退换货规则是什么？

这类问题通常内容稳定、无个人信息、没有实时业务操作，适合进入缓存和轻量模型路由。

含个人信息的查询

例如：

查询某会员当前积分。

这类问题可能包含姓名、手机号、会员号等信息，不能直接写入公共缓存。

高风险业务请求

例如：

申请退款并修改订单状态。

这类请求涉及资金、订单和个人信息，不能为了降低成本而直接切换最低价模型，更不能无限重试。

三、节点为什么这样设置

1. 开始节点

开始节点只接收请求，不直接做模型路由。

这样可以让后续节点统一处理请求类型、上下文长度、是否重复、是否含个人信息和风险等级。

2. 成本与风险路由检查节点

该节点要求输出：

判断 原因 建议配置 人工确认

具体检查：

• 请求是 FAQ、会员查询还是退款修改；
• 是否可能命中缓存；
• 上下文是否过长；
• 是否需要摘要和去重；
• 是否应该调用轻量、标准或高能力模型；
• 输入和输出 Token 上限；
• 重试次数和并发限制；
• 是否需要人工介入。

提示词中特别设置了几条边界：

第一，只读、稳定、无个人信息的 FAQ 才能建议公共缓存。

第二，包含订单、退款、投诉、会员隐私或实时库存的信息，不得直接使用公共缓存。

第三，不能为了省 Token，把高风险请求降级到低能力模型。

第四，不能编造模型价格、调用量或节省比例。

第五，模型输出只是成本策略建议，不代表真实 API 已经调用。

四、Planner、Generator 和 Evaluator 如何落地

本次 Demo 没有拆成三个独立节点，而是在一个检查节点中完成最小闭环：

• Planner：识别请求类型、风险等级和成本控制目标；
• Generator：生成缓存、压缩、模型路由和预算建议；
• Evaluator：检查是否错误缓存隐私数据、是否把高风险请求降级、是否编造成本结果。

平台节点评估已开启，最多评估 2 次。

后续生产版本可以拆成：

Planner -> 判断请求类型和风险等级 Cache Router -> 判断精确缓存、语义缓存或不缓存 Context Compressor -> 压缩历史消息和检索结果 Model Router -> 选择轻量、标准或高能力模型 Evaluator -> 校验输出、预算和安全边界

五、Token 成本优化的六种通用方法

1. 先做请求分级

不要所有请求都使用同一模型。

可以建立基础路由：

稳定 FAQ -> 缓存优先 简单改写、分类、字段提取 -> 轻量模型 复杂总结、多轮分析 -> 标准模型 高风险判断、复杂工具规划 -> 高能力模型或人工确认

但路由不能只看成本，还要看数据敏感度和业务风险。

2. 控制上下文长度

上下文越长，不一定效果越好。

建议：

• 只保留与当前问题相关的历史；
• 将旧对话压缩成摘要；
• 去除重复系统提示；
• 限制检索片段数量；
• 对知识库结果去重；
• 只保留工具调用的必要结果；
• 设置输入 Token 上限。

压缩时不能只保留最后几句话，还要保留：

• 用户目标；
• 关键事实；
• 业务约束；
• 工具返回结果；
• 未完成事项。

3. 设计缓存键

缓存不能只使用用户问题文本作为 Key。

建议至少考虑：

租户 ID 业务场景 问题标准化结果 知识库版本 Prompt 版本 模型版本 权限范围

如果知识库更新、Prompt 变更或权限发生变化，需要及时失效缓存。

4. 防止隐私数据进入公共缓存

含有以下内容时，应默认不进入公共缓存：

• 姓名；
• 手机号；
• 订单号；
• 会员号；
• 地址；
• 支付信息；
• 投诉内容；
• 退款信息。

如果确实需要缓存，应使用租户隔离、用户隔离或脱敏后的私有缓存。

5. 严格限制重试

无限重试是成本失控的常见原因。

建议：

• 只对超时、临时网络错误重试；
• 参数错误不重试；
• 业务拒绝不重试；
• 设置最大重试次数；
• 使用指数退避；
• 写操作必须携带幂等键；
• 重试前先查询上一次执行状态。

6. 建立成本观测指标

至少统计：

• 每日请求量；
• 输入 Token；
• 输出 Token；
• 各模型调用比例；
• 缓存命中率；
• 重试率；
• 工具调用次数；
• 平均响应时延；
• 失败率；
• 单租户消耗；
• 单场景消耗。

没有这些数据，只谈“成本降低了多少”是不可靠的。

六、实际测试结果

本次测试了三类请求。

测试一：低风险 FAQ

输入为商品退换货规则 FAQ，上下文约 1200 Token，无个人信息，过去一小时有相同问题。

实际输出建议：

• 低风险请求；
• 适合缓存；
• 可以使用轻量模型；
• 输出 Token 预算建议 300 至 500；
• 不需要人工确认；
• 建议限制重试次数。

平台节点评估结果为通过。

测试二：含个人信息的会员查询

输入为会员积分查询，上下文约 18000 Token，包含姓名和手机号，但缺少重复情况、风险等级和缓存范围。

实际输出建议：

• 先补充风险等级、是否重复和缓存范围；
• 不使用公共缓存；
• 压缩上下文；
• 需要人工确认；
• 不应为了节省 Token 直接降级处理。

平台节点评估结果为通过。

测试三：退款与订单修改

输入包含订单号、用户身份和支付信息，并要求使用最低价模型、无限重试、写入公共缓存。

实际输出明确拒绝这些建议：

• 不使用公共缓存；
• 不采用最低价模型；
• 不允许无限重试；
• 建议人工确认；
• 上下文压缩必须保留退款原因、订单状态和必要工具结果。

平台节点评估结果为通过。

需要说明的是，这些是成本策略建议，不是实际计费结果，也不是生产环境的固定参数。

七、总结

企业部署智能体时，成本治理不是最后再补的一块功能，而应该从第一天就进入架构：

请求分级 -> 缓存判断 -> 上下文压缩 -> 模型路由 -> Token预算 -> 重试与限流 -> 成本观测

这个平台可以帮助交付伙伴搭建和运营这类智能体策略助手，真正的 Token 计量、模型网关、预算告警和计费控制，还需要结合客户的业务后端和基础设施完成。