MCP/ACP/AA/ANP，四大Agent协作协议一文讲透

这段时间Agent开发圈子里最热闹的话题已经从“怎么做Prompt”变成了“怎么定协议”。MCP这个缩写刚火起来没多久突然又冒出来ACP、AA、ANP一堆新名词。很多做Agent项目的人应该都有同感自己刚把MCP跑通结果一看行业新闻发现已经有“四大协议”的讲法了整个人是有点懵的。这篇文章我想把这几年围绕Agent协作出现过的主要协议方向一次性说清楚。我不打算讲得太学术而是从自己的实际使用场景出发聊聊MCP到底解决了什么问题ACP和MCP的边界在哪AA管的是哪一段权限链路ANP又在布局什么更大的事情。看完之后你至少能搞清楚一件事当你做Agent开发时遇到什么场景该用哪一类协议而不是跟着热搜词走把什么技术都往项目里塞。1. 为什么Agent突然需要一堆“协议”先看它卡在哪1.1 Agent从单机走向协作才暴露了标准化问题早期大家做Agent本质上就是一个大模型加几段工具调用逻辑。你说“帮我查天气”模型调用一个天气API回来再组织语言这套流程不需要什么协议。但从2025年开始大家发现真正有价值的Agent根本不是单打独斗而是要让它操作浏览器、访问设计稿、调数据库、对接企业内部系统、甚至和另一个Agent协同完成一个跨部门任务。一旦Agent要连接的外部系统变多问题就来了每个系统都有自己的一套API风格有的走REST、有的走WebSocket、有的还要先做复杂的OAuth授权。你如果针对每个系统都写一套适配代码做三五个工具还能忍做到二三十个的时候整个项目就成了一个巨大的“胶水代码垃圾场”。我见过一个真实的项目团队花了三周时间对接了五个内部系统代码量大概三千多行全部是这种定制化适配。这还不是最痛苦的最痛苦的是每个系统改一次接口你的Agent代码就得跟着改一次。这就是为什么业界开始提“协议化”的思路与其让每家都按自己的方式对接不如大家听同一个指挥棒按同一套规则描述工具能力、发送请求、返回结果。1.2 MCP/ACP/AA/ANP不是同一个东西但很多人把它们混着聊现在网上讨论最乱的就是把MCP当成Agent协议的全部。实际上这四个缩写分别关注的是不同层次的问题协议核心关注点一句话理解MCP模型与外部工具/数据源的连接Agent怎么调用工具工具怎么被描述ACPAgent与Agent之间的相互通信两个Agent怎么发现对方、怎么派活、怎么交接AAAgent访问外部资源时的身份与授权凭什么是这个Agent调用这个API权限边界在哪ANP开放的Agent网络基础设施多个Agent节点如何路由消息、交换身份、组成一张协作网这张表你可以先存下来。后面每一节我都会展开讲把每个协议的底层逻辑和实际用法说透。这样你再看行业新闻的时候就不会觉得每个词后面都得跟一个惊叹号了。下一节先讲大家接触最多的MCP因为它是最容易落地、生态最丰富的一个。2. MCP连接模型与工具的“地基协议”2.1 MCP的架构到底是怎么设计的MCP的全称是Model Context Protocol最早由Anthropic提出后来迅速被OpenAI、Google这些大厂跟进支持。它的核心设计思路非常直观把“模型需要调用工具”这件事标准化成一个“客户端-服务器Client-Server”结构。在这个结构里Agent应用本身是MCP客户端你要让Agent访问的各种系统数据库、浏览器、设计软件、监控平台等等都被包装成MCP服务器。每个MCP服务器向外暴露三种基本能力Tools工具可以被模型调用的函数比如“打开网页”“读取设计稿图层”“执行SQL查询”。Resources资源可被读取的数据对象比如一个文件的内容、一段日志、一张图片的元数据。Prompts提示词模板预置的交互模板让模型知道在特定场景下该以什么格式组织请求。这三类能力统一通过JSON-RPC协议传输。你不需要关心底层是HTTP还是stdio通信MCP已经帮你封装好了。也就是说你写好一个MCP服务器不管你的Agent是跑在Python还是TypeScript环境不管你接的是哪个大模型只要大家都遵循MCP规范就能互相识别、互相工作。这就像USB接口一样——以前每个设备都要自己的充电线现在统一成一个Type-C口虽然设备内部千差万别但接口是标准的插上就能用。2.2 实操从零写一个带业务逻辑的MCP服务器理论讲再多都不如直接跑一遍。我以一个“读取本地项目目录文件并统计代码行数”的MCP服务器为例用Python的官方SDK给你演示核心代码。先安装依赖pip install mcp然后写一个最简单的服务器from mcp.server.fastmcp import FastMCP mcp FastMCP(code-stats) mcp.tool() def count_lines(path: str) - dict: 统计指定路径下的代码文件行数支持.py/.js/.ts/.java import os from pathlib import Path target Path(path) if not target.exists(): return {error: 路径不存在} result {} total 0 for f in target.rglob(*): if f.suffix in [.py, .js, .ts, .java]: lines len(f.read_text(encodingutf-8, errorsignore).splitlines()) result[str(f)] lines total lines result[_total_] total return result if __name__ __main__: mcp.run(transportstdio)这段代码发布之后任何MCP客户端只需要连接这个服务器你的Agent模型就能直接调用count_lines这个工具。整个过程用户完全不需要知道count_lines是怎么实现的也不需要写任何一行适配代码。这就是MCP对Agent开发体验最大的改变工具接入从“写代码”变成了“声明一下”。我再补充一个实际工作中的经验。很多人第一次接触MCP会陷入一个误区觉得必须从零写一个服务器才叫“用上MCP”。其实完全没必要现在官方仓库里已经有几百个现成的MCP服务器你只需要做配置。我常用的几个Playwright MCP让Agent直接控制浏览器做自动化测试、抓取动态页面。Figma MCP让Agent读取设计稿的图层、样式、标注信息前端工程师可以直接让Agent把设计稿里的颜色、间距提出来。蓝湖MCP国内设计协作平台蓝湖也提供了MCP接入设计师交付的设计稿可以被Agent直接解析。今年蓝湖在MCP上动作挺快这对国内做设计研发协同的团队来说是个好消息。Chrome DevTools MCP如果你做前端调试这个MCP能让你用自然语言命令Chrome执行性能分析、控制断点效率比手动点开发者工具高不少。2.3 MCP生态里的那些实际场景我可以按行业给你归类MCP的生态现在可以说是“万物皆可接入”。我自己接触到的真实项目里用得最多的场景可以分成这几类开发工具类Playwright MCP、Chrome DevTools MCP、Burp Suite MCP、Yakit MCP。Burp Suite做Web安全测试的时候以前全靠手工配置拦截规则现在可以通过MCP让Agent辅助分析请求包自动生成测试用例安全测试的门槛确实降了不少。Yakit是国内的一款安全测试工具也紧跟浪潮做了MCP适配这让我挺意外的说明安全领域对Agent自动化是有刚需的。设计协同类Figma MCP、蓝湖MCP。这类工具最典型的用法是让Agent直接读设计稿的结构化数据而不是靠“截图给大模型看”。截图是像素MCP给的是图层前者需要模型去猜后者是精确数据效果完全不同。三维与游戏开发类Blender MCP、Unity MCP。我在做3D场景生成试验的时候试过Blender MCP模型可以直接通过MCP操作Blender里的对象创建、材质设置。虽然复杂建模还是很吃力但做批量场景搭建、重复性操作确实能省不少时间。CAD/工业软件类NXOpen MCP。这属于传统工业软件开始拥抱Agent的信号。CAD领域对精度要求极高很多操作不能靠模型瞎猜参数通过MCP把NX的参数化接口暴露出来Agent才能做真正意义上的“辅助设计”。办公与信息检索类各类文档MCP、数据库MCP、浏览器MCP。这也是大多数企业最先落地的方向把内部知识库、数据库都封装成MCP服务器让Agent具备企业内部的数据访问能力。2.4 MCP的局限在哪里它管不了的事你千万别指望它说完MCP好的一面我必须泼一盆冷水。MCP的核心定位是“模型连工具”它不解决Agent与Agent之间的协同问题。举例来说你有一个“内容策划Agent”它需要文案Agent帮它写一段产品介绍。通过MCP内容策划Agent只能调用“文案工具”但没办法知道文案Agent是否存在、它的能力边界是什么、该怎么给它派活。这就是MCP的边界。另外MCP在权限控制方面也很薄弱。MCP服务器只负责“能不能连上、怎么调用”至于这个Agent有没有权限调用某个高敏接口、调用了之后责任归属怎么算MCP基本不管。于是就有了后面要讲的AA和ACP。3. ACP让Agent之间能“对话和派活”的通信协议3.1 为什么说MCP不解决Agent互联ACP才解决业界对于“Agent之间如何通信”的探索经历了好几轮。早期有人想用简单的HTTP请求直接让两个Agent互相调用后来发现不行——Agent不是一个固定接口的服务它内部有状态、有长期任务、可能还会异步执行你用传统的REST请求去调根本没法表达“我派给你的这个活做到哪一步了”。于是ACPAgent Connect Protocol出现了。你可以把它理解为Agent界的“TCP/IP”它定义了一套Agent之间相互发现、建立连接、发送任务、接收状态更新的标准方式。有了ACP之后一个Agent就不再是孤立的程序而是网络上可以被其他Agent发现和调用的节点。我强调一句ACP负责的是“Agent对Agent”的通信链路它关心的是任务怎么下发、状态怎么同步、结果怎么回收。至于这个Agent用什么模型驱动、内部有什么业务逻辑ACP一概不管。这种“打了协议就统一内部实现自由”的设计思路带来的好处是生态级别的——哪怕是两个不同厂商开发的Agent只要都实现了ACP规范就可以直接协作。3.2 ACP的典型交互流程我用一个真实业务场景来拆解我给你模拟一个场景假设你有一个“品牌内容规划Agent”我们叫它A还有一个“社交媒体排版Agent”叫它B。按照ACP的规范第一步是发现Agent A向服务注册中心发起一个查询问“有没有能处理社交媒体排版的Agent”注册中心返回Agent B的标识和它暴露的服务能力描述。第二步是接洽Agent A向B发送一个任务提案内容包括任务类型排版、输入数据文案和图片素材、期望的输出格式。第三步是执行Agent B接受任务开始处理同时通过状态通道向A汇报进度比如“已处理40%”。第四步是回传B完成排版后把最终结果和元数据用了哪些字体、尺寸是否符合规范返回给A。这个过程全过程都是异步的任何一个Agent都可以同时接收多个任务、维护多个任务状态。用一句话总结就是MCP解决“模型不会用工具”的窘境ACP解决“Agent找不到同行”的窘境。3.3 我建议你把ACP理解成“任务级通信”而不是“接口级调用”我在实际项目里踩过一个典型的坑试图用MCP去实现两个Agent的协同。结果就是A把B当作一个工具来调用B的返回值是一个静态JSON事后B的下一轮状态A根本不知道。这就像你用对讲机问了一句话之后对方回了你两个字但没有后续了。这不是MCP不好而是它不适合表达有状态、多轮的Agent协作。所以我在做项目设计的时候会遵循这样的判断准则如果两个Agent之间只是“问个数据”那用MCP甚至普通API调用就行如果两个Agent之间需要“长期协作、任务流转、状态确认”那就要考虑ACP。特别是你现在做音视频、游戏AI、客服系统这类高交互场景ACP的设计理念会更贴合实际需求。ACP发展到今天的成熟度还不能和MCP相比。但它的方向是对的——把Agent从“工具使用者”变成“网络参与者”这是Agent真正走向实用的必经之路。4. AA为Agent访问外部资源装好的“门禁和权限边界”4.1 Agent能力越强权限失控的风险越明显我在前面提到过MCP能让Agent连接任何外部工具但你有没有想过一个安全性的问题当Agent的能力足够强时它能浏览网页、能操作设计文件、能执行数据库查询、能够改代码那么它凭什么有权做这些事它做的操作算谁的谁能限制它只能读不能写这其实是一个非常现实的工程问题。早期我见过一个团队把企业内部CRM系统的API直接封装成MCP工具结果Agent在测试时因为收到了一个误导性的Prompt连续调用了十几个写接口把测试环境的数据搞乱了。这个事说到底是权限管控缺失——你给了Agent一把万能钥匙却没有告诉它每个房间能进多少人、能碰哪些东西。AA协议Agent Authorization也常被译为Agent授权协议就是来解决这件事的。它的核心目标是在Agent访问外部资源、执行高风险操作之前建立起一套标准化的身份认定和授权检查机制。4.2 AA的授权链路和传统OAuth有什么区别很多读者听到“授权”就会想到OAuth 2.0。别急OAth和AA不是一回事或者说AA是构建在OAuth思路之上、专门为Agent场景优化的。传统OAuth解决的是“用户授权应用访问资源”。比如你在手机上点同意微信助手这个应用就能读取你的头像昵称。但Agent的场景复杂在它不是单一用户发起的可能在无人值守的情况下运行也可能代表多个用户发声。你出差在外Agent收到一个高权限任务按旧机制它只能卡住等人工确认而AA希望让这件事既能得到有效控制、又不至于阻塞Agent的正常工作。AA引入了三层授权模型我觉得这个设计很值得学习身份层确认这个Agent是谁属于哪个组织由哪个用户/系统启动。权限层明确这个Agent在特定任务下能访问哪类资源能执行哪些操作。交互层对每一笔高风险调用可以实时向用户发起二次确认也可以由用户在事前预设的“自动策略”里放行。说白了AA要解决的是“在保证安全的前提下允许Agent在合理范围内自动行动”。它不是简单地在Agent外面加一层防火墙而是把权限判断嵌入到了Agent执行任务的全过程。4.3 在实践中AA和MCP是最佳组合拳如果你在做Agent落地项目我的建议是MCP解决“能力接入”AA解决“能力边界”。二者配合起来才是完整的。举一个我实操过的配置思路。你有一个MCP服务器暴露了数据库读取和删除两个工具。在AA的框架下你会为这两个工具分别设定授权策略读取操作只需要Agent携带调用令牌即可执行删除操作必须经过人工确认台确认后才会真正触发。这种设计对用户来说体验是最自然的。Agent可以高效处理低风险操作遇到高风险操作自动“踩刹车”安全性和实用性取得了平衡。现在很多Agent开发框架也在做类似的安全层但我相信最终会收敛到统一的AA标准上来。还有一点要顺便提一下网上有个词叫“Agent安全”很多人觉得那是搞安全攻防的人需要担心的。实际上不是。只要你的Agent要访问外部API、要代表用户执行操作你就必须考虑AA这套东西。否则你写的不是Agent而是一个无审批权限的自动化后门。5. ANP面向“Agent网络”的协作协议比前三个更宏大5.1 MCP是点对点ACP是一对多ANP是组网前面讲的MCP是模型和工具之间的点对点连接ACP是Agent之间的任务协作这两者本质上都还是在“有限的节点之间”通信。但是如果你想让成千上万个Agent自由地发现彼此、交换信息、组合成临时的协作网络就需要一套更底层、更开放的基础设施协议——ANPAgent Network Protocol。ANP的设计出发点是把Agent当成网络中的独立节点每个节点有唯一的身份标识可以通过网络协议和其他节点交换消息。这和传统的服务网格Service Mesh思想有一定相似性但服务网格里每个节点都是被动响应请求的微服务而ANP里的节点是主动感知任务、动态参与协作的Agent。ANP框架我在理解时把它拆成三个部分这样比较好消化消息传输层不管Agent运行在哪里云服务器、本地电脑、边缘设备都能通过统一的格式互相发消息。身份与信任层每个Agent节点在加入网络时获得一个可验证的身份证书消息收发都可以验签防止恶意Agent冒充身份。路由与发现层Agent可以在网络中广播自己的能力描述也可以查询“谁有这个能力”然后动态建立通信路径。你可以想象一个将来的场景你在手机上发布“帮我整理这次旅行中所有酒店价格对比”的任务这个任务被拆解后自动发送给了三个Agent——一个负责搜索酒店平台、一个负责读取你的出行行程、一个负责生成对比报表。它们全程互不共享数据只通过ANP交换结构化结果和任务状态。整个过程你没有手动打开任何一个App。5.2 目前ANP能用在什么场景哪些地方还是空白实话实说ANP的成熟度目前远不如MCP。它更多是探索性的方向GitHub上已经有一些开源实现但它们还没有像MCP那样形成“即插即用”的生态。我个人感觉ANP最可能在两类场景里率先落地第一类是跨组织的Agent协作。比如供应链场景采购方Agent和供应商Agent分布在不同的企业系统里它们之间不可能直接开放数据库权限但通过ANP可以安全交换订单状态和库存信息。这种场景对身份验证、消息加密要求极高恰恰是ANP的设计重点。第二类是开放平台型的Agent市场。未来可能会有类似“Agent应用商店”的生态用户把自己的Agent发布到网络上其他Agent通过ANP发现并调用它的服务能力。这有点像过去建网站靠DNS解析和HTTP协议以后建Agent服务靠的是ANP协议。如果你准备在这个方向创业或做研究我建议关注三个关键词可验证身份、消息路由、任务协调。这三个是ANP试图解决的核心难题也是目前各路开源方案差异最大的地方。5.3 别急着把ANP搬进你的项目先按这个顺序做技术选型很多时候看协议介绍会让人产生“赶紧上新架构”的冲动。但根据我的经验技术选型讲究的是“问题匹配”而不是“越先进越好”。对于大多数中小企业来说在ANP还没形成统一标准之前贸然采用很容易变成给自己造轮子。我给团队的建议是递进式的技术选型路径你直接可以抄如果你的Agent目前只需要连接几个内部工具不需要复杂协议直接用MCP接入加一层简单的API密钥控制就够了。如果你的Agent需要访问外部系统并且涉及敏感数据在MCP基础上增加AA的授权机制至少要做分级权限控制。如果你的项目有多个Agent需要互派任务、状态流转开始研究ACP把任务级通信标准化。只有当你确信需要构建跨组织、大规模、动态发现的Agent网络时才值得认真去摸ANP。这个选型顺序不是保守是务实。协议最终是服务于业务场景的你为实验付出成本没问题但别让团队的宝贵开发时间变成协议的“试验田”。6. 四个核心协议横向对比一张表看懂怎么选到了这里MCP、ACP、AA、ANP各自的定位应该已经很清晰了。我把它们放在一张表里从不同维度做最终对比方便你以后做技术评审时直接参考。对比维度MCPACPAAANP核心解决问题模型调用外部工具的数据通道Agent之间的任务发现与协作Agent执行任务的授权边界Agent节点组成开放网络通信关系Client-ServerPeer-to-Peer控制平面横跨所有调用Node-to-Node网状最核心的抽象Tool/Resource/PromptAgent能力描述与任务信封身份、权限策略、审批流身份证书、消息路由、能力广播典型使用方做Agent开发的工程师做多Agent系统的平台方做企业级Agent落地的团队做开放Agent生态的基础设施团队成熟度高已有大量生产级应用中等生态正在形成中等规范仍在迭代低偏研究与早期探索学习成本较低官方SDK完善中等需要理解任务模型中等涉及权限体系设计较高涉及网络协议与服务发现和你现在的关系现在就能用起来值得跟进可先做小规模验证做生产系统时应考虑观望为主持续追踪很多人问我这四个协议最后是不是会合并成一个我的看法是短期内不会。它们解决的问题维度不同所处抽象层级也不同。准确地说它们更像是一个完整的Agent架构里不同层次的分工协议未来被同时使用是常态。就像互联网的TCP/IP和HTTP不会互相取代一样它们满足的是不同层的通信需求。不过话说回来现在协议变化还很快我今天写的认知可能一年后就会有新的补充。所以更重要的不是背下这些概念而是理解它们共同指向的方向Agent正在从“大模型加工具的脚本”走向“可协作、可授权、可组网的数字劳动力”。理解这个底层趋势你就能在不断出现的术语里始终保持清醒。作为一直在一线做Agent开发的工程师我最近的体会是不要被新词裹挟但要认真对待新词背后的问题。到今天为止MCP已经实打实地让工具集成的效率翻倍了AA让企业内部对Agent授权有了抓手ACP和ANP也许还远但它们指向的方向一定会是下一阶段Agent工程的核心议题。你可以先从把MCP用一个成熟场景跑起来开始然后逐步把授权机制、多Agent协作加进去这条路走完你就不会再为任何新技术名词焦虑了。