Skip to main content
会话断了、上下文被压缩了、或者换了台设备——正常情况下你只需要重新输入 /comet。Comet 先读取项目根配置，进入 /comet-native 或 /comet-classic，再由对应工作流从自己的磁盘状态继续。两边不会扫描、猜测或转换另一侧的 change。

​
最短路径

在 Agent 平台里输入：
就这样。Comet 不依赖对话历史：Native 重读 .comet/config.yaml、<artifact-root>/comet/、实现和验证证据；Classic 重读同一项目配置、OpenSpec、.comet.yaml 与运行证据。
那两个是诊断命令，只在看起来有问题时才用（CLI/Skill 装坏了、change 不路由、证据对不上）。正常恢复就是 /comet 一步到位。

​
也可以直接说“继续”

0.4.0-beta.4 起，comet init 和 comet update 会把一段 Comet 恢复说明合并进项目的 AGENTS.md 和 CLAUDE.md。长程任务经过上下文压缩、跨会话或跨设备继续时，Agent 可能已经忘记当前请求原本属于 Comet，而用户也未再次输入 /comet。此时 Agent 可以先运行只读的 comet resume-probe，判断“继续刚才的登录重构”是否对应现有 change，再决定是否重新进入工作流。 这段说明只约束 Comet 的恢复探测，并会保留文件中已有的用户规则。探针先解析配置，再只检查一套工作流；配置损坏时不会回退。.comet/config.yaml 中的 ambient_resume: false 可以关闭普通请求触发的探针。它不会影响显式 /comet，也不会绕过已有决策点。 详见恢复探测命令。

​
Native 如何恢复

这一节解释 后台原理：你输入 /comet 继续 之后，Native 工作流内部是怎么从磁盘状态重建断点的。你不需要照着这里手动执行任何命令。
Native 的所有阶段都从永久入口 /comet-native 恢复。入口先运行 status 和 show，读取 brief、完整目标规格、canonical spec、仓库实现和测试，再决定继续 Shape、Build、Verify 还是 Archive。未提交改动只是现场证据，不会单独阻塞恢复；模型仍必须保留无关改动。 comet native next 用于满足条件后的状态推进，不是 Ambient Resume 的入口。多个 Native changes 时，用户精确点名优先，其次使用有效 selection；否则探针要求选择，不根据请求内容猜 change。

​
Classic 如何恢复

这一节同样是 后台原理：解释 /comet-classic 内部重读哪些文件、按什么规则路由到下一个阶段。你只需要输入 /comet 继续，下面的路由由 Comet 自动完成。
/comet-classic 的恢复能力来自三个机制： 恢复时的路由（命中即停，以文件状态为准）： 只要有一个活跃 Classic change，/comet-classic 会自动选中它；有多个时列出清单让你选一个。 如果通过自然语言恢复，多个 active change 不会被自动猜测；恢复探测会返回 ask_user，等待你点名目标。

​
换设备/换平台也能恢复

状态完全保存在仓库文件里：两边共享 .comet/config.yaml；Native change 使用 <artifact-root>/comet/ 与 comet-state.yaml，Classic change 使用 .comet.yaml、OpenSpec 和 docs/superpowers/。所以在另一台设备或另一个 Agent 平台打开同一个仓库，/comet 能从对应文件恢复。
唯一的注意点：未提交的工作区改动不会跟着 git push 走。跨设备前先把改动 commit 推上去，否则新设备上会是干净工作区的恢复（tasks.md 的勾选状态仍然有效）。

​
跨设备 0 上下文断点恢复现场

下图展示了跨设备、0 上下文的断点恢复现场——不管在哪台设备、哪个平台，只要仓库一致，/comet 就能从文件状态重建断点继续，无需任何额外操作或上下文传递： 跨设备 0 上下文断点恢复现场

​
上下文压缩后怎么办

如果 Classic change 所在的 Agent 平台自动压缩了上下文，重新输入 /comet。项目配置会再次进入 Classic，内部 /comet-classic 按恢复协议重载状态；必要时读取 brainstorm-summary.md、handoff 交接包和 .comet/subagent-progress.md。你不需要手动操作这些文件。

​
从任意阶段入口恢复

Classic 正常恢复使用 /comet。阶段和预设入口只用于手动控制或调试：/comet-open、/comet-design、/comet-build、/comet-verify、/comet-archive、/comet-hotfix、/comet-tweak。 这是 0.4.0-beta.1 渐进式加载带来的确定性保证：每个子 Skill 进入时都会先通过 comet/reference/scripts.md 定位脚本，然后跑自己那个阶段的入口检查或恢复检查，而不是从对话历史推断阶段。
  • 如果检查发现实际的 phase、workflow 或证据属于另一个 Skill，按脚本输出和 /comet-classic 路由规则切换——不要在错误的阶段里继续写状态。
  • 如果工作树有未提交改动，先用 comet/reference/dirty-worktree.md 的规则归因。
这条规则让你在 已知自己在哪个阶段 时跳过统一入口和 Classic 内部路由， 的路由开销直接干活，同时保证即使记错了阶段也不会把状态写坏——入口检查会拦住不匹配的进入。

​
build 阶段恢复的特殊情况

build 阶段的恢复最复杂，但大多数情况 /comet-classic 也能自动处理： subagent 模式（build_mode: subagent-driven-development）恢复时，主会话不会直接执行任务——它会回到后台子代理调度规则，由主会话只做协调。

​
有未提交改动时

如果工作区有未提交改动，Comet 会自动做归因，不需要你先解释改了什么：
  • 改动属于当前 change → 折叠进去继续
  • 和当前 change 无关 → 暂停问你怎么处理（并入 / 拆新 change / 保留 / 丢弃）
  • 来源不确定 → 暂停汇报文件列表和判断依据
构建产物（node_modules/、dist/ 等 .gitignore 的）会自动排除，不当用户改动。
dirty worktree 只代表代码事实，不会自动推进 .comet.yaml 的 phase 或勾选 tasks.md——只有完成归因、验证、过阶段 guard 后才推进状态。

​
真正需要你介入的情况

/comet-classic 能自动推进无歧义的衔接，但决策点必须等你明确选择。恢复时常见的需要你介入的情况：
  • 验证失败（verify_result: fail）——你要决定修复还是接受偏差
  • 真正的 plan-ready 暂停——你要选隔离和执行方式
  • build 决策缺失——你要补选 isolation/build_mode/tdd_mode
  • 无法归因的未提交改动——你要说明改动归属
  • 多个活跃 change——你要选恢复哪个
  • 其余是各阶段固有的停顿点（见五阶段停顿点）
这些之外，/comet-classic 都会自己往前走。

​
什么时候才用 comet status / comet doctor

这两个是诊断工具，不是恢复的必经步骤：
runtime_eval 会告诉你声明的步骤证据是否真在磁盘上——失败时会提示 run <命令> or restore missing evidence。

​
下一步

最后修改于 2026年8月2日