OpenRouter Ori 的 eval 与 harness：官方自带的评测这一层管到哪
有个问题在群里被反复问：Ori 到底是个「换凭证的壳」，还是能替我把模型选型这件事做完？这两件事在 OpenRouter 官方文档里是分成两页写的——《Ori Harness》（openrouter.ai/docs/guides/ori/harness）讲前者，《Ori Eval》（openrouter.ai/docs/guides/ori/eval）讲后者。它们共用一个 ori 命令，但管的范围完全不同，混着理解就会在 CI 里踩坑。
这篇只对照这两层：各自把边界划在哪，评测跑完之后文件落到哪几个位置，什么时候这个差异会咬到你。依据只有上面两页加《Where Ori writes files》（openrouter.ai/docs/guides/ori/files）这三页文档，落盘日 2026-08-18。
先说一句关于状态标记的话
这三页文档里，没有给 Ori 标 beta、preview、experimental 或 deprecated 中的任何一个字。我们逐页检索过，检索不到，所以也不替它标。
能核到的只有两处路径事实：安装脚本的地址写在 openrouter.ai/labs/ori/install.sh，配套的 skill 地址写在 openrouter.ai/skills/ 下。这两个路径是文档原文，至于路径里的 labs 是不是意味着什么，文档没有说明，我们不推断。
另外《Ori Harness》页末尾有一句原话，说目前这几个 agent「work today, and more harnesses are coming」。这意味着下面提到的命令清单会变，请以官方文档最新内容为准。
harness 层：换的是凭证和模型来源，不是你的工作方式
《Ori Harness》页开头写明，Ori Harness 跑的是「你已经在用的那个 agent CLI」，你跑一条命令，agent 就带着 OpenRouter 的凭证、模型和设置启动。它的原话是 you don’t change how you work。
文档列出的子命令是这几条：ori claude、ori codex、ori dsh、ori grok、ori hermes、ori opencode、ori pi、ori prime-agent。文档写明每条命令启动的是你机器上真实的那个 agent CLI，Ori 用的是 PATH 上的 CLI，缺了会问你要不要装。
这里有一个唯一的例外必须记住：ori dsh 不启动任何东西。文档写明 DeepSeek Harness 不像其它 CLI 那样有明确的启停，所以 Ori 只做配置——把你的全局 DeepSeek Harness 配置指向 OpenRouter，之后你照常跑 dsh。同样地，ori dsh --model 是设置 dsh 设置里的默认模型，也不启动任何东西。如果你按对待其它几条命令的方式去等一个 agent 被启动起来，你会等空。
凭证这块，文档写明 Ori 用 OAuth PKCE 走浏览器登录，不需要单独准备 API key；也可以先用 ori login 登一次。
ori login
ori claude --model anthropic/claude-sonnet-4.6
ori codex --model google/gemini-3.6-flash --full-auto
上面三条都是文档原样给出的示例，其中的模型 ID 只是官方文档当时写的示例值，平台上有哪些模型随时在变，不要当清单用。文档说明 Ori 自己的 flag 在前，agent 自己的 flag 放后面，Ori 会原样透传给 agent。ori grok 的 --model 则是 Grok Build 自己的 flag，Ori 直接透传。
harness 层还有一处边界值得单独标出来：并不是每个 agent 都有同一套开关。文档写明，对 Pi（ori pi）、Prime Agent（ori prime-agent）和 DeepSeek Harness（ori dsh）三者，Ori 把 agent 接到你自己的 OpenRouter 模型目录上——/model 列表来自你的目录，/fast 打开快速路由（Claude 模型走 Anthropic fast mode，OpenAI 模型走 priority service tier，其余走按吞吐排序的 :nitro），/zdr 则只让请求走不留存数据的 provider。Prime Agent 上要用 /speed 而不是 /fast，因为 Prime Agent 自己已经有一个 /fast。Grok Build 会把同一份目录加载进它自己的模型选择器，所以不需要 grok login，但文档明确写它没有 /fast 和 /zdr 这两个开关。至于剩下几个 agent 有没有这两个开关，文档没有说明这一点。
组织侧的约束是另一件事：文档写明 guardrails、allowlists、按 workspace 的权限以及 workspace 预算是设在 OpenRouter 组织上的，对每一个请求生效，不管是哪个客户端发的，包括通过 Ori 跑的 agent。这一层不属于 Ori，Ori 只是恰好也被它管住。
eval 层：这一层才产出可比较的东西
harness 层跑完不会留下任何「哪个模型更适合我」的结论。要那个结论得走 eval 层。
《Ori Eval》页写明，一次 run 解析出一个 harness 和一个 model，并在这次 run 的每个 test 里都保持住，prompt 改不了它们；因此用同样一批 eval 文件跑两次，用的是同一份配置。文档自述这样做的理由是「一个稳定的测试台是 eval 里最难的部分」。文档另外自述，因为请求走 OpenRouter，一次对比里可以包含多家供应商的模型，而只服务某一家的 harness 只能测那一家的模型。
eval 本身就是一个 *.eval.ts 文件，写起来像普通的 bun test 文件——文档示例里从 bun:test 导入 test，从 ori/eval 导入 setupAgent。断言挂在 run 上：run.tool('search').toBeCalled() 与 toNotBeCalled() 检查工具有没有被调，run.toComplete()、run.toCostAtMost()、run.toFinishWithin()、run.toMention() 分别管完成、成本上限、耗时上限和必须提到的内容。文档示例里给了具体的成本与超时数值，那是示例值不是建议值，这里不抄。
setupAgent() 不带参数时，拿到的就是你 workspace 解析出的那个 harness 和 model——也就是你平时在跑的那个 agent。要做模型横比，文档给的做法是用 candidateModels() 从 OpenRouter 的实时目录取候选，再循环建 test；这个函数还能按 maxCompletionPrice、minContextLength、质量指数、必需参数、输入模态和 excludeExpiring 来筛，文档特别说明：目录里没有给出某个值的模型，过不了对应的那条限制。如果你在文件里写死某个模型 slug，用 assertModelIsLive(slug)，模型离开实时目录时 eval 会带明确信息失败。
开放式回答用 setupJudge()，文档写明它会另起一个跑在自己评分模型上的 agent，所以分数独立于被测模型；judge.autoEvals() 接 criteria 和 run。startingCriteria 里给了六个可以直接改的 rubric：accuracy、completeness、instructionFollowing、safety、structuredOutput、toneAndVoice。
跑完之后，东西落在哪
这是两层最实的差别，也是最容易被忽略的一段。《Where Ori writes files》这一页把落盘位置列全了（表里 history.jsonl 那一行不在这一页上，它写在《Ori Eval》页里）：
| 位置 | 里面是什么 | 文档怎么说 |
|---|---|---|
<cwd>/.ori/ | 从项目里跑 Ori 时创建的工作区目录 | 应加进 .gitignore |
.ori/logs/ | event logs 与 session transcripts | 可能含仓库内容与 prompt 文本，按私有数据对待 |
.ori/eval/history.jsonl | 历次 eval run 的记录，--baseline 靠它比对 | 见《Ori Eval》页 |
~/.ori/ | 跨命令跨 workspace 共享的数据 | 可含模板、依赖、缓存、config.json、telemetry.json |
$TMPDIR/ori-eval-scratch-* 等三类 | eval 命令建的临时工作区 | 一次性，eval 跑完可删 |
/tmp/ori-create-eval-<hash>/ | create-eval 工作流的 run tracker | 工作流还在跑就别删 |
临时工作区那一行文档给的是三个前缀：ori-eval-scratch-*、ori-eval-results-*、ori-eval-sdk-*，里面放 eval 文件、导出数据、报告和安装的依赖。run tracker 里存的是 prompt、步骤进度、回答和错误日志，作用是让工作流能接着跑；文档写明工作流结束且你不再需要这份记录之后再删。
全局目录的取舍文档也写清楚了：模板、依赖、缓存删掉会让 Ori 重新下载；config.json 想保留设置就别删；telemetry.json 只在你不需要本地 telemetry 状态时删。
文档在这一页里直接要求把 .ori/ 加进仓库的 .gitignore，理由它自己写了：logs 里可能有仓库内容和 prompt 文本，要按私有数据对待。同一页还有两条同样是祈使语气的话：正在跑的 run 用到的文件别删；create-eval 的 run tracker 在工作流还活着的时候别删。三条里 .gitignore 那条最容易漏，因为它要你改的是仓库，不是 Ori 自己的目录。这条对 Windows 用户同样成立，.gitignore 是 Git 的事，跟平台无关。
至于 Ori 在 Windows 上把文件写到哪里——这三页没有说明。文档给的是 ~/.ori/、$TMPDIR、/tmp/ 这些类 Unix 写法，安装命令也是 curl -fsSL ... | bash。我们不替它推 Windows 上的对应路径，你在 Windows 上要先确认自己有没有可用的 bash 环境，以及 ori 实际落到了哪。这一点请以官方文档最新内容为准。
两条入口，产物位置不一样
这是本篇最需要你记住的一处。文档给了两条起步路径：
一条是让你的 coding agent 去跑 spawn-ori-eval skill（文档给的指令原文是让 agent run curl -fsSL https://openrouter.ai/skills/spawn-ori-eval and follow the instructions in its output to get started）。文档在一个 Note 里明确写着：这个 skill 在一个临时目录里做事，不会把 eval 文件放进你的项目。
另一条是手动跑：装 CLI、ori login，然后在项目目录里 ori code -p "..."。这条路径下，agent 写出来的是 evals/<feature>/<name>.eval.ts，留在你项目里当普通代码。文档还写明 create-eval skill 默认把新文件放在顶层的 evals/<feature>/ 目录，但 Ori 也能在别的目录找到 eval 文件。
所以「我按文档跑完了，怎么项目里什么都没有」这个疑问，答案通常就在你走的是哪条入口。想把 eval 文件留在仓库里，走手动那条。
ori code 这条命令另有几个硬性约束：-p 和 --prompt-file 不能同时给，没有 flag 直接甩一个 prompt 也会被拒绝；ori code -p 不需要终端，输出写到 stdout，prompt 完成就退出。
决策路径
按你的处境倒推：
- 你只想让现有 agent 用上 OpenRouter 的凭证和模型：只需要 harness 层，
ori <agent>加--model。别期待它给你任何分数，那不是这一层的事。 - 你需要一份能拿给别人看的对比结论：走 eval 层。
ori eval --report <path>写 Markdown 报告，ori eval --baseline last|best|model:<slug>跟历史比。注意文档写明的那条硬约束：只有包含完全相同 eval 文件的两次 run 才能比。你中途加了一个 eval 文件，这次就跟上次比不了了。 - 你想知道某次对比里某个模型为什么没数：文档写明，模型在给出答案之前就停了，报告里会把它标成
unmeasured；报告不会把它从对比里删掉，也不会给它显示成本为零。看到unmeasured就别再去找它的分数了。 - 你要把 eval 挂进 CI：文档明说 eval 会向真实模型发请求、会花钱，所以要放单独的 job，由人触发或按计划跑，不要放进普通单测 job。普通单测 job 里该跑的是
ori eval --list --allow-no-key，这条只找 eval 文件，不需要 key 也不调模型。
CI 里还有两个坑文档直接点了：一是 ori eval 用 Bun 跑 eval 文件，非交互终端或 CI 为 true 时它不会问你要不要装 Bun，只会停下告诉你怎么装——所以 CI 里要自己准备 Bun；二是安装脚本把 ori 放进 $HOME/.local/bin，而这个 PATH 变更只对跑安装脚本的那个 shell 生效，后续步骤要找得到 ori，得把这个目录追加进 $GITHUB_PATH。key 用 OPENROUTER_API_KEY 环境变量传（值放 repository secret，正文里一律写成 <YOUR_API_KEY> 这类占位），有了它就不需要在 CI 里跑 ori login。eval 失败返回非零退出码——文档写明 ori eval 的退出码就是 bun test 的退出码，所以一个变差的 agent 会直接卡住你的发布。
ori eval --list --allow-no-key
ori eval --report eval-report.md
ori eval --baseline best
以上为按官方文档中的参数语义组合的示例，未经实测，以官方文档与 --help 的实际输出为准。
有几个维度我们不比
- 两层各自的运行表现、稳定性、评测结果的可信度：没有依据，不比。
- eval 层给出的推荐质量：需要实际跑过才谈得上，我们没有跑过。
- 两层的成本差异：涉及价格，且随行情变动，不写。
一句实话收尾：harness 层文档里那句 you don’t change how you work 是有代价的对称面——它不改你的工作方式，也就不会替你产出任何可比较的东西。想要结论，只能走 eval 层，并且接受它落一堆文件到 .ori/ 和临时目录里。
本文依据 OpenRouter 官方文档（openrouter.ai/docs）于 2026-08-18 的公开内容整理。
该平台闭源，本文只复述官方文档写明的机制，不推断其内部实现；
我们没有对文中涉及的功能做过实测，因此不涉及界面外观与运行表现的任何描述。
该平台的供应商、模型与路由策略随时变动，文中不列具体供应商名单与模型清单；
价格、额度与限流的具体数值请以官方定价页与用量说明为准。
本文对照的是同一产品内的两种形态，依据均为上述官方文档，不对两种形态做优劣排名， 选型结论只在官方文档写明的能力边界内成立。
安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。