上周我在 Zed 里试了一个新功能。

我在输入框敲了一句：

“帮我重构这个模块”

回车之后，发生了一件很反直觉的事：

跑出来的不是 Zed 自带的 AI，也不是某个插件。

而是 Claude Code。

更奇怪的是：我没有装任何插件，没有改任何配置。

就像在编辑器里直接调用了一个本地命令。

并不像Trae等IDE内需要自己选择Claude Code或OpenCode后才会唤醒

我当时停了大概三秒。

不是惊讶功能，而是意识到一件更底层的事情：

编辑器这场打了十年的仗，可能方向一直错了。

它们一直在优化“怎么接 AI”，但没人真正解决：

“编辑器和 AI，到底该怎么说话？”

也就是这件事让我看到一个东西：ACP（Agent Client Protocol）

一、ACP 不是产品，它是“语言层”

先说清楚一件事：

如果你把 ACP 当成“又一个 AI 编辑器插件”，那基本会理解错。

它既不是模型，也不是编辑器。

它是一件更底层的东西：

一套定义“编辑器如何和 Agent 对话”的协议

我用一个更直观的类比：

USB 出现之前：

• 鼠标、键盘、打印机各有各的接口
• 每个厂商都在重复造适配器
• 插错接口是常态

USB 出现之后：

• 全部统一成一个标准口
• 外设可以自由流动

ACP 做的事情，本质类似：

它让 Claude Code、Codex、你自己写的 Agent，都能“插进任何支持 ACP 的编辑器里”。

编辑器不再关心：

• Agent 是谁写的
• 用什么模型
• 内部怎么推理

Agent 也不再关心：

• 运行在 Zed / VS Code / JetBrains 哪个环境

双方只说一种“语言”：

ACP

二、为什么偏偏是现在？

这个问题我一开始也没想明白。

毕竟：

• Copilot 已经 4 年了
• Cursor 已经成为事实标准
• 各种 AI 编辑器满天飞

为什么还需要一个协议？

直到我拆了一圈现有系统，才发现一个很尴尬的现实：

大家都在重复造“编辑器 × AI”的集成层

而且是两边都在重复。

第一层重复：编辑器在造适配层

Zed 要接 Claude Code，要写一套适配逻辑。

Cursor 要接 Codex，又要写一套。

VS Code 更夸张：每加一个 Agent，就是一套新插件体系。

但本质都在做同一件事：

文件系统暴露 + 上下文管理 + streaming UI + diff 渲染

只是实现方式完全不统一。

第二层重复：Agent 也在造适配层

Claude Code 想进 Zed，要适配 Zed。

Codex 想进 Cursor，要适配 Cursor。

结果变成：

Agent 在适配编辑器，编辑器在适配 Agent

两边在互相消耗。

我粗略看了一下：

仅“对话 + 文件操作 + 会话管理”这一层逻辑，

在 Zed / VS Code / Cursor / JetBrains 之间，至少重复实现了三到五次。

ACP 的一句话答案很简单：

别再各自造了，统一一层协议吧。

它不是在优化某个产品，而是在砍掉整个重复层。

三、ACP 在工程上到底解决了什么？

如果拆成工程能力，其实就四件事：

1）会话标准化（Session Protocol）

• 统一 Agent 生命周期
• 支持恢复 / 续跑 / 多轮状态

👉 解决：AI任务断裂问题

2）流式事件（Streaming Events）

• thinking
• plan
• diff
• tool result

👉 解决：AI黑盒不可观测

3）代码修改闭环（Patch System）

• Agent 输出不只是文本
• 而是结构化 diff

👉 解决：AI不能“真正改代码”

4）人类控制点（Approval Gate）

• diff review
• pause / resume
• human-in-the-loop

👉 解决：企业无法控制 AI 行为

一句话总结 ACP：

它把 Agent 从“聊天机器人”变成了“可控执行体”

四、对开发者意味着什么？

我试了几种接入方式，感受比较直接。

1）编辑器终于可以“换 AI”了

以前是：

用什么编辑器 = 用什么 AI

现在变成：

编辑器固定，AI可以换

比如：

• Zed + Claude Code
• Zed + Codex
• Zed + 自研 Agent

切换成本变成：

改一行配置

2）Agent 开发者第一次“脱离编辑器绑定”

以前你做 Agent：

• 要么 CLI
• 要么 VS Code 插件
• 要么 Cursor 内部适配

现在变成：

只要实现 ACP，就能进所有编辑器

3）CI/CD 也开始“Agent 化”

我试过一个 acpx（ACP CLI 客户端），放进 GitHub Actions：

• PR 自动触发 Agent review
• 自动读 diff
• 自动跑测试
• 自动评论

全程无 UI。

但效果比人工 review 更稳定。

五、ACP vs MCP：很多人其实搞反了

这里是最容易误解的点。

MCP 做的是：

Agent 能“用什么工具”

比如：

• 查数据库
• 调 API
• 读文档

ACP 做的是：

编辑器怎么“和 Agent 说话”

比如：

• 怎么发任务
• 怎么收 diff
• 怎么控制执行

一个是：

能力层（Tooling）

一个是：

交互层（Control Plane）

可以这么记：

• MCP = 给 Agent 装工具箱
• ACP = 给编辑器装“耳机接口”

六、生态已经开始动了

我看了一圈 GitHub，有几个信号挺明确：

• ACP 协议本身已经有几千 star
• openclaw 利用acpx CLI 在做 CI 自动化
• Obsidian 已经有人接入 Agent
• Cline 开始支持 ACP

这说明一件事：

ACP 不是概念，是已经在工程化落地的东西

七、我自己的判断

说几个不那么“宣传稿”的判断：

1）ACP 时机是对的

行业刚好进入：

“AI 编辑器过剩，但接口不统一”的阶段

2）短期赢家是编辑器，长期赢家是 Agent Runtime

因为：

编辑器会被协议解耦

3）最大风险是生态碎片化

如果：

• VS Code 不认
• Cursor 半支持
• Zed 独占推进

那 ACP 可能变成：

“一个优秀但局部的协议”

写在最后

我最近换编辑器的频率越来越低了。

不是因为工具变好了。

而是因为：

AI 终于从“编辑器的一部分”，变成了“可插拔的能力层”

ACP 不是让编辑器更聪明。

它做的更底层：

让编辑器和 AI，终于开始用同一种方式交流。