认识 OpenCode 2.0：21.7 万星的开源编程 Agent，第一件事是把 Bun 和 Tauri 全砍了

先讲一个让我盯着看了一会儿的细节。

2026 年 10 月 12 日，OpenCode 官方博客发了篇公告，标题就叫「OpenCode 2.0」。里面有一句话，原文是这样的：

The old API grew haphazardly as we and the world collectively learned what agents are and should be. It was bad.

翻译过来就是：我们那套旧 API 是在整个行业一起摸索"Agent 到底是什么"的过程中乱长出来的。它很烂。

一个 GitHub 上 21.7 万星、被上千万开发者天天用的项目，官方自己发公告说"我们过去那套东西很烂"——这种坦诚在开源圈其实不多见。更狠的是后半句：他们说干就干，把半个系统推倒重做了。

而推倒重做的第一刀，砍向的是自己当年最得意的两个选择。

Bun 换回 Node.js。Tauri 换回 Electron。

要知道 1.x 当年选这套技术栈是带着"性能浪漫主义"的：Bun 启动快，Tauri 安装包小。听起来很美。结果到了几百万人每天用的规模，画风就变了——Bun 的生态深度和稳定性拼不过老将 Node.js，Tauri 在高强度前端渲染和进程常驻的场景里，不同操作系统之间稳定性差异能把团队折腾疯。

官方给的理由里有一条我特别喜欢，大意是：我们跑了基准测试，Bun 快出来的那一点点，没有带来任何明显收益。

用数据说话，而不是用信仰选型。这句话值得贴在每个技术团队的墙上。

一个工具在"极客玩具"阶段和"几百万人每天在用"阶段，对架构的要求完全是两回事。前者追求快和爽，后者追求稳和可扩展。OpenCode 2.0 是从前者到后者的一次跳。

什么是 OpenCode

一句话：OpenCode 是一个开源的 AI 编程 Agent，住在你的终端、IDE 或桌面里，替你读代码、改文件、跑测试、提 PR。它本身不卖模型，你手里有谁的 API Key 就填谁的。

先把"它不是什么"说清楚：

• 它不是一个模型。它是跑模型、编排工具、托管会话的那一层——也就是现在大家说的 Harness（ Agent 运行时）；
• 它不是某一家模型的壳。官方口径支持 75+ LLM 服务商（通过 Models.dev，含本地模型），Claude、GPT、Gemini、DeepSeek、通义、GLM、Kimi 随便换，甚至可以直接登录 GitHub Copilot 或 ChatGPT Plus/Pro 的账号额度来用；
• 它不是只能待在终端里。终端 TUI、桌面应用、Web 界面、IDE 扩展四种形态都有。

项目	情况
定位	开源 AI 编程 Agent（The open source coding agent）
协议	MIT（可商用，无保留条款）
维护方	Anomaly（创始团队来自 Serverless Stack / SST）
当前版本	2.0 主线稳定版，官方博客 2026 年 10 月 12 日宣布；2.x 最新 tag 为 v2.0.32（2026-10-16），1.x 维护线最新 v1.19.3
Star / Fork	约 217,386 Star / 29,069 Fork（2026-10-19 实时数据）
官方口径规模	208K+ Star、950 位贡献者、13,000+ commit、每月 1,600 万开发者使用
技术栈	运行时 Bun → Node.js；桌面端 Tauri → Electron
安装	curl -fsSL https://opencode.ai/v2/install | bash，也支持 npm / bun / brew / paru / yay

顺带说个让它出圈的历史事件：2026 年 1 月，Anthropic 开始封禁第三方工具使用 Claude Pro / Max 的订阅凭据。一夜之间大批开发者被迫找"能自己填 API Key"的替代品。模型中立的 OpenCode 正好接住了这波迁移潮，Star 数从那之后一路飙升。

所以 OpenCode 骨子里的基因是：不赌模型，只做那个"不管谁赢都能接进来"的层。

它有什么特点

2.0 的变化不小，我按"从里到外"的顺序讲，这样逻辑比较顺。

1. 心脏：一个常驻后台服务，多个界面

1.x 时代 OpenCode 有客户端/服务器架构的基础件，但默认不启用，基本只有高级用户在玩。2.0 直接把它提成了系统的核心：

服务器会作为一个统一的后台进程，自动在你的电脑上常驻运行。 你打开 TUI、Web 界面还是桌面应用，它们都在跟同一个中心进程通信。

这意味着什么？

