ACP：从代码编辑器到全应用时代的AI Agent通用连接器——解锁Agent生态的宏大愿景

引言：AI Agent时代的“应用孤岛”困境

2026年，AI Agent已经从实验室概念走向大规模落地。Claude Code、Codex CLI、Gemini CLI、OpenCode、Qwen Code、Grok系列Agent、DeepSeek Agent，以及轻量级本地框架如nanobot、各种多Agent系统，层出不穷。它们在代码生成、推理、工具调用、自主规划等方面展现出惊人能力。

然而，一个严峻现实摆在面前：这些强大Agent大多被锁定在特定应用中。代码编辑器（Zed、JetBrains、VS Code、Cursor）是当前主战场，用户必须在特定IDE中才能充分调用某款Agent。笔记软件、设计工具、企业内部系统、浏览器、生产力平台等，仍然处于“AI Agent能力贫瘠”状态。用户被迫在不同工具间切换上下文，重复提示，丢失知识连续性，效率大打折扣。

Agent Client Protocol（简称ACP）正是为解决这一“紧耦合”问题而生。它被明确类比为AI时代的Language Server Protocol (LSP)。正如LSP让任意编辑器都能获得丰富的语言智能，而无需为每种语言重写集成，ACP旨在让任意应用通过实现一套标准化协议，就能接入整个AI Agent生态。

本文将详细阐述ACP的诞生背景、技术架构、当前在代码编辑器中的实践、向Obsidian、Figma、企业自动化平台等领域的扩展路径、实现指南、面临的挑战，以及最终的宏大愿景：ACP将成为AI Agent时代的通用连接器，推动从“应用+插件”向“应用+Agent生态”范式转变。

一、ACP的前世今生：从碎片化到标准化

1.1 历史参照系：LSP如何改变了编程工具生态

十年前，编程语言的智能提示功能面临和今天AI Agent一模一样的困境。当时，Visual Studio Code、Sublime Text、Atom、Vim、Emacs……每个编辑器都需要为每种编程语言单独实现代码补全、语法检查、跳转定义等功能。这是一个典型的M×N集成困境：M个编辑器×N个语言=M×N个集成工作。

2016年，微软发布了Language Server Protocol（LSP），定义了一套标准化的JSON-RPC协议，让编辑器与语言服务器能够以统一的方式通信。语言服务器实现一次，就能在所有支持LSP的编辑器中运行；编辑器实现一次LSP客户端，就能支持所有LSP语言服务器。

LSP彻底改变了编程工具生态。今天，几乎所有主流编辑器都支持LSP，几乎所有主流编程语言都有对应的LSP实现。这就是协议的力量——它不创造功能，但它让功能可以自由流动。

1.2 今日困境：AI Agent的“巴别塔”

时间快进到2024-2025年，AI编码智能体迎来了爆发期。Claude Code、Gemini CLI、GitHub Copilot、Codex、OpenCode、Goose、Qwen Code……各种Agent层出不穷，每个都有独特的优势和设计理念。

但问题也随之而来。在ACP出现之前，这些Agent与编辑器的集成方式是这样的：VS Code需要为Claude Code写一套集成代码，JetBrains需要为Gemini CLI写一套集成代码，Neovim需要为OpenCode写一套集成代码……每个Agent都有自己的API设计，每个编辑器都要重复实现相同的功能（文件读写、终端控制、权限管理）。Agent开发者被锁定在特定编辑器生态里，编辑器开发者也疲于为层出不穷的新Agent写适配层。

这正是十年前LSP所解决的M×N困境——只是这一次，主角从“编程语言”变成了“AI编程智能体”。

1.3 ACP的诞生：从终端hack到开放标准

ACP的诞生源于一个非常实际的问题。2025年初，Zed团队正在开发实验性的“智能体编辑”（agentic editing）功能——让AI助手能够自主执行多步代码修改。当时Google带着Gemini CLI找到Zed团队，双方都希望实现比“在终端里运行CLI”更深度的集成。

Zed的开发者回忆道：“我们已经在嵌入式终端里运行Gemini CLI……但我们需要一种比ANSI转义码更结构化的通信方式。”他们的解决方案是定义一套最小的JSON-RPC端点集合，用于传递用户请求和渲染Agent响应。这个实用主义的方案——源于即时需求而非委员会设计——后来成为了ACP的基石。

2025年8月，Zed以Apache许可证正式发布了ACP作为开放标准，Google的Gemini CLI成为首个参考实现。ACP的核心设计理念是：用户主要在代码编辑器中工作，希望能够随时调用智能体来协助完成特定任务。它同时支持本地和远程两种部署场景——本地智能体作为代码编辑器的子进程运行，通过stdio使用JSON-RPC通信；远程智能体可部署在云端或独立基础设施上，通过HTTP或WebSocket通信。

