导读Databricks 把 Coding Agent 的路由从“选模型”推进到“按任务选 Model + Harness"。成本优化的重点，也从 Token 单价转向一次任务最终花多少钱。
1. 模型便宜，不等于任务便宜
2. Smart Routing 为什么按 Task 路由
3.只选模型还不够，Harness 也进入路由
4. Agent 成本开始按“完成任务”算
8 月 13 日，Databricks 正式发布 Smart Routing，并以 Beta 形式接入 Unity AI Gateway。它会先判断 Coding Task 的复杂度，再把任务交给能够完成它的低成本模型；与 Omnigent 结合后，路由对象进一步从 Model 扩展到 Model + Harness。官方结果显示：在内部 Coding Workload 上，Smart Routing 的单任务成本约为 Claude Opus 5 的 65%，表现还略高；在公共 Coding Benchmark 上，它以不到一半的成本达到与 Opus 5 相当的表现。
关键不在 Router 本身，而在路由单位变了。Databricks 7 月的内部 Benchmark 已经显示，模型 Token 单价并不能直接代表任务成本，同一个模型换 Harness，成本也可能出现超过 2 倍的差距。到了 Smart Routing，优化对象开始从一次模型调用上移到一个完整 Task。
图 1｜Databricks 将低成本模型、Smart Routing、预算控制和 Context 优化列为 AI Coding 的四类主要成本手段。其中 Smart Routing 的方向性节省约为 30%。来源：Databricks 官方博客。
模型便宜，不等于任务便宜
传统 LLM 的价格很好比较：看输入、输出每百万 Token 的单价。但 Coding Agent 会读代码、搜仓库、调用工具、反复推理，再根据结果继续行动。最终成本取决于“单价 × 实际消耗”，而实际消耗又受模型推理效率、Harness 的上下文管理和任务轮数影响。
Databricks 的内部 Benchmark 给出了一个很直接的例子：Sonnet 5 每 Token 约比 Opus 4.8 便宜 1.7 倍，但完成同一批任务时，Sonnet 5 平均成本是 2.09 美元/Task，反而高于 Opus 4.8 的 1.94 美元/Task；完成率也更低，分别为 81% 和 87%。原因是 Sonnet 5 工作得更久、读取更多内容，总 Token 消耗约为后者的 1.9 倍。
这也是 Databricks 强调"Efficiency Frontier（效率前沿）”的原因。企业真正需要找的，不是绝对能力最强或 Token 单价最低的模型，而是在达到质量要求时，完成任务总成本最低的模型。对于改配置、单文件修改、明确的 Bug Fix，昂贵的前沿模型并不总是必要。
图 2｜同一模型、同一思考强度下，Pi 与原生 Harness 的单任务成本可相差 1.2～2.08 倍；不同配置的任务完成率也有小幅波动。来源：Databricks 官方 Benchmark。
Smart Routing 为什么按 Task 路由
Smart Routing 没有选择“每次请求都重新换模型”，而是采用 Task-aware Routing：在任务开始时判断复杂度，选定 Model 和 Harness，并尽量在这个任务中保持不变。原因很现实——Coding Agent 的长上下文高度依赖 Prompt Cache，频繁切换模型会打掉 Cache Hit，反而推高成本。
当前 Router 会先用一个便宜、低延迟的模型读取任务描述和元数据，判断修改范围、代码证据、故障形态、修复是否局部化等特征，再从中推断任务类型。随后系统默认从中等能力模型开始：简单任务下沉到便宜模型，复杂任务再升级到更强模型。
官方公布的结果是：内部 Benchmark 节省 35% 成本；公共 Coding Benchmark 节省 56%，同时达到与 Opus 5 相当的任务完成率。也就是说，主要收益并不是“所有任务都降级”，而是把昂贵模型留给真正需要它的任务。
图 3｜Smart Routing 在 Databricks 内部任务上节省 35% 成本；在公共 Coding Benchmark 上节省 56%，并达到与 Claude Opus 5 相当的表现。来源：Databricks 8 月 13 日官方博客。
只选模型还不够，Harness 也进入路由
模型只是 Agent 成本的一部分。Harness 决定每轮给模型多少上下文、怎样保留状态、何时调用工具、何时压缩上下文。Databricks 的 Benchmark 显示，同一个模型、同一思考强度，仅更换 Harness，单任务成本在部分配置中就能相差 2 倍以上。
差距主要来自上下文管理。Databricks 观察到，Pi Harness 每轮重新发送给模型的 Context 约少 3 倍，同时用更少的运行轮次完成任务。换句话说，模型价格决定“每个 Token 多少钱”，Harness 会影响“一个任务究竟要花多少 Token"。
Omnigent 就是为这层问题提供的 Meta-Harness。它位于 Claude Code、Codex、Pi 和自定义 Agent 之上，用统一接口把不同 Harness、Model 和 Agent 组合起来。开发者不必把工作方式绑定在某一个 Harness 上，模型和 Harness 也更容易被替换。
Smart Routing 与 Omnigent 结合后，可以为每个任务同时选择 Harness 和 Model；Sub-agent 启动时也会再次经过 Smart Routing，因此不同子任务可以拿到不同的组合。Harness 由此从开发者事先固定的工具，变成运行时可以参与调度的变量。
图 4｜Smart Routing 与 Omnigent 结合后，可以按任务自动选择 Coding Harness 和 Model；Sub-agent 也可以再次路由。来源：Databricks 8 月 13 日官方博客。
Agent 成本开始按“完成任务”算
在 Agent 场景里，用户最初输入的 Prompt 往往只占最终上下文的一小部分。真正进入模型的还有代码、搜索结果、工具输出、Skills、系统信息和历史状态。Databricks 提到，通过调整 Harness 和 Cache 设置，其内部生成 Token 数量及相关成本曾接近下降 50%，且没有观察到开发者侧的质量下降。
因此，只看“每百万 Token 多少钱”很难判断一个 Agent 是否真的便宜。更有意义的是看完整任务：花了多少钱、有没有完成、是否需要升级模型。Databricks 对 Router 的评估也直接关注端到端完成的 Session 数量和实际节省金额，而不是只看 Token 单价。
这条变化可以压缩成三步：
以前：Prompt → 一个模型
后来：Prompt → Router → 多模型
现在：Task → Smart Routing → Model + Harness；Sub-agent → 再次 Routing
Router 的角色也随之变化：它不再只是“给请求分模型”，而是在任务开始时决定应该用哪一级模型、哪个 Harness，以及哪些子任务值得重新路由。成本优化的单位，从单次推理调用上移到了完整任务。
Smart Routing 目前仍处于 Beta，Databricks 也明确承认现阶段还有局限：真实开发中的第一句话往往并不完整，一个 Session 还可能在中途换任务，而当前 Router 主要依据任务开始时的信息做决定。Databricks 正在研究延后几轮再路由、在 Context Compaction 时切换模型等方案。
Smart Routing 把 Agent 成本优化改成了一套任务级决策：先判断任务，再决定用什么 Model、什么 Harness，以及什么时候值得使用更贵的能力。企业最终要优化的，是完成一个任务的成本，而不是买到最便宜的 Token。
资料来源｜Databricks 官方
1. Smart Routing in Unity AI Gateway: Match frontier quality with 30%+ lower cost per task（2026-08-13）
2. Managing AI Coding Costs at Scale（2026-08-07）
3. Smart Routing for coding agents（文档最后更新 2026-08-12）
4. Benchmarking Coding Agents on Databricks'Multi-Million Line Codebase（2026-07-08）
5. Introducing Omnigent: A Meta-Harness to Combine, Control and Share Your Agents（2026-06-13）
往期推荐