10 月，OpenCode 团队发布 OpenCode 2.0，把这个 GitHub 上已超过 21 万 Star 的开源编程智能体彻底重做了一遍。官方公告的措辞是「一次大改（a major overhaul）」——它没有在 1.x 上继续加功能，而是把服务端、API、插件系统与配置格式全部重新设计。

升级入口已经接好：1.19.0 版本（10 月 11 日发布）的更新说明里写着，运行 opencode upgrade --major 即可升级到 OpenCode 2。开发者摘要站 Developers Digest 在 10 月 11 日的迁移指南里给了一句总结：对默认配置的用户是一次顺滑升级，对重度插件用户是一次重写——插件被官方明确列为「刻意的不兼容」。

三端共用一个后台服务

OpenCode 从第一天起就是客户端／服务端结构，但 1.x 默认没把它用起来，主要是高级用户在用。2.0 的改变是让这个服务自动以单一后台进程常驻：打开终端 TUI、网页端或桌面端，三者连的是同一个中央进程，看到的是同一份会话。

OpenCode 2 的客户端与后台服务：终端、网页、桌面，以及脚本调用方共享同一份会话状态

图 1：三端与脚本调用方共用同一个后台服务，会话状态在其中统一管理。

服务持有会话、配置、权限与工具执行。配套的几件事：

  • 脚本调用：新的 @opencode/client 包会自动发现本地服务并直接工作，官方特别点名它对定时任务有用；命令行侧可以用 opencode api 调用。
  • 配对与远程：opencode pair 会打印出 URL、用户名与密码，可以把服务暴露给其它主机；官方称基于这条链路的原生应用还在做。
  • API 重写：官方对旧 API 的评价很直接——「它是坏的」。新 API 从零开始重做，覆盖 142 个操作、285 个 schema，并提供 OpenAPI 3.1.0 描述；OpenCode 自己会用这套 API，比如开新工作时把当前会话移进一个 git worktree。
  • SDK：@opencode/sdk 就是驱动 CLI 的那份代码，可以被裁剪后跑在服务器或 Cloudflare Durable Objects 这类环境里，再用标准协议连回任意 OpenCode 客户端；基于 Effect 的可选 API 仍在开发中。

另外，2.0 新增了 warming（会话保温）配置：开启后，一段最近活跃的会话在你停手的 4 分钟后会收到一次保活请求，每 4 分钟一次，直到最后一次非保活请求满 30 分钟为止——目的是把供应商侧的提示词缓存留住。默认关闭，且这些是真实计费的请求。

Code Mode：把工具编译成 JavaScript 函数

2.0 里最受关注的新能力是 Code Mode。它来自 @opencode/codemode 包——一个极简的 JavaScript 解释器，会把 MCP 服务器或 OpenAPI 端点摄取进来，转换成函数，供智能体在脚本里调用。

Code Mode：MCP 与 OpenAPI 编译成函数，脚本里完成循环与并发，只把结果回传模型

图 2：脚本一次往返完成「读取一批数据 → 映射 → 再调用另一个工具」。

官方给的例子是「把 GitHub 上的 bug 归档到 Linear」：脚本先调 tools.github.list_issues 取回 open 状态的 issue，再 Promise.all 并发调用 tools.linear.save_issue，最后只把三个新 issue 的编号（["OC-412", "OC-413", "OC-414"]）返回给模型。整个「读一批、映射、再调另一个工具」的过程只占一次往返，而不是一次一条地调用工具。

两个设计细节值得留意：

  • 解释器原生执行这些脚本，不需要 Node.js 虚拟机，也不用嵌入 QuickJS 这类方案——这是官方强调的与其它实现路线的差别。
  • 2.0 里所有 MCP 服务器默认开启 Code Mode。官方称这意味着可以接入上千个 MCP 服务器而只带来极小的上下文膨胀：模型看到的是工具目录，具体调用交给脚本。

需要留意的是，社区已经报告 Code Mode 在调用长时间运行的插件时目前没有超时上限，可能导致会话一直等待、需要手动打断。

后台子智能体与后台 Shell

2.0 补上的另一块能力是「把活儿丢到后台」。官方判断是：最新一批模型在编排上已经相当强，外壳应当让它们把这份能力完整表达出来。

后台子智能体与后台 shell 命令：主智能体收到的是完成通知，而不是阻塞

图 3：子智能体与 shell 命令都可以转入后台，完成后通知发起方。

  • 后台子智能体：主智能体可以把手上的活派给另一个子智能体后继续干活，也可以手动触发，甚至可以指定另一个模型——官方示例就是「起一个后台的 fable 子智能体来审阅这段代码」，你继续提问。
  • 后台 Shell 命令：shell 工具可以异步调用，长时间运行的命令不必阻塞主智能体，完成时会收到通知。
  • 一个快捷键：如果前台某个 shell 命令或子智能体比你预期跑得久，按 ctrl+b 就能把它移到后台。

插件：先用自己把插件 API 喂饱

1.0 有插件系统，但官方承认「它没有得到应有的关注」。2.0 的解法有点意思：团队强迫自己把 2.0 的几乎所有功能都实现成内部插件，现在有 80 多个，以此保证 Plugin API 长期被维护。同时 TUI 插件从实验性升为稳定，底层由 OpenTUI 驱动。

