ACP v2 草案已发布（7分钟阅读）

# ACP v2 草案现已发布 - Agent Client Protocol 来源：https://agentclientprotocol.com/announcements/acp-v2-draft **发布时间：**2026年7月20日 今天，ACP 团队数月努力的目标终于实现，我们兴奋地分享**Agent Client Protocol 第 2 版的首个草案**。 自 v1 发布以来，我们借助协议的前向兼容特性以及我们的 RFD 流程（https://agentclientprotocol.com/rfds），成功交付了 **15 项以上 RFD** 及其相关功能。衷心感谢所有为此做出贡献的人，这也证明了我们无需每隔几个月进行大规模迁移，就能快速演进协议。 然而，在使用 v1 的过程中，我们也逐渐认识到，**某些**破坏性变更能够解锁当前协议难以表达的新用例和功能。v2 的核心目标就是：让更多会话状态得以表达，巩固我们已发现的实用模式，并让整体更加一致。 我们的目标是避免将所有能塞的东西都挤进 v2 而导致无法落地。因此，我们将继续依赖在 v1 中已证明行之有效的 RFD 流程（https://agentclientprotocol.com/rfds），引导新功能同时落地到 v1 和 v2，同时将本次发布紧密聚焦于几个核心行为的变更。如果你非常想要某个新功能但未在此列出，这并不意味着它不会被添加。我们只是希望将那些本身可选的或附加的功能与发布节奏解耦。 我们的核心设计目标仍然是为代理和客户端在实现中提供尽可能大的自由度，并仅就语义上有意义的部分达成一致。v2 让代理在会话期间的工作方式更加灵活，同时也为新的客户端模式铺平了道路。 ## v2 的主要主题 ### 超越“一轮对话” 当我们启动 ACP v1 时，大多数代理仅在用户发起消息后愉快地发出事件，并在生成完成后停止。但如今，代理能够工作更长时间，甚至编排越来越多的后台工作。虽然 ACP v1 规范并未*禁止*在“一轮对话”之外发送 `session/update` 通知，但这对实现者来说是一个常见的困惑点，他们通常希望围绕用户发起的一轮对话来保证交互模式。然而，强制这样做反而阻碍了有用的行为。代理可能已经准备好接收新输入，同时后台事件仍在发生，且它仍希望提供这些事件的实时更新。如果我们坚持面向“轮”的提示模式，双方都不满意。 如果我们希望允许对并非由用户发起的工作进行排队、引导或接收更新，就需要更清晰地表明提示请求/响应并不拥有整个工作生命周期的所有权。现在，`session/update` 通知可以在会话中的任何时间自由进行，而提示响应仅表示消息已被代理确认，并非一轮对话的结束。代理将重放用户消息在其插入位置的内容，这也有利于重放以及多个客户端观察同一会话的场景。代理可以指示自己何时处于“空闲”状态或准备好接收新输入，从而允许客户端指示就绪状态，同时代理可以继续更新会话状态。 更多信息请参阅新的提示生命周期 RFD（https://agentclientprotocol.com/rfds/v2/prompt）。 ### 更新消息与流式工具调用 用户消息、代理消息、工具调用以及终端输出现在通过稳定 ID 进行修补，具有统一的语义：省略的字段保持不变，`null` 表示清除，值则替换，块则追加。消息 ID 也成为必需，使得消息不仅可以流式传输，还可以在需要编辑或其他需求时进行更新和替换。 这种模式以前仅适用于工具调用，现在统一应用于这些会话项目类型，使事情更加一致和灵活。我们还将消息流式模式应用于工具调用内容，因此工具调用可以在不需要缓冲并反复重新发送整个内容的情况下进行流式传输。 ### 差异（Diff）重构 `oldText`/`newText` 差异被结构化的文件更改所取代。现在可以表达添加、删除、修改、移动、复制，以及二进制和非文本情况。其中一些情况在旧结构中可能可以推断，但并非全部。因此，我们希望现在能够报告代理在文件系统上所做的所有更改。 代理还可以提供可选的 `git_patch` 用于渲染更改。这可以直接显示，也足够结构化，以便客户端对文本更改进行良好的差异渲染。 ### 更灵活的权限请求 权限提示现在携带必需的 `title` 和可选的 `description`，并具有可扩展的 `subject`，而非硬绑定的工具调用。这也使得我们将来可以为终端命令或其他对象提供特殊的权限请求。将 `title` 和 `description` 与工具调用的标题和内容解耦，可以为做出决策的用户提供更多上下文，而不会意外覆盖工具调用本身。 ### 默认前向兼容 v1 的一大目标就是让 ACP 可扩展，这已被证明非常成功。许多人使用这些机制构建了出色的功能，其中一些已被回收到协议本身。 v2 现在使得在你能想到的几乎每个层面都可以进行扩展，以便在构建工具时提供更多实验或扩展点。模式中类似枚举的值接受未知变体，并使用 `_` 前缀表示实现特定的扩展。这建立在为会话配置选项添加的成功模式之上，并将其嵌入到模式本身中。这确保了新功能不会导致旧版客户端和代理在遇到未知嵌套数据时出错，并为在需要时扩展协议的更多部分提供了模式。 ## 草案状态 **v2 是一个草案**。我个人至少通读了模式中的每一行，甚至多次，我认为它已处于可开始测试的稳定状态。**但是，不同的部分在稳定之前可能而且将会发生变化**。这正是草案阶段的目的：在稳定之前接收反馈。 当你开始实现时，请将实现置于版本协商**和**功能标志之后。在接近稳定之前，不要在生产环境中默认发布。如果幸运的话，从现在到那时之间需要改变的地方不会很多。但我们也希望避免在大家共同适应必要变更的过程中给用户带来困扰。 添加 v2 支持不应意味着放弃 v1。仅支持 v1 的对端在一段时间内仍将普遍存在，因此实现者应同时支持两个版本。我们正在努力使这一点在各个 SDK 中更容易表达。 大多数类型在两个版本之间没有变化，但如果你维护代理、客户端或 SDK，请参考迁移指南（https://agentclientprotocol.com/protocol/v2/migration），其中通过前后示例说明了需要了解的关键变更。 ## 如何开始 - 阅读 v2 协议文档（https://agentclientprotocol.com/protocol/v2/overview）和迁移指南（https://agentclientprotocol.com/protocol/v2/migration）。 - SDK 作者可以针对 v2 JSON 模式生成代码，这些模式已在仓库发布中作为 `v2.0.0-alphaX` 与 v1 一同发布。 - v2 RFD 集合（https://agentclientprotocol.com/rfds/v2/overview）记录了较大变更背后的关键决策。 ## 我们期待你的反馈 现在的反馈最具影响力。如果 v2 中的某些内容不适合你的实现，请在稳定之前告诉我们：在 GitHub（https://github.com/agentclientprotocol/agent-client-protocol）上提交 issue 或发起讨论，或通过 RFD 流程（https://agentclientprotocol.com/rfds）参与单个 RFD 的讨论。 我坚信 v2 为我们提供了更好的基础来继续构建。它吸收了过去一年中的所有经验教训，巩固了一些常见模式，并为我们共同构建智能代理未来提供了更大的灵活性。 总的来说，对于有如此多的人使用 ACP 来构建代理、客户端以及你能想象到的几乎一切，我感到非常惊讶。这是一个广阔的领域，每一个采用 ACP 的新用例或应用都让我感到开心。你们的创造力推动着我们前进，我期待看到大家能用 v2 做出什么。