A2A TCK：把协议兼容拆成实际覆盖、任务生命周期和安全边界

wiki/ai/sources/a2a-tck-conformance-coverage-and-security-boundaries.md

分类：ai / sources · 更新：2026-09-10 09:10

A2A TCK：把协议兼容拆成实际覆盖、任务生命周期和安全边界

结论与知识点轴

A2A / benchmark-evaluation / harness-runtime / sandbox-security；关联 MCP Gateway 联邦。 官方 a2aproject/a2a-tck 的价值不是兼容徽章，而是把 Agent Card 声明、跨 transport 操作、任务状态和可审计测试报告串起来。测试命令成功不等于所有安全属性经过验证。

这是 a2a-v1-protocol-binding-governance 的实现层补充：从“协议支持什么”进入“对哪个版本、哪条接口、哪些可执行断言取得了什么证据”。适合用户未来把 coding/research/publishing agent 接到 MCP-Gateway-Runtime 后的接入验收，而不是作为已部署企业案例宣传。

本轮核验范围

GitHub API 当日读数：49 stars；README 声明 Apache-2.0。
固定仓库快照：263b9cfaf16a554bdfb166a7ba5b67716e946349。已读 README、specification/version.json、auth/push requirements、task lifecycle/push tests；其余仓库文件仅看目录，不声称逐项审计。
快照中的 specification baseline 为 v1.0.0，commit 173695755607e884aa9acf8ce4feed90e32727a1；不是不带版本的 latest。
另读官方 a2a-python issue #786 正文及全部七条评论，用来核对“规范要求”和“SDK 特定版本实现”的区别。
未运行 TCK、未部署 SUT、未探测第三方 endpoint。 以下是代码/文档阅读证据，不是测试通过报告。

机制：从能力声明生成测试矩阵

README 描述的流程：从 /.well-known/agent-card.json 读取 supportedInterfaces，为声明的 gRPC、JSON-RPC、HTTP+JSON 建立客户端；按 transport 与 RFC 2119 requirement level 执行。报告包含按 requirement/transport 拆分的 compatibility.json，以及 HTML、JUnit 等 CI 输出。

源码中 lifecycle tests 覆盖已有任务的 GetTask、CancelTask、对终态继续发送/订阅的错误、contextId 不匹配和订阅终止。Push tests 不只检查 config CRUD，还建立 receiver、触发状态变化并等待真实 webhook 请求，核验 Authorization 和 payload。这比只 GET Agent Card 更接近实际协作的状态合同。

但每项只能支持它实际断言的结论。例如已读 test_get_task_returns_current_state 在调用成功后核对返回 task ID；不能仅根据测试标题推断它已完整验证状态演化。因此验收链应为 规范条款 → 测试函数 → 具体 assertion → 运行结果。

深度重点：覆盖分母不能被 skip 隐藏

README 将 MUST 失败作为硬失败、SHOULD 用 xfail、MAY 在不声明能力时跳过；实际 push test 也会在 pushNotifications 未声明时记录 skipped。另一些前置创建/发送失败路径调用 pytest.skip，这和“不适用”不是同一种原因。

在已读 auth.py 中，生产 TLS 条款存在，但带 NOT_AUTOMATABLE 标签。Requirement 定义存在，不等于自动测试覆盖存在。 本轮未运行报告生成器，不能推断这些条款最终如何计入全量报告。

对照 Agent-Benchmarks，建议接入验收至少区分：

层次	应保存的字段	不能混成什么
声明	card hash、protocol/spec commit、supportedInterfaces、capabilities	服务真的实现
适用	required / optional、组织要求的 auth/push/stream	声明为 false 就自动免验
执行	assertion、executed / not implemented / manual / prerequisite failed	全部算 skipped
结论	passed / failed / xfail、运行版本、report hash	单个绿色 exit code

业务必须支持 push 时，“没声明 push，所以跳过”应是接入不满足，而非产品合规成功；组织必须保证 TLS 时，需要代理/部署层单独验证，不能把本地 HTTP 的 TCK 通过当生产安全认证。

SDK issue 给出的反例：只读标题会保存过时漏洞

#786 的 2026-03-08 报告基于 fa14dbf，提出 webhook SSRF 和 task ownership 两类问题。2026-04-24 维护者明确说明：task-level authorization 是 0.3 的缺口，稳定 1.0 SDK 已加入 task/push store ownership；报告者确认并同意移除这部分指控。4 月 27 日评论转向共享 URL validation 基础设施 #1023。

因此本页不宣称当前 A2A Python SDK 仍缺少 task authorization。Issue 的 open 状态及旧标题不能反驳后续修复说明；本轮也没有读取当前 SDK 实现来证明 SSRF 已修或未修。

同一讨论还揭示私网目的地是合法企业需求，维护者与报告者对默认启用方式的表述并不一致。正确工程问题不是简单“封所有私网”，而是按部署允许的目的地、解析结果、重定向与调用身份执行策略；token scope 也不能单独代替实际网络连接约束。

对 Hermes / llm-wiki 的实践启发

将 A2A-Agent2Agent-Protocol 的 Agent Card → task lifecycle → artifact 链路做成接入证据，而不是把 SDK 项目名当能力证明。
在自有隔离 SUT 上把跨身份 get/cancel/push 配置、过期凭据、终态任务和回调目的地作为负例；生产目标不可由无人雷达直接探测。
协议一致性报告与组织安全 profile 分开：前者证明交互语义，后者证明谁能做什么、能联系哪里。
雷达保存 issue comments、release 与精确版本；不把未关闭 issue 的最初描述写成当前事实。

失败模式与未解问题

由规范场景生成的 SUT 便于复现，但真实企业实现可能不懂测试控制消息；前置场景失败应报告为 blocked，不能直接认定 SDK 不兼容。
TCK 与 SUT 来源相近可能共享误解；高价值安全断言还需要独立测试及服务端回执，参见 redagentbench-state-grounded-safety-measurement。
无生产 trace、性能/恢复基准或本地执行结果；不能凭 README 推荐其承担唯一接入门禁。

写入记录

2026-09-10 09:06 CST：新增固定 commit 的 TCK 源码/规范/测试分析；核对 SDK #786 评论中的 0.3→1.0 ownership 修复，区分兼容测试、覆盖分母与部署安全。