智能体通信这件事，我终于看到有人愿意先把地基协议画出来了。
晚上翻完《Agent Network Protocol 技术白皮书（草案）》，我脑子里不是协议栈、消息格式这些细节，而是一个特别具体的场景：如果能让我的个人助理智能体，直接跟一个完全没打过交道的第三方智能体握手、协商、分活、对账，中途不经过任何平台中转、也不需要两边的工程师约需求排期写接口，那能省掉多少事情。
这份草案想做的，正是这么一套面向智能体对等通信的标准化协议。它不是某家公司的私有框架，也不是一个现成的Agent平台，而是一种通用“语言规则”，让不同厂商、不同技术栈、不同信任域里的智能体，可以互相发现、互相理解、互相授权、互相交付结果。适合谁看？如果你在研究多智能体系统、做AI Agent产品、或者负责企业内部的自动化协作框架，这份草案的思路值得从头到尾捋一遍。
1. 智能体通信，正在重演互联网早期那场乱战
1.1 现在两个智能体要协作，到底有多麻烦
先说一个很现实的问题：今天你手里的智能体，想调用另一个智能体的能力，基本靠什么？
绝大多数情况靠的是“项目级定制”。两边各出一个技术负责人，定好接口路径、确定JSON字段、商量鉴权方式、写联调文档、做异常重试……听起来是不是特别像十年前两个系统做对接的样子？整个流程走下来，业务需求不复杂的话可能也要两三天。如果背后不是同一个平台，而是跨公司、跨生态的两套Agent系统，时间还会翻倍。
另一个常见方案是“把能力塞进同一个平台”。大家都接同一个Agent框架，用同一套插件规范，工具调用在平台内部流转。这个方案解决了一部分落地问题，但代价是把生态锁死了——你接入了A平台，就很难再让A平台的Agent去指挥B平台的Agent。平台之间的壁垒，比公司之间的部门墙还高。
MCP、A2A这类协议的出现，本来是想解决一部分问题：MCP让模型能更方便地调用工具，A2A让Agent之间的HTTP互操作有了一致性的尝试。但我在实际落地中最直观的感受是，工具调用层面的打通容易，身份怎么互认、信任怎么传递、长耗时任务怎么跨节点追踪，仍然像没娘管的孩子，各家在用各家的私有办法。
1.2 四个让工程师深夜失眠的痛点
我把这几年看到的问题归成四类，每一类在真实项目里都能找到对应事故：
首先是集成成本高。每个新接进来的智能体，都是一次定向开发。字段对不上、状态码理解不同、鉴权方式五花八门，联调过程堪称程序员版“连连看”。
其次是身份无法互认。我信任这个Agent吗？它说自己是某公司的采购助手，有什么办法验证？现有的做法最多是看IP白名单、API Token，但Token可以被转发、IP可以伪造，跟智能体之间真正需要建立的那种“你是你、我是我”的信任，差得很远。
第三是协作太浅。两个智能体之间如果只是简单的一问一答，问题还不大。但一旦涉及多轮协商、异步执行、中途换人、分阶段审批，因为没有统一的会话追踪机制，经常出现任务做到一半，状态对不上、责任理不清。
第四是生态锁定。前期选择了某家Agent编排平台，后期想引入一个能力更强的外部智能体，你会发现自己被平台API和插件规范焊死。想挣脱吧，重构成本高得吓人；不挣脱吧，只能看着新能力进不来。
1.3 ANP想解决的核心问题
ANP这套草案，本质上是在回答三个问题：智能体之间如何证明身份、如何找到彼此、如何进行可信的语义级沟通。
它把智能体当作网络里的“一等公民”来对待，而不是某个系统里可以被随意调用的函数。这个视角的转变很关键——过去我们讨论的集成，是“微服务之间怎么调接口”；ANP想讨论的，是“智能体之间怎么协作做生意”。
它要实现的效果，有点像当年的TCP/IP对计算机网络做的事：通信双方不再关心对方是什么操作系统、什么硬件厂商、在哪台服务器上，只要遵守同一套报文规则，就可以互联互通。智能体世界也需要这样一套“通用报文规则”，让一个用LangChain写的Agent、一个用自研框架跑的商业Agent、一个跑在嵌入式设备上的轻量Agent，能够平等对话。
2. 白皮书草案的核心设计目标与总体分层
2.1 三条值得细品的设计目标
草案里反复强调的目标，我提炼出来是三条，每条背后都有实际痛点支撑。
第一是“对等性优先”。智能体之间不是主从关系，而是协商关系。传统API的模式是服务端定义规则、客户端遵守规则，但智能体协作经常没有固定的客户端和服务端，今天你请求我，明天我请求你。所以协议必须把双方放在对等位置，每个智能体既是服务的提供者，也是服务的消费者。
第二是“去中心化信任”。不依赖某个中心平台来发号施令、担保身份。身份认证靠密码学，信任关系靠可验证凭证和声誉积累，消息路由靠一组分布式的目录服务互相连通。
第三是“语义可协商”。不止交换数据，还要交换“对数据的理解”。两个智能体对接时，如果对字段含义的解读不一致，一切技术细节都是空中楼阁。所以ANP在消息层之上设计了一套语义协商机制，让双方在传输前先把Schema对齐。
2.2 四层协议栈的划分方式
整套协议大致可以拆成四层，按从底到顶顺序：
底层是传输适配层。ANP不强绑某种网络协议，TCP、TLS、WebSocket、HTTP都能作为承载，甚至私有物联网协议也行。这一层解决的是“消息能传过去”的问题。
第二层是身份与信任层。每个智能体注册一个去中心化身份（DID），持有对应密钥，通过签名和验证来确认消息来源。这一层解决的是“说话的是谁、能不能信”的问题。
第三层是发现与路由层。智能体在目录服务里发布能力声明，其他智能体可以按语义检索到它，再通过网关路由到具体实例。这一层解决的是“谁能干什么、怎么找到它”的问题。
第四层是消息与协作层。定义消息类型、会话ID、任务状态流转、异步回执，以及Schema协商流程。这一层解决的是“话怎么说、事怎么办”的问题。
2.3 为什么必须走去中心化路线
我见过不少团队，一听去中心化就上头痛，认为它又慢又难管理。但 ANP 这个场景下，去中心化不是一个情怀选择，而是务实的架构决策。
原因很简单：智能体的所有权高度分散。你手机上的个人助理数据归你管，公司供应链里的订单Agent归公司管，云端SaaS里的客服Agent归服务商管。如果存在一个中心平台来协调所有智能体的身份和路由，那么谁运营它、数据归谁、哪天它停服了怎么办，都是无解的问题。
去中心化不等于不要管理，而是把自治权交还给每个智能体的所有者。每个节点可以自己决定要不要开放能力、向谁开放、信任哪个目录、接入哪些网关。就像企业建自己的邮件服务器，但依然能和全世界互通邮件，因为大家遵守同一个邮件协议。
3. 四大核心机制拆解：身份、寻址、消息、信任
3.1 身份层：每个智能体一出生就是一把钥匙
整套协议里我最先关注的，是智能体的身份机制。
草案描述得很干脆：每个智能体生成一对公私钥，公钥直接参与生成去中心化身份标识，私钥用来签发所有外发消息。你可以把这个身份标识理解成智能体的“护照号”，而公钥就是验证护照真伪的防伪特征。无论这个智能体今天跑在云主机上、明天迁移到本地工作站、后天被部署到一台边缘网关里，它的身份不变，历史声誉和信任关系也跟着它走。
这一点和微服务的身份模型有本质区别。微服务通常用IP、域名或服务名定位，挂了换个实例就换身份。但智能体要维护的是长久的协作关系和声誉记录，今天它帮你处理过发票，明天你还想找它处理，靠IP是记不住这个连续性承诺的。
身份层还定义了多密钥机制。一个智能体可以有一个长期身份主密钥，再加若干短期会话密钥用于不同任务。主密钥离线保存，会话密钥在活跃时使用，这样即使某次会话密钥泄露，也不会动摇智能体本身的核心身份。
3.2 寻址与能力发现：从找“地址”变成找“能力”
传统网络寻址问的是“某某服务在哪台机器上”，ANP的寻址问的是“哪个智能体具备我需要的某种能力”。
这个转换非常自然，因为智能体本来就是可以移动的。一个负责库存管理的Agent，白天可能跑在云端响应高频查询，晚上可以拉回本地做离线盘点。如果它的地址是固定IP，就完全没法支持这种灵活性。所以ANP的目录服务里存的核心信息不是地址，而是一份“能力声明”。
能力声明是一份结构化文档，描述智能体能做什么、需要的输入是什么、输出是什么、收费方式、服务水平约定、信任评级等等。其他智能体通过语义查询，不是查“哪里有接口”，而是问“谁能帮忙核对发票真伪”，返回的是一群具备该能力的候选对象。
这个过程有点像搜索引擎，但它比搜索引擎更严谨：返回的不只是信息，而是带有密码学签名的可验证描述，调用方可以校验这份描述是不是真的来自那个声称有该能力的智能体。
3.3 消息层：协议里最有实用价值的一块
消息层决定了智能体之间“说话的方式”。草案把消息分成几类，主要包括查询、任务分派、协商、确认、结果回执等等。每一条消息都带有唯一的消息ID、会话ID以及时间戳，这样双方可以围绕一个长期任务不断交换消息，而不是每次都是无状态的独立请求。
比较吸引我的是“语义协商”机制。两个智能体第一次交流时，先不急着传业务数据，而是交换各自的Schema定义，比如“这个字段代表什么含义、值的范围是什么、是否允许为空”。双方用版本号标记自己理解的Schema，只有确认一致后才开始正式传数据。
这个设计从工程角度极其有意义。我见过太多系统联调事故，都源于两边对一个字段的解读不一致，比如“status=active”到底表示任务已开始还是已完成，不同团队有不同理解。有了语义协商，这个坑在握手阶段就被排掉了。
3.4 信任与安全：先验身份，后磋商授权
安全机制在草案里不是单点设计，而是贯穿各层。
身份验证靠签名：外发消息都带数字签名，接收方用对方的公钥验证来源。这个机制保证了消息不可伪造、不可抵赖。
权限委托靠令牌：当你希望某个智能体代替你执行某些操作时，不是把全局权限交出去，而是签发一个短时效、限定范围的授权令牌。令牌里写明“允许调用哪些能力、最多调用几次、是否允许读取历史记录、有效期到什么时候”。
隐私保护靠选择性披露：智能体可以证明自己是否具备某个资质，而不必透露全部资质细节。类比一下，你进酒吧只需要证明自己年满18岁，不用把完整身份证所有信息都亮出来。
在安全方面，草案还有一个值得注意的倾向：它希望把“信任”变成一个动态评价过程，通过每次交互的结果不断更新智能体的信任分，而不是简单相信一次性认证。这样即使一个智能体身份真实，但如果屡次交付失败，它的网络信誉也会下降。
4. 实操视角：一个智能体如何通过ANP找到并调用另一个智能体
4.1 设定一个具体的场景
为了让这套机制不悬在空中，我构造一个非常日常的场景来走一遍流程。
假设我有一个个人助理智能体A，我需要预订明天下午的一间会议室，但A自己不具备查询会议室状态和修改预订系统的能力。办公楼里另有两个第三方智能体：B负责提供会议室实时状态查询，C负责执行预订操作。三个智能体由完全不同的开发团队维护，彼此之前没有任何约定和共同数据库。
4.2 接入ANP前需要准备的三件事
任何智能体想要加入这个网络，最先要完成的不是写业务代码，而是三件基础工作。
第一，创建身份。生成密钥对，注册DID，并把公钥绑定到身份标识上，这一步类似给智能体上户口。
第二，发布能力声明。用结构化文档描述自己会做什么、输入输出格式是什么、可用时段、信任要求等。B会声明“我能提供会议室状态查询，输入是时间段，输出是会议室列表”，C会声明“我能执行会议室预订”。
第三，实现消息接收端点。智能体需要有一个收件箱和数据接收地址，并在目录服务里注册，让别人能找到、能发给它。
做完这三件事，智能体才算真正“入了网”。接入工作在草案里设计得相对轻，不会要求你搞一整套复杂SDK，关键是遵循消息格式和签名规则。
4.3 一次完整交互的六步流程
整个协作过程大致如下：
第一步，发现。A向目录服务发起语义查询：“明天下午可用的会议室，谁能查询状态？”目录返回B和它的能力声明。A检查声明，确认B的输出格式自己可以处理。
第二步，握手。A向B发送一个握手请求，用B的公钥加密。B收到后验证A的身份签名，确认A不是一个随机伪造的发送者。双方交换临时会话密钥，决定用密钥对后续通信加密。
第三步，语义协商。A把自己理解的“时间段格式”发给B，同步说明下午具体指14点到17点。B回应自己的Schema版本，表示“下午在某些语言环境里可能有歧义，建议统一用ISO格式的起止时间”。双方对齐后进入下一步。
第四步，派发查询任务。A向B发送查询指令，携带B需要的查询参数，以及一个短时效授权令牌，令牌限定B只能查询、不能修改。B执行查询，返回一个签名后的会议室列表。
第五步，异步回执。因为会议室状态可能实时变化，A和B约定这个任务不是一次同步请求就结束，而是一个持续3分钟的回执窗口，如果B发现结果变化，会主动推送更新。
第六步，预订执行。A从结果里选一个会议室，转而向C发送预订指令，同样携带限定范围的令牌。C完成预订后回传带有签名的确认单，A校验无误后向用户展示结果。
整套流程走下来，你会发现三个智能体之间没有共享数据库、没有统一平台、没有人工协调参数，纯粹靠协议规定的身份验证、能力发现、语义协商和消息流转完成了协作。
4.4 流程中的几个关键避坑点
这里有一些细节，只有实际跑了类似流程才会意识到多重要：
先说签名验证的顺序。一定是在解析业务数据之前先验签，而且验签失败的消息不能进入业务逻辑。我见过有人图省事跳过验签流程，结果被一个伪造消息直接打穿了状态机。
再说令牌的粒度。授权令牌一定要做到最小权限，查询场景就只给查询，别顺手把修改权限也带上。很多安全事件的核心教训就是权限粒度太粗，ANP哪怕把机制设计得再好，如果调用方习惯性签发全局令牌，一样挡不住风险。
还有超时与重试的问题。智能体不是稳定服务，它可能正在处理另一个长任务，响应延迟会非常高。所以在实现消息回执时，要把每个消息的超时时间独立设置，不要用一个全局超时。否则只是一个大任务执行慢一点，就会引发连环超时误报。
5. 设计取舍：为什么是“协议”而不是“平台”或“框架”
5.1 协议、框架和平台的差别，决定了走向
很多人容易把协议、框架、平台混为一谈。我梳理一下：
协议是双方共同遵守的一套规则，规定“消息长什么样、发到哪里、怎么确认成功”。协议本身不提供软件实现，就像TCP/IP规范不等于Windows网络栈。
框架是帮你实现这套协议的代码脚手架，它把很多细节封装好，让你专注业务。
平台则是一个运营起来的服务网络，是所有智能体实际运行和交易发生的场所。
ANP选择从“协议”切入，而不是做成平台，是一个非常谨慎的定位。一旦做成平台，就会出现平台方掌握用户关系、锁定开发者生态的问题，这就违背了智能体需要跨生态协作的初衷。而纯协议路线允许任何人实现自己的节点和目录，市场会形成多个互联的目录网络，谁也掐不死谁。
5.2 为什么不直接基于HTTP或者gRPC改造
有一种声音是：直接用HTTP加JSON再加OAuth，不行吗？
我觉得要分两个层面看。HTTP作为传输层，完全没问题，事实上ANP的设计就没有排斥HTTP作为承载协议。但如果只靠HTTP，你面临的问题是大量工作要在业务层重复实现：身份互认怎么做、跨域信任怎么建立、一个需要跑一个小时的任务怎么追踪上下文、两个服务之间怎么协商数据Schema。
这些问题在智能体场景里是会反复出现的，但HTTP本身不提供这些语义。所以你确实可以在HTTP之上自己设计一套，但那就是在发明另一个ANP，而且还更乱。
gRPC具有强类型接口约束，适合进程间紧密耦合的调用。但智能体协作很松散，你甚至不提前知道对方能提供什么方法，必须在运行时动态发现和协商。gRPC在这种语义柔性场景里并不顺手。
所以ANP的定位不是替代HTTP，而是把智能体之间真正需要的身份、发现、语义协商、信任委托这些“前置条件”做成标准层。这一层的价值不是某一次请求的成功率，而是让整个智能体生态有了互操作公约。
5.3 与MCP、A2A这些相邻方向的关系
讨论ANP，不可避免要提到已经存在的MCP和A2A。
MCP解决的核心命题是“模型如何调用外部工具”，它侧重智能体内部架构；A2A侧重Agent到Agent之间基于HTTP的互操作，已经给出了不少上下文和消息格式的约定。ANP的视野更大一些，把去中心化身份、能力目录、跨域路由也作为一等公民纳入设计。
其实三者不构成竞争，更像是分层分工：MCP在智能体内部打通工具层，A2A在HTTP之上做Agent互操作，ANP想把其中最关键的身份和信任底座独立出来，制造成整个智能体网络的公共设施。但草案目前对这三者的边界描述还比较模糊，哪些场景该走A2A、哪些场景该走ANP，需要更多真实案例来划界。
5.4 这份“草案”的完成度判断
从标题就能看出，这是一份“草案”，不是正式标准。我读下来的感受是：设计框架已经搭得很完整，四层结构、核心消息类型、身份机制这些都是清晰的，适合作为技术预研和原型验证的起点。
但工程化的部分还有不少待补之处，比如消息路由在超大网络里的收敛效率、安全问题之外的隐私合规细节、目录服务如何做数据同步与防篡改，都没有给出可测试的量化指标。对于做技术选型的团队来说，这份草案更适合用来建立认知框架，比拿着它直接上线生产要稳妥得多。
6. 哪些场景会先用起来，哪些还得等一等
6.1 可能率先落地的场景：To B协作和供应链
我看好的是企业内部和供应链上的多智能体协作。这类场景有一个特点：参与者数量有限，信任关系相对成熟，不需要庞大的公共网络，更像是一个个私有联邦先跑起来。
比如一个大型制造企业，采购Agent、库存Agent、物流Agent分属不同子公司，甚至使用了不同的技术栈。以前要协作，要么统一平台，要么定制接口。如果都接入同一套ANP私有网络，用DID互认身份，用能力声明做能力开放，用令牌做权限控制，整合成本会比定制开发低一个量级。
这类场景里最关键的推动力不是技术诱惑，而是实际可量算的成本：每少对接一个定制接口，就少一个维护联调负担。
6.2 中等成熟度的场景：个人助理与开放服务市场
个人助理领域的跨App协作，也有强烈需求，但成熟度次之。原因是个人场景里客户端设备多样、网络条件不稳定、用户隐私要求极高。你让我的手机助理去调用其他服务商的智能体，牵扯到个人数据在哪儿中转、什么时候删除、日志归谁管，这些问题目前的协议草案还不能给出让人放心的答案。
不过如果先把范围限定在低频、低敏感场景，比如会议室查询、航班状态通知、公开活动信息整理，我个人判断半年内就能看到第一批产品原型。真正高频处理日程、邮件、账单等高敏数据，还需要等隐私治理条款跟上。
6.3 远期场景：开放的智能体服务市场
再往后看，ANP如果铺开，最有想象力的场景是智能体服务市场。在这个市场里，各种能力型智能体像App一样上架，但不需要通过应用商店的统一审核，只要遵循同一套协议，就可以被其他智能体发现、订阅、调用和付费。
这会带来一种全新的软件协作模式：你的个人助理替我跑腿，我的法律咨询Agent为你出具初步分析，你的数据分析Agent替我处理报表。每个智能体都不需要在一个平台上架，只需要加入这个开放网络，就能和其他任意智能体自由组合。这当然是很远的图景，但它至少指明了一个正确的方向。
7. 草案阶段必须直面的五个现实问题
7.1 网络性能指标目前还是空白
一份协议能不能被大规模采用，很大程度上取决于它在大规模网络里的表现。草案给出了机制设计，但我没看到压力测试数据：全网有一百万个智能体在注册和查询时，目录服务能不能撑住？跨五个网关节点的消息往返延迟如何？密钥验证在高并发下会不会成为瓶颈？
没有这些数据，企业选型的时候很难下决心迁移。后续草案或实现方需要提供一套覆盖典型规模的基准测试报告。
7.2 语义协商的动态性还不够丰富
Schema对齐解决了初次见面的理解问题，但业务数据是动态变化的。一次会话中，如果B突然增加了一个输出字段，或者字段的取值范围发生变化，A如何感知并调整自己的处理逻辑？草案里提到了版本号协商，但没有深入说明运行中的Schema热更新策略。
这在实际操作里会非常考验消息层协议的严谨性。我甚至建议在协议里加入“能力变更通知”机制，让订阅方能在第一时间收到被调用智能体的能力调整提示。
7.3 监管问责模型没有明确提出
智能体偶尔会出错，一出错就需要有责任主体。比如C执行了错误的预订操作，是开发C的团队负责，还是允许C行动的令牌签发方负责？ANP的身份机制能在技术上定位到具体智能体，但具体到业务责任和赔偿流程，协议草案目前没有给出参考模型。
这个问题如果不解决，B端商用会有很大的合同障碍。技术部门可以说责任都能查证，但法务部门必须看到完整的分责框架才敢签字。
7.4 声誉系统容易被恶意行为污染
去中心化声誉是协议里比较理想化的一环，但任何开放系统的声誉都存在绕过和造假风险。一个攻击者可以创建大量身份来互相背书，让某个低质量智能体获得虚高评分，也可以批量差评打击竞争对手。
虽然选用了可签名的凭证，营造了一定的作恶成本，但是声誉的最终价值到底如何，还是要实打实地接受一场攻击场景的测试。草案即便是只作为参考，也可以把攻击模型和防御策略作为一节单独展开，让读者看清设计者已作思考的部分。
7.5 标准治理机制决定协议的生命周期
最后是我最关心的部分：草案变成正式标准之后，谁来维护？版本由谁发布？新增消息类型需要怎样的流程？协议的分支是否有兼容性约束？
这些管理问题如果没有明确的治理主体，很难走远。回顾历史，TCP/IP之所以能长期稳定运行，国际互联网工程任务组的公开流程和征求意见机制给了它持续进化的土壤。ANP如果想要成为真正意义上的智能体网络基础设施，也早晚要面对这个公共治理命题。哪怕先务实地在草案中提出“下一步，将通过公开讨论来收集社区反馈”，也是在朝着正确方向的迈进。
聊到最后，我想说一个自己的判断：这份草案最有价值的点，不在哪个字段怎么定义，也不在哪个机制设计得最精彩，而在于它第一次把“智能体作为网络对等主体”这个看似抽象的理念，拆成了一套可以讨论、可以争论、可以动手实现的技术框架。
如果你现在正在做多智能体系统，我的建议是别等标准成熟。先拿它的分层思路给自己做一次体检：你的系统里，身份、能力发现、消息语义、信任授权是不是耦合在一起的？如果是，先把它们拆开。等将来ANP正式成形，你迁移的成本会低得惊人；如果它最终没有成为主流，你按这个思路设计的系统，也不会白费——分布式协作的解耦理念，在任何协议栈上都成立。
