Back to Blog

OpenCode IDE 集成:VS Code、Zed 和 ACP 协议

2026-04-27T11:10:00+08:00
OpenCode VS Code Zed ACP IDE

OpenCode IDE 集成:VS Code、Zed 和 ACP 协议

很多人第一次接触 OpenCode 是在终端里——一个 TUI 界面,跑在 WezTerm 或 Alacritty 里,感觉就像在用 Vim 写代码的年代。但说实话,大多数开发者的日常是在 IDE 里度过的。你让我为了用 AI Agent 放弃 VS Code 的 IntelliSense、Zed 的 Collaborative Editing?那不现实。

好消息是,OpenCode 在 IDE 集成这件事上做得相当彻底。不是那种"你开个终端窗口跑命令"的伪集成,而是真正的 editor-native 体验——VS Code 扩展自动安装、快捷键直达、上下文感知;Zed 和 JetBrains 通过 ACP 协议深度对接;甚至 Neovim 用户也有两种插件可选。更关键的是,OpenCode 团队没有选择造一套私有协议,而是拥抱了 Agent Client Protocol (ACP) 这个开放标准。这意味着什么?意味着任何支持 ACP 的编辑器,配置两行 JSON 就能用 OpenCode。

这篇文章就把 OpenCode 的 IDE 集成方案从头到尾拆解一遍。

本文提纲

  1. VS Code 扩展:最丝滑的入门方式
  2. ACP 协议:连接编辑器和 Agent 的桥梁
  3. opencode acp:一行命令启动标准 Agent 服务
  4. Zed 配置实战:原生 Agent 面板体验
  5. JetBrains、Neovim 和其他编辑器
  6. 和其他 IDE AI 工具的对比

VS Code 扩展:最丝滑的入门方式

VS Code 系的编辑器(包括 Cursor、Windsurf、VSCodium)是 OpenCode 支持得最好的 IDE 生态。原因很简单——用户基数大,集成路径也最成熟。

自动安装,零配置

你不需要去 Extension Marketplace 搜索安装。只需要打开 VS Code 的集成终端,运行 opencode,扩展会自动安装。是的,你没看错——OpenCode CLI 检测到你在 VS Code 终端里运行,会自动帮你装好扩展

这背后用的是 VS Code 的 code CLI 接口。OpenCode 检测到 code 命令在 PATH 中可用,就直接帮你把扩展装上了。如果是 Cursor,就检测 cursor 命令;Windsurf 检测 windsurf 命令,以此类推。

如果自动安装失败(比如 code 命令没装),手动装也很简单——在 Extension Marketplace 搜索 "OpenCode",点 Install 就行。或者用命令面板(Cmd+Shift+P)搜索 "Shell Command: Install 'code' command in PATH" 先把 CLI 装上。

快捷键和上下文感知

装好扩展后,你能得到的不只是"终端里多了个 OpenCode"。以下是我觉得最有用的几个功能:

快捷键 功能
Cmd+Esc (Mac) / Ctrl+Esc (Win/Linux) 在分屏终端中打开 OpenCode,或聚焦已有会话
Cmd+Shift+Esc / Ctrl+Shift+Esc 强制开一个新 OpenCode 终端会话
Cmd+Option+K (Mac) / Alt+Ctrl+K 插入文件引用,比如 @File#L37-42

第一个快捷键是我用得最多的。你在编辑器里写着代码,遇到不确定的地方,按一下 Cmd+Esc,OpenCode 就在侧边栏弹出来了。而且它是上下文感知的——你当前选中的文本、打开的 Tab,都会自动共享给 OpenCode。这就避免了手动复制粘贴的痛苦。

Cmd+Option+K 这个文件引用快捷键也很实用。你在 prompt 里按这个组合键,就能快速插入类似 @src/index.ts#L37-42 的引用语法,精确告诉 OpenCode 你在说哪个文件的哪几行。

多编辑器兼容

OpenCode 的 VS Code 扩展不是只能在 VS Code 里用。以下编辑器都支持:

  • Cursor — 用 cursor 命令
  • Windsurf — 用 windsurf 命令
  • VSCodium — 用 codium 命令

