跳到正文
OpenRouter Blog·· 2026-08-25精选AI 评分60

OpenRouter 教你如何在编辑器内用 MCP 选出最合适的 AI 模型

How to Choose the Best AI Model (Live, in Your Editor)

AI 导读

OpenRouter 发布教程,提出按任务定义、实时用量与基准筛选、跨供应商比价、再用自有提示词实测的六步选型框架,并强调应以每完成一次任务的成本而非每 token 价格作为判断标准。

推荐理由

OpenRouter 给出了一套从任务定义到按任务成本核算的选型流程,并说明如何通过 MCP 在编辑器内直接调用实时数据。

正文 · AI 翻译

要选择 AI 模型,先定义任务,从实时使用数据和基准数据中筛选候选模型,比较各提供商的价格和延迟,然后用你自己的提示词测试入围模型。评判标准应是每完成一项任务的成本,而非每 token 的成本,并且要预期答案会随着新模型的发布而变化。

我们不会指定某一个最佳模型。我们写出的任何名字一个月内就会过时,而且正确的模型取决于你在构建什么,以及你愿意为正确结果付出多少。

本文描述了我们用来回答这个问题的框架,以及如何在不离开编辑器的情况下运行它。我们的 MCP 服务器将你的助手连接到实时使用排名、第三方基准、各提供商定价,以及一种向候选模型发送测试提示词的方式。

简而言之

  • 最佳意味着你的任务、你每完成一项任务的成本,以及你的延迟预算。排行榜名次不在这三者之列。
  • 用基准来构建候选名单,用你自己的提示词来选出赢家。Ori Eval 可以为你编写并运行这项对比。
  • 通过 MCP 从你的编辑器中查询实时排名和价格,然后用 get-generation 测量每次测试调用的成本。
  • 如果没有模型明显胜出,就用 openrouter/auto-beta 按请求路由,而不是只选一个。

Six-step framework flow: define the task, then shortlist, compare, test, and measure through the OpenRouter MCP server, then decide or route with openrouter/auto-beta

为什么不存在单一的最佳 AI 模型

不存在单一的最佳 AI 模型,只有在给定任务、预算和时刻下的最佳模型。

不同的任务需要不同的优势。摘要和编程对模型的要求不同。信息提取更需要每次调用都返回有效的 JSON,而不是优美的文笔。聊天功能取决于首个 token 到达的速度,这与完整答案的质量是两回事。一个在编程基准上排名第一的模型,在长文档上仍可能表现不佳,而且用于日常提取时成本过高。

一个更有用的问题会包含具体的工作。不要问“什么是最好的 AI 模型”,而要问“从扫描发票中提取行项目的最佳模型是什么”,或者“审查 TypeScript 拉取请求的最佳模型是什么”,或者“总结 90 分钟通话记录的最佳模型是什么”。写出你自己版本的问题,然后根据当前数据而非过时的排名来回答它。

我们的流量显示了答案因任务而异的程度。我们将一部分请求样本归类为 29 种任务类型,并发布其市场份额。仅编程一项就占了其中九种,涵盖代码生成、调试、代码审查、仓库扫描、SQL 工作和 DevOps 配置。这九种并不共享同一个领先者。在截至 2026 年 7 月 25 日的七天窗口内,一个模型在其中八种中领先,而另一个模型在代码审查和安全方面领先。即便在编程领域内,“最适合编程的模型”这个问题也过于宽泛。

基准是过滤器,不是答案

基准有助于将数百个选项缩小到几个你可以认真测试的候选模型。我们会展示来自 Artificial Analysis 和 Design Arena 的第三方评分,以及我们自己的使用数据。

排行榜无法替你做出最终选择。评分有噪声,热门基准会吸引针对性调优,而且它们都没有运行过你的提示词。用排行榜来筛选候选,用你自己的测试来做决定。

不同的任务需要不同的优势。编程需要推理质量和可靠的工具调用。摘要需要大上下文窗口和低输入定价。抽取需要一致遵循 schema,而非流畅度。聊天需要低延迟。视觉需要模型至少能接受图像,这在质量成为考量之前就已缩小了选择范围。

