【深度收藏】大模型智能体通信协议完全指南：从MCP到ANP的全方位解析

关注

原创最新推荐文章于 2026-04-21 07:45:00 发布 1.6k 阅读 AI 写同款· GEO 优化 ›

开源智能体通信协议对比分析：MCP、ANP、Agora、agents.json、LMOS、AITP 在智能体通信协议开发的过程中，我收集了行业已经出现的智能体通信协议，并且使用OpenAI的deepresearch，对协议的目标问题、关键技术、适用场景、技术架构、兼容性与扩展性、开源与生态以及未来发展前景等方面进行分析。我们去年初就启动了开源智能体通信协议的设计与开发工作，作为最早在这个领域研究的团队，我们能够十分明显的感受到，最近两三个月，这个领域正在受到越来越多的人的关注。欢迎关注我们的开源项目，加入我们的开源社区，无论你是个人开发者，还是人工智能领域的公司，我们都十分的欢迎。阅读详情

本文详细解析了11种智能体通信协议，包括MCP、A2A、AG-UI、ANP等，这些协议解决了智能体与外部工具交互、智能体间通信及与用户界面交互的标准化问题。这些协议构建了智能体互联网的基础设施，使不同框架、不同组织的智能体能够协同工作，形成有机网络。未来智能体互联网将是一个无边界、自进化的智能协作网络，人类与智能体共同主导的高效、可信、普惠的数字新生态正在形成。

MCP协议

过去，电脑需要多种硬件接口（如USB、HDMI等）连接不同设备，直到USB-C出现，凭借统一标准解决了设备互联的复杂性。MCP就像是AI世界的USB-C接口，为AI系统与外部工具搭建了标准化的数字桥梁，使大模型能够通过统一规范与数据库、API等动态交互。

MCP——AI世界的USB-C接口

MCP全称Model Connection Protocol，是一种模型上下文协议，旨在为AI与工具之间的通信创建一个标准化框架，减少对专有集成的依赖，并提高AI应用之间的模块化和互操作性。MCP的出现为模型能力拓展提供了一个标准的协议接口。该协议由Anthropic开发，最初是为了突破Claude模型与外部系统交互的局限性。2024年初，Anthropic选择开源MCP，以鼓励整个行业采用。

MCP采用客户端-服务端（C/S）架构。AI应用作为客户端，通过MCP协议向服务端发送请求，服务端提供资源与工具。MCP服务器端直接向客户端公开全部工具与资源列表，客户端将这些信息传递给模型，模型根据需要通过RPC调用特定工具或访问特定资源。MCP核心组件包括：

Host（主机端）：MCP主机端是诸如Claude Desktop、IDE或希望通过MCP访问数据的AI工具等程序。这些应用程序为用户提供与LLM交互的接口，同时集成MCP客户端以连接MCP服务器，从而利用MCP服务器提供的工具扩展LLM能力。

MCP 主机端示意图

Client（客户端）：连接LLM和MCP服务器的桥梁，嵌入在LLM中，主要负责接收来自LLM的请求；将请求转发到相应的MCP服务器以及将MCP服务器的结果返回给LLM。

MCP 客户端示意图

Server（服务器）：专为LLM提供工具调用与数据访问能力的程序。与传统的远程API服务器不同，MCP服务器既可作为本地应用程序在用户设备上运行，也可部署至远程服务器。

每个MCP服务器都提供了一组特定的工具，负责从本地数据或远程服务中检索信息。当LLM在处理任务时确定需要调用某个工具时，即可通过MCP服务器提供的工具获取必要数据并返回至大模型。

MCP 服务器示意图

以上组件最终构成了基于MCP的AI应用。

基于MCP的AI应用

MCP所有消息传输均采用 JSON-RPC 2.0 格式，支持请求（Request）、结果（Result）、错误（Error）和通知（Notification）等消息类型。其交互流程如下：

初始化：客户端发送初始化请求，与服务器协商协议版本和能力。
能力发现：客户端请求服务器提供的工具、资源和提示，服务器返回相应列表。
调用执行：客户端根据需求向服务器发送调用请求，例如调用API或执行特定任务。
结果返回：服务器完成操作后，将结果返回客户端，供Host应用进一步处理。

MCP交互流程

协议网站：https://modelcontextprotocol.io/

代码网址：https://github.com/modelcontextprotocol/

A2A协议

