# 1. A2A v1.0 已 GA 且由 Linux Foundation 多方治理，这对标准中立性和企业采用意味着什么 A A2A v1.0 由单一厂商私有维护，企业采用会大幅增加供应商锁定风险 B A2A v1.0 由 Linux Foundation 多方治理，规格演进公开可预期，可降低锁定风险并推动企业采用 ✓ 正确答案 C A2A v1.0 是一个未发布的草案，规格变动频繁且不可兼容 D A2A v1.0 与 MCP 是同一个协议，只是称呼不同
# 2. Agent Card 应如何描述身份、端点、能力、技能和认证要求，客户端怎样验证其可信性 A 只要通过 HTTPS 获取到 Agent Card 就应完全信任其内容 B Agent Card 必须包含 Agent 的私有密钥，客户端才能验证 C Agent Card 只用于展示，不参与任何安全决策 D 客户端应校验卡片来源 origin、签名链与传输安全，并将卡片视为不可信输入 ✓ 正确答案
# 3. submitted、working、input-required、auth-required、completed、failed、canceled、rejected 等 Task 状态如何形成合法生命周期 A 终态（completed/failed/canceled/rejected）之后仍可继续转移到 working B input-required 与 auth-required 是终态，任务一旦进入即结束 C 终态不可再转移，合法的中间态循环（如 input-required ↔ working）应设置迭代上限 ✓ 正确答案 D rejected 表示任务已开始执行但中途失败
# 4. A2A v1.0 GA 后与 MCP 稳定规范在协议层（JSON-RPC vs HTTP+SSE）上如何互补 A MCP 是 A2A 的替代品，两者不能同时使用 B A2A 使用专有二进制协议，MCP 使用 JSON-RPC C A2A 面向 Agent 间任务协同，MCP 面向 Agent-工具连接，二者基于 JSON-RPC 2.0 可互补组合 ✓ 正确答案 D A2A 与 MCP 完全等价，只是名称不同
# 5. Agent Card 的签名与来源验证如何防止恶意 Agent Card 注入（伪造的端点、能力） A 只要卡片放在 HTTPS 上，就无需验证签名 B 伪造端点无法通过签名，因此签名可完全替代来源校验 C 卡片中的能力声明是可信的，无需校验 D 客户端应校验来源 origin、TLS 及签名链，验证失败时拒绝或降级而非静默信任 ✓ 正确答案
# 6. Task、Status 与 Artifact 流事件如何关联顺序和幂等，断线后怎样恢复 A 流事件无需按 taskId 关联，客户端自行猜测即可 B artifact 事件只包含完整内容，不支持增量或断点续传 C 断线后任务必然失败，无需恢复机制 D 客户端应通过 taskId/messageId 去重排序，断线后用 task/get 获取权威状态并补齐增量 ✓ 正确答案
# 7. Push Notification webhook 如何做签名验证、重试、去重、过期和 SSRF 防护 A 只要回调地址是 HTTPS 就无需其他防护 B timestamp 偏差应无限宽松，避免误拒合法请求 C 重试时使用新的事件 ID 即可，无需幂等键 D 应组合签名、timestamp+nonce 反重放、幂等去重以及回调地址防 SSRF 等机制 ✓ 正确答案
# 8. A2A 认证与终端用户授权如何区分，Agent 间调用为何不能自动继承全部用户权限 A 认证验证 Agent 身份，授权界定用户 scope，二者应区分且 Agent 间调用应逐跳收缩权限 ✓ 正确答案 B 认证通过后即可自动继承用户全部权限 C 授权与认证是同一概念，无需区分 D 下游 Agent 应继承上游全部权限以便完成任务
# 9. Artifact 流事件（生成、签名、存储）应如何保证可验证与不可篡改 A 只要 artifact 存储在云端就天然不可篡改 B artifact 一旦生成就不可更新，因此无需版本化 C 签名是可选的，哈希已足够保证完整性 D 应通过内容哈希、版本化、数字签名与溯源记录绑定来实现可验证与不可篡改 ✓ 正确答案
# 10. A2A 与 MCP 为何正交，前者“Agent 找 Agent”、后者“Agent 找 Tool”，组合链路如何划界 A A2A 与 MCP 是同一种协议，只是实现不同 B 使用 A2A 后就不能再使用 MCP C MCP 只能用于本地，无法与 A2A 组合 D A2A 面向 Agent 间任务协同，MCP 面向 Agent-工具调用，二者可在同一链路中组合且职责不同 ✓ 正确答案
# 11. 发现未知 Agent Card 时，调用方应怎样做能力匹配、版本兼容和信任决策 A 应按能力匹配、版本兼容、信任决策三步处理，默认拒绝未知而非静默信任 ✓ 正确答案 B 只要卡片存在就应无条件信任并调用 C 未知卡片无需做版本校验，直接调用即可 D 信任决策只取决于卡片是否声称支持所需能力
# 12. 为什么 A2A 中终端用户授权不能自动继承上游，Agent 调用时应建立哪些最小权限传递 A 应通过逐跳收缩 scope、delegated token 与能力边界实现最小权限传递，权限只减不增 ✓ 正确答案 B 上游授权应完整传递给下游以简化开发 C 下游无需声明能力边界，可自由访问数据 D 权限继承与用户无关，是 Agent 之间的内部事务
# 13. A2A 与 MCP 在“工具调用”边界上的分工，何时该用 A2A，何时该用 MCP A 永远用 MCP 调用所有能力，A2A 无必要 B 二者互斥，无法在同一 Agent 中组合 C 永远用 A2A 调用所有能力，MCP 已废弃 D 确定性、原子、短时的工具调用用 MCP，异步、长时、需协商与状态的任务用 A2A ✓ 正确答案
# 14. Agent Card 发现后无法建立 TLS / 缺少身份验证时应如何快速失败而非信任 A 应快速失败（fail-closed），拒绝调用并记录告警，而非静默信任 ✓ 正确答案 B 应降级为明文调用以保证任务完成 C 缺少身份验证不影响调用安全性 D 证书域名不匹配时仍可继续调用
# 15. A2A Task 状态机中如何区分“超时未响应”与“明确取消”，二者语义差异 A 超时与取消是同一概念，都应直接重试 B canceled 是主动、可记录的终态；超时是客户端被动检测，通常先发 task/cancel 再决策 ✓ 正确答案 C 超时未响应应直接判定为失败并永久丢弃 D canceled 表示任务成功完成
# 16. Agent 间消息加密（E2EE）应在协议层强制还是应用层选择，二者取舍 A 强制放协议层永远优于应用层选择，无取舍 B E2EE 与数据敏感度无关，一律不要用 C 协议层强制安全一致但增加复杂度与互操作成本，应用层可选灵活但易遗漏；应结合威胁模型折中 ✓ 正确答案 D TLS 传输加密已完全等价于 E2EE，无需再讨论
# 17. A2A 注册中心与去中心化发现（DID、ENS）相比，各自适用场景是什么 A 去中心化发现总是优于注册中心 B 注册中心适合受管集中治理场景，DID/ENS 适合开放自托管生态，二者可组合 ✓ 正确答案 C 注册中心无法提供准入审核 D DID 只能用于集中目录，不能作为身份锚
# 18. A2A v1.0 协议基础（task/send、artifact、TaskState） A TaskState 是任务产出物，artifact 是任务状态 B artifact 决定任务状态，task/send 只用于查询 C task/send 是提交任务的入口，TaskState 描述生命周期，artifact 是任务产出，三者协作构成任务模型 ✓ 正确答案 D task/send 返回后任务即完成，无需状态跟踪
# 19. A2A v1.0 协议基础如何与外部记忆存储协作以避免跨 Agent 数据漂移 A 各 Agent 应各自维护独立状态，无需统一事实源 B 数据漂移与存储无关，只与网络有关 C 用 contextId 关联任务、artifacts 写入外部记忆存储作为单一事实源，并校验版本以避免漂移 ✓ 正确答案 D 外部记忆存储会破坏 A2A 协议，不应使用
# 20. A2A v1.0 协议基础在跨云迁移时，应通过哪些治理机制防止协议版本回退引发的兼容性回归 A 各环境自动更新即可，无需版本治理 B 应固化版本基线、做契约测试、灰度滚动并统一版本管理，回滚时同步回退状态与 artifact ✓ 正确答案 C 兼容性回归只与代码有关，与协议版本无关 D 跨云迁移不需要回滚预案
# 21. A2A v1.0 注册中心、心跳保活与 TLS 双向认证如何共同保证发现路径的完整性与抗降级 A 三者互相独立，无需协同 B 心跳保活会破坏双向认证 C mTLS 可以完全替代注册中心 D 注册中心提供可信目录、心跳提供活性、mTLS 提供双向身份认证，协同保证发现路径完整并抗降级 ✓ 正确答案
# 22. A2A v1.0 协议在灰度回滚时，如何把 Task 状态与 artifact 版本同时回退以避免半成品状态泄漏 A 回滚只回退代码即可，状态与 artifact 无需处理 B 半成品状态泄漏不会影响客户端 C 应将 Task 状态与 artifact 版本纳入同一事务/快照原子回退，并标记受影响任务，避免半成品泄漏 ✓ 正确答案 D 回滚后无需清理未提交的 artifact 增量
# 23. A2A v1.0 GA 协议在传输层同时规定了三类 binding，JSON-RPC 2.0 over HTTP、gRPC 与 HTTP+JSON——流式 artifact 投递应当走哪种 binding，其与 message/stream 的关系如何？哪些场景必须使用 gRPC 而非 JSON-RPC A message/stream 是消息抽象，binding 是传输实现；流式 artifact 可用 SSE 或 gRPC，双向流、高吞吐或强类型场景应选 gRPC ✓ 正确答案 B 流式 artifact 只能走 JSON-RPC，不能走 gRPC C gRPC 无法传输流式数据 D 三类 binding 完全等价，选哪个都一样
# 24. A2A v1.0 的 Agent Card 同时支持 .well-known/agent.json 发现与签名扩展，客户端应如何验证卡片的签名链（卡签名 → 注册中心签名 → 可选 DID 锚定），并在验证失败时优雅降级而不是静默信任 A 应自下而上验证卡签名、注册中心签名与可选 DID 锚定，失败时按信任等级降级并告警而非静默信任 ✓ 正确答案 B 验证失败时应静默接受卡片内容 C 只要拿到 .well-known 卡片就无需验签 D DID 锚定失败应视为卡片完全可信
# 25. A2A 的流式输出，SSE 事件流中 task/status/artifact 增量事件的顺序、终止条件与客户端渲染进度的处理？ A 客户端按 messageId 归序去重、以终态事件为终止条件，并增量渲染 artifact，断线后用游标补齐 ✓ 正确答案 B 事件顺序无所谓，客户端随机渲染即可 C 流结束前无需确认最终状态 D 增量 artifact 无法渲染，只能等全部完成
# 26. Task 状态机中 auth-required 与 input-required 在 v1.0 中被作为独立状态区分，auth-required 通常意味着需要客户端重新发起 scoped OAuth token，而 input-required 是补全参数——二者的客户端处理流程有哪些本质差异，如何避免混淆导致死循环 A 二者语义相同，处理方式相同 B auth-required 需重新发起 scoped 授权换 token，input-required 需补全参数，客户端应区分处理并设置重试上限避免死循环 ✓ 正确答案 C auth-required 是补参数，input-required 是换 token D 重试次数不限，直到成功为止
# 27. A2A v1.0 中 contextId 与 taskId 的传播规则，后续的 message/send 在什么条件下应创建新 Task（同 contextId 不同 taskId），什么条件下延续现有 Task（同 contextId 同 taskId）？服务端如何基于 contextId 历史决定这两条路径 A contextId 与 taskId 完全等价，可以互换 B 同 contextId 同 taskId 延续现有任务，同 contextId 新 taskId 创建新任务，服务端基于 contextId 历史决策 ✓ 正确答案 C 每个 message/send 都必须新建 taskId 且忽略 contextId D contextId 只用于展示，不影响任务创建
# 28. Push Notification webhook 防重放，A2A v1.0 推荐使用签名 + timestamp + nonce 三元组并在请求头携带，回调端应设置多大的拒绝窗口（如 ±5 分钟） A 应用签名+timestamp+nonce 三元组，拒绝窗口如 ±5 分钟，并配合 nonce 一次性去重 ✓ 正确答案 B 拒绝窗口应设为无限大，避免误拒 C 只要签名正确就无需时间窗口 D nonce 可以重复使用以简化实现
# 29. A2A v1.0 显式区分 authentication（Agent 是谁）和 authorization（代表哪个终端用户执行哪些操作），Agent A → Agent B 的链式调用应如何逐跳收缩用户授权 scope——B 是否应能反向继承 A 的全部权限？请结合 OAuth Token Exchange（RFC 8693）给出衰减模式。 A B 应继承 A 的全部权限以便完成任务 B authentication 通过后即可获得全部授权 C 用 RFC 8693 token exchange 将授权逐跳收缩为受限 scope，B 只获得 A 权限的子集，且可限制不可再委托 ✓ 正确答案 D 授权衰减与 scope 无关，只与 token 有效期有关
# 30. Agent Card 缓存策略，v1.0 建议 ETag / Last-Modified 缓存 + 5–15 分钟 TTL，但当上游 Agent 轮换签名密钥时，客户端应如何主动失效缓存并防止使用过期的 skills 与 authentication.schemes A 缓存 TTL 足够长即可，无需关心密钥轮换 B 密钥轮换后客户端可继续用旧卡，无影响 C 用 ETag/Last-Modified 条件请求配合版本号，检测并校验新卡签名后替换缓存，防止使用过期 skills 与认证方案 ✓ 正确答案 D 缓存中的卡片无需验证签名
# 31. canceled 与 rejected 都是 Task 的终态，但 canceled 是协作方主动中断而 rejected 是对方明示拒收——客户端在审计日志中应分别保留哪些字段才能满足 GDPR/PIPL 的数据主体权利审计 A 两者无需区分，记录相同字段即可 B 应记录 taskId、触发方、原因、数据范围与保留/删除标记，并支持按数据主体检索，以满足 GDPR/PIPL 权利审计 ✓ 正确答案 C 审计日志应保留全部个人数据正文以便审计 D rejected 不需要审计原因
# 32. A2A 结果投递方式，webhook 推送 vs 客户端轮询的取舍、断线恢复与重复投递去重？ A 推送永远优于轮询，无需权衡 B 轮询无法断线恢复 C 推送实时省资源但需开放回调与处理重试，轮询简单防火墙友好但延迟高，可混合并用幂等键去重 ✓ 正确答案 D 推送不需要去重，因为投递不会重复
