开放代码（OpenCode） 2.0 是一次重大重构，它吸收了数百万日常用户的经验，致力于提供一个能灵活适应智能体所需成为的一切的系统。此次更新包含大量新特性、性能改进和错误修复，下面先介绍其中影响较大的面向用户的变化。

OpenCode 2.0 是一次重大重构。它汲取了数百万日活用户的经验，提供了一个能够灵活适应智能体各种需求的系统。新版有大量新功能、性能改进和缺陷修复，下面介绍其中一些影响较大的面向用户变化。

服务

OpenCode 从一开始就采用了客户端/服务器模型。不过，默认情况下这一架构并没有被充分利用，主要只有高级用户会使用。

在 2.0 中，这个服务器会在你的机器上自动作为单一后台进程运行。无论你打开 TUI、网页界面还是桌面应用，它们都在与同一个中心进程通信。你会看到类似「opencode pid 48213 Running」的状态，以及「会话」列表，其中包含「修复偶发测试」「添加深色模式」和「审查改动」等内容。

如果你使用编程客户端 @opencode/client 编写自己的脚本，它们会自动发现本地服务并正常工作，这对定时任务尤其有用。你也可以通过 CLI 调用，使用 opencode api 命令。

你还可以把它暴露给其他主机，运行 /pair 或 opencode pair 来连接到其他应用。我们正在开发利用这一流程的原生应用。

API

旧版 API 是在我们和全世界逐步认识智能体是什么、应该是什么的过程中仓促成长起来的，设计得很糟糕。

我们从零开始，研究了每天使用 OpenCode 的数百万用户遇到的各种奇怪用例。现在它几乎支持你需要做的任何事情。

OpenCode 也能感知自己的 API，并会调用它来完成有用的操作，比如在开始新工作时把当前会话移到 git worktree（工作树）中。新建会话时，界面会显示当前路径 ~/app，以及此前被中断的「修复上传偶发测试」和已关闭的「迁移配置加载器」标签页；而本次新会话则会位于 ~/worktrees/rate-limit 这样的路径下。

我们还发布了新的客户端包 @opencode/client，其中包含面向原生 JavaScript 和 Effect 的客户端。例如，先通过 Service.ensure() 获取本地服务端点，再用该端点的 URL 和请求头创建 OpenCode 客户端；接着调用 client.session.create 在当前目录创建会话，最后用 client.session.prompt 让模型「审查当前改动」。

代码模式

模型喜欢写代码，而 OpenCode 2.0 比任何其他编程智能体都更充分地利用了这一点。我们在 @opencode/codemode 包中构建了一个极简的 JavaScript 解释器。

在会话中可以看到「代码模式」以及接入的 MCP 服务器，比如 github、linear 和 sentry。这个包会摄取 MCP 服务器或 OpenAPI 端点，把它们转换成智能体可以在脚本中调用的函数。它能原生运行这些脚本，无需 Node.js 虚拟机的复杂性，也不用嵌入 QuickJS 这类复杂方案。

这让智能体可以编写脚本，先调用一个工具，再遍历结果并调用另一个工具。整个过程只需一次往返，而不必逐个依次调用。

2.0 中所有的 MCP 服务器默认都启用代码模式。这意味着你可以添加上千个 MCP 服务器，而几乎不会造成上下文膨胀，智能体会自行发现并组合它们来完成任务。

后台任务

最新一批模型非常擅长编排（orchestration），因此框架必须让它们能够充分发挥这种能力。会话中新增了「后台」区域。

首先，我们增加了后台子智能体。主智能体可以把某些工作交给另一个智能体，同时自己继续处理。这一过程会自动发生，但你也可以手动触发，甚至使用不同的模型。它可以让你「生成一个后台 fable 子智能体来审查这段代码」，同时你继续下提示。

其次，我们增加了后台 shell 命令。shell 工具可以异步调用，这样长时间运行的任务就不必阻塞主智能体，任务完成时它会收到通知。

如果任何前台 shell 命令或子智能体耗时超出预期，你可以按快捷键把它们移到后台，以便继续下提示。

插件