在Google Cloud Next 2025大会上，谷歌正式宣布开源A2A（Agent-to-Agent）协议，这是全球首个标准化的AI智能体交互协议，旨在打破不同AI系统间的壁垒，让来自不同供应商、框架的智能体能够无缝协作。该协议已获得Atlassian、Salesforce、SAP、MongoDB等50余家科技巨头的支持，被视为AI智能体生态发展的关键里程碑。

A2A主要解决智能体间通信在用户、企业交互上的主要挑战，主要功能特性如下：

A2A功能特性

1.能力发现与动态服务匹配

通过标准化的智能体卡片（Agent Card）机制实现智能体能力的公开与发现。每个智能体以JSON格式描述自身功能，包括名称、技能列表、认证需求、支持的内容格式等。如此一来，客户端智能体便能精准识别出最适合执行特定任务的智能体，并通过A2A协议与远程智能体建立通信连接。

2.任务全生命周期管理

A2A协议围绕任务（Task）构建通信模型，支持从短时响应到长期协作的全生命周期管理。每个任务包含明确的状态流转（提交→处理中→需输入→完成/失败），并通过Task对象封装任务ID、参数、当前状态等信息。对于需要长时间执行的任务，协议支持通过SSE（Server-Sent Events）或Webhook实现实时状态更新，确保用户随时掌握进度。此外，任务的输出结果（Artifact）可包含多模态内容，支持复杂场景下的结果交付。

3.多模态协作与用户体验协商

A2A协议不仅限于文本交互，还支持音频、视频、网页表单等多种内容形式。智能体间通过Message对象传递上下文、指令或结果，每个Message由多个“Parts”组成，每个Part定义内容类型（如text/plain、application/html）。协议允许双方协商最适配的输出格式，这种灵活性确保了协作过程的自然性和用户体验的优化。

4.安全与认证机制

A2A协议内置企业级安全设计，支持OAuth2、JWT、API Key等多种认证方案，确保通信的安全性。所有数据默认通过TLS加密传输，并通过Agent Card声明认证需求，客户端需在协议外获取凭证（如Token）并通过HTTP头传递，而非直接内嵌在消息体中。此外，协议要求服务器验证每个请求的合法性，对未授权请求返回标准HTTP状态码。这种设计既符合企业合规要求，又避免了敏感信息泄露风险。

A2A是一种灵活的P2P交互方式。一个智能体（客户端Agent）可以直接与一个或多个其他智能体（远程Agent）对话协作，将一个大任务拆解为小任务，与其他智能体共同完成。

A2A交互示意图

A2A交互流程通常如下：

发现与选择：发起任务的客户端智能体首先通过Agent Card获取服务端智能体的能力信息，根据任务需求，选择一个或多个最合适的服务端智能体。这一机制使客户端无需预配置即可动态匹配最优执行者。
任务发起与初始化：客户端通过tasks/send或tasks/sendSubscribe接口启动任务，发送初始用户消息和唯一任务ID。
任务执行与状态同步：服务端智能体接收任务后，进入任务生命周期管理。
状态流转：任务状态从已提交→处理中→已完成或失败，通过SSE实时推送至客户端。
多轮交互：若任务需用户输入，服务端将任务状态设为input-required，并通过Message字段明确需求。客户端补充信息后，任务恢复执行。
多模态交互与内容协商：单次消息可包含文本、文件、结构化数据等。根据接收方能力动态调整格式。
结果交付：任务完成后，服务端智能体返回Artifact，客户端智能体校验产物完整性，确认无误后触发后续流程。若任务失败，服务端智能体返回failed状态及标准化错误码，客户端智能体可通过task/get接口查询详细原因并触发重试机制。

协议网站：https://www.a2aprotocol.org/

代码网站：https://github.com/a2aproject/A2A

AG-UI协议

AG-UI（Agent-User Interaction Protocol）是2025年5月由CopilotKit团队发起并开源的协议，旨在解决AI智能体与前端应用之间的交互标准化问题，提供一个轻量级、事件驱动的开放协议，实现AI智能体与用户界面的实时双向通信。

在AG-UI出现之前，AI智能体与前端的交互普遍存在“三难”问题：其一，接口碎片化，LangGraph、CrewAI等不同智能体框架的输出格式各异，前端需为每个框架开发专属适配代码，开发效率低下；其二，状态不同步，智能体执行长时任务时，前端只能通过轮询获取进度，不仅浪费资源，还无法及时反馈任务卡壳等异常；其三，交互僵硬，工具调用、参数调整等操作需跳转页面或刷新界面，用户无法在同一上下文完成协作，体验割裂。

