2.1 智能体将推动传统软件的全面更新换代

随着智能体技术的不断演进，我们正站在传统软件体系更新换代的转折点上。智能体不仅将成为下一代互联网的重要基础设施，更有望重塑人们与数字世界的交互方式。在个人层面，个人智能体将成为用户进入互联网的主要入口，现有的大部分网站与App，也将逐步智能体化，并通过智能体间交互的方式来交付相应的功能和服务。相较于依赖手动操作的界面型应用，智能体在信息整合、意图识别、决策辅助与多模态场景交互等方面展现出显著优势，可为用户带来数量级提升的使用体验。

在企业层面，企业将通过部署企业智能体，对内可提高业务处理流程的自动化水平，对外可提供更加智能化、个性化的用户体验与服务。

同时，个人智能体可以与企业智能体的直接连接，即可获得更加精准、高效、安全的服务体验。这种以个人智能体与企业智能体之间的点对点、直接连接为特征的新型连接范式也正在加速形成，预示着更灵活、更智能、更去中心的互联网架构即将到来。

2.2 智能体之间将实现普遍互联互通

在Agentic Web的图景中，智能体不再是孤立运作的单元，而是构成一个高度互联、协同演化的网络体系。实现任意智能体之间的自由连接，将从根本上打破当前互联网中“平台割裂”与“数据孤岛”的结构性限制，使信息得以在不同领域与系统之间自由流动。这种互联不仅意味着数据的互通，更代表着智能体能够动态获取和组合跨平台、跨场景的上下文信息，从而在服务个体用户或组织决策时展现出更强的综合感知与推理能力。同时，开放的连接机制使智能体能够按需调用全网工具和能力资源，构建出更复杂、更深入的协作链路。在这一趋势推动下，智能体之间的交互将逐步取代以人类为中心的交互方式，成为未来互联网最核心、最主要的连接形态。

2.3 智能体将基于原生协议进行连接和交互

当前，AI与互联网的交互主要依赖于以人为中心设计的界面方式，比如Computer Use、Browser Use。这些交互路径虽为AI提供了初步的接入能力，但本质上仍是为人类用户而设计，难以充分发挥AI在信息解析、语义处理和自动化执行方面的能力。事实上，AI更擅长处理结构化数据、语义标注信息和明确的功能调用，而非复杂多变的网页HTML或前端界面。因此，面向未来的Agentic Web亟需构建一种原生为AI设计的网络协议体系，使智能体之间能够以机器可读、语义明确的方式直接进行交互。这类协议将扮演类似于HTTP在人类互联网中的角色，成为支撑智能体网络的基础通信标准。以此协议体系为基础，一个专门面向AI设计、更易于智能体访问和操作的全新数据网络也将随之诞生。

2.4 智能体可自主组织和协作

Agentic Web演进的另一关键趋势，是智能体将具备更广泛的自主组织与协作能力。我们认为，在标准化的协议支持下，智能体之间能够通过自然语言进行动态协商，快速识别彼此的能力、意图与需求，并在无需预设接口的情况下，自主组建协作关系、完成任务分工。这种灵活、高度自适应的交互模式，突破了传统系统中依赖静态接口和人工编排的限制，显著提升了网络的运行效率与任务响应速度，同时大幅降低了人为干预与集成成本。随着协作机制的持续演进，一个由智能体自发驱动、高度可组合、具备快速响应能力的Agentic Web生态将逐步形成，为复杂任务处理与多智能体系统运行提供坚实基础。

4.1 智能体网络协议旨在解决的关键问题

