26.3 架构蓝图：Oh-My-Claude-Code
模型: claude-opus-4-6 (anthropic/claude-opus-4-6) 生成日期: 2026-04-01 书名: Claude Code VS OpenCode：架构、设计与未来 章节: 第26章 — 设计“Oh-My-Claude-Code“ Token 消耗: ~7,100 输入 + ~1,300 输出
在上一节我们看到，Claude Code 的扩展 API 覆盖了构建多智能体编排层约 40% 的能力需求。这一节的问题是：在这 40% 的地基上，能搭出什么样的建筑？
答案是：一个以系统提示词为编排引擎、自定义智能体为执行单元、MCP 为工具扩展层的架构。它不如 Oh-My-OpenCode 那样能深入对话引擎内部，但足以实现多智能体协作、任务委派、专业化分工和持久化记忆。
26.3.1 核心设计原则
Oh-My-Claude-Code 的架构建立在三个约束下的最优化原则上：
原则一：提示词即编排器。 既然无法通过钩子拦截消息流，那就把编排逻辑直接写进系统提示词。这就是“Sisyphus 提示“方法——把任务分解规则、委派策略、完成验证、续接逻辑全部编码为提示词中的行为指令。
衍生解释：Sisyphus 提示（Sisyphus Prompt）——源自希腊神话中西西弗斯反复推石上山的故事。在 Oh-My-OpenCode 中，这个概念指的是在系统提示词里嵌入“永不放弃“的续接逻辑：当智能体的上下文窗口耗尽或任务中断时，它会通过 todo 列表记录进度，在新会话中从断点继续。这种机制保证复杂任务不会因为单次会话限制而被放弃。将其迁移到 Claude Code，意味着在自定义智能体的 Markdown 定义中编码同样的续接规则。
原则二：智能体即微服务。 每个自定义智能体是一个有明确职责边界的执行单元，通过 AgentTool 被主智能体调度。这类似于微服务架构中服务间的 RPC 调用——调用方不关心被调用方的内部实现，只关心输入输出契约。
原则三：MCP 是唯一工具注入通道。 所有超出 Claude Code 内建工具的能力，都通过 MCP 服务器引入。
26.3.2 整体架构
┌─────────────────────────────────────────────────────────┐
│ 用户交互层 │
│ Claude Code TUI/IDE │
└─────────────────────┬───────────────────────────────────┘
│ 用户消息
▼
┌─────────────────────────────────────────────────────────┐
│ 主智能体 (Sisyphus) │
│ ┌─────────────────────────────────────────────────┐ │
│ │ 系统提示词 = 编排引擎 │ │
│ │ • 任务分析与分解规则 │ │
│ │ • 委派策略（何时派遣哪个子智能体） │ │
│ │ • Todo 纪律（必须维护任务列表） │ │
│ │ • 验证协议（LSP 检查 + 构建通过） │ │
│ │ • Sisyphus 续接（中断时保存进度） │ │
│ └─────────────────────────────────────────────────┘ │
│ │ │
│ AgentTool 委派 │ │
│ ┌────────────────┼────────────────┐ │
│ ▼ ▼ ▼ │
│ ┌────────┐ ┌───────────┐ ┌───────────┐ │
│ │ Oracle │ │ Explore │ │ Librarian │ │
│ │ 智能体 │ │ 智能体 │ │ 智能体 │ │
│ │ │ │ │ │ │ │
│ │ 深度 │ │ 代码库 │ │ 文档 │ │
│ │ 推理 │ │ 探索 │ │ 研究 │ │
│ └────────┘ └───────────┘ └───────────┘ │
│ ▲ ▲ ▲ │
│ └────────────────┼────────────────┘ │
│ │ │
│ 结果返回给主智能体 │
└─────────────────────┬───────────────────────────────────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
┌──────────┐ ┌─────────┐ ┌──────────┐
│ 内建工具 │ │ MCP │ │ CLAUDE.md│
│ Read/Edit│ │ 扩展 │ │ 记忆 │
│ Bash/Git │ │ AST-grep│ │ 系统 │
│ LSP/Glob │ │ Session │ │ │
└──────────┘ └─────────┘ └──────────┘
26.3.3 “Sisyphus 提示“方法详解
整个编排逻辑的核心在于主智能体的系统提示词。一个典型的 Sisyphus 提示词包含以下模块：
身份与角色定义——明确智能体是一个“专注执行者“，不做无谓的确认和寒暄，直接开始工作。
任务分解纪律——收到复杂任务时，必须先用 todowrite 工具创建原子化的任务列表，每次只标记一个任务为 in_progress，完成后立即标记 completed。
委派策略——明确在什么条件下应该派遣子智能体：需要深度代码分析时派遣 Explore 智能体、需要文档研究时派遣 Librarian 智能体、需要跨领域推理时派遣 Oracle 智能体。
反重复规则——一旦委派了探索任务给子智能体，主智能体禁止自己重复执行相同的搜索，避免浪费上下文预算。
验证协议——任务完成前必须运行 lsp_diagnostics 检查变更文件、确认构建通过、确认所有 todo 标记为完成。
终止纪律——首次验证成功后立即停止，最多检查 2 次状态，然后无论如何停止。
这种方法的本质是用自然语言编写一个有限状态机。它没有代码级的强制力（不像 Oh-My-OpenCode 的钩子可以在运行时拦截违规行为），但在实际使用中，高质量的 LLM 对提示词中的行为约束有很高的遵从度。
衍生解释：有限状态机（Finite State Machine, FSM）——计算机科学的基础概念，指一个系统在任意时刻处于有限个状态之一，根据输入事件在状态之间转换。这里的类比是：Sisyphus 提示词定义了智能体的状态（分析中、委派中、执行中、验证中、完成）以及触发状态转换的条件（任务复杂→委派、代码修改完→验证、验证通过→完成）。
26.3.4 智能体协作模型
与 Oh-My-OpenCode 的多智能体系统不同，Oh-My-Claude-Code 的智能体协作完全依赖 Claude Code 的原生 AgentTool。这意味着：
- 同步委派：主智能体调用子智能体时会等待其完成，不能真正并行。背景智能体需要通过 Claude Code 的 Task 系统实现。
- 无会话续接：子智能体每次被调用都是一个新会话，不保留之前的上下文。如果需要续接，必须在调用时显式传递之前的状态摘要。
- 统一模型：所有智能体使用同一个模型（Claude），无法像 Oh-My-OpenCode 那样为不同智能体分配不同的模型。
这些限制并非致命。对于大多数编码任务，同步委派已经足够；会话续接可以通过在提示中传递状态摘要来近似实现；统一模型在 Claude 的能力范围内通常不是瓶颈。
26.3.5 小结
Oh-My-Claude-Code 的架构蓝图不是 Oh-My-OpenCode 的完美复制品，而是在 Claude Code 扩展约束下的最优解。它用提示词工程替代了钩子拦截，用文件约定替代了编程式 API，用 MCP 替代了原生工具注册。这种架构的上限取决于两个因素：LLM 对提示词中编排指令的遵从度，以及 MCP 生态的丰富程度。
下一节，我们将这个蓝图拆解为可执行的实施阶段。