[P0][Eval Reliability] 修复 Live Nightly 全部运行失败仍显示成功，并增加运行有效性闸门

[helsome]

问题

当前 Live Nightly 的 Actions 绿灯不能证明真实 Agent 评测有效。最近这次运行中，所有 case 都在健康检查或模型凭证环节失败，没有完成有效的模型/工具任务，却仍生成一个看似可比较的综合分，并以成功状态结束。

这是评测有效性与失败传播的缺陷；不能据此断言整个 Folio 的 Pi Runtime 无法启动，也不能归因于某个待合并 PR。

审计更正（2026-09-17）

本 Issue 初稿误写了“86/86 PI_EXECUTABLE_NOT_FOUND、根本未启动 Pi”。重新解压并统计同一个原始 artifact 后，确认这一错误码并不存在于产物中。正确结果为 1 条 PI_HEALTH_TIMEOUT + 85 条 PI_RUNTIME_ERROR（No API key found for the selected model.）。这是初稿的事实错误，不是运行环境在两次审查之间发生了变化；以下实证已更正。

当前现状与实证

审查基线：6405b7b9a9aad331dcdb60dc1a7965328a6a6f4a。

实际运行：https://github.com/helsome/folio/actions/runs/35074861257

原始 artifact：10437259480，包含 eval-full.json / eval-full.log。本次重新核对本地 ZIP 的 SHA256 与 GitHub artifact digest 一致：693043414c88b02a2b76ab46051a85e987226b6e86c70596946584465f7faefe。

• Live 模式，86 cases；86 个 run 的 status 均为 failed，0 个 tool call。
• 第一条 error 为 PI_HEALTH_TIMEOUT：Pi health check timed out after 5000ms.。该次健康检查超时的更底层原因尚未确认，不能直接归因为未安装 Pi。
• 其余 85 条 error 为 PI_RUNTIME_ERROR：No API key found for the selected model.。错误同时给出了已解析的 /tmp/bunx-1001-@mariozechner/pi-coding-agent@latest/.../docs/ 路径。
• 这些结果说明本轮所选模型没有获得可用凭证；是否是 Secret 未配置、注入失败或所选 provider 不匹配，需要进一步检查，不能仅凭产物认定具体 Secret 状态。
• Pass rate = 0，但 composite score = 0.5961041146555713；未执行工具时仍取得若干满分的规则指标。
• 日志明确打印 No judge configured ... — deterministic evaluators only.，所以相关 Judge 指标没有得到有效测量。
• Actions 最终 conclusion = success。

涉及代码：

• .github/workflows/eval-nightly.yml：live step 使用 continue-on-error: true，命令经 | tee，未显式配置保留管道失败的 shell；缺少完整的 runtime/model 凭证就绪检查。
• scripts/eval/run.ts：非 baseline 模式下，case 全失败本身并不保证非零退出；live kernel 直接使用 process.env，不能假设会读取开发者桌面端保存的凭证。
• packages/shared/src/evaluation/experiment-service.ts / aggregate：实验完成、测量有效、质量通过需要明确区分。

期待的解决方向

1. 增加最小 live preflight：实际可执行 Pi、所选模型可用、该 suite 要求的数据源与 judge 已就绪；只报告状态，不输出 secret。安装/配置缺失不能继续冒充有效 live suite。
2. 把 execution validity 与 quality score 分开。invalid/inconclusive 不等于模型质量差，也不等于通过；必须显示 requested/started/evaluated/infra-failed/skipped 计数及原因。
3. 没有有效运行时，不输出可被误用为有效 benchmark 的 headline composite / passing baseline；分项诊断可以保留，但必须带 applicability/sample count。
4. CLI 返回可区分的失败状态；workflow 保留真实退出码，移除“失败仍成功”的包装。失败时仍上传日志、JSON 与 summary。
5. 有效质量结果按显式阈值/baseline 决定是否通过；不要把“所有 run 都有记录”当作成功，也不要把所有负向测试一刀切为无效。

验证标准

• focused tests 覆盖：Pi 不存在、所需模型/数据源/必需 judge 不可用、0 个有效 case、部分基础设施失败、有效负向 case；状态与计数准确。
• 用与 workflow 相同的 ... | tee ... shell 路径演示底层失败不会变成 exit 0；失败产物仍上传。
• 缺失条件作为明确失败/不可验收状态出现，不能用整套 skipped 得到 live acceptance 绿灯。
• 至少运行 1 条真实模型 + 正常 Folio Agent/Tool + 成功真实数据源的 smoke，报告命令、Bun/OS、model/provider、query、run/tool id、真实返回摘要、最终答案和产物位置。无需为这个修复重新跑完整 86 条。
• 所需 judge 启用时，真实评分调用有结果；不启用时明确声明未测哪些指标，不能声称 groundedness 已通过。
• PR 提供可复现报告，说明原始基线与修复后状态。

Scope / 所有权

Refs #15、#14、#107；#15 仍由 @xxstar-01 认领，本 Issue 仅拆出 live-run 有效性和 CI 失败传播的维护修复，不替代或关闭 Gold Case 总任务。可与原认领者协调后贡献独立修复。

不要求新 benchmark 平台、多模型大规模跑分、性能优化、额外 UI 或新的调度系统。

[suzhiguo7]

/claim

[github-actions]

@suzhiguo7 已认领该 Issue，并已自动设为 Assignee。提交 PR 时请在描述中写 Closes #113。