• 互联互通与打破数据孤岛：协议需要提供机制，使不同平台、不同开发者创建的智能体能够相互发现、验证、连接和通信，从而打破当前互联网中普遍存在的数据孤岛现象。这要求协议能够支持跨域通信，并促进信息的自由流动，确保智能体能够获取做出高质量决策所需的完整上下文信息。
• 异构智能体间的协作：Agentic Web将由大量具有不同架构、能力和目标的异构智能体组成。协议必须能够解决这些异构智能体之间的通信和协作问题，例如通过标准化的消息格式、交互模式和能力描述机制，使得它们能够理解彼此并协同工作。
• 兼容性与标准复用：为了促进广泛的采纳和集成，智能体网络协议应尽可能兼容并复用现有的成熟Web标准和技术（如HTTP、WebRTC、OpenAPI、WoT等）。这不仅可以降低开发和部署的门槛，也有助于充分利用现有网络基础设施的稳定性和安全性。
• 构建信任与降低协作成本：在开放的Agentic Web中，智能体间的信任是一个核心问题。协议应包含建立和验证智能体身份、信誉和能力的机制，以降低未知智能体之间协作的风险和成本，促进可信的交互。
• 高效协作与隐私保护的交互模式：协议需要定义智能体之间信息交互的模式，既要保证协作的高效性，也要兼顾用户隐私和数据安全。这将涉及到在对智能体身份进行可信验证的基础上，对通信内容进行加密、支持选择性的信息共享、以及定义不同粒度的访问控制机制。

4.2 智能体网络协议核心功能需求

一个全面的智能体网络协议应满足以下核心功能需求，以支持智能体在Agentic Web中的有效运作：

• 智能体身份 (Agent Identity)：构建统一的身份表示与验证机制，使智能体在不同平台、服务与域之间能够进行可信的身份声明与认证，从而实现跨平台环境下的互操作性与信任传递。
• 智能体描述 (Agent Description)：建立标准化的智能体描述模型，用于表达智能体的信息、功能、接口、服务范围，使其他智能体能够基于统一语义准确理解其能力边界，并实现自动解析与调用。
• 智能体发现 (Agent Discovery)：支持智能体基于语义匹配、任务需求或能力特征，在网络中动态检索和定位其他合适的智能体，从而构建按需协作的分布式智能体网络。
• 智能体数据交换 (Agent Data Exchange)：制定统一的数据格式与交互流程，用于智能体之间的信息、指令及上下文的可靠传递，确保跨智能体通信的语义一致性、结构规范性与协作有效性。
• 智能体能力调用 (Agent Capability Invocation)：在身份、描述与发现机制基础上，建立通用的调用机制，支持一个智能体调用另一个智能体公开的服务或接口，实现任务委托、流程编排与跨智能体协同操作。调用过程需涵盖接口发现、参数传递、权限验证、执行反馈等完整闭环，确保调用的准确性、安全性与可审计性。

基于 DID 的身份认证：参考实现方案

上述设计原则确立了智能体身份机制的需求。本节介绍去中心化标识符（DID），特别是基于 Web 的智能体 DID 方法（did:wba），作为满足这些需求的参考实现方案，同时克服了传统认证方案的局限性。

传统方案在智能体网络中的局限性

智能体网络面临一个独特挑战：来自不同平台的智能体必须动态地建立信任，通常没有任何预先存在的关系。传统认证方案并非为此场景设计：

OAuth 的局限性：OAuth 2.0 假设存在一个双方都认可的可信授权服务器。在多平台智能体场景中，这造成了重大挑战：

• 平台 X 的智能体要访问平台 Y 的智能体，要么平台 Y 必须预先将平台 X 注册为可信的 OAuth 客户端，要么双方必须信任一个共同的身份提供商。
• 对于 N 个平台自由互操作，这需要 O(N²) 双边信任协议或依赖单一主导身份提供商——两��都无法很好地扩展或保持去中心化。
• 新平台面临"冷启动"问题：在与现有平台建立 OAuth 关系之前无法参与。

传统 PKI 的局限性：虽然 PKI 提供了强大的密码学保证，但在智能体身份方面存在局限：

• TLS 证书验证域名所有权，而非单个智能体身份。同一域名上的多个智能体共享同一证书。
• PKI 设计用于传输层安全，而非对等智能体之间的应用层身份验证。
• 跨域证书验证依赖于中心化的证书颁发机构（CA）信任链。
• 对于频繁创建和退役智能体的动态生态系统，证书管理开销很高。

DID 如何解决这些问题

W3C 去中心化标识符（DIDs）[[DID-CORE]] 为智能体身份提供了解决上述局限的基础：

