Agent Network Protocol技术白皮书：一个对标Anthropic MCP的协议

Anthropic MCP让人们看到智能体通过API或协议与外部数据对接的巨大潜力。我们在几个月之前就发布了Agent Network Protocol技术白皮书，一个和MCP类似的协议，致力于解决智能体通信中的挑战。中间迭代了几个版本，这是我们最新的版本。在这个版本中，我们提出了给更具有实施性的去中心化身份验证方案did:wba，加入了元协议，加入了智能体服务发现与描述设计。我们已经开发了一个开源实现，目前迭代到了0.2.0，未来几周我们会陆续完善协议细节和代码。

联系我们：

摘要

当前互联网基础设施虽已相当完善，但针对智能体网络的特殊需求，仍缺乏标准化的通信和网络连接方案。为充分发挥人工智能的潜力，本文提出了一种用于智能体通信的协议框架------Agent Network Protocol Framework。该框架旨在消除信息壁垒，实现智能体之间便捷的、去中心化的身份认证，以及高效协作。框架由三层结构组成：身份与加密通信层、元协议层和应用协议层。身份与加密通信层基于 W3C DID 标准，提供去中心化身份认证和端到端加密通信，确保智能体间的安全连接。元协议层通过自然语言协商和 AI 代码生成，提升了协作的灵活性与效率，降低了通信成本。应用协议层则通过标准化的协议描述和管理，简化了智能体间的交互过程。本文重点阐述该协议框架的整体设计，为智能体通信提供了一种创新的解决方案。

1. 简介

随着智能体（Agent）技术的迅速发展，它正逐渐成为继 Android、iOS 之后的下一个重要平台^1^。然而，目前仍缺乏一种标准化的方案来实现智能体之间的通信和网络连接。尽管互联网基础设施已相当成熟，但其现有技术无法完全满足智能体网络的特殊需求，主要体现在以下几个方面：

首先，智能体通常需要全面获取用户信息以作出准确决策。然而，现有互联网存在的数据孤岛效应使得用户信息分散在不同平台，限制了智能体的功能发挥。其次，当前的互联网应用主要面向人类用户，依赖图形化界面，然而智能体更擅长通过协议或 API 直接处理底层数据。图形化界面不仅增加了开发成本，还降低了处理效率。最后，智能体具备使用自然语言进行网络连接和协商的能力，能够通过自我组织和自我协作，实现更加个性化和高效的通信。

因此，亟需一种新的协议框架，能够打破数据壁垒，实现智能体间的无缝连接与通信。该框架应具备以下特性：消除信息壁垒，使智能体在完整的上下文中作出决策；提供适合 AI 的数据接口，降低信息处理成本；支持智能体自主连接、协商和协作。为此，本文提出了一种三层协议框架，包括身份与加密通信层、元协议层和应用协议层，旨在解决智能体通信中面临的挑战。

2. 协议三层架构

为了解决智能体网络中的身份认证、协议协商和应用交互等问题，我们设计了一个由三层组成的协议架构，如下图所示：

身份与加密通信层 ：此层定义了一系列规范，旨在解决智能体之间的身份认证问题，特别是跨平台的身份认证。我们设计了一个基于 W3C DID ^2^的去中心化身份认证方案，提供端到端的加密通信，确保任意两个平台的智能体之间能够安全地进行身份认证。
元协议层：该层定义了智能体如何利用自然语言进行协商，包括通信协议的协商和联调。通过自然语言的灵活性，智能体可以动态调整通信协议以适应不同的交互需求。
应用协议层：此层定义了智能体如何描述其能力和支持的协议，以及如何加载和处理协议代码。通过标准化的协议描述，智能体可以更高效地进行交互和协作。

2.1 身份与加密通信层

