高频面试题

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

Agent Card 是 A2A 里最像“名片”的部分，但真正的考点是它如何让调用方在不知道远端实现细节的情况下发现能力、判断适配性并安全发起协作。

适合阶段：多 Agent 协作 / Agent 平台设计面核心能力：Discovery · Capability Metadata · Skill Matching · Trust Boundary

面试官角度分析，想考什么

• Agent Card 是什么？
  考你能否把它说成 A2A Agent 的能力名片，而不是一份普通 JSON 配置。

• 它在发现和协作里起什么作用？
  考匹配：让其他 Agent 先知道会什么、怎么连、要什么认证、适不适合当前任务。

• Agent Card 能不能被完全信任？
  考安全：它是声明不是证明，还要做来源校验、授权、运行时验证和审计。

可直接抄走的 30 秒参考答案

Agent Card 是 A2A 协议里 Agent 对外暴露的标准化能力名片，通常是一个 JSON 元数据文档。它描述这个 Agent 的名称、提供方、endpoint、版本、capabilities、skills、输入输出模式和认证要求。它的作用是让其他 Agent 或 orchestrator 在调用前先完成发现和匹配：知道谁能做这个任务、怎么连、是否支持流式或通知、需要什么凭证。但 Agent Card 不是信任本身，生产里还要做来源校验、授权、运行时验证和审计。

面试回答详解，知其所以然

Agent Card 很容易被答成“一个 JSON 配置文件”。更好的面试答案要说明：它是多 Agent 系统里的发现入口和协作契约，但不是安全证明，也不是完整 API 文档。

1. Agent Card 的定位

在 A2A 协议中，Agent Card 是一个公开或受控可访问的元数据文档，用来描述一个 Agent 对外提供的能力。官方规范约定 Agent 可以通过固定路径暴露它，例如：

https://example.com/.well-known/agent-card.json

调用方拿到 Agent Card 后，可以知道：

• 这个 Agent 是谁，由谁提供。
• 它的服务 endpoint 在哪里。
• 它支持哪些能力和技能。
• 它支持哪些输入 / 输出内容类型。
• 它是否支持流式、推送通知、状态变化等能力。
• 调用它需要什么认证和安全方案。

所以 Agent Card 是发现和接入的第一步，不是任务执行本身。

2. Agent Card 通常包含什么

一个 Agent Card 不是随便写一段介绍，而是结构化的协作元数据。常见字段可以按用途理解：

• 身份信息：name、description、version、provider，帮助调用方和用户识别 Agent。
• 访问入口：url 或 endpoint，告诉调用方往哪里发送 A2A 请求。
• 能力声明：capabilities，例如是否支持 streaming、push notifications、state transition history 等。
• 技能列表：skills，描述 Agent 能处理的任务类型、标签、示例和输入输出模式。
• 交互模式：默认输入 / 输出 modes，说明文本、文件、结构化数据等支持情况。
• 安全配置：认证方式和安全要求，帮助调用方知道如何授权。

面试里可以强调：skills 是路由和匹配的关键。Agent Card 不只是“这个 Agent 在线”，还要告诉系统它擅长什么任务。

3. Agent Card 在发现中的作用

多 Agent 系统里，发现不是简单列一个 URL。调用方需要回答：

我要完成的任务 -> 哪些 Agent 可能会做 -> 哪个 Agent 最匹配 -> 怎么安全调用

Agent Card 提供了这几个判断依据：

• 能力发现：通过技能、描述和标签找到候选 Agent。
• 模式匹配：判断输入输出类型是否兼容，例如是否能接文件、图片、表格或结构化 JSON。
• 协议兼容：确认对方支持的 A2A 能力，例如流式状态或 push notification。
• 认证准备：在发起任务前知道需要 OAuth、API key、mTLS 或其他安全方案。
• UI 展示：让用户或编排器能看到 Agent 名称、提供方、能力和适用范围。

没有 Agent Card，多 Agent 平台只能靠硬编码注册表或人工读文档；有了 Agent Card，Agent 可以用标准方式自描述。

