企业开始部署智能体后最先遇到的问题往往不是模型能不能回答而是账单越来越难解释为什么同一个问题重复调用多次为什么输入 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 计量、模型网关、预算告警和计费控制还需要结合客户的业务后端和基础设施完成。