发帖
雷达卡
核心通信协议解析：MCP、A2A 与 AG-UI
在当今迅速发展的 AI Agent 生态系统中，一系列标准化协议正在快速出现，旨在应对智能体之间及与外部世界互动的复杂性。对于开发者来说，理解这些协议的核心设计哲学、技术实现及其相互关系，是构建可扩展、易维护且具备互操作性的下一代应用的关键。本章节将深入探讨三个处于核心地位的协议：模型上下文协议（MCP）、Agent-to-Agent 协议（A2A）以及 Agent-用户交互协议（AG-UI），它们分别构成了 Agent 能力的“连接层”、“协作层”和“交互层”。
模型上下文协议（Model Context Protocol, MCP）由 Anthropic 发起，并已获得 OpenAI、Google DeepMind 等巨头的支持，被视为 AI 领域的“USB-C接口” [1 [1] ,?3 [2] ]。其基本目标是标准化大型语言模型（LLM）或 Agent 与外部工具、数据源和 API 的交互方式 [12 [3] ,?37 [4] ]。通过引入一个通用的接口，MCP 使得 Agent 能够动态地发现、选择并执行所需的操作，从而摆脱了传统提示工程中静态、硬编码的工具调用模式 [51 [5] ]。MCP 采用客户端-服务器架构，其中 Host（通常是 LLM 应用）、Client（负责桥接和翻译指令）和 Server（封装具体的工具或数据服务）协同工作 [13 [6] ,?51 [7] ]。其核心消息格式基于 JSON-RPC 2.0，支持通过 HTTP、WebSocket 甚至 Stdio 等多种传输协议进行通信 [3 [8] ,?10 [9] ]。MCP 的设计初衷并非为了Agent-to-Agent 的直接通信，因此在早期版本中存在一些局限性，例如缺乏细粒度的流式传输、不支持跨服务器共享内存、以及对消息体结构的约束较弱等问题 [2 [10] ]。然而，随着 v2025-06-18 版本的发布，MCP 增加了对 HTTP Streaming 和 Token-based authentication 的支持，显著提升了其与外部系统的互操作性和安全性 [13 [11] ]。尽管如此，它在处理复杂的多 Agent 任务编排时仍显不足，这正是其他协议发挥作用的地方。
Agent-to-Agent 协议（Agent-to-Agent Protocol, A2A）由 Google 于 2025 年发起，并得到了超过 50 家科技企业的广泛支持，现已成为 Linux Foundation 下的开源项目 [5 [12] ,?9 [13] ]。A2A 的核心任务是解决多 Agent 系统中普遍存在的“N-squared”集成难题，即在一个包含 n 个 Agent 的系统中，需要$O(n^2)$个点对点的集成连接 [4 [14] ,?47 [15] ]。A2A 通过一套标准化的任务生命周期管理和能力发现机制，让来自不同厂商、运行在不同框架下的 Agent 能够无缝协作 [43 [16] ]。该协议的核心组件是“Agent Card”，这是一个机器可读的 JSON 文档，类似于 Agent 的数字名片，详细描述了其身份、端点、认证要求以及可用的能力（Skills）[4 [17] ,?45 [18] ]。当一个 Agent 需要与其他 Agent 协作时，它可以先通过查询 Agent Card 来发现潜在的合作者。任务本身被建模为“Task Objects”，具有明确的生命周期状态（如
submittedworkingcompletedfailedAgent-用户交互协议（Agent-User Interaction Protocol, AG-UI）则专注于解决 Agent 后端逻辑与前端用户界面之间的实时、双向同步问题。传统的聊天机器人模式往往依赖于简单的请求-响应循环，无法有效支持需要复杂用户反馈、进度展示或动态 UI 更新的互动场景 [8 [26] ]。
AG-UI 通过一个简化的事件流来打破这一僵局，它定义了一系列标准化的 JSON 事件类型，通过 HTTP 或 WebSocket 以 Server-Sent Events (SSE) 的形式从 Agent 后端持续推送到前端 [39 [27] ,?69 [28] ]。这些事件类型涵盖了从文本流式输出（
TEXT_MESSAGE_CHUNKTOOL_CALL_STARTSTATE_DELTA协议 核心目标 治理机构 架构模型 关键技术/组件 生态系统成熟度 MCP 标准化 LLM/Agent 与外部工具/数据的连接 [37 [34] ] Anthropic 主导，社区驱动 [78 [35] ] Hub-and-Spoke [5 [36] ] JSON-RPC 2.0, OAuth 2.0 [3 [37] ,?16 [38] ] 高 (已有大量预建连接器) [37 [39] ] A2A 标准化 Agent 间的协作与任务编排 [47 [40] ] Linux Foundation [5 [41] ] Point-to-Point (with Orchestration needed at scale) [4 [42] ] Agent Card, Task Lifecycle, Parts & Artifacts, SSE [43 [43] ] 极高 (Google, IBM, Salesforce, SAP 等巨头支持) [5 [44] ] AG-UI 标准化 Agent 后端与前端用户的实时交互 [8 [45] ] CopilotKit [69 [46] ] Client-Server (for UI) [69 [47] ] Server-Sent Events (SSE), Custom JSON Events [69 [48] ] 中等 (新兴协议，正在快速增长)
协议融合与分层架构：从碎片化到统一标准
在 AI Agent 协议发展的初期，市场上曾涌现出多个并行的规范，例如 IBM 的 Agent Communication Protocol (ACP) 和 Google 的 Agent2Agent (A2A) 协议。这两种协议在目标上高度一致，均致力于解决 Agent 间的互操作性问题，但其技术细节和治理背景有所不同 [5
[49]
,?42
[50]
]。ACP 最初由 IBM 推出，强调 REST/HTTP-native 设计，追求极简的实现方式和框架无关性，旨在成为“AI Agents 的 HTTP” [5
[51]
,?8
[52]
]。而 A2A 则由 Google 主导，拥有庞大的产业联盟支持，功能更为全面，特别注重企业级的安全性、任务生命周期管理和多模态通信 [5
[53]
,?43
[54]
]。这种并存的局面虽然促进了竞争和创新，但也给开发者带来了选择困难，并可能导致生态系统的碎片化。
市场的演进很快给出了答案。2025 年下半年，业界发生了一项关键性事件：IBM 宣布 ACP 将与 A2A 协议合并，共同纳入 Linux Foundation under umbrella，形成一个统一的标准 [5 [55] ]。这次合并并非简单的收购，而是旨在整合两家公司的优势，创建一个更强大、更具包容性的协议。新的 A2A 协议将吸收 ACP 的简洁性与开放精神，并保留 A2A 原有的丰富功能和强大的生态系统背书 [5 [56] ]。这一举措极大地简化了开发者的决策过程，减少了因协议选择不当而导致的投资风险，也为整个 AI Agent 行业建立了一个坚实、统一的通信基础。对于开发者而言，这意味着可以将精力集中在一个主导性的 Agent-to-Agent 通信标准上，从而加速应用的开发和部署。
这一融合的背后，体现了行业对于构建分层、模块化 Agent 系统的共识。一个理想的现代 Agent 应用架构并非由单一协议支撑，而是呈现出明确的层次结构，每一层对应不同的职责和抽象层级。这种分层方法不仅逻辑清晰，还能最大化系统的灵活性、可扩展性和维护性。
第一层是 模型增强层 (Model Enhancement Layer) ，其核心是 MCP。这一层主要关注“单个 Agent 如何获得能力”的问题，即如何将其与外部世界连接起来。无论是访问内部数据库、调用 CRM 系统，还是获取实时天气信息，都需要通过 MCP 这样的协议来实现标准化的工具调用和数据检索 [5 [57] ,?37 [58] ]。可以说，MCP 是赋予 Agent 感知与行动能力的基础。
第二层是 Agent 协作层 (Agent Collaboration Layer) ，其核心是统一后的 A2A 协议。在 Agent 具备基本能力之后，复杂的任务通常需要多个 Agent 的协作才能完成。A2A 协议在此层扮演着“调度员”和“协调者”的角色，它定义了 Agent 之间如何发现彼此、协商任务、传递消息以及管理长周期的工作流 [5 [59] ,?47 [60] ]。无论是公司内部不同部门的 Agent 合作，还是跨越组织边界的合作伙伴 Agent 协同，都依赖于 A2A 提供的一套标准化沟通语言。
第三层是 用户交互层 (User Interaction Layer) ，其核心是 AG-UI 协议。当 Agent 系统需要与最终用户进行互动时，AG-UI 就显得至关重要。它负责将 Agent 后端生成的复杂状态和信息，以一种实时、动态、易于理解的方式呈现给用户 [8 [61] ,?70 [62] ]。无论是在代码编辑器中实时生成代码片段，还是在数据分析仪表盘上动态更新图表，或是自动化报销审批流程中的用户确认，AG-UI 都确保了人机互动的流畅与高效。
在这种分层架构下，一个典型的生产级 Agent 系统可能会这样运作：一个销售 Agent（Agent A）通过 MCP 连接到公司的 Salesforce CRM 系统，获取客户信息 [1 [63] ]。当需要为客户制定一份详细的 IT 解决方案时，Agent A 通过 A2A 协议向一个专门的解决方案设计 Agent（Agent B）发送任务请求 [5 [64] ]。Agent B 在执行过程中，通过 A2A 的流式通信机制将设计进度实时反馈给 Agent A。最后，当方案完成后，Agent A 通过 A2A 将结果呈现给用户，并启动一个由 AG-UI 驱动的交互流程，让用户审查、批准或提出修改意见 [70 [65] ]。在这个例子中，MCP、A2A 和 AG-UI 各司其职，紧密配合，共同构建了一个完整、高效且可扩展的 Agent 应用。这种架构不仅适用于内部业务流程，也适用于更广泛的跨企业应用场景，如供应链自动化或联合客户服务 [9 [66] ,?53 [67] ]。
商业化基础设施：信任与支付协议 AP2、x402 与 ERC-8004
随着 AI Agent 从实验性项目走向实际的商业应用，一个至关重要的挑战浮现出来：如何让 Agent 安全、可信地进行经济交易。自主采购、API 按需付费、机器对机器（M2M）的服务市场等场景，都对 Agent 支付协议提出了迫切需求。为此，一系列围绕信任、授权和支付的协议应运而生，其中最具代表性的是由 Google 牵头的 Agent Payments Protocol (AP2)，以及在 Web3 原生社区兴起的 x402 和 ERC-8004。
Agent Payments Protocol (AP2) 是一个旨在为 Agent 驱动的商业活动建立开放、安全、可审计框架的行业标准 [17 [68] ]。它并非一个孤立的支付协议，而是被设计为 A2A 和 MCP 协议的扩展，意在解决 Agent 商业化面临的三大核心挑战：授权（Authorization）、真实性（Authenticity）和问责制（Accountability）[17 [69] ,?18 [70] ]。AP2 的核心创新在于引入了“Mandates”——一种基于 W3C Verifiable Credentials 的、由多方签名的数字合同 [19 [71] ]。在一次交易中，用户会首先签署一个“Intent Mandate”，授权 Agent 在其设定的边界内（如价格上限、购买品类）自主行动 [18 [72] ,?57 [73] ]。当 Agent 找到合适的商品并生成购物车后，用户会再签署一个“Cart Mandate”，这是对具体交易内容的最终确认，形成了一个不可否认的法律证据链 [18 [74] ,?19 [75]
这种基于 Verifiable Credentials 的机制，确保了每一笔交易都有明确的归属和意图证明，从根源上解决了 Agent 自主行为的合规性问题。AP2 的优势在于其获得了超过 60 家顶级企业和金融机构的强大支持，包括 Mastercard、American Express、PayPal、Coinbase、Salesforce 和 ServiceNow 等 [17 [76] ,?57 [77] ]。这表明 AP2 不仅是一个技术提案，更是一个符合全球支付行业标准的、面向未来的商业化基础设施，为 Agent 驱动的电子商务、自主采购和订阅服务铺平了道路。
与此同时，在 Web3 和区块链社区，一种完全不同的范式正在形成，其核心是 x402 和 ERC-8004 这两个协议。x402 是一个轻量级互联网协议，它巧妙地激活了自 1999 年以来一直未被广泛使用的 HTTP 402 "Payment Required" 状态码 [74 [78] ,?75 [79] ]。x402 允许资源提供方（如一个 API 服务）在需要付费时，返回一个带有支付要求的 402 响应。请求方（如一个 AI Agent）收到此响应后，可以直接附带加密货币支付的 Payload 来尝试获取资源，整个过程无需账户、会话或复杂的前端交互，非常适合程序化的、机器对机器的微支付场景 [55 [80] ,?74 [81] ]。它被设计为链无关（chain-agnostic）和代币无关，旨在降低 Web3 支付的门槛 [74 [82] ]。
如果说 x402 解决了“如何支付”的问题，那么 ERC-8004 则致力于解决“信任谁”和“如何验证”的问题。ERC-8004 是一个在以太坊社区提出的 EIP 标准，旨在为 AI Agent 提供一个去中心化的“信任层” [25 [83] ,?27 [84] ]。它通过三个核心的 On-chain Registry 来实现这一目标：Identity Registry、Reputation Registry 和 Validation Registry [61 [85] ]。Identity Registry 使用 ERC-721 NFT 为每个 Agent 分配一个独一无二的、可移植的身份标识 [34 [86] ]。Reputation Registry 记录了 Agent 的行为反馈，而 Validation Registry 则允许第三方验证 Agent 工作的正确性，例如通过重计算或使用可信执行环境（TEE） [61 [87] ]。这三个 Registry 共同构成了 Agent 的“数字护照”和“信用报告”，使其能够在开放网络中进行可信的协作和交易，而无需依赖任何中心化的中介。
x402 和 ERC-8004 并非相互竞争，而是形成了一个功能互补的生态系统。一个完整的去中心化 Agent 交易流程可能是这样的：Agent A（客户端）通过 ERC-8004 的 Identity 和 Reputation Registry 发现并评估 Agent B（服务提供者）。两者达成协议后，Agent A 使用 x402 协议发起支付，资金被锁定在一个智能合约中。Agent B 完成任务后，其结果被提交至 ERC-8004 的 Validation Registry 进行验证。一旦验证成功，智能合约就会自动将 x402 支付的费用释放给 Agent B [28 [88] ,?33 [89] ]。这个闭环实现了“无工作，无报酬”的原则，并将信任、支付和验证完全置于透明、不可篡改的区块链之上。这种 Web3 原生的范式为构建开放、抗审查的 Agent 经济体系提供了全新的可能性，尤其是在那些传统金融体系难以覆盖的领域。
| 协议 | 提出方/背景 | 核心机制 | 主要特点 | 适用场景 |
|---|---|---|---|---|
| AP2 | Google (Linux Foundation) | Verifiable Credentials ("Mandates") [19 [90] ] | 行业联盟驱动, 支付方法多样(卡, 稳定币), 强调合规与审计 [17 [91] ,?18 [92] ] | 企业级 Agent 商业交易, 自主采购, Web2 电商自动化 |
| x402 | Coinbase / Web3 社区 | HTTP 402 "Payment Required" 状态码 [75 [93] ] | 链无关, 微支付友好, 无需账户/会话, gasless交易 [74 [94] ,?76 [95] ] | API 按需付费, M2M 服务市场, 去中心化应用中的 Agent 支付 |
| ERC-8004 | Ethereum Foundation / MetaMask | On-chain Registries (Identity, Reputation, Validation) [25 [96] ] | 去中心化的信任层，适用于 AI Agent 的身份验证和声誉管理 [25 [83] ,?27 [84] ] | 去中心化应用中的 AI Agent 交互与协作 |
去中心化, 可组合, 抗审查, 提供 Agent 身份和信誉基础 [27 [97] ,?34 [98] ]
去中心化的 Agent 市场, DeFi 自动化, 以及在 DAO 治理中的 Agent 参与
其他重要协议与框架的评述
除了 MCP、A2A、AG-UI 和 AP2/x402/ERC-8004 等协议外，AI Agent 生态系统中还出现了许多值得重视的协议、框架和概念。这些协议或在特定领域提供了独特的解决方案，或是未来发展方向的一部分，共同构成了日益复杂的基础设施图景。本节将对 Agent Network Protocol (ANP)、Task Definition Format (TDF)、Open Agent Protocol (OAP) 以及其他提及的协议进行评述。
Agent Network Protocol (ANP) 是一个极具雄心的协议，其愿景是成为“Agent 互联网时代的 HTTP” [63 [99] ,?64 [100] ]。ANP 的设计理念与 MCP 所强调的“模型为中心”的视角不同，它提倡一种“以 Agent 为中心”的世界观，认为 Agent 应该作为网络中的平等参与者，而不仅仅是 LLM 的工具 [78 [101] ]。ANP 的核心架构分为三层：身份和加密通信层（基于 W3C DID）、元协议层（用于动态协议协商）以及应用协议层（基于语义网技术描述能力）[63 [102] ,?65 [103] ]。它旨在打破数据孤岛，使 Agent 能够自动发现和组织自己，实现高效的协同工作 [65 [104] ]。尽管 ANP 的理念先进且具有吸引力，但与目前由大公司主导的协议生态（如 A2A）相比，其实现路径更为理想化，面临的采纳和标准化挑战也更大。当前来看，ANP 更像是一个探索性和理论上的参考架构，而非广泛应用的工业标准。
在更高层次的抽象层面，我们看到一些旨在简化 Agent 开发和集成的框架与格式。Task Definition Format (TDF) 是一种声明性协议，专注于将复杂目标分解为可组合的任务和子任务，为 Agent 的规划和协作提供了一个标准化的框架 [12 [105] ,?14 [106] ]。它关注的是“做什么”和“怎么做”的宏观层面，与 A2A 等关注“如何通信”的微观协议相辅相成。Open Agent Protocol (OAP) 则是一个更偏向于工程实践的开源框架，基于 LangGraph 构建，旨在通过简化 API 集成、提供可视化调试界面等方式，降低在不同 Agent 框架（如 LangChain, AutoGen, CrewAI）之间开发的门槛 [12 [107] ,?14 [108] ]。OAP 本身不是一个通信协议，但它通过整合现有的通信协议（尤其是 MCP），为开发者提供了一个更高级别的抽象，使他们可以更加专注于业务逻辑而非底层通信细节。类似地，RDF-Agent 利用 W3C Semantic Web 技术（如 RDF, SPARQL）实现基于知识图谱的 Agent 推理，强调语义互操作性，特别适用于需要深度知识理解和推理的企业知识库场景 [12 [109] ,?14 [110] ]。
此外，还有一些协议名称在资料中出现，但其具体细节尚不明确。例如，Tool Abstraction Protocol (TAP) 和 Function Call Protocol (FCP) 都旨在解决工具调用的标准化问题，前者侧重于工具的描述和暴露，后者则强调函数调用的 Schema 强制执行，二者都可以视为 MCP 理念的延伸或补充 [12 [111] ,?14 [112] ]。Agent Gateway Protocol (AGP) 由 Cisco 的 Outshift initiative 提出，定位为 Agent 与外部系统之间的“网关”，强调高吞吐量、强安全性和可观测性，适用于云和边缘环境中的大规模 Agent 网格 [12 [113] ,?15 [114] ]。而像 FIPA ACL 这样的早期协议，则因其平台耦合度高和语义复杂，在现代 Web-centric 的开发范式中已被边缘化 [7 [115] ]。
对于开发人员而言，理解这些协议的相互关系十分重要。一个完整的 Agent 系统通常并不是基于单一协议构建的，而是由多种协议和框架组成的有机整体。例如，企业级的 Agent 应用可能会使用 MCP 连接内部系统，通过 A2A 协调不同部门之间的 Agent 团队，利用 TDF 完成高层次的任务规划，并借助 OAP 框架简化开发与调试过程。此外，如果涉及商业交易，则 AP2 或 x402 是必不可少的组成部分。因此，开发者需要具备全面视野，根据具体应用场景、技术栈和业务需求灵活选择并组合这些协议与工具，构建既强大又稳健的 Agent 系统。
实践指南与未来趋势展望
面对一个快速演变、多种协议不断融合的 AI Agent 生态系统，开发人员需要采取明智策略以抓住机遇并规避风险。本章将提供一套针对开发者的实践指南，并对该领域未来的趋势进行展望，帮助开发者更好地应对挑战，把握方向。
首先，
采用分层架构是首要原则。
不要期望找到一个能解决所有问题的“万灵药”协议。相反，应从一开始为系统设计明确的分层结构，将 MCP、A2A 和 AG-UI 视作构建现代 Agent 应用的基础构件。这种架构不仅逻辑清晰，还能最大程度提高系统的模块化性、可扩展性和维护便利性。建议开发者优先投资于学习和掌握 A2A 协议，鉴于ACP 已并入 A2A，后者实际上已成为 Agent-to-Agent 通信的标准主导者，掌握了它就掌握了 Agent 合作的核心 [5 [116] ,?67 [117] ]。同时，应紧密关注 AP2 和 x402/ERC-8004 生态的进展，因为它们分别代表了中心化和去中心化的商业化路径。开发者应根据自身应用场景（如是否需要满足严格的金融监管要求，或者是否服务于 Web3 原生应用）做出战略决策。
其次，
实施策略应逐步推进。
直接构建一个复杂的、全面的 Agent 系统通常是困难的。更安全的做法是从一个小范围的试点项目起步，逐渐扩大规模 [47 [118] ]。例如，可以从简单场景开始：让一个 Agent 通过 MCP 连接到内部 API，然后借助 A2A 实现与其他本地 Agent 的基本任务交接。在开发过程中，充分利用官方和社区提供的 SDK、参考实现及模板可以显著降低入门难度 [43 [119] ,?53 [120] ,?70 [121] ]。例如，Google ADK、IBM BeeAI 和 CopilotKit 均提供了丰富的工具集，有助于开发者迅速搭建原型 [43 [122] ,?53 [123] ,?70 [124] ]。此外，为了应对未来可能出现的协议演变或混合环境，设计一个抽象层或协议转换网关是一个非常明智的选择。这个网关可以隐藏底层协议复杂性，使上层应用无需关注具体的通信细节，从而保护开发投资不受未来技术变迁影响 [1 [125] ,?42 [126] ]。
展望未来，AI Agent 协议生态系统将继续向几个关键方向发展。
协议的进一步整合与融合将是常态。
我们可能会见证更多像 A2A+ACP 那样的合并案例，以及 AP2 与 x402 生态在未来可能出现的合作与互操作性标准。
内置协议感知能力也将成为 LLM 的一个重要发展趋向，未来的模型可能被训练以理解任务需求，并自动选择最合适的协议进行交互。
性能优化将是另一个关注点，随着 Agent 规模的扩大和复杂度的增加，对协议延迟、吞吐量及资源消耗的要求将越来越高，这可能会促进更高效的二进制协议或压缩方案的发展。最重要的是，
安全与合规性将进一步增强。
随着 Agent 执行更多关键任务，针对 Agent 通信的新类型攻击（如利用 LLM 特定弱点的 prompt injection 或 sycophancy 攻击）将成为安全研究的重点 [31 [127] ]。相应地，将不断完善安全协议、漏洞修复机制和治理框架，以确保 Agent 生态系统的健康与稳定。
总而言之，AI Agent 协议正处于一个从多样化的探索阶段向由分层架构和核心协议主导的稳定期转变的关键时刻。对于开发人员而言，现在正是深入了解这一新兴基础设施范式的最佳时机。通过掌握 MCP、A2A、AG-UI 等关键技术，并结合 AP2/x402 等商业化工具，开发者将能够创建真正具有变革潜力的智能应用，引领人工智能进入一个更加协作、自主和包容的新时代。
References
[1]链接到文章：开放标准的AI代理——A2A、MCP、LangChain代理协议的技术对比
[3][4][5][6][7][8]再次链接到文章：开放标准的AI代理——A2A、MCP、LangChain代理协议的技术对比
[9][10][11][12][13][14]链接到HiveMQ博客文章：企业级规模的智能AI协作——A2A第一部分
[15]链接到OneReach AI博客文章：什么是A2A——代理对代理协议？
[16]链接到Google Cloud中等文章：了解A2A——代理协作协议
[17]再次链接到HiveMQ博客文章：企业级规模的智能AI协作——A2A第一部分
[18]链接到Google Codelabs：入门A2A——购买礼宾服务
[19]链接到Akka博客文章：MCP、A2A和ACP——这一切意味着什么？
[20]再次链接到Google Cloud中等文章：了解A2A——代理协作协议
[21]再次链接到文章：开放标准的AI代理——A2A、MCP、LangChain代理协议的技术对比
[22]再次链接到Google Cloud中等文章：了解A2A——代理协作协议
[23]再次链接到Google Cloud中等文章：了解A2A——代理协作协议
[24]1:
[47]69:
[48]69:
[49]5:
[50]42:
[51]5:
[52]8:
[53]5:
[54]43:
[55]5:
[56]5:
[57]5:
[58]37:
[59]5:
[60]47:
[61]8:
[62]70:
[63]1:
[64]5:
[65]70:
[66]9:
[67]53:
[68]17:
[69]17:
18:
19:
18:
57:
18:
19:
17:
57:
74:
75:
55:
74:
74:
25:
27:
61:
34:
61:
28:
33:
17:
18:
75:
74:
76:
25:
27:
34:
63:
64:
78:
63:
65:
65:
12:
14:
12:
14:
12:
14:
[112]14:
[113]12:
[114]15:
[115]7:
链接到Aisera博客关于A2A（Agent-to-Agent）协议的文章
[116]5:
链接到Dotsquare实验室资源页面，讨论ACP和A2A的联合
[117]67:
链接到Agent Communication Protocol网站介绍页
[118]47:
链接到OneReach博客关于A2A（Agent-to-Agent）协议的文章
[119]43:
链接到Google Cloud Medium文章，了解A2A代理协作协议
[120]53:
链接到Harshit Sinha在Medium上的文章，解析代理通信协议ACP
[121]70:
链接到CopilotKit博客关于使用AG UI构建ADK代理前端的文章
[122]43:
链接到Google Cloud Medium文章，了解A2A代理协作协议
[123]53:
链接到Harshit Sinha在Medium上的文章，解析代理通信协议ACP
[124]70:
链接到CopilotKit博客关于使用AG UI构建ADK代理前端的文章
[125]1:
[126]42:
链接到Dotsquare实验室资源页面，比较AI代理通信协议
[127]31:
京公网安备 11010802022788号
