3 篇文章带有标签 “agent2agent”

A2A ❤️ MCP

TLDR; Agentic applications need both A2A and MCP. We recommend MCP for tools and A2A for agents.

TLDR; 代理应用程序需要 A2A 和 MCP。我们建议将 MCP 用于工具,将 A2A 用于代理。

Why Protocols?(为什么需要协议?)

Standard protocols are essential for enabling agentic interoperability, particularly in connecting agents to external systems. This is critical in two interconnected areas of innovation: Tools and Agents.

标准协议对于实现代理互操作性至关重要,特别是在将代理连接到外部系统时。这在两个相互关联的创新领域中至关重要:工具和代理。

Tools are primitives with structured inputs and outputs and (typically) well-known behavior.

Agent2Agent 协议 (A2A)

A2A

一个开放协议,旨在实现不透明的智能代理应用程序之间的通信和互操作性。

企业采用人工智能的最大挑战之一是如何让基于不同框架和供应商构建的代理协同工作。这就是我们创建开放的 Agent2Agent (A2A) 协议的原因,这是一种协作方式,旨在帮助不同生态系统中的代理相互通信。Google 正在推动这项行业开放协议倡议,因为我们相信这个协议对于支持多代理通信至关重要,它将为您的代理提供一种通用语言——无论它们构建于哪个框架或供应商之上。借助 A2A,代理可以相互展示它们的功能并协商如何与用户交互(通过文本、表单或双向音频/视频)——所有这些都在安全地协同工作的同时进行。

观看 A2A 的实际应用

观看此演示视频,了解 A2A 如何实现不同代理框架之间的无缝通信。

概念概述

Agent2Agent (A2A) 协议促进了独立 AI 代理之间的通信。以下是核心概念:

  • 代理卡片 (Agent Card): 一个公开的元数据文件(通常位于 /.well-known/agent.json),描述了代理的功能、技能、端点 URL 和身份验证要求。客户端使用它进行发现。
    • A2A 服务器 (A2A Server): 一个公开 HTTP 端点并实现 A2A 协议方法(定义在 json 规范 中)的代理。它接收请求并管理任务执行。
    • A2A 客户端 (A2A Client): 一个消费 A2A 服务的应用程序或另一个代理。它向 A2A 服务器的 URL 发送请求(如 tasks/send)。
    • 任务 (Task): 中心的工作单元。客户端通过发送消息(tasks/sendtasks/sendSubscribe)来启动任务。任务具有唯一的 ID,并经历以下状态:submitted(已提交)、working(工作中)、input-required(需要输入)、completed(已完成)、failed(失败)、canceled(已取消)。
    • 消息 (Message): 表示客户端(role: "user")和代理(role: "agent")之间的通信轮次。消息包含 Parts(部件)。
    • 部件 (Part): MessageArtifact(工件)中的基本内容单元。可以是 TextPart(文本部件)、FilePart(文件部件,包含内联字节或 URI)或 DataPart(数据部件,用于结构化 JSON,例如表单)。
    • 工件 (Artifact): 表示代理在任务期间生成的输出(例如,生成的文件、最终的结构化数据)。工件也包含 Parts(部件)。
    • 流式传输 (Streaming): 对于长时间运行的任务,支持 streaming 功能的服务器可以使用 tasks/sendSubscribe。客户端接收服务器发送事件 (SSE),其中包含 TaskStatusUpdateEvent(任务状态更新事件)或 TaskArtifactUpdateEvent(任务工件更新事件)消息,提供实时的进度。
    • 推送通知 (Push Notifications): 支持 pushNotifications 的服务器可以主动向客户端提供的 webhook URL 发送任务更新,该 URL 通过 tasks/pushNotification/set 配置。