作者: Phodal Huang 2026年2月9日 15:20

最近，我们在 AutoDev 中集成了 ACP 协议，使用它进一步优化 AutoDev 的跨平台渲染架构，在提升 AutoDev 的同时，也兼容了其它智能体。由于，ACP 协议带来了更有趣的思考，所以，我决定写一篇文章来分享一下我们的思考与实践。

在企业研发环境中，AI 智能体已经不再只是“可选工具”，而正在成为开发团队日常生产力的核心组成部分。Cursor、Copilot、Augment、Claude Code 等多种助手往往同时出现在同一企业中。对于企业 IT 或平台团队而言，这带来了一个新的挑战：

如何在保证研发效率、团队协作和平台治理的前提下，让多个 AI 智能体在不同编辑器中顺畅共存？

一、ACP 协议概览与集成实践

对于 ACP（Agent Client Protocol）的关注，起源于我们想为客户在内网环境提供一个统一的 AI Coding 智能体服务。与互联网流行的 Vibe Coding 的 各种 demo 不同的是：在企业场景中，人总是要为自己的代码负责的，AI 只是辅助的工具 —— AI 不能帮你背绩效。所以，写完代码之后，都需要一个工具 来 review AI 的代码。

而现在流行的各类 Coding CLI 工具都缺少一个与现有编辑器更好的集成方式。我们尝试了 Claude Code 的 IDEA 插件，发现不太行，然后注意到了 JetBrains 的 ACP 协议，发现它与我们的愿景不谋而合。如下其 AI Assistant 的示例：

images

你可以在 IDEA 中集成各类 Coding Cli 工具，而这些工具可以与 IDEA 的生态进行深度融合，他可以是支持 ACP 协议的 OpenCode、Auggie 等，也可以是不支持 ACP 协议的 Claude Code 等 —— IDEA 会帮它们支持的。在这种背景之下，IDE 只是作为一个 render 工具，来让你更好地与 AI 进行交互，而不是成为一个 AI 编程工具。

而不仅仅是 JetBrains，我们可以发现 ACP 已经在各种 AI 编程工具中流行起来。

ACP 协议是什么？

ACP（Agent Client Protocol，智能体客户端协议）是一个标准化的通信协议，定义了 IDE/编辑器与 AI 编码助手之间的交互规范。如果你熟悉 LSP（Language Server Protocol），可以将 ACP 理解为 "AI Agent 的 LSP"。

ACP 的设计围绕一个核心原则：让 IDE 完全掌控 AI Agent 的每一步操作。在传统的 AI 编码助手中，Agent 往往是一个"黑盒" ——你发送一个请求，等待一段时间后得到结果，但中间发生了什么、Agent 读取了哪些文件、修改了什么代码，这些过程对 IDE 和用户来说都是不可见的。这在企业环境中带来了严重的问题：

  • 安全风险：无法审计 Agent 访问了哪些敏感文件
  • 信任问题：用户不知道 Agent 在"思考"什么，难以建立信任
  • 协作困难：IDE 无法在 UI 中实时展示 Agent 的工作进度
  • 调试困难：出错时无法追溯 Agent 的操作历史

ACP 通过将 工具调用（Tool Call）作为一等公民，彻底解决了这个问题。在 ACP 中，Agent 的每一个操作——读取文件、编辑代码、执行命令——都必须通过明确的工具调用来完成，并且这些调用对 IDE 完全可见、可控、可审核。

工作原理

ACP 采用 主从通信模型：IDE 作为 Client，Agent 作为 Server 子进程。通信通过 JSON-RPC 2.0 协议在 stdio （标准输入输出）上进行。

一个典型的交互流程如下：

1. 初始化与能力协商。IDE 启动 Agent 子进程后，双方首先进行能力协商——类似 LSP 的初始化握手，这种双向协商确保了 IDE 和 Agent 都清楚对方的能力边界，避免了不兼容问题。 2. 会话与任务执行。用户在 IDE 中发起请求后，Agent 开始工作。关键在于，Agent 的每一步操作都会实时推送给 IDE，IDE 可以在 UI 中实时展示这些信息：执行计划、当前正在读取的文件、即将修改的代码。用户对 Agent 的行为一目了然。 3. 权限控制与审核。当 Agent 需要执行敏感操作（如修改文件、执行命令）时，必须向 IDE 请求权限。IDE 可以：自动批准（基于用户预设的策略）、 弹窗询问用户、展示 Diff 让用户审核后再应用

