AI技术

从Token降价到多模型路由：企业Agent成本控制架构

,
从Token降价到多模型路由：企业Agent成本控制架构封面

9月24日AI技术日报里，有一组看似只是“模型降价”的消息：GPT-6 Sol与Luna把同档API价格继续向下压，缓存输入读取折扣达到90%；与此同时，AnyJev尝试把开放大模型变成带置信度的类型化决策组件，Prismor则把安全判断放到工具真正执行之前。把三件事放在一起看，结论并不是“以后调用大模型更便宜了”，而是企业Agent终于具备了按任务拆分成本的条件。

模型单价下降当然重要，但它很容易制造一种错觉：只要换成更便宜的模型，总账就会同步下降。实际运行中，企业Agent的成本不是一个简单的“输入Token数×输入单价＋输出Token数×输出单价”。一个任务可能经历意图识别、资料检索、计划生成、工具调用、异常重试、结果核验、总结归档等十几个阶段；同一段系统提示、业务规则和历史上下文可能被重复读取几十次。真正应该管理的是“完成一个可验收业务结果的总成本”，而不是单次调用价格。

从Token降价到多模型路由：企业Agent成本控制架构信息图

先把成本对象从Token改成任务

企业可以把Agent任务成本拆成六部分：模型推理、上下文读取、检索与存储、工具执行、失败重试以及人工复核。模型推理最显眼，却未必占比最高。长链路任务里，重复上下文、低质量检索导致的冗余输入、工具超时后的整链重跑，以及最终仍需人工返工，都会吞掉降价红利。

因此，成本看板至少需要同时记录三个口径：每次调用成本、每个任务成本和每个成功任务成本。第三个最关键。一个低价模型如果把任务成功率从90%降到65%，并触发更多升级调用和人工处理，它可能比高价模型更贵。日报提到OpenAI公布的AutomationBench数据适合观察“能力—成本”趋势，但厂商自有评测不能直接代替企业真实流程。企业需要建立自己的任务集，以订单核验、合同抽取、设备告警处置、客服闭环等结果作为分母。

可落地的指标包括：首次完成率、平均调用步数、升级率、重试率、缓存命中率、人工接管率、单成功任务成本和P95任务时延。预算控制也应落到任务级，例如“普通工单自动处理成本不超过0.2元，高风险合同审查不超过8元”，而不是笼统规定每月Token额度。

一套可实施的六层成本控制架构

第一层是任务入口与预算封套。每个请求进入系统时先生成任务ID，绑定租户、业务类型、数据敏感级别、时延目标和最大预算。预算不是到月底才统计，而是执行过程中的硬约束。规划器在每一步调用前预估剩余成本；达到软阈值时缩短上下文、换低价模型或减少候选分支，达到硬阈值时停止自动执行并转人工。

第二层是轻量分类与置信度路由。日报中的AnyJev说明，许多流程并不需要模型自由生成，而只需要分类、路由、批准或风险评级。入口处可用小模型或经过校准的类型化决策器判断任务难度、领域和风险，并输出置信度。高置信度、低风险任务进入低价模型；低置信度任务升级到中高能力模型；涉及付款、删除、外发数据等动作，则无论文本判断多自信，都进入规则审查或人工审批。

第三层是多模型执行池。企业不应把“一个Agent”绑定为“一个模型”。更合理的方式是按角色配置模型：便宜模型负责改写查询、结构化抽取和常规摘要；中档模型负责计划与多步推理；最强模型只处理歧义高、损失大的少数节点；确定性程序处理计算、格式转换和数据库查询。模型路由策略也不应只比较报价，而要根据企业离线评测得到的质量—成本前沿动态选择。

第四层是上下文与缓存层。日报强调，Agent成本高点常常是同一上下文被反复读取。Prompt Caching要发挥作用，提示词必须工程化：把长期稳定的系统规则、工具定义和公共知识放在前缀，把用户输入与实时数据放在后部；对稳定前缀做版本管理，避免无意义的空格、顺序和字段变化破坏缓存键。对于长任务，还应把完整轨迹压缩成“状态快照＋证据引用”，不要在每一步回放全部对话。

缓存也有边界。个性化敏感信息不应进入跨用户共享缓存；时效性数据要带TTL；模型版本、工具清单或安全策略变化后，应主动失效相关条目。缓存命中率不能孤立追求，如果为了命中而塞入大量无关固定文本，输入账单和注意力污染反而会上升。

