主题
第十八章 三系统架构总评
← 返回目录 | 上一章：实战案例与设计评价 | 附录：关键文件索引 →
本章是全文的收束。我们从架构哲学、技术选型、适用场景三个维度，对 Opencode、OmO、Claude Code 进行最终的横向总评。
18.1 架构哲学对比
三个系统看似解决同一问题——"用 AI 在终端里写代码"，但底层的架构哲学截然不同：
| 维度 | Opencode | OmO | Claude Code |
|---|---|---|---|
| 核心定位 | 平台/框架 | 编排增强层 | 独立产品 |
| 架构范式 | 可扩展平台 | 多 Agent 编排 | 单体 Agent + 可选多 Agent |
| 设计原则 | 平台纯粹性 | 最大化自动化 | 最大化单 Agent 能力 |
| 扩展策略 | 开放 Hook + 插件 | 插件内自闭环 | Hooks + Skills + MCP |
| 模型策略 | 多 Provider 开放 | 多 Provider + 经济学分配 | Claude 单模型深度优化 |
Opencode 的哲学："我提供最好的基础设施，你来决定怎么用。"
它不对"如何与 AI 协作"做假设。它提供 Effect-TS 类型安全框架、SolidJS TUI 渲染、Worker 线程架构、插件系统——然后退后一步。这种"平台纯粹性"的代价是开箱即用能力有限，回报是最大的可扩展空间。
OmO 的哲学："AI 协作应该像一个高效团队，有明确的角色分工和工作流程。"
它将软件工程的组织模式映射到 Agent 系统：Prometheus 做规划、Sisyphus 做执行、Oracle 做咨询、Momus 做审查、Explore/Librarian 做调研。每个角色有专属的模型、Prompt、工具集和行为约束。这种"显式编排"的代价是系统复杂度（48 个 Hook、12 个 Agent），回报是可预测性和质量控制。
Claude Code 的哲学："一个足够强的 Agent 不需要复杂的编排，它需要的是最好的工具和最少的摩擦。"
它将工程精力集中在单 Agent 的极致优化上：流式工具执行减少延迟、推测执行消除等待、5 级压缩延长会话寿命、50+ 工具覆盖所有操作。Coordinator 模式作为可选的多 Agent 能力存在，但不是默认工作方式。这种策略在 Claude 模型能力范围内非常高效，代价是对单一模型供应商的深度依赖。
18.2 技术选型对比
| 技术维度 | Opencode | OmO | Claude Code |
|---|---|---|---|
| 语言 | TypeScript (Effect-TS) | TypeScript (Bun) | TypeScript (Bun) |
| 运行时 | Node.js / Bun | Bun only | Bun only |
| UI 框架 | SolidJS + Ink | (复用 Opencode) | React + Ink + React Compiler |
| 状态管理 | SolidJS Signals | (复用 Opencode) | 二层：全局 STATE + React Store |
| 构建 | tsc + bundler | bun build + tsc 声明 | bun:bundle + feature flags |
| LLM 接口 | AI SDK (Vercel) | (复用 Opencode) | 自研 API Client |
| 数据库 | SQLite (Drizzle ORM) | (复用 Opencode) | 文件系统 (JSON/Markdown) |
| 线程模型 | Worker 线程隔离 | (复用 Opencode) | 单线程 + AsyncLocalStorage |
| 测试 | Vitest | Bun test (given/when/then) | Vitest |
| Schema 验证 | Zod | Zod v4 | Zod |
值得注意的差异：
Effect-TS vs 普通 TypeScript：Opencode 使用 Effect-TS 管理副作用（Layer 依赖注入、类型化错误通道、结构化并发），学习曲线陡峭但可维护性强。Claude Code 和 OmO 都选择了普通 TypeScript，用模块级单例和传统 async/await 管理状态。
Worker 线程 vs 单线程：Opencode 将 UI 和 LLM 处理隔离到不同线程。Claude Code 在单线程内用 AsyncLocalStorage 实现 Agent 隔离。前者 UI 永远流畅，后者实现更简单但 CPU 密集操作可能阻塞 UI。
AI SDK vs 自研 Client：Opencode 使用 Vercel AI SDK 获得多 Provider 支持。Claude Code 自研 API Client 深度绑定 Claude API 特性（prompt caching、extended thinking、streaming events 等）。
18.3 关键设计决策对比
三个系统在几个核心设计决策上的分歧，深刻影响了各自的能力边界：
18.3.1 上下文管理策略
| 策略 | Opencode | OmO | Claude Code |
|---|---|---|---|
| 基础压缩 | compaction Agent 摘要 | 复用 + Queue Messages 恢复 | 5 级渐进压缩 |
| 上下文注入 | 插件级 Hook | 动态 System Prompt 构建（48 个 Hook 注入点） | CLAUDE.md + Skills + Team Memory |
| 长任务续航 | 手动恢复 | Ralph Loop + Todo Continuation + Boulder 机制 | 自动压缩 + 对话恢复 |
| 跨会话记忆 | SQLite 持久化 | 复用 Opencode | Team Memory + Project Memory |
OmO 的上下文恢复最激进——它通过 Queue Messages 在压缩后自动重新注入关键上下文（待办事项、文件状态、Agent 会话等），确保 Agent 在长任务中不会"失忆"。Claude Code 的 5 级压缩则更精细，从轻量过滤到深度摘要逐级升级。
18.3.2 工具执行模型
三个系统对"何时执行工具"的回答截然不同：
- Opencode：标准 ReAct 循环——LLM 输出工具调用 → 等待执行完成 → 将结果回传 → 继续推理
- OmO：在 ReAct 基础上增加异步后台执行——父 Agent 可以发起后台任务继续工作，不必阻塞等待
- Claude Code：引入推测执行——在用户审批前就预执行工具，审批通过则立即展示结果，审批拒绝则回滚。还支持流式工具执行，多个工具的准备工作并行进行
Claude Code 的推测执行是三者中最具工程创新性的设计，它将用户感知延迟降低了 30-50%。
18.3.3 权限与安全模型
| 层级 | Opencode | OmO | Claude Code |
|---|---|---|---|
| 工具级权限 | 敏感工具需确认 | 复用 Opencode | 7 种权限模式（从 Default 到 Yolo） |
| 命令过滤 | 基础黑名单 | 复用 Opencode | ML 分类器 + 正则规则 + 启发式检测 |
| 企业策略 | 无 | 无 | Policy Settings（组织级强制约束） |
| 沙箱隔离 | 无 | 无 | Docker 容器模式 |
Claude Code 在安全层面的投入远超 Opencode+OmO 体系。这不意外——作为商业产品，Claude Code 需要满足企业客户的合规需求，而 Opencode 作为开源平台更侧重灵活性。
18.4 适用场景
| 场景 | 推荐系统 | 原因 |
|---|---|---|
| 日常编码（单文件修改、Bug 修复） | Claude Code | 最低延迟，推测执行加速 |
| 大型重构 / 迁移 | OmO | 多 Agent 并行 + Metis 预分析 + 结构化验证 |
| 需要多 Provider 支持 | Opencode + OmO | Claude Code 仅支持 Claude |
| 企业合规环境 | Claude Code | 7 模式权限 + ML 分类器 + 企业策略 |
| 深度定制工作流 | Opencode + 自研插件 | 最开放的扩展架构 |
| 团队协作 / CI 集成 | Claude Code | Team Memory + Headless 模式 + CCR |
| 教学 / 学习 AI Agent 架构 | 三者皆可 | 各有独特的架构模式值得学习 |
没有银弹：上表是粗略指南。实际选择取决于团队偏好、基础设施约束、预算和模型可用性。
18.5 架构演进展望
趋势一：多 Agent → 自组织 Agent
OmO 的显式角色分工是当前多 Agent 的主流模式。Claude Code 的 Coordinator 代表了另一个方向——Agent 自主决定何时需要帮手、分配什么任务。未来可能会看到更多自组织模式：Agent 根据任务复杂度动态决定是否分裂为多个子 Agent，而不是预设固定角色。
趋势二：上下文工程持续深化
三个系统在上下文管理上的投入都远超预期（Claude Code 的 5 级压缩、OmO 的 Queue Messages、Opencode 的插件级上下文注入）。随着模型窗口继续增长但仍然有限，"如何在有限上下文中放最有价值的信息"将持续是核心工程挑战。
趋势三：推测执行普及
Claude Code 的推测执行证明了"预测-预执行-确认"模式的可行性。这种模式可能会扩展到更多场景：预测用户的审查决策、预生成测试用例、预编译修改后的代码。
趋势四：平台与产品的融合
Opencode（平台）+ OmO（增强层）的组合模式可能成为主流。AI 编码工具的核心基础设施（TUI、LLM 接口、工具系统）趋于标准化，差异化竞争转向上层的编排策略和 DX 创新。
18.6 结语
回顾全文，三个系统给我们展示了 AI 编码工具设计空间中的三个截然不同但同样有效的点：
Opencode 证明了一个好的平台设计可以支撑远超预期的上层建筑。它的 8 个 Hook 点、Effect-TS 类型安全、Worker 线程架构——这些看似"保守"的选择，为 OmO 那样的激进创新提供了坚实的地基。
OmO 证明了多 Agent 编排在当前模型能力下仍然有巨大价值。将复杂任务分解为"规划→探索→执行→验证"的流水线，比让单个 Agent 处理一切更可靠——至少在当前这一代模型上如此。
Claude Code 证明了一个足够强大的单 Agent 加上精心设计的工具和优化，可以在不引入复杂编排的情况下交付优秀的开发者体验。推测执行、流式工具执行、5 级压缩——这些工程创新直接转化为用户感知的效率提升。
最终，这三个系统不是竞争关系，而是互补的探索方向。AI 编码工具的未来很可能会融合三者的优点：Opencode 式的平台开放性、OmO 式的结构化编排（在需要时）、Claude Code 式的单 Agent 极致优化（在足够时）。