跳转到主要内容
Evals 应该和测试一样进入 CI。它们能在 PR 阶段发现 agent 行为回退，也能在 nightly job 中跟踪模型、成本和延迟变化。

​
退出码

默认情况下，只要存在失败的 gate，niceeval 将以非零状态码退出。CI 中通常使用 --strict，让失败更明确。 
npx niceeval exp ci --strict

​
GitHub Actions 示例

name: evals
on:
  pull_request:
  workflow_dispatch:

jobs:
  evals:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npx niceeval exp ci --strict
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

​
配置 secrets

1

在仓库中添加 secrets

把 provider token 放进 GitHub Actions secrets。
2

在 workflow 中传入 env

只在运行 eval 的 step 暴露必要环境变量。
3

验证变量存在

用最小 eval 或 list / dry run 先验证配置。

​
JUnit reporter

import { defineConfig } from "niceeval";
import { Console, JUnit } from "niceeval/reporters";

export default defineConfig({
  reporters: [Console(), JUnit(".niceeval/junit.xml")],
});
CI 可以上传 JUnit XML，让失败出现在测试报告 UI 里。

​
只检查发现

npx niceeval list
适合快速验证 eval 文件能加载、配置没有明显错误。

​
缓存 .niceeval/

可以在 CI 中缓存 .niceeval/，但要确保 fingerprint 覆盖了影响结果的输入。对于 nightly 基准，通常保留完整 artifacts 更有价值。

​
控制并发

npx niceeval exp ci --max-concurrency 2
标准 GitHub-hosted runner 上，sandbox eval 并发不宜过高。远程 HTTP eval 可以按服务限流能力调高。

​
推荐模式

PR runs

只跑关键 eval 和高风险路径，保持反馈快。

Nightly 全量矩阵运行

运行完整 experiment，记录 pass rate、成本和延迟趋势。