面向 Coding Agents 的 MCP Model Catalog：讓模型選擇實現機器可讀性

如果編碼代理將模型名稱寫死（hardcode）在程式碼中，最終一定會在凌晨兩點觸發警報。針對編碼代理使用 MCP 模型目錄可以改變這種失敗模式。代理程式不再是讀取埋在原始碼中的字串，而是在請求時讀取包含當前模型、成本、模態（modalities）和狀態欄位的結構化清單。我們在 TokenLab 維護著類似的目錄，並將其視為路由的唯一事實來源（source of truth）。在我們的管線中，模型選擇是一個查詢動作，而非一個常數。

為什麼編碼代理需要機器可讀的模型資料

大多數編碼代理的整合方式仍像十年前的 API 整合。開發者挑選一個模型名稱，貼到設定檔或環境變數中，然後發布。這在模型被供應商棄用、定價變更或發布更好的選項之前都運作良好。一旦發生變動，團隊往往沒有採用新模型的流程。

機器可讀的目錄改變了這種失敗模式。當模型退役時，代理程式可以查詢目錄，發現模型已消失或被標記為棄用，並自動切換到已記錄的替代方案。開發者無需手動對每個新發布的模型進行基準測試，工具可以先比較列出的上下文視窗（context windows）、模態支援和成本欄位，再進行切換。

這也是進行嚴謹模型路由的先決條件。你可能希望在 DeepSeek V4 Flash 或 Gemini 3.5 Flash 上進行低成本、高流量的補全任務，並保留 Claude Sonnet 5 用於多檔案重構。路由邏輯仍然需要一個事實來源，該來源必須說明哪些模型是當前的、它們的成本是多少，以及它們支援什麼功能。沒有它，路由規則就會像寫死的模型名稱一樣逐漸失效。

TokenLab 曾直接探討過這個問題。請參閱 agent-readable model truth 以了解更廣泛的論點，並參閱 agent-first API 以了解當主要呼叫者是代理而非人類開發者時，API 設計會如何改變。

重點摘要

• 模型目錄將模型選擇從寫死的字串轉變為執行時期的查詢，這減輕了供應商發布新模型時的維護負擔。
• 編碼代理受益於將不同任務類型（自動補全、重構、測試生成、審查）路由至不同的模型，而不是對所有任務使用同一個模型。
• MCP 的模型目錄資料請求通常遵循 resource-list 或 tool-call 的形式；在進行開發前，請務必根據供應商的官方文件驗證確切的 schema。
• TokenLab 在 /models/data 發布模型資料中心，並在 /models 發布模型目錄；請將這些地方視為驗證當前模型名稱的來源，而非本文，因為模型陣容變動頻繁。

MCP 模型目錄條目應包含什麼

對於編碼代理而言，有用的目錄條目不僅僅需要模型名稱。開發者和使用者至少應預期看到：

• 模型識別碼 (Model identifier)：API 預期的確切字串，因為供應商通常會精確地對名稱進行版本控制（此處的不匹配是最常見的整合錯誤之一）。
• 供應商 (Provider)：提供該模型的公司或平台，當目錄聚合多個供應商時，此資訊尤為重要。
• 模態支援 (Modality support)：文字、程式碼、影像或影片。將像 Kimi K2.7 Code 這樣的編碼模型與像 Nano Banana Pro 這樣的影像模型混合在同一個目錄中時，需要一個欄位讓代理程式根據實際需求進行篩選。
• 上下文視窗 (Context window)：對於在大型儲存庫中工作的編碼代理來說，token 限制至關重要。
• 成本欄位 (Cost fields)：輸入和輸出 token 的定價，最好分開列出，因為編碼代理通常有非對稱的輸入密集型工作負載（大型檔案上下文、小型 diff 輸出）。
• 狀態 (Status)：當前、已棄用或預計退役。這是防止靜默故障（silent breakage）的關鍵欄位。
• 任務適用性標籤 (Task suitability tags)：選用但有用的元資料，例如「coding」、「low-cost routing」或「open-weight」，以便代理程式無需事先了解每個模型的特性即可進行篩選。

並非每個供應商的目錄格式都保證包含這些欄位。在 建立整合 之前，請檢查您所使用供應商記錄的實際 schema。對於 TokenLab 提供的模型，請驗證當前的欄位集和更新頻率（位於 /models/data），不要假設它們與本文相符。目錄 schema 會隨著新模型和模態的增加而改變。

範例：透過 MCP 請求模型目錄

MCP 通常透過 JSON-RPC 2.0 進行通訊。客戶端要求伺服器列出可用模型資源時，可能會發送如下格式的請求。此範例遵循一般的 MCP resource-list 模式，並非針對任何特定供應商的即時 schema。在編寫生產環境程式碼之前，請務必對照 https://docs.tokenlab.sh 或您的 MCP 伺服器文件確認確切的方法名稱和回應欄位。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "resources/list",
  "params": {
    "filter": {
      "modality": "text",
      "tag": "coding"
    }
  }
}