没有哪个模型在所有类别中都领先。为所有任务选择一个模型会产生一个昂贵的默认选项,它在演示中表现良好,但在你实际运行的工作中表现不佳。

设置 OpenRouter MCP 服务器

下面的每一步都通过 MCP 服务器运行,所以请先连接它。

OpenRouter MCP 服务器由我们托管,因此无需在本地安装任何东西。任何 MCP 客户端都可以连接。下面的设置涵盖 Claude Code、Cursor 和 Codex CLI,文档也涵盖 OpenCode 和 Claude Desktop。你只需连接一次,之后你的助手就能拉取实时模型、定价、额度、排名、基准测试和文档,并发送测试提示,而无需你离开编辑器。在选型时使用它。发布时,照常调用 API。

Claude Code:

claude mcp add --transport http openrouter https://mcp.openrouter.ai/mcp
claude mcp login openrouter

你也可以在会话中运行 /mcp,选择 openrouter,然后点击 Authenticate 进行身份验证。

Cursor:将此添加到 ~/.cursor/mcp.json,然后用 cursor-agent mcp list 验证。

{
  "mcpServers": {
    "openrouter": { "url": "https://mcp.openrouter.ai/mcp" }
  }
}

Codex CLI:

codex mcp add openrouter --url https://mcp.openrouter.ai/mcp
codex mcp login openrouter

身份验证只需一步浏览器操作,在三个编辑器中的工作方式相同。在 Cursor 中,它在你首次请求时运行,而不是通过登录命令。未认证的请求会返回 401,从而启动我们的 OAuth 流程,批准屏幕会在你同意之前说明你同意了什么。

The OpenRouter authorization screen for an MCP connection from Claude Code, showing the account, the $10 default credit limit, the key label, and a warning that the request redirects to a local app

我们会生成一个标记为 OpenRouter MCP: <app name> 的密钥,限定于该客户端,有效期为七天,信用额度为 10 美元,你可以在该屏幕上更改(MCP 公告)。该密钥是短期的,默认有上限,你可以随时断开连接,并且可以从你的密钥仪表板撤销。

该流程会重定向到 localhost,这对于像 Claude Code 或 Cursor 这样的桌面客户端来说是正常的,但这意味着我们无法验证哪个本地应用接收了密钥。只有在你刚刚自己发起连接时才批准它。

你将使用的工具

大多数是针对实时数据的只读查询。例外是 send-message、generate-image、transcribe-audio 和 generate-speech,它们会进行计费推理调用,以及 send-feedback,它会对你自己的某个生成结果写入反馈(MCP 文档)。

工具它返回什么
list-task-classifications按任务类型划分的流量份额,以及每类中的领先模型
list-benchmarks来自 Artificial Analysis 和 Design Arena 的第三方评分,可按任务类型筛选
list-daily-model-rankings前 50 个模型的每日 token 总量,用于趋势而非任务适配
list-models / get-model搜索实时目录;获取单个模型的完整详情
list-model-endpoints提供某个模型的所有提供商,包含价格、延迟、吞吐量和数据政策
search-docs在工具内从我们当前文档中获取答案
send-message (计费)在你的提示上运行候选模型。支持 :online、:nitro、:floor、:free
get-generation一次调用的确切成本、token 数量、提供商和延迟

A Claude Code session querying the OpenRouter MCP server for the top code-generation models this week, returning a ranked table of usage and token shares before moving on to per-provider pricing

助手为 code:general_impl 标签调用 list-task-classifications,返回领先模型及其使用量和 token 份额,然后继续到各提供商定价。不涉及浏览器。

选择模型的六步框架

按顺序运行这些步骤。第 2 步到第 5 步各自对应你的助手可以针对实时数据进行的一次特定调用。第 1 步和第 6 步是你的判断:你定义你需要什么,然后决定发布什么。

第 1 步。按你将发布的方式定义任务

从任务开始,而不是从模型名称开始。写下输入、你期望的输出、什么算作好、你的延迟目标,以及在成本和质量冲突时你倾向于哪一边。

最后一项会影响之后的每一步。向客户展示的摘要可以支撑更高的价格。跨一百万条记录的夜间提取任务则可以支撑更低的价格,即使质量有所牺牲,因为数据量主导了账单。说明你正在构建的是哪一种。

