Zjl37
1
（好像论坛还没人讨论 ACP，我来发个贴）
最近 Zed 好像在干一件很有眼光的事：提出 ACP 协议，将编辑器和 AI 编程助手的交互标准化
https://zed.dev/blog/bring-your-own-agent-to-zed/
ACP 的作用就好像从前微软的 LSP 协议将编辑器和语言服务解耦一样，只不过这次是连接 Coding Agents. 支持了 ACP 的 Agent 就能自动获得众多编辑器的集成，支持了 ACP 的编辑器就能接入各家不同编程助手，并很方便地切换不同的厂家。不需要再像以前一样，每个编辑器给 claude code 做一个集成插件，再给 gemini cli 做一个集成插件，再给什么新冒出来的做……也不需要通过一层终端进行交互了，毕竟这类 Command-line agents 的 TUI 都比较花哨难对付，而目前 Emacs 各个终端实现都有各的不太令人满意的地方，或者说能绕开终端的话集成度肯定能上一步。
Emacs 方面，目前好像只搜到一个人在做（并且ta好像还挺想要打钱的），目前刚起步一个很小的基础库
5 个赞
Zjl37
2
（（（怎么第一个链接没变成卡片）
如果此事能成，感觉像是继 tree sitter 之后，Emacs 再一次吃了 Zed 发展的福利（？
guo
3
按现在编程智能体的发展趋势，例如claude-code, codex, 编辑器的地位在下降，大多数时候并不需要编辑器了。
2 个赞
我的观点是，编辑器不需要介入 AI 的工作，所以自然不需要一个编辑器和 AI 之间交互的协议。
3 个赞
我认同三楼和四楼的观点。codex 现在就主打可以把 CLI 任务直接转移到云端 codex。顺便说一下现在有一个新的 AI Coding CLI 叫做 crush，这个 crush 内置了 LSP 的支持，意味着 AI 可以凭借着工具调用就可以看见 LSP 的诊断，查找等功能。那和编辑器本身的集成就更没必要了。
事实上这个 ACP 目前也只有 gemini-cli 在跟进。更多的是 zed 和 gemini-cli 团队搞出来的自己在玩的东西。 claude-code 的 ACP 是 zed 团队基于 clude code 的 SDK 自己实现的。codex 团队明确说了不会跟进，建议社区自行根据公开的 API 去做适配。
可能更需要的是反过来，编辑器适应agent。以agent为中心，编辑器被agent调用。agent完成代码之后，调用编辑器，给用户方便地展示出来修改点，改动对比诸如此类的。。。
这位作者好像开发了很多插件, 这个 agent-shell 试了下挺快的
作者回 issue 也很快
他看起来也挺急需 sponsor 的
他看起来也挺急需 sponsor 的
他已经说过自己现在被裁员了，所以他现在真的是在没有任何收入来源的情况下做开源工作。
前一段其实还有个类似的项目 GitHub - editor-code-assistant/eca: Editor Code Assistant (ECA) - AI pair programming capabilities agnostic of editor
主要是做 editor 方面的。不过好像关注度不高。
看下来感觉没太大必要。因为 editor 是给人用的，而 Agent 是属于自动化工具，像 mcp 那样就行，自动化完，人直接看观察结果和一点点过程就行。并不需要像人一样去执行过程。