为了实现所有智能体之间的互联互通，首要任务是解决智能体之间的身份认证问题。当前，互联网应用大多采用中心化身份技术，不同技术实现导致系统间的账户难以相互认证。尽管 OAuth2.0 技术在一定程度上缓解了这一问题^3^，但由于 OAuth2.0 并非专为跨系统身份认证设计，其流程相对复杂，且在去中心化方面存在局限。因此，亟需一种便捷、跨平台且去中心化的身份认证技术。

基于区块链的去中心化身份认证方案虽然提供了可能的解决途径，但由于区块链在大规模应用中面临扩展性挑战，目前尚未成为最优解决方案。

针对上述问题，我们引入了 W3C 的去中心化标识符标准（Decentralized Identifier，DID）^2^。DID 是一种新型标识符标准，旨在解决传统中心化身份管理系统的依赖性。它使用户能够掌握自己的身份并进行相互认证，无需依赖中心化系统。DID 核心规范未限定实现者必须采用特定的计算基础设施来构建去中心化标识符，这使我们能够充分利用现有的成熟技术和完善的 Web 基础设施来构建 DID。此外，各种类型的标识符系统都可以添加对 DID 的支持，从而在集中式、联合式和去中心化标识符系统之间架起互操作的桥梁。这意味着现有的中心化标识符系统无需彻底重构，只需在其基础上创建 DID，即可实现跨系统互操作，从而大大降低了技术实施的难度。

DID 的核心组件是 DID 文档，其中包含与特定 DID 相关的关键信息，用于验证 DID 所有者的身份，并支持对 DID 相关的操作、权限和访问控制进行管理。

在身份验证过程中，DID 文档包含用于验证用户身份的方法和相应的公钥（私钥由用户自行保管）。客户端可以在首次HTTP请求时，在HTTP头中携带DID和签名。在不增加交互次数的情况下，服务端可以使用DID文档中的公钥快速验证客户端的身份。首次验证通过后，服务端可以返回token，客户端后续请求中携带token，服务端不用每次验证客户端的身份，而只要验证token即可。整个过程的核心在于验证者使用可信的公钥对用户签名信息进行验证，并且能够在一次请求中完成身份认证、权限认证、数据交换等操作，流程简洁高效。

DID 方法定义了如何创建、解析、更新和停用 DID 与 DID 文档，以及如何进行身份验证和授权。在现有的 DID 方法草案中，did:web 方法^4^ 基于成熟的 Web 技术构建，允许系统使用中心化技术（如云计算）来创建、更新、停用 DID 和 DID 文档。不同系统之间通过 HTTP 协议实现互操作，其效果类似于互联网的emai服务，各个平台以中心化的方式实现自己的账户体系，同时，各个平台之间可以互联互通。

基于 did:web 方法，我们针对智能体通信的场景，添加了跨平台身份认证流程和智能体描述服务等规范，提出了一种新的 DID 方法------did:wba（Web-Based Agent）。did:wba 方法继承了 did:web 的优势，进一步优化了智能体间的身份认证机制，提升了在智能体网络中的适用性。

此外，用户通常为 DID 创建一个或多个公私钥对，这些密钥对不仅用于身份验证，还可用于端到端加密通信。基于 DID 的公私钥对，我们采用椭圆曲线 Diffie-Hellman 临时密钥交换协议（Elliptic Curve Diffie-Hellman Ephemeral，ECDHE）^5^，设计了一种端到端加密通信方案，实现了两个 DID 之间的安全通信，确保中间节点无法解密通信内容。

2.2 元协议层

元协议（Meta-Protocol）是一种定义通信协议操作、解析、组合和交互规则的高级协议。本质上，它是用于协商通信协议的协议，不直接处理具体的数据传输，而是提供一个灵活、通用且可扩展的通信框架。

目前，智能体之间的通信主要有两种方法：

