1 - A2A 核心概念

A2A 核心概念

https://google-a2a.github.io/A2A/topics/key-concepts/

其他内容待继续


Agent2Agent(A2A)协议是围绕一组定义代理如何交互的核心概念构建的。理解这些概念对于开发或集成 A2A 兼容系统至关重要。

核心参与者

  • User: 发起需要 agent 协助的请求或目标的最终用户(人工或自动服务)。
  • A2A 客户端(客户端代理): 代表用户向远程代理请求操作或信息的应用程序、服务或其他 AI 代理。客户端使用 A2A 协议发起通信。
  • A2A 服务器(远程代理): 一个 AI 代理或代理系统,公开实现 A2 A 协议的 HTTP 端点。它接收来自客户端的请求,处理任务,并返回结果或状态更新。从客户端的角度来看,远程代理作为一个“不透明”系统运行,这意味着客户端不需要知道它的内部工作、内存或工具。

基本通信元素

  • Agent Card: 代理卡

    • JSON 元数据文档,通常可在众所周知的 URL(例如,/.well-known/agent.json),它描述了 A2 A 服务器。
    • 它详细说明了代理的身份(名称、描述)、服务端点 URL、版本、支持的 A2A 功能(如流或推送通知)、它提供的特定技能、默认输入/输出模式和身份验证要求。
    • 客户使用代理卡来发现代理并了解如何安全有效地与他们互动。
    • 详见方案规范:代理卡 。
  • Task: 任务

    • 当客户端向代理发送消息时,代理可以确定满足请求需要完成有状态任务(例如,“生成报告”、“预订航班”、“回答问题”)。
    • 每个任务都有一个由代理定义的唯一 ID,并在定义的生命周期中进行(例如, 已提交 、 正在工作 、 需要输入 、 已完成 、 失败 )。
    • 任务是有状态的,可以涉及客户端和服务器之间的多个交换(消息)。
    • 详见协议规范:任务对象 。
  • 消息

    • 表示客户端和代理之间的单轮或单单元通信。
    • 消息有一个角色 (客户端发送消息的 “用户” 或服务器发送消息的 “代理”),并包含一个或多个携带实际内容的 Part 对象。Message 对象的 messageId 部分是由消息的发送者为每个消息设置的唯一标识符。
    • 用于传达不一定是正式工件的指令、上下文、问题、答案或状态更新。
    • 详见协议规范:消息对象 。
  • 部件

    • 消息或文件中内容的基本单位。每个部分都有特定的类型 ,并且可以携带不同类型的数据:
    • TextPart:包含纯文本内容。
    • FilePart:表示一个文件,它可以作为内联 base64 编码的字节传输,也可以通过 URI 引用。包括文件名和媒体类型等元数据。
    • DataPart:携带结构化 JSON 数据,用于表单、参数或任何机器可读信息。
    • 详见协议规范:部件对象 。
  • Artifact

    • 表示远程代理在任务处理期间生成的有形输出或结果。
    • 示例包括生成的文档、图像、电子表格、结构化数据结果或作为任务的直接结果的任何其他自包含信息。
    • 工件由一个或多个 Part 对象组成,并且可以以增量方式流式传输。
    • 详见协议规范:工件对象 。

交互机制

Request/Response (Polling)

请求/响应(轮询):

  • 客户端发送请求(例如,使用消息/发送 RPC 方法)并从服务器接收响应。

  • 如果交互需要一个有状态的长时间运行的任务,服务器最初可能会响应一个工作状态。客户端然后将周期性地调用 tasks/get 以轮询更新,直到任务到达终端状态(例如, 完成 , 失败 )。

流(服务器发送事件- SSE)

2 - 什么是 A2A?

什么是 A2A?

https://medium.com/@akash22675/what-is-a2a-agent-to-agent-protocol-d2325a41633a


代理到代理协议(Agent to Agent Protocol / A2A) 是一个标准化的通信框架,使 AI agent 代理能够以一致、可预测的方式相互交互。A2A 由 Google 发布,并被包括 Intuitive,LangChain 和 MongoDB 在内的多家公司采用,它为不同的 AI agent 提供了基础设施,以便在复杂的任务上进行有效的协作。

A2A 协议的核心概念

A2A 解决了什么问题?

在现代人工智能应用中,复杂的任务通常需要多个专业代理的专业知识。例如,计划旅行可能涉及专门从事机票预订,酒店推荐和当地活动的代理商。如果没有标准化的协议,这些代理中的每一个都需要自定义集成代码来相互通信,从而导致:

  • 不一致的通信模式
  • 不兼容的数据格式
  • 维护和更新困难
  • 有限的互操作性

A2A 通过为代理建立标准方法来解决这些问题:

  • 发现彼此的能力
  • 交换信息
  • 协作处理任务
  • 处理错误和异常

A2A 与 MCP(模型上下文协议)

