别再凭排行榜选模型：OpenRouter 的 spawn-ori-eval 在做什么

模型越来越多，选型却常常很随意：看一眼排行榜，刷几条社交媒体测评，再挑一个最近最火的模型接进项目。

这套办法适合尝鲜，不适合生产环境。通用 Benchmark 测的是固定题目，与你的 Prompt、工具、数据和业务规则往往不是一回事。一个模型在公开榜单上领先，不代表它能正确处理退款流程，也不代表它写 Code Review 时误报更少。

OpenRouter 的 spawn-ori-eval 想解决的就是这个问题：别问「哪个模型最强」，改问「哪个模型最适合我的项目」。

它不是评测网站，而是一份给智能体的操作手册

spawn-ori-eval 是一份 Skill，主要给 Codex、Claude Code、Cursor、OpenCode 等编码智能体读取。当前智能体按照这份说明启动 OpenRouter 的 Ori，再由 Ori 为项目生成一套临时模型评测。

这几个词可以直接拆开理解：

• • spawn：启动一个新的执行过程；
• • Ori：OpenRouter 的智能体运行与评测工具；
• • eval：evaluation，也就是评测。

所以它不是新模型，也不是另一个公开排行榜。更准确地说，它是一套自动搭建「项目专属模型选型实验」的流程。官方 Skill 还固定了执行模型和评审模型，让不同编码工具启动的评测尽量使用同一套环境。当前版本固定为 openai/gpt-5.6-terra。

一次评测会做什么

完整流程可以压缩成五步。

1. 找到项目里的 AI 功能

Ori 会检查模型调用代码、System Prompt、工具定义、测试数据、聊天记录和已有错误案例。它要找的不是几道通用题，而是项目真正需要模型完成的任务。

项目用什么语言并不重要。最终评测文件使用 TypeScript，只是因为 Ori 用 Bun 执行 *.eval.ts，被测业务可以是 Python、Go、Java、Rust 或其他技术栈。

2. 让人来定义「什么叫好」

系统会询问评测对象、真实数据、质量要求、预算、候选模型和当前基线模型。官方流程通常会提出五到六个问题，而且一次只问一个。

这一步不能交给 AI 猜。客服机器人的重点可能是不能违规退款；数据提取任务可能要求 JSON 零格式错误；Code Review Agent 更在意真实 Bug 的召回率和误报率。标准不同，赢家自然不同。

3. 自动生成 Eval

假设客服 Agent 收到一句：「客户要求退款，订单号是 #1234。」评测可能检查：

run.tool("lookup_order").toBeCalled();
run.tool("refund").toNotBeCalled();
run.toCostAtMost(0.01);
run.toFinishWithin(30_000);

它看的不只是最终回复，还包括模型有没有调用正确工具、是否跳过必要步骤、是否超时，以及单次费用有没有越线。

对于客服回复、总结、方案分析等没有唯一答案的任务，Ori 可以用独立的 LLM Judge 按 Rubric 打分。这里要保持警惕：Judge 依然会有风格偏好，两个非常接近的小数分差不值得当成确定结论。

4. 让候选模型做同一批任务

Ori 会根据上下文长度、输入类型、价格等要求挑选候选模型，并在同一套测试上横向比较。最终结果不只包含通过率，还会给出延迟和费用。

真正有用的结论通常不是「模型 A 更聪明」，而是下面这种：

模型 A 的质量最高，适合高风险任务；模型 C 的通过率略低，但费用只有一半，适合高频、低风险请求。

这才是生产系统需要的答案。

5. 决定要不要留下这套评测

spawn-ori-eval 默认把文件放在项目外的临时工作区，不直接修改仓库。看到结果后，如果测试确实有用，再把它移进项目、纳入版本控制或接入 CI。

它尤其适合把线上 Bug 固化成回归测试。比如 Agent 曾经没查订单就直接退款，这次事故可以变成一条永久断言。以后更换模型、调整 Prompt 或新增工具，都要重新通过它。

它适合谁

如果项目已经有真实用户、线上失败案例、工具调用或明显的 API 成本，spawn-ori-eval 值得试。典型场景包括客服 Agent、Code Review、RAG、SQL Agent、文档提取、内容审核和自动化办公。

只有几个 Prompt 的 Demo 没必要上这套流程。没有真实样本，也说不清成功标准时，自动评测只会产出一张看起来很专业、实际上没什么用的表。

使用前要知道的风险

第一，「最佳模型」只在当前测试条件下成立。样本偏了、Rubric 写错了，评测越自动化，错误结论反而越像真的。

第二，它会产生真实费用。候选模型数、样本数、重复次数和 Judge 调用会一起放大开销。官方 Skill 明确提示，一次流程可能需要 10～30 分钟，并可能消耗超过 API Key 当前余额的费用。先用少量关键案例试跑更稳妥。

第三，项目内容可能被发送给不同模型供应商。真实聊天记录、客户信息、内部代码和密钥不能直接拿去跑。至少要先脱敏、删除 Secret，并检查供应商的数据策略。

第四，下面这种命令读取的是服务器当下返回的远程说明：

curl -fsSL https://openrouter.ai/skills/spawn-ori-eval

远程内容可能变化，也可能触发安装脚本。对高权限机器和敏感项目，更稳妥的做法是先审查 Skill，固定到具体 Git Commit，再放进隔离环境运行。

最后怎么评价它

spawn-ori-eval 自动化的是评测工程，不是「什么叫好」这个判断。

它最有价值的地方，不是替你跑几个新模型，而是把真实任务、业务断言、质量评分、费用和延迟放进同一套实验。只要测试集来自真实场景，团队就能少靠印象选模型，也能在模型升级或 Prompt 改动时更早发现退化。

反过来，如果输入的是几条随手编的案例和含糊的评分标准，Ori 只会更快地给出一个不可靠答案。

我的判断：实用性高，成熟度中等。对于已经进入生产阶段的 Agent 项目，它值得试；对于简单 Demo，明显偏重。

参考资料

• • OpenRouter：spawn-ori-eval Skill
• • OpenRouterTeam/skills：spawn-ori-eval 源文件
• • OpenRouter：Ori Eval 官方说明
• • OpenRouter：Ori Eval 发布文章