A2A 协议中的 Agent Card 是什么?它在多 Agent 发现和协作中起什么作用?
- 标签:AI、大模型、Agent
🏛 业务架构师
Agent Card 是 A2A 协议中的"Agent 名片"——一份标准化的 JSON 文档,通常发布在 /.well-known/agent.json 路径,内容涵盖:Agent 身份(名称、描述、服务地址)、能力声明(支持的任务类型、输入输出模态)、鉴权要求(支持的认证方案)、传输协议(JSON-RPC/SSE/Webhook)、安全策略等。
在多 Agent 发现中的作用:
- 能力发现:调用方拉取 Card 就知道对方"是谁、能干什么、怎么连接"——相当于服务注册+API 文档的合体。没有 Card,每个协作方要人工交换接口文档;
- 动态匹配:Agent 可程序化地根据 Card 里的 skills 字段筛选"谁擅长这个任务",实现自动路由与编排——这是多 Agent 生态"市场化分工"的基础;
- 信任建立:Card 声明鉴权方式与安全策略,是企业准入评审的依据。
在协作中的作用:发现之后,Card 中声明的接口约定驱动整个任务生命周期——按声明的认证方式建立会话、按声明的传输方式收发任务、按声明的能力范围委派工作。
业务视角:Agent Card 的价值类比"企业工商注册+资质公示"——让 Agent 经济从"熟人协作"走向"陌生协作"。企业落地建议:对外提供 Agent 服务时,把 Card 当产品接口文档认真维护(能力描述准确、版本化管理);内部多 Agent 体系也可用 Card 思路做能力目录,统一治理 Agent 资产,防止"影子 Agent"泛滥。
🏗 系统架构师
Agent Card 是 A2A 协议里 Agent 的自描述文档:JSON 格式,托管在 Agent 服务端的众所周知路径(/.well-known/agent.json),内容涵盖——名称与描述、能力技能列表(skills)、支持的输入输出模态(文本/文件/结构化)、认证方式(如 OAuth2 的 securitySchemes)、服务端点、版本信息。
它在多 Agent 发现与协作中的角色,我类比成三合一:
- 服务注册中心:客户端 Agent 通过拉取 Card 完成能力发现——不用预先硬编码集成,运行时扫描 Card 就知道"市面上谁能干什么"。这是 Agent 市场生态(Agent 目录、搜索引擎)的基础设施;
- API 文档(面向 Agent 的):skills 描述就是给对方 LLM 看的能力说明,描述质量直接决定"被选中的准确率"——和 MCP 工具描述同理,这是写给模型的营销文案;
- 契约与协商依据:客户端按 Card 声明的模态、认证、版本决定怎么发起任务(发什么格式、带什么凭证),实现协议层的无假设集成(Opaque Execution 的前提)。
架构师实践要点:Card 要版本化 + 缓存 + 变更监控(能力变了要通知依赖方,避免按旧契约调用失败);描述要诚实(声明的技能做不到会被差评,Agent 市场需要信誉机制);敏感信息不进 Card(端点走网关收敛)。Card 是 A2A 生态的"元数据基石",治理要从第一天做。
💻 全栈开发专家
Agent Card 是 A2A 协议里 Agent 的自描述名片:一个标准化 JSON 文档,默认发布在 /.well-known/agent-card.json,任何客户端 GET 这个 URL 就能完成能力发现。
核心字段(简化):
json
{
"name": "订单退款Agent",
"description": "处理电商订单退款申请与进度查询",
"url": "https://refund.example.com/a2a",
"version": "1.2.0",
"capabilities": {"streaming": true, "pushNotifications": true},
"authentication": {"schemes": ["oauth2"], "scopes": ["refund:write"]},
"defaultInputModes": ["text/plain"],
"defaultOutputModes": ["application/json"],
"skills": [
{"id": "process-refund", "name": "退款处理",
"description": "校验并执行退款,返回退款单号",
"tags": ["refund", "order"], "examples": ["帮我把订单A123退了"]}
]
}在多 Agent 协作中的作用:
- 发现:客户端拉 Card 就知道「对方是谁、会什么、怎么认证」,无需事先对接文档——服务发现从「人肉接口约定」变成「机器可读」;
- 技能匹配:客户端(或编排器)拿用户需求对 skills 做语义匹配,选择委托目标——Card 的 description 质量直接决定被选中的准确率,要写清「适用与不适用场景」;
- 协商:认证 scheme、输入输出模态、是否支持流式,都在 Card 里声明,调用前就能判断兼容性;
- 治理:版本号管理兼容性,安全团队可以审 Card 做准入。
工程实践:Card 要随代码发布自动生成(注解/配置驱动),漂移(Card 说的和实际实现不一致)是 A2A 联调最常见的事故;把企业内所有 Agent Card 汇总成注册中心,就是内部的「Agent 目录」。