4. Agent Card 在协作中的作用

发现只是第一步，协作还需要把任务发给合适的 Agent。Agent Card 在协作前提供了契约边界：

• Orchestrator 根据技能列表选择候选 Agent。
• 调用方根据 input/output modes 转换任务输入。
• 调用方根据 security schemes 准备凭证。
• 调用方根据 capabilities 决定是同步等待、流式接收，还是通过通知追踪长任务。
• 用户界面可以在授权前展示“将把任务交给哪个 Agent、它由谁提供、会访问哪些能力”。

这让远端 Agent 可以保持 opaque：它不需要暴露内部 prompt、模型、MCP tools 或 workflow，只需要声明协作所需的外部契约。

5. Agent Card 不是信任本身

Agent Card 帮助发现，但不能替代安全控制。一个恶意 Agent 也可以写一个看起来很漂亮的 Agent Card。

生产里应该配合：

• Agent Card 来源校验，例如可信域名、签名、注册表或组织审核。
• 认证和授权，不因为 card 声明能力就允许调用。
• 运行时输入输出校验，避免返回恶意内容或越权数据。
• 用户确认，尤其是跨组织、涉及敏感数据或有副作用的任务。
• 可观测性，记录选择了哪个 Agent、基于哪个 card、执行了什么任务。
• 定期刷新和版本控制，避免旧 card 与实际能力不一致。

成熟回答要把 Agent Card 看成“发现和协作入口”，而不是“安全认证书”。

面试官追问3个问题

追问一：Agent Card 只是一个简介文件吗？

• 考察点：是否理解结构化协作元数据。
• 回答方向：不是。它包含 endpoint、capabilities、skills、security、input/output modes 等字段，是其他 Agent 发现和调用前的标准化入口。

追问二：Orchestrator 如何使用 Agent Card 做路由？

• 考察点：多 Agent 调度能力。
• 回答方向：先根据任务语义匹配 skills，再检查输入输出模式、认证要求、capabilities 和版本，最后结合健康状态、权限和历史质量选择目标 Agent。

追问三：Agent Card 里的 skills 和 MCP tools 有什么区别？

• 考察点：是否理解 Agent 能力和工具 schema 的边界。
• 回答方向：skills 描述 Agent 能承担的任务类型和协作能力，通常比较高层；MCP tools 描述具体可调用工具的输入输出 schema，通常更底层。A2A 调用方不需要看到远端 Agent 内部用了哪些 MCP tools。

扩展知识

Agent Card 和 OpenAPI 的区别

OpenAPI 更偏向描述 HTTP API 的 endpoint、参数和响应。Agent Card 更偏向描述 Agent 作为协作者的能力边界。

• OpenAPI：这个接口怎么调，参数是什么。
• Agent Card：这个 Agent 是谁、会什么、怎么协作、支持哪些任务模式。

两者可以互补。Agent 内部服务接口可以用 OpenAPI 描述，但 A2A 需要 Agent Card 来做能力发现和协作决策。

Agent Card 和注册中心

Agent Card 可以放在 .well-known 路径，也可以被平台索引到注册中心。两者关系类似：

Agent Card = 单个 Agent 的自描述
Registry = 多个 Agent Card 的索引、审核和治理入口

企业内做多 Agent 平台时，通常不会让 orchestrator 在公网随便抓 card，而会通过可信 registry 管理 Agent Card 的发布、审核、版本和权限。

好的 Agent Card 应该怎么写

好的 Agent Card 应该让调用方能做出正确路由判断：

• 技能描述要具体，避免“能处理所有任务”。
• 示例要贴近真实任务，帮助匹配器理解边界。
• 输入输出模式要准确，不能声称支持文件但实际只会文本。
• 安全要求要清楚，避免调用时才发现权限不足。
• 版本和 provider 要可追溯，方便审计和回滚。
• 能力声明要保守，不能把实验能力写成稳定能力。

Agent Card 写得越泛，越容易导致错误路由；写得越贴近能力边界，协作越稳定。