配合「2.0 的一切都可以热重载」，官方称 OpenCode 可以在会话中途给自己写一个插件并立刻用上。插件数组来自多个配置文件，按优先级从低到高叠加而非替换；条目按顺序处理，可以用 - 前缀禁用某个插件或用 * 通配。插件也可以直接从 .opencode/plugins/ 目录发现 .ts / .js 文件。CLI 侧提供 opencode plugin add / list / check / update / remove 管理包插件，支持 npm 版本、tag、range 以及 Git 仓库（含私有仓库）。

上手与迁移

安装方式覆盖 curl、Homebrew、npm、bun、pnpm、yarn、Vite+、AUR、mise，以及各平台独立二进制；Windows 的包管理器不受支持，但提供独立二进制。Docker 镜像使用版本 tag，例如 ghcr.io/anomalyco/opencode:2.0.0。

OpenCode 2 的配置键迁移对照与三处刻意不兼容

图 4：V1 → V2 的配置键对照，以及需要提前知道的三个坑。

官方列出的三处刻意不兼容是：

  1. 插件：1.0 插件在 2.0 里不会运行，需要按专门的插件迁移指南重写——光改文件名或挪位置没用。
  2. 服务端 API：契约完全变了，调用方要迁到 @opencode/client。
  3. 终端配置：从分层的 tui.json(c) 收拢到全局 ~/.config/opencode/cli.json，首次启动会自动迁移全局配置，但项目级配置不会迁移。

其余部分官方称向后兼容。V2 读取与 V1 相同的配置路径，并会在内存里规范化旧字段而不改写文件，所以「先不改配置、直接跑一次 V2」是安全的。其余迁移要点：

  • 别让 V1 指向已转成 V2 形态的配置；两个版本共用 opencode 命令，也不再默认并存，安装 V2 前要先卸载包管理器装的 V1。
  • 想省事可以让 OpenCode 自己转换配置：把迁移文档指给它，让它按保留行为的方式改写。
  • 最稳妥的顺序是：先备份 ~/.config/opencode/ 与各项目的 .opencode/，在废弃项目里验证模型、凭据、agents、权限与 MCP 服务器，再逐个迁移插件。

还有三件容易被忽略的事：

  • LSP：V2 接受并保留 lsp 配置，但不启动语言服务器、不暴露 LSP 工具、不产生 LSP 诊断——要用 lint、类型检查或编译器命令来替代。
  • 指令文件：V2 只发现 AGENTS.md，不再回退读取 CLAUDE.md。
  • 共享后台服务：默认每个用户账号一个，且它才是真正执行工具的地方。opencode --standalone 可以跑一个私有服务，opencode service set disabled true 则把私有服务设为默认——无人值守、CI 或 API 场景要先想清楚用哪种模式。

配置侧还新增了 Policies：与「权限」不同，Policies 是二元的、永不弹窗、只会收紧而不会放宽，用来按语句允许或拒绝某个 provider、硬拒某次权限检查，或封掉某个 MCP 服务器、技能与插件。它也能由已连接的 OpenCode Console 工作区下发，且 opencode.config.policy 与 opencode.provider.opencode 这两个内置插件忽略移除指令，以免仓库自行关掉策略执行。

社区反馈：两类用户，两种体验

Hacker News 上这条公告拿到 748 分、94 条评论。正面的一侧包括：有评论者称 2.0 下较新的模型会自动派生子任务（开箱就能跑出 5 个以上异步子任务），也有人提到常驻服务带来的副作用是应用打开更快。质疑的一侧则集中在：默认常驻一个后台守护进程，有人并不想要；以及「所有工具调用现在都走后台进程」，导致只沙箱化 TUI 已经不够，需要 --standalone 才能把服务一并纳入沙箱。

Reddit 的 r/opencode 侧读数偏负面，有帖子直言 2.0 弄坏了他们的工作流，建议先修好插件和脚本再升；另一篇「和 OpenCode V2 相处一个周末」称大部分自定义内容都失效了、出现了一些 bug，且有些改动没法做成插件。Developers Digest 的迁移指南只读了摘要，给出的公允读法是：插件是官方刻意的不兼容，重度插件用户应当把它当作一次重写来规划。

OpenCode 2 终端会话示意，展示一次代码修改与随后的 bun test

图 5：OpenCode 终端会话示意——修改 src/cart.ts 后接着跑测试。

核心总结

  • 定位：OpenCode 2.0 是对这个 21 万 Star 开源编程智能体的一次彻底重做，1.19.0 起可用 opencode upgrade --major 升级
  • 架构：终端、桌面、网页与脚本调用方共用同一个后台常驻服务，会话、配置、权限与工具执行都在其中
  • Code Mode：把 MCP 服务器与 OpenAPI 端点编译成 JavaScript 函数，脚本原生执行、一次往返完成「读一批 → 映射 → 再调工具」；所有 MCP 默认开启
  • 后台任务：后台子智能体（可换模型）与后台 shell 命令，ctrl+b 可把前台任务移入后台
  • 插件与 SDK：80+ 内部插件反哺 Plugin API，全链路热重载；@opencode/sdk 可把同一套引擎嵌进服务器或 Durable Objects
  • 三处不兼容：插件 API、服务端 API、终端配置格式；另有 LSP 不运行、只认 AGENTS.md、默认共享后台服务三个坑

一句话：OpenCode 2 把「一个终端里的编程助手」推进成「一个本地常驻的智能体服务」，代价是插件作者与服务端 API 的调用方要重写一遍。

原文：OpenCode 2.0（Anomaly，2026-10）

参考：