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

退出码

默认情况下,只要存在失败的 gate,NiceEval 将以非零状态码退出。CI 中通常使用 --strict,让失败更明确。
CI profile 不输出 ANSI、spinner 或动态表格。日志使用单一有序 stdout 流,只追加 start、低频 heartbeat、失败/错误、diagnostic 和最终 result;通过的 Attempt 不逐条打印。

GitHub Actions 示例

配置 secrets

1

在仓库中添加 secrets

把 provider token 放进 GitHub Actions secrets。
2

在 workflow 中传入 env

只在运行评估用例的 step 暴露必要环境变量。
3

验证变量存在

用最小评估用例或 list / dry run 先验证配置。

JSON、JUnit 和结构化错误

退出码是第一层红绿信号;JSON、JUnit 和结果快照是完整机器接口,日志行只用于搜索和 annotation。errored 行带 locator、eval/experiment 身份、已知时的正式 phase,以及一层 reason 摘要。详细 cause、stack 和 diagnostics 保存在 Attempt 的 result.json,可在保留 artifact 后运行 niceeval show @<locator> 回顾。 CLI 显式要求的 JSON/JUnit 和默认 results artifact 都是 required 输出:写入失败必须让 job 判红,不能只留 warning 后退出 0。把结果同时上报到 Braintrust 等实验平台的配置见 Reporter 上报

只检查发现

适合快速验证评估用例文件能加载、配置没有明显错误。

缓存 .niceeval/

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

控制并发

标准 GitHub-hosted runner 上,Sandbox 评估用例并发不宜过高。远程 HTTP 评估用例可以按服务限流能力调高。

推荐模式

PR runs

只跑关键评估用例和高风险路径,保持反馈快。

Nightly 全量矩阵运行

运行完整 experiment,记录 pass rate、成本和延迟趋势。
跑出来的结果要发布成静态报告站(Vercel / GitHub Pages 自动更新),见通过 CI 发布报告