2025年10月，JetBrains正式宣布支持ACP，并与Zed联合推进协议的发展。JetBrains强调，ACP的最大好处是“没有厂商锁定”——开发者可以在任何支持该协议的IDE中使用他们偏好的编程助手。

二、ACP的技术架构详解

2.1 通信模型：JSON-RPC 2.0的双向对话

ACP的通信模型基于JSON-RPC 2.0规范，支持两种类型的消息：请求（Request）——需要响应的请求-响应对，包含id字段；通知（Notification）——单向消息，不需要响应，不包含id字段。

这种双向通信设计是ACP区别于LSP的关键特征。LSP是编辑器主动、语言服务器被动响应；而ACP中，Agent可以主动向Client发起请求——例如请求读取文件内容、请求执行终端命令、请求用户授权等。

ACP默认使用stdio作为传输通道，Agent作为Client的子进程运行，通过标准输入输出进行JSON-RPC通信。Kiro CLI的ACP实现就是一个典型例子：kiro-cli acp启动后通过stdio进行JSON-RPC 2.0双向通信，任何支持ACP的编辑器都可以通过子进程方式调用它。这种方式的优势在于简洁高效、安全可靠——Agent的生命周期由编辑器管理，通信过程不涉及网络层，天然隔离。

2.2 协议架构：三个核心组件

ACP的架构包含三个核心组件：

Client（客户端） ：通常是代码编辑器或IDE，负责提供用户界面、管理环境、控制资源访问。Client向Agent发送用户提示，并处理Agent发出的文件操作、终端命令、权限请求等。
Agent（智能体） ：使用生成式AI自主修改代码的程序，通常作为Client的子进程运行。Agent接收用户指令，自主规划并执行代码修改任务，期间可以向Client请求所需的资源和操作。
Proxy（代理） ：可选组件，位于Client与Agent之间，可拦截并转换消息，实现提示注入、日志记录、安全审计等高级功能。

此外，ACP还定义了Conductor这一可选的中心化组件，负责在代理链（Proxy Chains）中协调消息流。

2.3 通信生命周期：从握手到完成

一个完整的ACP交互遵循三个阶段：

阶段一：初始化（Initialization） ——Client向Agent发送initialize请求，协商协议版本并交换能力信息。

阶段二：会话创建（Session Setup） ——Client通过session/new创建新会话，指定工作目录和可用的MCP服务器。

阶段三：提示回合（Prompt Turn） ——核心交互阶段：Client通过session/prompt发送用户消息；Agent通过session/update通知流式推送进度更新；Agent根据需要发起文件操作或权限请求；Client可以随时发送session/cancel中断处理；回合结束时，Agent发送响应，包含停止原因。

2.4 核心能力：Agent的“手”与“脚”

ACP为Agent定义了几类核心能力，让Agent真正成为一个“有手有脚”的助手：

文件系统操作：Agent可以读写文件，但路径必须是绝对路径，且受会话的工作目录约束。

终端控制：Agent可以创建终端、执行命令、获取输出、等待退出。这让Agent能够真正“动手”——运行测试、构建项目、安装依赖。

权限请求：当Agent要执行敏感操作时，必须先请求用户授权。用户可以选择允许、拒绝，或者允许所有同类操作。这是ACP信任模型的核心——Agent有能力，但用户有最终控制权。

流式响应：Agent可以流式推送响应内容，实现逐字输出效果。

2.5 多语言SDK生态

ACP官方和社区提供了丰富的SDK支持，极大降低了集成门槛：

Rust SDK：par-term-acp提供了核心ACP协议实现，用于与AI编码智能体（Claude Code、Codex CLI、Gemini CLI等）通信，处理智能体生命周期管理、文件系统沙箱、权限分发和会话管理。
Java SDK：Spring AI社区提供了纯Java实现的ACP SDK，支持构建客户端和智能体，与Zed、JetBrains、VS Code及任何ACP兼容编辑器协同工作。SDK提供客户端SDK、智能体SDK和测试工具三大部分。
Dart SDK：acp_dart是官方的Dart实现，提供了JSON-RPC错误映射，参数验证失败映射到-32602（Invalid params），意外运行时失败映射到-32603（Internal error）。
TypeScript/JavaScript SDK：@agentclientprotocol/sdk是官方TS实现。
Kotlin SDK：用于JetBrains深度集成。
Python SDK：面向Agent开发的官方实现。
Go SDK：社区贡献，丰富了企业级集成选择。
Swift SDK：社区贡献，面向Apple生态。