• 自主身份：每个智能体拥有自己的密码学身份（公私钥对），由其自主控制，独立于任何中心化机构。
• 自托管身份文档：包含公钥的 DID 文档托管在智能体自己的域名上，消除了对第三方身份提供商的依赖。
• 直接验证：任何智能体都可以通过获取其 DID 文档并验证密码学签名来验证另一个智能体的身份——无需预先建立的关系。
• 联邦式架构：类似电子邮件，每个平台以中心化方式管理自己的账户，同时通过标准协议实现跨平台互操作性。

基于 Web 的智能体 DID 方法（did:wba）

did:wba 方法扩展了 did:web 规范，专门针对智能体通信场景。它继承了基于 Web 的 DID 的简洁性，同时添加了针对智能体交互优化的跨平台认证流程。

关键特性：

• 无需区块链：与 did:btc、did:ethr 或 did:ion 不同，did:wba 使用标准 Web 基础设施（DNS、HTTPS、Web 服务器）。这消除了区块链可扩展性问题，降低了部署复杂性。
• 熟悉的基于 URL 的解析：像 did:wba:example.com:user:alice 这样的 DID 解析为 https://example.com/user/alice/did.json——一个托管在标准 Web 服务器上的简单 JSON 文档。
• 单次请求认证：智能体在首次 HTTP 请求中包含其 DID 和密码学签名。服务器获取 DID 文档，验证签名，并返回访问令牌——全部在单次往返中完成。
• 分级授权支持：DID 文档可以包含用于常规智能体操作与需要人工授权的敏感操作（humanAuthorization）的独立验证方法，支持前面描述的分级授权原则。

认证流程：

1. 客户端智能体在首次请求的 HTTP Authorization 头中包含其 DID 和签名。
2. 服务器从客户端的域名获取客户端的 DID 文档（例如，https://client-domain.com/agent/did.json）。
3. 服务器使用 DID 文档中的公钥验证签名。
4. 验证成功后，服务器返回用于后续请求的访问令牌。
5. 结果：跨平台认证在单次往返中完成，无需预先注册。

实际场景：多平台智能体协作

考虑一个旅行预订场景，用户的个人智能体（平台 A）需要与多个服务智能体协调：

• 向酒店智能体（平台 B）查询可用性
• 通过航空公司智能体（平台 C）预订航班
• 通过租车公司智能体（平台 D）安排租车

使用 OAuth：平台 A 需要预先注册为平台 B、C 和 D 的 OAuth 客户端——或者所有平台需要信任一个共同的身份提供商（造成中心化）。添加新的旅行服务平台需要在任何协作发生之前建立新的 OAuth 关系。

使用 DID：每个智能体只需在其域名上托管 DID 文档。平台 A 的智能体可以立即验证并与平台 B、C 和 D 上的智能体交互，通过获取其 DID 文档并验证签名。新平台只需托管 DID 文档即可加入生态系统——无需双边协议或中心协调。这实现了第二章描述的"智能体间普遍互联互通"愿景。

解决采用顾虑

一个常见的顾虑是 DID 引入了不熟悉的概念和学习开销。然而，did:wba 旨在最小化这一障碍：

概念简单性：从本质上讲，DID 只是"域名 + 路径 + 公钥"。格式类似于熟悉的模式：

• 电子邮件：alice@example.com
• DID：did:wba:example.com:user:alice

渐进式采用：现有系统无需重构。组织可以在现有认证机制的基础上添加 DID 文档托管，实现渐进式迁移。DID 文档只是通过 HTTPS 提供的 JSON 文件——无需特殊基础设施。

熟悉的技术栈：did:wba 使用 Web 开发者已经熟悉的技术：HTTP、JSON、公钥密码学和 DNS。认证流程类似于 API 密钥认证，但增加了密码学验证的好处。

工具可用性：常见编程语言都有参考实现和库可用，降低了实现工作量。

4.3 智能体网络协议的关键非功能性需求

除了核心功能外，智能体网络协议还必须满足一系列关键的非功能性需求，以确保其在现实世界中的安全性、可用性、扩展性和可控性：

