IFABLE

本文为「AI Agent 技术系列」第 10 篇。MCP（第 3 篇）解决”Agent 如何接入工具与数据”，A2A（第 8 篇）解决”独立 Agent 之间如何协作”，ACP（第 9 篇）解决”编辑器与编码 Agent 之间如何通信”。AAMP 补上第四个方向：当 Agent 无法暴露公网端点时，平台如何把任务异步派发给它，并把结果回写回来。

本文为「AI Agent 技术系列」第 9 篇。MCP（第 3 篇）解决“Agent 如何接入工具与数据”，A2A（第 8 篇）解决“独立 Agent 之间如何协作”，ACP 补上第三个方向：人每天使用的编辑器与编码 Agent 之间如何通信。三条通道互不替代，可以同时存在。

在编辑器里用 AI 编码助手已是日常，但“接进来”这件事并不便宜。每个编辑器要为每个想支持的 Agent 写定制集成；反过来，Agent 想触达用户，就得逐个实现编辑器的私有 API。落到使用者身上，就是你选定一个 Agent，往往等于接受了它所支持的界面 [1]。

Zed 团队在 2025 年发起的 Agent Client Protocol（ACP）正是冲着这个问题来的 [1][2]：像 LSP 统一语言服务器的接入那样，把 Agent 的接入也统一掉 [1]。本文以当前稳定的 v1 为基准，讲清它的架构、通信模型与一次会话的完整流程，再单列一节梳理 v2 的重构。除特别说明，方法名与字段以官方文档为准，JSON 示例中的 ID 仅为说明结构。

本文为「AI Agent 技术系列」第 8 篇。MCP（第 3 篇）侧重“Agent 如何接入工具与数据”，A2A 侧重“独立 Agent 如何发现彼此、委托任务并交换结果”。两者可以配合使用，但不存在必须依次接入的依赖关系。

让两个 Agent 互相发消息并不难。难的是：对方能做什么、任务是否仍在执行、缺少信息时怎样追问、断线后怎样继续跟进。如果每次对接都重新约定这些细节，多 Agent 协作很快就会变成集成工程。A2A 要标准化的正是这套交互约定。

本文为「AI Agent 技术系列」第 7 篇。在 LangChain 工程化（第 4 篇）提到的多智能体协作基础上，深入”多个 Agent 之间如何共享状态”这一架构设计层面。

本文为「AI Agent 技术系列」第 6 篇，独立性较强。与前 5 篇聚焦”应用 Agent”不同，本文聚焦”编码代理”的上下文工程。

本文为「AI Agent 技术系列」第 5 篇。在 LangChain 工程化（第 4 篇）基础上，深入安全防护这一个切面。

本文为「AI Agent 技术系列」第 4 篇。在 ReAct 理论（第 1 篇）和 Function Calling 机制（第 2 篇）基础上，进入工程框架层面。

本文为「AI Agent 技术系列」第 3 篇。Function Calling（第 2 篇）解决了”模型如何决定调用工具”，MCP 解决”工具如何被标准化接入”。

2026-07-29 重要更新：MCP 官方于 2026-07-28 发布了新版规范 [1][2]。这次改动很大——协议核心从”双向有状态”转为”请求/响应无状态”，核心维护者称其为远程 MCP 上线以来最重要的一次发布。本文已按新协议全面重写，并保留新旧协议对比，方便已有实现的读者评估迁移。

本文为「AI Agent 技术系列」第 2 篇。Function Calling 是 Agent 调用工具的基础机制，理解本文是阅读 MCP 协议（第 3 篇）和 LangChain 工程化（第 4 篇）的前提。

本文为「AI Agent 技术系列」第 1 篇，后续文章将分别深入 Function Calling、MCP 协议、LangChain 工程化、护栏与安全、上下文工程、多 Agent 协作等主题。