AG-UI协议的出现主要是为了解决智能体与前端应用之间的交互标准化问题，通过定义统一的事件类型、传输规则与适配层工具，让智能体的行为能被前端读懂，前端的操作能被智能体响应，最终实现智能体处理过程可见、用户干预实时生效、多端状态无缝同步的协作效果。

AG-UI核心架构由三个主要组件构成：前端应用层、协议中间件层和AI智能体后端。

AG-UI 核心架构

Application（应用程序）：用户直接交互的前端界面（如网页、移动端App），通过AG-UI客户端与后端智能体通信。
AG-UI Client（通信客户端）：负责与智能体建立连接，发送用户输入并接收事件流，支持多种传输协议（如SSE、WebSocket）。
Agent（后端智能体）：处理用户请求，生成响应事件，可基于不同框架（如LangGraph、CrewAI、LlamaIndex）实现。
Secure Proxy（安全代理）：提供身份认证、加密通信和访问控制，确保交互安全。

其交互流程如下：

客户端通过POST请求发起一次AI Agent会话；
建立HTTP流，如SSE或WebSocket等协议，实现事件的实时监听与传输；
每个事件都包含类型和元信息Metadata，用于标识和描述事件内容；
AI Agent持续以流式方式将事件推送至UI端；
UI端根据收到的每条事件，实时动态更新界面；
同时，UI端也可以反向发送事件或上下文信息，供AI Agent实时处理和响应；

AG-UI交互流程

AG-UI采用协议层 - 传输层 - 适配层的分层架构，既保证了核心逻辑的标准化，又为不同技术栈提供了灵活的适配空间，避免了一刀切的设计局限。

协议层是AG-UI的核心，通过多种标准化JSON事件类型，覆盖从任务启动到结果交付的全流程，确保智能体与前端的语言统一。这些事件可分为生命周期事件、内容交互事件、工具调用事件以及状态管理事件四大类。

传输层负责事件的传递通道，支持三种主流通信方式，可根据场景灵活选择。Server-Sent Events（SSE）适用于智能体向前端单向推送事件的场景，如任务进度更新、文本内容流式生成，无需前端频繁请求，降低资源消耗；WebSocket提供双向实时通信能力，适合需要用户干预的复杂场景；Webhook用于异步通知，当智能体完成耗时较长的任务后，通过Webhook向前端指定地址发送结果，避免前端长时间等待。

为让不同技术栈的开发者快速接入，AG-UI在适配层提供了完善的工具链。后端SDK支持Python与TypeScript，可将LangGraph、CrewAI等智能体框架的输出，自动映射为AG-UI标准事件流，开发者无需手动构建事件结构；前端工具提供React Hooks组件库，封装了事件订阅、状态管理、UI渲染等核心逻辑。

协议网站：https://docs.ag-ui.com/

代码网址：https://github.com/ag-ui-protocol/ag-ui

ANP协议

ANP（Agent Network Protocol）是一种开源智能体通信协议，由国际人工智能联盟（IAIC）主导开发，于2024年底正式发布。ANP旨在成为智能体互联网时代的HTTP协议，为数十亿智能体构建开放、安全、高效的协作网络，重新定义机器间的交互规则。

ANP 协议的三层架构

ANP采用三层架构设计，确保了智能体能够在互联网上自主寻找彼此，安全建立连接，并有效交流。

最底层是身份与加密通信层，基于W3C的去中心化身份标识（DID）标准，实现分布式的身份认证和端到端加密通信，解决“我是谁”和“如何安全通信”的问题。每个智能体拥有独一无二的DID，就像数字世界的护照，使其能够独立验证其他智能体的身份，无需依赖第三方授权服务器。

中间层是元协议层，负责智能体间动态协商具体的通信协议，解决“如何协商通信方式”的问题。当两个智能体建立连接后，会通过元协议商量使用什么语言和格式交流，使网络具备自适应、自协商的能力。

最上层是应用协议层，基于语义网技术实现智能体能力的描述与高效交互，解决“提供什么功能”和“如何被发现”的问题。智能体通过标准化的描述文档公布自己的功能清单和支持的接口，类似于交换电子名片。这使得智能体不仅能传输数据，还能理解数据的语义，实现更高级的协同决策。

与A2A的企业级中心架构、MCP的客户端 - 服务器模式不同，ANP坚持纯P2P架构，任意两个智能体都可直接对等连接，彼此既能发起请求也能接收请求，无需依赖中心服务器中转。这种设计使网络具备极高的弹性和可扩展性，单个节点的故障不会影响整个网络的运行。在跨机构、跨地域的智能体协作场景中，如智慧城市的交通管理系统，这种架构能有效避免单点故障风险，提高系统可靠性。

