面向 Coding Agents 的 MCP 模型目錄：讓模型選擇實現機器可讀

針對編碼代理的 MCP 模型目錄是一個結構化、可查詢的可用模型列表，代理可以透過 Model Context Protocol（模型上下文協議）讀取該列表，而不必依賴硬編碼在原始碼中的模型名稱。這讓代理、IDE 外掛程式或編排層（orchestration layer）能夠在執行時期（runtime），根據任務類型、上下文視窗（context window）或成本上限來選擇模型，而不是使用開發者半年前輸入後就忘記更新的字串。

這件事的重要性超乎想像。編碼代理會不斷呼叫模型，用於自動補全、多檔案重構、測試生成、提交訊息撰寫等。每一項任務都有其理想的模型。如果代理無法發現有哪些模型存在以及它們擅長什麼，那麼每次供應商發布新版本時，就必須有人去修改設定檔。本文將探討模型目錄條目應包含的內容、MCP 風格的目錄請求格式，以及如何決定將哪些模型路由至哪些編碼任務。

重點摘要

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

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

大多數編碼代理的整合方式仍與十年前的 API 整合方式相同：開發者挑選一個模型名稱，將其貼入設定檔或環境變數中，然後發布。這在供應商棄用該模型、更改定價或發布更好的選項（而團隊卻沒有採用流程）之前都能運作。

機器可讀的目錄改變了故障模式。當模型退役時，代理不會默默失效，而是可以查詢目錄，發現模型已移除或標記為棄用，並回退到已記錄的替代方案。開發者也不必手動對每個新版本進行基準測試，代理（或開發者的工具）可以在切換前比較列出的上下文視窗、模態支援和成本欄位。

這也是任何嚴肅的模型路由策略的先決條件。如果您想將廉價、高容量的補全任務發送給低成本模型（如 DeepSeek V4 Flash 或 Gemini 3.5 Flash），並為多檔案重構保留更強大的模型（如 Claude Sonnet 5），路由邏輯就需要一個關於哪些模型是當前可用、成本為何以及支援哪些功能的真理來源。沒有這些，路由規則就會像硬編碼的模型名稱一樣過時。

TokenLab 曾直接探討過這個問題，旨在讓模型資訊成為代理可以信任的內容，而非人類必須手動重新驗證的內容。請參閱 agent-readable model truth 以了解關於代理可讀模型真理的更廣泛論點，以及 agent-first API 以了解當主要呼叫者是代理而非人類開發者時，API 設計將如何改變。

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

對於編碼代理而言，一個有用的目錄條目需要的遠不止模型名稱。開發者在建構或使用目錄時，至少應預期看到：

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

並非所有供應商的目錄格式都保證包含這些欄位。在 建構整合 之前，請檢查您所使用供應商記錄的實際 schema。特別對於 TokenLab 提供的模型，當前的欄位集和更新節奏應在 /models/data 進行驗證，而不應從本文假設，因為隨著新模型和模態的加入，目錄 schema 會有所變動。

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

MCP 通常透過 JSON-RPC 2.0 進行通訊。客戶端請求伺服器列出可用模型資源時，可能會發送如下格式的請求。此範例僅用於說明一般的 MCP 資源列表模式，並非針對任何特定供應商的即時 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、文件註解）	單 token 成本優先於原始能力	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 維護著一個截至 2026-07-14 的模型資料中心（位於 /models/data）和一個模型目錄（位於 /models）。這些是檢查當前模型列表的管道，而非依賴任何靜態文章，因為模型目錄本質上具有時效性。TokenLab 在 https://docs.tokenlab.sh 的 API 文件是整合前驗證確切請求和回應 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 或供應商的文件。