三、ACP与MCP、A2A的关系：互补而非竞争

在理解ACP时，最容易被问到的问题是：ACP和MCP有什么区别？它们会竞争吗？答案是：它们互补，而非竞争。

3.1 MCP：Agent的“工具箱”

MCP（Model Context Protocol）由Anthropic于2024年底推出，它解决的核心问题是：AI模型如何标准化地访问外部工具和数据源。MCP提供了标准化的工具调用接口，让Agent可以查询数据库、调用API、访问文件系统、执行本地脚本等。它本质上拓宽了模型的“感知与行动边界”。

3.2 ACP：Agent的“工作台”

ACP解决的是完全不同的问题：编辑器（或更广泛的客户端）如何与AI Agent通信。ACP定义了Agent如何接收用户指令、如何向编辑器请求文件内容、如何请求执行终端命令、如何请求用户授权、如何展示代码diff。它本质上定义了Agent在编辑器中的“存在方式”。

3.3 三者关系：工作台、工具箱与通讯录

用一个比喻来理解三个主要Agent协议的关系：

ACP（Agent Client Protocol） 是Agent的“工作台”——定义Agent在哪里工作、如何与用户交互
MCP（Model Context Protocol） 是Agent的“工具箱”——定义Agent能用什么工具
A2A（Agent-to-Agent Protocol） 是Agent的“通讯录”——定义Agent之间如何协作

在ACP的设计中，编辑器可以把用户配置的MCP服务器信息传递给Agent，Agent收到后直接连接这些MCP服务器获取工具能力。这种设计的好处是：编辑器不需要知道Agent内部如何使用工具，Agent也不需要关心MCP服务器是谁配置的。

三者可以组合使用：用户通过ACP在编辑器中向Agent发送指令；Agent通过MCP调用外部工具获取数据；遇到自己不擅长的任务时，Agent通过A2A委托给其他专业Agent；所有结果最终通过ACP流式返回到编辑器。

四、生态关键里程碑：ACP Registry的诞生

如果说ACP协议本身定义了“通信的语言”，那么ACP Registry就是这套语言的“应用商店”。

4.1 从碎片化分发到统一注册表

在ACP Registry出现前，开发者面临两大难题：重复打包——同一个Agent要为Zed、VS Code、JetBrains各做一套扩展；更新延迟——用户装的是旧版，新功能要等编辑器审核才能上线。

2026年1月28日，Zed与JetBrains联合宣布ACP Registry正式上线。开发者只需注册一次Agent，所有兼容ACP的编辑器（Zed、JetBrains全家桶、VS Code等）都能自动发现并使用最新版。正如Zed团队所说：“Implement once, work everywhere.”（一次实现，处处运行）。

4.2 入驻Registry的热门Agent

ACP Registry中已收录了多款经过审核的Agent：

Auggie CLI（Augment，专注大规模代码重构）
Claude Code（Anthropic）
Codex CLI（OpenAI）
Factory Droid（自动化代码生成工作流）
Gemini CLI（Google，ACP的首个参考实现）
GitHub Copilot（Microsoft）
Mistral Vibe（Mistral AI，轻量级快速Agent）
OpenCode（社区驱动的开源Agent）
Qwen Code（Alibaba，多语言支持）

此外，Kimi CLI（Moonshot AI）、goose（Block公司）、Augment Code等也已确认支持ACP协议。

4.3 客户端支持全景

ACP的客户端生态已经从Zed一家扩展到几乎所有主流编辑器：

客户端类型	代表产品	支持方式
原生支持	Zed	深度集成，ACP的诞生地
IDE平台	JetBrains全家桶（IntelliJ IDEA、PyCharm、GoLand、WebStorm等）	从2025.3版本起原生支持
插件方式	VS Code、Cursor	通过ACP Client扩展
经典编辑器	Neovim、Emacs	通过CodeCompanion、agent-shell等插件
笔记软件	Obsidian	通过Agent Client插件
浏览器	Chrome	通过Chrome ACP扩展/PWA
数据工具	Jupyter Notebooks、DuckDB	通过扩展
即时通讯	Discord、Slack、Telegram	通过各类桥接工具

4.4 关键时间线

2025年初：Zed团队开始实验“agentic editing”功能
2025年8月：Zed正式发布ACP开放标准，Gemini CLI成为首个参考实现
2025年10月：JetBrains宣布正式支持ACP
2026年1月28日：ACP Registry正式上线
2026年2月：ACP Registry的RFD从Preview阶段移至Completed

五、Obsidian的突破：知识工作中的Agent革命