ANP协议点对点通信

ANP交互流程主要包括以下几个步骤：

ANP交互流程

智能体发现：搜索引擎通过智能体发现机制爬取智能体B的信息，包括其描述文档URL、名称等基本信息。
智能体搜索：智能体A通过搜索引擎找到智能体B的描述文档URL。这一步使得智能体能够在不知道对方具体域名的情况下，通过语义搜索找到合适的服务提供者。
身份验证请求：智能体A使用自己的私钥对请求进行签名，并携带自己的DID标识符，向智能体B请求描述文档或服务。签名确保了请求的真实性和完整性。
身份验证：智能体B接收到请求后，根据请求中的DID标识符获取智能体A的DID文档，从中提取公钥，并验证请求签名的有效性，确认智能体A的身份。
服务交互：身份验证通过后，智能体B返回请求的数据或服务响应。智能体A根据返回的数据完成任务，如预订酒店、查询信息等。整个过程基于标准化的接口和数据格式，确保了跨平台互操作性。

协议网站：https://www.agent-network-protocol.com/zh/

代码网址：https://github.com/agent-network-protocol/

AGNTCY项目

AGNTCY项目由思科旗下Outshift团队孵化，团队意识到AI智能体正处于孤立开发、无法跨组织协作的状态，基础设施存在关键缺口，这些问题阻碍了智能体实现规模化协同。AGNTCY项目通过开放、通用的基础设施，为开发者和组织提供安全的智能体身份、可靠的消息传递和端到端的可观测性，提升透明度、性能、效率和信任度。

2025年3月，Outshift联合Galileo与LangChain，在GitHub上正式发布AGNTCY项目，包含完整代码、技术规范与服务；同时搭建了智能体所需的发现、身份认证、消息传递、可观测性四大核心组件，支撑智能体完成相互发现、能力验证、安全协作等关键操作。截至2025年7月，已有超75家企业加入该项目。在此背景下，AGNTCY 被捐赠给Linux基金会，思科、戴尔、谷歌云、甲骨文与红帽成为创始成员。

AGNTCY项目核心组件包括如下九个方面：

AGNTCY项目核心组件

智能体身份：基于去中心化技术，管理和验证“任意组织发布的智能体或工具”的身份，确保交互的安全性与可信度。
开放智能体模式框架（OASF）：基于OCI（开放容器倡议）的可扩展数据模型，用于描述智能体属性并确保其唯一标识。OASF支持描述A2A智能体、MCP服务器，还可扩展适配其他主流格式。
智能体目录：支持通过OASF描述的智能体或多智能体应用进行公告与发现。任意组织均可运行专属目录，并与其他目录同步，共同构成智能体互联网资源清单。该组件支持A2A智能体卡片、ACP智能体清单、MCP服务器描述等多种数据模型。
语义软件开发工具包（Semantic SDK）：支持A2A、MCP和ACP等多种协议。通过输入/输出映射智能体（I/O Mapper Agent）处理需要相互通信的智能体之间的语义数据适配。通过语义路由器（Semantic Router）实现语义匹配引导工作流。
句法软件开发工具包（Syntactic SDK）：智能体连接协议（ACP）定义调用智能体、提供输入、检索输出、获取支持的模式、图拓扑结构及其他有用信息的标准接口。API 桥接智能体用于将智能体与任何API端点（工具或数据源）相连接。人机协作智能体用于无缝衔接人类的输入/输出。
消息传递软件开发工具包（Messaging SDK）：SLIM（安全低延迟交互式消息传递）协议定义了AI智能体之间安全高效的网络级通信标准和指南。SLIM通过规定消息格式、传输机制和交互模式，确保互操作性和无缝的数据交换。SLIM节点和SDK为一组智能体提供便捷的安全网络级通信服务。它扩展了gRPC，除了支持请求/回复、流式传输、即发即弃等交互外，还支持发布/订阅交互。
智能体工作流服务器：部署和监控以各种框架编写的智能体工作流，并通过智能体连接协议使其可用。此类工作流可以是包括工具包智能体、本地智能体和远程智能体的混合。
智能体集成可观测性与评估：支持多智能体应用可观测性和评估的遥测收集器、工具及服务。
智能体集成安全：用于信任和保护多智能体应用程序的工具和服务。

AGNTCY项目运行机理

官方网址：https://agntcy.org/

代码地址：https://github.com/agntcy

ACP协议