第 2 步。从实时数据中筛选候选名单

候选名单来自两个问题:人们在这个任务上使用什么,以及什么在这个任务上得分高?

对于第一个问题,调用 list-task-classifications。它返回我们过去七天窗口内的 29 个任务标签,每个标签都带有其使用份额,以及一个来自真实流量的、服务于该任务的模型排名列表。对于第二个问题,调用 list-benchmarks 并将 task_type 设为 coding、intelligence 或 agentic,它会返回 Artificial Analysis 和 Design Arena 的分数以及定价。这三个类别有意比 29 个流量标签更粗略,这两个调用应当配合使用。基准过滤器会剔除某个宽泛类别中得分低的模型,而流量标签随后会显示人们在该类别中你具体的那部分使用哪些模型。

list-daily-model-rankings 对趋势很有用。默认情况下,它返回整体排名前 50 的模型的每日 token 总量,外加每天一行聚合的 other。你可以按用例类别(如 programming 或 roleplay)、按模态或按工具调用活动来缩小范围,但类别切片来自每周聚合的抽样数据集,所以要把这些总量视为估计值。它告诉你什么在增长,而不是什么在你的任务上表现好。同样的视图可在 openrouter.ai/rankings 查看。

第 3 步。比较成本、提供商和延迟

对每个入围模型,调用 list-model-endpoints。你会得到服务该模型的每个提供商,以及其价格、上下文长度、过去三十分钟的吞吐量和延迟、正常运行时间、量化和支持的参数。同一个模型在不同提供商之间可能在价格、速度和可靠性上存在差异,最好在这里而不是在生产环境中发现这些差异。

当你需要与某人分享时,比较页面会在浏览器中显示同样的数据。

第 4 步。在你自己的数据上测试候选名单

基准测试给了你候选名单,而你自己的提示词做出最终选择。

对你自己实际拥有的工作运行 send-message:真实的工单、真实的文档、真实的 schema,包括那些通常会导致失败的。一个干净的评估集会让每个模型看起来都能胜任,这就是它无法区分它们的原因。

测试时有三个变体会有帮助。:floor 会路由到服务该模型的最便宜提供商,从而降低评估成本。:nitro 会路由到最快的,这是你检查延迟预算的方式。:online 在任务需要当前上下文时添加网络搜索。

注意 :online 的成本。用三种方式运行同一个简单提示词,:floor 花费 $0.0000030,:nitro 花费 $0.0000024,而 :online 花费 $0.0052576。对于单个提示词来说,这大约是普通调用的两千倍,所以要有意使用它,而不是让它一直启用。

用 Ori Eval 让比较可重复

临时测试调用只能回答一次问题。Ori Eval 让这一步可重复。你用平实的语言提出一个问题,例如“什么模型最适合我的支持代理”,你的编码代理会在你的项目中找到测试材料,把评估写成一个 *.eval.ts 文件,运行候选模型,并推荐一个模型,同时给出其背后的分数、耗时和成本。要从编辑器中启动它,请给你的编码代理这条指令:

run curl -fsSL https://openrouter.ai/skills/spawn-ori-eval and follow the instructions in its output to get started

Ori 在一次运行中确定一个 harness 和一个模型,并在该次运行的每个测试中保持不变,因此同一组评估文件的两次运行会使用相同的配置。它通过 OpenRouter 发送请求,因此一次比较可以包含来自多个提供商的模型。上面的指令在临时目录中即可运行。如果你改为运行手动步骤,评估文件会作为普通代码留在你的项目中,你可以在新模型发布时重新运行它们,用 --baseline 与之前的运行进行比较,并按计划在 CI 中运行它们。

第 5 步。衡量每个已完成任务的成本

每次测试调用后,将生成 ID 传给 get-generation。你会得到确切的成本、提示和补全的 token 数量、提供服务的提供商以及延迟。对一组有代表性的提示取平均值,根据任务成功的频率进行调整,并将该数字记录在决策文档中。