• 会话跨界面流转。 终端里起一个活儿，切到桌面应用或网页继续干，进度一秒不丢；
• 脚本能自动找到它。 用新的 @opencode/client 写脚本，会自动发现本地服务并连上，天然适合跑定时任务（比如每天早八点自动过一遍代码检查）；
• 可以开放给别的设备。 服务能暴露给其他主机，用 /pair 或 opencode pair 把别的应用程序接进来，官方说原生 App 正在做。

界面只是显示器，服务才是本体。这一步把 OpenCode 从"一个桌面工具"变成了"一个本地 Agent 平台"。

2. 神经：API 推倒重写，Agent 会自己使唤自己

旧 API 官方自评"很烂"，于是从零重做。最有意思的不是换了几个函数名，而是——OpenCode 现在知道自己有这套 API，并且会主动调用它。

官方给了两个例子，特别直观：

例一，你说"在一个新 worktree 里开始做上传限流"，它会自己依次按下这几个按钮：

opencode.worktree_create  [name=rate-limit]
opencode.session_rename   [title=Rate limit uploads]
opencode.session_move     [directory=~/worktrees/rate-limit]

例二，你说"那个修 flaky test 的会话卡住了，停掉它，让它把测试隔离，再把我已完成的标签页关了"，它会：

opencode.session_list
opencode.session_context   [sessionID=ses_7c41e09a]
opencode.session_interrupt [sessionID=ses_7c41e09a]
opencode.session_prompt    [sessionID=ses_7c41e09a, text=Quarantine uploads.test.ts]
opencode.tab_close         [sessionID=ses_2f9d61b4]

看出来区别了吗？以前的 Agent 是个等指令的工具人，现在是个能自己调度自己的工作伙伴。 它能开自己的工作区、能把会话搬进去、能掐掉另一个卡死的会话。

用新的 @opencode/client 包，你自己写代码调它也就是几行：

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() 这一行就是上面那套设计的体现：脚本不关心服务在哪，"确保它在"就行。

3. 最锋利的刀：Code Mode，把工具调用变成写脚本

这是我觉得整场更新里最被低估的一项，而且它解决的是一个你一定踩过的坑。

传统 Agent 调工具的流程是：调一个工具 → 等结果 → 读完 → 决定下一个 → 再调。中间结果全部进上下文。更隐蔽的问题是——每个工具都带着名称、描述和参数 Schema，传统做法会在你输入任何内容之前，把这些全塞进上下文。

接几台 MCP 服务器，每次请求都要交这笔"上下文税"；接几十台，Agent 就被自己的工具手册淹没了，每一行说明都在跟你的真实任务抢注意力。所以过去的通行建议一直是：工具列表尽量精简，按任务手动开关服务器。

OpenCode 2.0 的解法非常取巧：模型天生爱写代码，那就让它写代码来调工具。

@opencode/codemode 包里实现了一个极简 JavaScript 解释器，能把 MCP 服务器和 OpenAPI 端点转换成脚本里可直接调用的函数——不需要 Node.js VM，也不需要嵌 QuickJS 这类复杂方案。Agent 写一段脚本，一次执行里调多个工具、处理返回结果，最后只把需要的东西交还给模型。

官方那个例子是"把 GitHub 上的 bug 同步到 Linear"：

return [search({ query: "list github issues" }),
        search({ query: "create linear issue" })]

const { issues } = await tools.github.list_issues({
  owner: "anomalyco", repo: "opencode",
  labels: ["bug"], state: "OPEN",
})

const filed = await Promise.all(issues.map(({ title }) =>
  tools.linear.save_issue({ team: "OC", title })))

return filed.map(issue => issue.identifier)

一整个来回，返回 ["OC-412", "OC-413", "OC-414"]。以前这种活得跟它废话十几轮。

关键一句：2.0 里所有 MCP 服务器默认启用 Code Mode，不需要开关，不需要改配置。 官方给的胆子很大的数字是——你可以接入上千台 MCP 服务器（注意是服务器不是工具），而上下文膨胀极小。

这一步解决的是整个行业的真实瓶颈：工具越多，Agent 越笨。Code Mode 的本质是把"工具发现"和"工具编排"从提示词层下沉到代码执行层。给模型一个解释器，比给它一本厚厚的工具手册管用得多。

4. 它会"三心二意"了——这是夸它

以前的 AI 助手有个毛病：让它干一件事，它必须干完才理你。它在那儿跑测试跑得起劲，你多问一句它都没空回。

2.0 加了两样本事：

