OC + OMO + STDD 三层融合架构分析：1+1+1 > 3 的 Token 效率革命

OC + OMO + STDD 三层融合架构分析（hermes分析三个仓库得到的报告，还没部署配置并投入项目开发）

三项目独立分析，探讨将 OpenCode 框架 + Oh My OpenAgent 编排 + STDD 流程方法论融合的可行性、架构设计与 Token 效率优势。

一、三项目核心定位

二、当前各自的问题

OpenCode 单独使用

• 强大的 Runtime 但无研发流程约束——完全依赖 Prompt 驱动
• Context System 很精巧，但 Context Sources 的加载策略需要外部指导
• 无内置质量门禁，所有"检查"都是 prompt 中的软约束

OMO 单独使用

• 53-60 个 Hook 带来巨大的 Context 开销（每个 Session 启动都要加载）
• 11 个 Agent + Team Mode 需要大量 Token 来维持协作状态
• 编排能力强但缺乏"该做什么"的流程指导——Agent 知道怎么工作但不知道该做什么工作

STDD 单独使用

• Skill 文件很大（6 个阶段 + 模板 + 规范），加载进 Prompt 消耗大量 Token
• 依赖外部 AI 平台的 Plugin/Skill 机制，无法深度集成到 Runtime 层
• CLI 工具链与 Agent 之间的交互靠 prompt 指令，不是原生协议

三、融合架构：三层分离

┌─────────────────────────────────────────────────────┐
│              STDD Process Layer (流程层)              │
│  ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐      │
│  │ P1   │ │ P2   │ │ P3   │ │ P4   │ │ P5/6 │      │
│  │Undst │ │ Spec │ │Slice │ │Build │ │Verify│      │
│  └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘      │
│     │        │        │        │        │           │
│  ┌──┴────────┴────────┴────────┴────────┴──┐        │
│  │    STDD Context Sources (Lazy Loaded)    │        │
│  │  Phase Rules │ Failure Checks │ History │        │
│  └──────────────┬──────────────────────────┘        │
├─────────────────┼───────────────────────────────────┤
│             OMO Orchestration Layer (编排层)          │
│  ┌──────────────────────────────────────────────┐   │
│  │   Lifecycle Hooks → Gate Enforcement (代码)   │   │
│  │  pre-tool: "此操作是否需要 Gate 确认?"         │   │
│  │  post-tool: "输出是否符合当前 Phase 规范?"      │   │
│  └──────────────────┬───────────────────────────┘   │
│  ┌──────────────────┴───────────────────────────┐   │
│  │   Agent Factory：按 Phase 切换 Agent          │   │
│  │  P1→Oracle(分析) P2→Librarian(设计)          │   │
│  │  P4→Sisyphus(实现) P5→Metis(审查)            │   │
│  └──────────────────┬───────────────────────────┘   │
│  ┌──────────────────┴───────────────────────────┐   │
│  │   Team Mode：P3 Slice → 并行分派              │   │
│  └──────────────────────────────────────────────┘   │
├─────────────────────────────────────────────────────┤
│          OpenCode Runtime Layer (基础设施层)          │
│  ┌──────────────────────────────────────────────┐   │
│  │  Context System Registry                      │   │
│  │  Stable Key → Lazy Loader → Codec → Render   │   │
│  │  Mid-Conversation System Message (增量)       │   │
│  └────────────────┬──────────────┬──────────────┘   │
│  ┌────────────────┴┐ ┌───────────┴──────────────┐   │
│  │ Tool Registry   │ │ LLM Provider Abstraction  │   │
│  │ MCP Adapters    │ │ Session Mgmt + Compaction │   │
│  └─────────────────┘ └──────────────────────────┘   │
└─────────────────────────────────────────────────────┘

四、Token 效率优势详解

4.1 Context Source 惰性加载 (Lazy Loading)

现状痛点： STDD 的 6 个 Phase Skill 文件全部加载到 Prompt，约 15-20KB 固定开销。

融合方案： 每个 STDD Phase 注册为一个 OC Context Source：

• 只有当前活跃 Phase 的 Source 被加载到 Baseline System Context
• Phase 切换时通过 Mid-Conversation System Message 增量更新，而非重新加载全部
• Context Epoch 提供自然的 Phase 边界——Compaction 时旧 Phase 知识自动退出

节省： ~12-18KB 固定 Token，仅在 Phase 边界产生微小的增量更新（~2-3KB）

4.2 Hook 替代 Prompt 指令 (Encode Rules in Code)

现状痛点： STDD 的"请记得做 11 类失败模式检查"是一段 Prompt 指令，LLM 必须理解和执行。

融合方案： OMO 的 tool.execute.after Hook 捕获每个工具调用输出，在代码中执行失败模式检查：

• 幻觉行为检测 (a)：Hook 检查工具输出中的文件路径是否存在
• 范围蔓延检测 (b)：Hook 对比修改文件列表与 Scope 定义
• 覆盖真空检测 (j)：Hook 在测试执行后检查测试覆盖率

这些检查逻辑不是 LLM 推理的一部分——它们是确定性代码，零 Token 开销。

节省： ~3-5KB 的"请检查..."类 Prompt 被移除；检查更精确（代码 vs LLM 猜测）

4.3 MCP 工具替代 Prompt 知识 (Tool over Prompt)

现状痛点： STDD 的 CLI (validate/trace/diff) 通过 prompt 指令让 AI 调用终端。