• 安全性（Security）：提供完善的身份认证、访问控制、数据完整性校验与通信加密机制，具备对常见攻击行为（如伪造、篡改、重放等）的防护能力，保障智能体间交互的安全可信。
• 隐私保护（Privacy）：协议设计应内嵌隐私保护机制，避免不必要的数据暴露与共享，支持智能体在交互过程中最小化传递个人信息，符合相关法律与规范要求。
• 可扩展性（Scalability）：协议设计应具备良好的扩展能力，能够处理不断增长的智能体数量和交互，而不会出现显著的性能下降。
• 灵活性（Flexibility）：协议设计应具备良好的演进能力，能够灵活适配未来AI能力的演化、新型智能体角色的涌现及交互模式的不断变化。
• 兼容性（Compatibility）：在适当情况下确保与现有Web协议和标准的兼容性，并使来自不同开发者/平台的智能体能够协同工作 (11)。
• 可审计性（Auditability）：支持对智能体行为和交互过程的全过程记录、溯源与审查，确保在出现争议或异常行为时能够进行验证、分析与责任认定。
• 可观测性（Observability）：支持人在回路中（Human-in-the-loop），能够对智能体的行为进行监控和管控。

模型上下文协议 (MCP)

• 描述：MCP是一个由Anthropic发起并已开源的开放标准，旨在标准化应用程序向大型语言模型（LLMs）提供上下文的方式。它被形象地比喻为"AI应用的USB-C端口"，目标是解决AI模型与外部数据源、工具和系统（如云平台、企业数据库、本地文件）连接时面临的M×N集成难题。通过提供统一接口，MCP简化了AI模型与外部世界的交互，减少了为每个新数据源或工具构建定制连接器的需求。
• 主要特性/机制：MCP采用客户端-服务器架构，其中AI应用（如聊天助手、AI驱动的IDE）作为MCP客户端，连接到一个或多个暴露能力或数据的MCP服务器 (31)。其核心交互原语包括：工具（Tools，可动态调用的可执行函数，如API调用）、资源（Resources，供AI参考的结构化静态数据流）和提示（Prompts，可复用的对话工作流或模板）。协议层处理消息帧、请求/响应映射和通知传递，支持多种传输协议，如用于本地进程的Stdio和用于网络服务的HTTP+SSE。
• 关注点/目标挑战：MCP的核心目标是为LLM提供结构化的上下文注入，实现工具和知识的灵活插拔，支持安全的基础设施集成，并确保跨不同LLM供应商的兼容性。它致力于提升AI模型的上下文感知能力和动态工具发现与执行能力。
• 使用核心技术：JSON-RPC（用于客户端-服务器接口），HTTP，服务器发送事件（SSE）。

Agent-to-Agent协议 (A2A) (Google)

• 描述：A2A是由Google发起并与超过50个行业伙伴共同推动的开放协议，旨在使不同框架、不同供应商构建的独立AI智能体能够安全、无缝地通信、协作和协调动作。它致力于解决异构智能体生态系统中的互操作性问题，使智能体能够在不暴露其内部状态、记忆或工具的情况下协同工作。
• 主要特性/机制：A2A的核心架构围绕客户端智能体和远程智能体展开。智能体通过"智能体名片（Agent Card）"（一种JSON元数据文档）来发布其身份、能力、技能、服务端点和认证要求，从而实现能力发现。协议支持任务管理生命周期，允许创建、发送和跟踪任务状态，并能处理可能需要数小时甚至数天的长时任务。A2A支持多种交互模态，包括文本、文件、结构化JSON数据，以及音频和视频流。
• 关注点/目标挑战：A2A专注于实现不透明、自主智能体之间的动态交互、能力共享和任务协调，特别是在企业级工作流中。它旨在打破智能体孤岛，简化企业集成，并促进一个更互联、更强大的AI生态系统。A2A与MCP解决不同的问题，MCP关注智能体与工具/数据的连接，而A2A关注智能体间的协作。
• 使用核心技术：HTTP(S)（作为传输层，要求TLS加密），JSON-RPC 2.0（作为请求和响应的有效载荷格式），服务器发送事件（SSE）（用于服务器到客户端的实时流式通信，如任务状态更新）。

智能体网络协议 (ANP)

