为什么要做这个对比？
如果你正在用 Claude Code，你可能听说过 OpenCode——一个 GitHub 上 121K+ stars 的开源 Coding Agent。反过来也一样。
这两个工具的界面、定价、生态完全不同，但用深了之后你会发现一个有趣的事实：它们的底层原理高度同构。理解了一个，另一个几乎可以无缝上手。
这篇文章不是简单的功能清单对比。我想回答的核心问题是：
深入理解 OpenCode 的底层机制，能否直接迁移到 Claude Code（反之亦然）？如果能，迁移率是多少？哪些能力可以迁移，哪些不能？
为了回答这个问题，我从 OpenCode 的源码（commit f2d3a4c7）和 Claude Code 的官方文档（v2.1.74）出发，逐层拆解了两者的架构。以下是完整的分析。
一、架构总览：技术栈不同，骨架相同
先看最表层的技术差异：
| 维度 | OpenCode | Claude Code |
|---|---|---|
| 语言 | TypeScript | TypeScript |
| 运行时 | Bun | Node.js（编译为原生二进制） |
| 代码开放性 | MIT 开源，完整源码可审计 | 闭源，编译后分发 |
| 架构模式 | 客户端-服务端分离（TUI/Desktop → Core） | 单体（CLI 内嵌所有逻辑） |
| 持久化 | SQLite + Drizzle ORM | JSONL 文件 |
| LLM 接入 | Vercel AI SDK，75+ 供应商 | 仅 Anthropic Claude 系列 |
看起来差异不小，但这些都是「皮肤层」的不同。往下一层看——Agent Loop、工具系统、上下文管理——你会发现它们几乎是同一个蓝图的两种实现。
OpenCode 采用 monorepo 结构：packages/opencode（核心引擎）、packages/app（TUI 界面）、packages/desktop（Electron）、packages/sdk（开发者接口）。Claude Code 则是一个编译好的二进制，所有逻辑打包在一起。结构不同，但功能分层几乎一致：都有独立的 LLM 调度层、工具注册层、会话管理层、权限控制层。
二、Agent Loop：完全同构的核心引擎
所有 Coding Agent 的心脏都是同一个循环：
用户 Prompt → LLM 推理 → 工具调用 → 观察结果 → 继续推理 → ... → 完成这个 Agent Loop 不是某个产品的发明，而是 LLM Tool Use 协议的必然产物。OpenCode 和 Claude Code 的实现方式几乎完全一致：
OpenCode 的实现（packages/opencode/src/session/llm.ts）：
- 使用 Vercel AI SDK 的
streamText()发起 LLM 调用 - 设置
maxSteps控制最大迭代轮数 - 每一轮：LLM 返回工具调用请求 → 执行工具 → 将结果作为下一轮输入
- 循环直到 LLM 返回纯文本（不再请求工具）
Claude Code 的实现：
- 调用 Anthropic API（或兼容端点）
- 同样的
tool_use→tool_result循环 - 同样的终止条件：LLM 返回
stop_reason: end_turn
两者的循环逻辑不仅概念相同，连控制流都几乎可以一一对应。如果你理解了 OpenCode 的 streamText + maxSteps 模式，切换到 Claude Code 时唯一的区别是 API 格式（Vercel AI SDK vs Anthropic native）——而这个区别对使用者来说是透明的。
迁移率：100%。 Agent Loop 的理解完全通用。
三、工具系统：近乎 1:1 的映射
工具系统是 Agent Loop 的「手」——LLM 通过工具与真实世界交互。两者的工具集高度重叠：
| 能力域 | OpenCode | Claude Code | 映射关系 |
|---|---|---|---|
| 读文件 | Read | Read | 完全一致 |
| 写文件 | Write | Write | 完全一致 |
| 编辑文件 | Edit（oldString→newString） | Edit（oldString→newString） | 接口完全相同 |
| 终端命令 | Bash | Bash | 完全一致 |
| 文件搜索 | Glob | Glob | 完全一致 |
| 内容搜索 | Grep | Grep | 完全一致 |
| 目录列表 | LS | LS | 完全一致 |
| 子任务 | Task（子 Agent） | Task（子 Agent） | 概念一致，实现不同 |
| LSP 集成 | 6 个 LSP 工具暴露给 LLM | 内部使用，不暴露给 LLM | OpenCode 独有 |
关键发现：Edit 工具的接口完全一样——都是基于 oldString → newString 的搜索替换模式，不是基于行号的 patch。这意味着你在一个工具里学会的「如何写好 Edit 指令」技巧，另一个工具里直接适用。
唯一的结构性差异是 LSP 集成。OpenCode 将 LSP 功能（跳转定义、查找引用、诊断、重命名等）作为 6 个独立工具暴露给 LLM，让模型可以主动请求类型检查和符号分析。Claude Code 也使用 LSP，但作为内部能力（不以工具形式暴露），主要用于 Linter 集成和代码导航辅助。
迁移率：~95%。 核心工具 1:1 对应，LSP 暴露策略是唯一差异。
四、上下文管理：同一个问题，同一个解法
上下文窗口是 Coding Agent 最稀缺的资源。两者对这个问题的处理方式几乎一模一样：
Auto-Compaction（自动压缩）
当对话历史接近上下文窗口上限时，两者都会自动触发压缩：
- OpenCode：在 token 使用达到 95% 时触发，将历史消息总结为摘要
- Claude Code：类似机制，具体阈值未公开，但行为一致——保留关键信息，压缩冗余历史
Sub-Agent 架构
两者都支持通过子 Agent 隔离上下文：
- OpenCode：
Task工具派生子 Agent，每个子 Agent 持有独立的上下文窗口 - Claude Code：同样的
Task工具，子 Agent 独立运行后将结果返回主 Agent
这种「主 Agent 协调 + 子 Agent 执行」的模式，本质上是对 Anthropic 提出的 Context Engineering 理念的直接实现——通过架构手段对抗 Context Rot。
迁移率：100%。 上下文管理的心智模型完全通用。
五、配置体系：不同的文件名，相同的分层逻辑
两者都使用 Markdown 文件作为 AI 的「项目规范」，而且都采用层级覆盖机制：
| 层级 | OpenCode | Claude Code |
|---|---|---|
| 全局配置 | ~/.config/opencode/AGENTS.md | ~/.claude/CLAUDE.md |
| 项目配置 | .opencode/AGENTS.md | .claude/CLAUDE.md（项目根目录） |
| 子目录配置 | 支持子目录级 AGENTS.md | 支持子目录级 CLAUDE.md |
| 覆盖规则 | 项目 > 全局 | 更近的范围 > 更远的范围 |
一个值得注意的细节：OpenCode 在找不到自己的配置文件时，会 回退读取 ~/.claude/CLAUDE.md。这不是巧合——OpenCode 的设计者显然认为，已有 Claude Code 配置的用户应该能无缝迁移。
两者还都支持 .gitignore 风格的忽略文件（OpenCode 的 .opencodeignore、Claude Code 的 .claudeignore），语法完全相同。
迁移率：~90%。 文件名不同，但逻辑、语法、分层规则几乎一致。已有的配置内容（规则、约束、代码风格说明）可以直接复制。
六、Hooks 与生命周期：最大的分野
前面五个维度的迁移率都在 90% 以上。到了 Hooks 系统，情况发生了变化——这是两者差异最大的领域。
设计哲学的根本不同
| 维度 | OpenCode | Claude Code |
|---|---|---|
| 配置方式 | 代码驱动（TypeScript 插件） | 配置驱动（JSON 声明） |
| Hook 类型 | 1 种：TypeScript 函数 | 4 种：command / http / prompt / agent |
| Hook 位置 | .opencode/plugins/*.ts | .claude/settings.json 内 hooks 字段 |
| 数据传递 | 函数参数（类型安全） | JSON 通过 stdin 管道传入 |
| 阻断机制 | 返回值控制 | 退出码协议（0=放行，2=阻断） |
这个分野的本质是两种工程文化的碰撞：OpenCode 面向开发者，给你最大的灵活性和类型安全；Claude Code 面向更广泛的用户群（包括企业），用声明式配置降低入门门槛。
事件覆盖对比
Claude Code 的 21 个 Hook 事件（按生命周期阶段）：
| 阶段 | 事件 | OpenCode 等价物 |
|---|---|---|
| 会话 | SessionStart, SessionEnd | session.created, session.updated via 事件总线 |
| 用户输入 | UserPromptSubmit | chat.message 插件 Hook |
| 工具执行 | PreToolUse, PostToolUse, PostToolUseFailure | tool.execute.before, tool.execute.after |
| 权限 | PermissionRequest | permission.ask |
| 通知 | Notification | 事件总线 notification.* |
| 子 Agent | SubagentStart, SubagentStop | ❌ 无直接等价物 |
| 压缩 | PreCompact, PostCompact | experimental.session.compacting |
| 配置 | ConfigChange, InstructionsLoaded | ❌ 无直接等价物（但可通过事件总线模拟） |
| 任务 | TaskCompleted, Stop | 事件总线 session.idle |
| 交互 | Elicitation, ElicitationResult | ❌ 无直接等价物 |
| Worktree | WorktreeCreate, WorktreeRemove | ❌ 无直接等价物 |
OpenCode 的独有能力（Claude Code 无等价物）：
| 能力 | 说明 |
|---|---|
experimental.chat.system.transform | 修改 System Prompt——可以在运行时动态注入或修改系统提示 |
experimental.chat.messages.transform | 修改消息历史——可以在发送给 LLM 之前对消息做变换 |
chat.params | 修改 LLM 参数——温度、max_tokens 等，按需动态调整 |
shell.env | 注入 Shell 环境变量——Bash 工具执行时自动携带 |
file.updated | 文件监听器——代码库文件变更时实时触发 |
| 49+ 事件总线 | 完整的 Bus.publish / Bus.subscribe 发布订阅系统 |
Hooks 迁移评估
从 Claude Code 迁移到 OpenCode：约 80% 的 Claude Code Hook 可以在 OpenCode 中找到等价实现，但需要从 JSON 声明改写为 TypeScript 代码。SubagentStart/Stop、Elicitation、Worktree 相关的 Hook 没有直接对应。
从 OpenCode 迁移到 Claude Code：约 60%。OpenCode 的 System Prompt 修改、LLM 参数修改、消息变换等高级能力在 Claude Code 中完全没有等价物——这些都依赖于 OpenCode 代码驱动的灵活性。
综合 Hooks 迁移率：~60-70%。 这是整个对比中迁移率最低的领域。
七、MCP 支持：协议相同，配置格式不同
两者都支持 Model Context Protocol（MCP），但配置方式不同：
- OpenCode：在
opencode.json中声明 MCP 服务器，支持stdio和sse两种传输 - Claude Code：在
.claude/settings.json中声明，同样支持stdio和sse
MCP 本身是标准协议，工具定义、资源访问、提示模板的概念完全通用。迁移时只需要改配置文件格式，MCP 服务器本身不需要任何修改。
迁移率：~95%。 协议层完全通用，仅配置语法不同。
八、子 Agent 系统：概念一致，能力不同
| 维度 | OpenCode | Claude Code |
|---|---|---|
| 触发方式 | Task 工具 | Task 工具 |
| 并行能力 | ✅ 多 Session 并行 | ✅ Agent Teams（Research Preview） |
| 上下文隔离 | ✅ 每个子 Agent 独立上下文 | ✅ 同上 |
| 共享机制 | 通过文件系统 | 通过任务列表 + 文件系统 |
| 生命周期 Hook | ❌ | ✅ SubagentStart / SubagentStop |
OpenCode 的子 Agent 系统更灵活（可以选择不同模型运行子任务），Claude Code 的更结构化（Agent Teams 有明确的角色分工和任务协调）。
迁移率：~85%。 核心概念一致，高级特性各有侧重。
九、综合迁移率评估
把所有维度汇总：
| 能力层 | 迁移率 | 说明 |
|---|---|---|
| Agent Loop | 100% | 完全同构，理解一个就理解了所有 |
| 工具系统 | ~95% | 近乎 1:1，Edit 接口都一样 |
| 上下文管理 | 100% | 同样的 Compaction + Sub-Agent 策略 |
| 配置体系 | ~90% | 文件名不同，逻辑完全一致 |
| MCP | ~95% | 标准协议，只改配置格式 |
| 子 Agent | ~85% | 概念一致，高级特性不同 |
| Hooks/生命周期 | ~60-70% | 最大分野——代码驱动 vs 配置驱动 |
按技能层级的迁移评估
L1 基础操作（~95% 迁移）：Prompt 技巧、工具使用习惯、上下文管理策略——这些是通用技能，不绑定任何特定工具。你在 OpenCode 里学会的「如何写好 Edit 指令」「如何控制上下文不膨胀」「如何用子 Agent 分解复杂任务」，在 Claude Code 里完全适用。
L2 工程实践（~85% 迁移）：配置规范编写（AGENTS.md → CLAUDE.md）、MCP 集成、权限策略设计——核心逻辑相同，需要适配格式。一个下午就能完成切换。
L3 高级定制（~50-60% 迁移）：Hooks 编写、插件开发、生命周期定制——这是差异最大的层。OpenCode 的 TypeScript 插件能力（修改 System Prompt、拦截 LLM 参数）在 Claude Code 中没有等价物；Claude Code 的声明式 Hook 系统和企业管控能力在 OpenCode 中也没有直接对应。这个层级需要重新学习。
十、结论：同一个蓝图，两种工程风格
综合迁移率：~85-90%。
OpenCode 和 Claude Code 不是两个恰好功能相似的产品——它们是同一套底层范式（LLM Tool Use Agent Loop）的两种实现。差异主要在于工程决策和目标用户：
- OpenCode 选择了开放和灵活：75+ 模型供应商、代码驱动的插件系统、LSP 暴露给 LLM、完整源码可审计。它适合想要最大控制权的开发者。
- Claude Code 选择了深度和集成：专为 Claude 模型优化的推理链路、声明式 Hook 降低入门门槛、GitHub App + CI 打通完整研发流水线、企业级管控策略。它适合追求开箱即用和团队标准化的场景。
对于个人使用者来说，最实际的建议是：
- 不要纠结「学哪个」——学任何一个，你都在学习 Coding Agent 的通用能力
- 把时间花在 L1/L2 技能上——这些技能 95% 可迁移，是真正的长期资产
- Hooks/插件按需深入——除非你确实需要深度定制，否则基础 Hook 知识就够了
- 关注 OpenCode 源码——即使你主力用 Claude Code，OpenCode 的开源代码是理解所有 Coding Agent 内部机制的最佳教材
最终，这两个工具的关系不是竞争，而是互补。OpenCode 让你看清 Coding Agent 的全部内幕，Claude Code 让你用最少的配置获得最强的推理质量。理解了一个，你就已经理解了另一个的 85%——剩下的 15%，也不过是换一种语法表达同样的意图。
参考来源
- OpenCode 源码：github.com/anomalyco/opencode（commit
f2d3a4c7，2026年3月） - OpenCode 文档：opencode.ai/docs
- Claude Code 文档：docs.anthropic.com/claude-code
- Claude Code Hooks 文档：code.claude.com/docs/en/hooks
- Bryan Whiting 对比分析：bryanwhiting.com
- Cefboud 技术深度分析：cefboud.com