Book: Claude Code VS OpenCode: Architecture, Design and The Road Ahead 章节: 第13章 — 架构哲学对比 Model: openai/gpt-5.4 Generated: 2026-04-01 Token Usage: 当前API环境不可见
13.2 简单 vs 复杂
所有 AI Coding Agent 都在承诺一件事：让开发者以更低摩擦完成更复杂的工作。但问题在于，复杂性从来不会真正消失，它只会被重新安放。于是，一个系统到底是“简单”还是“复杂”，不能只看用户界面，也不能只看代码行数，而要看复杂性被放在了哪里、由谁承担、换来了什么能力。
OpenCode 处在一个相对均衡的位置。它并不极简，但它的复杂度大体属于 moderate complexity，而且层次划分相对清晰。Provider 抽象、Tool 注册、Session 管理、MCP 接入、权限控制、插件表面，基本都能看到较明确的模块边界。从软件工程角度看，这种“复杂但分层”的状态是很健康的。系统真正可维护，不是因为它没有复杂度，而是因为复杂度被合理分区了。所谓分区，就是开发者可以只理解某一个子系统，就能做局部修改，而不必在脑中同时模拟整个代码库的全局状态。
Claude Code 展示的是另一种形态：外部简单，内部复杂。对最终用户来说，Claude Code 往往比 OpenCode 更“省心”。命令行和交互体验更成熟，默认行为更强，安全与审批流程被产品内建，很多配置负担也被平台吸收了。但这并不意味着它内部更简单。恰恰相反，产品层面的平滑，往往意味着实现层面的复杂。一个很直观的信号，就是版本分析中那个接近 4691 行的 main.tsx。单一大文件本身未必等于坏设计，但它通常意味着：编排逻辑、UI 状态、产品需求、边界条件、兼容分支在同一个中心面逐步沉积。
这其实是商业产品里很常见的现象。厂商为了给用户一个更顺滑的表面，会主动吞下大量内部复杂性。用户少配一点参数、少理解一点架构，意味着产品内部要多做很多判断、兜底、降级、回退和协同。也就是说，Claude Code 的“简单”，更多是一种 interface simplicity，不是 implementation simplicity。看起来越顺手，后面往往越重工程。
OMO 则是三者中最明确拥抱复杂性的系统。它大约 129K LOC 的规模，不是偶然膨胀，而是它对问题定义的自然结果。OMO 不满足于“单智能体 + 工具调用 + 少量提示词约束”这一层，它要做的是多智能体委派、后台任务、skill 体系、hook 多路复用、任务续跑、提示词操作纪律、上下文继承、工作流强化。这一整套能力，天然就要求更多的状态、更多的控制路径、更多的恢复逻辑。换句话说，OMO 把复杂性当成能力建设成本，而不是单纯想把系统做大。
这里可以引入一个 CS 和软件工程里很重要的区分：essential complexity 与 accidental complexity。前者叫“本质复杂性”，来自问题本身；后者叫“偶然复杂性”，来自糟糕抽象、坏耦合或实现细节失控。OMO 支持者会说，它面对的是“极端自治”这个本来就难的问题，所以复杂度大部分是本质复杂性。批评者则会指出，任何 129K 行级别的编排系统，都几乎不可能完全避免偶然复杂性。两者并不冲突：一个系统可以确实在解决困难问题，同时也在某些地方付出过高的架构税。
OpenCode 则更像一个中间解。它足够复杂，能作为平台承载多种能力；但又没有复杂到完全压垮概念清晰度。Claude Code 是把复杂度往内部压，让用户表面更轻；OMO 是把复杂度向上层编排系统推，以换取更强自治与持续执行能力。三者差别，不只是写法不同，而是在回答同一个问题：谁来承担认知成本？
这个问题还有一个 UX 维度。对用户简单，往往意味着对修改者不透明。Claude Code 的普通用户得到了低摩擦体验，但外部开发者很难重塑它。OpenCode 虽然少了一些“魔法感”，却因此更容易被理解和扩展。OMO 对新手最不友好，但对高级操作者可能最有吸引力，因为它提供的不是一个“聪明助手”，而是一套可以操作高自治工作的工程化底座。
所以，判断一个系统“简单还是复杂”，至少要看三层。第一层是 interface simplicity：用户是否容易上手。第二层是 architectural simplicity：代码和模块边界是否清晰。第三层是 operational simplicity：用户要花多少持续精力才能把系统带到正确方向。Claude Code 优先优化第一层，OpenCode 在第二层表现较好，OMO 则愿意牺牲前两者的一部分，换取在硬任务中的执行力度。
本节最核心的结论是：不要抽象地问“系统复杂是不是坏事”。应该问的是，复杂性放在哪、谁为它买单、它是否换来了真实能力。好的架构并不总是减少复杂性，很多时候它只是把复杂性移动到最能被管理的那一层。