虽然 OpenCode 1.0 曾有插件系统，但它从未得到应有的重视。为了改变这一点，我们强制自己把几乎每一个 OpenCode 2.0 功能都实现为内部插件，现在已有 80 多个插件。这保证了 Plugin API 能得到良好维护。

我们还把 TUI 插件从实验状态提升为稳定状态。由于全部由 OpenTUI 驱动，你几乎可以构建任何东西。这里有个没什么用的例子。

我们还花了大量时间确保 OpenCode 2.0 中的所有东西都可以热重载。因此它可以在会话中途为自己编写一个插件并立即使用——我们在之前的一篇博客中介绍过这个设计。

你可以让 OpenCode 构建任何你想要的插件，它知道怎么做。不过如果你确实想读文档，可以在这里查看。

SDK

现在，OpenCode 也可以通过 @opencode/sdk 包作为库来使用。这与驱动我们 CLI 的代码完全相同。

这意味着你可以对它进行裁剪，打造出自己的 OpenCode 版本，让它运行在服务器上或 Durable Objects 这类专用环境中。然后，你可以从任何 OpenCode 客户端连接到它，因为它使用标准的 OpenCode 服务器协议。

它还有一个可选的基于 Effect 的 API。由于相关设计仍在变动，这部分仍在开发中，但你已经可以开始使用。

升级

要升级 CLI，请先确保你使用的是最新的 1.x 版本，然后运行 opencode upgrade --major。

要升级桌面应用，请在此处下载最新版本。

有一些破坏性变更：

• 1.0 的插件在 2.0 中无法使用
• 服务器 API 完全不同
• tui.json 配置已移至 json

还有很多其他改动，但它们是向后兼容的。值得把 OpenCode 指向这份文档，让它帮你完成迁移。

多数人认可 OpenCode 2.0 在客户端/服务器架构、插件自动重载和后台任务上的进步，并视其为一次质量大修；但官网与安装包的性能和交互、后台进程导致的沙箱失效与资源占用，以及团队维护、计费透明度和项目身份，也构成了主要分歧，部分不满用户已转向 Pi 等替代方案。

认可 2.0 的功能与架构改进（较多人）

• 大量用户认为 2.0 消除了 V1 的许多痛点：技能与插件终于自动重载，任务可后台运行，子代理能在启动时指定模型；内置浏览器、内置配置编辑技能与前端改进提升了日常开发体验。配置改为从会话所在目录加载，而非服务器启动目录，减少了不一致。原生应用连接 OpenCode 服务器可在远程主机上运行会话，也被视为强 server/client 模型的价值所在。
• 有用户称这次更新把 OpenCode 在功能上带入当下时代，靠强 server/client 模型留住了自己；也有人表示跨过同时升级服务端和客户端的门槛后，通过 OpenChamber 2.0 使用非常顺利。仍有人以 OC 为日常主力，但希望进一步开放 GUI 构建块（按钮、标签等），以便自定义合并 PR、显示 CI 状态等，并肯定内置浏览器和 Opencode Go 的 40 美元方案。 > 这次更新基本消除了 V1 的许多恼人之处，让 OpenCode 在功能上进入当下时代，质量上也完成了一次大修（@solarkraft）

认为 Web UI/桌面端与非 TUI 运行是核心差异（少数人）

• 有用户强调，OpenCode 是他试过的唯一能在 TUI 之外运行的开源 agent 框架，Web UI/桌面端是选择它的主要原因；他喜欢终端，但不喜欢用 TUI 进行以自然语言为主的提示交互。
• 但他也提醒这一优势护城河很浅：插件和模型服务代理对他没有吸引力，其余功能并不算出彩。 > 对我来说 OpenCode 的独特之处是它能在 TUI 之外运行，是我试过的唯一带 Web UI/桌面端的开源 agent 框架（@MatthiasPortzel）

吐槽官网与安装包的性能和交互（较多人）