ACP（智能体通信协议）是一套用于智能体互操作性的开放协议，旨在解决AI智能体、应用程序与人类之间日益复杂的连接难题。ACP为智能体通信提供了标准化接口，不仅能实现客户端与服务器之间的无缝交互，还支持复杂系统中多个智能体的协同工作。目前ACP协议已成为Linux基金会旗下A2A协议的一部分。

核心组件包括ACP客户端和ACP服务器，可灵活组合部署，单个进程既可以作为服务器（处理入站请求），也可以作为客户端（向其他智能体发起出站请求）。

ACP客户端：可由ACP智能体、应用程序或其他服务使用，这些主体通过ACP协议向ACP服务器发起请求。
ACP服务器：可托管一个或多个ACP智能体，智能体执行请求后，服务器通过ACP协议将结果返回给客户端。ACP服务器的核心作用是通过REST接口将智能体的能力对外暴露。

最简单的ACP部署方式是客户端通过HTTP上的REST接口直接连接单个智能体。此架构模式适用于与单个专业智能体的直接通信、对基础设施需求较低的轻量级部署、开发与调试环境以及概念验证实现。在该架构中，ACP服务器对智能体进行封装并暴露HTTP端点，智能体被调用后，会以标准化的ACP格式返回响应结果。

基础单智能体架构

ACP服务器可在单个HTTP端点后托管多个智能体。每个智能体都能通过服务器的路由机制单独寻址，服务器会根据智能体的元数据确定对应的请求处理器。该架构适用于具有相似资源需求，或存在关联关系、适合协同部署的智能体以及包含多个测试智能体的开发环境。核心优势包括：

资源高效性：共享服务器基础设施，减少资源冗余；
部署简化：仅需管理单个服务，降低运维成本；
集中化管控：支持集中式日志记录与监控；
权限统一：实现一致的身份认证与授权机制。

单服务器多智能体架构

在分布式架构中，ACP客户端可发现并与多个独立服务器通信，每个服务器托管一个或多个智能体。这种架构模式具备以下能力：

高可扩展性：支持对不同类型的智能体进行独立扩容，实现跨多服务器的负载分发以及服务间故障隔离，避免单个服务器故障影响整体系统。
高灵活性：可为不同智能体配置差异化的部署环境，支持技术栈多样性，各智能体的开发与部署周期相互独立，互不干扰。

分布式多服务器架构

高级ACP部署支持面向复杂工作流的多智能体架构，其中“路由智能体”模式是常见设计，由一个中央路由智能体负责以下核心任务：

请求分解：将复杂请求拆分为多个专门的子任务；
任务路由：将子任务分配给对应的专业智能体；
结果聚合：将各智能体返回的子结果整合为连贯的最终结果；
工具调用：不仅可使用自身工具，还能通过MCP扩展调用下游智能体暴露的工具。

高级多智能体编排架构

官方网站：

https://agentcommunicationprotocol.dev/introduction/welcome

代码地址：https://github.com/i-am-bee/beeai-platform

LMOS协议

LMOS（Language Model Operating System）协议由Eclipse基金会推出，目标是为构建智能体互联网铺路，让来自不同组织的AI智能体和工具能轻松发布、发现和互连，打破技术壁垒，形成开放、可互操作的生态系统。

LMOS协议去中心化示意图

LMOS协议受Matter/Thread（实现智能家居设备互联互通）和ActivityPub（实现不同社交媒体网络用户交互）的启发，致力于实现跨平台、跨技术的智能体与工具的交互和协作。通过定义标准化的元数据、数据模型、交互模式和通信协议，消除不同智能体和工具之间的交互障碍。

通过定义标准化的元数据、元数据传播机制、元数据发现流程、数据模型、交互模式及通信协议，LMOS协议实现了六大核心功能，为智能体互联提供全方位支撑：

统一描述格式：用JSON-LD规范智能体/工具的能力与元数据，通过W3C DID签名确保真实完整，实现跨平台互认。
灵活元数据传播：支持本地（DNS-SD/mDNS）、全局（注册表）、去中心化（联邦协议）等多种方式，让元数据高效流转。
全场景发现机制：兼容本地/全球网络，智能体可按需求（如能力、元数据）动态发现合作对象，支持描述文件更新与智能体演化。
去中心化身份认证：基于W3C DID实现智能体/工具的自主身份验证，无需依赖中央机构，提升跨网络信任与安全。
自适应通信协议：不强制固定传输方式，智能体可根据场景自主选择HTTP、MQTT等协议，兼顾效率与适配性。
智能体群组管理：支持群组的创建、维护与解散，建立群内信任关系，强化多智能体协同效率。

