1. 为什么大家都在谈 Agent Client Protocol
做智能体开发的同学应该都能感觉到,最近半年圈子里的讨论重心悄悄从“模型能力”转移到了“工程基建”上。模型本身越来越同质化,真正的差异反而落在外围:怎么接数据、怎么接工具、怎么接客户端。Agent Client Protocol(简称 ACP)就是在这个节骨眼上被反复提到的关键词。
先说人话版本:ACP 是一个标准化的协议,定义了一套 HTTP 接口,用来统一智能体和客户端之间的通信方式。也就是说,不管你的智能体跑在云端还是本地,不管前端是聊天窗口、IDE 插件还是桌面应用,双方只要按照 ACP 的规范说话,就能互相理解、顺畅协作。
可能有人会觉得,这不就是又一个 API 规范吗?先别急着下结论。ACP 和传统 API 最大的区别在于它服务的对象是“会话型应用”。传统 API 是请求-响应模型,你调一下、我回一下,简单直接。但智能体场景下,交互是长连接式的、多轮次的、动态变化的——模型要推理、要调工具、要等外部结果,很多时候一个请求发出去,几秒甚至几十秒后才会有完整结果。这种异步、流式、可中断的复杂交互,靠普通 REST API 根本撑不住。
我个人在本地部署智能体的时候,最头疼的就是客户端和智能体之间的对接逻辑。不同客户端有不同实现,同一套智能体要在多个界面上跑,就得写好几套适配层,维护成本高到离谱。ACP 要解决的正是这个痛点:通过统一协议,把智能体的后端实现与前端界面彻底解耦。这对那些正在做智能体产品的团队、独立开发者、甚至只是想在自己项目里内部集成智能体的人来说,都是值得花时间研究的东西。
这篇文章我会从协议的核心机制、具体实现、与 MCP 的关系、以及实际落地中的坑这几个维度展开,尽量把技术细节讲透,也会补充一些我自己实测的经验和踩坑记录。读者如果是做智能体开发、LLM 应用集成、或者客户端工具链的,应该都会有收获。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. ACP 的核心思路与设计目标
2.1 ACP 到底解决的是什么问题
在 ACP 出现之前,智能体与客户端对接基本是“三不管”状态:模型层有 OpenAI API、Anthropic API,工具层有 MCP 标准,但中间这一层——客户端怎么跟智能体对话、怎么把智能体的状态呈现给用户、怎么处理多轮推理过程——没有一个公认的规范。
这就导致一个很尴尬的现实:每个智能体项目都要自己定义一套通信协议,自己设计消息格式、状态管理、错误处理。今天接了一个 Web 聊天界面,明天想换个桌面客户端,就得重写一堆适配代码。更麻烦的是,如果智能体有多个实例在跑(比如不同模型、不同配置、不同工具集),客户端得针对每一个实例单独适配。
ACP 的思路是居中做一个标准化层。它本质上定义的是“智能体边界”的接口:只要智能体实现了 ACP,任何支持 ACP 的客户端都可以直接接入。这个思路参考了本世纪初 HTTP 标准化对 Web 生态的推动作用——当年大家各自搞私有协议的时候,网页和浏览器之间的壁垒有多高,今天的智能体和客户端之间的壁垒就有多高。
2.2 设计上的三个关键动作
ACP 的设计文档里,核心设计目标可以拆成三个点:
第一是标准化会话管理。会话概念是整个 ACP 的核心抽象之一。智能体与用户的每次交互都归属于一个会话,会话带有明确的状态、生命周期和持久化语义。客户端通过 ACP 接口创建、恢复、更新会话,智能体则负责维护会话内部的运行状态。这个设计让智能体支持多轮对话、断线恢复、多实例切换变得非常自然。
第二是统一的更新推送机制。这一点我认为是 ACP 最聪明的地方。传统 HTTP 接口无法主动向客户端推送消息,但智能体的执行过程天然是异步的——模型推理要时间、工具调用要时间、思考过程也是一步步展开的。ACP 通过在客户端实现回调接口,让智能体能主动推送会话中的更新内容。客户端只需要暴露一个 endpoint,智能体就把所有的进度、中间结果、状态变化都推过去。这个机制把“轮询”的痛苦彻底消除了。
第三是能力协商机制。不同智能体的能力差异非常大,有些支持多模态,有些不支持;有些可以流式输出,有些只能整段生成;有些支持中断操作,有些一旦跑起来就停不下来。ACP 设计了能力协商层,客户端和智能体在建立连接时互相声明自己支持的能力,然后按照公共子集进行通信。这在实现上避免了大量的兼容性开小差代码。
2.3 与 MCP 的分工逻辑
说起 ACP 经常有人拿它跟 MCP 对比。其实两者根本不是竞争关系,而是分别站在智能体框架的不同层级。我在本地同时用了两套协议,感受非常明显:MCP 管的是“智能体如何调用工具”,不管客户端的事情;ACP 管的是“客户端如何与智能体对话”,不管内部工具怎么编排。
打个比方:MCP 是智能体手臂上的标准接口,让
