comet eval ... --html 会生成可浏览报告。用户不需要逐行读底层日志，先看结果、归因和产物，再决定下一步。
报告位置
--html 会要求报告同时产出 markdown 和 HTML。CLI 输出里会包含 Experiment 和 Report path，常见位置：
<experiment-id> 的实际格式是 <experiment_name>_<YYYYMMDD_HHMMSS>，例如 authoring_skill_smoke_20260625_143000。experiment name 来自第一个参数化测试的 task name（- 转 _，没有测试时默认 experiment）。
如果 CLI 输出里显示的是占位符，用同一段输出里的 Experiment 值对应查找即可。到下面目录查也能找到对应实验：
报告目录结构
.comet/eval/runs/<experiment-id>/
summary.md
summary.html
metadata.json
events/
raw/
reports/
artifacts/
reports/<treatment>_rep<n>_report.json：每次运行的完整结果，含passed、checks_passed[]、checks_failed[]、events_summary（tokens/cost/skills_invoked/failure_attribution）。metadata.json：experiment_id、started_at、completed_at、total_runs、total_passed、treatments[]、report_outputs。
优先看什么
打开报告后，优先看这几类信息，而不是逐行读底层日志：- 评估是否通过（summary 顶部 / CLI 输出）
- 失败归因是 harness、workflow、task 还是 model
- 失败用例是否和 Skill 目标相关
- 是否缺少预期 artifact（硬校验）
- 是否是路径、manifest 或环境问题
- token / cost / duration 是否异常
先看 summary，再查单次 report，最后用 failure attribution 决定下一步
失败归因
comet eval ... --html 的输出会提示 failure attribution：报告会把失败归到 harness、workflow、task、model 四个桶里。归因逻辑按顺序判断：
Rubric 评分（信息性）
报告里会有[RUBRIC] <dim>: <score> - <reason> 行和汇总的 RubricAvg 列。这是信息性评分，不直接决定通过与否。不同 profile 的维度：
summary.md 里的 rubric 列
Results 表每个 treatment 一行，列顺序是：Checks → 各 rubric 维度列 → RubricAvg → Turns/Duration/Tools/Tokens/Cost。
- 维度列：单次运行显示该维度分（0.00–1.00）；多次运行（reps）显示均值。
- RubricAvg：该次运行所有维度分（含
weighted_score行）的简单均分——是横向快速对比的汇总，和单 rubric 用各自权重算的weighted_score算法不同。 - weighted_score：rubric 自己输出的加权总分（
Σ(维度分×权重)/Σ(权重)），作为一列出现。
reps > 1 时的聚合
用了--count N 重复运行时，summary 会多一个 “Aggregated by Treatment” 表：Reps Passed（通过的重复数）、Checks、Avg Turns/Duration、Tokens、Cost、Skills、Scripts。每个重复的通过/失败（零 checks_failed 即通过）汇总后用于算 pass@k。
Rubric 是诊断工具，不是通过条件
。真正的通过/失败由校验器（expected artifacts、test_scripts）和”required skill
是否被调用”决定。Rubric 分低但 check 全过，仍然算通过。
pass@k / pass^k（对比报告）
pass@k / pass^k 不在summary.md，而在对比报告（comparison_report.md，由 compare_baselines.py 产出）的 ## pass@k / pass^k — capability vs reliability 章节：
- pass@k：k 次里至少成功一次的概率（能力上限）
- pass^k：k 次全部成功的概率（可靠性下限）
- gap（pass@k − pass^k）：不稳定性——能做但不能保证每次都做对
--count）才有意义；单次运行只能算 k=1。完整的公式、含义和对比表的读法见评分指标与双 Agent 评测。
如何决定下一步
失败时怎么判断是哪个环节
collect 失败
优先检查：- manifest 路径是否正确
comet/eval.yaml是否存在- manifest 里推荐的 task 是否存在
- 当前是否在 Comet 仓库根目录或传了正确
--project
run 失败
优先看报告里的 failure attribution，按上面的桶定位。再看reports/<treatment>_rep<n>_report.json 里的 events_summary：
skills_invoked为空 → harness 归因，Skill 没跑起来files_created缺少 expected artifact → Skill 没产出预期文件total_tokens异常低 → 可能 Skill 提前终止
评估”瞬间通过”
几乎肯定是环境没准备好导致 suite 被跳过。检查 Docker、模型凭证和选定的 Agent CLI。HTML 报告没找到
先看 CLI 输出的Experiment 和 Report path。如果路径里有占位符，用实际 experiment id 到 .comet/eval/runs/ 目录查。
报告如何进入发布
不要手工编辑 Bundle 状态，也不要手工把报告路径写进内部 JSON。让/comet-any 或 Bundle 后端记录 eval 结果，并让 comet creator status 读取 readiness。
Eval 证据进入 readiness 的规则：
下一步
- Runtime check — 区分
comet eval和comet skill check - comet eval 命令 — 完整选项和子命令参考
- 发布和分发 Skill — eval 证据如何驱动 readiness