RC1 实验于 2026-08-28 运行。beta16 的 48 个 baseline 样本来自 2026-08-27—28
的已有实验，本次直接复用，没有重跑。两边使用相同的 16 个任务和 3 次重复，但
Native 产物与轨迹检查遵循各自版本的契约。
最终 RC1 分析集是 48 个唯一的
task + run 记录。此前 4 个恢复尝试只产生了 harness_trigger_suspect / exit-125 的 Docker 噪声壳，因此排除；对应缺失 node 已由后续精确补跑替代。不会重复计数。原始 RC1 快照一度记录为 47/48，是因为 parser 把 find ... -path '*/.claude/skills/*' 中的 shell glob 识别成了名为 * 的意外 Skill。修复 parser 后重新读取同一份 raw stdout，显式调用只有 comet-native；因此本文使用校正后的 48/48 分析集，不修改原始快照。实验如何对齐
业务任务和业务验证器保持一致；workflow 检查分别遵循 beta16 和 RC1 的真实 Native 契约。
strict pass 表示业务验证器和对应版本的 Native workflow 检查都通过。业务验证单独列出，避免把 workflow 证据失败误认为代码或任务失败。
核心结果
两边的任务级
pass@3 都是 100%，即 16 个任务都至少成功过一次。RC1 多 2 次 strict pass，并多 2 个任务实现了三次全通过。耗时下降只能视为方向性证据，因为 beta16 使用复用的历史运行，两组样本并非同一时间窗口的受控重跑。
为什么同时看 pass@3 和 pass^3
pass@3 衡量三次尝试中至少一次成功，适合观察能力覆盖；pass^3 衡量三次观察运行全部成功，适合观察重复运行稳定性。
这两个指标区分了“版本能够完成任务”和“版本每次都稳定完成任务”。本次两边都覆盖全部 16 个任务，但 RC1 有 16/16 个任务三次 strict pass，beta16 为 14/16。
完成任务的执行效率
效率主视图只统计两边都 strict pass 的 46 组相同任务重复，避免把提前失败误当成低消耗。模型启动/恢复次数表示评测器进入被测模型的次数；Agent 轮次是这些调用内部的累计轮次。
在两边都 strict pass 的配对视图中，RC1 的模型进入次数更少、累计耗时更低；但完整表格也显示了代价：RC1 的 Agent 轮次、工具调用、总 Token 和平均成本都更高。因此这是“更短但不更便宜”的执行画像，不是所有效率指标都改善。
两边 48/48 条轨迹都保留了峰值上下文遥测；峰值上下文平均为 RC1 102,470 Token、beta16 104,208 Token。本次结论不使用 LLM Judge 的定性文本替代硬检查。
修正后的模型耗时
耗时从 raw stdout 重新计算：累加每个样本的全部顶层result.duration_ms。计算范围排除 Docker 准备和业务验证器运行时间。
- RC1：48 个可观测样本，平均 391.260s，中位数 369.053s。
- beta16：48 个可观测样本，平均 503.552s，中位数 476.481s。
任务级稳定性矩阵
RC1 有 16/16 个任务三次 strict pass；beta16 为 14/16。两边都覆盖全部 16 个任务的至少一次成功。
失败归因
修正后的 RC1 分析没有剩余 strict failure；beta16 有 2 次。原始 RC1 快照中的 1 次失败已通过同一份 raw stdout 和修复后的 shell-glob parser 复核为误报：
beta16 有 1 次纯 workflow 失败和 1 次业务与 workflow 同时失败。因此业务验证行分别是 RC1 48/48、beta16 47/48。
关于 LLM Judge
本次比较只采用确定性的任务与 workflow 验证、每次运行的最终passed 状态，以及 raw result 耗时；不使用定性 LLM Judge 文本替代这些检查。
如何解读这次结果
- 任务覆盖没有变化。 RC1 和 beta16 的任务级
pass@3都是 16/16。 - RC1 在这组样本中略微更稳定。 strict pass@1 高 4.17 个百分点，
pass^3高 12.50 个百分点。 - RC1 更快但不是更便宜。 配对成功样本中的平均成本和总 Token 上升，尽管 raw model duration 的平均值和中位数下降约 22%。这些是经验性 trade-off，不是单一的“全面更好”。
关闭记忆与项目规则后的严格复测
为排除上一轮模型规格不一致造成的偏差，补充复测只选择最难的comet-full-workflow，运行 1 次。主模型固定为 deepseek-v4-flash[1m]，与 RC1-on 对照一致；同时关闭 memory.learning、memory.retrieval，并在启动快照中确认 plugins: []。复测通过 18/18 项检查，业务基线为 6/6。
这次结果没有支持“关闭记忆和规则后 Token 反而增加”的判断。之前的异常增幅来自把
deepseek-v4-flash（200K 上下文）与 deepseek-v4-flash[1m]（1M 上下文）混作对照；在模型规格校正后，RC1-off 样本的总 Token 和成本反而低于 RC1-on 三次平均。
这仍然不是项目规则插件的因果成本实验：当前源码已经移除了 comet.project-rules，本次启动快照也没有加载插件，因此只能说明校正后的 RC1-off 参考值，不能从一个样本推导插件本身增加了多少 Token。完整证据和配置快照见下面的同格式 HTML 报告。
HTML 可视化报告
下面的嵌入报告集中展示 headline metric、可靠性指标、配对执行效率、修正耗时、16 个任务的三次运行矩阵、失败归因和比较边界。下一步
- 在同一服务窗口、相同并发条件下复跑 RC1 和 beta16，再加强耗时结论。
- 单独跟踪 RC1 的工具调用、轮次、Token 和成本上升，与耗时下降分开评估。
- Comet 基线真实评估实验 - 查看较早的 Classic 基线对比。
- 评分指标与双 Agent 评测 - 理解
pass@k、pass^k、硬验证和 LLM Judge 的区别。