Agent 圈子里有个感受越来越明显：单个 Agent 的能力再强，也解决不了多个 Agent 之间“谁也不理谁”的尴尬。各家平台各自定义消息格式、各自的调用约定、各自的身份体系，表面上大家都在说“多智能体协作”，实际上连一次跨平台的委托任务都跑不通。这就很像上世纪网络刚起步时，每家厂商都有自己的一套协议，要不是 TCP/IP 站出来做公共语言，今天互联网不可能长成现在的样子。Agent Network Protocol（ANP）这份技术白皮书草案，干的就是这件事——给智能体网络定一套公共的语言、寻址方式、消息语义和信任机制，让不同来源的 Agent 可以互相发现、互相理解、互相协作。这篇内容适合正在做 Agent 框架、多智能体平台、或者研究 AI 系统互操作的朋友，也适合对下一代 AI 基础设施好奇的工程师。我会把这份草案里最核心的设计逻辑、关键机制和还没解决的挑战拆开讲清楚，也会补上一些白皮书里不会写的实操判断。
1. 智能体网络的“巴别塔困境”：为什么现在就要谈协议
先聊一个很现实的问题。我自己手头维护过几个 Agent 应用，有做任务编排的，有接外部工具的，也有跑多角色对话的。单看每个系统内部，其实玩得挺流畅：A 角色把任务分给 B 角色，B 角色拿到结果回传给 A，中间用各自框架里定义好的消息结构。但一旦想跨系统协作，就全乱套了——A 系统发出的“task.assign”，到了 B 系统里变成了一条无法识别的 JSON；B 系统自带的“权限令牌”在 A 那里根本没有验证入口；更不用说 Agent 的“身份”在不同平台之间完全无法对应，同一个智能体换个平台就相当于另一个人。
这就是我理解中 Agent Network Protocol 白皮书草案一开始就要解决的问题。它不关心你的 Agent 是在 LangChain、Semantic Kernel、自己写的框架还是某个云平台上跑的，它只关心一件事：所有 Agent 对外暴露的通信接口，能不能统一到一套可解析、可路由、可验证的消息模式上。草案把这个需求拆成了几个层面：首先是身份，每个 Agent 需要一个全局唯一的、可验证的标识；其次是寻址，对方 Agent 在世界上的哪个端点可以触达；然后是语义，双方交换的每一条消息表达什么意图、携带什么上下文；最后是信任，我怎么确认对面真的是它声称的那个 Agent，它给我的消息有没有被篡改。
这些需求单拎出来，每一项都不是新玩意儿。分布式系统几十年前就在做身份认证、寻址解析、消息路由；但放在 Agent 场景里，难点出现了新的变化。成百上千个 Agent 可能动态加入、退出，位置会漂移，能力会变化，而且每个 Agent 的“智能”是嵌入在模型推理里的，不是传统进程那种确定性的服务端口。你没法用一个固定的服务端口来描述一个 Agent，也没法用一次简单的心跳来确定它是不是还活着——它可能只是在思考，暂时没响应而已。所以 Agent 网络协议不能照搬传统的服务发现和消息中间件那一套，它必须在设计上默认“节点是动态的、能力是语义化的、响应是不确定的”。
草案想清楚了一个前提：协议的目标不是替代你现有的 Agent 框架，而是成为框架之间的一种“通用互操作层”。像互联网里 IP 协议并不关心上面跑的是 HTTP 还是邮件，ANP 也不关心每个 Agent 内部怎么推理、用哪个模型，它只保障一条消息能从 A 正确、安全、可理解地送到 B。理解了这一层，后面所有设计细节就都好读了。
2. 协议设计目标与边界：草案主动选择不做什么，才是最有价值的部分
白皮书草案里最容易被忽略但最值得琢磨的，其实是它给自己划的那条边界。很多协议项目失败，不是因为没有定义足够多的功能，而是因为什么都想管，最后谁也接不上。ANP 的定位很克制，这本身就是一种设计判断。
2.1 三个核心目标：互通、信任、动态适应
我把草案的目标归纳为三点。第一是实现跨平台互通，让不同来源的 Agent 能够通过统一协议进行消息交换，这要求协议在格式层和语义层都给出明确的规范，而不能只提供一个参考实现。第二是建立基础信任与安全框架，通过身份认证、消息签名、权限令牌等机制，让双方在不确定的网络环境里能够验证对方身份、确认消息完整性，这算多智能体协作的前提。第三是支持动态的网络适变，Agent 频繁上下线、能力升级、位置迁移都要在协议层面得到支持，目录服务和能力描述机制必须跟上。
这三点之间其实存在微妙的张力。互通要求标准化，标准化就需要牺牲一部分灵活性；信任要求严谨的验证链路，严谨往往带来更多开销；动态适应要求宽松的状态管理，宽松又容易让安全边界模糊。草案把这些张力处理成了显式的设计决策，而不是含混的愿景描述。比如在消息格式上，它选择了严格定义的 Envelope（信封）结构，但把内部 Payload（载荷）留给实现者自定义，这样既保证路由层可解析，又保留业务层灵活性。
2.2 明确的非目标：不管 Agent 内部发生了什么
白皮书草案里有几项内容，我认为可以明确写进“非目标”清单。协议不规定 Agent 内部使用什么推理模型、什么提示词策略、什么记忆存储方式；不规定单个 Agent 的能力上限，也不强制任何具体的任务分解算法；不试图定义一种通用的“Agent 编程语言”。这些内容属于框架层和应用层的范畴，如果协议把手伸进去，很容易被绑定到某一家或某几家的实现路线上，也就失去了公共协议的意义。
对我来说，这个边界尤其重要的一点是：它让协议具有了“可测试的合规标准”。一个实现只要能在消息格式、身份验证、路由语义上符合规范，就能与其他合规实现互通，至于里面跑的是 GPT 还是本地的小模型、用的记忆机制是向量库还是图数据库，完全不影响互联。这种剥离业务语义、只固定通信语义的设计思路，才是互操作性能真正落地的核心原因。
2.3 与现有协议的取舍：为什么不能直接拿 HTTP/RPC 或区块链那套用
读者可能会有疑问：为什么不直接把所有 Agent 通信都定为 RESTful API 或者 gRPC 呢？原因很简单，传统请求-响应模型是同步的、地址固定的、契约先行的。Agent 的交互往往需要异步协调，思考过程可能持续很久；Agent 的地址和可用性可能动态变化；而且 Agent 之间的能力匹配经常需要运行时协商，而不是编译期就敲定契约。REST 和 gRPC 在它们自己的问题域里依然优秀，但搬到 Agent 网络场景，缺了动态目录、语义协商、消息签名和身份持久化这几块。
那区块链那套去中心化身份和智能合约协议呢？它也并非对症。Agent 协作追求的是高效、低延迟、可演进，而链上协议的成本和延迟在目前阶段很难支撑高频的智能体交互。白皮书草案更务实的路线是借力现有基础设施：用加密算法保证签名安全，用目录服务实现轻量级寻址，用可扩展的元数据结构承载未来需求。这种“不重新发明轮子，只在必要的环节发明新轮子”的做法，是草案真正成熟的表现。
3. 协议架构总览：分层模型与消息面设计
如果把 ANP 看作一栋楼，它现在的结构是三层：网络接入层、语义路由层、能力协商层。这不是传统意义上那种严格划分的通信层级，而是按照 Agent 协作的特点做的一种功能分层。我逐层拆一下每层的职责，以及它们如何形成闭环。
3.1 网络接入层：建立端点、传输与基础安全
这一层解决的是最基本的“消息怎么从 A 传到 B”。每个 Agent 在接入网络时需要声明自己的 Endpoint（端点），这个端点可以是 WebSocket 地址、HTTP 回调地址，或者其他可操作的网络入口。协议底层不强制绑定某一种传输协议，而是要求接入层提供一个统一的 Bound（绑定）抽象，使得上层消息不需要关心底层走的是长连接还是短连接。
这里有个容易被忽视的细节：Agent 的端点未必是固定的。你训练好的一个 Agent 可能部署在本地边缘设备，也可能迁移到云端。所以网络接入层必须支持“身份与端点分离”——Agent 的 ID 是长期稳定的唯一标识，而 Endpoint 是可以动态变更的绑定关系。这意味着任何网络接入层的实现，都需要一个地址绑定信息的同步机制，让目录服务和其他 Agent 始终能通过 ID 查到当前可用的端点。草案在一开始就把这种“身份-地址分离”作为建模的基础，我觉得这个决策非常关键。
3.2 语义路由层：消息的理解与定向传递
网络接入层解决的是字节到达，语义路由层解决的是“理解这字节是什么意思、该往哪儿转”。ANP 的每条消息都带一个 Envelope，里面包含了消息类型、发送者 ID、目标 ID、消息 ID、时间戳、签名等标准字段；而 Payload 则承载业务数据。Envelope 是路由层的公共语言，任何符合规范的中间节点都能读懂，从而完成转发、归档、鉴权等操作。
草案里定义了四类基础消息类型：请求（Request）、响应（Response）、事件（Event）、公告（Announcement）。Request 和 Response 对应一次有来有回的任务交互；Event 用于异步通知，比如某个 Agent 主动报告状态变化；Announcement 用于广播能力或元信息变更。这个分类看起来简单，但恰恰是协作场景里最常见的四类动作，设计成四种独立消息类型有助于路由策略的差异化，比如事件类消息可以走轻量广播通道，而请求类消息需要可靠的送达确认。
3.3 能力协商层：跨 Agent 的动态契约
能力协商层是 Agent 网络协议和其他传统通信协议差异最大的一层。传统协议里，接口契约是提前定义好的，一次调用就是按文档传参数；但在 Agent 网络里，双方的能力边界本身就可能漂移——某一方今天新增了一个工具，或者某个模型下线了，如果不动态感知，代码不会报错，但协作结果会悄悄变差。ANP 将“能力描述”（Capability Descriptor）作为协议的一等公民，通过它实现能力的注册、发现、匹配与协商。
协商过程一般走这样一条链路：第一步，Agent 在接入目录服务时注册自己的能力描述，描述里包含能力名称、输入参数 Schema、输出参数 Schema、语义标签和 QoS（服务质量）说明；第二步，当某个 Agent 需要某项能力时，向目录服务发出查询，目录服务返回所有注册了该能力的 Agent 列表；第三步，请求方与候选方交换扩展的协商消息，敲定参数约束和执行条件；第四步，执行完后通过响应消息返回结果。整个过程有点类似服务网格里的流量管理，但增加了语义匹配这一步，使 Agent 不再依赖无意义的方法名，而是通过结构化描述来互相理解。
三层架构之间并不是严格串行关系。一个高频率的协同场景里，能力协商可能只在首次建立会话时执行一次，后续消息直接走语义路由层；而当目录发生变化时，公告消息可以反向触发能力协商的刷新。这种分层与联动并存的设计，让协议既能做到轻量转发，也能做到智能匹配。
4. 核心机制拆解：寻址、会话、信任与目录刷新
协议光有框架不行，落地要靠各个机制细节。这一部分我会拆解四个核心机制：Agent 如何被找到、会话如何在不确定网络中维持、信任如何建立、目录如何保持新鲜。这四件事是任何 ANP 实现都必须认真处理的硬骨头。
4.1 寻址：用长期身份绑定短期端点
Agent 的寻址过程我习惯这么理解：每个 Agent 注册时获得一个不可变的 Agent ID（建议使用统一的 Key 对生成自签名标识），同时它要维护一条“ID → 当前 Endpoint”的动态映射。消息发出前，发送方本地缓存里若有目标 ID 的映射就直接使用；没有或过期，就向目录服务查询。整个过程应当对应用层尽量透明，发送方只需要知道目标 Agent ID，最多加一个版本号约束。
这里有一个容易踩坑的细节：Agent ID 本身不要携带位置信息。如果 ID 里包含域名、IP 或者云厂商前缀，Agent 一迁移，ID 就失效了。正确的做法是 ID 只承载一个全局唯一且可验证的身份标识，例如基于公钥的 DID 风格标识，位置永远通过映射在运行时解决。白皮书草案虽然还没有把 ID 规范细化到格式级，但从架构意图看，长期身份和短期端点分离是明确方向。我自己在实际系统里就是这么处理的：Agent 的 DID 对外永远不变，每个部署实例把当前 endpoint 上报到目录，客户端查询后缓存在本地，配合 TTL 过期，既能减少目录压力，也能容忍 Agent 位置漂移。
4.2 会话管理：为“思考型”节点设计的状态机
分布式系统里的会话管理通常依赖心跳超时：服务端 N 秒没收到心跳就判定节点失联。这套思路拿到 Agent 场景会误杀一大片——一个 Agent 可能正在执行一个长达几十秒甚至几分钟的工具调用链，期间它不会像传统服务端那样高频发送心跳，但它绝对不是宕机了。ANP 草案需要定义一种更宽容的会话状态机。
我的理解是，会话应当区分“连接状态”和“活动状态”。连接状态由传输层保障，比如 WebSocket 的通断；活动状态则用“事务时间窗口”来度量，只要某个已分配的任务还在约定的截止时间内，会话就算活跃，不依赖每几秒一次的心跳。同时协议应该支持显式的暂停与续期指令：Agent 在执行长任务前发送 Pause 消息，完成后发送 Resume，避免对方因为等待超时误判。这条设计对真实的 Agent 系统很有价值，否则你永远会在生产环境里看到“对方明明是正常思考，却被判了死刑”的奇怪事故。
4.3 信任体系：签名、令牌与最小化披露
没有信任，Agent 之间不敢真正把关键任务互相委托。信任机制在 ANP 里主要体现在三条链路：身份验证、消息完整性和授权边界。身份验证依赖公私钥体系，每个 Agent 用自己的私钥对发出的每条消息签名，接收方用对方公钥验签；消息完整性由签名覆盖 Envelope 关键字段和 Payload 哈希来保证。这一步能有效防止消息在中间节点被篡改。
授权则是另一套逻辑。即使确认了消息来自合法的 Agent 身份，也不能默认它拥有所有权限。草案倾向于在握手阶段交换权限令牌（Token），令牌里写明调用哪些能力、访问哪些数据域、有效期多长。为了减少隐私泄露，令牌应该支持最小化披露原则——请求方只需要拿到能完成当前任务的最小范围和最短有效期，而不是一层不变的全局授权。用现实类比的话，这就像你请人帮忙代收快递，只需要给他留一个取件码，而不是把家门钥匙也一起给他。白皮书草案在这个方向上的设计思路，基本符合当前安全体系的共识，但距离完整落地还需要一系列规范细节的填充。
4.4 目录服务与信息新鲜度：避免“目录里活着、现实中已死”
目录服务是 Agent 网络的心脏，也是最容易出性能问题的节点。如果每个 Agent 的状态变更都立刻同步给全网络，规模一大必然爆炸。草案里的一个核心思路是“带 TTL 的注册 + 主动查询 + 事件订阅”三者结合：注册信息自带有效期；查询方需要自行承担过期风险，必要时查询后立即调用；对于高频协作者，可以建立订阅关系，目标状态变更时实时推送增量事件。
这个机制和文件名解析的思路很像。你本地缓存某个 Agent 的端点地址，但它可能已经迁移，于是你留了过期时间；如果你和它正在协作，你订阅它的状态变更，一有迁移就刷新本地缓存。成熟的实现还会设置一个降级逻辑：如果目录服务暂不可达，本地缓存中的旧信息依然允许使用，只是消息头会打上 staleness（陈旧度）标记，接收方可以判断信息的可靠程度。这套设计考察的是实战经验，白皮书草案里也许只占了小篇幅，但我觉得它是整个网络能否支撑大规模 Agent 场景的关键。
5. 能力发现与运行时协商：从 RPC 调用升级为结构化共生
如果协议只做了寻址和消息传输，那它本质上还是一个加了签名的消息中间件。真正让 ANP 区别于传统 RPC 的，是能力发现与运行时协商这套机制。它让智能体之间的协作从“调用一个写死的接口”变成“实时地理解对方能干什么、怎么配合”。
5.1 能力描述：给智能体做一张规范“简历”
能力描述更像一份结构化的 Agent 简历。我先拆几个字段：能力名称，用于机器可读的索引；输入 Schema 和输出 Schema，数据结构的校验标准；语义描述，用自然语言和标签向其他系统解释能力的用途；约束条件，包括执行环境、费用上限、响应时间等；变体版本，同一能力在升级时可以兼容旧版调用。能力描述的目的是让别的 Agent 不依赖人工文档就能评估“找你办事行不行”，所以字段的设计需要同时兼顾人类可读与机器可写。
举一个我实际碰到过的例子：一个检索 Agent 老版本只能提供“按关键词搜文档”的能力。后来它升级成了“语义检索 + 摘要生成”的新能力，老契约依然保留。如果只升级但不更新能力描述，其他调用方只会按旧方式调用，发挥不了新能力；而 ANP 的目录通知机制使其向相关方广播了一份新的事件，其他 Agent 收到后更新本地缓存，下次匹配时就能按新 Schema 来协商。这个机制保证了能力升级对现有协作关系的平滑兼容。
5.2 匹配与协商：不止是找交集
匹配阶段是请求方与目录服务的交互。请求方提交自己的需求描述，目录服务将需求 Schema 与已注册的能力 Schema 做结构兼容性对比，再结合语义标签做相关性排序，返回候选 Agent 后，请求方再用协商消息与候选者逐个确认，最终选定执行方。
这里容易产生一个误区：只知道找 Schema 交集，忽略约束条件。举个生活中的例子，一个人找“能修漏水水管的师傅”，从能力上，任何一个水管工都匹配；但加上“今天下午三点能上门、预算不超过 200 元”这两个约束后，候选范围立刻骤降。Agent 能力协商也一样，Schema 只是能力的“形”，约束才决定能力的“用”。协议层面的参数尽量把这种约束显式化，避免双方到执行阶段才发现根本不在同一页面上。
5.3 任务协同与反馈闭环：让协作能自我修复
能力协商成功之后，进入真正的协同执行阶段。一个复杂任务往往会被分解成多个子任务，交给不同 Agent 执行，再由发起方汇总结果。ANP 为此引入了“任务上下文”的概念，可以理解为一次协作会话内共享的状态结构。各参与方通过上下文同步进展，哪一步失败了，可以精确回溯到负责的 Agent 并重新发起请求。
这个设计给现实带来的好处很明显：之前做过多 Agent 协作的人都经历过“RPC 返回了，但结果是错的”的状态，又难追踪是哪个 Agent 已生成错误信息。任务上下文允许所有相关方基于同一份信息做判断，还能利用信息衰减的策略处理过期中间结果，不让旧数据污染后续决策。草案的最终形态不一定完全照此实现，但它在设计基调上强调了这种面向可观测性和可恢复性的思路，是纯调用包的理念根本没法覆盖的。
6. 草案阶段的热点议题：性能成本、恶意攻击与标准化路线
老实讲，现在这份“技术白皮书（草案）”离行业标准还有距离。它有价值的地方在于已经明确画出了技术路线，同时也让我们看清了哪些问题接下来必须下狠功夫。这一章我会聊一聊草案阶段最受关注的三个议题。
6.1 协议开销：每一层信任都要用性能来换
加签名、加令牌、加 Schema 校验、加任务上下文，这些都是有成本的操作。我做个粗略计算：一个简单的任务请求消息，如果携带完整的签名、时间戳、上下文快照，Payload 大小可能比普通 JSON 调用膨胀 30% 到 100%；对于高频工具调用，这个膨胀比例不可忽略。草案的思路是把大量开销前置到握手和协商阶段，一旦协商完成，后续的批量消息可以通过复用会话参数来降低附加信息。这个设计方向是对的，但实际生产环境还需要更细化的压测指标。比如单台 Agent 网关能够承受多少并发签名验证，目录服务在高频注册刷新时会不会成为瓶颈，这些问题都应该出现在配套的性能白皮书里。
6.2 面对恶意 Agent：信任建立之后还需要持续免疫
身份认证解决的是“你是不是你”，但没有彻底解决“你是不是好人”。恶意 Agent 可能注册合法身份之后，用高并发请求对网络进行洪水攻击；也可能注册一个看起来正常、实际执行时返回伪造数据的能力，毒害依赖它的 Agent。草案阶段的安全体系需要向前一步，引入基于行为的信誉机制：每次协作完成后，参与者之间可以交换评价信号，构成全局信誉视图。在早期阶段，信誉机制又会引发“刷分”和“陷害”的新问题，所以我说这不单纯是代码问题，而是一个既涉及博弈论又涉及工程权衡的大课题。白皮书草案现在只是指出了方向，离真正实现还有很长的路要走。
6.3 标准化路线：草案如何走向真正的行业标准
一份草案的价值，很大程度要看它能不能获得生态支持。从草案走向标准，至少需要经过这样几步：第一步是公开细则，让大家能逐行审查；第二步是参考实现，用代码验证协议可行性，并留出兼容性的回旋余地；第三步是互操作测试，让不同团队各自实现的 Agent 网关互相拉通，这是协议设计最残酷也最有效的检验；最后是形成文档化 RFC 流程。目前草案阶段还有不少字段处于开放讨论状态，但它的分层架构和明确边界已经为演进留了余地，我认为这是它最可能成功落地的结构性基础。
7. 一个最小可运行的接入思路：从零把一份草案变成能跑的链路
最后从实践出发，我想说说如果现在就想基于草案搭一个最小链路，应该从哪儿下手。不需要完整实现全套协议，只需要把最小闭环跑通：Agent 身份创建、目录注册、消息收发、签名校验。
第一步，创建 Agent 标识。可以用一个密钥对生成工具，生成公私钥对，将公钥哈希作为 Agent ID。第二步，启动一个目录服务实例，维护 Agent ID 到当前 Endpoint 的映射。第三步，Agent A 启动时向目录注册自己的 Endpoint 和能力描述，能力描述先写一个简单的 JSON Schema，比如“echo”能力。第四步，Agent B 向目录查询所有拥有 echo 能力的 Agent，获取 A 的 Endpoint，然后构造一个 ANP Request 消息，Envelope 里填发送者、接收者、类型、时间戳和签名。第五步，A 收到后验签、解析 Payload、把结果封装成 Response 返回。到此，一个最小链路就走通了。
在这个阶段，需要特别注意的事情有三件。一是签名算法选型要统一，最好在协议细则里直接指定默认算法，否则不同实现连验签都做不了；二是时间戳要统一用 UTC 且带精度约定，否则你会发现在分布式环境下，两个 Agent 的时间差会让消息重放检测形同虚设；三是本地缓存与 TTL 策略要先行，避免每个请求都打穿目录服务，这点在很早就会成为瓶颈。
如果你看完草案想动手实现，我的建议是先选一个你最熟悉的框架，在消息封装层之上做适配，不要直接改造框架内部。这样协议演进不会伤到你的业务代码，而协议的收益也最容易直观看见——真正跨平台调用、多语言互联，你会感受到一种终于把各说各话的智能体拉到同一张桌子上的踏实感。
我不确定最终的标准会收敛成什么样，但有一点我很确定：Agent 网络要想走向真正的规模化和商业化，彼此之间必须有一份能被所有人共同遵守的协议。这份草案不一定就是最终答案，但它已经在正确的方向上走出了非常关键的第一步。在这个阶段参与进去、把真问题暴露出来，比等到一切尘埃落定再追赶要明智得多。
