第十二章实战案例与设计评价（三系统对比）

前几章从技术维度剖析了三个系统的各个子系统。本章切换视角：先通过实战案例展示它们在真实场景中的行为差异，再对各自的设计亮点和不足进行综合评价。

12.1 实战案例

案例一：用户要求"添加 JWT 认证"

同一个需求在三个系统中的处理流程截然不同。

OmO（多 Agent 编排）

用户: "给 REST API 添加 JWT 认证"

Phase 0: 意图识别
  Sisyphus: "实现请求 + 外部库(JWT) + 多模块(路由/中间件/数据库)"
  → 触发: Explore×2 + Librarian×2 并行

Phase 1: 四路并行探索（~10秒）
  [Explore #1] 查找 auth 中间件、登录处理器
  [Explore #2] 查找错误处理模式、Error 子类
  [Librarian #1] JWT 安全最佳实践（OWASP 指南）
  [Librarian #2] Express 生产级 auth 模式
  + 同步创建 6 项 Todo 列表

Phase 2: 结果收集 → 发现项目已有 bcrypt 但无 auth 模块

Phase 3: 委派 Junior（6 段式 Prompt：TASK / EXPECTED OUTCOME /
         REQUIRED TOOLS / MUST DO / MUST NOT DO / CONTEXT）

Phase 4: 验证 → lsp_diagnostics 0 errors + 测试全通过

Claude Code（单 Agent 直接执行）

用户: "给 REST API 添加 JWT 认证"

Agent 直接开始:
  1. Read 项目结构，理解现有代码
  2. 搜索已有 auth 相关代码
  3. 直接编写 auth 中间件 + 路由
  4. 若权限模式允许自动接受编辑 → 无需确认
  5. 运行 Bash 测试

特点: 无并行探索，无任务委派，无结构化验证流程
优势: 速度快，无编排开销
劣势: 缺少外部最佳实践参考，无结构化验证

Opencode（平台 + 单 Agent）

用户: "给 REST API 添加 JWT 认证"

Agent（由 AI SDK 驱动）:
  1. 使用内置工具读取代码
  2. 直接实现
  3. 基础验证

特点: 最简洁，但也最缺少辅助机制

三系统对比要点：OmO 的优势在于并行探索 + 外部知识 + 结构化验证，代价是编排开销和更多 API 调用。Claude Code 的优势在于速度和简洁性——对于模型能力范围内的任务，直接执行通常足够好。Opencode 提供基础能力，其余由插件决定。

案例二：大规模重构（CommonJS → ESM 迁移）

OmO：Ultrawork 模式

用户: "ulw 把整个项目从 CommonJS 迁移到 ESM"

关键词检测 → 所有模型升级为最高版本 + 注入强化 Prompt

Metis（预分析）→ 识别隐藏风险:
  - 动态 require() 需手动处理
  - 部分 npm 包不支持 ESM
  - Jest 配置需要大改

Prometheus（规划）→ Momus（审查）:
  ⚠️ 缺少 tsconfig.json 更新步骤
  ❌ 没有回滚策略

修正计划后分阶段执行:
  Phase 1: 配置文件更新 (Junior - quick)
  Phase 2: 核心模块迁移 (Junior - deep)
  Phase 3: 测试框架适配 (Junior - deep)
  Phase 4: 依赖兼容性修复 (Junior - ultrabrain)
  Phase 5: 全量测试 + LSP 诊断

Atlas "巨石"续航 → 每个 Phase 完成后自动推进下一个
结果: ~15 分钟，120 文件，147/147 测试通过

Claude Code：Coordinator 模式

用户: "把整个项目从 CommonJS 迁移到 ESM"

Agent 可选择进入 Coordinator 模式:
  Main Agent（coordinator）:
    1. 分析项目结构
    2. 通过 AgentTool 启动 worker sub-agents:
       [Worker #1] 处理 src/core/ 目录
       [Worker #2] 处理 src/api/ 目录
       [Worker #3] 更新配置文件
    3. 汇总结果，处理冲突

特点:
  - 真正的并行执行（in-process teammates via AsyncLocalStorage）
  - 无需预规划审查——Agent 自主决定分工
  - 缺少 OmO 那样的"Metis 预分析"和"Momus 审查"环节

关键差异：OmO 的多 Agent 流程是显式编排（人类设计的角色分工），Claude Code 的 Coordinator 是隐式编排（模型自主决定如何分工）。OmO 更可预测，Claude Code 更灵活。

案例三：调试——持续失败时的升级路径

调试 race condition，前两次修复尝试均失败

OmO 路径:
  → 第 1 次失败 → 再试
  → 第 2 次失败 → 触发 Oracle（高推理模型）
  → Oracle 诊断出根因在另一个文件
  → 按 Oracle 建议修复 → 通过

Claude Code 路径:
  → Agent 持续尝试，无显式升级机制
  → 依赖模型自身的推理能力发现根因
  → 可手动通过 "think hard" 提示或切换 effort 级别

Opencode 路径:
  → 与 Claude Code 类似，依赖模型能力
  → 无内置升级机制

OmO 的"2 次失败后升级到更强模型"是一种机制化的问题升级，而不是依赖用户判断何时需要更强的分析能力。

12.2 设计亮点

三系统共同的优秀设计

工具化的 LLM 交互

三个系统都没有走"纯聊天"路线，而是将 LLM 锚定在工具调用范式上。工具提供确定性的执行能力，弥补了 LLM 生成的不确定性。这是当前 AI Agent 架构的共识性最佳实践。

终端原生 + React-like 渲染

三个系统都选择了终端 CLI 形态（而非 IDE 插件或 Web 应用），并采用 React-like 终端渲染（Opencode/OmO 用 SolidJS + Ink，Claude Code 用 React + Ink + React Compiler）。终端 UI 已经进化到可以承载复杂交互的程度。

OmO 独特亮点

纯插件架构的工程美学：通过仅 8 个 Hook 接口注入 12 个 Agent、48 个 Hook、26 个工具。证明良好的扩展点设计能支撑远超预期的功能扩展。

经济学驱动的模型分配：搜索用最便宜模型，决策用最贵模型，执行用中等模型。整体费用远低于统一用最好模型，关键决策点质量不降。

Queue Messages 旁路通信：不修改对话历史、不打断思维链，在下一次 LLM 调用时作为系统消息追加——尊重 LLM 工作模式的信息注入。

6 段式委派 + Session 续接：结构化委派解决子 Agent 的范围蔓延和信息缺失。强制 session_id 续接节省约 70% token。

Claude Code 独特亮点

推测执行的工程实现：通过 Overlay 目录 + Copy-on-Write 实现安全的预执行沙箱。从"用户等待 Agent"变为"Agent 等待用户确认"，根本性改变了交互节奏。

StreamingToolExecutor：工具不等消息完整返回再执行——解析到 tool_use 块的必要字段后立即启动。Bash 错误可级联取消同批次其他工具。这种"边流式边执行"在三个系统中独此一家。

5 级压缩层次：从 Token 级 Snip 到会话级 Session Memory Compact，形成了最精细的上下文生命周期管理。特别是 Microcompact 的"保留最后一条完整 Assistant 消息"策略，在压缩激进度和信息保留之间找到了精妙的平衡点。

统一 Task 接口：local_bash、local_agent、remote_agent、in_process_teammate、monitor_mcp、dream 等 7 种任务类型共享同一 Task 接口和生命周期。将"Agent 调用"和"脚本执行"统一为同一抽象。

权限系统的 7 模式 × 8 来源矩阵：从 plan（只读）到 bypassPermissions（全放行），结合 ML 自动分类器、AllowList、DenyList 等 8 种规则来源，实现了细粒度且可扩展的安全控制。

Opencode 独特亮点

Effect-TS 的类型安全副作用管理：在需要管理 LLM 流、子进程、数据库、网络等多种副作用的系统中，Effect 的 Layer 依赖注入和类型化错误处理提供了显著的可维护性优势。

Worker 线程 UI 隔离：TUI 与 LLM 处理运行在不同线程，通过 MessagePort 通信。UI 永远流畅，即使 LLM 处理阻塞。

开放的插件架构：8 个精心设计的 Hook 点 + 工具注册 + 命令注册 + MCP 加载，使得像 OmO 这样复杂的增强层可以在不 fork 的情况下实现。

12.3 不足与改进空间

OmO

不足	说明	改进方向
后台任务无持久化	进程崩溃时所有运行中任务丢失	状态持久化到 SQLite
子 Agent 间无直接通信	必须经 Sisyphus 中转	允许有限的 Agent 间协作
轮询模式	3 秒轮询检查任务状态	改用 Promise/Observable
系统提示膨胀	光系统提示可能占用数千 tokens	按需加载提示片段
配置复杂度	三层合并 + 多维配置难以调试	增加 dump effective config 命令

Claude Code

不足	说明	改进方向
REPL.tsx 巨型组件	5006 行单文件	拆分为子组件
全局 STATE 对象	90+ 字段的单一可变状态	领域拆分或不可变状态
单模型锁定	只支持 Claude 系列	扩展 Provider 支持（社区需求）
推测执行限内部	`USER_TYPE === 'ant'` 门控	开放给所有用户
query.ts 复杂度	1729 行核心文件	职责分离

Opencode

不足	说明	改进方向
无原生多 Agent	单 Agent + 单会话	引入 Agent 委派原语
无自动化迭代	缺少续航/循环机制	内置 idle-continuation
Effect-TS 门槛	学习曲线陡峭	更多文档和示例
无跨会话连续性	会话间无信息传递	引入会话摘要/记忆

12.4 值得关注的设计模式

以下设计模式跨越三个系统，值得在 AI Agent 工程中借鉴：

三次失败熔断（OmO）：Agent 连续修复同一问题失败 3 次后强制停止、回滚、记录上下文、升级到 Oracle。防止 Agent 陷入"随机尝试"的反模式。

反重复执行规则（OmO）：一旦委派 Explore/Librarian 搜索，Sisyphus 自己不得执行同样的搜索。避免 token 浪费和信息矛盾。

工具安全分区（Claude Code）：partitionToolCalls() 将工具分为"可并发"和"必须串行"两批。文件系统写操作永远串行，读操作可并行。简洁但有效的并发安全策略。

Copy-on-Write 文件沙箱（Claude Code）：推测执行的 Overlay 目录机制。写操作先在临时目录执行，确认后才合并回主文件系统。这种操作系统层面的隔离思路可以推广到更多 AI 操作场景。

Layer 化依赖注入（Opencode）：Effect-TS 的 Layer 模式使得测试中可以替换任意依赖（LLM Provider、文件系统、数据库），不需要 mock 框架。这是函数式编程在 AI 系统工程中的成功实践。

ToolSearch 延迟加载（Claude Code）：50+ 工具中只有约 30 个在每次请求时发送完整定义，其余通过 ToolSearch 按需加载。这种"搜索引擎式"的工具发现模式有效控制了上下文消耗。

12.5 小结

三个系统在实战中的表现差异，本质上是架构选择的外化：

OmO 的多 Agent 编排在复杂任务中展现出巨大优势（并行探索、结构化验证、自动升级），但在简单任务中引入了不必要的编排开销
Claude Code 的单 Agent + 可选 Coordinator 模式在大多数场景下足够高效，推测执行和流式工具执行等创新直接提升了交互体验
Opencode 的平台纯粹性使其成为最佳的构建基础——它不试图解决所有问题，而是为解决方案提供稳固的扩展平台

没有"最好"的架构，只有"最适合场景"的架构。对于需要严格质量控制和可预测行为的生产环境，OmO 的显式编排更可靠；对于追求速度和灵活性的日常开发，Claude Code 的直接执行更高效；对于需要深度定制的团队，Opencode 的插件平台提供了最大的自由度。

← 返回目录 | 上一章：自动化与开发者体验 | 下一章：三系统架构总评 →

第十二章 实战案例与设计评价（三系统对比） ​

12.1 实战案例 ​

案例一：用户要求"添加 JWT 认证" ​

案例二：大规模重构（CommonJS → ESM 迁移） ​

案例三：调试——持续失败时的升级路径 ​

12.2 设计亮点 ​

三系统共同的优秀设计 ​

OmO 独特亮点 ​

Claude Code 独特亮点 ​

Opencode 独特亮点 ​

12.3 不足与改进空间 ​

OmO ​

Claude Code ​

Opencode ​

12.4 值得关注的设计模式 ​

12.5 小结 ​