有两点需要注意。生成记录在调用返回的瞬间无法查询,因此紧接着进行的查询会返回 404,并在几秒后解析成功。应重试,而不是把第一次 404 当作失败。另外,补全响应已经带有 usage.cost,所以如果你只需要调用的价格,就跳过这次额外的往返。当你还需要提供商、延迟或原生 token 数量时,使用 get-generation。

第 6 步。做出决定,或按请求路由

如果某个模型在你运行的工作中明显胜出,就使用它。

如果结果很接近,如果你的流量混合了多种任务,或者你不想每次有更好的模型发布时都重新审视这个决定,就使用模型字符串 openrouter/auto-beta 指向 Auto Router。较旧的 openrouter/auto 仍可解析,但已被记录为弃用,因此请使用当前的版本。

路由器不是随机选择的。它将每个请求分类为大约 30 种细粒度任务类型,根据过去七天窗口内的真实支出份额对候选模型进行排名,应用你的成本和质量偏好,并使用回退进行路由(Auto Router 文档)。这就是上面的框架,按请求运行,使用你在第 2 步中查询的相同任务分类数据。

以每个任务的成本思考,而不是每个 token 的成本

比较模型经济性时,正确的单位是每个任务的成本,而不是每个 token 的成本。

人们按每个 token 的价格进行比较,是因为这样容易比较,而且过去很难衡量完全加载后的成本。有了 get-generation 在每次调用时返回真实数字,这种困难就不复存在了。

当模型重试、产生的补全内容超出你的 token 预算,或者需要更强的模型在其后兜底以捕获其失败时,单位价格低的模型就不再便宜。一个更昂贵但能在第一次尝试就完成任务的模型,总成本往往更低。

2026 年一项关于推理模型定价的研究对此进行了测量。在 32% 的模型配对比较中,标价更低的模型反而产生了更高的总成本,极端情况下这种反转高达 28 倍(Chen 等人,《价格反转现象》)。作者将其归因于不同模型在思考上花费 token 的方式差异巨大:同一个查询,一个模型可能比另一个多用 900% 的 token,而单个查询的重复运行差异可高达 9.7 倍。标价完全反映不出这些。

cost per task = ((input tokens × input price) + (output tokens × output price)) × expected attempts

大多数比较都忽略了预期尝试次数,而这一项通常决定了结果。

以下是使用真实价格进行的计算,核对日期为 2026 年 7 月 27 日。GPT-5.4 mini 标价为每百万输入 token 0.75 美元、每百万输出 token 4.50 美元。Claude Sonnet 5 标价为 2.00 美元和 10.00 美元,大约贵 2.4 倍。假设一个任务有 2,000 个输入 token 和 800 个输出 token。如果 Sonnet 5 有 95% 的概率首次尝试即成功,那么每完成一千个任务约花费 12.63 美元。要让 mini 与之持平,它首次尝试的成功率必须达到 40%。低于 40%,这个每 token 便宜 2.4 倍的模型反而是完成工作更昂贵的方式。

当你向他人报告这一点时,请使用每完成 1,000 个任务的成本。token 最便宜的模型往往不是完成工作最便宜的方式。

下图绘制的是整条曲线,而不是单个点。曲线是更值得保留的东西,因为盈亏平衡点会随着你所比较的两个候选模型之间的价格差距而移动。差距越大,较便宜的模型在落败前能容忍的成功率就越低。

Chart of cost per 1,000 completed tasks against first-try success rate, showing the break-even point at 40% where GPT-5.4 mini's per-token savings are erased against Claude Sonnet 5 held at 95% success

同一个计算示例,绘制在所有成功率上而非单一成功率。Sonnet 5 固定为 95% 作为参照,而 mini 的成功率则变化。标价截至 2026 年 7 月 27 日,任务为 2,000 个输入和 800 个输出 token,成功率是被扫描的变量,而非我们测量得到的任何东西。

逐任务优化什么

这是一个起点,而非排名。每一行告诉你该优化什么以及该调用哪个,实时数据提供名称。我们不公布赢家,因为任何赢家名单到下一次发布时就会过时。