• 许多用户批评官网难用：加载缓慢，需要向下滚动却不明显，SDK 文字在底部被截断，信息密度和交互让人回到 90 年代风格，链接与按钮语义混乱；若页面是交互式画布，就应该让画布成为主体，而不是和文本混在一起。也有用户担心会涌现大量 WebGL 密集型站点，或提到官网中附带的基础小游戏虽简陋却意外有趣。
• 安装器同样因进度条渲染极慢，有人花六分钟只到 10%，必须等进度条渲染完；相关修复方式见文末补充。 > 我的笔记本为了渲染这个网站直接起飞、撞出窗外并阵亡了（@dormento）

担心后台进程、资源占用与沙箱失效（较多人）

• 有用户指出 2.0 并未降低资源占用，内存与 1.0 相当甚至更高；仍有人怀疑它会扫描包含上亿文件的工作目录、吃满内存，并用超长系统提示词挤占上下文。更反直觉的是，升级后所有工具调用改由后台进程执行，导致原本包裹 TUI 进程的沙箱悄然失效，本该被拦截的网页抓取等请求成功外发，用户花了几天才察觉。守护进程 PID 虽有助于 Web GUI，但在高强度并行下可能出现意外问题；也有用户在肯定之余询问推荐的沙箱模式，因为为每个 harness 单独管理 Linux 用户、bubblewrap 和 openbao 已越来越重。 > 升级后工具调用改走后台进程，我用来包裹 TUI 进程的沙箱悄然失效，本该被屏蔽的网页抓取等请求竟然成功外发（@kingds）

对团队维护、计费透明度和信任度失望（少数人）

• 一些用户表示不再信任该项目：称团队忽视 bug 报告与 Discord 求助，缺乏现代 CI/CD 与 bug triage，经常带回归发布，并认为其开源模型订阅服务可能是最差之一。有用户核算 token 费用后发现实际扣费总是高于文档标价，其中 GPT Luna 大约贵一倍；在 Discord 承认异常后却被长期无视，因而选择离开。还有人迁移到 Pi，称其设计、开发者和社区更好，或至少“说做什么就做什么”，没有这些折腾。 > 我按文档公布的单价核算过用量，发现实付总是偏高且 GPT Luna 大约贵了一倍，而在 Discord 承认异常后却被长期无视（@moralestapia）

抱怨 2.0 质量不稳定、基础功能缺失且 issue 堆积（少数人）

• 有用户称 2.0 目前令人失望，连隐藏侧边栏这样的基础操作都不可用；仓库积压约 3200 个 open issue，报 bug 也无意义。结合其他批评，团队被指缺乏现代 CI/CD 与回归防护，使得升级和日常使用都缺乏信心。（少数人）

疑惑项目身份：是重命名、分叉还是新团队？（少数人）

• 有用户提问这是否就是 opencode.ai，或是否为原项目的分叉；也有人指出 OpenCode 似乎已改名为 Crush，原开发者去了新项目，因此不清楚这个 2.0 从何而来、背后是谁在维护。（少数人）

质疑为何用 TypeScript 而非 Rust/C++ 编写（少数人）

• 看到仓库主要语言是 TypeScript 后，有用户质疑：既然项目大量由 LLM 生成，为什么没有用 C++ 或 Rust 来写，并希望得到明确解释。（少数人） > 既然整个项目基本是 LLM 产出的，我想知道为什么没用 C++ 或 Rust 来写（@rfgplk）

有价值的补充

• 安装脚本极慢的根因是进度条渲染：把安装脚本的输出经 cat 管道（如 bash 2>&1 | cat 的写法）可避开 TTY 中的进度条渲染，从而大幅提速（@denysvitali）。
• 原生应用连接 OpenCode 服务器可在远程主机上跑会话；相比之下，Claude Code 桌面端会在重连时重启并中断长任务，官方推荐的 Remote Control 又需要 Claude.ai 账号，这让部分用户更看重 OpenCode 的 server 模型（@afruitpie）。
• 配置加载位置发生变化：配置从会话创建目录加载，而非服务器启动目录，能减少服务端与客户端不一致带来的困惑（@solarkraft）。
• 后台任务/子代理支持在启动时指定模型，虽是小改动，却被认为显著改善了日常开发的 QoL（@361994752）。