Obsidian是ACP扩展至非代码领域的最成功早期案例。2026年初社区开发者推出obsidian-agent-client插件，直接基于ACP协议，将Claude Code、Codex、Gemini CLI、OpenCode乃至Qwen Code引入Obsidian。

5.1 插件功能全景

obsidian-agent-client插件的核心能力包括：

嵌入式聊天面板：在Obsidian右侧边栏直接与AI Agent对话，无需切换应用
笔记上下文引用：使用@notename语法直接在对话中引用特定笔记内容
斜杠命令：快速触发Agent操作而无需输入完整提示词
多Agent切换：在Claude Code、Codex、Gemini CLI之间自由切换，根据任务选择最优Agent
模型/模式切换：在聊天界面直接切换模型（如Sonnet、Haiku、Opus）和Agent模式（如Plan Mode）
终端命令执行：Agent可执行shell命令并内联返回结果——运行构建脚本、git命令或任何终端操作
图片输入：粘贴或拖拽图片到聊天中，适合视觉调试或UI相关问题
细粒度权限控制：基于舒适度批准或拒绝文件读取、编辑和命令执行

5.2 知识工作的新范式

在Obsidian中，用户可以对整个知识库（数百篇双向链接笔记）进行语义查询与重构；让Agent自动生成Literature Review、更新知识图谱、找出矛盾点；在写作时实时调用Agent进行事实检查、灵感扩展、结构优化；Agent可读取Markdown、调用MCP工具（如搜索、计算、绘图），并将结果以新笔记或嵌入方式返回。

这已超出“聊天插件”范畴，而是让笔记软件成为Agent的第二大脑。用户不再把Obsidian当作静态存储，而是动态的、具有自主性的知识工作站。正如一位用户所说：“这种体验让我可以把自己的本地Obsidian知识库与AI无缝结合在一起，也不需要另开窗口，直接在应用内就可以开始使用。”

5.3 技术实现细节

插件基于ACP协议，通过Zed的SDK适配器连接各类Agent：

Claude Code → 通过Zed的SDK适配器（@zed-industries/claude-code-acp）
Codex → 通过Zed的适配器（@zed-industries/codex-acp）
Gemini CLI → 直接通过--experimental-acp选项
自定义Agent → 任何ACP兼容的Agent（如OpenCode、Qwen Code）

截至2026年2月，该插件仍在Obsidian社区插件审核中，当前推荐通过BRAT（Beta Reviewers Auto-update Tester）安装。

这证明了ACP的普适性：任何需要“理解上下文+自主行动+富输出”的场景，都适合ACP。

六、设计工具的未来：Figma中的智能Agent协同

如果说Obsidian展示了ACP在知识管理领域的落地潜力，那么Figma的实践则揭示了ACP在创意设计领域的巨大想象空间。

6.1 Figma向Agent开放画布

2026年3月24日，Figma正式宣布向AI Agent开放画布。通过Figma MCP server，AI Agents现在可以直接编辑Figma文件，使用设计系统中的组件、变量和标记创建和修改真实的设计资产。

关键工具包括：

use_figma工具：使Agent能够直接在设计画布上操作，利用设计系统进行创作和修改
generate_figma_design工具：将实时应用和网站的HTML转换为可编辑的Figma图层，当设计与代码不同步时，可将最新UI导入Figma进行迭代
Skills（技能） ：作为Markdown文件编写的一系列指令，定义Agent如何在Figma中执行工作流——包括步骤、顺序和应遵循的惯例

6.2 Uber的实战案例：uSpec自动化设计规范生成

Uber的设计系统团队提供了一个极具说服力的实战案例。他们构建了uSpec——一个连接Cursor中AI Agent与Figma的智能体系统，通过开源的Figma Console MCP自动生成组件规范。

单个组件规范就包括6个部分：解剖结构（编号标记+属性表）、API（所有可配置属性、值和默认值）、属性（变体轴和布尔开关+实例预览）、颜色标注（每个元素映射到设计token）、结构（各尺寸和密度变体的高度/内边距/间距）、屏幕阅读器（VoiceOver、TalkBack、ARIA的数百个属性）。

过去，设计师需要数周手动创建这些规范。通过uSpec，Agent在几分钟内完成整个流程，且所有数据在本地处理——不通过网络发送任何专有设计数据，这对Uber这样的企业至关重要。

6.3 ACP视角下的Figma场景

虽然Figma当前主要通过MCP（而非ACP）实现Agent集成，但这一方向恰恰印证了ACP的设计理念。从ACP的角度看，Figma的实践揭示了一个关键趋势：设计工具的核心资产（画布、组件、时间线、图层）完全可以序列化为Agent可理解的上下文。