本质上,只要你的编辑器基于 VS Code 的扩展系统,OpenCode 就能用。

和 Server 的关系

这里有个值得提的架构细节。当你运行 opencode 时,它实际上启动了两个东西:

  1. TUI — 终端界面,你看到的交互窗口
  2. Server — 一个 HTTP 服务,暴露 OpenAPI 3.1 接口

VS Code 扩展就是通过 Server 来控制 OpenCode 的。比如 /tui 端点可以用来预填 prompt、执行命令、显示 Toast 通知。这也就是为什么你在 VS Code 里的操作和终端里是完全一致的——它们操作的是同一个后端。

ACP 协议:连接编辑器和 Agent 的桥梁

如果说 VS Code 扩展是 OpenCode 的"特供方案",那 ACP 就是面向所有编辑器的"通用方案"。

Agent Client Protocol (ACP) 是一个开放标准协议,用于标准化代码编辑器和 AI Agent 之间的通信。它由 Zed Industries 发起,Google 的 Gemini CLI 作为首批实现者。现在已经有 40+ 个 Agent 和 10+ 个编辑器客户端实现了 ACP 支持。

为什么需要 ACP?

在 ACP 出现之前,编辑器和 Agent 之间是一对一的集成关系。每个编辑器想支持一个新 Agent,就要单独写一遍集成代码。想想看——Zed 要支持 Claude Code、Gemini CLI、OpenCode、Goose……每个都写一遍?反过来,OpenCode 想支持 Zed、JetBrains、Neovim……也是每个写一遍?

这就跟 LSP (Language Server Protocol) 出现之前的情况一模一样。每个编辑器要为每种语言写单独的语法高亮、自动补全。后来微软搞了 LSP,编辑器和语言服务器之间用统一协议通信,一次实现,到处可用。

ACP 做的就是同样的事,只不过对象从"语言服务器"换成了"AI Agent"。

ACP 的设计原则

ACP 的架构文档明确列出了三个设计原则:

  1. MCP-friendly:基于 JSON-RPC,尽可能复用 MCP (Model Context Protocol) 的类型定义。这样集成者不需要再去学一套新的数据格式
  2. UX-first:协议设计围绕 Agent 交互的 UX 挑战展开——怎么展示 Agent 的意图、怎么渲染 diff、怎么处理工具调用请求
  3. Trusted:ACP 假设你在用信任的编辑器和信任的模型。编辑器给 Agent 本地文件访问权限和 MCP 服务器配置,但仍保留对工具调用的控制

架构图

一个典型的 ACP 会话流程是这样的:

  1. 用户在编辑器里触发 Agent 对话(比如 Zed 的 agent: new thread
  2. 编辑器作为 Client,启动 Agent 作为子进程
  3. 双方通过 stdin/stdout 交换 JSON-RPC 消息
  4. Agent 可以通过协议向编辑器请求权限(比如执行 bash 命令)
  5. 编辑器可以将用户配置的 MCP 服务器信息传递给 Agent

每个连接可以支持多个并发的 session,所以你可以同时开多个 Agent 对话。

opencode acp:一行命令启动标准 Agent 服务

OpenCode 对 ACP 的实现非常简洁。运行以下命令:

opencode acp

就这。OpenCode 会启动一个 ACP 兼容的子进程,通过 JSON-RPC over stdio 和编辑器通信。

JSON-RPC over stdio 是什么意思

如果你不熟悉 JSON-RPC over stdio 这个通信方式,这里简单解释一下。

JSON-RPC 是一种轻量级的远程调用协议。每条消息都是一个 JSON 对象,包含 jsonrpcmethodparamsid 等字段。比如编辑器发给 OpenCode 的初始化请求可能是这样的:

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"clientInfo":{"name":"Zed","version":"0.170.0"}}}

OpenCode 返回的响应:

{"jsonrpc":"2.0","id":1,"result":{"agentInfo":{"name":"OpenCode","version":"0.1.48"},"capabilities":{}}}