人类工程师设计通信协议：例如常见的行业标准。人类工程师为智能体设计通信协议，开发协议代码，进行调试、测试和部署。然而，这种方法往往面临开发成本高、协议更新迭代慢、难以适应新场景等问题。
智能体直接使用自然语言通信：智能体之间使用自然语言进行通信，内部利用大型语言模型（LLM）处理自然语言数据。但这种方法存在数据处理成本高、处理准确率低等问题。

为了解决上述问题，可以使用元协议和AI代码生成的方案。通过使用元协议并利用AI代码生成技术，能够显著提高智能体之间的通信效率，降低通信成本，同时保持通信的灵活性和个性化^6^。

使用元协议进行通信的基本过程如下：

元协议请求：智能体A首先向智能体B发送一个元协议请求。请求主体使用自然语言描述自己的需求、输入、期望获得的输出，并提出候选通信协议。候选通信协议一般包括传输层协议、数据格式、数据处理方式等。
协议协商：智能体B收到元协议请求后，利用AI处理请求中的自然语言描述，并结合自身能力，判断是否接受A的请求和候选协议。如果B的能力无法满足A的请求，则直接拒绝；如果B不接受A的候选协议，则可以提出自己的候选协议，进入下一轮协商。协商过程持续，直到双方达成一致或协商失败为止。
代码生成与部署：双方达成一致后，各自根据协商的协议生成协议处理代码，并进行部署。
联调测试：代码部署完毕后，双方协商联调的测试数据，对协议以及AI生成的协议处理代码进行联调和测试。
正式通信：联调完成后，协议正式上线。之后，智能体A和智能体B开始使用最终协商的协议进行通信，并利用AI生成的代码处理数据。
需求变更处理：如果需求发生变化，则重复上述过程，直到双方再次协商一致。

然而，元协议协商过程耗时较长，且依赖于AI代码生成能力。如果每次通信都进行元协议协商，将会带来巨大的成本消耗和较差的交互体验。鉴于智能体之间存在大量相同或类似的通信过程，智能体可以将元协议协商的结果保存下来。后续遇到类似需求时，可以直接使用之前的协商结果作为正式协议进行通信，或作为候选协议进行协商。同时，智能体也可以分享协商结果，供其他智能体查询和使用。

如何在经济层面激励智能体主动上传协商结果，并选取智能体之间的共识协议，是元协议层仍需深入研究的问题。

2.3 应用协议层

为降低通信成本并提升交互体验，在大多数通信场景中，智能体应避免每次都通过元协议进行通信协议的协商。因此，在应用协议层，我们设计了一套规范，包括智能体能力与支持协议描述 和应用协议管理规范，使得智能体之间的通信更加便捷、高效和低成本。

智能体能力与支持协议描述规范明确了智能体如何描述自身的能力和支持的协议，以及调用这些能力所需的协议信息。智能体可以将这些描述文档发布在互联网或专门的智能体搜索服务上，供其他智能体查询和调用。

应用协议管理规范则规定了应用协议的文档格式、元数据（如协议版本、发布时间、创建者等），以及协议文档的查询与下载方法。应用协议应包含以下内容：

协议版本：标明协议的迭代更新信息，确保双方使用兼容的协议版本。
功能描述：详细说明协议的功能、适用场景和预期效果。
输入输出数据格式：定义交互过程中数据的格式、类型和约束条件。
协议处理流程：描述通信的步骤、顺序和逻辑关系。
经过可信DID签名的协议代码：包括请求方发起请求的代码和响应方处理请求的代码，确保代码的安全性和可信度。

应用协议的来源可以多样化：

人类定义的标准协议：由领域专家或行业组织制定，具有广泛的适用性和一致性。
智能体间协商的共识协议：智能体通过元协议协商达成一致，适用于特定的协作任务。
智能体间的个性化协议：根据特定需求或场景，由智能体定制的专用协议。

为便于应用协议的共享和复用，未来可以建立一个类似于PyPI的协议服务平台，对应用层协议进行集中管理。智能体可以在该平台上搜索、下载并使用已有的协议及其代码，对外提供服务。在调用其他智能体的服务时，可以根据对方支持的协议，加载相应的协议代码并进行通信。

