Skip to main content
关于 Native 的适用场景、四阶段工作流、可跨设备同步的状态、验证、恢复和冲突处理的常见问题。

​
基础概念

主力模型是 Fable 5、GPT-5.6 及同档强模型时优先 Native：这类模型能自主规划和实现，强加方法论约束反而浪费它的能力，Native 把方法选择权交给它，只锁住结果与证据。模型能力档更低、需要更明确过程约束时用 Classic，它通过 OpenSpec 与 Superpowers 提供 open、design、build、verify、archive 五阶段治理。两套工作流由 .comet/config.yaml 选择。
不依赖。Native 自带 Shape、Build、Verify、Archive 和 Runtime。只有 Classic 才安装并使用 OpenSpec 和 Superpowers。
Builder 只提交实现 handoff。Runtime 先运行必要检查，再分派新的只读 Verifier 覆盖全部 A1…An。平台无法启动独立 Verifier 时，Comet 会暂停并给出”重试验证”（—retry-verifier， 保留候选和已完成检查）或”接受降级结果”两个选项；接受降级才进入归档，并在报告中标明降级。
验收失败、检查失败、Verifier 漏项或结果无效都会写入下一步 continuation，并把 change 返回 Build。下一轮按失败原因修复后，由新的 Builder 和新的 Verifier 重新开始。
可以。Shape 和 Build 需要同步的 brief、Specs 和 comet-state.yaml；verification.md 是可重建报告。Verify 或 archive-ready 在另一台设备上会重建本机执行状态并重新确认，不会直接复用旧的本机结果。
comet-state.yaml 保存阶段、Loop、验收、handoff、检查摘要、Verifier 结论、阻塞原因和下一步；换设备时靠这份文件恢复进度。.comet/runtime/native/ 只保存本机 state.json、日志、锁和事务，缺失或版本不匹配时可以重建。
Batch 会先整理问题依赖，再一次询问当前前提已具备的问题，减少重复往返。Sequential 仍可配置，按轮次询问一个最上游问题；两者都要在 Build 前确认共享理解。
当前 Verifier 通过 request-checks 请求 Runtime 执行。Runtime 会合并等价的检查请求、限制请求轮数并返回结果；不要自行创建“检查回执”或在状态文件里填通过。
可以。创建 change 时会在适用时展示 current、branch、worktree 选择；.comet/current-change.json 只选择下一次写入归属，不限制 active change 数量。两个 change 要修改同一 capability 时，Archive 会要求明确顺序。

​
Supervisor Change

一个整体目标包含至少两个能够独立实现和验证的结果，并且仍需要统一集成和最终验收时，适合使用 Supervisor Change。Runtime 会按验收项分配 child、管理依赖和独立 worktree，并在所有 child 集成后验证完整目标。没有共同最终验收的目标应创建多个独立 Change。多个部分需要频繁修改同一核心区域，或者拆分成本高于并行收益时，继续使用单个 Native Change。
推进方式只决定 child 在哪里执行；拆分结果、依赖、验收和集成规则在两种方式下保持一致。多会话协作由当前会话统筹，优先使用 Codex 独立会话或 Claude Code Agent Teams；单会话推进由当前会话按顺序完成 child。Runtime 在确认 Supervisor Shape 时把选择保存为 coordination_mode。恢复任务或因需求变化重新进入 Shape 时会沿用这个选择，不重复询问。
Comet 会先重新读取 Runtime，不会根据旧会话的残留信息判断 child 已经完成。持久化为 multi-session 时，独立会话或 Agent Team 不可用会自动改用 subagent，不会切换为单会话。已经派发但丢失的任务会先通过 supervisor-cancel 使旧 runId 失效，再使用新的任务包和 runId 重新派发。旧执行的迟到结果会被拒绝；subagent 也不可用时，Comet 会报告真实阻塞。

​
恢复和排障

如果变化只是补齐已确认目标的实现，继续 Build 和 Verify Loop。变化修改了用户可见目标、范围或验收标准时，Native 会让 change 返回 Shape，记录新的决定并使旧验证失效。即使 change 已经 archive-ready，也要先重新确认需求，再针对当前目标取得新的验证结果。
可以先通过 comet status 和 comet native doctor <change-name> 判断状态。能够迁移的 active change 会按 Runtime 返回的动作保守迁移；旧版归档保持只读。不要手工移动旧 Runtime、修改状态文件或复制验证记录。升级后先运行 comet update 刷新 Skill 和 Runtime。只有 Doctor 明确提供修复动作时，才运行 comet native doctor <change-name> --repair。
先运行：
不要手工修改 comet-state.yaml、.comet/current-change.json 或 .comet/runtime/native/。如果代码、artifact root、branch/worktree 未同步，或 active/archive 目录混合，Runtime 会返回具体的 await-user/blocked 动作。旧版本留下的 change-local Runtime、旧 receipt/evidence 或 native.snapshot 配置只用于迁移和只读兼容。RC1 新建的 Portable State change 不会继续创建这套旧版状态记录。
继续阅读：Native 配置、产物与状态、验证与修复 和 恢复手册。
最后修改于 2026年9月4日