A2A 协议中的 Agent Card 是什么？它在多 Agent 发现和协作中起什么作用？

参考答案

Agent Card 是 A2A 协议里的核心概念，本质上就是 Agent 的”电子名片”。它是一份标准化的 JSON 文档，描述了一个 Agent 的身份信息、能力范围、支持的交互模式和访问入口。

在多 Agent 系统里，Agent Card 解决的是一个最基础的问题：Agent 之间怎么找到彼此、怎么知道对方能干啥。就像你进一家新公司，得先摸清各个部门和同事都负责什么，有事才知道找谁。Agent Card 就是让每个 Agent 自报家门的标准格式。

Agent Card 发布在一个约定好的 URL 路径下 /.well-known/agent-card.json，其他 Agent 或管理平台直接读这个文件就能发现并了解它。一份 Agent Card 主要包含：Agent 的名称和描述、它擅长处理的任务类型、支持的输入输出格式、认证方式、通信端点地址。

Agent Card 在协作中覆盖三个环节：

发现阶段，管理平台或其他 Agent 通过 Agent Card 知道系统里有哪些可用的 Agent；
选择阶段，根据 Card 里描述的技能匹配最适合当前任务的 Agent；
调用阶段，按 Card 里声明的通信方式和认证要求发起请求。

扩展知识

Agent Card 的结构详解

下面是一个教学用的简化示例，真实字段以 A2A 官方规范为准：

▼

json

复制代码

{
  "name": "数据分析 Agent",
  "description": "擅长数据清洗、统计分析和可视化，支持 CSV、Excel 和 SQL 数据源",
  "url": "https://data-agent.example.com",
  "version": "1.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  },
  "skills": [
    {
      "id": "data-analysis",
      "name": "数据分析",
      "description": "对结构化数据进行统计分析并生成报告",
      "inputModes": ["text", "file"],
      "outputModes": ["text", "file"]
    }
  ],
  "authentication": {
    "schemes": ["OAuth2"]
  }
}

这份 Card 告诉其他 Agent：我是个数据分析专家，能处理文本和文件输入，支持流式输出，走 OAuth2 认证。

几个关键字段值得注意：

skills 数组是能力声明的核心，一个 Agent 可以有多项技能，每项技能独立声明输入输出模式。
capabilities 声明的是通信能力，比如支不支持流式响应、能不能接收推送通知，直接决定了调用方的交互策略。

动态发现和能力匹配

在大规模多 Agent 系统里，Agent 数量可能有几十上百个，手动配置每个 Agent 的信息不现实。Agent Card 配合服务注册中心，就能做到自动化发现和匹配。

这个机制和微服务架构里的服务注册发现一个路子。每个 Agent 启动时把自己的 Agent Card 注册上去，其他 Agent 需要协作时去注册中心搜合适的伙伴。Google 在 2024 年 4 月发布 A2A 协议时，就明确把这个机制类比为”Agent 版的 DNS + 服务发现”。

实际匹配过程中，Orchestrator 拿到用户请求后，先从注册中心拉回所有候选 Agent 的 Card，然后用 LLM 对比任务描述和各 Card 的 skills.description，选出最匹配的 1-3 个 Agent 来执行。

这比硬编码路由灵活得多，新增一个 Agent 只要注册 Card 就行，不用改调度逻辑。

Agent Card 和 MCP 工具描述的对比

MCP 里的工具也有描述信息，看着跟 Agent Card 有点像，但 抽象层次 完全不同：

维度	Agent Card	MCP 工具描述
粒度	能力级别，描述 Agent 能做什么类型的事	函数级别，精确到每个参数的类型和含义
暴露程度	只暴露高层能力，不泄露内部实现	完整暴露接口签名和参数结构
耦合度	松耦合，调用方不需要知道内部用了什么工具	紧耦合，调用方必须按接口规范传参
协作模式	Agent 对 Agent，双方都有自主决策能力	Host 对 Tool，工具被动等着被调用

一个 Agent 内部可能用了十几个 MCP 工具来完成数据分析，但对外通过 Agent Card 只暴露”数据分析”这一个能力。这就是 A2A 追求松耦合能力协作、MCP 追求精确工具集成的设计哲学差异。

A2A 协议的整体定位

A2A 是 Google 在 2024 年推出的 Agent 间通信协议，跟 Anthropic 的 MCP 是互补关系。MCP 解决的是”Agent 怎么用工具”，A2A 解决的是”Agent 怎么跟 Agent 对话”。两者一个管纵向集成、一个管横向协作，在一个完整的多 Agent 系统里往往同时存在。

到如今，A2A 已经被 LangChain、CrewAI、Google ADK 等主流框架不同程度地支持。Agent Card 作为 A2A 的入口机制，基本成了多 Agent 发现和协作的事实标准。

面试官追问

提问：如果某个 Agent 的能力发生了变化，比如新增了一个技能，Agent Card 怎么更新？其他 Agent 怎么感知到这个变化？

回答：Agent Card 本身是个静态 JSON 文件，更新就是改文件内容。感知变化有两种做法：一种是轮询，注册中心或调用方定期重新拉取 Card，适合变化不频繁的场景，间隔设 5-10 分钟就行。另一种是事件驱动，Agent 更新 Card 后主动通知注册中心，注册中心再广播给订阅方。后者实时性好但实现复杂，大多数系统目前还是用轮询，因为 Agent 的能力变化本来就不频繁。

提问：Agent Card 里的 skills 描述是自然语言的，匹配准确性怎么保证？

回答：纯靠自然语言描述确实会有模糊匹配的问题。实践中一般两手抓：一是给 skills 加标签体系，比如 tags 字段写上 “data-analysis”、”csv”、”visualization” 这些结构化标签，先做标签过滤再做语义匹配。二是在 description 里写得尽量具体，不要只写”数据分析”，要写”对 CSV 和 Excel 格式的结构化数据做统计分析并生成 Matplotlib 图表”，给 LLM 更多信息来判断匹配度。标签过滤 + 语义匹配两层下来，准确率基本够用。

提问：A2A 协议在安全性上是怎么考虑的？Agent Card 里的认证机制够用吗？

回答：Agent Card 的 authentication 字段声明了支持的认证方式，OAuth2、API Key、mTLS 都可以。但 Card 本身只是声明，真正的安全校验在通信层。实际部署中通常还会加上 Agent 身份验证、请求签名、权限范围限制这些。比如一个财务 Agent 只允许被特定的管理类 Agent 调用，这个权限控制逻辑不在 Card 里，在注册中心或网关层做。Card 负责”告诉你怎么认证”，网关负责”判断你有没有资格调”。