这种机制让企业可以实施细粒度的安全策略，例如："允许 Agent 读取任何文件，但修改代码必须经过人工审核"。

核心特性

  • Session 持久化ACP 支持会话的保存和恢复。开发者可以在多个任务间切换，就像在浏览器中切换标签页一样。早上开始一个重构任务，下午切换去修 bug，第二天再回来继续重构——所有上下文都被保留。
  • 多模式支持Agent 可以运行在不同模式下：ask（问答模式）、code（编码模式）、architect（架构设计模式）。不同模式下，Agent 的行为和可用工具可能不同。
  • MCP 集成ACP 原生支持 MCP（Model Context Protocol）服务器。Agent 可以通过 MCP 访问数据库、API、文件系统等外部资源，极大扩展了能力边界。IDE 提供的 MCP 服务器（如代码索引、语法分析）也可以被 Agent 调用。
  • 实时反馈通过 session/update 通知，Agent 可以推送：执行计划（plan）、 工具调用进度（tool_call） 、内部思考过程（agent_thought_chunk） 、消息流（agent_message_chunk）

这让 IDE 能够构建丰富的 UI，展示 Agent 的"思考"和"行动"，而不是简单的加载动画。

AutoDev 的 ACP 集成实践

ACP （ https://agentclientprotocol.com/ ） 作为一个标准的协议，主流的语言都已经有 SDK 可以使用了。我们也在 AutoDev 集成了 ACP 能力。

AutoDev ACP 文档见：https://ide.unitmesh.cc/acp

在构建新 AutoDev 3.0（Xiuper）的时候，我们思考的是基于统一的渲染架构来支持多端渲染，这与 ACP 协议的初衷不谋而合。在实现 ACP 的时候，我们做的事情如下：

  1. 双向 ACP 实现。使用官方 ACP Kotlin SDK 和 TypeScript SDK， 实现了 AutoDev 的 ACP 服务端和客户端，以便于 AutoDev 可以作为 ACP 服务端，也可以作为 ACP 客户端。
  2. ACP 渲染架构。实现 AcpRenderer 桥接 ACP 协议和渲染系统，并针对流式传输优化。
  3. 非 ACP Agent 适配，诸如 Claude Code 适配，实现 ClaudeCodeClient 解析其 stream-json 协议、映射 stream_event 到标准 CodingAgentRenderer 接口等。

所有渲染器都实现 CodingAgentRenderer 接口，ACP 事件通过这个统一接口分发到各平台，实现了“一次编写，多端渲染”的目标。

二、ACP 生态与企业级统一管理

在没有统一标准的情况下，每个编辑器都必须单独为每个 AI 助手实现集成接口，而每个助手也需要针对不同编辑器开发特定插件或 API。这在企业中带来了明显问题：

  • 集成成本高：每增加一个编辑器-助手组合，都意味着重复开发和维护工作
  • 兼容性受限：助手通常只能支持少数编辑器，限制了开发者的选择
  • 平台治理难度大：企业无法统一管理助手的权限、日志和使用策略

这些问题不仅增加了 IT 维护成本，也限制了研发团队的灵活性和创新能力。于是，Zed 与 JetBrains 等编辑器厂商开始思考：如何将 AI 编程助手从特定的编辑器中解脱出来，类似于微软发起的 LSP（Language Server Protocol）。

JetBrains ACP 实践

作为 AI 时代落后的 JetBrains，它在 2025 年对我的最大用途就是调试和查看（跳转）代码。因此 ACP 也可以视为 JetBrains 的新尝试。 作为 ACP 协议的主要推动者之一，JetBrains 不仅定义了标准，更通过一系列实际举措将其转化为可用的企业级生态。JetBrains 的 ACP 实现包含以下核心特性：

ACP Agent Registry：官方策划的 Agent 中心

JetBrains 提供了官方的 ACP Agent Registry，这是一个集中管理和分发 Agent 的平台。通过 Registry，用户可以：

  • 一键安装：从 IDE 内直接搜索、安装和更新 Agent，无需手动配置
  • 自动运行时管理：Registry 自动下载和管理 Node.js、Python 等必要的运行时环境，开发者无需手动配置
  • 版本管理：支持 Agent 的版本控制和自动更新，确保用户始终使用最新的稳定版本

双向配置模式

JetBrains ACP 支持两种灵活的配置方式，满足不同场景的需求：

  1. Registry 安装（推荐）。通过 JetBrains 官方 Registry 一键安装，适合大多数用户和企业。
  2. 自定义配置（acp.json）。对于需要自定义部署或集成内部 Agent 的企业，可以通过 acp.json 配置文件进行精细控制：

