OpenCode 与 Claude Code：两种系统边界观

上一篇我已经把 OpenCode 当成一个架构样本拆了一遍。那篇文章写完之后，一个很自然的问题就会出现：如果 OpenCode 和 Claude Code 都是 AI Coding Agent，它们到底在系统边界上做了什么不同的选择？

:::note[来源边界] 本文只比较两者公开文档呈现的系统边界，不推断内部实现。OpenCode 侧引用自其公开 GitHub 仓库文档；Claude Code 侧引用自 Anthropic 官方文档站点。对于 Claude Code 部分未在公开文档中明确说明的细节，我会显式标注为作者归纳或判断。 :::

这里说的”系统边界”，不是指功能列表，不是比谁支持更多命令，也不是比谁更聪明。它更接近下面这些问题：

代理的执行环境是怎么组织的。
工具权限是交给角色系统、配置系统，还是交给用户临场确认。
项目记忆和会话状态是显式文件，还是更多留在工具内部。
扩展能力是协议层的一等公民，还是宿主工具的一部分。
这个 agent 更像一个平台，还是一个深度嵌入现有工作流的产品。

从这个角度看，OpenCode 和 Claude Code 都不是”谁强谁弱”的关系，而是两种不同的系统边界观。

先说结论：同一类问题，不同的切法

如果只看表面，两者都在做类似的事：读代码、改文件、跑命令、接工具、记住项目约定，最后把模型能力嵌进真实开发流程。

切法不一样。

OpenCode 更像是在搭一个”可组合的代理执行环境”。公开文档里，它的服务端、会话、provider、session、MCP、LSP、share 都是显式可见的能力层，终端 TUI 只是这个系统的一个客户端。

Claude Code 则更像是把完整的代理体验尽量收敛进 Anthropic 自己定义的一套体系里。公开文档中，它的用户界面覆盖终端、IDE、桌面和 Web；在自动化与集成层面，还有 GitHub Actions、Remote Control、Agent SDK 等入口。它同样支持扩展和配置，但系统边界更多是围绕”Claude Code 作为宿主工具”来组织的。

简单说，OpenCode 更像”平台化执行环境”，Claude Code 更像”产品化工作台”。

执行形态：OpenCode 从一开始就是显式分层，Claude Code 更强调统一体验

OpenCode 的公开服务端文档写得非常直接：运行 opencode 时，会同时启动一个 TUI 和一个 HTTP server；TUI 本质上只是 server 的客户端。opencode serve 还能单独以 headless 方式运行，并暴露 OpenAPI 3.1 接口。

执行层和展示层是明确拆开的。终端只是一个入口，不是整个系统本身。

Claude Code 的公开文档则强调另一种表述：它”available in your terminal, IDE, desktop app, and browser”，并且这些 surface 连接到”the same underlying Claude Code engine”。Claude Code 也不是单一终端程序，但它并没有像 OpenCode 那样把”一个显式 HTTP server + 一个客户端”的结构作为核心对外暴露。

两者都支持多入口，但对外呈现方式不同：

OpenCode 把”执行系统”本身暴露得更清楚。
Claude Code 把”统一体验”暴露得更清楚。

实际影响很直接：如果你更看重”代理能力能不能被其他客户端、IDE 插件、远程前端甚至程序化接口直接驱动”，OpenCode 的系统边界更开放。如果你更看重”无论我在哪个界面工作，面对的都是同一套 Claude Code 体验”，Claude Code 的边界更收敛，也更产品化。

权限模型：OpenCode 更强调角色边界，Claude Code 更强调规则与模式

OpenCode 公开文档里最有代表性的一个点，是它把不同代理角色本身就做成了权限边界的一部分。比如 plan agent 默认不允许编辑文件，对 bash 也更谨慎；build 则承担更完整的执行权限。

在 OpenCode 里，“先分析、后执行”不是一句 prompt 提醒，而是可以通过 agent 角色直接落地的行为约束。

Claude Code 公开出来的权限模型则是另一条路线。它提供了显式的 permission modes，比如：

default
acceptEdits
plan
dontAsk
bypassPermissions

同时还有 allow / ask / deny 规则、allowedTools / disallowedTools、hooks，以及 project/user/local/managed 多层配置。

这套设计和 OpenCode 很不一样。

OpenCode 更像是：先把权限边界绑定在代理角色上。

Claude Code 更像是：把权限做成一套通用控制系统，再由当前模式和规则决定 agent 能做什么。

OpenCode 的方式更像”工作流内建”，更容易把分析和执行分阶段。
Claude Code 的方式更像”策略系统”，在组织和团队场景里，统一治理、IT 管控和安全落地可能更容易做（这是作者的判断，不是文档的直接表述）。

这也是为什么 Claude Code 文档里会特别强调 managed settings、权限继承、hook 和 policy，而 OpenCode 更强调 agent、tools 和 session 之间的边界关系。

上下文归属：OpenCode 更显式，Claude Code 更双轨

上下文管理是两者差异最大的地方之一。

OpenCode 的公开形态里，AGENTS.md、session、share、fork、revert、summarize 都是系统的一等对象。也就是说，它把”项目记忆”和”会话状态”直接作为可见结构暴露给你。

这种做法的好处是明确的：

项目约定可以写进仓库。
会话可以被分叉、回滚、分享。
上下文不只是聊天记录，而是有生命周期的工作状态。

Claude Code 也有项目记忆，但方式不同。公开文档里，它是通过两套机制来完成的：

