引言
2024 年至 2026 年间，多智能体系统经历了从概念验证到广泛应用的快速发展。AutoGen、CrewAI、LangGraph 等框架的相继出现，使得基于大语言模型的智能体协作成为可能。然而，深入分析这些框架的架构设计，会发现它们普遍存在一个共性假设：所有参与协作的智能体必须预先注册到同一个中心化的编排节点。
这一假设在真实场景中带来了若干根本性的限制。首先，中心化编排器构成单点故障，其可用性直接决定了整个系统的可用性。其次，所有通信流量集中经过中心节点，在智能体数量增长时形成性能瓶颈。再者，跨框架、跨组织的智能体协作需要额外的适配层，不同生态的智能体之间缺乏原生的互操作能力。最后，系统的动态扩展能力受限，新增智能体往往需要修改配置甚至重启服务。
这些限制促使我们思考一个更根本的问题：智能体之间的协作，是否必须依赖中心化的协调机制？人类社会的协作并非如此——个体通过社会网络自主发现彼此、建立联系、形成协作。智能体是否也可以拥有类似的自主协作能力？

本文介绍 AI Mesh 项目，一个去中心化的多智能体协作网络基础设施，旨在为智能体提供自主发现、通信与协作的网络层支持。

 系统架构：

AI Mesh 采用分层架构设计，从底层到上层依次为身份层、传输层、协议层、协作层和应用层。
身份层负责智能体的身份管理与密钥生命周期管理。每个智能体节点启动时生成一个 Ed25519 密钥对，并以此为基础派生出 libp2p PeerId 用于网络层寻址，以及符合 W3C 标准的 did:key 用于语义层身份标识。智能体的能力声明以 Agent Card 的形式存在，并使用 JWS 进行签名以防止伪造。
传输层基于 libp2p 协议栈实现，承担节点发现、连接管理、加密通信和 NAT 穿透等职责。在节点发现方面，系统采用三级发现机制：局域网内通过 mDNS 实现零配置发现，广域网范围内通过 Kademlia DHT 进行分布式查找，实时状态变化则通过 GossipSub 进行广播同步。在通信安全方面，所有传输均经过 Noise 协议加密，单条 TCP 连接通过 Yamux 承载多条逻辑流以实现多路复用。在 NAT 穿透方面，系统通过 AutoNAT 检测节点的网络可达性，优先尝试 DCUtR 双端打洞，在打洞失败时降级至 Circuit Relay 中继转发。
协议层同时实现了 A2A（Agent-to-Agent）和 MCP（Model Context Protocol）两种标准化协议。A2A 协议基于 JSON-RPC 2.0，定义了智能体之间的消息交互格式和任务生命周期管理，核心方法包括 SendMessage、GetTask 和 ListTasks。MCP 协议则定义了智能体能力的标准化暴露方式，通过 tools/list 和 tools/call 方法实现工具的发现与远程调用。两种协议的分工清晰：A2A 负责智能体间的对话与任务协作，MCP 负责智能体能力的暴露与调用。
协作层在协议层之上实现了六种协作模式，包括任务交接（Handoff）、并行处理（Parallel）、层级分解（Hierarchical）、顺序流水线（Sequential）、多智能体辩论（Debate）和方案投票（Voting）。这些协作模式通过结构化任务契约（使用 JSON Schema 定义）进行信息传递，并支持父子任务链的完整追踪。
应用层提供了与外部系统的集成能力，包括 GitHub Webhook 接口、WebSocket 实时仪表板和命令行工具。

关键技术决策

传输层选型：为什么选择 libp2p
在多智能体系统的传输层选型中，我们对比了几种候选方案。WebRTC 支持浏览器环境但不擅长大规模 P2P 网络的节点发现与管理。gRPC 功能完备但过于沉重，且缺乏内置的服务发现机制。HTTP/REST 则原生不支持服务端主动推送和流式通信。
libp2p 的优势在于其经过 IPFS 和 Filecoin 等大规模生产系统的验证，提供了从节点发现到 NAT 穿透的完整解决方案。其模块化设计允许按需组合各功能组件，避免引入不必要的依赖。

