oh-my-claudecode 的执行模式怎么选autopilot、team、ralph 与 ultrawork 的决策依据【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode在 oh-my-claudecodeOMC里跑任务时第一步往往是选执行模式一个产品想法要一路自动走到可运行代码用autopilot要多个 worker 并行认领任务池用/team要不验证通过就不停的持久化循环用ralph而ultrawork则是被它们复用的并行执行引擎。选错模式的代价是autopilot 会对单点小修发起五阶段重流程team 会把一个人能更快干完的工作套上协调开销。这篇文章基于仓库内的模式选择文档和三个模式各自的 SKILL 文档给出一条可执行的决策路径按什么问题选哪个模式、命令怎么调、以及跑完后拿什么证据判断它真的完成了。适用前提已安装 Claude Code 并装好 OMC 插件Claude Max/Pro 订阅或ANTHROPIC_API_KEY安装与omc-doctor验证步骤见 GETTING-STARTED.md本文依据的仓库版本标记为 5.0.2CLAUDE.md 中的OMC:VERSION注释。先分清四种模式类型以及一个版本事实mode-selection-guide.md 把模式分成四类这个分类决定了哪些模式可以叠加、哪些互斥类型模式说明Standalone独立autopilot、team各自独立运行互相冲突Wrapper包装ralph在 ultrawork 外层加持久化循环 验证Component组件ultrawork只做并行 agent 调度没有持久化、没有验证循环Modifier修饰eco修改模型路由以偏好的廉价档不能单独使用mode-hierarchy.md 给出的继承关系autopilot (autonomous end-to-end) ├── includes: ralph (persistence) │ └── includes: ultrawork (parallelism) └── includes: plan (strategic thinking) ralph (persistence wrapper) └── includes: ultrawork (parallelism engine) (adds: loop until done architect verification) ultrawork (parallelism engine) └── COMPONENT only - parallel agent spawning (no persistence, no verification loop)写作与选型时必须注意的版本事实5.0.0 起ultrawork、ultrapilot、swarm、pipeline、ultraqa等 17 个名字被整体移除且不作为别名保留CLAUDE.md、MIGRATION.md。也就是说在 5.x 里ultrawork不再是可直接调用的独立命令官方替代映射是/oh-my-claudecode:execute或/team协调式并行 worker 用/teamultrapilot和swarm则并入team。而模式选择文档里仍把ultrawork作为模式列出——那描述的是 ralph/autopilot 内部的并行引擎概念不再是独立入口。本文按这条边界处理涉及并行的选型落到/team或/oh-my-claudecode:execute。按三个问题走一遍决策流程mode-selection-guide.md 的决策流程图按下面的顺序提问不确定需求、想法模糊 ├── YES: 先用 deep-interview 澄清再执行 └── NO: 继续 想要自主执行autonomous ├── YES: 任务能拆成 3 个以上独立组件吗 │ ├── YES: team N:executor带文件所有权的并行自主执行 │ └── NO: autopilot顺序执行 ralph 阶段 └── NO: 想要并行执行 人工监督 ├── YES: 要成本控制吗 → 是: eco 并行模式否: 纯并行 └── NO: 需要直到验证通过才停 ├── YES: ralph持久化 并行 验证 └── NO: 标准编排直接向 agent 委派 有大量相似的独立任务例如修 47 个错误 └── YES: team N:executorN 个 agent 从任务池认领判断依据是任务结构不是个人偏好。文档给出的示例原文示例可直接对照自己的任务任务描述文档示例文档推荐模式原因Build me a REST APIautopilot单一连贯交付物Build frontend, backend, and databaseteam 3:executor组件边界清晰Fix all 47 TypeScript errorsteam 5:executor大量独立相似任务Refactor auth module thoroughlyralph需要持久化 验证Quick parallel executionultrawork5.x 中对应 /team 或 execute偏好人工监督的并行Dont stop until doneralph持久化关键词触发需求模糊时不要直接进执行模式文档建议先跑/deep-interview用苏格拉底式提问澄清模糊想法并暴露隐藏假设之后再进 autopilot——autopilot 检测到.omc/specs/deep-interview-*.md已存在时会直接把它当 Phase 0 输出。autopilot从想法到已验证代码的自主链路触发方式关键词autopilot、build me、I want a或直接/oh-my-claudecode:autopilot taskGETTING-STARTED.md 的首个任务示例就是一行autopilot build me a hello world app。执行结构autopilot SKILLPhase 0 扩展需求 → Phase 1 规划planner 出计划、critic 审计划→ Phase 2 执行executor 按任务难度分 haiku/sonnet/opus独立任务并行→ Phase 3 QA → Phase 4 多视角验证 → Phase 5 清理状态文件。何时判断该停下/继续文档给了明确的停止条件QA 循环最多 5 轮同一个错误连续出现 3 次 → 停止并报告根本问题等人工介入验证architect 功能完整性、security-reviewer 漏洞、code-reviewer 质量要求三方全部批准被拒项修复后重新验证重验证失败累计 3 轮后停止报告用户说 stop/cancel/abort 即停。完成判定SKILL 的 Final Checklist5 个阶段全部完成、Phase 4 全部验证者批准、有新鲜的测试运行输出且全部通过、有新鲜构建输出且成功、状态文件已清理。运行中可通过 Claude Code 状态栏 HUD 观察文档示例输出非固定预期[OMC] autopilot:execution | agents:3 | todos:2/5 | ctx:45%恢复取消或失败后重新运行/oh-my-claudecode:autopilot会从断点继续/oh-my-claudecode:cancel会保留进度。不适合 autopilot 的情况SKILL 的 Do_Not_Use_When想探索方案/头脑风暴用plan、单一聚焦的代码修改用ralph或直接委派 executor、快速小修直接委派。team并行 worker 分阶段验证触发与语法team SKILL/oh-my-claudecode:team N:agent-type task description /oh-my-claudecode:team task description /oh-my-claudecode:team ralph task descriptionN是 worker 数量范围 1–20缺省时按任务分解自动定规模agent-type只覆盖team-exec阶段的 worker 类型executor、debugger、designer 等其余阶段由 lead 按阶段路由表选专用 agent文档示例/team 5:executor fix all TypeScript errors across the project、/team 3:debugger fix build errors in src/。执行结构是固定管道team-plan → team-prd → team-exec → team-verify → team-fix循环。每个阶段切换时 lead 会写 handoff 文档到.omc/handoffs/stage-name.md记录已决定/已拒绝/风险/遗留项验证失败生成 fix 任务回流team-fix有次数上限max_fix_loops默认 3超过即转终态failed不会无限循环。完成判定所有真实任务非内部任务在任务列表中标记completed或到达带证据的明确 failed/blocked 终态随后 lead 逐个向 teammate 发shutdown_request、等shutdown_response30 秒超时确认后才清理 OMC 状态并删除.omc/state/team-state.json。终态只有三种complete、failed、cancelled。取消与恢复/oh-my-claudecode:cancel处理 team 清理lead 崩溃后可通过state_read(modeteam)找到最后阶段并从该阶段恢复而不是重复 spawn worker。两个使用边界平台检查原生 Windows 上先运行tmux -V确认 tmux 兼容二进制psmux 受支持不要直接告知用户必须 WSL只有确实没有 tmux 兼容二进制时才建议安装 psmux 或改用 WSL2。team ralph组合team 管道包在 ralph 持久化循环里team-verify通过后 ralph 再做 architect 验证至少 STANDARD 档任一侧取消都会连带取消另一侧。不适合 team 的情况选择指南的 Avoid when 一列写明——一个人能比协调开销更快地干完时不要用 team。ralph以 PRD 为完成依据的持久化循环触发方式关键词ralph、dont stop、must complete、keep going until done或/oh-my-claudecode:ralph taskralph SKILL。执行结构ralph 是 PRD 驱动的循环——启动时会生成prd.json脚手架活动状态在.omc/state/sessions/{sessionId}/prd.json你必须先把脚手架里 Implementation is complete 这类泛化验收标准替换成任务专属标准例如函数 X 在给定 Z 时返回 Y然后逐条 story 实现、逐条验收、把passes置为true直到所有 story 通过。验证是 ralph 与跑到一半就宣称完成的区别选--criticarchitect默认、--criticcritic或--criticcodex指定完成审核者审核档位小于 5 个文件、少于 100 行且有完整测试 → 至少 STANDARD 档Sonnet超过 20 个文件或涉及安全/架构变更 → THOROUGH 档Opus审核者是针对 prd.json 里的具体验收标准审不是泛泛问完成了吗批准后还要过 Step 7.5 的ai-slop-cleaner清理与 Step 7.6 的回归重验证测试/构建/lint 全重跑最后才/oh-my-claudecode:cancel干净退出可用--no-deslop跳过清理。完成判定Final Checklist 摘录所有 prd.json story 为passes: true且无未验证的活跃标准新鲜的测试运行输出全绿、构建输出成功所选 reviewer 针对具体标准批准/oh-my-claudecode:cancel已执行。停止条件遇到需要用户输入的根本阻塞缺凭据、需求不清、外部服务挂了时停止报告同一问题连续 3 轮以上复发时报告为潜在根本问题reviewer 拒绝则修复后重验不是停。不适合 ralph 的情况想要从想法到代码的完整自主管线改用 autopilot、想先探索规划用plan、一次性快修直接委派 executor。ultrawork 在 5.x 中的位置ultrawork的定位在 mode-hierarchy.md 里写得很明确它是 component only——只做并行 agent 调度没有持久化、没有验证循环并行度有、持久化无、验证无。它的设计用途是被 ralph 和 autopilot 内部复用。在 5.0.0 之后你需要并行执行 人工监督选择指南里 ultrawork 那一行的场景时文档给出的落点是协调式并行 worker →/teamMIGRATION.md 的替代映射Use/teamwhen you want coordinated parallel workers单条并行执行 →/oh-my-claudecode:execute。ultrawork的状态文件ultrawork-state.json仍出现在模式状态表里见 mode-hierarchy.md取消命令也会清理它——这是 ralph/autopilot 内部并行阶段留下的状态不代表你还要直接调用 ultrawork 命令。组合规则哪些能叠哪些互斥来自 mode-selection-guide.md 的组合表组合效果eco ralphRalph 持久化 廉价档 agenteco ultrawork并行执行 廉价档 agenteco autopilot自主执行 成本控制无效组合组合原因autopilot team两者都是 standalone只能选一个eco单独使用修饰模式必须有被修饰的执行模式eco的触发关键词是 eco、budget作用是让模型路由偏好廉价档mode-hierarchy 说明它does NOT include persistence — thats ralphs job。除了模式间互斥还有一条更硬的规则一个会话只有一个主循环权威。选择指南的 Goal-Oriented Workflow Selection 一节要求 Ralph、Team、/goal、artifact-only Ultragoal 之间只选一个持久化循环作为主权威不同时跑竞争的持久化循环冲突处理使用确定性的refuse、adopt_existing、artifact_only策略。各循环的适用边界文档表格的要点Claude Code/goal单一可度量完成条件、需要跨轮持续注意其评判者只看会话中已呈现的证据不会独立跑命令或读文件Ralph单所有权实现必须完成全部 PRD story 且经 reviewer 验证Team显式任务所有权的并行工作 分阶段验证Artifact-only Ultragoal只有持久目标台账/检查点、没有活动执行循环时的规划与交接场景。另外 HOOKS.md 给出了钩子层的冲突裁决顺序cancel 优先级最高其次 ralph autopilot ultrawork。如果你同时触发了多个模式关键词按这个顺序理解哪个生效。运行中怎么核对状态结束后怎么验证运行中HUD 状态栏显示当前阶段、活跃 agent 数、任务完成数与上下文占用前文 autopilot 的示例同样适用于其他模式状态文件位于.omc/state/{name}.json项目级全局备份在~/.omc/state/{name}.json模式与文件的对应关系模式状态文件ralphralph-state.jsonautopilotautopilot-state.jsonultraworkultrawork-state.jsonteamteam-state.json另有.omc/handoffs/阶段交接文档文档特别强调不要把 OMC 状态存进~/.claude/那是 Claude Code 自己的目录。结束后三个模式的完成都不是以进程停下来的那一刻为准而是以各自证据为准autopilot 看 Phase 4 全验证者批准 新鲜测试/构建输出ralph 看 prd.json 全passes: true 新鲜测试/构建 reviewer 批准 回归重验证通过team 看全部真实任务终态 shutdown 确认 状态已清理。清理统一走/oh-my-claudecode:cancel——它自动检测活跃模式autopilot、ralph、ultrawork、pipeline 等不要手动删状态文件替代它。如果你的任务同时命中了多个模式关键词例如 dont stop 并 build me 一个 REST API按本文的决策顺序先确定主循环权威持久化 → ralph单一交付物自主 → autopilot其余模式只作为其内部组件出现而不是并排调用。【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
oh-my-claudecode 的执行模式怎么选？autopilot、team、ralph 与 ultrawork 的决策依据
oh-my-claudecode 的执行模式怎么选autopilot、team、ralph 与 ultrawork 的决策依据【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode在 oh-my-claudecodeOMC里跑任务时第一步往往是选执行模式一个产品想法要一路自动走到可运行代码用autopilot要多个 worker 并行认领任务池用/team要不验证通过就不停的持久化循环用ralph而ultrawork则是被它们复用的并行执行引擎。选错模式的代价是autopilot 会对单点小修发起五阶段重流程team 会把一个人能更快干完的工作套上协调开销。这篇文章基于仓库内的模式选择文档和三个模式各自的 SKILL 文档给出一条可执行的决策路径按什么问题选哪个模式、命令怎么调、以及跑完后拿什么证据判断它真的完成了。适用前提已安装 Claude Code 并装好 OMC 插件Claude Max/Pro 订阅或ANTHROPIC_API_KEY安装与omc-doctor验证步骤见 GETTING-STARTED.md本文依据的仓库版本标记为 5.0.2CLAUDE.md 中的OMC:VERSION注释。先分清四种模式类型以及一个版本事实mode-selection-guide.md 把模式分成四类这个分类决定了哪些模式可以叠加、哪些互斥类型模式说明Standalone独立autopilot、team各自独立运行互相冲突Wrapper包装ralph在 ultrawork 外层加持久化循环 验证Component组件ultrawork只做并行 agent 调度没有持久化、没有验证循环Modifier修饰eco修改模型路由以偏好的廉价档不能单独使用mode-hierarchy.md 给出的继承关系autopilot (autonomous end-to-end) ├── includes: ralph (persistence) │ └── includes: ultrawork (parallelism) └── includes: plan (strategic thinking) ralph (persistence wrapper) └── includes: ultrawork (parallelism engine) (adds: loop until done architect verification) ultrawork (parallelism engine) └── COMPONENT only - parallel agent spawning (no persistence, no verification loop)写作与选型时必须注意的版本事实5.0.0 起ultrawork、ultrapilot、swarm、pipeline、ultraqa等 17 个名字被整体移除且不作为别名保留CLAUDE.md、MIGRATION.md。也就是说在 5.x 里ultrawork不再是可直接调用的独立命令官方替代映射是/oh-my-claudecode:execute或/team协调式并行 worker 用/teamultrapilot和swarm则并入team。而模式选择文档里仍把ultrawork作为模式列出——那描述的是 ralph/autopilot 内部的并行引擎概念不再是独立入口。本文按这条边界处理涉及并行的选型落到/team或/oh-my-claudecode:execute。按三个问题走一遍决策流程mode-selection-guide.md 的决策流程图按下面的顺序提问不确定需求、想法模糊 ├── YES: 先用 deep-interview 澄清再执行 └── NO: 继续 想要自主执行autonomous ├── YES: 任务能拆成 3 个以上独立组件吗 │ ├── YES: team N:executor带文件所有权的并行自主执行 │ └── NO: autopilot顺序执行 ralph 阶段 └── NO: 想要并行执行 人工监督 ├── YES: 要成本控制吗 → 是: eco 并行模式否: 纯并行 └── NO: 需要直到验证通过才停 ├── YES: ralph持久化 并行 验证 └── NO: 标准编排直接向 agent 委派 有大量相似的独立任务例如修 47 个错误 └── YES: team N:executorN 个 agent 从任务池认领判断依据是任务结构不是个人偏好。文档给出的示例原文示例可直接对照自己的任务任务描述文档示例文档推荐模式原因Build me a REST APIautopilot单一连贯交付物Build frontend, backend, and databaseteam 3:executor组件边界清晰Fix all 47 TypeScript errorsteam 5:executor大量独立相似任务Refactor auth module thoroughlyralph需要持久化 验证Quick parallel executionultrawork5.x 中对应 /team 或 execute偏好人工监督的并行Dont stop until doneralph持久化关键词触发需求模糊时不要直接进执行模式文档建议先跑/deep-interview用苏格拉底式提问澄清模糊想法并暴露隐藏假设之后再进 autopilot——autopilot 检测到.omc/specs/deep-interview-*.md已存在时会直接把它当 Phase 0 输出。autopilot从想法到已验证代码的自主链路触发方式关键词autopilot、build me、I want a或直接/oh-my-claudecode:autopilot taskGETTING-STARTED.md 的首个任务示例就是一行autopilot build me a hello world app。执行结构autopilot SKILLPhase 0 扩展需求 → Phase 1 规划planner 出计划、critic 审计划→ Phase 2 执行executor 按任务难度分 haiku/sonnet/opus独立任务并行→ Phase 3 QA → Phase 4 多视角验证 → Phase 5 清理状态文件。何时判断该停下/继续文档给了明确的停止条件QA 循环最多 5 轮同一个错误连续出现 3 次 → 停止并报告根本问题等人工介入验证architect 功能完整性、security-reviewer 漏洞、code-reviewer 质量要求三方全部批准被拒项修复后重新验证重验证失败累计 3 轮后停止报告用户说 stop/cancel/abort 即停。完成判定SKILL 的 Final Checklist5 个阶段全部完成、Phase 4 全部验证者批准、有新鲜的测试运行输出且全部通过、有新鲜构建输出且成功、状态文件已清理。运行中可通过 Claude Code 状态栏 HUD 观察文档示例输出非固定预期[OMC] autopilot:execution | agents:3 | todos:2/5 | ctx:45%恢复取消或失败后重新运行/oh-my-claudecode:autopilot会从断点继续/oh-my-claudecode:cancel会保留进度。不适合 autopilot 的情况SKILL 的 Do_Not_Use_When想探索方案/头脑风暴用plan、单一聚焦的代码修改用ralph或直接委派 executor、快速小修直接委派。team并行 worker 分阶段验证触发与语法team SKILL/oh-my-claudecode:team N:agent-type task description /oh-my-claudecode:team task description /oh-my-claudecode:team ralph task descriptionN是 worker 数量范围 1–20缺省时按任务分解自动定规模agent-type只覆盖team-exec阶段的 worker 类型executor、debugger、designer 等其余阶段由 lead 按阶段路由表选专用 agent文档示例/team 5:executor fix all TypeScript errors across the project、/team 3:debugger fix build errors in src/。执行结构是固定管道team-plan → team-prd → team-exec → team-verify → team-fix循环。每个阶段切换时 lead 会写 handoff 文档到.omc/handoffs/stage-name.md记录已决定/已拒绝/风险/遗留项验证失败生成 fix 任务回流team-fix有次数上限max_fix_loops默认 3超过即转终态failed不会无限循环。完成判定所有真实任务非内部任务在任务列表中标记completed或到达带证据的明确 failed/blocked 终态随后 lead 逐个向 teammate 发shutdown_request、等shutdown_response30 秒超时确认后才清理 OMC 状态并删除.omc/state/team-state.json。终态只有三种complete、failed、cancelled。取消与恢复/oh-my-claudecode:cancel处理 team 清理lead 崩溃后可通过state_read(modeteam)找到最后阶段并从该阶段恢复而不是重复 spawn worker。两个使用边界平台检查原生 Windows 上先运行tmux -V确认 tmux 兼容二进制psmux 受支持不要直接告知用户必须 WSL只有确实没有 tmux 兼容二进制时才建议安装 psmux 或改用 WSL2。team ralph组合team 管道包在 ralph 持久化循环里team-verify通过后 ralph 再做 architect 验证至少 STANDARD 档任一侧取消都会连带取消另一侧。不适合 team 的情况选择指南的 Avoid when 一列写明——一个人能比协调开销更快地干完时不要用 team。ralph以 PRD 为完成依据的持久化循环触发方式关键词ralph、dont stop、must complete、keep going until done或/oh-my-claudecode:ralph taskralph SKILL。执行结构ralph 是 PRD 驱动的循环——启动时会生成prd.json脚手架活动状态在.omc/state/sessions/{sessionId}/prd.json你必须先把脚手架里 Implementation is complete 这类泛化验收标准替换成任务专属标准例如函数 X 在给定 Z 时返回 Y然后逐条 story 实现、逐条验收、把passes置为true直到所有 story 通过。验证是 ralph 与跑到一半就宣称完成的区别选--criticarchitect默认、--criticcritic或--criticcodex指定完成审核者审核档位小于 5 个文件、少于 100 行且有完整测试 → 至少 STANDARD 档Sonnet超过 20 个文件或涉及安全/架构变更 → THOROUGH 档Opus审核者是针对 prd.json 里的具体验收标准审不是泛泛问完成了吗批准后还要过 Step 7.5 的ai-slop-cleaner清理与 Step 7.6 的回归重验证测试/构建/lint 全重跑最后才/oh-my-claudecode:cancel干净退出可用--no-deslop跳过清理。完成判定Final Checklist 摘录所有 prd.json story 为passes: true且无未验证的活跃标准新鲜的测试运行输出全绿、构建输出成功所选 reviewer 针对具体标准批准/oh-my-claudecode:cancel已执行。停止条件遇到需要用户输入的根本阻塞缺凭据、需求不清、外部服务挂了时停止报告同一问题连续 3 轮以上复发时报告为潜在根本问题reviewer 拒绝则修复后重验不是停。不适合 ralph 的情况想要从想法到代码的完整自主管线改用 autopilot、想先探索规划用plan、一次性快修直接委派 executor。ultrawork 在 5.x 中的位置ultrawork的定位在 mode-hierarchy.md 里写得很明确它是 component only——只做并行 agent 调度没有持久化、没有验证循环并行度有、持久化无、验证无。它的设计用途是被 ralph 和 autopilot 内部复用。在 5.0.0 之后你需要并行执行 人工监督选择指南里 ultrawork 那一行的场景时文档给出的落点是协调式并行 worker →/teamMIGRATION.md 的替代映射Use/teamwhen you want coordinated parallel workers单条并行执行 →/oh-my-claudecode:execute。ultrawork的状态文件ultrawork-state.json仍出现在模式状态表里见 mode-hierarchy.md取消命令也会清理它——这是 ralph/autopilot 内部并行阶段留下的状态不代表你还要直接调用 ultrawork 命令。组合规则哪些能叠哪些互斥来自 mode-selection-guide.md 的组合表组合效果eco ralphRalph 持久化 廉价档 agenteco ultrawork并行执行 廉价档 agenteco autopilot自主执行 成本控制无效组合组合原因autopilot team两者都是 standalone只能选一个eco单独使用修饰模式必须有被修饰的执行模式eco的触发关键词是 eco、budget作用是让模型路由偏好廉价档mode-hierarchy 说明它does NOT include persistence — thats ralphs job。除了模式间互斥还有一条更硬的规则一个会话只有一个主循环权威。选择指南的 Goal-Oriented Workflow Selection 一节要求 Ralph、Team、/goal、artifact-only Ultragoal 之间只选一个持久化循环作为主权威不同时跑竞争的持久化循环冲突处理使用确定性的refuse、adopt_existing、artifact_only策略。各循环的适用边界文档表格的要点Claude Code/goal单一可度量完成条件、需要跨轮持续注意其评判者只看会话中已呈现的证据不会独立跑命令或读文件Ralph单所有权实现必须完成全部 PRD story 且经 reviewer 验证Team显式任务所有权的并行工作 分阶段验证Artifact-only Ultragoal只有持久目标台账/检查点、没有活动执行循环时的规划与交接场景。另外 HOOKS.md 给出了钩子层的冲突裁决顺序cancel 优先级最高其次 ralph autopilot ultrawork。如果你同时触发了多个模式关键词按这个顺序理解哪个生效。运行中怎么核对状态结束后怎么验证运行中HUD 状态栏显示当前阶段、活跃 agent 数、任务完成数与上下文占用前文 autopilot 的示例同样适用于其他模式状态文件位于.omc/state/{name}.json项目级全局备份在~/.omc/state/{name}.json模式与文件的对应关系模式状态文件ralphralph-state.jsonautopilotautopilot-state.jsonultraworkultrawork-state.jsonteamteam-state.json另有.omc/handoffs/阶段交接文档文档特别强调不要把 OMC 状态存进~/.claude/那是 Claude Code 自己的目录。结束后三个模式的完成都不是以进程停下来的那一刻为准而是以各自证据为准autopilot 看 Phase 4 全验证者批准 新鲜测试/构建输出ralph 看 prd.json 全passes: true 新鲜测试/构建 reviewer 批准 回归重验证通过team 看全部真实任务终态 shutdown 确认 状态已清理。清理统一走/oh-my-claudecode:cancel——它自动检测活跃模式autopilot、ralph、ultrawork、pipeline 等不要手动删状态文件替代它。如果你的任务同时命中了多个模式关键词例如 dont stop 并 build me 一个 REST API按本文的决策顺序先确定主循环权威持久化 → ralph单一交付物自主 → autopilot其余模式只作为其内部组件出现而不是并排调用。【免费下载链接】oh-my-claudecodeTeams-first Multi-agent orchestration for Claude Code项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-claudecode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考