以下是智能体A调用智能体B服务的示例流程：

能力发现：智能体A通过搜索或查询服务，发现智能体B具备满足其需求的能力。
协议匹配：A查阅B的能力描述文档，确定可用的通信协议。
协议加载：A通过协议服务平台，加载对应的协议处理代码。
通信执行：A使用加载的协议代码，按照规定的流程与B进行通信。

在具体的数据交换中，协议的数据格式并不限定，可以根据需求选择JSON、OpenAPI、Protocol Buffers等业界标准格式，以满足不同应用场景的要求。

3. 展望

虽然我们提出的三层协议架构在一定程度上解决了智能体网络通信中的关键问题，但仍存在若干需要深入研究的领域。

首先，跨平台身份认证技术的优化是亟待解决的问题。尽管W3C的DID标准为去中心化身份认证提供了可能，但作为一项新发布的推荐标准，其基础设施尚不成熟。

其次，底层通信协议的适用性需要重新审视。我们的方案依赖于现有的Web基础设施，这虽然降低了技术实施的难度，但可能忽视了智能体通信的特殊需求。现有的HTTP协议是否仍然是智能体的最佳选择？是否存在更适合智能体数据交换和通信效率的协议方案？这些问题值得进一步探讨。

最后，区块链技术在智能体网络中的应用前景值得期待。随着区块链技术的逐渐成熟，其天然的去中心化特性和对个人数据主权的强调，可能为构建智能体网络提供理想的基础。区块链不仅可以促进AI更便捷地访问用户数据，其内在的金融属性还可能解决智能体在协商协议时所面临的经济激励难题。

我们的研究为智能体网络通信提供了基础性的框架，但在身份认证、通信协议和技术选择等方面仍有大量工作需要开展。未来的研究应针对这些关键问题，提出更具创新性和实用性的解决方案。

4. 结论

本文提出了一种针对智能体网络通信的三层协议架构，旨在解决当前智能体之间缺乏标准化通信与网络连接方案的问题。首先，通过引入基于 W3C DID 的去中心化身份认证方案，我们为智能体提供了跨平台的身份认证能力，并设计了端到端的加密通信机制，确保了通信的安全性和可信性。其次，在元协议层，我们利用自然语言协商和 AI 代码生成的能力，提升了智能体之间的通信效率和灵活性，减少了协议协商的复杂度和成本。最后，应用协议层通过规范化的协议描述和管理，简化了智能体间的交互过程，降低了通信成本，提升了交互体验。

尽管该架构在解决智能体通信问题上取得了显著的进展，但仍有一些挑战需要克服。例如，如何进一步优化跨平台身份认证技术，提高其可扩展性和实用性；探索更适合智能体通信的底层协议，以提升数据交换的效率和可靠性。此外，区块链技术在智能体网络中的应用潜力也值得深入研究，特别是在去中心化身份管理和经济激励机制方面。

总之，本研究为智能体网络通信提供了一种创新性的解决方案，奠定了良好的基础。未来的工作将致力于完善该架构，解决现存的问题，推动智能体技术的进一步发展。

参考文献

Footnotes

Bill Gates, AI is about to completely change how you use computers, www.gatesnotes.com/AI-agents ↩
Decentralized Identifiers (DIDs) v1.0:Core architecture, data model, and representationswww.w3.org/TR/did-core... ↩ ↩²
The OAuth 2.0 Authorization Framework, tools.ietf.org/html/rfc674... ↩
did:web Method Specification, w3c-ccg.github.io/did-method-... ↩
The Transport Layer Security (TLS) Protocol Version 1.3，www.rfc-editor.org/rfc/rfc8446... ↩
A Scalable Communication Protocol for Networks of Large Language Models, arxiv.org/pdf/2410.11... ↩