协议设计：A2A 与 MCP 的协同
在协议选型中，我们面临的一个核心问题是：是否应该采用统一的协议来处理所有通信场景？
分析表明，A2A 和 MCP 解决的是不同层面的问题。A2A 的协议原语围绕智能体间对话展开，包含消息发送、任务创建与状态跟踪等操作，适合描述复杂的多轮协作流程。MCP 的协议原语则围绕工具调用展开，通过标准化的工具列表查询和调用接口实现能力的跨智能体复用

两种协议在功能上互补而非重叠。采用双协议栈的设计决策使系统能够根据不同场景选择最合适的通信模式：在智能体间对话场景中使用 A2A，在工具调用场景中使用 MCP。
身份模型：一个密钥对的多重用途
系统的身份模型遵循一个设计原则：最小化密钥管理复杂度。每个智能体维护单个 Ed25519 密钥对，该密钥对同时承担四重职责。
在传输层，私钥用于 Noise 协议的加密握手协商，公钥派生出 libp2p PeerId 作为网络层寻址标识。在应用层，私钥用于对每条消息进行数字签名以确保消息的完整性与不可否认性，私钥也用于对 Agent Card 进行 JWS 签名以防止身份伪造。在语义层，公钥派生出符合 W3C 标准的 did:key 作为全局唯一的身份标识。

这一设计的核心优势在于消除了多密钥体系下的信任传递问题。在传统设计中，传输层身份、应用层身份和签名密钥往往相互独立，需要在各层之间建立额外的信任绑定。单密钥模型天然消除了这一需求。
协作模式的标准化
在协作模式的实现中，我们面临的一个关键问题是：如何在不同智能体之间传递任务信息，以避免因自然语言的二义性导致协作失败。
我们的方案是引入结构化任务契约。每个协作任务使用 JSON Schema 定义其输入输出格式，智能体之间传递的是符合 Schema 的结构化数据而非自然语言提示词。每个任务包含唯一的任务标识符、任务类型、输入参数、期望输出格式和超时设定。
此外，系统支持任务链的完整追踪。父任务在拆分子任务时，会在子任务中注入父任务 ID，形成完整的任务血缘关系图。这一设计为后续的协作审计和性能分析提供了数据基础。 

在真实模型推理方面，使用 Ollama qwen2.5:3b 在 CPU 上运行，简单问答场景（约 50 Token 输入）的推理延迟约 1 秒，代码审查场景（约 500 Token 输入，含代码上下文）的推理延迟约 4-5 秒。
我们完成了一个完整的端到端协作实验。两个智能体分别承担安全审查和测试生成的角色，就一段存在 SQL 注入漏洞的登录代码进行协作。安全审查智能体首先分析代码并生成安全建议，随后通过 MCP 协议调用测试生成智能体暴露的工具，测试生成智能体基于审查上下文自动生成针对 SQL 注入的测试用例。整个流程涉及节点发现、Agent Card 交换、A2A 消息交互、MCP 工具调用和 Handoff 任务交接，全部自动化完成。
项目现状与未来工作
目前，AI Mesh 项目已在 GitHub 上以 MIT 许可证开源。项目包含 42 个源文件，累计 22 个单元测试与集成测试用例全部通过。
系统当前支持的主要功能包括：基于 Ed25519 的身份管理与 JWS 签名的 Agent Card；基于 libp2p 的 P2P 传输与三级节点发现（mDNS、DHT、GossipSub）；A2A 与 MCP 双协议栈的完整实现；六种结构化协作模式；GitHub Webhook 集成与 WebSocket 实时仪表板；以及 Docker 一键部署支持。
未来的工作计划聚焦于以下几个方向。首先，部署公网 Bootstrap 节点，支持跨网络的智能体开箱即用。其次，完成 GitHub App 的 Marketplace 上架流程。再次，提供 Python 和 Go 语言的 SDK，降低非 Node.js 生态智能体的接入门槛。最后，启动 Rust 核心的迁移工作，以进一步降低协议层延迟并提升系统的资源利用效率。
总结
AI Mesh 项目探索了去中心化多智能体协作网络的一种可行架构。通过将 libp2p 作为传输层基础设施、A2A 和 MCP 作为协议层标准、结构化协作模式作为协作层抽象，系统为智能体提供了自主发现、通信与协作的网络能力。
与传统中心化编排方案相比，去中心化架构在系统可用性、水平扩展能力和跨组织互操作性方面具有理论优势。当前的实现与实验验证了核心设计假设的可行性，为后续工作奠定了基础。

https://github.com/zhouwneleee/ai-mesh.git我们还没有死。