如果Figma未来实现ACP Client，将带来更丰富的交互可能：设计师选中画布区域，Agent通过ACP接收完整画布状态（组件树、样式、变量），提出多方案、生成变体、自动调整布局；多Agent协作——一个Agent擅长UI布局，一个擅长用户研究洞察，一个擅长无障碍设计，通过底层协作协议协同，再通过Client ACP将最终结果落地到Figma画布；Agent提出的修改以可视化diff形式呈现，用户一键接受或迭代，如同代码审查。

类似场景适用于Adobe Suite、Framer、Canva、Blender（3D）、DaVinci Resolve（视频）。设计工具的核心资产完全可以序列化为ACP上下文，插件或内置扩展只需实现ACP Client，即可接入整个Agent生态。

七、企业自动化平台的ACP落地

企业场景需求更为迫切。许多公司有内部CRM、ERP、OA、BI、代码仓库、知识库等孤岛系统。传统RPA（Robotic Process Automation）僵硬、维护成本高。AI Agent天然适合复杂、动态、需要判断的流程。

7.1 从本地协议到企业编排网关

ACP在企业场景的一个重要演进方向是作为多Agent编排的基础设施。以OpenClaw为例，它通过深度扩展ACP，将其从一个本地开发协议升级为整个多Agent编排体系的“远程控制总线”。

OpenClaw对ACP的关键扩展包括：

双层桥接架构（Bridge & Gateway） ：表面通过ACP接收客户端请求，内部将请求翻译并转发到自己的Gateway，再由Gateway调度真正的模型或工具
多Agent调度（Multi-Harness） ：同时挂载多个Agent，利用ACP反向调用外部Agent进行工作流接力
会话持久化与线程绑定：传统ACP断开即丢失，而OpenClaw的ACP会话可以持久化存储，并与Discord、Telegram等外部通道的频道/用户进行线程绑定
零信任接入策略：在WebSocket连接之上叠加多因子认证（Gateway Token、设备签名Ed25519、Bootstrap Token、Tailscale身份等）

简而言之，在OpenClaw的语境下，ACP已经从一个本地开发协议，升级为进入整个多Agent编排体系的“远程控制总线”。这为ACP在企业级自动化场景中的应用提供了强有力的参照。

7.2 n8n工作流自动化集成

n8n-acp-agent是另一个有趣的实践案例。它是一个ACP兼容的JSON-RPC智能体，能够根据提示词或结构化意图自动组合生产就绪的n8n工作流JSON，与Zed的外部Agent和Neovim通过ACP兼容客户端协同工作。

支持的方法包括：initialize、session/new、session/prompt、create_workflow、modify_workflow、explain_workflow等。通过自然语言描述工作流需求（例如“创建一个每小时运行的n8n工作流，获取带有bug标签的开放问题，总结标题并发布到#alerts频道”），Agent可以自动生成完整的n8n工作流配置。

这展示了ACP在企业工作流自动化中的巨大潜力：通过ACP，用户可以在熟悉的界面（编辑器、笔记软件、企业内部平台）中，以自然语言驱动复杂的企业工作流自动化。

7.3 企业ACP落地的架构设想

通过ACP，企业内部平台可以：

将内部系统暴露为安全的上下文与Action（经严格权限控制）
允许员工在熟悉界面中调用企业级Agent（如基于公司私有数据的Agent或自托管模型）
实现“自然语言驱动的企业自动化”：“帮我分析本季度销售异常，找出Top 5原因，并生成corrective Jira tickets和邮件草稿”
多Agent流水线：Research Agent收集数据→Analysis Agent建模→Decision Agent提出建议→Execution Agent在系统中落地，全程通过ACP与Client保持结构化沟通

安全与合规是核心。ACP可结合企业权限系统、审计日志、人类-in-the-loop确认机制。JetBrains的产品经理指出：“展望未来，您的IDE将通过ACP协议作为中介，管理对文件、终端和其他工具的访问。结果就是智能体在您的日常工具中变得可移植、强大且可预测。”相比为每个内部工具单独训练或集成Agent，ACP提供“一次实现、全生态可用”的路径，大幅降低企业AI adoption成本。

八、技术实现指南：如何为你的应用添加ACP支持

实现ACP门槛相对可控，参照LSP的经验即可。

8.1 实现路径

选择传输层：本地优先用stdio JSON-RPC，远程用WebSocket/HTTP。
实现Client侧：暴露应用当前上下文（文件、笔记图谱、画布JSON、选中元素等）；处理Agent返回的事件（streaming text、proposed edits、tool requests、diffs）；提供UI层渲染（侧边栏聊天、画布overlay、接受/拒绝按钮）。
安全沙箱：所有修改需用户确认或使用细粒度权限。ACP采用了基于角色的访问控制（RBAC）和操作特定的JWT来增强安全性。
兼容MCP：让Agent能进一步调用应用暴露的工具。

