Edit: ACP：从代码编辑器到全应用时代的AI Agent通用连接器—

编辑文章

标题 *

URL 别名 *

内容 * (支持 Markdown 格式)

# 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的架构包含三个核心组件：

1. **Client（客户端）** ：通常是代码编辑器或IDE，负责提供用户界面、管理环境、控制资源访问。Client向Agent发送用户提示，并处理Agent发出的文件操作、终端命令、权限请求等。

2. **Agent（智能体）** ：使用生成式AI自主修改代码的程序，通常作为Client的子进程运行。Agent接收用户指令，自主规划并执行代码修改任务，期间可以向Client请求所需的资源和操作。

3. **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 实现路径

1. **选择传输层**：本地优先用stdio JSON-RPC，远程用WebSocket/HTTP。

2. **实现Client侧**：暴露应用当前上下文（文件、笔记图谱、画布JSON、选中元素等）；处理Agent返回的事件（streaming text、proposed edits、tool requests、diffs）；提供UI层渲染（侧边栏聊天、画布overlay、接受/拒绝按钮）。

3. **安全沙箱**：所有修改需用户确认或使用细粒度权限。ACP采用了基于角色的访问控制（RBAC）和操作特定的JWT来增强安全性。

4. **兼容MCP**：让Agent能进一步调用应用暴露的工具。

### 8.2 快速上手示例：Java SDK

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

```java
// 启动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中的集成为例：

```json
// ~/.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提供了桥梁。剩下的，是我们共同去搭建这座通往智能时代的宏大生态。

**参考资料**

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

配图 (可多选)

选择新图片文件或拖拽到此处

标签