comet resume-probe 主要解决长程任务中的工作流上下文丢失：用户仍想继续某个 Comet change，但 Agent 在新的上下文窗口、会话或设备上已经不知道当前请求属于 Comet，用户也没有再次显式调用 /comet。恢复探测会只读比较用户请求与现有 active changes，判断是否应重新进入对应的 Native 或 Classic 工作流，避免 Agent 脱离 Comet 后把“继续刚才的登录重构”当成一项普通的新任务。
它先读取项目的 .comet/config.yaml 确定 Native 或 Classic，再只读取该工作流的 active changes、当前阶段和用户请求。没有有效 workflow 配置的旧 Classic 项目保持 legacy fallback；配置损坏时停止并要求修复，不扫描另一套目录。
恢复探测只负责识别和路由。它不会修改 change、推进阶段、替用户选择多个 change，也不会自动执行返回的下一条命令；真正的恢复仍由 Agent 按 nextCommand 调用 /comet-native 或 /comet-classic 完成。
为什么需要恢复探测
长程任务不一定始终处于同一个完整上下文中。以下情况都可能让 Agent 忘记当前工作原本由 Comet 管理：- 对话经过上下文压缩、切换窗口或开启新会话；
- 用户换设备继续同一个仓库和 change；
- 新 Agent 只能看到磁盘状态和一句“继续之前的工作”；
- 用户自然地要求继续任务，但没有再次输入
/comet。
恢复探测不是要求用户记住一个额外命令。它主要供 Agent 和项目恢复说明调用，用来弥补自然语言续接与显式
/comet 入口之间的断层。自动探测如何发生
用户不需要输入comet resume-probe。正常交互仍然是直接告诉 Agent：
继续刚才的登录重构。
comet init 和 comet update 会把恢复说明写入项目的 Agent 指令文件。当 ambient_resume 开启时，Agent 在处理可能属于长程任务的自然语言请求前，会自动运行只读恢复探测：
- 读取项目配置，确定应检查 Native 还是 Classic；
- 比较用户请求、active changes、当前阶段和 selection；
- 目标唯一时按
nextCommand重新进入对应的/comet-native或/comet-classic； - 目标有歧义时只问用户一个问题；请求无关时正常处理，不进入 Comet。
/comet 时会直接按项目配置进入工作流，不依赖自动探测。通过宿主显式调用的非 Comet Skill 或斜杠命令同样不触发恢复探测——任务意图已经由该调用明确，直接执行该 Skill 即可。项目若设置 ambient_resume: false，普通自然语言请求不会触发环境感知探测，但 /comet 仍然可用。
对用户而言，恢复探测是自动的。下面的 CLI 参数用于 Agent、Hook、项目指令和自动化集成，不是恢复任务前必须手工执行的步骤。
Agent 与自动化集成参考
Agent 或集成可以直接传入请求：如何理解结果
JSON 使用
comet.resume_probe.v2，包含 workflow、skill、entrySource、reasonCode、candidates、changeName、phase、nextCommand 和判断证据。Native 任一阶段都通过 /comet-native 恢复；comet native next 是状态推进命令，不是恢复入口。Classic 自带 runtime 的内部 v1 探针保持兼容，但顶层 CLI 返回 v2。
哪些情况一定会暂停
- 多个 active change，但用户请求没有点名目标。
- 多个 active change 且没有有效 selection 或用户点名。
- active change 缺少有效状态或项目配置损坏。
- 当前处于 plan-ready、验证失败、归档确认等用户决策点。
- 请求与已有 change 无关或只是信息查询时不会恢复，而是返回
out_of_scope。
/comet-native 检查现场；Classic 继续保留工作树归属确认规则。
与其他命令的区别
下一步
- 恢复中断的工作 — 自然语言恢复与显式
/comet的使用方式 - 状态损坏与恢复 — 恢复探测提示状态异常时如何排查
- comet status — 查看全部 active change 的详细状态