基于 Yeachan-Heo/oh-my-claudecode 仓库源码分析
OMC 的 Agent 按模型能力分为三个梯队，决定了推理深度与成本的平衡。
1.1 Opus 梯队（claude-opus-4-6）— 深度推理
用于分析、规划、评审等需要深度思考的场景。
1.2 Sonnet 梯队（claude-sonnet-4-6）— 执行主力
用于实现、调试、测试和动手调查等日常工作负载。
1.3 Haiku 梯队（claude-haiku-4-5）— 轻量快速
用于快速搜索和文档生成等对速度敏感的场景。
2.1 调用了 Agent 的 Skill（共 14 个）
/plan — 结构化规划
用途： 通过多角色协作创建高质量工作计划
explore haiku 扫描代码库，建立上下文 需求分析
analyst opus 将需求转化为验收标准 方案规划
planner opus 创建可执行的工作计划 架构审查
architect opus 审查方案的架构合理性 批判审查
critic opus 多视角查找方案缺陷
调用模式： 顺序流水线（explore → analyst → planner → architect → critic）
/ralph — 智能代码审查与修复
用途： 对变更代码进行架构审查 + 批判审查 + 自动修复
architect opus 审查代码变更的架构影响 批判审查
critic opus 查找代码缺陷和弱点 代码修复
executor sonnet 根据审查意见修复代码 代码清理
ai-slop-cleaner（Skill） — 清理 AI 生成的冗余代码
调用模式： 顺序流水线 + Skill 间调用（architect → critic → executor → ai-slop-cleaner）
/autopilot — 自动驾驶开发
用途： 全自动的分析-规划-执行-审查循环
analyst opus 理解任务需求 架构设计
architect opus 设计实现方案 方案审查
critic opus 评审方案质量 代码实现
executor sonnet 执行代码变更 安全审查
security-reviewer opus 检查安全漏洞 代码审查
code-reviewer opus 评审代码质量
调用模式： 带条件分支的循环流水线（analyst → architect → critic → executor → security-reviewer → code-reviewer，不通过则回到 executor 修复）
/ultrawork — 极简执行器
用途： 直接将任务交给 executor 执行，支持分层模型路由
executor sonnet（默认） 直接执行任务 执行（复杂）
executor opus（可选） 通过参数或复杂度触发升级
调用模式： 单 Agent 直接调用，支持模型分层路由
/team — 全团队协作
用途： 模拟完整软件团队，5 阶段流水线交付
explore haiku 代码库探索
planner opus 创建工作计划
analyst opus 需求分析 2. team-prd 架构设计
architect opus 产出架构设计文档 3. team-exec 并行执行
executor sonnet 多个 executor 并行实现
designer sonnet UI/UX 实现
debugger sonnet 调试修复
writer haiku 文档编写
test-engineer sonnet 测试编写
scientist sonnet 数据分析研究 4. team-verify 全面验证
verifier sonnet 功能验证
security-reviewer opus 安全审查
code-reviewer opus 代码审查 5. team-fix 修复循环
executor sonnet 根据审查意见修复
调用模式： 5 阶段流水线（team-plan → team-prd → team-exec → team-verify → team-fix），第 3 阶段内部并行
使用 Agent 数量： 13 个（OMC 中最多）— explore, planner, analyst, architect, executor, debugger, designer, writer, test-engineer, verifier, security-reviewer, code-reviewer, scientist
/ultraqa — 交互式 QA 测试
用途： 通过真实交互验证应用行为
architect opus 设计测试方案 交互测试
qa-tester sonnet 通过 tmux 执行交互式测试 修复验证
executor sonnet 修复发现的问题
调用模式： 顺序流水线（architect → qa-tester → executor），可循环
/ralplan — 共识规划
用途： /plan –consensus 的别名，多规划者共识收敛
planner opus 多个 planner 并行产出方案 架构审查
architect opus 审查各方案的架构合理性 共识评审
critic opus 在多个方案间找到共识
调用模式： 并行扇出 + 共识收敛（多 planner 并行 → architect 审查 → critic 评选）
/sciomc — 科学研究执行
用途： 并行执行数据分析和研究任务
scientist sonnet（默认） 数据分析和 Python 研究 研究执行（深度）
scientist opus（可选） 复杂分析升级为 opus
调用模式： 并行扇出 + 模型分层路由（多个 scientist 并行执行）
/deep-interview — 深度代码库访谈
用途： 对棕地（已有）代码库进行深度分析
explore haiku 全方位扫描代码库结构和关系
调用模式： 单 Agent 深度调用，后可串联到 /ralplan → /autopilot 流水线
/deepinit — 深度项目初始化
用途： 为新项目创建深度的项目文档和架构
explore haiku 了解项目结构 架构分析
architect opus 分析和规划项目架构 文档编写
writer haiku 编写项目文档
调用模式： 顺序流水线（explore → architect → writer）
/external-context — 外部文档检索
用途： 并行搜索外部文档和参考资料
document-specialist sonnet 按分解后的搜索面并行检索
调用模式： 并行扇出（分解查询为 2-5 个搜索面 → 最多 5 个 document-specialist 并行 → 综合报告）
/self-improve — 自主进化引擎
用途： 自主循环的代码改进，带锦标赛选择和崩溃恢复
si-researcher.md） opus 研究改进方向 基准构建 自定义（
si-benchmark-builder.md） opus 构建基准测试（仅初始化阶段） 并行规划
planner opus N 个 planner 并行产出改进方案 架构审查
architect opus 逐方案审查架构（顺序，在 critic 之前） 方案把关
critic opus 逐方案把关（顺序，在 architect 之后） 并行执行
executor opus N 个 executor 在独立 worktree 中并行实现 锦标赛选择
git-master sonnet 合并、打标签、归档候选方案
调用模式： 自主无限循环（Steps 0-11 持续运行），包含并行扇出（N planner + N executor）、顺序审查管线（architect → critic）、锦标赛选择与回滚、失败重试一次、基于 iteration_state.json 的崩溃恢复
/trace — 因果追踪
用途： 通过竞争假说调查观测结果的根因
tracer sonnet（默认） 3 条独立调查通道并行执行
调用模式： Lead-Worker 架构（Lead 生成 3 个假说 → 3 个 tracer worker 并行调查 → 反驳轮 → 收敛/分离检测 → 排序综合）。使用 Claude 内建 team 模式，通过 YAML frontmatter 声明 agent: tracer
/writer-memory — 写作记忆系统
用途： 小说写作的角色、关系、场景记忆管理
architect opus 复杂角色弧线跨场景分析
调用模式： 条件式按需调用（仅在需要深度角色分析时触发），其余 CRUD 操作不涉及 Agent
2.2 未调用 Agent 的 Skill（共 20 个）
omc ask 路由到外部 CLI（Claude/Codex/Gemini） CLI 路由，非 Agent 委派
cancel 取消当前运行模式 状态管理工具
debug 调试辅助 简单工具 Skill
hud 配置 OMC 状态栏显示 配置/设置类
learner 从对话中提取可复用的技能 自改进类（Level 7），无 Agent
mcp-setup 配置 MCP 服务器 交互式设置向导
omc-doctor 诊断和修复 OMC 安装问题 6 步诊断流水线
omc-reference OMC 内建参考手册 被动文档（
user-invocable: false）
omc-setup OMC 安装/刷新/修复 4 阶段设置流水线
omc-teams 通过 tmux 启动外部 CLI 工作进程 OS 级进程管理，非 Agent
project-session-manager Worktree 开发环境管理 Git/tmux 会话管理
release 通用发布助手 8 步顺序发布流水线
remember 会话知识路由到正确的记忆面 分类 + 路由工具
setup 统一设置入口 路由到 omc-setup/omc-doctor/mcp-setup
skill Skill 管理元工具 列出/添加/删除/搜索 Skill
skillify 将重复工作流转化为 Skill 草稿 6 步线性流程
verify 验证工具 简单工具 Skill
visual-verdict 视觉 QA 判定器 无状态评估器，设计为被外部循环调用
wiki 持久化 Markdown 知识库 CRUD 数据层
以下统计每个 Agent 被多少个 Skill 直接调用。
关键发现：
architect是被调用频次最高的 Agent（9 个 Skill），反映了“架构审查”在 OMC 工作流中的核心地位executor紧随其后（6 个 Skill），体现了“执行”作为最终落地环节的普遍性code-simplifier是唯一未被任何 Skill 直接调用的 Agent，可能设计为用户直接通过 Agent 方式调用/team是覆盖面最广的 Skill，使用了 13⁄19 个 Agent
OMC 中的 Skill 使用了以下几种典型的 Agent 调用模式：
4.1 顺序流水线（Sequential Pipeline）
特征：Agent 按固定顺序依次执行，前一个的输出作为后一个的输入。
A → B → C → D 代表 Skill：
/plan：explore → analyst → planner → architect → critic/deepinit：explore → architect → writer/ralph：architect → critic → executor → ai-slop-cleaner
4.2 并行扇出（Parallel Fan-out）
特征：多个同类 Agent 同时执行独立子任务，完成后汇总。
┌→ Agent-1 ─┐ Input ──┼→ Agent-2 ──┼→ Merge └→ Agent-N ─┘
代表 Skill：
/external-context：2-5 个 document-specialist 并行搜索/sciomc：多个 scientist 并行研究/ralplan：多个 planner 并行规划后共识收敛
4.3 分阶段流水线（Staged Pipeline）
特征：多个阶段顺序执行，每个阶段内部可能有并行。
Stage-1 → Stage-2 → Stage-3(并行) → Stage-4 → Stage-5 代表 Skill：
/team：team-plan → team-prd → team-exec(并行) → team-verify → team-fix/autopilot：analyst → architect → critic → executor → reviewer(s) → fix loop
4.4 Lead-Worker 架构
特征：Lead 分配任务给多个 Worker，Worker 独立执行后 Lead 汇总。
Lead: 生成假说 ├→ Worker-1: 调查假说 A ├→ Worker-2: 调查假说 B └→ Worker-3: 调查假说 C Lead: 反驳轮 + 综合 代表 Skill：
/trace：Lead 生成 3 假说 → 3 tracer 并行调查 → 反驳 → 排序
4.5 自主循环（Autonomous Loop）
特征：无限循环执行，直到满足退出条件。
┌→ Research → Plan(并行) → Review → Execute(并行) → Select → ─┐ └─────────────────────── Loop ←──────────────────────────────┘ 代表 Skill：
/self-improve：研究 → N 并行规划 → 逐个审查 → N 并行执行 → 锦标赛选择 → 循环
4.6 单 Agent 直接调用
特征：只调用一个 Agent，可能有模型分层路由。
Input → Agent (model routing) → Output 代表 Skill：
/ultrawork：直接调用 executor/deep-interview：直接调用 explore/sciomc（单任务模式）：直接调用 scientist
4.7 条件式按需调用
特征：大部分时间不调用 Agent，仅在特定条件下触发。
代表 Skill：
/writer-memory：仅在需要深度角色弧线分析时调用 architect
部分 Skill 之间存在调用或串联关系：
/setup ──路由──→ /omc-setup /omc-doctor /mcp-setup /ralph ──调用──→ /ai-slop-cleaner（清理阶段）
/deep-interview ──串联──→ /ralplan ──串联──→ /autopilot （推荐的完整工作流：探索 → 共识规划 → 自动执行）
/ralplan ≡ /plan –consensus（别名关系）
/skill ──可触发──→ /learner（扫描对话模式）
/team ──区别于──→ /omc-teams（前者用 OMC Agent，后者用外部 CLI 进程）
下表展示所有使用了 Agent 的 Skill 与 Agent 的交叉关系。● 表示直接调用，○ 表示通过 team 模式或特殊机制调用。
OMC 中 Agent 的模型选择遵循以下规律：
model 参数覆盖默认模型 self-improve 中 executor 升级为 opus
动态路由 根据任务复杂度或用户参数选择模型 ultrawork 支持
–opus 标志升级
成本优化 搜索和文档任务使用低成本模型 explore 用 haiku，writer 用 haiku
实际模型使用情况：
按用途找 Skill
/plan 5 多方案共识规划
/ralplan 3 全自动开发
/autopilot 6 快速执行一个任务
/ultrawork 1 模拟完整团队
/team 13 审查代码变更
/ralph 3 + 1 Skill 交互式 QA 测试
/ultraqa 3 数据分析
/sciomc 1 了解代码库
/deep-interview 1 初始化项目文档
/deepinit 3 查找外部文档
/external-context 1 自主代码改进
/self-improve 5 + 2 自定义 追踪问题根因
/trace 1 管理写作记忆
/writer-memory 1
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/267518.html