• 后台子 Agent（background subagents）。 主 Agent 可以把一部分活儿甩给另一个子 Agent，自己继续陪你聊。这会自动发生，也可以手动触发，甚至可以给子 Agent 指定不同的模型——比如"起一个后台子 Agent 用便宜模型 review 这段代码"，你这边继续提需求；
• 后台 Shell 命令。 shell 工具可以异步调用，长时间的构建、测试不再阻塞主 Agent，跑完通知它。

还有一个很贴心的交互：任何前台命令或子 Agent 跑得比你预期久，按 Ctrl + B 就能把它挪到后台，你继续输入提示。

官方演示里是这么个画面：后台子 Agent 在 review 代码留下 2 条评论，后台 bun test 跑过 148 个测试，后台构建成功，主 Agent 同时顺手更新了 CHANGELOG。从"单线程对话"到"多任务并发编排"，差别就在这儿。

5. 插件系统重做 + SDK：把自己做成零件包

1.x 有插件机制，但官方承认"一直没花足够精力打磨"。2.0 的做法很狠——逼着自己把几乎所有新功能都实现成内部插件，现在内部已经有 80 多个。 道理很朴素：自己天天用，接口才不敢烂。

配套的两个改进：

• 全面热重载。 官方原话是它可以"在会话中途给自己写个插件，写完立刻用上"。你甚至可以开口让 OpenCode 给你造个插件，它知道怎么造；
• TUI 插件从实验性转正，底层是 OpenTUI，基本什么都能画。

另外 2.0 新增了 @opencode/sdk——和驱动 CLI 的完全是同一套代码。这意味着你可以把它剥下来，做成"自家风味的 OpenCode"，跑在服务器或者 Cloudflare Durable Objects 这种受限环境里；因为讲的是标准的 OpenCode server 协议，任何 OpenCode 客户端都能连上你的定制版。

谁在用它，用来干什么

这部分我尽量只写能查到出处的。

Cloudflare：把 OpenCode 做成了全公司的 AI 代码评审系统。 这是目前公开的最硬的一个案例。Cloudflare 没有买现成的 AI 评审工具，而是围绕 OpenCode 搭了一套 CI 原生的编排系统，最多同时派出 7 个专项评审 Agent（安全、性能、代码质量、文档、发布管理、合规等），由一个协调 Agent 统一管理。上线第一个月的数据：

指标	数字
评审运行次数	131,000+ 次
覆盖合并请求	48,000 个
覆盖仓库	5,169 个
评审中位耗时	3 分 39 秒（此前人工首次评审等待以小时计）
单次评审平均成本	$1.19
需要人工推翻的比例	0.6%
发现问题数	159,103 条

他们选 OpenCode 的理由写得也很实在：内部用得多大家熟、开源能直接上游提 PR（Cloudflare 工程师已经合入 45+ 个 PR）、SDK 好用，以及硬性要求——server-first 架构，TUI 和桌面应用只是客户端。因为他们需要用编程方式创建会话、发提示、从多个并发会话里收结果。

日本 Japan Trading Card Center：200 人全员上 Agent，AI 成本砍到十分之一以下。 这家公司给包括非工程师在内的全部约 200 名员工每人配了 OpenCode，后端走自建在 ECS Fargate 上的 LiteLLM 网关。几个设计挺值得抄：模型被抽象成 Low / Mid / High / XHigh 四档"力气档位"，后台换模型员工配置一行不用改；每人每周重置一次预算，超了走 Slack 审批；多个 MCP 服务器用 Cloudflare One 的 MCP 门户收敛成一个端点。他们先试过 Claude Code 走 LiteLLM，但新参数和 header 不支持导致反复 400，最后 OpenCode 的 JSON 配置加一行安装脚本的分发成本赢了。结果：提示词全部可审计，AI 成本降到上线前的十分之一以下——主要原因是"不再默认用最强模型"。

Spiko：不到 10 个工程师管着近 20 亿欧元资产。 这家法国金融公司的工程博客写得很细：主力用 OpenCode，自定义了 plan（只读，探索代码库、迭代方案）、build（执行，挂 Notion / Nx / Figma 等 MCP）、review（审 PR、分支 diff 或未提交改动）三个 Agent；PR 一开就由 spiko-bot 在 CI 里拉起 review agent，也能评论 /review 手动触发。他们还有个观点我很认同——同样的模型，OpenCode 让你对 harness 的每一层（系统提示词、工具选择、编排逻辑）都有更强的控制力，这是他们选它不选闭源方案的原因。

innFactory：德国一家 AI 公司，把 OpenCode 和 GitHub Copilot、AI Foundry、Vertex AI 并列进日常工具链，公开理由是模型不可知（75+ 服务商）、MIT 协议透明、可自托管满足数据合规。

