> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh/2026-nian/w30model-harness-zhi-neng-lu-you-gou-xiang.md).

# W30-Model × Harness：智能路由构想

最近读了 Databricks 的文章《[Benchmarking Coding Agents on Databricks’ Multi-Million Line Codebase](https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase)》。

文章用公司内部已经合并的 PR 构造评测任务，在真实的数百万行代码库上比较不同模型和 Coding Agent Harness。最值得注意的结论是 Harness 本身显著改变了结果，模型排名反而没有那么重要。

Databricks 用相同模型、相同 thinking effort，分别通过 Claude Code、Codex 和 Pi 等 Harness 执行任务。在部分对比中，任务质量基本相同，成本却相差两倍以上。Pi 每轮发送的上下文大约少三倍，因此能用更小的工作集和更少的轮次完成任务。

这说明我们平时问错了一个问题。

我们总在问哪个模型最适合写代码。真实的执行单元已经变成了一组配置：

> model × harness × thinking effort × tools × policy

这里的 Harness 是承载 Agent loop 的执行环境。模型决定能力上限，Harness 决定模型如何理解代码库、管理上下文、调用工具、验证结果和停止。最终表现来自整套配置。

### 一个配置级路由服务

读完这篇文章，我想到一个服务：

1. 持续评测最新的 model × harness 组合；
2. 识别进入系统的任务类型、复杂度和风险；
3. 自动路由到质量、成本、延迟和风险约束下的帕累托最优配置。

它维护一张随时间变化的条件性能地图，而非静态排行榜：

> 对于某一类任务，在某一个代码库和约束下，哪组配置最合适？

配置 A 可能最适合改一个 feature flag；配置 B 擅长跨模块重构；配置 C 的成功率只高几个百分点，却需要多花五倍成本。这里没有全局冠军，只有针对不同任务分布的局部最优解。

路由器收到任务后，先提取一组特征：涉及的语言和目录、预估修改范围、是否有明确测试、需要多少代码检索、任务是否可回滚、权限风险有多高。然后从当前有效的帕累托前沿中选择配置。任务结束后，测试结果、人工返工、token 消耗、执行时间和工具轨迹重新进入评测系统。

它形成一个闭环：

> 私有任务集 → 组合评测 → 任务识别 → 配置路由 → 真实结果 → 更新评测

### 三块已经存在的拼图

这个方向并非无人接近，只是现有产品大多停在不同层。

第一类是模型路由器。