虽然这些协议看起来相似,但它们用于不同的目的:

  • MCP(Model Context Protocol)

    专注于语言模型如何与工具和资源(如 API、数据库和知识源)进行通信。把 MCP 看作是机械师如何与他们的工具进行交互,您可以在这里阅读更多上下文。

  • A2A

    A2A(Agent to Agent Protocol):专注于完整的代理(每个代理包含一个 LLM 加上工具)如何相互通信。A2A 是机械师与客户或零件供应商沟通的方式。

一个有用的类比:如果一个代理就像一个汽车维修人员(LLM)与他们的工具箱(通过 MCP 连接的工具),那么 A2A 定义了这个汽车维修人员如何与客户,零件供应商和其他专家进行沟通。

A2A 的主要组成部分

Agent Card

代理卡是代理用来向其他代理通告其能力的标准化描述。将 Agent Card 视为名片或个人资料,其中包括:

代理卡示例(JSON 格式):

{
  "name": "Google Maps Agent",
  "description": "An agent that helps with map-related tasks",
  "url": "https://maps-agent.example.com",
  "provider": {
    "name": "Google",
    "url": "https://google.com"
  },
  "capabilities": [
    {
      "type": "route_planning",
      "description": "Plan routes between locations"
    },
    {
      "type": "custom_map",
      "description": "Create custom maps with points of interest"
    }
  ]
}

代理发现

为了让代理进行协作,它们首先需要发现彼此。A2A 支持多种发现方法:

  • 基于 DNS 的发现 :客户端可以通过解析域名找到 agent.json 文件来发现代理。
  • 基于注册表的发现 :应用程序维护受信任代理的注册表。
  • 私有发现 :已知代理端点的直接配置。

任务处理流程

A2A 协议定义了代理之间的任务处理的标准流程:

A2A 中的任务遵循标准格式,通常用 JSON 表示:

{
  "task": {
    "input": "Tell me a joke",
    "instructions": "Generate a short, family-friendly joke"
  }
}

通信协议

A2A 基于已建立的通信协议:

  • HTTP/HTTPS:用于基本的请求/响应通信
  • JSON-RPC:用于结构化方法调用
  • 服务器发送事件(Server-Sent Events / SSE):用于流响应
  • JSON:作为标准数据交换格式

高级功能

A2A 支持多个高级功能,可实现强大的 agent 交互:

  • 多模式通信 :处理文本、图像、音频和其他数据类型
  • 流 :对长时间运行的任务进行实时流响应
  • 错误处理 :标准化的错误格式,以便更好地调试
  • 澄清请求 :agent 提出后续问题的能力

实用 A2A 实现

让我们看看 A2A 在实际实现中的样子:

示例:报销代理

// Agent Card Definition
const agentCard = {
  name: "Expense Reimbursement Agent",
  description: "An agent that processes expense reimbursement requests",
  url: "https://reimbursement.example.com",
  provider: {
    name: "Financial Services Inc.",
    url: "https://financial-services.example.com"
  },
  capabilities: [
    {
      type: "process_reimbursement",
      description: "Process expense receipts and generate reimbursement forms"
    }
  ]
};

// Agent Implementation
class ReimbursementAgent {
  constructor() {
    this.llm = new GeminiModel("gemini-2.0-flash");
    this.tools = [
      new ReceiptParser(),
      new PolicyValidator(),
      new FormGenerator()
    ];
  }
  
  async processTask(task) {
    // Process the task using LLM and tools
    const parsedReceipt = await this.tools[0].execute(task.input);
    const validationResult = await this.tools[1].execute(parsedReceipt);
    
    if (validationResult.needsClarification) {
      return {
        type: "clarification_request",
        question: validationResult.question
      };
    }
    
    const reimbursementForm = await this.tools[2].execute(validationResult);
    return {
      type: "task_complete",
      result: reimbursementForm
    };
  }
}

真实世界的 A2A 工作流程示例

为了更好地理解 A2A 的实际应用,让我们来看看一个真实的示例:

在本例中:

  • HR 经理在 Google Agent Workspace 中与客户端代理交互
  • 客户端代理发现并与专门的代理进行通信,以确定候选人来源和安排面试
  • 代理商在需要时提出澄清问题
  • 每个代理使用自己的工具和资源执行其专门功能
  • 客户端代理协调整个工作流并将结果呈现给用户

A2A 协议的优点

  • 标准化通信 :代理交互的一致方式,无需自定义集成
  • 可组合性 :易于联合专用代理以执行复杂任务
  • 发现 :发现可用代理及其能力的机制
  • 互操作性 :来自不同提供商的代理可以一起工作
  • 可扩展性 :新的代理类型可以加入生态系统

现状和未来潜力

Agent to Agent Protocol 仍处于早期阶段,最近由 Google 发布。虽然许多公司已经开始采用该协议,但该协议的全面影响和演变将随着时间的推移而展开。

主要发展领域包括:

  • 安全和认证标准
  • 更复杂的代理发现机制
  • 高级错误处理和恢复
  • 跨平台代理兼容性
  • 与现有 AI 生态系统的整合

Agent to Agent Protocol(A2A)是创建更具协作性的人工智能生态系统的重要一步。通过标准化代理之间的通信方式,A2A 可以实现更复杂的多代理解决方案,而无需为每个代理配对进行自定义集成。