• 描述：ANP是一个开源协议，其愿景是成为"Agentic Web时代的HTTP"，旨在为数十亿智能体构建一个开放、安全、高效的协作网络。它致力于解决当前互联网基础设施在满足智能体网络特定需求方面的不足。ANP由开源社区开发与维护，同时社区承诺开放、中立的立场，并且社区永远不做商业化。
• 主要特性/机制：ANP主要为解决智能体在互联网上的连接与协作问题，它采用三层架构：
  1. 身份与加密通信层：基于W3C DID（去中心化标识符）规范构建去中心化认证方案和端到端加密通信，使跨平台智能体无需依赖中心化系统即可相互认证。
  2. 元协议层：一个用于智能体之间协商通信协议的协议，是实现智能体网络自组织、自协商高效协作的关键。
  3. 应用协议层：基于语义网规范，使用JSON-LD和schema.org描述智能体的信息、能力和接口，智能体的入口点是一个智能体描述文档（Agent Description Document）。使用RFC 8615设计智能体发现机制，使用W3C VC实现智能体之间交易的凭证记录，同时复用现有的很多规范比如OpenAPI、Webrtc等。

  

• 关注点/目标挑战：ANP旨在解决智能体互联网的三大核心挑战：实现所有智能体间的互联互通，打破数据孤岛，确保AI能获取完整上下文信息；提供AI原生接口，使AI能通过API或通信协议与数字世界高效交互，而非模仿人类操作；以及利用AI实现智能体间的自动组织和自动协商，构建更经济高效的协作网络。它特别关注开放互联网环境下的去中心化发现与协作，以及跨异构域的互操作性。
• 使用核心技术：W3C去中心化标识符（DIDs），JSON-LD，W3C 可验证凭证（VC），端到端加密技术。

Agent Connect Protocol (ACP)

• 描述：ACP 是由 Cisco 主导，并与 LangChain、Galileo 等合作伙伴共同开发的开源协议，作为 AGNTCY 计划的一部分，旨在为分布式系统中的自主智能体提供协作和共享资源的通信层。。
• 主要特性/机制：ACP采用RESTful API作为标准接口，定义了智能体交互的方式，包括检索智能体可执行的工作流、创建和管理上下文线程以及运行智能体。它支持有状态的通信线程，允许智能体在任务中进行协商和共同推理，并通过消息传递实现松散耦合的交互。智能体发现通过 Agent Directory 和 OASF（Open Agentic Schema Framework）文档实现，后者是描述智能体功能、调用方法、输入/输出模式等的标准化 JSON 文件。ACP支持异步优先的交互、多部分消息和可观察性特性。
• 关注点/目标挑战：ACP主要解决企业环境中异构智能体（可能基于不同技术栈或框架构建）之间的通信障碍和协作效率问题。它旨在实现可扩展的、标准化的多智能体交互，使多个智能体能够作为一个逻辑单元共同完成复杂任务。
• 使用核心技术：RESTful API，JSON（用于 OASF 文档和消息模式）。可与LangGraph等工作流框架集成。

Agent Communication Protocol (ACP)

• 描述：Agent Communication Protocol (ACP) 是一个由IBM贡献给Linux基金会的开源标准，旨在为异构AI智能体提供共享语言，实现连接、协作与复杂任务执行。该协议的主要目标是消除供应商锁定，通过开放治理模式促进智能体生态系统的发展。
• 主要特性/机制：ACP定义了一个标准化的RESTful API，支持同步、异步和流式交互，并采用对等方交互设计。其核心特性包括：
  • 无需专门SDK：协议设计上无需专门SDK即可交互，可直接使用标准HTTP工具进行交互，同时提供Python/TypeScript SDK。
  • 离线发现：通过元数据实现智能体发现，可嵌入分发包实现离线发现，使用Agent Detail模型描述智能体。
  • 对等交互：强调对等方交互，支持智能体之间的直接通信协作。
  • 与MCP互补：与Model Context Protocol (MCP)形成互补关系，专注于智能体间通信。
• 关注点/目标挑战：ACP主要解决异构AI智能体之间的互操作性问题，通过提供共享通信语言来实现跨框架、跨技术栈的智能体协作。该协议特别强调避免供应商锁定，采用开源、Linux基金会治理模式确保标准的开放性和中立性。
• 使用核心技术：HTTP, JSON, OpenAPI Specification, Python/TypeScript SDKs。协议依赖底层HTTP(S)及部署环境的企业级安全实践，支持在安全/气隙环境中的发现和交互。

协议比较分析

为了清晰地比较上述主要协议，下表总结了它们的一些关键特性：