---
url: /opencode/introduction.md
description: >-
  OpenCode 是 MIT 协议开源的 AI 编程 Agent，2026 年 10 月 12 日发布 2.0（当前 v2.0.32），GitHub
  21.7 万 Star。2.0 把运行时从 Bun 换回 Node.js、桌面端从 Tauri 换回 Electron，核心改成常驻后台服务，API
  推倒重写、Code Mode 默认开启可接上千台 MCP 服务器、新增后台子 Agent 与后台 Shell、80+ 内部插件全面热重载；代价是 1.x
  插件全线报废。本文从它是什么讲到在本机把它跑起来。
---

# 认识 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` 包，你自己写代码调它也就是几行：

```ts
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"：

```js
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。官方现在推荐的是这一行：

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

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

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

```bash
cd your-project
opencode
```

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

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

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

```bash
# 在终端里让它干活
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 诊断，先别急着升，拿一台测试机验一遍再说。**

升级命令本身倒不难：

```bash
# 先确保自己在最新的 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 这种底层级别的重写，同步成本会非常高。开源分叉的账，早晚要还。

## 进阶

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