融合方案： OMO 的 3 层 MCP 系统将 STDD CLI 注册为 Mo 原生 MCP 工具：

• stdd_validate → 无需在 prompt 中写"请运行 python bin/stdd validate"
• stdd_trace → 直接通过 Tool Registry 暴露，LLM 自动发现
• stdd_diff → 结构化输出，LLM 直接消费

节省： ~2-4KB 的工具调用指令被移除；工具发现自动完成（OpenAPI Schema → OC Tool Registry）

4.4 Agent 专业化 = 上下文隔离 (Specialized Context Isolation)

现状痛点： 一个 Agent 全知全能，Prompt 包含全栈知识。

融合方案： OMO 的 11 个 Agent 对应 STDD 的不同 Phase：

节省： 从 ~20KB 全栈知识 → 每个 Agent 仅 ~2-5KB = 节省 75-90%

4.5 并行切片减少上下文切换 (Parallel Reduce Context Thrash)

现状痛点： LLM 在单 Session 中串行处理 N 个切片，每切换一个切片需要 Context 重建。

融合方案： OMO Team Mode 为每个切片启动独立 Agent 会话：

• 每个 Agent 只有自己的切片的上下文（约 2-5KB）
• 主 Agent 只负责协调和合并结果
• N 个切片并行，总 Token 是 N×(切片上下文) 而非 N×(全量上下文)

节省： N=4 时，从 4×20KB=80KB → 4×3KB + 主协调 3KB = 15KB = 节省 81%

4.6 Gate 逻辑代码化 (Gate Logic in Code)

现状痛点： STDD 的 3 道 Gate 是 Prompt 中的"请用户确认"指令——LLM 可能跳过或忘记。

融合方案： Gate 由 OMO Hook 强制执行：

• chat.message Hook：检测是否进入新 Phase → 检查前一 Phase 的产出物是否存在
• tool.execute.before Hook："你想写代码？Gate 2 确认了吗？"→ 未确认则拒绝
• Gate 状态存储在 OC Session 的持久化 Context Source 中

Gate 不是"请记住"的软约束，而是平台级硬约束，0 Token 开销。

五、Token 效率量化对比

六、1+1+1 > 3 的涌现效应

6.1 OC 解决"怎么执行"——Context 框架是关键

OC 的 Context System Registry (stable key, lazy loader, codec, pure renderer, mid-conversation system message) 是一个一等公民的上下文管理系统。STDD 的 Phase知识不再是"prompt 中的一段文字"，而是注册的 Context Source，具有以下特性：

• 惰性加载（只在需要时执行 loader）
• 增量更新（changed source → mid-conversation system message，非全量替换）
• 持久化（Context Snapshot 跨 Session 重启存活）
• Provider 中立（渲染为纯文本，不依赖特定 LLM 的 system prompt 格式）

6.2 OMO 解决"怎么编排"——Hook 是 Token 节省的关键

OMO 的 14 个 OpenCode Hook Handlers 提供了 5 层 Hook 组合（Core + ToolGuard + Transform + Continuation + Skill），这是将约束从 Prompt 移到代码的核心机制。每条从 Prompt 移入 Hook 的规则，都是永久节省的 Token：

• 代码执行的检查比 LLM 推理更便宜——一个 if (!gatePassed) 的成本是纳秒级，LLM "记住要检查 Gate" 的成本是数千 Token
• 代码检查更可靠——LLM 可能在长上下文中"忘记"，Hook 不会
• 代码检查可测试——Hook 逻辑可以单元测试，Prompt 指令不能

6.3 STDD 解决"该做什么"——流程提供结构性

STDD 的 6 Phase + 3 Gate + 11 类检查不仅仅是"应该做的事情"，它提供了一个可编码的流程契约：

• Phase 产出物（proposal.md / design.md / specs / test-plan.md）有明确的结构和模板
• Gate 条件有明确的判断标准（文件存在、字段完整、用户确认标记）
• 失败模式有明确的检测规则（可转化为 Hook 中的代码断言）

这种结构性使得流程可以被代码理解和执行，而不仅仅是提示 LLM。

6.4 量变到质变：从"引导 AI"到"AI 遵循协议"

传统 AI Coding Workflow 本质上是 "告诉 AI 怎么做"（Prompt Engineering），把工作推给推理引擎。融合后：

七、总结论

能。OC + OMO + STDD 融合是 Token 效率的最优解。

三个项目各自解决不同层次的问题，互补而不重叠：

• OC 提供 Runtime 层的 Context 框架和插件系统——是"怎么做"的基础设施
• OMO 提供编排层的 Hook 系统和 Agent 工厂——是"谁来做"的调度中心
• STDD 提供流程层的方法论和质量门禁——是"做什么"的规范指南

Token 效率提升的根源不是"减少 Prompt 长度"这种浅层优化，而是将底层结构性约束从 LLM 的推理空间迁移到确定性代码空间。每一次从 Prompt 到 Hook/Context Source/MCP Tool 的迁移，都是永久性的 Token 节省。当 N 个切片并行时，这种节省呈指数级放大。

实际效果预估：一个中等复杂度的变更（4 切片，6 Phase），传统 Prompt 方式约 120-150KB Token，融合架构约 25-35KB Token，整体节省 4-5 倍。更重要的是，质量确定性从"LLM 今天心情不错"变为"平台强制执行"。