为实现上述功能，LMOS协议设计了结构化的三层架构，各层职责明确且相互协同：

LMOS协议三层架构

应用协议层定义智能体与工具的核心交互规则，包括发现机制、智能体与工具描述格式、语义数据模型，以及WebSocket子协议。该层通过标准化元数据确保互操作性，同时支持跨本地与全球网络的动态发现，是智能体交互的业务逻辑中枢。

传输协议层负责定义智能体间通信协议的协商与建立机制，支持多种传输协议。智能体可根据每次交互的需求，动态选择并适配最优协议，在不同网络环境下均能保障通信的灵活性与可靠性。

身份与安全层制定智能体间（尤其是跨平台场景下）安全身份认证与加密通信的标准。除了基于W3C DID的去中心化身份认证方案，还兼容OAuth2、Bearer Token等主流安全机制，构建多层次安全防护体系。

官方网站：https://eclipse.dev/lmos/

代码地址：https://github.com/eclipse-lmos

AITP协议

AITP（Agent Interaction & Transaction Protocol）是一种专为多智能体系统设计的协议，由NEAR基金会提出。它专注于规范智能体之间的复杂交互行为与可信交易流程，特别适用于需要价值交换（如数据、服务、资源交易）的分布式场景。AITP通过标准化交互规则和安全机制，解决了多智能体系统中跨信任边界协作的难题，推动了AI代理在去中心化环境中的高效协作。AITP的核心优势如下：

通用通信能力：任何兼容AITP的智能体，无论由哪家机构开发，均可实现交互。
结构化数据交换：智能体不仅能传递文本，还可共享UI元素、表单及支付请求等复杂信息。
跨信任边界交互：代表不同主体（如个人、企业、机构）的智能体之间，能实现安全可靠的交互。
可扩展功能：通过功能体系可新增交互类型，灵活适配各类场景需求。

AITP主要由聊天线程（Threads）和能力（Capabilities）两部分组成。

线程是智能体之间的主要通信对象，包含对话中交换的所有信息，涵盖消息内容、参与方及其具备的功能。线程支持多方参与，可灵活添加或移除智能体与用户。聊天线程之所以成为智能体交互的理想基石，核心源于普适性理解、灵活性与上下文保持、技术层面优势以及贴合业务逻辑四大优势。

能力（Capabilities）是针对特定场景的标准化消息规范，用于实现结构化交互（如处理支付、共享敏感数据）。智能体或客户端在创建/加入线程时，会主动声明自身支持的能力；线程中的其他智能体可据此调整响应方式，充分利用这些能力提升交互效率。目前，AITP已定义多模态交互、生成式UI、支付集成、人机协同以及跨链交互五大核心能力模块，覆盖主流场景需求。这些能力并非强制集成，智能体可根据自身定位选择支持的模块。例如，政务查询智能体可能仅需多模态交互与人机协同能力，而电商服务智能体则需完整集成生成式UI、支付集成等功能。

上表展示了AITP与其他协议的对比，这些框架和AITP都涉及智能体通信，但AITP专门解决跨信任边界的交互，例如用户智能体与企业智能体对话。

作为开源协议，AITP目前由NEAR AI Hub主导开发，已吸引包括OpenAI、微软、沃尔玛等企业加入生态。AITP协议通过标准化交互流程、可信交易机制和跨信任边界协作能力，为多智能体系统提供了坚实的技术基础。

官网网站：https://aitp.dev/

代码地址：https://github.com/nearai/aitp

NANDA项目

随着AI技术的发展，自主AI智能体数量预计将达到数万亿，它们需在全球分布式、互联互通的环境中执行任务、沟通、推理和决策。但现有的以DNS为核心的网络基础设施，无法满足AI智能体在隐私保护、低延迟解析、可验证信任评估等方面的需求。NANDA（Networked AI Agents in a Decentralized Architecture）项目由麻省理工学院发起，旨在创建一个去中心化、协议中立的生态系统，提供AI智能体所需的索引、协议和工具，解决数十亿AI智能体相互发现、能力验证和任务协调时可能出现的瓶颈和安全漏洞，推动AI智能体互联网的发展。

NANDA架构

NANDA采用多层级栈式架构，每一层均为去中心化智能体协作提供独特且必需的服务。

第一层：加密身份与信任。协议栈的基础是身份体系，NANDA网络中的每个智能体，均通过“公钥/私钥对”拥有加密身份。这一设计使智能体能够对所有消息与行为进行签名，形成不依赖任何中央机构、可验证且无法伪造的身份。

NANDA 网络信任金字塔

