ANP协议是什么?当Agent多到管不过来的时候,你需要一个“Agent黄页“

发布时间:2026/10/16 0:14:17
ANP协议是什么?当Agent多到管不过来的时候,你需要一个“Agent黄页“
ANP协议是什么当Agent多到管不过来的时候你需要一个Agent黄页写在前面MCP和A2A我们都聊过了——MCP解决Agent怎么用工具A2A解决Agent怎么跟Agent说话。但随着你做的系统越来越大会遇到一个新问题Agent太多了根本管不过来。想象一下你的公司里部署了50个Agent分别负责客服、销售、财务、人事、研发……每个Agent都有自己的地址和能力。新来的Agent想找一个能处理退款的Agent怎么找总不能把50个Agent的地址都硬编码进去吧这就是ANPAgent Network Protocol要解决的问题。如果说MCP是USB接口、A2A是人与人沟通的语言那ANP就是公司的通讯录组织架构——它帮你在庞大的Agent网络里找到你需要的那个Agent。今天这篇文章我就来聊聊ANP的设计目标——它要解决什么问题跟MCP/A2A是什么关系以及为什么说它是Agent规模化的关键。一、从一个真实的痛点说起我先讲一个自己项目里的真实经历你就能明白ANP的价值了。我们团队做了一个企业内部的Agent平台一开始只有3个Agent大家相安无事地址写在配置文件里就行。后来业务扩张Agent数量一路涨到了20多个问题就来了问题1新增Agent要改一堆配置。每加一个Agent所有可能调用它的Agent都要更新配置加上它的地址和能力。有一次我们加了一个新的发票处理Agent忘了告诉财务Agent结果财务Agent还是走老流程手动处理发票过了一周才发现。问题2Agent地址变了全链路崩。有个Agent迁移了服务器IP地址变了。结果五六个依赖它的Agent全部调用失败报警邮件炸了邮箱。我们花了半天时间一个个去改配置、重启服务。问题3不知道哪个Agent能做什么。新人接手项目的时候完全搞不清楚这20多个Agent分别是干嘛的。得一个个去看代码、问同事效率极低。有一次两个团队同时做了合同审查Agent功能高度重叠浪费了不少人力。问题4负载均衡无从谈起。客服Agent高峰期扛不住想部署多个实例分流但调用方都是直连单个地址的根本没法做负载均衡。只能垂直升级配置成本越来越高。问题5没有统一的监控和治理。哪个Agent在跑、哪个挂了、哪个调用量最大、哪个响应最慢……全靠人肉监控。出了问题排查半天才发现是某个Agent内存泄漏挂了。这些问题本质上都是Agent网络的治理问题。MCP和A2A解决的是通信的问题但没有解决发现和组织的问题。当Agent数量从个位数涨到几十、几百个的时候没有一套服务发现和治理机制系统就会陷入混乱。ANP就是为了解决这些问题而生的。二、ANP要解决的核心问题搞清楚了痛点ANP的设计目标就很清晰了。我总结了一下ANP主要解决这几个核心问题1. 服务发现Service Discovery这是ANP最核心的功能。Agent启动时向网络注册自己的信息名称、能力、地址、状态其他Agent需要某种能力时可以通过ANP搜索和发现对应的Agent。就像你手机里的通讯录——你不需要记住每个人的电话号码只需要知道名字搜一下就能找到。2. 能力匹配Capability MatchingANP不只是按名字找Agent还支持按能力搜索。比如你可以问“我需要一个能处理PDF文件的Agent”ANP会返回所有具备这个能力的Agent列表。这比按名字查找更灵活——你不需要知道Agent叫什么只需要知道你需要什么能力。3. 健康检查和自动摘除Health CheckANP会定期检查注册的Agent是否还活着。如果某个Agent挂了自动从注册列表里摘除这样其他Agent就不会再调用一个已经死掉的服务。这解决了上面说的地址变了全链路崩的问题——调用方不需要关心目标Agent的具体地址和状态ANP会自动路由到健康的实例。4. 负载均衡Load Balancing当同一个能力有多个Agent实例时ANP可以做负载均衡——轮询、随机、按权重、按响应时间……把请求分散到多个实例上。这解决了客服Agent扛不住的问题——你可以部署10个客服Agent实例ANP自动把流量分散开。5. 路由和转发Routing Forwarding在复杂的Agent网络里两个Agent可能不在同一个网络不能直连。ANP可以作为中间层帮它们转发消息。就像互联网里的路由器——你不需要直接连到目标服务器通过路由器一层层转发就能到达。6. 元数据和治理Metadata GovernanceANP还可以存储Agent的元数据——版本号、负责人、SLA、调用统计、安全等级等。有了这些数据你就能做统一的监控、审计、权限控制。这六个问题是Agent规模化之后必然会遇到的。ANP相当于给Agent世界建了一套基础设施让大规模的Agent网络成为可能。三、ANP跟MCP、A2A的关系很多人会问有了MCP和A2A为什么还要ANP它们三个是什么关系我的理解是它们解决的是不同层面的问题是互补关系不是竞争关系。用一个类比来说明MCP相当于电器的电源插头标准。它定义了Agent怎么连接和使用外部工具电器。有了MCP任何Agent都能插上任何工具。A2A相当于人与人之间的沟通语言。它定义了Agent之间怎么对话、怎么协作、怎么委托任务。有了A2A任何Agent都能跟任何Agent说话。ANP相当于城市的交通系统通讯录。它定义了在一个庞大的Agent网络里怎么找到你要找的Agent、怎么把消息送到它那里。有了ANPAgent网络才能规模化。再换一个角度从OSI网络模型的思路来看MCP在应用层——具体的工具调用A2A在会话层——Agent之间的对话和协作ANP在网络层——寻址、路由、发现三层各司其职共同构成了完整的Agent通信协议栈。在实际系统中三者经常配合使用Agent通过ANP发现需要的目标Agent通过A2A跟目标Agent建立对话、委托任务目标Agent在处理任务时通过MCP调用外部工具你看一个完整的Agent工作流可能同时用到这三个协议。它们不是三选一而是组合使用。四、ANP的设计理念了解了ANP要解决的问题我们再看看它的设计理念。我觉得ANP有几个核心设计原则很值得品味原则1去中心化优先但支持中心化部署ANP的设计倾向于去中心化——Agent之间可以直接互相发现和通信不依赖一个中心服务器。但同时也支持中心化的注册中心部署方式方便企业内部统一管理。这种设计很务实。完全去中心化在公网环境下更有韧性但企业内部往往需要中心化的管控。ANP两种都支持用户可以根据场景选择。原则2能力驱动而不是身份驱动ANP的发现机制是按能力查找而不是按名字查找。你不需要知道Agent叫什么只需要描述你需要什么能力。这让Agent网络更灵活——新增一个同能力的Agent调用方不需要任何改动就能用上。这跟微服务领域的接口驱动思路是一致的——服务消费者依赖的是接口契约而不是具体的服务实例。原则3轻量级可嵌入ANP被设计成轻量级协议可以嵌入到现有的Agent框架里不需要单独部署一套重型基础设施。你可以用Redis、etcd、Consul等现成的服务发现组件做后端也可以用ANP自己的轻量实现。原则4安全内置Agent网络的安全很重要——不能随便一个Agent都能发现和调用你的Agent。ANP内置了身份验证、权限控制、访问审计等安全机制确保Agent网络是可信的。原则5跟现有协议兼容ANP不试图替代MCP和A2A而是跟它们无缝配合。ANP负责发现和路由发现之后的通信用A2A工具调有用MCP。这种不重复造轮子的设计思路我很欣赏。五、ANP的核心概念最后简单介绍一下ANP的几个核心概念为后面的实战做铺垫1. Agent ProfileAgent档案每个Agent在ANP中注册时会提交一份档案包含基本信息名称、描述、版本能力列表这个Agent能做什么接入信息地址、支持的协议A2A/MCP等状态信息是否在线、负载情况元数据负责人、SLA、安全等级等2. Capability能力能力是ANP中发现Agent的基本单位。每个Agent声明自己具备哪些能力其他Agent按能力查找。能力可以有层级和分类比如文档处理.PDF解析、“数据分析.图表生成”。3. Registry注册中心注册中心是ANP的核心组件存储所有Agent的档案提供搜索和查询功能。可以是中心化的服务器也可以是去中心化的P2P网络。4. Router路由器路由器负责在Agent之间转发消息。当两个Agent不能直连时通过路由器中转。路由器还可以做负载均衡、流量控制、熔断降级。5. Discovery Query发现查询Agent查找其他Agent时使用的查询语句可以按能力、名称、标签、元数据等多维度筛选。比如查找所有具备’发票处理’能力、在线、响应时间小于500ms的Agent。这几个概念是ANP的基石后面讲实战的时候会详细展开。六、我的一些思考研究ANP的过程中我有几个感受比较深第一Agent的规模化一定会催生基础设施层。回顾互联网的发展历史一开始只有几台服务器直接IP访问就行服务器多了有了DNS再后来有了负载均衡、服务网格、CDN……每一次规模化都会催生新的基础设施。Agent领域也在走同样的路。现在大部分人还在做单Agent或少量Agent的应用感觉不到ANP的必要性。但等Agent数量涨到几十、几百个的时候服务发现和治理就会成为刚需。ANP就是在为这个未来做准备。第二协议的分层很重要。MCP、A2A、ANP三个协议各管一层这个设计很清晰。如果试图用一个协议解决所有问题结果往往是哪个都做不好。分层让每个协议可以独立演进也让用户可以按需选用——只需要工具接入就用MCP需要Agent协作就加A2A需要规模化治理再加ANP。第三ANP目前还很早期。说实话ANP目前的成熟度远不如MCP。规范还在快速变化可用的实现不多生态也很小。大部分人现在做的Agent系统用硬编码配置或者简单的注册中心就够了还不需要完整的ANP。但我觉得关注ANP是有价值的——它代表了Agent网络的未来方向。等你的系统真的需要规模化的时候ANP可能已经成熟了到时候直接用上就行。写在最后ANP可能是三个协议里最不接地气的一个——MCP你今天就能用上A2A做稍微复杂点的多Agent系统也能用上但ANP大部分人短期内可能都用不上。但理解ANP的设计目标依然很重要。它让你看到Agent技术的完整图景——不只是单个Agent怎么聪明还包括大量Agent怎么组织、怎么协作、怎么治理。当你在设计系统的时候能想到以后Agent多了怎么办就能提前做好架构上的准备。这篇文章是10.4节的第一篇主要讲了ANP的设计目标和核心概念。下一篇我们会进入实战看看怎么用ANP做服务发现让Agent自动找到彼此。你们的系统里现在有多少个Agent是怎么管理它们的地址和能力的有没有遇到过Agent太多管不过来的问题欢迎在评论区聊聊。下一篇预告使用ANP服务发现。我们会动手搭建一个ANP注册中心让Agent自动注册和发现体验一下Agent黄页是怎么工作的。