8.2 快速上手示例：Java SDK

以ACP Java SDK为例，以下是连接Gemini CLI作为ACP Agent子进程并发送提示的完整代码示例：

// 启动Gemini CLI作为ACP Agent子进程  
var params = AgentParameters.builder("gemini")  
    .arg("--experimental-acp")  
    .build();  
var transport = new StdioAcpClientTransport(params);  
  
AcpSyncClient client = AcpClient.sync(transport)  
    .sessionUpdateConsumer(notification -> {  
        // 流式输出Agent响应  
        if (notification.update() instanceof AgentMessageChunk msg) {  
            System.out.print(((TextContent) msg.content()).text());  
        }  
    })  
    .build();  
  
client.initialize();  
var session = client.newSession(new NewSessionRequest(".", List.of()));  
var response = client.prompt(new PromptRequest(  
    session.sessionId(),  
    List.of(new TextContent("What is 2+2? Reply with just the number."))  
));  
System.out.println("\nStop reason: " + response.stopReason());  
client.close();

官方文档（agentclientprotocol.com）提供了完整的规范与多语言SDK。社区已有Obsidian、Chrome扩展、Unity等参考实现。

8.3 Zed中的Agent集成

以n8n-acp-agent在Zed中的集成为例：

// ~/.config/zed/settings.json  
{  
  "agent_servers": {  
    "n8n_workflow_agent": {  
      "command": "n8n-acp-agent",  
      "args": [],  
      "env": {  
        "OPENAI_API_KEY": "${OPENAI_API_KEY}",  
        "RAGIE_API_KEY": "${RAGIE_API_KEY}"  
      }  
    }  
  }  
}

这种基于子进程+环境变量的设计模式简单而强大——任何遵循ACP协议的Agent都可以通过类似方式集成到支持ACP的编辑器中。

九、争议与挑战：ACP的“成人礼”

ACP的发展并非一片坦途。从诞生之日起，它就面临着来自社区的多种质疑和批评。

9.1 协议碎片化：又一个新协议？

开发者社区最尖锐的批评是：在ACP出现之前，已经存在AG-UI、A2A、ANP等多个与Agent通信相关的协议。ACP是在解决问题，还是在制造新的碎片化？截至2026年初，市场上已有至少7种AI Agent相关协议在竞争：Anthropic的MCP、Google的A2A、Google的AGP、Cisco的AGNTCY、IBM的ACP（Agent Communication Protocol，与Zed的ACP命名冲突）、Zed的ACP，以及Agent Network Protocol（ANP）。

JetBrains对此的态度非常明确：“我们承诺开放。我们希望您使用任何偏好的智能体。这意味着我们将支持多种协议。ACP是开放中立的，但如果另一个标准在开发者中流行起来，我们也会愉快地集成它。”

支持者的回应是：ACP解决的是一个具体且紧迫的问题——编辑器和Agent之间的集成。与通用Agent UI协议不同，ACP专注于编码和知识工作场景，深度考虑了文件操作、终端控制、代码diff展示等特有需求。它不是“又一个协议”，而是填补了协议生态中的特定空白。

9.2 与AgentHQ的竞合关系

当GitHub推出AgentHQ（面向VS Code和GitHub生态的集中式Agent管理系统）后，有人担心JetBrains会因此放弃ACP。JetBrains的回应是：“ACP和AgentHQ不冲突——它们互补。ACP是一种开放的‘语言’，任何IDE或Agent都可以使用；AgentHQ是GitHub特定的Agent管理平台。”

这种态度体现了ACP生态的开放性——协议的价值不在于排他，而在于互联。

9.3 JSON-RPC的性能争议

ACP选择JSON-RPC over stdio作为通信方式，也引发了性能方面的讨论。部分开发者认为JSON-RPC的文本序列化和反序列化会带来不必要的开销。支持者的观点是：JSON-RPC的优势在于简单、可读、跨语言兼容，这正是标准协议所需要的特性。而且ACP的通信频率远低于LSP（LSP需要在每次按键时发送请求），JSON-RPC的性能开销在实际使用中几乎不可感知。

9.4 安全性挑战：从本地到远程的暴露面

随着ACP的采用范围扩大，安全性问题也开始受到关注。2025年11月发表的一篇学术论文首次对ACP进行了实证性安全分析，指出“ACP的架构灵活性，尤其是其可选的JWS执行，导致了高影响的完整性和保密性缺陷”。

