当我们与 Google 的 Gemini CLI 团队合作 推出 智能体客户端协议 (ACP) 时，我们没有想到对这种协议有如此大的压抑需求！
- 首先，我们看到了对 Anthropic 的 Claude Code 的大量请求
- 然后，我们看到许多 其他客户端和智能体采用 ACP，最近的是 JetBrains
- 现在，我们又看到了对 OpenAI 的 Codex 的新一波请求
截至今天，Zed 通过 ACP 开箱即用地支持 Codex。您可以像选择 Claude Code 或 Gemini CLI 一样，从“新线程”菜单中选择它。
与我们其他的 ACP 集成一样，通过 ACP 使用 Codex 严格是为了改进 UI 并让您在选择的 IDE 中保持流畅；计费和法律/条款安排直接在您和 OpenAI 之间进行。Zed 不收取使用 Codex 等外部智能体的费用，通过 Codex-ACP 发送给 OpenAI 的提示和代码也不会触及 Zed 的服务器！我们还另外开源了 codex-acp 适配器，以便您也可以在 Zed 之外使用它。
向不同智能体学习
每个模型的行为都与其他模型略有不同，智能体也是如此。例如，有些智能体支持在对话过程中切换模型，而另一些则要求始终使用相同的模型。有些支持查看和恢复过去的对话，而另一些则没有对话持久性的概念。ACP 的设计足够灵活，可以与各种智能体功能配合使用，但使用它们的体验仍然会因智能体的实现细节而异。
我们在构建 Codex ACP 适配器时遇到的一个细节是，Codex 智能体在其自己的进程中运行终端命令，然后将该终端进程的输出字节流传输到客户端。过去，我们曾将此反过来：智能体向客户端发送运行终端命令的请求（例如 mkdir examples），然后客户端管理该命令的实际运行。
自然，我们希望无论您使用哪个代理，都能保持一致的外观和感觉，但 Codex 和其他代理之间的这种设计差异使得某些细节不可避免地有所不同。例如，对于其他代理，我们可以在伪终端 (PTY) 模式下生成终端。这意味着如果代理启动交互式进程，您实际上可以直接在代理面板中与终端交互，这也意味着彩色终端输出等功能通常默认启用。
另一方面，处于 PTY 模式意味着智能体可能会卡住。一个经典的例子是当智能体尝试运行 git rebase --continue 并且终端弹出配置的编辑器时，然后等待程序员对提交消息进行任何编辑（如果需要）。这对于人类来说可能很好，但对于等待命令完成的智能体来说，这会造成死锁。如果没有交互，进程将不会继续，而智能体在进程完成之前不会进行交互！让终端在非 PTY 模式下工作可能会导致颜色减少和交互性降低，但也会导致智能体卡住的情况减少。
现在我们已经集成了启用和禁用 PTY 模式的智能体，我们可以比较两种情况下的体验，并以此为基础为未来的 ACP 集成提供建议。
下一个 ACP 集成是什么？
除了 Codex，我们还通过 ACP 为 Zed 添加了对 Claude Code、Gemini CLI 和其他智能体的支持。由于 ACP 不特定于 Zed，我们也看到它被 Neovim、Emacs 等编辑器以及现在的JetBrains 系列 IDE 所采用。
既然该协议已获得足够的自身采用，我们很高兴将重点转移到与社区合作，共同探讨协议的未来——而不是像我们为 Codex 和 Claude Code 所做的那样，亲自构建 ACP 适配器。我们很高兴看到社区将带来哪些令人惊叹的 ACP 集成！