模型 : claude-opus-4-6 (anthropic/claude-opus-4-6)
生成日期 : 2026-02-18
上一节我们看到 VSCode 扩展采用了"终端 + HTTP"的轻量级集成方案。本节将分析 OpenCode 在 Zed 编辑器中的扩展实现——一种与 VSCode 截然不同的集成方式。
16.2.1 packages/extensions/zed/ 配置
衍生解释——Zed 编辑器
Zed 是一款用 Rust 编写的高性能代码编辑器，由 Atom 编辑器（GitHub 开发的著名开源编辑器，2022 年停止维护）的原始团队创建。Zed 的核心特点包括：
极致性能 ：GPU 加速渲染，启动速度和响应速度远超 Electron 应用（VSCode 基于 Electron）
AI 原生 ：从架构层面集成了 AI Agent 能力，提供了"Agent Panel"作为 AI 交互界面
Zed 与 VSCode 最大的区别在于扩展模型。VSCode 的扩展是命令式 的——开发者编写 TypeScript/JavaScript 代码，调用 VSCode API 注册命令、创建 UI、处理事件。Zed 的扩展更倾向于声明式 ——通过配置文件描述扩展的能力，由 Zed 运行时负责具体的执行逻辑。
Zed 的 Agent Server 机制
Zed 编辑器引入了"Agent Server"的概念——它允许外部 AI Agent 作为"服务器"运行，Zed 作为"客户端"通过标准化协议与之通信。这正是 ACP（Agent Client Protocol）的应用场景：
Copy ┌───────────────┐ ACP ┌──────────────────┐
│ Zed 编辑器 │ ◄──── 协议通信 ────► │ OpenCode Agent │
│ (ACP Client) │ │ (ACP Server) │
│ │ │ │
│ Agent Panel │ │ opencode acp │
└───────────────┘ └──────────────────┘ 当用户在 Zed 中安装 OpenCode 扩展时，Zed 会：
根据当前操作系统和 CPU 架构下载对应的 OpenCode 二进制文件
执行 opencode acp 命令启动 OpenCode 的 ACP 模式
通过 ACP 协议与 OpenCode 进行全生命周期的交互
这与 VSCode 扩展的"创建终端 + HTTP 通信"模式有本质区别——Zed 扩展不需要任何自定义代码，所有集成逻辑由 ACP 协议标准化处理。
OpenCode 的 Zed 扩展位于 packages/extensions/zed/ 目录下：
整个扩展只有一个配置文件和一个图标——没有源代码、没有编译步骤、没有运行时依赖。
16.2.2 extension.toml 声明格式
让我们逐段分析 extension.toml 的完整内容：
这些字段是 Zed 扩展的标准元数据：
Agent Server 声明
agent_servers 是 Zed 扩展 TOML 中的关键段落。它声明了该扩展提供的 Agent Server 列表。一个扩展可以声明多个 Agent Server，每个都是一个独立的 AI Agent 服务。opencode 是 server 的标识符，name 和 icon 用于在 Zed 的 Agent Panel 中显示。
这是整个配置文件中最有意思的部分：
每个 target 段落定义了一个平台的构建产物和启动命令：
每个 target 包含三个字段：
archive .zip 格式，Linux 使用 .tar.gz 格式
cmd ./opencode.exe，其他平台是 ./opencode
args ["acp"]。这表示以 ACP 协议模式启动 OpenCode
衍生解释——跨平台二进制分发
为什么需要为每个平台单独提供二进制文件？这涉及到编译型语言的本质特征：
操作系统差异 ：不同操作系统的可执行文件格式不同——macOS 使用 Mach-O，Linux 使用 ELF，Windows 使用 PE/COFF。同一份源码编译出的二进制文件不能跨操作系统运行。
CPU 架构差异 ：x86-64（也称 AMD64）和 ARM64（也称 AArch64）使用不同的指令集。即使是同一操作系统，为 x86 编译的程序也不能直接在 ARM CPU 上运行（Apple 的 Rosetta 2 是一个例外，它在 M 系列 Mac 上对 x86 程序做实时翻译）。
OpenCode 使用 Bun（基于 JavaScriptCore 的 JavaScript 运行时）构建，Bun 本身是编译型应用，因此需要为每个平台目标单独构建二进制包。GitHub Actions 的矩阵构建（Matrix Build）功能可以自动化这个过程——在 CI/CD 流水线中同时为所有目标平台构建并发布到 GitHub Releases。
opencode acp：ACP 模式
所有平台 target 的 args 都是 ["acp"]。这意味着 Zed 启动 OpenCode 时执行的完整命令是：
这个命令启动 OpenCode 的 ACP 服务器模式——不显示 TUI 界面，而是通过标准输入/输出（stdin/stdout）与 ACP 客户端（即 Zed）进行 JSON-RPC 风格的协议通信。这与 Language Server Protocol（LSP）的工作方式类似——编辑器启动一个语言服务器进程，通过 stdio 进行双向通信。
16.2.3 VSCode 与 Zed 扩展方案对比
衍生解释——声明式 vs 命令式扩展模型
这两种扩展方案体现了软件工程中一个经典的设计权衡：
命令式（Imperative） ：开发者编写代码描述"怎么做"。VSCode 扩展就是典型——你调用 vscode.commands.registerCommand() 注册命令，调用 vscode.window.createTerminal() 创建终端，每一步都是显式的指令。优点是灵活性极高，缺点是需要了解宿主 API。
声明式（Declarative） ：开发者编写配置描述"要什么"。Zed 的 extension.toml 是典型——你只需声明"我有一个 Agent Server，它在各平台的二进制在哪里，启动命令是什么"，Zed 负责处理下载、解压、启动、通信的全部细节。优点是简单可靠，缺点是只能做框架预设的事情。
声明式模型的成功依赖于底层协议的通用性——ACP 协议如果足够强大，那么声明式的 Zed 扩展可以实现与命令式的 VSCode 扩展同等甚至更强的功能。这也是为什么 ACP 协议的设计如此重要。
从上面的对比可以看出，Zed 的集成方案虽然"零代码"，但功能深度远超 VSCode 扩展。这并非 Zed 扩展本身的功劳，而是因为 ACP 协议提供了一套完整的 Agent 交互标准——包括 Session 管理、权限审批、工具调用追踪、消息流式传输等。
下一节我们将深入剖析 ACP 协议的实现细节，理解 OpenCode 如何通过 acp/agent.ts、acp/session.ts 和 acp/types.ts 三个文件实现了完整的 ACP Agent 服务端。