当ACP被扩展到OpenClaw这样的多Agent编排网关时，其暴露面会显著扩大。传统的ACP是本地进程通信，安全性主要依赖操作系统的进程隔离；但当ACP通过WebSocket暴露为远程服务时，攻击者可能通过协议语义指纹进行暴露面探测。

OpenClaw的应对策略是叠加多层认证（Gateway Token、设备签名Ed25519、Bootstrap Token、Tailscale身份），形成严格的零信任接入策略。这些安全挑战是协议走向成熟必须解决的问题，也是ACP社区当前重点投入的方向之一。论文建议采用混合方法，结合CORAL的集成架构与ACP的强制性每消息完整性保证，为下一代弹性Agent通信奠定基础。

9.5 最大的悬念：VS Code的态度

ACP面临的最大市场挑战，或许是VS Code的态度。VS Code占据了超过75%的开发者市场份额。JetBrains对此的态度是：“我们对微软未来的ACP计划没有内幕消息。我们基于当前可用的东西做决策，而非猜测。”VS Code的缺席是ACP生态的最大不确定性，但JetBrains等IDE厂商的支持已经为ACP提供了足够大的初始用户基础。

十、未来演进：ACP的路线图

ACP仍在积极开发中，从官方RFD列表可以看到几个重要的演进方向。

10.1 会话增强

当前ACP的会话管理相对简单。未来版本将引入更丰富的会话操作：session/fork从某个历史点分叉出新会话，用于探索不同的解决方案分支；session/resume恢复中断的会话，支持长时任务；session/list列出所有可用会话；会话持久化支持将会话状态保存到磁盘，跨编辑器会话恢复。这些增强将使ACP能够支持更复杂的多轮、多分支交互场景，让Agent真正成为一个“长期工作伙伴”而非“一次性问答工具”。

10.2 代理链（Proxy Chains）

Proxy Chains是ACP最具想象力的演进方向之一。它允许多个代理（Proxy）串联在Client和Agent之间，每个代理可以拦截、转换、增强消息流。典型应用场景包括：提示注入（在用户消息前自动添加系统指令）、日志记录（记录所有通信内容用于调试和审计）、安全审计（检查Agent的敏感操作是否符合安全策略）、性能监控（统计Agent的响应时间和工具调用频率）、多Agent协作（一个Agent的输出作为另一个Agent的输入）。

10.3 Telemetry导出

标准化Agent的性能和使用数据导出方式是ACP的重要方向。这包括：工具调用次数和耗时、文件操作的类型和频率、会话时长和token消耗、错误率和失败原因。标准化的Telemetry将为Agent开发者提供宝贵的性能洞察，也为用户提供选择Agent的客观依据。

10.4 远程Agent的完整支持

目前ACP主要面向本地Agent（作为编辑器的子进程运行）。对远程Agent的完整支持仍在积极开发中，ACP团队正在与多家Agent平台密切合作，以确保协议能够满足云托管和远程部署场景的特定需求。远程Agent支持将带来新的可能性：团队共享同一个Agent实例、使用云端GPU加速推理、Agent 7×24小时运行处理长时任务等。

10.5 标准化IDE能力

ACP正在探索通过Proxy将IDE的更多原生能力标准化并暴露给Agent。例如：诊断信息（将LSP产生的错误和警告传递给Agent）、代码导航（让Agent能够跳转到定义、查找引用）、重构操作（标准化重命名、提取函数等重构操作）、测试运行（集成测试框架的结果）。这将让Agent真正“理解”代码库的状态，做出更智能的决策。

十一、四协议横向对比：ACP在协议生态中的位置

在Agentic AI协议生态中，ACP并非孤立的协议。它与MCP、A2A、ANP共同构成了多Agent系统的通信基础设施。理解它们的关系，有助于正确选型。

维度	ACP（Agent Client Protocol）	MCP（Model Context Protocol）	A2A（Agent-to-Agent）	ANP（Agent Network Protocol）
核心定位	Agent的“工作台”	Agent的“工具箱”	Agent的“通讯录”	Agent的“社交网络”
通信双方	客户端（编辑器）↔ Agent	Agent ↔ 工具/数据源	Agent ↔ Agent	Agent ↔ Agent（去中心化）
传输层	JSON-RPC over stdio/HTTP/WebSocket	JSON-RPC over stdio/HTTP	HTTPS	P2P
发现机制	ACP Registry	工具注册表	Agent Card	W3C DID标准
典型场景	在IDE中调用AI编程助手	模型查询数据库、调用API、读写文件	企业工作流中的多Agent协作	跨组织Agent市场、去中心化协作
安全方案	权限请求+RPC沙箱+可选JWS	OAuth 2.0	企业级签名	加密签名+W3C DID
提出者	Zed Industries+JetBrains	Anthropic	Google+多家企业	BeeAI+IBM

