## 核心发现
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：数字名片与三字段陷阱
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 看起来很专业：
```json
{
"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"这句话没有任何机器可校验的约束。它既不区分部分退款与全额退款，也不声明是否需要二次审批。调度器只能信这句话。这张卡片的可信度，等同于一句广告语。
## 二、能力冒充：admin 案例与自证不可信
最致命的失真不是写得差，而是**故意写假**。某团队在 staging 环境部署了一个恶意（rogue）智能体，它在 Agent Card 里声称自己具备 `admin` 能力，结果直接访问了生产用户数据。事后复盘给出的铁律只有一句：**"永远不要信任调用方的能力列表。"** 修复方案是引入服务端能力验证，对照存储在 Vault 里的白名单逐项核对。
这不是孤立事故。A2A 协议官方文档承认，Agent Card 包含敏感信息（内部 URL、受限能力描述），因此推荐"已认证的扩展卡片"和选择性披露——但披露机制解决的是**谁能看到卡片**，不是**卡片内容是否为真**。签名 Agent Card（v1.0 被称为"最重要的安全改进"）能防篡改、能追溯签发者，却无法阻止签发者把"我只能查天气"写成"我能动生产库"。自证能力的结构性缺陷，签名补不上。
## 三、能力 ID 过宽：refund vs invoice.refund 的泛匹配税
即使没有恶意，粗粒度的 ID 也会让路由失真。how2.sh 的工程实践给出明确建议：用精确 ID（`invoice.refund`）而非宽泛 ID（`refund`）。原因在于调度逻辑通常是子集匹配——只要候选 Card 的能力集合是所需集合的超集就算命中。
```python
def supports_all(card, required_ids):
provided = {c["id"] for c in card.get("capabilities", [])}
return required_ids.issubset(provided) # 宽 ID 轻易命中
```
当一个 Card 只声明了 `refund`（含义模糊），而任务需要的是带版本约束的 `invoice.refund@1.1`（要求处理 1.1 版退款协议），子集匹配仍会把它选为候选。后果是任务被分发给一个语义擦边的智能体，直到执行阶段才暴露它根本不懂 1.1 版协议——而这往往表现为一个泛化的"task failed"，工程师要花两小时才能定位到能力不匹配。实测中，把宽泛 ID 收敛为带域前缀 + 版本的精确 ID，是发现层性价比最高的一处改动。
## 四、静默漂移：改了 schema 不加版本，消息被悄悄丢弃
第三类失真最阴险——**能力声明与现实之间发生了漂移，而系统沉默**。一个智能体悄悄修改了字段名（比如把 `user_id` 改成 `userId`）却没有 bump 版本号。schema 校验失败时，调用方拿到的是一个模糊错误，甚至没有错误。
A2A 文档坦承：不声明 schema 或声明不一致的智能体，会导致**静默消息丢弃**，看起来像网络问题。thecodeforge 给出的工程对策是在每条消息里嵌入 **schema hash**，hash 不匹配时强制返回 `CapabilityMismatch` 错误并记录每一次不匹配——绝不允许静默降级。配合 jsonschema 在发现阶段预校验 Card 结构（required 字段、类型约束），可以把这类漂移从"运行时偶发故障"前置成"发现时硬失败"。核心原则来自 how2.sh：**使用前校验卡片，必需能力缺失时 fail closed，而不是 fail open 去猜。**
## 五、签名验身份不验能力：v1.0 签名卡的信任边界
v1.0 引入签名 Agent Card 是对的，但要清醒认识它的边界。签名解决了三件事：防篡改（卡片在传输中没被改）、可追溯（谁签的，吊销列表怎么查）、身份真实性（确实是 example.com 这台服务器发的）。它**没**解决一件最关键的事：**声明的能力是否与实际能力一致**。
这正好类比 PKI 体系：一张 X.509 证书能证明域名归属，证明不了那个域背后的服务真的安全。能力声明的真实性，必须靠**带外验证**——即真正的能力探测——来补充。这就是为什么官方文档反复强调"强烈推荐使用带外动态凭证，而非在 Card 里嵌入静态密钥"：Card 里能写的都是声明，可信的部分必须放到 Card 之外。把签名当成能力担保，是把身份信任错当成能力信任，正是多智能体发现层最常见的认知错位。
## 六、发现层规模税：1 万智能体握手，注册表 p99 从 10ms 烧到 5s
能力失真不只是正确性问题，还是规模问题。当 1 万个智能体同时与中央能力注册表握手，注册表的 p99 延迟从 10ms 飙到 5s。修复需要三层：Redis 缓存能力查询、指数退避重试（100ms 起、10s 封顶）、以及每 60s 一次的"能力心跳"让注册表持有新鲜数据而无需全量握手。任务路由则改用**一致性哈希环**，把任务类型映射到固定智能体，在扩缩容时避免雪崩式重握手——这一项让握手负载直降 90%。
但这套机制的前提，是注册表里的能力数据本身可信。心跳上报的仍是智能体**自报**的能力。若一个智能体每 60s 心跳一次声称自己健康且具备某能力，注册表就会持续把任务路由过去——直到真正调用时才发现它在"假活"。规模越大，发现层与执行层之间的能力真相延迟就越久，一张失真的 Card 被复用的次数就越多。
## 七、下游失真：能力声明失效如何变成对抗性共识
能力失真的代价不止是路由错误，它会在协作层放大为**对抗性共识**。仲裁研究发现多智能体分歧有四类：风格性、推理性、高置信度、对抗性。其中对抗性分歧最危险——一个被操纵的智能体通过反复的协调性附和，能把目标智能体推向错误结论。医疗 AI 的对照实验显示，对抗性 assistant 智能体能达到 **98%–100% 的攻击成功率**，手段正是"制造假共识"。
这与能力失真的关联是：当一个能力冒充或漂移的智能体混入网络，它输出的"协作信号"会被其他智能体当作可信输入。多数票投票会**放大共享错误**而非抵消它——若若干智能体都从同一个失真能力源获得污染信号，多数票反而锁定错误。唯一的解药在研究里被明确写出：**一个锚定外部 ground truth 的验证器智能体，能彻底消除这类攻击**。能力声明可以被伪造，但对照外部事实的探测不能。这正是把"自证"升级为"实测"的工程出口。
## 发现与验证分层架构
```mermaid
flowchart TB
subgraph D["发现层 Discovery"]
A1[智能体自发布 Agent Card
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
实测而非自证]
C4[锚定 ground truth 验证器]
end
subgraph R["协作层 Collaboration"]
D1[多数票投票]
D2[LLM Judge 仲裁]
D3[辩论协议]
end
A1 & A2 & A3 --> S
S -->|声明可信| V
V -->|能力可信| R
V -.->|fail closed
必需能力缺失| 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 落地潮中是明确空白市场，适合做成训练营的"多智能体可信发现"专题。
## 参考来源
1. [Agent Discovery - A2A Protocol 官方规范](https://a2a-protocol.org/latest/topics/agent-discovery/) — Agent Card 结构、三种发现策略、签名与缓存官方定义
2. [A2A Protocol for AI Agents — How We Lost $40k to Agent Handshake Timeouts](https://thecodeforge.io/ml-ai/a2a-protocol-agents/) — 4 万美元事故复盘、admin 能力冒充案例、1 万智能体注册表规模税
3. [How to Implement A2A Agent Discovery with Capability Cards](https://how2.sh/posts/a2a-agent-discovery-capability-cards/) — 能力卡片实现、精确 ID、fail-closed 校验代码
4. [When Your Agents Disagree: Consensus and Arbitration in Multi-Agent Systems](https://tianpan.co/blog/2026-04-12-when-agents-disagree-consensus-arbitration-multi-agent-systems) — 多智能体分歧分类、对抗性共识 98-100% 攻击成功率、ground truth 验证器
5. [Agent-to-Agent Communication Protocols: A2A, MCP, and Multi-Agent Security](https://zylos.ai/en/research/2026-05-16-agent-to-agent-communication-protocols-a2a-mcp/) — A2A v1.0 签名 Agent Card 作为最重要的安全改进
> [!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 等场景全覆盖。
