> 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-hant/2026/w30-model-harness-an-intelligent-routing-vision.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)