Zed 编辑器刚刚发布了 1.0 正式版。大多数媒体报道把焦点放在”版本号”上，但真正的故事完全不是版本号——Zed 1.0 通过 ACP（Agent Communication Protocol）协议，把编辑器从一个代码编辑工具变成了一个所有 Code Agent 的统一调度中心。
发生了什么
Zed 1.0 的核心变化可以概括为三点：
1. ACP 协议原生支持：直接在编辑器内启动 Claude Agent、Codex CLI、OpenCode、Cursor CLI、Gemini CLI，甚至国产的 Kimi CLI 和 Qoder CLI 都已被纳入支持列表。这些 Agent 不再需要通过 VSCode 插件或终端窗口各自为战——它们在 Zed 里共享同一个上下文感知层。
2. 并行 Agent 工作管理器：你可以同时启动多个 Agent 实例，各自处理不同任务（一个改 Bug、一个写测试、一个重构），Zed 的 ACP 面板会汇总所有 Agent 的进度，并在任务完成时通知你。这意味着”多 Agent 协作”第一次在编辑器层面获得了原生支持。
3. 会话历史导入：Zed 支持导入其他工具的历史会话记录，开发者不再需要为了切换工具而丢失之前的上下文。
为什么 ACP 比”装一堆插件”更重要
当前 AI 编辑器的普遍困境是：每个 Agent 都是一个孤岛。
Claude Code 有自己的 CLAUDE.md 配置，Codex 有自己的设置，Cursor 有自己的 Agent 模式。当你想在不同 Agent 之间切换时，你需要重新配置、重新建立上下文、重新”教”它理解你的项目。
ACP 协议的做法是把 Agent 标准化为一个可插拔的进程层：
| 能力 | 传统 VSCode 插件模式 | Zed ACP 模式 |
|---|---|---|
| Agent 启动 | 每个插件独立进程 | 统一 ACP 进程管理 |
| 上下文共享 | 插件间无法通信 | 通过 ACP 协议共享项目上下文 |
| 通知机制 | 各插件各自的 UI | 统一 ACP 通知面板 |
| 会话迁移 | 不可能 | 支持导入其他工具历史 |
| 并行执行 | 需要手动切换终端 | 原生并行 Agent 工作管理器 |
实际体验：多 Agent 怎么协作
根据社区开发者的实际使用反馈，典型的多 Agent 工作流是这样的：
1. 在 Zed 中打开项目
2. 启动 Agent A（Claude）：处理核心业务逻辑重构
3. 启动 Agent B（Codex）：同步编写单元测试
4. 启动 Agent C（Kimi CLI）：审查代码并生成文档
5. ACP 面板实时显示三个 Agent 的进度
6. 任一 Agent 完成时，Zed 通过通知面板提醒你
7. 所有变更通过 Zed 的 diff 系统统一呈现这不是”在三个终端窗口之间切换”——而是真正的编辑器级别的 Agent 编排。
行业格局判断
Zed 1.0 的发布标志着 AI 编辑器竞争进入了新阶段：
- Cursor 的护城河在于”AI 原生编辑器”的品牌认知，但它主要绑定 Claude 生态
- VSCode + 插件 胜在生态广度，但 Agent 体验是碎片化的
- Zed 的策略是”我不做 Agent，我做 Agent 的入口”——这是一个更聪明的定位
当一个编辑器能同时调度 Claude、Codex、Kimi、Qoder 时，开发者就没有理由被任何一个 Agent 厂商锁定了。Zed 可能正在成为 Agent 时代的”通用遥控器”。
行动建议
- 如果你已经在用多个 Code Agent：Zed 1.0 是目前唯一提供原生多 Agent 管理的编辑器，值得花 30 分钟试用
- 如果你只用一个 Agent：短期内 Zed 的优势不明显，但 ACP 协议的开放性意味着未来会有更多 Agent 接入，长期看有迁移价值
- 如果你在做 Agent 开发：ACP 协议的标准化可能成为下一个行业标准，值得花时间了解其接口设计
Zed 1.0 不是终点——它是一个信号：编辑器的战场已经从”谁的 AI 更强”转移到”谁能最好地管理多个 AI”。