> ## Documentation Index
> Fetch the complete documentation index at: https://docs.comet.rpamis.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Comet Native 与 0.4.0 Classic 真实评估

> 使用相同的 16 个任务和 pass@3 样本规模，对比 Comet Native 与 0.4.0 Classic 的严格通过率、重复运行稳定性和修正耗时。

目录

<ol>
  <li>
    [实验如何对齐](#%E5%AE%9E%E9%AA%8C%E5%A6%82%E4%BD%95%E5%AF%B9%E9%BD%90)
  </li>

  <li>
    [核心结果](#%E6%A0%B8%E5%BF%83%E7%BB%93%E6%9E%9C)
  </li>

  <li>
    [为什么同时看 pass@3 和 pass^3](#%E4%B8%BA%E4%BB%80%E4%B9%88%E5%90%8C%E6%97%B6%E7%9C%8B-pass%403-%E5%92%8C-pass%5E3)
  </li>

  <li>
    [完成任务的执行效率](#%E5%AE%8C%E6%88%90%E4%BB%BB%E5%8A%A1%E7%9A%84%E6%89%A7%E8%A1%8C%E6%95%88%E7%8E%87)
  </li>

  <li>
    [修正耗时口径](#%E4%BF%AE%E6%AD%A3%E8%80%97%E6%97%B6%E5%8F%A3%E5%BE%84)
  </li>

  <li>
    [失败归因](#%E5%A4%B1%E8%B4%A5%E5%BD%92%E5%9B%A0)
  </li>

  <li>
    [关于 LLM Judge](#%E5%85%B3%E4%BA%8E-llm-judge)
  </li>

  <li>
    [如何解读这次结果](#%E5%A6%82%E4%BD%95%E8%A7%A3%E8%AF%BB%E8%BF%99%E6%AC%A1%E7%BB%93%E6%9E%9C)
  </li>

  <li>
    [HTML 可视化报告](#html-%E5%8F%AF%E8%A7%86%E5%8C%96%E6%8A%A5%E5%91%8A)
  </li>

  <li>
    [下一步](#%E4%B8%8B%E4%B8%80%E6%AD%A5)
  </li>
</ol>

[← 评估实验](https://docs.comet.rpamis.com/zh/tech-blog.md#eval-experiments)

2026-07-16

评估实验

# Comet Native 与 0.4.0 Classic 真实评估

使用相同的 16 个任务和 pass\@3 样本规模，对比 Comet Native 与 0.4.0 Classic
的严格通过率、重复运行稳定性和修正耗时。

作者：Comet 团队

> [!WARNING]
>
> 这是源码/维护者保存的历史实验报告，不是普通用户的运行教程。复现实验需要对应的 Comet
> 源码、任务和报告快照。普通用户请使用[快速上手](https://docs.comet.rpamis.com/zh/eval/quickstart.md)。

> [!NOTE]
>
> 本文是 2026-07 的历史实验，Native 样本来自 beta16/旧 Native
> 产物协议。它用于保留当时的模型表现对比，不能作为 beta17 的文件布局、Verify 或恢复契约。当前 beta17
> 以 [Native 工作流](https://docs.comet.rpamis.com/zh/concepts/native-workflow.md)、[产物与状态](https://docs.comet.rpamis.com/zh/native/artifacts-and-state.md)
> 和最新 [Changelog](https://docs.comet.rpamis.com/zh/changelog.md) 为准。

这次实验回答一个更具体的问题：模型本身已经足够强（Fable 5、GPT-5.6 这一档）时，Comet Native 能否在保留需求、状态、验证和归档证据的同时，比 0.4.0 Classic 更轻？

我们把 Native 的样本规模对齐到 0.4.0 曾经运行过的 `pass@3` 实验：使用相同的 16 个业务任务，每个任务重复 3 次。两组共 96 次运行。

> [!NOTE]
>
> Native 与 Classic 是两套面向不同模型能力的 workflow，不存在 Native 升级到 Classic
> 的关系。本文比较的是它们在相同业务任务上的完成能力、稳定性和模型耗时，不要求两者生成相同的流程产物。

## 实验如何对齐

对齐实验并不意味着把 Classic 的检查原样套到 Native 上。业务目标和业务验证器保持一致，workflow 检查则分别遵循两种模式的真实契约。

| 观察项 | Native | 0.4.0 Classic |
| - | - | - |
| 业务任务 | 相同的 16 个任务 | 相同的 16 个任务 |
| 重复次数 | 每任务 3 次，共 48 次 | 每任务 3 次，共 48 次 |
| 业务验证 | 沿用相同 task validator | 沿用相同 task validator |
| workflow 验证 | Native Skill、`comet/` 产物、状态、轨迹和隔离性 | Classic Skill、OpenSpec、阶段、状态和依赖 Skill 契约 |
| 执行方式 | 当前本地并发运行 | 2026-07-04 至 05 的历史运行 |
| 实验标识 | `experiment_20260716_104344` | `combined_comet_workflow_full_k3_20260705_v3_rerun_failed` |
| Analysis set | 48/48 included，high confidence | 48/48 included，全部 flagged、medium confidence |

部分任务提示仍包含 Open、Design、Build、Verify、Archive 等 Classic 术语。Native treatment 会明确要求模型保留业务需求，但将它们映射到 Shape、Build、Verify、Archive，不创建 OpenSpec、Superpowers 或旧的 change-local `.comet` 流程产物。这样可以减少任务文案对 Classic 的先验偏置。

0.4.0 的 48 个样本，日志中都出现了 outer runner、API 或环境失败字样，因此全部保守标记为 `flagged`，但仍进入 analysis set。`flagged` 只是可观测性标记，并不代表样本被排除或判定失败。本文保留其 strict pass 结果，并将这一可观测性差异纳入比较限制。

## 核心结果

| 指标 | Native | 0.4.0 Classic | 差异 |
| - | -: | -: | -: |
| strict pass\@1 | 46/48，95.83% | 43/48，89.58% | Native +6.25 pp |
| pass\@3 | 16/16，100% | 16/16，100% | 持平 |
| pass^3 | 14/16，87.5% | 12/16，75% | Native +12.5 pp |
| 业务验证通过 | 48/48 | 47/48 | Native +1 次 |
| 修正平均耗时 | 183.971s | 352.375s | Native -47.8% |
| 修正中位耗时 | 174.493s | 328.192s | Native -46.8% |

这组结果可以从两个角度看。两种模式的 `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 | 0.4.0 Classic | Native 差异 |
| - | -: | -: | -: |
| 模型启动/恢复次数 | 1.80 | 2.85 | -36.8% |
| Agent 轮次 | 39.02 | 91.66 | -57.4% |
| 工具调用 | 36.22 | 81.80 | -55.7% |
| 累计模型耗时 | 180.8s | 343.9s | -47.4% |
| 非缓存输入 Token | 16,647 | 74,903 | -77.8% |
| 输出 Token | 5,471 | 13,788 | -60.3% |
| 总 Token（包含缓存读取） | 891,631 | 3,840,975 | -76.8% |
| 模型成本 | \$0.658 | \$2.638 | -75.1% |

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 平均耗时降低 47.8%，中位耗时降低 46.8%。这与 Native 减少阶段切换、依赖 Skill 和重复流程读取的设计目标一致。

> [!WARNING]
>
> 0.4.0 数据来自历史运行，Native
> 数据来自当前并发运行。模型、任务和样本规模相同，但机器负载和服务时段并未完全受控。因此耗时差异只能作为方向性证据，不应表述为严格的因果实验结果。

## 失败归因

Native 的两次失败都不是业务实现失败：

| 任务 | Run | 失败检查 | 业务验证 |
| - | - | - | - |
| `comet-api-cache-ttl` | r2 | `native_state`：brief、specification 或 verification 证据不完整 | 通过 |
| `comet-graph-execution-review` | r3 | `native_state`：brief、specification 或 verification 证据不完整 | 通过 |

0.4.0 Classic 的五次失败包括一次业务失败和四次流程契约失败：

| 类型 | 次数 | 主要信号 |
| - | -: | - |
| 业务实现 | 1 | `full-workflow` 未实现要求的 `--sentences` 功能 |
| 依赖 Skill 契约 | 3 | 未观测到要求的 Superpowers 依赖 Skill |
| 主流程与阶段 | 1 | 主 Comet Skill 未调用，只观察到 3/5 个阶段 |

这反映了两套模式不同的失败情况。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 结论。

## 如何解读这次结果

这次对齐实验支持以下几点判断：

1. **轻执行没有牺牲任务覆盖。** Native 和 0.4.0 Classic 的任务级 `pass@3` 都是 100%。
2. **Native 的重复运行更稳定。** strict pass\@1 高 6.25 个百分点，`pass^3` 高 12.5 个百分点。
3. **Native 的模型执行明显更短。** 修正后的平均值和中位数都下降约 47%，但仍需在完全相同的运行窗口中复测，才能形成更强的延迟因果结论。

它不支持“Classic 已经没有必要”这一结论。Native 服务于 Fable 5、GPT-5.6 及同档强模型：这类模型能自行完成复杂代码推理，但仍需要需求澄清、状态、检查和归档。Classic 则继续服务于能力档更低、需要更细阶段指导和更强过程约束的模型与任务。

## HTML 可视化报告

下面的嵌入报告集中展示 headline metric、可靠性指标、完成任务的轮次、工具调用、Token、成本、修正耗时、16 个任务的三次运行矩阵、失败归因和比较边界。

Comet Native 与 0.4.0 Classic 对比报告

## 下一步

* 在同一运行窗口、相同并发条件下复跑两种模式，进一步收紧耗时结论。
* 继续提高 Native 终态证据完整性，重点检查 brief、specification 和 verification 的归档一致性。
* [Comet 基线真实评估实验](https://docs.comet.rpamis.com/zh/eval/comet-baseline-experiment.md) - 查看 0.3.9 与 0.4.0 Classic 的完整基线对比。
* [评分指标与双 Agent 评测](https://docs.comet.rpamis.com/zh/eval/scoring.md) - 理解 `pass@k`、`pass^k`、硬验证和 LLM Judge 的区别。

[← 返回评估实验](https://docs.comet.rpamis.com/zh/tech-blog.md#eval-experiments)

[在评估文档中阅读 ↗](https://docs.comet.rpamis.com/zh/eval/comet-native-vs-040-experiment.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.