任务优化目标如何筛选
编程推理质量、工具调用可靠性,然后是延迟用 list-benchmarks 配合 task_type=coding,并与 list-task-classifications 中的 code: 标签交叉核对
摘要与长上下文上下文窗口和输入价格,这两者主导账单用 list-model-endpoints 查看上下文长度和提示定价
结构化提取模式遵循以及每次调用都返回有效 JSON用 list-model-endpoints 查看支持的参数,然后用 send-message 对照你的真实模式
聊天与助手延迟优先,然后是质量用 list-model-endpoints 查看提供商延迟和吞吐量;用 :nitro 测试
视觉与多模态图像输入支持,然后是领域契合度用 list-models 按输入模态筛选,然后用你自己的图像
智能体工具使用跨多步的指令遵循用 list-benchmarks 配合 task_type=agentic,然后进行多步测试

编程:先确定你指的是哪种编程。我们的任务标签将代码生成与调试、审查、前端和仓库扫描区分开来,而各自的领先者不同。用你待办事项中的真实工单测试候选模型,而不是玩具问题。

摘要:把输入价格和上下文长度放在一起看,因为只看其中任何一个都会误导你。一个窗口大但更便宜的模型,往往胜过输入定价高的更强模型。

提取:一个每次都能返回有效 JSON 的较小模型,胜过一天两次弄坏某个字段的更强模型。测试那些困难输入:缺失字段、模糊记录和格式错误的源文本。

视觉:多模态质量因领域差异很大,所以先按图像输入筛选,然后跑你自己的截图。一套现成的演示集会让每个候选模型都显得不错。

在每种情况下,都运行查询,查看本周的数据,然后从中挑选。

为什么通过 OpenRouter 运行这个循环

你完全不必只锁定一个模型。

一次集成就能让你获得跨提供商的整个目录。当下个月发布更好的模型时,你只需更改一个模型字符串,而无需集成另一个 SDK 并重新测试集成路径。选择和执行位于同一平台,借助 MCP,选择数据在你已经使用的编辑器中即可获取。你还能获得提供商冗余和自动回退,以及精确到足以让上述每任务成本计算准确而非估算的每请求成本数字。

如果你确定只想要来自某一个地方的某一个模型,而且这不会改变,那么直接对接提供商是合理的选择。新模型不断发布,所以请考虑你有多确定。

选择模型时的常见错误

大多数糟糕的模型决策源于衡量了错误的东西,或者衡量正确的东西太晚。以下是我们最常见的五个。

把排行榜位置当作生产决策:在公开排行榜上的高排名只能为你赢得入围资格,而不是生产流量。先让你的提示词跑一遍该模型。

按每 token 价格选购:低单价掩盖了重试、长补全和回退。在get-generation告诉你每完成任务的成本之前,你并不知道这个模型的成本。

忽视上下文形态:既要检查上下文长度,也要检查在该长度下的费用。长上下文模型能力强但也昂贵。使用能完成任务的最小可靠上下文策略,并在考虑更大窗口之前先考虑检索。

选一次就不再重新评估:一月份最适合你任务的模型,到七月份就不会是最适合的。在截至 2026 年 7 月 27 日的三十天里,我们新增了约 40 个模型,所以在你的类别中有任何重大发布后,都要重新运行这六个步骤,在你的仓库中保留一个 Ori 评估并按计划重新运行,或者把问题交给 Auto Router。

把延迟和可靠性留到上线时才考虑:检查list-model-endpoints中的延迟、吞吐量和正常运行时间数据,然后按生产环境的方式演练该端点。上线后才发现提供商不可靠,是可以避免的事故。

为任务而选择,然后让选择保持最新

正确的问题不是哪个模型最好,而是哪个模型最适合你正在构建的东西、在你的预算下、此时此刻。

有了清晰的任务定义、实时数据和一组真实提示词,你可以在一个下午内回答这个问题,并在情况变化时用几分钟重新回答。

  • 最好是与任务相关且与时间相关的。评判标准是每完成任务的成本和延迟,而不是排名。
  • 基准测试构建入围名单,你自己的数据选出赢家。send-message和get-generation来定夺。
  • 一旦连接了 MCP 服务器,整个循环都可以从你的编辑器中运行。

添加 OpenRouter MCP server,让你的助手为你本周要交付的工作筛选并报价候选模型。如果你还没决定,或者要处理多种任务,就使用带 openrouter/auto-beta 的 Auto Router,让它按请求逐一选择。