第二层：去中心化智能体注册中心。作为智能体网络的DNS，NANDA包含一套去中心化注册系统。它将唯一智能体名称映射到名为AgentFacts的结构化元数据。该注册中心采用联邦式架构，不同组织或社区可自主托管和管理专属注册分册，同时支持跨注册中心解析，兼顾治理自主性与生态互操作性。

第三层：动态路由与解析。与固定IP地址的静态网站不同，AI智能体往往是临时或可移动的（可在云端与边缘基础设施间迁移）。NANDA内置动态解析逻辑，能在请求发起时为智能体匹配最优端点。这一逻辑会综合考量可用性、信任分数及其他元数据。

第四层：语义化发现与匹配。当任务需要特定能力时，NANDA协议栈会启动语义化发现流程，用户或智能体可通过网络查询，筛选出AgentFacts与所需技能、信任等级及其他条件匹配的智能体。系统随后动态选择并验证最适配的智能体，将静态查询转化为可验证、上下文感知的匹配过程。

NANDA智能体选择流程

第五层：安全证明与审计追踪。为确保问责制，所有重要交互均会被签名并记录在分布式账本中，形成防篡改的审计追踪，可用于纠纷解决、合规验证、智能体行为追踪。NANDA架构还支持零知识证明，智能体可在不披露敏感输入 / 输出数据的前提下，证明任务已正确完成，从而兼顾可验证性与隐私保护。

第六层：内置经济激励。去中心化生态要实现自我可持续，必须对贡献者进行激励。NANDA在架构中预留了经济层接口，使智能体可通过执行任务、提供数据、共享计算资源获得代币或使用额度等奖励。

NANDA提出了根本性的架构升级，它填补了身份、发现、经济等关键缺失层，为构建真正的智能体互联网奠定基础。通过集成并拓展A2A、MCP等协议，NANDA展现了稳健且开放的设计理念，未来的AI智能体将不再仅是互联网的使用者，而是互联网本身。

官方网站：https://nanda.media.mit.edu/

代码地址：https://github.com/projnanda

Agents.json协议

Agents.json是WildCard AI团队开发的一款基于OpenAPI标准的开源规范，专为AI智能体与互联网服务提供商使用的交互设计。API的设计初衷是服务开发者，而非LLM。若要为AI智能体搭建集成功能，针对每个API，都需编写重复的基础代码、调试系统提示词、优化工具定义，还要将API返回结果解析后存入向量数据库，这一系列工作需逐个API完成。

Agents.json核心目的是让智能体能够通过自然语言与API实现高效交互，解决智能体调用API时顺序混乱、准确性低的问题，同时引入智能体身份验证机制，减少未知自动化带来的风险。API提供商可利用其现有的OpenAPI规范构建该文件，而智能体则通过解析此文件，实现一系列精准的API调用。Agents.json在OpenAPI规范的基础上进行了补充，重点优化了端点发现效率与大语言模型参数生成逻辑，具体改进包括完善接口描述、增加调用示例等。

传统API规范仅描述端点与数据模型，却未说明它们之间如何协同工作，这正是AI智能体难以按正确顺序执行操作的关键原因。为解决这一问题，Agents.json引入了flows与links两个核心概念：flows是包含一系列API调用的协议，用于实现特定业务目标；links则定义了两个操作之间的衔接方式。

基于LLM的智能体与API交互

Agents.json核心设计理念如下：

基于OpenAPI的扩展：在OpenAPI规范的基础上引入flows和links概念，定义复杂操作的执行顺序。优化端点发现和LLM参数生成，简化AI代理对API的理解与调用。
自然语言驱动的交互：AI代理通过自然语言理解用户意图后，自动选择预定义的flows并执行。减少开发者手动编写适配代码的需求，提升任务执行效率。
无状态设计与低部署成本：AI代理独立管理上下文，无需依赖额外基础设施。服务提供方仅需提供符合规范的agents.json文件，即可支持AI代理调用。

API提供方可利用现有的OpenAPI规范构建agents.json文件，并将其放置在“/.well-known/agents.json”路径下，以便AI智能体获取。智能体加载agents.json文件后，理解用户意图并选择合适的flows进行调用，使用execute_flow执行任务流，自动准确地调用相应API完成任务。

与MCP相比，二者都能让AI智能体获取外部数据，但Agents.json更侧重AI智能体与互联网服务提供商的交互，保证多步骤调用的可靠性；与谷歌A2A协议里的agent.json不同，Agents.json是服务提供方的API声明，而A2A的agent.json 文件声明的是agent自身的能力、响应方式、状态等信息。