四个协议各司其职，共同构成完整的Agentic AI协议栈。正如HTTP让万维网爆发，USB-C让设备互联标准化，LSP让编程体验飞跃，ACP有望成为AI Agent时代的通用连接标准。

十二、更宏大的愿景：ACP作为AI Agent时代的通用连接器

ACP的终极价值远超“让Obsidian能用Claude Code”。它代表一种范式转变：应用从“孤立软件”变为“Agent可嵌入、可协作的开放环境”。任何需要理解、创造、行动能力的场景——笔记、设计、表格、邮件、CRM、代码、视频编辑、甚至游戏引擎——都可以通过实现ACP，瞬间接入全球最先进的Agent能力。

JetBrains的愿景清晰地表达了这一点：“智能体应该是可移植的。你的智能体应该能轻松地在JetBrains IDE、VS Code及其他工具之间移动。你不应该被锁定在单一供应商中。竞争应该围绕创造卓越的用户体验，而不是专有壁垒。”

这将催生：

Agent Marketplace：开发者专注打造垂直Agent（法律Agent、医疗Agent、设计Agent），通过ACP在任意支持的应用中即插即用。
Multi-Agent OS：操作系统层面或跨应用层面，由多个专业Agent协作完成复杂工作流。
个人知识-行动统一体：你的Obsidian、Figma、VS Code、Notion、Slack通过同一套Agent生态互联，形成个人“第二大脑+第二双手”。
企业Agent Fabric：内部所有系统被一张Agent网络覆盖，业务流程实现真正的智能化编排。

正如ACP Registry的口号所说：“Implement once, work everywhere.”这不仅是效率的提升，更是开发体验的一次范式升级。

结论：行动的时刻已经到来

ACP的愿景不止于代码编辑器。它生于代码，却注定要超越代码。

从Obsidian插件的早期成功，到Figma向Agent开放画布，再到企业级编排网关的实践，我们已经看到ACP从一个“编辑器-Agent通信协议”逐渐演化为跨应用的通用连接标准。JetBrains与Zed联合推出的ACP Registry为Agent分发提供了基础设施，多语言SDK降低了实现门槛，而社区驱动的Obsidian插件等项目证明了协议的可扩展性。

当然，ACP仍面临协议碎片化、安全性、市场接受度等挑战。VS Code的态度仍是最大的不确定性，远程Agent支持也在积极开发中。但一个开放、中立的协议，其价值不在于立即被所有人接受，而在于为生态中的各方提供一个可以自由选择和协作的基础。

未来不属于某个单一的AI模型，也不属于某个垄断的应用平台，而是属于那些愿意开放、愿意标准化、愿意与整个Agent生态协作的产品。

ACP提供了桥梁。剩下的，是我们共同去搭建这座通往智能时代的宏大生态。

参考资料

Agent Client Protocol官网：https://agentclientprotocol.com/
ACP GitHub仓库：https://github.com/agentclientprotocol/agent-client-protocol
ACP Registry is Live - Zed Blog（2026年1月28日）：https://zed.dev/blog/acp-registry
JetBrains ACP智能体注册表已上线（2026年3月）：https://blog.jetbrains.com/zh-hans/ai/2026/03/acp-agent-registry/
Agents, Protocols, and Why We‘re Not Playing Favorites - JetBrains AI Blog：https://blog.jetbrains.com/ai/2025/12/agents-protocols-and-why-we-re-not-playing-favorites/
从ACP协议看OpenClaw的暴露面探测 - 安全内参（2026年3月）：https://www.secrss.com/articles/88898
Security Analysis of Agentic AI Communication Protocols - arXiv:2511.03841
Top AI Agent Protocols in 2026 - MCP, A2A, ACP & More - getstream.io：https://getstream.io/blog/ai-agent-protocols/
Obsidian Agent Client插件介绍（2026年1月）：https://www.vibesparking.com/en/blog/ai/agent-client/2026-01-04-agent-client-obsidian-ai-agents/
Agents, Meet the Figma Canvas - Figma Blog（2026年3月）：https://www.figma.com/blog/the-figma-canvas-is-now-open-to-agents/
How Uber Built an Agentic System to Automate Design Specs - Uber Blog（2026年3月）
n8n-acp-agent - npm：https://www.npmjs.com/package/n8n-acp-agent
ACP Java SDK - Spring AI Community：https://springaicommunity.mintlify.app/acp-java-sdk
Zed IDE官宣ACP：一次注册，AI处处可用 - 腾讯云开发者社区：https://cloud.tencent.com/developer/article/2631977