常见问题

如何选择最佳的 AI 模型?

精确界定任务,根据实时使用数据和基准数据筛选候选模型,比较每个模型在各服务商处的价格和延迟,然后用自己的提示词测试入围模型。评判胜出者时,要看每完成一个任务的成本,而不是每 token 的成本。在 OpenRouter 上,你可以通过 MCP server 在编辑器里完成上述每一步。

最适合编程的 AI 模型是哪个?

没有固定答案,而且编程并不是单一任务。我们把编程流量分为九个独立标签,涵盖代码生成、调试、文件 I/O、shell 执行、代码审查与安全、前端与 UI、仓库扫描、SQL 与数据库工作,以及 DevOps 配置,而在这些类别中领先的模型并不相同。用 list-benchmarks 结合 task_type=coding 来筛选,用 list-task-classifications 对照真实流量进行交叉验证,然后用你自己待办列表中的真实工单测试候选模型。

什么是 OpenRouter MCP server?

它是由我们托管的远程 MCP server,无需在本地安装任何东西。连接后,你的 AI 助手可以查询实时模型数据、各服务商定价、使用量排名、第三方基准和文档,并向候选模型发送测试消息,全程无需离开你的编辑器。任何 MCP 客户端都可以连接。我们提供了 Claude Code、Codex CLI、OpenCode、Cursor CLI 和 Claude Desktop 的设置文档。

如何在 Claude Code 或 Cursor 中设置 OpenRouter MCP server?

在 Claude Code 中,运行 claude mcp add --transport http openrouter https://mcp.openrouter.ai/mcp,然后运行 claude mcp login openrouter。在 Cursor 中,将 server URL 添加到 ~/.cursor/mcp.json,并用 cursor-agent mcp list 验证。身份验证只需在浏览器中完成一步,之后我们会生成一个专用 API key,有效期为七天,消费上限为 $10。

每 token 成本和每任务成本有什么区别?

每 token 成本是输入和输出所标示的单价。每任务成本是获得一个成功结果所需的成本,其中包括重试、更长的补全,以及任何回退到更强模型的情况。token 价格更低的模型,每完成一个任务的成本可能更高。get-generation 会返回每次调用的实际成本和 token 数量,因此你可以测量,而不是估算。

如何比较 AI 模型?

同时从三个维度比较:在你的任务上的质量、每完成一个任务的成本,以及延迟。使用第三方基准来建立候选名单,用 list-model-endpoints 比较每个模型在各服务商处的价格、延迟和吞吐量,再用你自己的提示词做最终选择。并排比较的网页视图位于 openrouter.ai/compare。

我应该多久重新评估一次模型选择?

在你的任务类别中有任何重大发布后,或者每当成本、延迟或失败率出现漂移时,就重新运行这套框架。在截至 2026 年 7 月 27 日的三十天里,我们新增了约 40 个模型,所以要把模型选择当作一项运营决策,而不是一次性的设置步骤。如果你不想跟踪这种节奏,就改用 Auto Router 按请求进行路由。

如何让模型评估可重复?

使用 Ori Eval。你用平实的语言提出一个问题,你的编码代理会在你的项目中找到测试材料,将评估写成一个 *.eval.ts 文件,通过 OpenRouter 运行候选模型,并推荐一个模型,同时给出其背后的分数、时间和成本。评估文件就是普通的代码,因此当有新模型发布时,你可以重新运行它们,用 --baseline 比较各次运行,并按计划在 CI 中运行它们。

我应该使用一个模型还是在多个模型之间路由?

当任务范围狭窄、提示词稳定,且有一个候选模型能以明显优势通过你的评估时,使用一个模型。当请求的复杂度各不相同、可靠性比模型的一致性更重要,或者你不想在每个发布周期都重新审视这个决定时,就进行路由。Auto Router 将每个请求分类为大约 30 种任务类型,并根据社区在过去七天窗口内的支出份额,为每个请求进行选择。

参考资料

本页面上的每一项陈述都已对照这些来源进行核实,包括实时 API 调用。

来源:OpenRouter Blog · openrouter.ai