第五层是工具执行控制面。Prismor带来的启发是，成本控制与安全控制应落在同一个“执行前关口”。Agent发起Shell、文件、包安装或外部API动作时，控制面先判断允许、警告还是阻断，同时估算调用费用、资源消耗和可逆性。例如，高价搜索API连续调用、云端批量转码、数据库全表扫描，都可能不是Token成本，却会显著推高任务账单。执行前策略可以限制次数、并发和金额，并要求幂等键，防止重试造成重复扣费或重复写入。

第六层是评测与成本归因。每一步都要写入统一追踪记录：调用了哪个模型、使用哪个提示版本、输入输出Token、缓存命中情况、工具费用、路由原因、置信度、结果评分以及是否人工接管。只有把日志关联到任务ID和最终业务结果，FinOps团队才知道钱花在哪个环节，模型团队才知道降本是否伤害质量。

路由机制不能只是一个if-else

早期系统常按输入长度或关键词选择模型，这种方式简单，却无法处理真实风险。更稳妥的路由器至少考虑五个维度：任务复杂度、错误损失、数据敏感度、时延要求和当前预算。它可以采用“规则底座＋校准分类器＋在线反馈”的组合，而不是完全交给另一个生成模型。

推荐采用三级升级机制。L0由规则和类型化决策器完成，不生成长文本；L1使用低价模型完成常规任务，并进行格式与事实校验；L2使用强模型处理复杂任务。若L1输出未通过Schema验证、证据不足或置信度低，再升级到L2，而不是默认所有请求都使用最强模型。对高风险动作，模型升级不能替代人工授权。

还要避免“级联失控”：便宜模型失败后反复尝试，最终又调用强模型，造成成本叠加。每类任务应规定最大尝试次数、升级路径和终止条件。路由器自身也必须被评测，重点观察错路由率：把难题送给弱模型会损害质量，把简单题送给强模型则浪费预算。

路由评测集不能只收集“模型能不能答对”的题，还要还原路由器真正面对的选择。每条样本至少包含原始请求、任务类型、风险等级、允许使用的数据、期望输出、验收规则、可接受时延和成本上限，并标注“最低可胜任模型”。这样才能同时计算任务成功率与过度路由率。对于合同、客服、代码和数据分析等不同场景，应分别抽取简单、边界、对抗和历史故障样本；线上出现人工接管、连续重试或投诉后，也要将对应轨迹脱敏后补入回归集。

评测时应冻结提示版本、工具版本和价格快照，对候选模型做同批回放，并至少重复运行数次，避免一次采样的偶然性。评分不能只依赖另一个模型裁判：结构化抽取可用字段级准确率，工具任务可核对最终系统状态，事实问答应检查证据是否支持结论，高风险流程则由领域人员抽检。最终按任务分层绘制质量、时延和成本的前沿线，再为路由器设门槛。例如，低风险任务允许在质量下降不超过既定范围时选择更低成本模型；高风险任务则优先满足零关键错误约束。

预算策略也要区分“预留、消耗和结算”。任务开始时根据历史分位数预留预算，执行中每一步扣减预计费用并保留升级余量，结束后再按实际Token、缓存折扣和工具账单结算。若一开始就把预算全部交给低价模型，失败后往往没有余量调用强模型；更稳妥的做法是为验证、升级和人工接管预留固定比例。批量任务还应设置租户级和队列级限额，避免某个异常批次挤占全公司的日预算。

软预算触发后，系统可依次采取减少候选数、停止非必要润色、压缩历史上下文、改用批处理或延后低优先级任务；硬预算触发后则只允许完成安全收尾，不再开启新的模型分支。预算豁免必须记录原因、批准人和有效期，不能把“临时放开”变成长期默认。财务侧可以按业务价值设不同封套，但技术侧仍应公开同一套单成功任务成本口径，防止部门通过降低验收标准制造表面降本。

数据工程决定缓存和路由能否长期有效

多模型架构最容易低估的是数据一致性。不同模型的分词方式、上下文窗口、工具调用格式和结构化输出能力不同；如果没有统一消息协议，同一任务切换模型时就会丢失状态。企业应建立模型无关的任务状态Schema，把事实、假设、证据、待执行动作、执行结果和错误分开保存，不把自然语言对话当作唯一状态载体。

