💡 本文写作于 2026-10-15。OpenCode 2.0 于 10 月 14 日正式发布，当天在 Hacker News 收获 224 分热度。一手资料来自官方发布说明 anoma.ly/notes/opencode-2-0 与 opencode.ai 文档。
OpenCode 不是新名字。从 1.0 走到 2.0，这个开源编码代理积累了数百万日活用户，而 2.0 是一次彻底的重构：官方博客的原话是「一个能屈伸成代理所需一切的系统」。过去两年大家把编码代理当工具用，2.0 想回答的问题是——当代理成为日常基础设施时，工具层应该长什么样。本文按官方发布说明的脉络逐块拆解，并给出可直接照做的迁移与实战步骤。
一、常驻服务：从「可选架构」到「默认形态」
OpenCode 从第一天起就有客户端与服务器分离的架构，但很长时间里这只是高级用户的玩法——大多数人开着 TUI，感知不到底下有个服务器。2.0 把这件事做成了默认：服务进程自动在后台运行，本机只有一个。
你打开 TUI、打开 Web 界面、打开桌面应用，三者连的都是同一个中央进程。会话列表、运行中的任务、上下文状态全部共享。这意味着几个此前做不到的事：
- 跨客户端接续。白天在终端里跑的会话，晚上在桌面应用里打开接着聊，状态不丢。
- 定时任务有了宿主。你的脚本用
@opencode/client编程接入时，会自动发现本机服务，不需要自己拉起进程。配合 cron 或 launchd，让代理在固定时间处理仓库事务成为一行配置的事。 - 跨设备配对。把服务暴露给其他主机后，执行配对命令即可把别的应用连上来，官方的原生应用就在走这条路径。
CLI 侧也有对应入口：通过命令行可以调用服务的接口，把服务当成一个可编程对象来操作。如果你写自动化脚本，这就是最稳的入口——服务常驻，脚本即起即用。
⚠️ 对比提醒：10 月 13 日 Codex CLI 也上线了守护进程自动启动（本站有专文分析），但那是「CLI 顺手帮你把进程拉起来」的轻量方案。OpenCode 2.0 是把整个产品重构成服务优先架构，两者量级不同——前者是便利性改进，后者是形态转换。
二、全新 API：代理开始调用「自己」
旧 API 是随需求长出来的，官方自评「很糟糕」。2.0 的 API 从零重写，目标是覆盖数百万用户暴露出来的所有真实用例。更有意思的是第三个变化：OpenCode 会调用自己的 API。
官方演示了两个场景。第一个：用户说「在一个新的 worktree 里开始限制上传速率的工作」，代理依次执行创建 worktree、重命名会话、把会话移动到对应目录三个操作——全部通过调用 OpenCode 自身的接口完成。第二个：用户说「那个卡住的会话，停掉它，让它隔离那个测试，再把我完成的标签页关掉」，代理先列出会话、读取上下文确认卡在哪，然后中断会话、注入新指令、关闭无关标签页。
这说明新 API 的粒度足够细：会话可以按目录隔离、可以互相注入提示、可以被编程中断。多会话编排从「用户手动开多个终端」变成「一个主代理调度一组会话」。这也是后台任务能力的基础设施。
配套发布了新的客户端包，支持原生 JavaScript 与 Effect 两种风格。一段最小可用的接入代码：
import { OpenCode } from "@opencode/client"
import { Service } from "@opencode/client/service"
const endpoint = await Service.ensure()
const client = OpenCode.make({
baseUrl: endpoint.url,
headers: Service.headers(endpoint),
})
const session = await client.session.create({
location: { directory: process.cwd() },
})
await client.session.prompt({
sessionID: session.id,
text: "Review the current changes",
})Service.ensure() 负责发现或拉起本机服务，之后所有操作都是类型安全的函数调用。把这段代码放进 CI、放进定时脚本、放进你自己的内部工具，都是同一个模式。
三、后台任务：把编排权交还给模型
2.0 的第三块大改动是后台任务，分两层。
后台子代理：主代理可以把工作派给另一个代理，同时自己继续响应用户。官方例子是「派一个后台子代理去评审这段代码」，评审在后台跑，用户接着提问，评审完成时主代理收到通知，把两条意见线汇合。子代理甚至可以指定用不同的模型——便宜快速的模型做评审，贵的模型做主任务，成本结构立刻可控。
后台 shell：shell 工具支持异步调用，长时间运行的构建、测试不再阻塞主代理，完成时有通知。
还有一个体感极好的细节：任何前台命令或子代理跑得太久，一个快捷键就能把它移入后台。你不需要预先判断哪个任务该后台化——先跑，卡了再扔后台，对话不断线。
💡 实践建议：把「评审、测试、构建」三类任务默认设想为后台候选。主会话留给「读代码、做决策、写代码」这类强交互工作。这套分工和人类团队的模式完全一致：主编不等 CI 跑完才继续写下一篇。
四、Code Mode：上千个 MCP 工具不再撑爆上下文
OpenCode 2.0 内置了一个极小的 JavaScript 解释器（独立包，不依赖 Node.js 虚拟机，也没有嵌入 QuickJS 的复杂度）。它把 MCP 服务器或 OpenAPI 端点转换成代理可以在脚本里调用的函数。
传统 MCP 用法是逐个调用：代理想查 GitHub 的 bug 列表再逐条写入 Linear，每个工具一次模型往返，十个工具就是十次往返，每次都带着完整的工具定义占上下文。Code Mode 之下，代理写一段脚本：先并行取回所有 bug，再循环创建 issue，一次往返完成。
更关键的是默认策略的变化：2.0 里所有 MCP 服务器默认启用 Code Mode。工具定义不再需要在上下文里逐个展开，所以官方敢说「你可以接入上千个 MCP 服务器而不撑爆上下文，代理会发现并组合它们完成任务」。
对运维着几十个内部 MCP 服务器的团队，这一条几乎是升级的最强理由。本站 10 月初写过 Pi 1.0 的 Code Mode 设计，OpenCode 的思路同源但走得更远：Pi 解决的是「调用更省」，OpenCode 进一步解决了「接入更省」。
五、插件：80 个内部插件换来的 API 信誉
1.0 的插件系统一直没得到足够投入。2.0 团队用了近乎自虐的方式来修复：几乎所有 2.0 新特性都用内部插件实现，总数超过 80 个。插件 API 好不好用，团队自己每天都在用——这是最强的回归测试。
两个实打实的改进：
- TUI 插件从实验性转正，基于 OpenTUI 构建，理论上 TUI 里能画的东西插件都能画。
- 全量热重载。整个产品的一切都可以在会话中途替换，官方此前有专文讲这套设计。落地的效果是：你可以直接让代理给你写一个插件，写完立刻生效。
最后一个能力值得单独强调：代理知道怎么给自己写插件。当某个团队特有的工作流（比如定制的发布检查清单）没有现成插件时，你不需要去读插件文档、不需要开仓库建项目——告诉代理你要什么，它写完自己装上就用。
六、SDK：把整条 CLI 嵌进你的产品
新的 @opencode/sdk 包暴露的就是驱动 CLI 的同一套代码。你可以把它裁剪后跑在服务器上、跑在 Durable Objects 这类特殊环境里，然后用任何 OpenCode 客户端连上去，因为它说的是标准的服务协议。
这是「代理基础设施化」的最后一块拼图：过去你要在自己的平台里嵌一个编码代理，要么用 CLI 包一层进程管理，要么自己造会话管理。现在把 SDK 跑起来，会话、工具、上下文管理全部继承，你只需要做产品层。Effect 风格的 API 也在路上，适合偏好函数式错误处理的团队。
七、升级路径与踩坑清单
- 先升到最新 1.x，再执行主版本升级。CLI 用
opencode upgrade --major，桌面端从官网下载新版本。 - 1.0 插件直接失效。依赖旧插件的工作流要提前重写，好消息是可以让代理按 2.0 插件规范帮你迁移。
- 服务器 API 完全不同。所有 curl 旧端点的脚本要重写；
@opencode/client是新入口。 - tui.json 并入主配置。手动改过 TUI 配置的要把内容搬进统一配置文件。
- 让代理读迁移文档。官方明确建议把迁移文档喂给 OpenCode，让它自动迁移配置——这本身就是官方对自己产品能力的实弹演练。
结语：编码代理的第二阶段
OpenCode 2.0 的五个改动（服务化、新 API、后台任务、Code Mode、插件与 SDK）指向同一个判断：编码代理正在从「开发者手里的工具」变成「开发流程里的常驻基础设施」。当代理需要 7x24 待命、需要被其他程序调用、需要调度自己的同类时，单进程 TUI 形态就不够了。
这一周的工具层变化非常密集：Codex 的守护进程、OpenCode 的服务化重构、昨天我们写过的 Muse Wonder 把个人代理接进模型 API。方向高度一致——会话要有宿主，代理要有身份，服务要有协议。如果你的团队还在「每个开发者一个终端窗口」的模式里，OpenCode 2.0 是一个值得花一个下午迁移的信号。