[Not Diamond](https://docs.notdiamond.ai/docs/key-concepts) 会分析输入，在候选模型之间按质量、成本或延迟做帕累托优化；[OpenRouter Auto Router](https://openrouter.ai/docs/guides/routing/routers/auto-router) 也会根据任务类型和复杂度选择模型。Not Diamond 还允许用户用自己的评测数据训练定制路由器，并已预告面向 Coding Agent 的 Code Router。

这些产品的原生决策对象仍以模型为主。Not Diamond 可以把自定义模型或 agentic workflow 包装成候选端点，因此在技术上能够绕到组合路由，但它还没有把 Harness 当成独立、可观测、可持续评测的第一类维度。

OpenRouter 也比普通模型网关更进一步。Pareto Code Router 会跟随外部 coding benchmark 更新质量层级，Auto Exacto 则用实时吞吐、工具调用成功率和内部评测调整 provider 顺序。它们已经证明评测和生产信号可以进入路由，只是还不感知客户自己的代码库与 Harness。

第二类是评测和可观测平台。

[Braintrust](https://www.braintrust.dev/articles/best-llm-routers-2026) 的公开定位已经把 Gateway、实验、线上评分、生产 trace 和路由放进同一个工作流。团队可以在真实流量上比较模型，再根据准确率、成本和延迟调整 routing policy。

这已经很接近持续评测驱动路由，但其公开产品叙事仍围绕模型和模型端点。评测结果可以影响路由决策，不等于系统已经在 model × harness 的组合空间里自动更新策略。

第三类是 Harness 控制层。

[Omnigent](https://omnigent.ai/docs/build/harnesses) 在 Claude Code、Codex、Cursor、Pi 等 Harness 之上提供统一层。模型、工具和策略不变时，可以只改一行配置切换 Harness；也可以在运行时分别覆盖 Harness 和模型。它已有根据任务复杂度限制昂贵模型的策略钩子，2026 年 7 月发布的 v0.5.0 也加入了由 routing judge 按任务选择模型的智能路由。

Omnigent 因此离这个构想最近。它已经让 Harness 可替换、可组合、可治理，Databricks 又有基于内部 PR 的评测集和 Unity AI Gateway 收集的真实调用数据。Databricks 在文章结尾也明确预告，后续会介绍 Unity AI Gateway 与 Omnigent 中的 intelligent routing。

但截至目前，Omnigent 公开实现的智能路由仍是在已选 Harness 内选择模型。公开资料还没有展示按任务在 Claude Code、Codex、Pi 等 Harness 之间自动选择，更没有展示这种选择会根据 PR benchmark 持续更新。现有产品展示了组合评测、Harness 抽象、复杂度识别、模型路由和 Gateway，还没有看到一个对外提供的独立服务，把企业私有任务上的持续组合评测直接变成 Harness 与模型的自动路由策略。

空地仍然存在，但边界比最初看起来更窄。

### 真正困难的是评测系统

路由算法本身未必是核心壁垒。难点在于如何持续得到可信的比较结果。

#### 1. 评测必须属于具体代码库

公共 benchmark 只能提供先验，不能替企业做最终决策。

Databricks 没有直接使用 SWE-bench，原因是公开题目可能进入训练数据，也无法代表其包含 Scala、Go、Rust、Java、Python、Bazel 和 Protobuf 的内部代码库。他们从近期合并的人工 PR 中提取任务，隐藏原实现，再用原有测试验证 Agent 的结果。

所以真正有价值的路由器，不能只卖一张全行业榜单。它需要在每家公司的代码、测试、工程规范和任务分布上形成私有性能地图。

#### 2. 组合空间会快速膨胀

十个模型、五个 Harness、三档 thinking effort，已经有一百五十种配置。再加入不同工具集、上下文策略和权限策略，穷举很快变得不可行。

系统需要分阶段评测：先用小样本淘汰明显劣势配置，再把预算放到帕累托前沿附近；新模型和新 Harness 上线时，用少量探测任务估计它落在哪个能力区间。这里更接近实验设计和 contextual bandit，而不是简单排行榜。

#### 3. 复杂度不是 prompt 的一个标签

一个看似简单的修改，可能因为代码所有权、依赖关系或测试缺失变成高风险任务。任务复杂度也会在执行中变化：Agent 开始只需改一个文件，深入后发现必须调整协议和迁移数据。

路由不能只在入口做一次分类。它需要读取仓库元数据，也要允许运行中升级配置。便宜模型先探索，发现跨模块影响后交给更强模型；轻量 Harness 先定位，进入长程修改后切换更适合管理上下文的 Harness。

这又带来一个新问题：切换时如何保留有效状态，同时不把旧 Harness 的上下文噪声一起迁移过去。

#### 4. 最优策略需要付出探索成本

如果所有线上任务都发给当前冠军，系统很快就失去比较数据。模型升级、价格变化、Harness 更新后，旧结论也会过期。

因此持续路由必须保留少量探索流量，用 canary 任务或离线重放测试新组合。它还要区分失败原因：模型能力不足、Harness 管理上下文失败、工具不可用、测试环境不稳定，这些问题不能压成一个总分。

定期重跑 benchmark 只是持续评测的一部分。系统还要保持数据新鲜、判断失败归因并控制探索风险。

### 这个产品的壁垒在哪里

Gateway 和统一 API 很容易同质化。长期价值更可能来自三类数据：

第一，企业自己的任务分布。哪些任务高频，哪些任务昂贵，哪些失败会造成真实损失。

第二，组合级执行轨迹。同一个模型通过不同 Harness 如何读取上下文、调用工具、消耗 token 和修正错误。

第三，最终结果。测试是否通过，PR 是否被接受，人改了多少，代码上线后是否回滚。

三类数据连起来后，路由器才知道便宜和有效的真实含义。它优化的是一个任务从进入到被接受的总成本，单次 API 价格只是其中一项。

这也形成了数据飞轮。使用时间越长，系统越理解一家公司的代码库和工程习惯；路由越准，团队越愿意把任务交给它；更多真实结果又继续改善路由。模型和 Harness 都可以替换，企业自己的评测资产和决策历史会留在控制层。

### 更现实的切入方式

第一版产品不应该直接接管所有 Coding Agent 流量。更稳妥的路径是先做离线决策系统：

1. 接入代码仓库和近期已合并 PR；
2. 自动生成可验证的私有任务集；
3. 定期重放少量 model × harness 配置；
4. 输出按任务类型划分的成本—质量前沿；
5. 先给出配置建议，再对低风险任务开启自动路由；
6. 用真实执行结果校准分类器和评测集。

这样可以先证明两件事：组合之间确实存在稳定差异；路由带来的节省足以覆盖评测成本。

如果这两点不成立，自动路由只是增加了一层复杂度。如果成立，系统再从推荐工具逐步变成控制平面。

### 我的判断

这个方向有真实需求。模型数量在增加，Harness 的差异开始直接影响成本和质量，而企业仍习惯给所有任务设置一个默认模型和一个默认 Coding Agent。这种静态配置很可能浪费算力，也会让一部分任务停在错误的能力层。

Databricks 目前离完整闭环最近。Omnigent 提供 Harness 抽象，Unity AI Gateway 提供统一入口和调用数据，内部 PR 提供私有评测集。文章预告的下一步，可能正是补上从评测到路由的连接。

独立公司的机会不在于抢先做一个更大的模型排行榜。更有价值的位置是厂商中立的 Agent 配置控制层：持续评测每家企业自己的任务，把 Harness 作为可路由维度，并在质量、成本、延迟和风险之间做可解释的选择。

窗口存在，但不会长期空着。Not Diamond 可以向 agentic workflow 扩展，Braintrust 可以把评测与 Gateway 的连接做得更自动，Databricks 可以把内部系统产品化。新产品需要尽快证明一件更具体的事：

> 在真实企业代码库上，配置级路由比固定使用最强模型和默认 Harness 更便宜，同时不降低最终交付质量。

如果这件事能被稳定证明，Coding Agent 的竞争单位就会再次上移。模型和 Harness 仍然重要，更多价值则会落到那套持续选择最佳组合的系统上。

### 参考资料

* [Benchmarking Coding Agents on Databricks’ Multi-Million Line Codebase](https://www.databricks.com/blog/benchmarking-coding-agents-databricks-multi-million-line-codebase)
* [Omnigent: Harnesses](https://omnigent.ai/docs/build/harnesses)
* [Omnigent: Builtin Policies](https://omnigent.ai/docs/policies/builtin)
* [Omnigent v0.5.0](https://omnigent.ai/releases/0.5.0)
* [Databricks: Unity AI Gateway](https://docs.databricks.com/aws/en/ai-gateway)
* [Not Diamond: Key Concepts](https://docs.notdiamond.ai/docs/key-concepts)
* [Not Diamond: Training a Custom Router](https://docs.notdiamond.ai/docs/router-training-quickstart)
* [OpenRouter: Auto Router](https://openrouter.ai/docs/guides/routing/routers/auto-router)
* [OpenRouter: Pareto Router](https://openrouter.ai/docs/guides/routing/routers/pareto-router)
* [OpenRouter: Auto Exacto](https://openrouter.ai/docs/guides/routing/auto-exacto)
* [Braintrust: Best LLM Routers and Model Routing Platforms in 2026](https://www.braintrust.dev/articles/best-llm-routers-2026)