一句话总结：ACP 是 AI 编程代理与编辑器之间的通信协议，类似”AI 的 LSP”。它目前处于早期阶段，对大多数开发者而言关注但不急于投入是最佳策略。
一、ACP 是什么
1.1 基本定义
| 项目 | 内容 |
|---|---|
| 全称 | Agent Client Protocol（代理客户端协议） |
| 发起方 | Zed 编辑器（2025 年 4 月开源） |
| 联合维护 | JetBrains（2025 年 6 月宣布支持） |
| 许可证 | Apache 2.0（开源） |
| 核心目标 | 解决 AI 编程代理与代码编辑器之间的通信问题 |
1.2 类比理解：“AI 的 LSP”
| 协议 | 解决的问题 | 效果 |
|---|---|---|
| LSP（语言服务器协议） | 编程语言 ↔ 编辑器 | 任何语言在任何编辑器里获得语法提示 |
| ACP（代理客户端协议） | AI 代理 ↔ 编辑器 | 任何 AI 代理在任何编辑器里运行，无需单独开发插件 |
1.3 技术基础
- 通信方式：JSON-RPC 2.0，通过 stdio 流传输
- 代理能力：读取代码、修改文件、调用终端命令
- 编辑器职责：UI 展示 + 权限管控
- 核心设计：一次注册，全平台可用
1.4 ACP 注册后的效果
在 ACP Registry 注册一次后，以下编辑器自动发现并使用：
- Zed（协议发起方）
- JetBrains 全家桶（IntelliJ、GoLand、RustRover、PyCharm 等）
- Neovim
- Emacs
上下文无缝衔接：项目上下文和文件状态通过协议自动传递，无需手动复制粘贴。
二、ACP 的核心价值
核心定位：ACP 解决的不是”备份”问题，而是**“人机协作密度”**问题。
2.1 三大适用场景
| 场景 | 问题描述 | ACP 的解决方案 |
|---|---|---|
| 高频 AI 交互（每天 50+ 次调用） | 终端 ↔ 编辑器反复切换，上下文切换成本高 | AI 在编辑器内流式输出 diff，减少切换 |
| 团队协作与权限管控 | CLI 权限是”全有或全无”，安全风险大 | 内置权限沙盒，限制文件/命令/网络访问 |
| 多代理编排（Agent Swarm） | 多个 AI 代理可能互相覆盖文件 | 统一中枢调度层，避免冲突 |
2.2 ACP 到底解决什么问题
| 维度 | 没有 ACP | 有 ACP |
|---|---|---|
| 文件修改方式 | 黑盒操作：直接覆盖磁盘，编辑器里文件突然变了 | 可视化协作：侧边栏 diff，逐行审查后应用 |
| 交互体验 | 无法查看变更细节，无法审查 | 接受/拒绝/修改工作流 |
| 安全性 | 无权限隔离 | 权限沙盒机制 |
2.3 CLI 工具的”上帝模式”风险
CLI 工具（如 codebuddy、kimi）在用户权限下运行，天然拥有完整系统访问权：
- 能读取
~/.ssh/id_rsa等敏感文件 - 能执行
curl 恶意地址 | sh等危险命令 - 能修改
.git/config推送代码到陌生仓库 - 能删除整个
~/Documents
ACP 的关键价值之一：建立安全边界，让编辑器决定 AI 能做什么。
三、ACP vs CLI 工具：三种操作方式对比
3.1 方式总览
| 方式 | 原理 | 是否需要 ACP | 适用场景 |
|---|---|---|---|
| CLI 直接操作 | 进程调用系统 API（fs 模块） | 不需要 | 终端里用 codebuddy "refactor auth" |
| 编辑器插件操作 | 编辑器 Extension API 修改 Buffer | 不需要（原生 API） | VS Code Copilot 插件 |
| ACP 桥接 | CLI 代理 ↔ ACP 协议 ↔ 编辑器 UI | 需要 | Zed / Kimi CLI 深度集成 |
CodeBuddy 的定位：属于第一类，就是普通命令行程序，像
rm、sed一样直接操作文件系统。
3.2 核心原则
ACP 不是给 CLI”赋能”文件操作，而是给编辑器”规范”如何调用 CLI。
四、现状判断：ACP 处于什么阶段
4.1 发展时间线
| 时间 | 事件 |
|---|---|
| 2025 年 4 月 | Zed 开源 ACP，主要是 Zed 用户在用 |
| 2025 年 6 月 | JetBrains 宣布支持，覆盖 IDEA 系列 IDE |
| 当前 | 绝大多数开发者（>90%）仍使用 VS Code + Copilot/Cursor 或纯 CLI 工具 |
4.2 其他相关协议
| 协议 | 发起方 | 现状 |
|---|---|---|
| MCP（Model Context Protocol） | Anthropic | 主要用在 Claude Desktop 等特定生态，通用工程采纳率有限 |
| A2A（Agent2Agent Protocol） | 生产级落地案例极少，多在演示场景和特定云平台内使用 |
4.3 ACP 的市场定位
- ACP 目前更像**“基础设施协议”**，普通用户感知不强
- 类比：大多数程序员不知道 LSP 是什么，但每天都在用
- ACP 可能走类似路线——未来你可能在不知情的情况下通过编辑器插件间接使用它
五、为什么 Git + CLI 已经足够
5.1 各场景覆盖情况
| 场景 | Git + CLI 方案 | 协议方案评估 |
|---|---|---|
| 代码生成/重构 | aider, cursor, cline 直接操作 Git 工作区 | 过度设计 |
| Prompt 版本管理 | Git 管理 prompt 模板文件 | 引入额外复杂度 |
| 多模型切换 | CLI 配置多个 API endpoint | 抽象收益不高 |
| 自动化流水线 | Shell 脚本 + GitHub Actions | 更成熟稳定 |
| 团队协作 | Git branch / review 工作流 | 已有成熟实践 |
5.2 工程现实
绝大多数开发团队并没有使用这些协议，而是直接通过 HTTP API / SDK / CLI 工具 与 AI 服务交互，配合 Git 进行版本管理。
六、什么时候应该考虑 ACP
6.1 引入 ACP 的信号
| 如果你遇到… | 考虑方案 |
|---|---|
| 每天切终端和编辑器超过 30 次，感到烦躁 | Zed + Kimi ACP 减少切换 |
| 开始团队协作，需要限制 AI 的访问范围 | ACP 的权限沙盒 |
| AI 经常改错文件，需要精细的 diff 审查 | 编辑器内可视化 diff |
| 同时使用 2 个以上 AI 代理 | ACP 避免代理冲突 |
6.2 协议化方案真正有价值的场景
以下特定边界才显现价值：
- 多 Agent 编排系统：3+ 不同厂商的 Agent 互相调用，降低接入成本
- 企业级工具集成：大量内部系统（Jira、Confluence、私有数据库）需统一暴露给多个 LLM 客户端
- 跨组织协作：不同公司/团队的 Agent 需要标准接口互调
七、结论与建议
7.1 核心结论
对于绝大多数个人开发者和小团队，Git + AI CLI 工具完全够用，且更轻量、更可控、调试更直接。
7.2 未来展望
- 协议层目前像基础设施层的早期标准化尝试（类似 REST API 标准化之前的 SOAP）
- 可能在 2-3 年后成为事实标准
- 当 VS Code / Cursor 原生支持、主流 CI 工具集成时，迁移成本很低
7.3 实践建议
- 保持现有的 Git + CLI 工作流
- 关注但不急于投入
- 观察工具发现机制的演进
- 等待生态成熟后再考虑迁移