这种配置方式允许企业：

  • 集成内部 Agent：将企业自研的 Agent 集成到 IDE 中
  • 自定义运行环境：指定特定的运行时路径和参数
  • 灵活部署：支持本地和远程 Agent 的混合部署

MCP 集成：能力扩展的桥梁

JetBrains ACP 原生支持 MCP（Model Context Protocol）服务器的集成，这使得 Agent 可以：

  • 访问 IDE 能力：通过 use_idea_mcp 配置，Agent 可以调用 IDE 提供的工具和资源
  • 使用自定义 MCP：通过 use_custom_mcp 配置，Agent 可以集成企业自定义的 MCP 服务器
  • 扩展功能：Agent 可以通过 MCP 访问数据库、API、文件系统等外部资源，实现更复杂的功能

这种设计使得 ACP 和 MCP 形成了完美的互补关系：ACP 负责 Agent 与 IDE 的交互，MCP 负责 Agent 与外部系统的能力扩展。

三、多 Agent 协作的前沿实践

结合我最近受邀使用的 Augment Intent 工作空间，我们可以发现在有了 ACP 之后，你可以很容易创建一个 GUI 工具来管理多个 AI Agent，如同时使用 Claude Code、AutoDev、Cursor 等多个 AI Agent。

而在企业研发环境中，AI 编码助手不再是孤立工具。开发者、平台和多个 AI 软件需要协同工作，这带来了跨工具的管理、编排与协作需求。

Augment Intent：多 Agent 统一工作空间

Intent 解决的核心问题是：当你同时用好几个不同编程工具的 AI Agent 干活时，怎么管理它们？

它的做法是搞了一个统一的工作空间，让多个 Agent 在里面协同工作。架构上有点像一个小型开发团队：

  • Coordinator 是项目经理，负责拆任务、分活儿、协调进度
  • Specialist Agents 是各司其职的专家——Implement 负责写代码，Verify 负责验证，Code Review 专门审代码，Debug 处理问题
  • 每个 Agent 在自己的 Worktree 里干活，互不干扰，但进度实时同步

几个让我觉得有意思的设计：

  1. 并行执行：多个 Agent 可以同时跑，不用排队等。比如一个在写代码，另一个在跑测试，第三个在做 Code Review
  2. Best-of-N：同一个任务让多个模型或 Agent 同时尝试，最后挑最好的结果用
  3. 会话持久化：关掉 Intent 明天再开，所有 Agent 的状态都还在，不用重新解释上下文
  4. 多模型混用：复杂架构用 Opus，快速迭代用 Sonnet，不同任务配不同模型

本质上，Intent 把"多 Agent 管理"这件事产品化了——你不用自己写调度逻辑，也不用操心 Agent 之间怎么通信，它帮你搞定了。

Google Antigravity：Agent 优先的开发平台

Google 在 2025 年 11 月推出的 Antigravity，思路和 Cursor Agents 有点像，但走得更远：它不只是一个编辑器，而是一个"Agent 优先" 的开发平台。Antigravity 的核心设计是把工作界面分成两块：

  • Editor View：传统的 AI 辅助编辑器，有代码补全、内联命令，适合你需要亲自动手的时候
  • Manager Surface：这是重点——一个专门用来管理 Agent 的界面，你可以在这里启动、编排、观察多个 Agent 在不同工作区异步干活

Google 的想法是：Agent 不应该只是侧边栏里的聊天机器人，它们应该有自己的工作空间。你可以把一个完整的任务丢给 Agent，比如"复现这个 bug、写个测试用例、然后修掉它"，然后去忙别的事情，Agent 会在后台跑着。

一个很实用的设计是 Artifacts（产出物）。Agent 干完活不是给你一堆日志让你慢慢翻，而是生成截图、浏览器录屏、任务清单这些可视化的东西。 你扫一眼就知道它干得对不对，有问题直接在Artifact 上留评论，Agent 会根据反馈继续改。

Antigravity 还支持多模型：Gemini 3 Pro、Claude Sonnet 4.5、GPT-OSS 都能用，跨平台（macOS、Windows、Linux）。

四、企业级 AI 平台治理体系

在多 AI 助手共存的企业环境中，单靠一个 IDE 插件或单一助手已经无法满足企业研发效率和治理要求。结合我们在 AutoDev 的 ACP 集成实践，以及 MCP/Skill 与 A2A 协议，企业可以构建一个完整的 AI 平台协作与治理体系：

