一、发生了什么
OpenCode的起点非常小。2025年6月在GitHub发布时，创始团队仅有几个人。真正的转折点出现在2026年1月：Anthropic开始封禁第三方工具通过Claude Pro/Max订阅调用模型的行为。OpenCode此前支持用户用Claude订阅直接登录，其原理是伪装成Claude Code的客户端身份，发送相同的OAuth请求头。
Anthropic的应对措施分为三步：技术封锁、账号封禁、法律行动。OpenCode的回应也很干脆——直接移除了对Claude Pro/Max订阅和Claude API Key的支持。
但社区的响应比这两方都要迅速。开发者大量涌入，到2026年3月，OpenCode的GitHub Star数达到12.8万，贡献者超过800人；月活跃开发者从65万飙升至650万。
安全博主Daniel Miessler进行了一次直接的对比实验：用OpenCode从零开始编写一个完整的博客。他的结论是——“OpenCode和Claude Code一样出色，至少在这个任务上”。他原本以为Claude Code的优势在于某种“秘密配方”——上下文管理、记忆维护、多文件多步骤的编排能力。但实际使用后他发现，OpenCode在这些方面同样表现优异。他的判断是：Claude Code并不神秘，很可能只是围绕上下文窗口和记忆管理的优秀工程实践。一旦其他工具实现了类似的编排策略，差距就会迅速缩小。
二、本质上是供应商锁定的反弹
这件事的本质并非“Claude不让用了”，而是开发者对“供应商锁定”的集体反弹。
过去两年，AI编程工具市场被几个巨头瓜分：Cursor每月20美元，绑定了自己的模型套餐；Claude Code按Token计费，只能用Anthropic的模型；GitHub Copilot每月10美元，只能用OpenAI。每个工具都在努力将用户圈在自己的生态中。
OpenCode走了一条完全相反的路：模型无关。它支持超过75种模型提供商——Anthropic、OpenAI、Google Gemini、DeepSeek，甚至本地部署的Ollama和llama.cpp。你用谁的API Key，就连谁的模型，工具本身不抽成、不锁定、不干预。
一个Reddit高赞评论说得更直接：“Anthropic正在激励用户留在自己的产品生态里，而不是在API之上构建外部工具。”开发者用脚投票的结果是：OpenCode成为GitHub上星标最高的开源编程Agent。
但模型无关只是“为什么用”的理由。真正让开发者“留下来”的，是它内部那套主Agent与子Agent的分层架构。
三、核心机制拆解：主Agent与子Agent的分层架构
OpenCode采用客户端-服务器架构，基于TypeScript和Bun运行时构建，整体分为四层：客户端层、核心服务层、扩展层、模型适配层。最值得关注的设计，是核心服务层里的Agent系统。
OpenCode的核心设计理念，是以“袋鼠模式工作流”为核心，将复杂编程任务拆分为“主袋鼠↔子袋鼠”的协作模式。
3.1 主Agent与子Agent的定位差异
主Agent出现在OpenCode的Agent切换器中，是用户直接交互的对象。子Agent通过Task工具被主Agent生成，不能直接被用户选中。本质上这样分工：主Agent负责理解用户的整体目标、规划执行步骤、统筹全局；子Agent负责拆出去执行具体的小任务——查文档、修改某个模块、编写测试、运行命令、整理结果。
你可以把子Agent理解成主Agent派出的专项助手。主Agent负责整体目标和主线判断，子Agent负责一个更明确的小任务。
3.2 为什么需要分层
单个Agent处理复杂任务时会遇到三个典型问题：第一，上下文窗口不够用。一个Agent既要理解项目全貌，又要处理具体文件的修改细节，上下文很快就会撑爆。第二，任务无法并行。主Agent处理任务是排队的——先做A、再做B、再做C，但很多任务其实可以并行——审查代码和写测试完全可以同时进行。第三，职责混杂。同一个Agent既要做规划，又要写代码，还要做审查，角色不清晰，决策质量自然下降。
分层的核心价值就在于解决这三个问题。
3.3 四层架构中的Agent系统
OpenCode的四层架构从下到上分别是：
用户交互层提供CLI、TUI、Web三种接入方式；AI引擎层通过统一的模型抽象层实现模型热插拔和智能路由；核心能力层是Agent系统的所在地；工具集成层通过标准化接口与外部系统交互。
Agent系统在核心能力层中包含三个关键组件：决策中枢（基于ReAct框架的思维链推理引擎）、记忆管理（短期工作记忆与长期知识库的分层存储）、行动规划（动态生成可执行步骤序列的规划器）。
3.4 主从协作的完整流程
下面这张图展示了主Agent与子Agent协作的典型流程：
以一个实际的开源插件Blueprint为例，它实现了五个专门化的Agent：
- Planner（主Agent）：调研代码库、访谈用户、生成结构化实施计划
- Orchestrator（主Agent）：执行计划、创建git worktree、委派任务、验证结果
- Investigator（子Agent）：深度代码库调研——目录结构、代码模式、依赖关系
- Reviewer（子Agent）：审查计划和代码，发现遗漏和范围蔓延
- Worker（子Agent）：在隔离的git worktree中实现单个原子任务
这里有一个关键的设计约束：只有Worker Agent可以写源代码。Planner、Orchestrator、Investigator、Reviewer被限制只能在.blueprint/目录内写入文件。这个约束解决了一个很实际的问题：职责边界清晰。做规划的就做规划，写代码的就写代码，审查的就审查，不会出现一个Agent既当运动员又当裁判员的情况。
3.5 Self-Healing自愈机制
OpenCode还有一个不太常被提及但非常重要的设计：Self-Healing自愈机制。核心思想是任务中断后可以从断点继续。实际运行中，LLM调用可能超时、网络可能闪断、上下文可能溢出。如果没有自愈机制，整个任务就要从头开始。有了断点续传，损失就被控制在了局部。
四、一个真实的对比：同样改代码，差别在哪里
假设你要给一个项目添加用户认证功能，涉及三个文件的修改和一个新文件的创建。
没有分层架构的Agent：一个Agent从头干到尾。它要先理解项目结构，然后写代码，然后自己审查。过程中它的上下文会越来越臃肿——既要记住项目全局，又要关注每个文件的细节。改到第三个文件的时候，前面两个文件的上下文可能已经被挤出去，结果就是顾此失彼。
有分层架构的OpenCode：主Agent先派一个Investigator子Agent去调研项目结构——目录怎么组织的、用了什么框架、现有的认证方式是什么。调研结果写回主Agent的记忆里。然后主Agent基于调研结果生成实施计划，派Worker子Agent去改代码——每个Worker只负责一个原子任务，在隔离的git worktree里工作。改完了派Reviewer子Agent去审查。每个子Agent的上下文是干净的，只关注自己那一亩三分地；主Agent的上下文也是干净的，只关注整体目标和状态协调。
分层的本质不是“多几个Agent”，而是让每个Agent的上下文窗口只装它该装的东西。
五、工程落地启示
说了这么多OpenCode的设计，对我们自己有什么启发？
第一，上下文隔离是Agent系统稳定运行的前提。一个Agent的上下文窗口再大也是有限的。把任务拆细、把职责拆清，让每个子Agent只关注一件事，比训练一个“万能Agent”要靠谱得多。
第二，主Agent不要做具体的事。主Agent的核心职责是规划、调度、决策。具体执行交给子Agent。如果主Agent既要做规划又要写代码，它的决策质量一定会下降。
第三，工具级别的权限控制比提示词约束更可靠。Blueprint的做法是在工具层面通过tool.execute.before钩子强制执行权限控制，而不是靠提示词告诉Agent“你不要写源代码”。工程上能用代码保证的事，不要依赖提示词。
第四，自愈机制不是可选项。在生产环境中，LLM调用失败是常态，不是异常。设计系统时要假设每一步都可能失败，并且有办法从失败中恢复。
六、最后问一个问题
你的系统里，Agent的上下文是共享的还是隔离的？
如果是共享的——所有Agent共用一个巨大的上下文窗口——那当任务变复杂的时候，上下文污染几乎是必然的。如果是隔离的——每个子Agent有自己的上下文，主Agent只负责协调——那你就已经在用分层架构的思路了。
想清楚这个问题，比学会用OpenCode本身更重要。因为工具会变，但架构思想不会。