stdio 是 "standard input/output" 的缩写。编辑器启动 opencode acp 作为子进程,编辑器的标准输出连接到 OpenCode 的标准输入,OpenCode 的标准输出连接到编辑器的标准输入。消息通过换行符分隔,一行一条 JSON-RPC 消息。

这个方式的好处是不需要额外的网络端口、不需要 WebSocket、不需要 HTTP 服务——一个子进程 + 两根管道就行。简单、可靠、跨平台。

opencode acp 的参数

opencode acp [flags]
参数 说明
--cwd 工作目录
--port 监听端口(可选)
--hostname 监听主机名(可选)

大多数情况下你不需要手动运行这个命令——编辑器会自动帮你启动它。但了解它的存在有助于调试。

功能支持

通过 ACP 连接的 OpenCode 和终端里运行的 OpenCode 功能基本一致:

  • 所有内置工具(文件操作、终端命令等)
  • 自定义工具和 slash 命令
  • MCP 服务器(通过 OpenCode 配置)
  • 项目级别的规则(AGENTS.md
  • 自定义 formatter 和 linter
  • Agent 和权限系统

目前已知的小限制是 /undo/redo 这两个内置 slash 命令在 ACP 模式下暂不支持。

Zed 配置实战:原生 Agent 面板体验

Zed 是目前 ACP 支持最好的编辑器之一——毕竟 ACP 就是 Zed 团队发起的。在 Zed 里用 OpenCode,体验非常原生。

配置步骤

编辑 Zed 的配置文件 ~/.config/zed/settings.json,添加以下内容:

{
  "agent_servers": {
    "OpenCode": {
      "command": "opencode",
      "args": ["acp"]
    }
  }
}

就这一步。保存配置后,在 Zed 的 Command Palette 里执行 agent: new thread,选择 OpenCode 作为 Agent,就能在 Zed 的原生 Agent 面板里和 OpenCode 对话了。

绑定快捷键

如果你想更快地唤出 OpenCode(谁不想呢?),可以在 keymap.json 里绑定快捷键:

[
  {
    "bindings": {
      "cmd-alt-o": [
        "agent::NewExternalAgentThread",
        {
          "agent": {
            "custom": {
              "name": "OpenCode",
              "command": {
                "command": "opencode",
                "args": ["acp"]
              }
            }
          }
        }
      ]
    }
  }
]

我把快捷键设成了 Cmd+Alt+O,按一下直接打开 OpenCode 的 Agent 面板。这个快捷键配置方式是 Zed 特有的,定义了一个"外部 Agent 线程"的动作,指向 OpenCode。

实际体验

在 Zed 里用 OpenCode 和在终端里用的最大区别是——Agent 面板是编辑器原生 UI 的一部分。你可以拖拽面板位置、调整大小、用键盘在编辑器和 Agent 之间切换。Agent 返回的 diff 可以直接在编辑器的 diff 视图里渲染,比终端里的纯文本输出清晰多了。

而且因为 ACP 支持多 session,你可以在 Zed 里同时开多个 OpenCode 对话——一个负责重构代码,一个负责写测试,并行推进。

JetBrains、Neovim 和其他编辑器

ACP 的生态已经覆盖了主流编辑器。以下是 OpenCode 支持的其他 IDE 配置方式。

JetBrains IDEs

IntelliJ IDEA、PyCharm、WebStorm 等 JetBrains IDE 也支持 ACP。配置方法是在项目的 acp.json 文件中添加:

{
  "agent_servers": {
    "OpenCode": {
      "command": "/absolute/path/bin/opencode",
      "args": ["acp"]
    }
  }
}

注意 JetBrains 需要用绝对路径。配置好后,在 AI Chat 的 Agent 选择器里就能看到 OpenCode 了。

Neovim: Avante.nvim

如果你是 Neovim 用户,可以用 Avante.nvim 来接入 OpenCode:

{
  acp_providers = {
    ["opencode"] = {
      command = "opencode",
      args = { "acp" }
    }
  }
}

需要传环境变量的话:

{
  acp_providers = {
    ["opencode"] = {
      command = "opencode",
      args = { "acp" },
      env = {
        OPENCODE_API_KEY = os.getenv("OPENCODE_API_KEY")
      }
    }
  }
}

Neovim: CodeCompanion.nvim

另一个选择是 CodeCompanion.nvim

require("codecompanion").setup({
  interactions = {
    chat = {
      adapter = {
        name = "opencode",
        model = "claude-sonnet-4",
      },
    },
  },
})

还有很多

根据 ACP 官方文档,支持 ACP 的客户端包括:

  • Emacs — 通过 agent-shell 插件
  • marimo notebook — Python notebook 环境
  • Eclipse — 原型开发中

在 Agent 侧,支持 ACP 的已经有 40+ 个,包括 Gemini CLI、Claude Code、Codex、GitHub Copilot、Goose、Cursor 等等。OpenCode 是其中之一。

这意味着什么?意味着你今天选了 OpenCode,明天想换 Zed 或者 Neovim,配置文件改两行就行。你的 Agent 配置、MCP 服务器、项目规则(AGENTS.md)都是跟着项目走的,跟编辑器无关。

和其他 IDE AI 工具的对比

最后聊聊 OpenCode 的 IDE 集成和其他方案的差异。我挑了几个有代表性的来对比。

OpenCode vs GitHub Copilot

Copilot 是编辑器里最"透明"的 AI 工具——你打字它补全,基本不需要主动交互。OpenCode 的定位不同,它是一个 Agent,你需要主动给它任务。Copilot 适合"你写代码我帮忙"的场景,OpenCode 适合"你描述需求我来写"的场景。

OpenCode vs Cursor

Cursor 本身就是一个修改版的 VS Code,AI 能力深度嵌入编辑器。它的优势是 AI 功能和编辑器 UI 融合得非常紧密。但代价是——你必须用 Cursor 这个编辑器。OpenCode 通过 ACP 协议实现了类似的原生体验,但你可以继续用自己喜欢的编辑器。而且 OpenCode 是开源的,配置完全透明。

OpenCode vs Claude Code

Claude Code 也有 VS Code 扩展,但它的 Agent 只能用 Anthropic 的模型。OpenCode 支持 75+ LLM Provider(通过 Models.dev),包括 Claude、GPT、Gemini、DeepSeek,甚至本地模型。在模型选择自由度上,OpenCode 优势明显。

Claude Code 通过 Zed 的 SDK adapter 实现 ACP 支持,而 OpenCode 是原生实现了 ACP——直接 opencode acp 就行,不需要额外的 adapter 层。

OpenCode vs Codeium / Tabnine

这类工具和 Copilot 类似,专注于代码补全。OpenCode 的 Agent 模式更强大——它可以执行多步骤任务、读写文件、运行命令、调用 MCP 服务器。不是同一个层面的东西。

一个关键区别:协议开放性

这是我觉得最值得关注的一点。在 AI Agent + 编辑器这个领域,大多数方案都是私有的、封闭的。Copilot 只能在 VS Code/JetBrains 里用,Cursor 要求你用 Cursor 编辑器,Claude Code 专注于 Anthropic 生态。

OpenCode 选了不同的路——拥抱 ACP 开放协议。这不只是技术选择,更是生态策略。开放协议意味着:

  • 编辑器自由:今天用 VS Code,明天换 Zed,后天试 Neovim——Agent 跟你走,不跟编辑器走
  • Agent 自由:你可以在同一个编辑器里切换不同的 Agent(OpenCode、Claude Code、Gemini CLI),按需选择
  • 配置一次,到处运行AGENTS.md、MCP 配置、自定义工具——这些跟着项目走,不管你用什么编辑器

这种模式更接近 Unix 哲学——做好一件事(AI Agent),通过标准协议(ACP)和其他工具组合。如果你和我一样在意工具的可组合性和开放性,OpenCode 的路线值得认真看看。


作者: itech001 来源: 公众号:AI人工智能时代 主页: https://www.theaiera.cn(每日分享最前沿的AI新闻和技术)

本文首发于 AI人工智能时代,转载请注明出处。

Enjoyed this article? Share it with others!