Agents.json对现有Web十分友好，它是对网站的轻量扩展，采用标准HTTP文件形式，极易集成，站点开发者只需编写JSON声明，将其托管在固定URL即可。对客户端智能体来说，解析JSON也比解析HTML简单很多，许多现有HTTP库即可完成获取。此外，该协议对工具和框架无依赖，任何语言的Agent都能读JSON，根据内含描述调用HTTP接口，用已有网络协议实现实际操作，没有特殊运行库要求。

代码地址：https://github.com/wild-card-ai/agents-json

Agora协议

随着LLM技术的爆发，各类智能体如雨后春笋般涌现，但它们基于不同框架（LangChain、Camel AI、Swarm等）构建，采用异构技术栈，形成了一个个通信孤岛。传统解决方案要么依赖固定结构化协议牺牲灵活性，要么完全依赖自然语言交互导致效率低下，始终无法平衡多样性、效率与可移植性三者关系。

智能体通信的三难困境

2024年，牛津大学计算机科学系的研究团队在《A Scalable Communication Protocol for Networks of Large Language Models》论文中正式提出Agora协议。作为专门针对LLM驱动智能体设计的元协议，Agora不规定具体通信格式，而是提供一套让智能体能够自主创建通信规则的机制，从根本上解决了传统协议的适配难题。

Agora协议采用双层架构设计，通过“自然语言协商 + 结构化执行”的混合模式，在效率与灵活性之间实现动态平衡。这种架构不依赖中央服务器，而是让每个智能体既是协议的使用者也是创建者，体现了彻底的去中心化理念。

自然语言协商层构成了智能体初次交互的通用语。当两个陌生智能体建立连接时，无需预设共同协议，而是直接通过自然语言交换智能体的能力描述与任务需求等信息。这一层确保了最大程度的兼容性，无论智能体基于何种框架开发，都能通过LLM的自然语言理解能力进行基础沟通。

动态协议执行层将协商结果转化为高效的机器交互。一旦协议达成，智能体的LLM会自动编写处理协议的例行程序（Routine），通常采用Python或JavaScript等通用语言。这些代码包含数据验证、格式转换和异常捕获功能，将自然语言描述的规则转化为可执行的结构化逻辑。

Agora目前主要在学术实验场景验证，适用于需要高度灵活协议的多智能体环境，如研究型多智能体系统，让智能体自行演化沟通方法。短期内Agora更多用于概念验证，如实验LLM能否自动生成协议解决特定任务。未来若成熟，可应用于规模和异质性极高的智能体网络。

官方网站：https://agoraprotocol.org/

代码地址：https://github.com/agora-protocol/

总结

从DNS时代的被动响应到智能体互联网的主动协同，IoA协议与项目的演进，本质上是数字世界从服务人类向人机协同跃迁的底层支撑革命。单一协议或项目难以支撑万亿级智能体的复杂交互，未来的突破必然来自协议互补、项目协同。

智能体互联网的终极形态，或许是一个无边界、自进化的智能协作网络，在这里，智能体不再是孤立的工具，而是构成数字世界的新节点。当协议的壁垒被打破、项目的生态相互渗透，一个由人类与智能体共同主导的高效、可信、普惠的数字新生态，正从构想走向现实。而此刻的每一项技术探索、每一次标准共识，都在为这场变革铺设基石。

普通人如何抓住AI大模型的风口？

为什么要学习大模型？

在DeepSeek大模型热潮带动下，“人工智能+”赋能各产业升级提速。随着人工智能技术加速渗透产业，AI人才争夺战正进入白热化阶段。如今近**60%的高科技企业已将AI人才纳入核心招聘目标，**其创新驱动发展的特性决定了对AI人才的刚性需求，远超金融（40.1%）和专业服务业（26.7%）。餐饮/酒店/旅游业核心岗位以人工服务为主，多数企业更倾向于维持现有服务模式，对AI人才吸纳能力相对有限。

在这里插入图片描述

这些数字背后，是产业对AI能力的迫切渴求：互联网企业用大模型优化推荐算法，制造业靠AI提升生产效率，医疗行业借助大模型辅助诊断……而餐饮、酒店等以人工服务为核心的领域，因业务特性更依赖线下体验，对AI人才的吸纳能力相对有限。显然，AI技能已成为职场“加分项”乃至“必需品”，越早掌握，越能占据职业竞争的主动权

随着AI大模型技术的迅速发展，相关岗位的需求也日益增加。大模型产业链催生了一批高薪新职业：