面向 Coding Agents 的 MCP 模型目录：让模型选择实现机器可读

面向编程智能体的 MCP 模型目录是一个结构化的、可查询的可用模型列表。智能体可以通过 Model Context Protocol (MCP) 读取该列表，而无需依赖硬编码在源代码中的模型名称。它允许智能体、IDE 插件或编排层在运行时根据任务类型、上下文窗口或成本上限来选择模型，而不是使用开发者半年前输入且早已忘记更新的字符串。

这一点的重要性超乎想象。编程智能体会频繁调用模型，用于自动补全、多文件重构、测试生成、提交信息起草等。每一项任务都有其理想的模型。如果智能体无法发现有哪些模型存在以及它们擅长什么，那么每当提供商发布新版本时，就必须有人不断地去修改配置文件。本文将探讨模型目录条目应包含的内容、MCP 风格的目录请求格式，以及如何决定将哪些模型路由到哪些编程任务。

关键要点

• 模型目录将模型选择从硬编码字符串转变为运行时查找，从而降低了提供商发布新模型时的维护负担。
• 编程智能体通过将不同任务类型（自动补全、重构、测试生成、审查）路由到不同的模型，而非对所有任务使用同一个模型，能从中获益。
• 针对模型目录数据的 MCP 请求通常遵循 resource-list 或 tool-call 格式；在基于其构建之前，应根据提供商自己的文档验证确切的 schema。
• TokenLab 在 /models/data 发布了模型数据中心，并在 /models 发布了模型目录；请将这些地方作为核实当前模型名称的权威来源，而非本文，因为模型阵容更新频繁。

为什么编程智能体需要机器可读的模型数据

大多数编程智能体集成的工作方式仍与十年前的 API 集成无异：开发者选择一个模型名称，将其粘贴到配置或环境变量中，然后发布。这种方式在提供商弃用模型、更改定价或发布团队无法及时采用的更好选项之前，一直有效。

机器可读的目录改变了这种故障模式。当模型退役时，智能体不会静默崩溃，而是可以查询目录，发现模型已消失或被标记为弃用，并回退到已记录的替代方案。开发者无需手动对每个新版本进行基准测试，智能体（或开发者的工具）可以在切换前比较列出的上下文窗口、模态支持和成本字段。

p>

这也是任何严肃的模型路由策略的先决条件。如果你想将廉价、高频的补全任务发送给 DeepSeek V4 Flash 或 Gemini 3.5 Flash 等低成本模型，并为多文件重构保留 Claude Sonnet 5 等更强大的模型，路由逻辑就需要一个关于哪些模型是当前可用、成本多少以及支持什么的“事实来源”。没有这些，路由规则就会像硬编码的模型名称一样失效。

TokenLab 曾直接探讨过这个问题，旨在让模型信息成为智能体可以信任的内容，而不是人类必须手动重新核实的内容。请参阅 agent-readable model truth 以了解关于智能体可读模型事实的更广泛论点，以及 agent-first API 以了解当主要调用者是智能体而非人类开发者时，API 设计将如何改变。

MCP 模型目录条目应包含的内容

对于编程智能体而言，一个有用的目录条目需要的不仅仅是模型名称。开发者在构建或使用目录时，至少应期望看到：

• 模型标识符：API 期望的精确字符串，因为提供商通常会精确地对名称进行版本控制（此处的不匹配是集成中最常见的 Bug 之一）。
• 提供商：由哪家公司或平台提供该模型，在目录聚合多个提供商时非常重要。
• 模态支持：文本、代码、图像或视频。当目录混合了 Kimi K2.7 Code 等编程模型和 Nano Banana Pro 等图像模型时，需要一个字段让智能体根据其实际需求进行过滤。
• 上下文窗口：对于在大型代码库中工作的编程智能体，token 限制至关重要。
• 成本字段：输入和输出 token 定价，最好分开列出，因为编程智能体通常具有非对称的输入密集型工作负载（大文件上下文、小 diff 输出）。
• 状态：当前、已弃用或计划退役。这是防止静默崩溃的关键字段。
• 任务适用性标签：可选但有用的元数据，如“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 维护着一个模型数据中心（/models/data）和一个模型目录（/models），截至 2026-07-14 可见。这些是核实当前模型列表的场所，而不是依赖任何静态文章，因为模型目录本质上是具有时效性的。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 核实确切的模型标识符、定价和上下文窗口。

常见问题解答

MCP 本身是否定义了标准的模型目录 schema？ MCP 定义了通过 JSON-RPC 进行资源和工具交互的通用模式，但模型目录中的确切字段（定价、上下文窗口、状态）取决于实现 MCP 的服务器选择如何公开该数据。请与你集成的服务器或提供商核实具体 schema。

编程智能体是否应该始终使用最强大的可用模型？ 不一定。自动补全等任务对延迟和成本敏感，而多文件重构则受益于更强的推理能力和更大的上下文。带有任务标签和成本字段的目录允许你按任务进行路由，而不是默认对所有任务使用同一个模型。

我应该多久重新检查一次智能体所依赖的模型目录？ 模型阵容变化频繁，一次性集成是不够的。请将你的路由逻辑构建为查询目录，而不是永久缓存模型标识符，并定期检查 /models/data 或提供商的文档。