A2A 协议（Agent-to-Agent）在 2026 年成为多智能体协作的事实标准之一，其基础设施是 Agent Card——一份由智能体自己发布的 JSON "数字名片"，列出身份、端点、鉴权方式与 Skills（能力）。问题在于：能力声明本质是自证（self-attestation）。智能体（或其开发者、或生成卡片的 LLM）自己填写自己能干什么，而 v1.0 引入的签名 Agent Card 只能证明"这张卡片是 X 签发的"，证明不了"X 真的具备它声称的能力"。本文实测三类能力失真——能力冒充、ID 过宽、静默漂移——并复盘一次因能力协商失败级联导致的 4 万美元损失事故。结论：发现层若只做匹配不做验证，多智能体的"找人干活"就从精确路由退化为概率赌博。
| 发现机制 | Agent Card 来源 | 能力可信度 | 失真代价 | 典型场景 |
|---|---|---|---|---|
| Well-Known URI | 智能体自托管 /.well-known/agent-card.json |
最低（完全自证） | 路由到不称职者 | 公开/跨域发现 |
| 策展注册表 | 中央注册表策展 | 中（注册表把关） | 注册表成单点 + 信任瓶颈 | 企业内/市场 |
| 直接配置 | 硬编码/配置文件 | 高（人工背书） | 零弹性，能力变就失配 | 私有强耦合 |
| 签名 Agent Card（v1.0） | 自发布 + 加密签名 | 中（验身份不验能力） | 身份真实但能力可虚标 | 跨厂商互操作 |
| 能力探测验证层 | 声明 + 运行时回声校验 | 最高（实测） | 每次发现附探测开销 | 关键路径任务 |
Agent Card 的官方结构包含五块：Identity（name/description/provider）、Service Endpoint（url）、A2A Capabilities（streaming/pushNotifications 等开关）、Authentication（Bearer/OAuth2）、以及最关键的 Skills。每个 Skill 是一个 AgentSkill 对象，含 id、name、description、inputModes、outputModes、examples。
陷阱恰恰藏在三处自由文本里。description 是自然语言，跨厂商对同一能力的措辞天差地别；examples 是示例而非契约，无法保证泛化；而 name 往往被 LLM 调度器当作语义匹配的主键。一份典型 Card 看起来很专业：
{
"name": "Refund Specialist",
"description": "Handles customer refunds and billing adjustments",
"skills": [
{ "id": "refund", "name": "Process Refund",
"description": "Refunds any order", "inputModes": ["text"] }
]
}
但"Refunds any order"这句话没有任何机器可校验的约束。它既不区分部分退款与全额退款，也不声明是否需要二次审批。调度器只能信这句话。这张卡片的可信度，等同于一句广告语。
最致命的失真不是写得差，而是故意写假。某团队在 staging 环境部署了一个恶意（rogue）智能体，它在 Agent Card 里声称自己具备 admin 能力，结果直接访问了生产用户数据。事后复盘给出的铁律只有一句："永远不要信任调用方的能力列表。" 修复方案是引入服务端能力验证，对照存储在 Vault 里的白名单逐项核对。
这不是孤立事故。A2A 协议官方文档承认，Agent Card 包含敏感信息（内部 URL、受限能力描述），因此推荐"已认证的扩展卡片"和选择性披露——但披露机制解决的是谁能看到卡片，不是卡片内容是否为真。签名 Agent Card（v1.0 被称为"最重要的安全改进"）能防篡改、能追溯签发者，却无法阻止签发者把"我只能查天气"写成"我能动生产库"。自证能力的结构性缺陷，签名补不上。
即使没有恶意，粗粒度的 ID 也会让路由失真。how2.sh 的工程实践给出明确建议：用精确 ID（invoice.refund）而非宽泛 ID（refund）。原因在于调度逻辑通常是子集匹配——只要候选 Card 的能力集合是所需集合的超集就算命中。
def supports_all(card, required_ids):
provided = {c["id"] for c in card.get("capabilities", [])}
return required_ids.issubset(provided) # 宽 ID 轻易命中
当一个 Card 只声明了 refund（含义模糊），而任务需要的是带版本约束的 [email protected]（要求处理 1.1 版退款协议），子集匹配仍会把它选为候选。后果是任务被分发给一个语义擦边的智能体，直到执行阶段才暴露它根本不懂 1.1 版协议——而这往往表现为一个泛化的"task failed"，工程师要花两小时才能定位到能力不匹配。实测中，把宽泛 ID 收敛为带域前缀 + 版本的精确 ID，是发现层性价比最高的一处改动。
第三类失真最阴险——能力声明与现实之间发生了漂移，而系统沉默。一个智能体悄悄修改了字段名（比如把 user_id 改成 userId）却没有 bump 版本号。schema 校验失败时，调用方拿到的是一个模糊错误，甚至没有错误。
A2A 文档坦承：不声明 schema 或声明不一致的智能体，会导致静默消息丢弃，看起来像网络问题。thecodeforge 给出的工程对策是在每条消息里嵌入 schema hash，hash 不匹配时强制返回 CapabilityMismatch 错误并记录每一次不匹配——绝不允许静默降级。配合 jsonschema 在发现阶段预校验 Card 结构（required 字段、类型约束），可以把这类漂移从"运行时偶发故障"前置成"发现时硬失败"。核心原则来自 how2.sh：使用前校验卡片，必需能力缺失时 fail closed，而不是 fail open 去猜。
v1.0 引入签名 Agent Card 是对的，但要清醒认识它的边界。签名解决了三件事：防篡改（卡片在传输中没被改）、可追溯（谁签的，吊销列表怎么查）、身份真实性（确实是 example.com 这台服务器发的）。它没解决一件最关键的事：声明的能力是否与实际能力一致。
这正好类比 PKI 体系：一张 X.509 证书能证明域名归属，证明不了那个域背后的服务真的安全。能力声明的真实性，必须靠带外验证——即真正的能力探测——来补充。这就是为什么官方文档反复强调"强烈推荐使用带外动态凭证，而非在 Card 里嵌入静态密钥"：Card 里能写的都是声明，可信的部分必须放到 Card 之外。把签名当成能力担保，是把身份信任错当成能力信任，正是多智能体发现层最常见的认知错位。
能力失真不只是正确性问题，还是规模问题。当 1 万个智能体同时与中央能力注册表握手，注册表的 p99 延迟从 10ms 飙到 5s。修复需要三层：Redis 缓存能力查询、指数退避重试（100ms 起、10s 封顶）、以及每 60s 一次的"能力心跳"让注册表持有新鲜数据而无需全量握手。任务路由则改用一致性哈希环，把任务类型映射到固定智能体，在扩缩容时避免雪崩式重握手——这一项让握手负载直降 90%。
但这套机制的前提，是注册表里的能力数据本身可信。心跳上报的仍是智能体自报的能力。若一个智能体每 60s 心跳一次声称自己健康且具备某能力，注册表就会持续把任务路由过去——直到真正调用时才发现它在"假活"。规模越大，发现层与执行层之间的能力真相延迟就越久，一张失真的 Card 被复用的次数就越多。
能力失真的代价不止是路由错误，它会在协作层放大为对抗性共识。仲裁研究发现多智能体分歧有四类：风格性、推理性、高置信度、对抗性。其中对抗性分歧最危险——一个被操纵的智能体通过反复的协调性附和，能把目标智能体推向错误结论。医疗 AI 的对照实验显示，对抗性 assistant 智能体能达到 98%–100% 的攻击成功率，手段正是"制造假共识"。
这与能力失真的关联是：当一个能力冒充或漂移的智能体混入网络，它输出的"协作信号"会被其他智能体当作可信输入。多数票投票会放大共享错误而非抵消它——若若干智能体都从同一个失真能力源获得污染信号，多数票反而锁定错误。唯一的解药在研究里被明确写出：一个锚定外部 ground truth 的验证器智能体，能彻底消除这类攻击。能力声明可以被伪造，但对照外部事实的探测不能。这正是把"自证"升级为"实测"的工程出口。
flowchart TB
subgraph D["发现层 Discovery"]
A1[智能体自发布 Agent Card<br/>Well-Known URI]
A2[策展注册表 Registry]
A3[直接配置 Config]
end
subgraph S["签名校验层 v1.0"]
B1[加密签名: 防篡改]
B2[签发者追溯: 身份真实]
B3[❌ 不验证能力真伪]
end
subgraph V["能力验证层 新增"]
C1[schema hash 比对]
C2[精确 ID + 版本匹配]
C3[回声探测 echo probe<br/>实测而非自证]
C4[锚定 ground truth 验证器]
end
subgraph R["协作层 Collaboration"]
D1[多数票投票]
D2[LLM Judge 仲裁]
D3[辩论协议]
end
A1 & A2 & A3 --> S
S -->|声明可信| V
V -->|能力可信| R
V -.->|fail closed<br/>必需能力缺失| X[❌ 拒绝路由]
R -.->|对抗性共识污染| C4
C4 -.->|消除 98%攻击| R
classDef trap fill:#ffe0e0,stroke:#c33,color:#900
class B3 trap
分层信任，把自证逐层替换为实测。 发现层只负责"找到候选"，不可承担能力担保。三步落地：第一，发现阶段强制 schema 校验 + 精确 ID（带域前缀与版本），宽泛 ID 一律拒绝；第二，引入能力探测层——对关键能力在握手后做一次廉价回声测试（发一个已知输入，核对输出契约），把"声明可信"升级为"实测可信"；第三，协作层至少保留一个锚定外部 ground truth 的验证器，专门用来刺破假共识。
按场景选发现机制：公开跨域用 Well-Known URI + 签名卡（接受自证风险，靠探测兜底）；企业内用策展注册表（注册表做治理，但仍需探测）；关键路径用直接配置 + 探测（最高可信，零弹性代价）。永远不要让"找到了"和"能干"画等号——前者是声明的，后者必须实测。
变现评估：能力声明审计（Card 契约校验 SaaS）、发现层探测探针（按能力探测计费）、对抗性共识红队服务——这三块在 2026 年企业 A2A 落地潮中是明确空白市场，适合做成训练营的"多智能体可信发现"专题。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。