CLAUDE.md：你写的持久指令
auto memory：Claude 自己积累的项目 learnings

其中 CLAUDE.md 是显式文件，auto memory 则是工具自动维护的项目记忆层（根据公开文档，这类记忆会被持久化到用户目录下）。

Claude Code 不是没有显式上下文，而是走了”双轨制”：一条是你手写的规范文件，一条是工具自动沉淀的经验记忆。

和 OpenCode 相比：

OpenCode 更强调”会话对象本身”的可操作性
Claude Code 更强调”项目记忆 + 自动记忆”的组合连续性

如果你的重点是”让状态对象可分享、可回放、可程序化操作”，OpenCode 的边界更适合。如果你的重点是”让工具自己逐渐学会项目，而我不需要频繁手动整理”，Claude Code 的双轨设计会更自然。

扩展能力：两者都拥抱 MCP，但位置不同

这是一个很容易被误读的点。

很多人会觉得，既然 Claude Code 和 OpenCode 都支持 MCP，那它们在扩展层面差不多。其实不完全是这样。

Claude Code 的公开 MCP 文档展示了相当完整的支持，包括多种传输协议、多级配置作用域，以及 Claude Code 自身作为 MCP server 暴露工具的能力（具体支持的协议类型和作用域以官方文档为准）。

Claude Code 对 MCP 的支持已经相当深入，而且和它自己的配置系统、权限系统、插件系统是连在一起的。

OpenCode 这边的公开结构则更强调另一种事：MCP 是它”能力接入层”的一部分，它和 tools、LSP、formatters、agents 一起出现在同一个执行体系里，甚至服务端 API 里还有动态添加 MCP server 的入口。

真正的差异不是”谁支持 MCP”，而是 MCP 在系统里所处的位置：

在 Claude Code 里，MCP 是宿主工具的重要扩展机制。
在 OpenCode 里，MCP 是代理执行环境中的能力接入层之一。

这影响的是长期系统重心：Claude Code 的重点是让 Claude Code 本身成为一个能承载丰富扩展的宿主；OpenCode 的重点是让代理系统本身能够不断接入新的能力源。前者更像”产品内扩展”，后者更像”平台内接入”。

工作流集成：Claude Code 更像现成生产工具，OpenCode 更像可编排执行节点

两者都已经不是”只在本地终端里回答问题”的工具了，但它们往工作流里延伸的方式还是不同。

Claude Code 官方文档展示了一套完整的生态：在用户界面层面，有终端、IDE、桌面和 Web；在自动化与集成层面，有 GitHub Actions、Remote Control、Agent SDK 等。其中 GitHub Actions 文档明确说明，Claude Code Action 建立在 Claude Agent SDK 之上，可以在 GitHub 的 runner 里分析代码、修 bug、建 PR，并遵守 CLAUDE.md 里的规范。

这是一种典型的产品化延伸：Claude Code 不是只给你一个本地 CLI，而是给你一整套”Claude 工作环境”的入口。

OpenCode 的工作流延伸则更偏执行节点思维。上一篇文章里已经提到，它的 GitHub 方案、share、server、IDE 客户端、session API，组合起来更像一个可被驱动、可被接入其他表面的代理执行环境。

放进团队工程流里看：

Claude Code 更像一个已经包装好的生产工具栈。
OpenCode 更像一个可以继续被拼装进其他系统里的代理基础层。

这不是成熟度高低的问题，而是面向对象不同。

提供商与生态控制权

OpenCode 的一个重要卖点就是 provider 不耦合，支持大量模型提供商，并把模型层当成可替换资源。

Claude Code 也在逐步开放 provider 选择。根据公开文档，Terminal CLI 和 VS Code 扩展已支持第三方模型提供商；GitHub Actions 则支持通过 Anthropic API、Bedrock、Vertex 等不同后端执行（具体支持范围以各组件的官方文档为准，Claude Code 本体与 Actions/SDK 的能力边界可能存在差异）。

但两者的生态重心仍然不同。OpenCode 的叙事中心是”代理系统怎么组织不同模型和 provider”；Claude Code 的叙事中心仍然是”Claude Code 作为 Anthropic 产品，如何扩展到不同环境和基础设施”。

更准确的说法不是”Claude Code 不能多 provider”，而是：它的开放性是在 Claude Code 这个宿主边界内展开的；而 OpenCode 从一开始就把 provider 可替换性放在更核心的位置。

两者的系统边界观

OpenCode 更像是在搭一个可组合、可驱动、可扩展的代理执行环境；Claude Code 更像是在构建一个覆盖终端、IDE、Web 与工作流自动化的统一代理工作台。

OpenCode 更偏平台边界
Claude Code 更偏产品边界

选择工具时，真正该问的问题不是”谁功能更多”，而是：

你需要的是一个能被继续拼装的系统，还是一个已经整理好的工作环境？
你更重视代理执行层的开放性，还是更重视整体体验的一致性？
你要优化的是平台可组合性，还是个人与团队的直接生产力？

OpenCode 和 Claude Code 最有意思的地方，并不在于它们都能”改代码”。真正值得看的，是它们在系统边界上的不同判断。

OpenCode 的判断是：把执行环境、工具接入、会话状态和 provider 组织成一个可编排系统。

Claude Code 的判断是：把代理体验、记忆机制、权限系统、多 surface 和工作流入口组织成一个统一产品。

它们都在把 AI Coding Agent 从聊天工具往工程现场推进，但推进的方式不同。