pass@3 实验：使用相同的 16 个业务任务，每个任务重复 3 次。两组共 96 次运行。
Native 与 Classic 是两套面向不同模型能力的 workflow，不存在 Native 升级到 Classic
的关系。本文比较的是它们在相同业务任务上的完成能力、稳定性和模型耗时，不要求两者生成相同的流程产物。
实验如何对齐
对齐实验并不意味着把 Classic 的检查原样套到 Native 上。业务目标和业务验证器保持一致，workflow 检查则分别遵循两种模式的真实契约。
部分任务提示仍包含 Open、Design、Build、Verify、Archive 等 Classic 术语。Native treatment 会明确要求模型保留业务需求，但将它们映射到 Shape、Build、Verify、Archive，不创建 OpenSpec、Superpowers 或
.comet 流程产物。这样可以减少任务文案对 Classic 的先验偏置。
0.4.0 的 48 个样本都因日志中出现 outer runner、API 或环境失败字样而被保守标记为 flagged，但仍全部进入 analysis set；它们不是 48 个被排除或判定失败的样本。本文保留其 strict pass 结果，同时把这一可观测性差异作为比较限制，而不是忽略它。
核心结果
这组结果有两个层次。两种模式的
pass@3 都是 100%，说明每个任务在三次尝试中都至少成功过一次。Native 的 pass^3 更高，则说明它在重复运行稳定性上更好：16 个任务中有 14 个连续三次通过，0.4.0 Classic 为 12 个。
为什么同时看 pass@3 和 pass^3
pass@3 衡量三次尝试中至少一次成功，适合观察能力覆盖。pass^3 衡量三次尝试全部成功，适合观察可靠性下限。
如果只看 pass@3 = 100%，会看不到 48 次运行中实际存在的失败。Native 有两次 strict failure；0.4.0 Classic 有五次。两种指标必须一起看，才能区分“模型有能力完成”和“模型每次都能稳定完成”。
完成任务的执行效率
效率主视图只统计 Native 与 Classic 都通过的同一任务重复，共 41 组。这样不会把提前失败、因而消耗更少的运行误当成效率提升。一次“模型启动/恢复”表示评测器启动被测模型，或在用户回答、冷恢复后再次进入同一任务；它不同于调用内部累计的 Agent 轮次。
Native 的 48 次运行都保留了逐消息上下文 usage：平均峰值为 34,771 Token，中位峰值为 34,568，最大值为 42,012；平均峰值占 200k 窗口的 17.4%。旧 Classic 轨迹只有 9/48 保存了同等粒度的数据，因此不能可靠计算两种 workflow 的上下文占用提升比例。
修正耗时口径
早期报告中的Duration 只保留了最后一段 result 事件。当一次自动交互包含多轮模型调用时，这会把前面轮次的耗时漏掉，出现不合理的 4 秒或 5 秒样本。
本次比较改为累加每个样本所有顶层 result.duration_ms：
- Native：48 个可观测样本，平均 183.971 秒，中位数 174.493 秒。
- 0.4.0 Classic：47 个可观测样本，平均 352.375 秒，中位数 328.192 秒；另有一次运行在产生 result 前失败。
- 两者都不计入 Docker 准备和 task validator 运行时间。
失败归因
Native 的两次失败都不是业务实现失败：
0.4.0 Classic 的五次失败包括一次业务失败和四次流程契约失败：
这反映了两套模式不同的失败面。Classic 的流程依赖更多，失败可能来自主 Skill、阶段、OpenSpec 或依赖 Skill 的任一环节。Native 的流程面更窄，但仍然保留终态证据检查；代码完成而 brief、specification 或 verification 不完整，依然不会计为 strict pass。
关于 LLM Judge
本次结论不使用 Native 旧报告中的 LLM Judge 定性文本。复核发现，生成该报告时 Judge 会读到适配前的_test_results.json transport 文件，从而把其中的旧路径检查误认为 Native 最终产物。
因此本文只采用：
- task validator 和 workflow validator 的硬检查；
- 每次运行的最终
passed状态； - 原始顶层 result 事件中的累计耗时；
- 可追溯的任务级失败原因。
_test_context.json 和 _test_results.json，但不会用修复后的代码反向改写这次历史实验的定性 Judge 结论。
如何解读这次结果
这次对齐实验支持三个判断：- 轻执行没有牺牲任务覆盖。 Native 和 0.4.0 Classic 的任务级
pass@3都是 100%。 - Native 的重复运行更稳定。 strict pass@1 高 6.25 个百分点，
pass^3高 12.5 个百分点。 - Native 的模型执行明显更短。 修正后的平均值和中位数都下降约 47%，但仍需在完全相同的运行窗口中复测，才能形成更强的延迟因果结论。
HTML 可视化报告
下面的嵌入报告集中展示 headline metric、可靠性指标、完成任务的轮次、工具调用、Token、成本、修正耗时、16 个任务的三次运行矩阵、失败归因和比较边界。下一步
- 在同一运行窗口、相同并发条件下复跑两种模式，进一步收紧耗时结论。
- 继续提高 Native 终态证据完整性，重点检查 brief、specification 和 verification 的归档一致性。
- Comet 基线真实评估实验 - 查看 0.3.9 与 0.4.0 Classic 的完整基线对比。
- 评分指标与双 Agent 评测 - 理解
pass@k、pass^k、硬验证和 LLM Judge 的区别。