一個合理的預期回應格式（同樣僅供說明，非驗證過的 schema）：

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resources": [
      {
        "id": "claude-sonnet-5",
        "provider": "Anthropic",
        "modality": ["text", "code"],
        "context_window": "verify at provider docs",
        "status": "current",
        "tags": ["coding", "review"]
      },
      {
        "id": "deepseek-v4-flash",
        "provider": "DeepSeek",
        "modality": ["text", "code"],
        "context_window": "verify at provider docs",
        "status": "current",
        "tags": ["low-cost", "coding"]
      }
    ]
  }
}

請勿將上述的上下文視窗數值、確切欄位名稱或特定模型視為任何即時 API 的確認事實。它們僅展示請求與回應的結構，而非定價或效能數據。在開發時，請從供應商的當前文件或 /models/data 獲取這些數值。

按任務選擇模型：決策檢查清單

模型目錄只有在代理程式或設定代理程式的開發者擁有將任務類型與模型匹配的規則時才有用。下表是一個入門框架，而非基準測試結果。在投入生產環境的路由規則之前，請務必根據供應商文件和 /models 驗證當前的定價和效能聲明。

編碼代理任務	最關鍵的因素	建議評估的模型
自動補全 / 行內建議	低延遲、單次呼叫成本低	DeepSeek V4 Flash, Gemini 3.5 Flash, Laguna XS 2.1
多檔案重構	較大的上下文視窗、強大的程式碼推理能力	Claude Sonnet 5, DeepSeek V4 Pro
測試生成	一致的格式、中等推理能力	Kimi K2.7 Code, Claude Sonnet 5
程式碼審查 / PR 摘要	強大的推理能力、準確引用 diff 的能力	Claude Sonnet 5, Gemini 3.5 Flash
高流量批次任務（Linting、文件註解）	成本優先於原始效能	GLM-5.2, Qwen3.7 Plus, MiniMax M3
開放權重需求（自託管或授權限制）	開放權重、可在託管 API 之外部署	GLM-5.2, DeepSeek V4 Pro, DeepSeek V4 Flash, Qwen3.7 Plus, Kimi K2.7 Code

建立路由邏輯本身的實用檢查清單：

1. 目錄條目是否包含狀態欄位，以便您能在呼叫失敗前偵測到棄用？
2. 目錄是否將具備編碼能力的模型與通用文字或影像模型分開，以便篩選時無需依賴寫死的清單？
3. 您是否能為每種任務類型設定成本上限，並讓代理程式選擇符合該上限的最便宜模型，而不是總是預設使用最強大（也最昂貴）的選項？
4. 是否為每個任務類別定義了備用模型，以防首選模型不可用或受到速率限制？
5. 您是否按排程重新檢查目錄，而不僅僅是在首次整合時檢查，因為模型陣容會隨時間變更？

TokenLab 在此工作流程中的角色

TokenLab 維護著一個模型資料中心（位於 /models/data）和一個模型目錄（位於 /models），截至 2026-07-14 皆為有效。請檢查這些介面以獲取當前模型清單，而非依賴任何靜態文章。模型目錄本質上具有時效性。TokenLab 的 API 文件（位於 https://docs.tokenlab.sh）是整合前驗證確切請求和回應 schema 的地方。

您可以建立一個在多個模型之間進行路由的編碼代理。將 Claude Sonnet 5 用於審查任務，將 DeepSeek V4 Flash 用於低成本高流量補全，並將 Kimi K2.7 Code 用於測試生成。將模型識別碼視為變數，在請求時對照目錄進行解析，而不是將其作為編譯進代理原始碼的常數。實際步驟是檢查 /models/data，並根據 TokenLab API 文件確認您的 MCP 客戶端所需的請求格式。確認無誤後，再將路由邏輯寫入生產環境。

限制

本文描述了 MCP 模型目錄和編碼代理路由的一般模式。它並不保證任何特定供應商（包括 TokenLab）會在上述結構中精確公開所有描述的欄位（上下文視窗、成本欄位、狀態、任務標籤）。Schema、欄位名稱和可用模型變動頻繁。請將本文中的 JSON 範例視為 MCP 一般請求與回應模式的說明，而非任何即時端點的驗證 schema。在發布前，請務必根據供應商的當前文件和 /models/data 確認確切的模型識別碼、定價和上下文視窗。

常見問題 (FAQ)

MCP 本身是否定義了標準的模型目錄 schema？

MCP 定義了透過 JSON-RPC 傳輸資源和工具的一般模式，但模型目錄中的確切欄位（定價、上下文視窗、狀態）取決於實作 MCP 的伺服器如何選擇公開這些資料。請與您整合的伺服器或供應商確認具體的 schema。

編碼代理是否應該總是使用當前最強大的模型？

不一定。像自動補全這樣的任務對延遲和成本敏感，而多檔案重構則受益於更強的推理能力和更大的上下文視窗。一個帶有任務標籤和成本欄位的目錄，讓您可以按任務進行路由，而不是對所有任務預設使用同一個模型。

我應該多久重新檢查一次代理程式所依賴的模型目錄？

模型陣容變動頻繁，單次整合是不夠的。請將您的路由邏輯設計為查詢目錄，而不是永久快取模型識別碼，並按排程檢查 /models/data 或供應商的文件。

請先查看 /models/data 的當前清單，並在將路由邏輯寫入生產環境前，根據 TokenLab API 文件確認您的 MCP 客戶端所需的請求格式，即可開始著手開發。