把这几个案例放一起看，会发现一件有意思的事：没有一家是在用"它能不能一次写完一个功能"来评价它的。 它们在用的是——能不能被分发给 200 个人、能不能被 CI 编排、能不能被审计、成本能不能控住。

这跟 OpenHands 那边的结论一模一样：AI 编程工具过了"证明能干活"这一关之后，第二关就是谁来管这堆 Agent。

初体验：五分钟把它跑起来

先装 CLI。官方现在推荐的是这一行：

curl -fsSL https://opencode.ai/v2/install | bash

包管理器也行，官方列了 npm、bun、brew、paru、yay 五种。

装完进你的项目目录，直接敲：

cd your-project
opencode

第一次启动会让你选模型、登录服务商。如果你已经有 GitHub Copilot 或 ChatGPT Plus/Pro 的订阅，官方是直接支持登录复用的，这一步对国内用户挺友好——不用额外买 API。

想先试再决定接什么模型，也可以先用官方自带的免费模型（Zen）。

然后就可以说话了。几个立刻能用上的：

# 在终端里让它干活
opencode "帮我把这个仓库的 README 补一段快速开始"

# 桌面应用 / Web 界面里继续同一个会话
opencode serve

# 把本地服务开放出去，让别的设备或应用连
opencode pair

# 直接用 CLI 调 API
opencode api session.list

新手最容易忽略的一点：2.0 的服务是常驻后台的（进程名里能看到 opencode，带 pid）。你关掉终端窗口不等于关掉它。想彻底停掉，去系统进程里找一下，别让它在后台偷偷烧 token。

升级之前，先看好这四个坑

官方把这次叫"major overhaul"，破坏性变更是明着写出来的：

1. 1.x 的第三方插件在 2.0 里全部跑不起来。 不是小修小改能救的，整套接口换了，必须照新文档迁移。内部 80+ 插件是官方自己重写的，第三方得等作者适配；
2. 服务器 API 完全不同。 任何用外部脚本调旧版服务器的工作流，都得重写；
3. 终端配置文件从分层的 tui.json 迁到了 cli.json（官方公告里写的是 "tui.json config is moved to json"），不过这项迁移是自动完成的；
4. CLAUDE.md 不再读取，只认 AGENTS.md。 如果你的项目工作流重度依赖 CLAUDE.md，得手动把指令搬过去（这一条来自国内媒体对迁移清单的整理，动手前建议先确认）。

另外有一条存在争议、我必须标出来的：有报道称 2.0 虽然接受你的 LSP 设置，但实际运行时不会启动语言服务器，也不提供 LSP 诊断信息，官方建议改用项目本地的 lint / 类型检查 / 编译器。但 OpenCode 官网首页目前仍然把 "LSP enabled — Automatically loads the right LSPs for the LLM" 列为卖点。 两处口径不一致，我的建议是：如果你的日常工作流重度依赖 LSP 诊断，先别急着升，拿一台测试机验一遍再说。

升级命令本身倒不难：

# 先确保自己在最新的 1.x，再跨大版本升
opencode upgrade --major

好消息是你的模型配置、MCP 服务器、自定义 Agent 这些"声明式资产"能自动迁移，官方甚至建议直接把迁移文档指给 OpenCode，让它帮你搬：

把这个文档读一遍，帮我把配置迁到 2.0：https://opencode.ai/v2/docs/migrate-v1/

所以决策很简单：配置简单的（一个模型、几台 MCP、少量自定义 Agent），放心升；维护逻辑插件或深度调 API 的，先在沙箱里迁完再动；重度依赖 LSP 诊断的，暂时留在 1.x。

我的两点看法

第一，OpenCode 2.0 把竞争焦点从"谁的模型更聪明"搬到了"谁的运行时更硬核"。 模型在快速商品化，这是行业共识。当模型不再是壁垒，能留住用户的就是运行时——能不能被编排、能不能被嵌入、能不能被审计、能不能被分发给 200 个人。Code Mode 和常驻服务这两手，是冲着这个去的。

第二，这次升级对国内的分叉项目是个坏消息。 比如小米基于 OpenCode V1 代码库分叉做的 MiMo Code，本来靠"项目记忆"和自进化蒸馏做出了差异化，但面对 2.0 这种底层级别的重写，同步成本会非常高。开源分叉的账，早晚要还。

进阶

更多开源技术干货和学习资料，关注公众号「遇码」，领取专属福利。