从今天起，OpenCode v2 的更新日志做成一个固定系列：官方每发一个版本，第二天就有一篇速读。日志来源官方信息，不二手、不脑补。
第一篇先不追新，先把 v2 从 9 月 12 日首发到 10 月 23 日 v2.1.4 的整条线讲清楚。不看清这条线，后面每一篇单版本速读都没有参照系。
本文目录
一、先解决一个背景问题：v2 的日志到底在哪二、42 天 38 个版本：节奏先看一眼三、10 篇日志，每篇一句话四、210 条变更里，58% 是修 bug五、把流水账收拢，其实是四条主线六、唯一的 breaking change：v2.1.0 的 6 处七、怎么升级 + 这个系列怎么追
一、先解决一个背景问题：v2 的日志到底在哪
写这个系列前我先踩了个坑，先替你踩掉：
官网 opencode.ai/changelog 只挂了 10 篇——从 v2.0.26（10 月 8 日）到 v2.1.4（10 月 23 日）。翻到第二页，直接跳到 v1.19.4，v1 的日志。
也就是说：v2.0.0 到 v2.0.25 这 26 个版本，官网一篇日志都没有。
那 v2 前期的更新记录在哪？答案是 GitHub 仓库里的 CHANGELOG.md（anomalyco/opencode，dev 分支）。我查了这份文件的提交历史，它 2026 年 10 月 8 日才建档，首次提交信息写得很直白：feat(release): write reviewed V2 release notes to CHANGELOG——从这天起，官方才开始「reviewed」地写 v2 的发布说明。
所以 v2 的时间线其实分两段：
|
|
|
|
|
|---|---|---|---|
|
|
|
|
无日志 |
|
|
|
|
|
注意阶段二是 12 个版本只写了 10 篇——v2.0.31 和 v2.1.1 被跳过了。看提交记录就知道原因：每篇日志都是人工审过的（reviewed），纯补丁版不值得写。后面这个系列每篇的「漏网版本」，我也会顺手补上。
还有一个实用信息：npm 上的 v2 包名是 @opencode/cli，registry.npmjs.org 能查到全部 38 个 v2 版本的精确发布时间——本文所有节奏数据都来自 npm 官方 registry，不是估算。
二、42 天 38 个版本：节奏先看一眼
先说结论：v2 的发版密度和 v1 末期完全不是一个量级。
我之前写过 v1.18.x 的发版节奏（v1.18.22 到 v1.18.23 隔 16 小时就算「第二短」）。v2 直接把刻度换了：
- 38 个版本 / 43 天，平均 26 小时一版
- 43 天里 29 天有发版，最长的空档只有 3 天（出现过 4 次）
- 单日峰值 3 个——就是 9 月 12 日首发当天，v2.0.0 / 2.0.1 / 2.0.2 连着出
这张图还有两个细节值得留意：
1. 开始写日志之后，发版并没有变慢。 10/9 之后 15 天发了 12 个版本，密度跟前一个月基本持平——说明「写日志」没有拖慢发布，团队是把写说明做进了发布流程里（每次发布自动同步一次 CHANGELOG.md）。
2. 周末明显收工。 9 月中之后的三个周末，基本没有版本落地。v1 时代那种「深夜连发」在 v2 少了很多，发布节奏更像一个正经产品了。
三、10 篇日志，每篇一句话
10 篇日志我全部读完了，每篇压缩成一句话，连 Highlights 数、总条目数、PR 数一起列成表（原图可放大）：
|
|
|
|
|
|
|
|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| v2.1.0 |
|
|
|
|
Windows 持久终端；TUI todo；6 处 breaking |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| v2.1.4 |
|
|
|
|
MCP 输入表单弹出；后台压缩 |
几个数字口径说明一下：条目数是 Highlights 之外 Core / TUI / Desktop / SDK / Extensions 五个分区的变更条目；PR 数是日志里引用的去重 PR。10 篇合计 210 条变更、228 个不重复的 PR。
四、210 条变更里，58% 是修 bug
这可能是本篇最反直觉的一张图。
把 210 条变更按官方自己的分区拆开：
|
|
|
|
|
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
123 条是 Bug 修复，占 58%。 v2 的第一个月基本在「填坑」，不是加功能。而且规律很明显：每发一个新能力，下一版就跟着补它的边界情况——MCP 表单是 2.1.4 的 Highlight，同篇就有 5 条 MCP 相关的修复；压缩（compaction）相关的改进和它引发的修复交替出现在 2.1.3 和 2.1.4。
唯一的例外是 SDK：14 条改进对 5 条修复——这个分区的条目少、历史短，还处在铺接口的阶段，没到还债的时候。
另外注意 Extensions 的修复占 76%，是所有分区里最惨的。如果你在写 v2 插件，这 42 天里插件系统的稳定性变化值得专门看一眼——我后面出单篇讲。
五、把流水账收拢，其实是四条主线
单条看是流水账，归堆之后 v2 这 42 天在押注什么就很清楚了：
主线 01 · MCP 从「能连」到「能用」（14 条）最典型的是 2.1.4 的「MCP 输入表单终于弹出」——之前 MCP 服务器在工具调用中要输入，表单不显示，调用直接等到超时。现在桌面和 Web 都支持，覆盖 text / number / choice / multiselect / boolean / URL。配套还有 OAuth 修复、远程请求扛过 Bun 空闲超时、输出 schema 兼容放宽。
主线 02 · 上下文与压缩（11 条）token 是真金白银，v2 在这条线上持续加码：2.1.4 的 experimental.background_compaction 让摘要提前在后台备好；压缩请求超限时先缩短旧工具输出，保住更有用的历史；再往前是 2.0.26 的快照提速省盘。
主线 03 · 三端一体：TUI / Desktop / Web（79 条）Desktop 44 条是所有分区第一。远程扫码配对、每轮改动文件、PWA 可安装、Windows ARM64 原生构建、WinGet 上架、TUI 的 /diff 侧栏和实验性 todo——目标是让你在哪个入口用都是完整体验。
主线 04 · SDK 外延（19 条）实验性 voice API（发现模型、开 GPT-Live 会话）、connectClientMcp() 让客户端通过 WebSocket 挂自己的工具、permission.saved.update……这是四条主线里最「平台化」的一条：OpenCode 想被别的程序调用，而不只是被你在终端里敲。
六、唯一的 breaking change：v2.1.0 的 6 处
42 天 228 个 PR，破坏性变更只出现过一次，全部集中在 2.1.0：
- Provider replay 数据结构改为
native - Tool call 和 result 数据合并进
tool.native - Key credential 配置项的答案移到
metadata - Summary compaction 引用被保留的消息
- Provider compaction 窗口移到
native.messages - 移除未被使用的
session.compacted事件
影响面判断：如果你只是终端里用 OpenCode 写代码，这 6 处基本无感——它们动的是 SDK / 集成层的数据契约。但如果你有自己的集成代码、插件或者 dashboard，2.1.0 那篇值得逐条对。后面写到 2.1.0 单篇时我会把每处的迁移写法展开。
七、怎么升级 + 这个系列怎么追
升级方式（v2 官方文档口径）：
这个系列的追法，说好规矩：
- 每篇只讲一个版本，来源以官方 changelog 为准，PR 数据我会自己去 GitHub 对；
- 官网没收录的版本（比如 2.0.31、2.1.1 这种）我会从 npm 和提交记录里补出来；
- 篇幅控制在一杯咖啡的时间，重点写「这版跟你有什么关系」。
下一篇就从 v2.1.4 开始——它是当前最新版，MCP 表单和后台压缩这两个 Highlight 也最值得展开。
互动问题：你现在停在 v2 的哪个版本？2.1.0 的 breaking change 有没有咬到你？后面这个系列，你希望我重点盯哪条主线——MCP、压缩、三端体验还是 SDK？
