IBM 实战总结：AI Agent 模型路由不是分类问题，而是系统优化

type

status

date

slug

summary

成本：标价不代表真实账单

IBM 团队在 AppWorld Test Challenge 上用同一个 CodeAct Agent 跑了 417 个任务，结果出人意料：Claude Sonnet 4.6 总共花费 79 美元（每个任务 0.19 美元），而 GPT-4.1 花费了 155 美元（每个任务 0.37 美元），几乎贵一倍。单看 token 定价，GPT-4.1 在输入和输出上都更便宜，而且 Sonnet 完成任务所需的推理步骤大约是其三倍，按理说 GPT-4.1 应该轻松胜出。

真正的解释是缓存。Agent 工作负载会在多个步骤之间反复复用大段上下文，当缓存命中率很高时，有效输入成本会大幅下降。Sonnet 更低的缓存读取价格让它在这种模式下获得了不成比例的优势，足以抵消更高的基础定价和更长的执行轨迹。结论很直接：只看定价表的路由器，优化的是错误的数字。

复杂度：任务难度在路由时往往不可见

按"任务难度"分流是最常见的路由策略，但它有两个致命缺陷。第一，难度往往在执行前无法判断——一句看似简单的"总结这份合同"，可能触发检索、合规检查、工具调用和多轮修订；而一个高度技术性的提示词，反而可能被一个小的专用模型高效处理。第二，即使能完美估计难度，它也只是众多信号之一。生产环境中的路由器需要同时平衡成本、延迟、模型专长和可靠性，企业部署还要叠加合规要求、数据驻留规则、隐私约束和获批模型清单。一个理想上该去某模型的任务，可能因治理原因必须去别处，路由器还得优雅地处理这种情况。

延迟：不只是模型大小的问题

用户实际感受到的延迟远不止模型本身的速度。路由本身会引入开销；硬件类型、缓存是否预热、端点繁忙程度等基础设施因素，常常主导端到端响应时间。路由粒度也是关键权衡：每个任务路由一次开销最小，但逐步路由虽然更灵活，每一个额外决策点都会增加延迟和运维复杂度。

IBM 的解法：从分类转向优化

基于这些教训，IBM 团队不再问"哪个模型最适合这个任务"，而是让路由算法同时优化成本、质量和延迟三个维度，并保持自身轻量（每个任务约 6 毫秒、2KB 内存），避免路由器本身成为瓶颈。在 AppWorld 测试中，其延迟优化配置以 93 美元成本、83 秒耗时达到 84% 准确率——相比单独运行 Opus，成本降低 21%、延迟降低 9%，准确率仅下降 4%。而传统的基于难度的路由器虽然准确率相近，成本却更高，因为它无法像优化方法那样探索完整的权衡空间。

风险与限制

需要注意的是，这些结论高度依赖具体工作负载和基础设施。缓存命中率、任务结构和合规约束在不同企业间差异巨大，一套路由策略很难通用。此外，优化型路由器需要持续采集成本与质量信号，本身也带来额外的工程与运维投入，小规模团队未必能立刻复制。

结语

IBM 这篇实践文章的核心启示是：模型路由的本质不是"选模型"，而是为整个系统寻找最优运行点。模型只是一个变量，缓存行为、基础设施状态、合规约束和工作负载模式同样重要。对正在构建 Agentic 系统的团队来说，把路由当优化问题而非分类问题来设计，才是值得投入的方向。