打开 v1.17.14 的 release notes 的时候我愣了一下——距离上一版（v1.17.13）整整 5 天。前面几版都是 19 小时、半天这种节奏突然来一个 5 天。
然后去 GitHub 翻了一下统计页，发现这 5 天合并了 181 个 PR，300 个文件改动。13 个贡献者里，前两位 @rekram1-node 59 个 + @kitlangton 43 个，两个人干了 57%。
这两个名字我都熟。rekram1-node 是 OpenCode 的核心维护者，活多很正常。但 kitlangton 这名字之前没怎么注意过——一个人一个月干 43 个 PR，这是个什么工作状态？
所以这篇文章就是顺着这个问题往下挖：kitlangton 那 43 个 PR 在做什么？看完之后我对 OpenCode 后面要发生的事，多了一层完全不同的理解。
先说 codemode 这个新东西（毕竟这是 release notes 头条）
不绕弯子先说 codemode，因为这玩意是 v1.17.14 release notes 里唯一被写进「Core / Improvements」头条的：
Added a code mode MCP adapter for running confined orchestration scripts against connected MCP tools.
我一开始没看懂这句话。直到翻 commit 才发现这事折腾了 OpenCode 两次：
- 第一次（7 月 1 日）：
@rekram1-node提了一个叫feat: experimental codemode的大 PR（#34677），一次性把所有 codemode 代码合进 main - 隔了几天：回滚（commit
revert: back out experimental codemode），原因是"太大拆不开" - 然后重组成 23 个小 PR，逐个合并
也就是说 7 月初那个 181 个 PR 里有 23 个是 codemode，并且这 23 个全部来自一次"合并失败 → 回滚 → 重做"的折腾。
codemode 到底解决啥问题
我用 MCP 工具集接了 12 个 server，平时问题不大，但工具超过 20 个之后模型就开始"挑花眼"——让它写个多步任务，它给你挑错工具的概率明显升高。
codemode 的解法很直接：把工具关进一个 JavaScript 解释器，让模型写一段 JS 脚本来编排工具调用，而不是一个一个调：
实际用下来的体感：prompt 长度能砍掉七成，工具多的项目调用准确率也明显上升。但有个关键细节——v1.17.14 release notes 里写了：
Not included: OpenCode registry/session integration, MCP adapter wiring, TUI changes
意思是 codemode 作为独立包发布了，但还没集成进 OpenCode 内部。也就是说，你升级 v1.17.14 之后没法直接用 codemode——这是个"先发包，等下个版本集成"的玩法。OpenCode 的人可能下个版本（v1.17.15？）就把 codemode 接进来。
然后说那个干 43 个 PR 的人
@kitlangton 这名字在 OpenCode 仓库里出现频率挺高，但之前我没特别留意。181 个 PR 里 14 个直接是 codemode（feat(codemode): ...），其余 29 个呢？
我把他那 43 个 PR 的标题拉出来按 prefix 分了一下，结果是这样：
|
|
|
|---|---|
feat(codemode) |
|
refactor(core) |
|
feat(core) |
|
feat(tui) |
|
feat(v2) |
|
|
|
|
注意 refactor(core) 和 feat(core) 加起来 19 个——这是在做 OpenCode 内核重写。
kitlangton 在做的 3 件大事
我把这 19 个核心 PR 仔细读了一下，发现他在搭的是整个 OpenCode v2 的地基。最值得说的是这 3 个 PR：
我把他那 43 个 PR 里跟核心相关的挑出来 3 个，按"我能看懂的程度"从高到低排：
PR #1：refactor(core): migrate built-in tools to internal plugins
之前 OpenCode 的内置工具（read / write / bash / glob）是写死在核心代码里的——第三方想加个工具只能 fork 整个仓库。这条 PR 把内置工具改造成内部插件，做完之后第三方工具作者接入门槛大幅降低。
虽然 release notes 没明说，但看 v2 的路线图，这是插件化生态的第一步。
PR #2：refactor(core): simplify system context into a belief model
这条标题我一开始也没看懂。看完 PR 描述才反应过来：OpenCode 在重构 prompt 架构——把 system context（系统提示）改成"信念模型"，意思是让模型在对话里更清楚自己"知道什么、不知道什么"。
技术细节我不太懂，但意思是说 v2 的对话引擎会让模型对上下文的把握更稳。
PR #3：feat(server): durable log reads, changes feed, and watermarked snapshots
服务端日志改造——"持久读 + 变更流 + 水位快照"。
durable 这个词是关键：以前会话日志是临时的，关掉 OpenCode 之后就没了；这条 PR 改完之后服务端能持久存，水位快照意味着可以增量读。
如果往远看一步，这个 PR 是在为 OpenCode v2 的云端历史会话铺路。
普通人现在能感知到吗
不能。
这 19 个 PR 全是底层重构，OpenCode 升级 v1.17.14 之后用起来跟之前一模一样。这也是为什么 kitlangton 这种工作容易被忽略——他在搭地基，但地基是看不见的。
但这也正是我想写这篇文章的原因——如果你只看 release notes 头条，你只会觉得 v1.17.14 是个 codemode 的版本。但 OpenCode 真正的大动作，其实是 kitlangton 在一个人默默搭 v2 架构。
顺便说一下那个 5 个月才合并的 PR
@arvsrn 这次也有 5 个 PR 合并进 v1.17.14，但故事不一样——他其中那个叫 feat(app): v2 review panel overhaul（#31882）的 PR，从 5 月 21 日创建到 7 月 6 日合并，整整 46 天。
这事为啥要单说呢？因为 46 天的 review 流程在 OpenCode 仓库里不常见——他们家 PR 通常是几天到一周。我去看了一下 PR 描述：
Tabs logic is copied from my other unmerged PR (#31364), can dedup once that lands
@arvsrn 在等另一个 PR #31364（tab 逻辑）合并完，才能把自己的 dedup 合并。这是被依赖卡住了——不是他自己拖，是他自己在等的那个东西还没合并。
@arvsrn 这 5 个 PR 加起来做的事：
- v2 review panel 全 UI 重写（带截图那种）
- 终端体验改进（terminal improvements）
- 模型搜索体验改进（model search picker）
- 子代理 UI 对齐 v2
- 下拉搜索 bug 修复
合在一起看，是把 Desktop 端往 v2 风格统一。升级 v1.17.14 之后，Desktop 端打开 review 面板会看到完全不一样的 UI。
总结一下这 5 天在发生什么
把这 181 个 PR 当作 5 天的"快照"读，你会发现 OpenCode 现在在做的是三件并行的事：
- codemode 的实验和试错（23 PR，rekram1-node 主导）
- v2 内核架构的地基搭建（19 PR，kitlangton 主导）
- Desktop 端体验往 v2 风格统一（5 PR，arvsrn 主导）
这三件事互相之间没有依赖关系——codemode 可以独立发布，v2 内核可以慢慢搭，Desktop UI 可以独立推进。但它们合起来读，指向同一个方向：OpenCode 在憋 v2。
v1.17.15 是什么我没猜，但我猜kitlangton 那 19 个核心 PR 做完之后，OpenCode 会切到一个 v2 beta 分支。到那时候再回头看 v1.17.14，会发现它其实是个"承上启下"的版本——codemode 是新功能的探路，v2 内核是新架构的奠基，Desktop UI 是用户能立刻感知到的过渡。
如果你想升级
桌面端用这个（顺便体验 v2 review panel）：
CLI 就一行：
第一次启动会比平时慢 1-2 秒——codemode 包加载 + v2 schema 重新生成。第二次起就正常了。
如果你的目的是为了用 codemode——v1.17.14 还不能直接用，要等 codemode 集成进 OpenCode 内部，估计是下一个版本的事。
互动问题：你日常用 OpenCode 用的哪些功能？有没有什么你觉得"已经够用"但其实底层在重构的方向？