层级 主要对象 核心关注点 企业价值
MCP / Skill 企业复用能力、业务 Skill 可组合、可调用的企业级能力模块 将业务知识与 AI 能力模块化，实现团队复用、版本控制和权限管理
ACP IDE 与 AI 助手 实时交互、文件操作、会话管理 将 AI 智能体变为可治理、可观察的工程对象，统一管理本地与远程助手，提升研发效率与工具灵活性
A2A Agent 之间 分布式协作、异步任务 构建企业级智能网络，实现跨团队、跨组织的 Agent 调度与能力互用，支持长周期任务与 Agent Marketplace

MCP / Skill：模块化企业能力

在 AutoDev 实践中，我们通过 MCP 让 Agent 能够访问企业内部能力，例如数据库、API、代码索引和自研业务 Skill。企业可以将业务知识和 AI 能力模块化，形成可复用、可管理的能力库，不仅降低重复开发成本，也保证了权限和版本控制。

核心价值：

  • 企业级能力复用，避免每个项目重复集成 AI 助手能力
  • 精细化权限管理，确保 AI 访问企业资源可控
  • 支持版本迭代，保证团队使用一致且稳定的能力模块

ACP：可控的人机交互层

通过 ACP 协议，企业可以让 IDE 与多 AI 助手之间实现透明、可观察、可控的交互。AutoDev 的实践表明：

  • 双向 ACP：AutoDev 即可作为 ACP 客户端，也可作为服务端
  • 统一渲染层：不同助手的事件通过统一接口分发，实现“一次编写，多端渲染”
  • 非 ACP 助手适配：如 Claude Code，通过协议适配层接入 ACP 架构

企业价值：

  • 多助手协作无缝，提升研发效率
  • 操作和修改可追踪，满足安全和合规要求
  • 会话持久化，支持长任务和上下文延续

A2A：智能体协作网络

在企业场景中，单个 AI 助手无法覆盖所有任务。通过 A2A（Agent-to-Agent Protocol），企业可以构建跨团队、跨项目的智能任务网络 ，实现：

  • 并行执行：多个 Agent 可同时处理不同任务
  • 任务拆分与协作：如 Augment Intent，Coordinator Agent 拆分任务，Specialist Agent 各司其职
  • 产出物管理：Agent 干完活生成可视化产出（Diff、截图、录屏），便于审查与迭代

企业价值：

  • 支撑长周期任务和跨团队协作
  • 不同模型或 Agent 可组合使用，实现最佳方案选择（Best-of-N）
  • 构建企业级 Agent Marketplace，实现能力共享

三层协议的协同价值

通过 MCP / Skill、ACP 和 A2A 三层结合，企业 AI 平台不再是“工具堆叠”，而是可管理、可复用、可扩展的研发生产力基础设施：

  1. 研发效率提升：ACP 保证开发者桌面与 IDE 内多助手协作顺畅
  2. 企业级能力复用：MCP / Skill 模块化企业知识和能力，实现团队复用和权限控制
  3. 跨团队智能协作：A2A 支持长周期、跨项目任务的智能 Agent 网络
  4. 统一治理与监控：三层协议结合，实现权限、日志、审计和安全策略统一管理

总结：

  • MCP 是企业知识和能力的载体
  • ACP 是开发者与助手的交互层
  • A2A 是企业智能体之间的协作网络

这种三层体系，让企业 AI 平台真正成为可扩展、可观测、可治理的生产力平台，而不仅仅是工具的简单叠加。

总结

ACP 协议正在成为多智能体时代的关键基础设施。它解决了一个核心问题：如何让多个 AI 助手在同一开发环境中协同工作，同时保持可控、可观测、可治理 。

核心要点：

  1. ACP 定义了标准化的人机交互协议，让 IDE 能够统一管理来自不同 AI 助手的操作请求，实现"一次集成，多端协作"
  2. 双向 ACP 架构（如 AutoDev 实践）既支持作为客户端调用外部 Agent，也支持作为服务端被其他工具调用
  3. 与 MCP、A2A 形成三层协议体系：MCP 提供能力模块化，ACP 管理人机交互，A2A 实现智能体间协作
  4. 企业级治理成为可能：统一的协议层让权限控制、操作审计、安全策略得以落地

随着 JetBrains、Augment、Google 等厂商的积极布局，ACP 生态正在快速成熟。对于企业而言，现在是构建多智能体研发平台的最佳时机。

或许您还需要下面的文章:

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)