提示词、路由规则、模型版本、评测集和价格表都需要版本化。价格变化后，路由策略可以重算，但不能悄悄改变已经审批的高风险流程。离线数据还要覆盖长尾失败案例，并按部门、语言、文本长度、敏感级别分层，防止平均分掩盖局部退化。

缓存版本治理需要把“内容相同”和“语义兼容”分开处理。缓存键可由租户隔离域、模型版本、稳定提示摘要、工具清单版本、安全策略版本和知识库快照共同生成，而不是只对整段文本做哈希。提示词改了标点但语义未变时，可通过规范化减少无效失效；安全边界、工具参数或知识截止时间变化时，则必须提升版本并定向清理。为避免一次升级造成命中率骤降，可以采用新旧版本短期并行预热，但读取时只能命中与当前策略明确兼容的条目。

缓存条目还应记录创建时间、来源、数据级别、TTL和最后命中时间。下线模型、撤销文档权限或修正错误知识后，要能按版本或来源批量失效，而不是等待自然过期。上线前应观察命中率、节省金额、过期读取率和错误复用率；其中错误复用率比命中率更重要。缓存返回的内容仍需经过权限检查和必要的时效校验，不能因为结果曾经正确，就绕过当前任务的安全控制。

隐私方面，应落实最小化输入：检索层只送与任务相关的片段，敏感字段先脱敏，跨境和跨租户数据禁止混入共享上下文。日志保留输入输出时也要采用分级存储，运营指标可以长期保存，原始业务内容则按合规期限删除。

失败重试必须有边界，也必须能够回滚

重试首先要判断失败属于哪一类。网络超时、限流和短暂服务不可用，可以在读取服务端重试提示后采用指数退避，并加入随机抖动；格式不合法可在保留原证据的前提下做一次定向修复；权限不足、参数错误、预算耗尽和安全策略阻断则不应盲目重试。每次尝试都要继承同一任务ID，同时生成独立尝试ID，记录失败分类、已花成本和下一步依据。

涉及外部写入时，重试前必须确认动作是否已经生效。付款、发信、建单、修改数据库等操作应使用幂等键，并把“准备执行、已提交、已确认”分开记录；如果状态未知，先查询外部系统，而不是再次提交。多步骤流程可采用补偿动作回滚，例如撤销尚未生效的预约、恢复旧配置或标记订单待人工处理。并非所有动作都可逆，因此系统要在执行前保存旧值、版本号和证据，对不可逆动作提高审批等级。

模型或路由策略发布也要支持回滚。新版本先做影子流量和小比例灰度，同时保留旧模型、旧提示与旧路由配置；当关键错误率、人工接管率、P95时延或单成功任务成本越过阈值时，自动停止扩量并切回已验证版本。回滚后仍要保留失败轨迹用于复盘，不能只删除异常结果。这样，重试解决单次波动，回滚控制系统性退化，两者都不会把失败成本无限转嫁给后续链路。

产业判断：模型降价会抬高架构能力的价值

当模型价格持续下降，企业间差距不会自动缩小。相反，便宜模型会鼓励更多自动化尝试，调用规模迅速扩大，架构中的浪费也会被同步放大。未来采购重点将从“哪家模型每百万Token便宜”转向三个问题：能否稳定完成业务任务，能否在多模型之间迁移，能否解释每一笔成本和每一次自动决策。

模型厂商会继续用缓存折扣、批处理价和不同能力档位争夺工作负载；Agent平台会把路由、观测、预算和安全策略做成控制平面；企业自己的护城河，则是任务评测集、路由数据和流程级成本基线。模型可以替换，但这些运营数据很难直接购买。

企业现在可以做什么

第一，用两周时间选出20—50个高频任务，补齐“成功定义”和人工基准成本。第二，建立最小三档模型池，不必一开始接入十几个模型。第三，把稳定提示前缀、工具定义和任务状态拆开，测试真实缓存命中率。第四，在所有工具调用前加统一策略层，设置金额、次数、权限和幂等约束。第五，每周审查单成功任务成本，而不是只看Token总量。第六，为路由器建立回放测试，任何模型、价格或提示升级都先跑企业任务集。

Token降价是机会，但不是答案。企业Agent真正成熟的标志，是系统能把每一单位智能分配到最需要它的步骤，并且知道什么时候不该调用模型。

参考资料

分享到