Token省76.8%、速度快47.4%Comet Native实测基准数据背后的原理深潜【免费下载链接】cometComet: agent skill harness for turning ideas into evaluated workflows项目地址: https://gitcode.com/rpamis/cometComet是面向编码 Agent 的技能与长任务工作流平台其Comet Native 工作流在最近一轮实测基准中交出了一份亮眼答卷在双方均通过的 41 组配对样本里Native 相比 0.4.0 Classic总 Token 减少 76.8%、Agent 轮次减少 57.4%、耗时减少 47.4%且 pass^3 提升到 87.5%12.5 个百分点。本文带你深潜这组基准数据背后的原理钱和速度到底省在哪里一、先看数据这组基准是怎么测出来的在解读原理之前先明确实验口径避免幸存者偏差式的误读项目说明实验任务16 个对齐的 Comet 工作流任务每组运行次数Native / Classic 各 48 次pass3 口径下多轮采样对比样本双方均通过的 41 组配对样本排除掉队样本干扰核心结果Token -76.8%、Agent 轮次 -57.4%、耗时 -47.4%质量结果Native pass^3 达 87.5%12.5pp两种模式 pass3 均为 100%⚠️ 一个容易被忽略的细节省 Token不是以牺牲可靠性换来的。pass3 双方都是 100%而衡量每次都做对的严格指标 pass^3Native 反而更高。也就是说省下来的 Token 不是少干正事而是少干重复、无效的协议动作。二、原理深潜①把证明我完成了的开销砍掉传统重型工作流如 Classic 保留的 OpenSpec Superpowers 五阶段治理模型要求 Agent 在每一步都留下可审计的证据项目快照、文件哈希、receipt回执、evidence证据链、逐项验收文件……这些机制本身没问题但每一分证明成本最终都折算成 Agent 的上下文占用与额外轮次也就是真金白银的 Token。Comet 0.4.0-beta.17 对 Native Runtime 做了一次彻底的验收重构设计全文见 NATIVE-RUNTIME-VERIFICATION-LOOP-REDESIGN.md核心决策只有四条但条条切在 Token 消耗的大头上实现者与验收者分离Builder Agent 只提交候选完成没有宣布通过的权力验收由 Runtime 分派的全新 Verifier execution完成。这样避免了同一上下文里自我复核—自我说服带来的冗长往返。删除重型完整性机制正常 Verify 路径不再做项目快照、不再计算全项目文件哈希、不再维护 receipt/evidence 引用链。一份comet-state.yaml作为唯一可携带语义状态Agent 崩溃或换会话后只需读它恢复而不是重读一整套派生状态文件。每个必要检查在同一实现状态上最多执行一次Runtime 用检查回执check receipt记录这条命令已经真实跑过且通过后续复用而不是让 Agent 反复重跑。有界 Loop 停滞判断Build ↔ Verify 之间保留修复循环但带总轮次上限与停滞检测——Agent 不会陷入重试 → 失败 → 再解释 → 再重试的 Token 黑洞。一句话概括把证明的活从 Agent 的上下文里挪进 Runtime 的代码里。Agent 专注写代码和验收协议开销由确定性程序承担这直接解释了 Agent 轮次为何能砍掉 57.4%。三、原理深潜②Runtime 自身也在抠毫秒Token 省了还不够CLI 和 Runtime 自身的启动、检查耗时同样会被 Agent 反复调用慢一秒就是几十秒的累积等待。项目仓库里保存了两轮严格的 Runtime 实测Windows、Node v22.20.0每场景 30 次正式采样CLI 层实测workflow-cli-performance-results.md场景中位耗时变化Git 子进程数Classic 检查首次执行-48.0%3432.7 → 1786.3 ms26 → 8Classic 检查复用-48.0%2149.5 → 1116.9 ms15 → 4Classic 输入变化后检查-59.1%5096.0 → 2085.0 ms45 → 12Native 检查首次执行-28.5%4874.5 → 3487.0 ms21 → 20收益主要来自两处工程手段批量合并 Git 调用把脏文件/未跟踪文件逐个git hash-object的逐文件扫描合并为有序批量调用Git 子进程数最高从 45 次压到 12 次只读查询走快捷路径 去重current/next这类高频状态查询跳过低收益模块加载经验性学习记录延迟到实际记录时才加载并在同一命令内复用身份查询结果详见 runtime-performance-report.md 与 runtime-latency-repair-validation.md。 值得注意30 个 worktree 的Native status中位耗时从 8248 ms 降到 577 ms约 -93%Git 调用从 92 次降到 2 次——查询成本不再随无关 worktree 数量增长这正是Agent 每轮都要问一次状态场景下的隐藏 Token/时间税。四、省下的成本去哪了——质量不降反升省 Token 最大的风险是偷工减料。Comet 用双层证据回答这个问题Rubric 画像0.4.0 在 11 个评测维度上对 0.3.9 全面持平或领先Recovery resilience恢复韧性一项提升 0.44总加权分 0.07可审计的原始报告仓库内保留了完整的基准原始数据例如 native-benchmark-report.json 逐 Wave 记录了 turns、total_tokens、cost_usd 与失败检查项任何人都可以自行复核而不是只看结论图。在浏览器端统一的三栏 Dashboard 让你随时看到每个 change 处于设计 / 构建 / 验证 / 归档哪一阶段、Verify 是否通过、下一步该执行什么命令——效率优化没有以牺牲可观测性为代价。五、如何上手体验 Comet Native️ 上手成本极低只需要记住两个 Skill 一个命令初始化如需要 clone仓库地址为 https://gitcode.com/rpamis/comet 在项目里运行comet init交互式选择 Native面向能自主规划、验证的强模型或 Classic需要完整五阶段强约束的任务配置统一写入.comet/config.yaml进入工作流在 Agent 中用/comet它会只读项目配置并确定性地转发到/comet-native或/comet-classic评估你的 Skill用comet eval结合 Rubric、Passk / Pass^k 对任意 Skill 做科学评测让优化有没有用有数据支撑。Native 的用户可读产物默认位于docs/comet/需求、目标行为、验收结论三类 Markdown机器状态固定在.comet/runtime/native/两者分离——这也是状态不伪装成文档、文档不拖累上下文设计哲学的落点。六、关键资料索引资料相对路径中文 README含 76.8% 实验摘要README-zh.mdNative 验收循环重构设计原理核心docs/architecture/NATIVE-RUNTIME-VERIFICATION-LOOP-REDESIGN.mdSupervisor 子任务统一验收设计docs/architecture/NATIVE-SUPERVISOR-SUBTASK-ACCEPTANCE-UNIFICATION.mdWorkflow CLI 性能对比结果docs/research/2026-09-22-workflow-cli-performance-results.mdRuntime 性能前后对照报告scripts/benchmark/runtime-performance-report.md基准原始数据JSONassets/eval-reports/comet-native-vs-beta16-beta17-20260810/native-benchmark-report.jsonNative 运行时源码domains/comet-native/七、总结省钱的本质是职责归位回到标题的那组数字——76.8% 的 Token 与 47.4% 的时间节省并非来自某个魔法参数而是三个工程决策叠加的结果✅ 把快照、哈希、证据链等协议开销从 Agent 上下文移入 Runtime 代码✅ 用检查回执与只读快捷路径把每次调用的 CLI/Git 成本压到最低✅ 用有界 Loop 与独立 Verifier杜绝无效重试的同时保住了质量。对普通用户而言你不需要理解这些细节就能受益选 Native、跑/comet、用 Dashboard 看进度即可。但当你读懂了钱省在哪也会更有信心判断这套工作流在复杂项目里值得托付。【免费下载链接】cometComet: agent skill harness for turning ideas into evaluated workflows项目地址: https://gitcode.com/rpamis/comet创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考