独立解读
Agent 的身份是什么？它怎样证明自己代表谁？
01Agent 身份02用户授权03交易凭证
你让购物 Agent 找一双鞋。商家收到请求时，先要判断“这是谁发来的”，还要判断“它是否有权为用户买下这双鞋”。两个答案并不一样。
识别 Agent、识别用户、证明授权和确认支付，是四个不同的问题。 一个签名正确的 Agent，仍可能没有权限购买该商品。
以下为概念案例。身份信号与用户授权的具体用途、数据字段及可用范围由协议和实际接入方决定；本文没有进行产品接入或真实交易测试。
flowchart LR
A[用户提出购买要求] --> B[Agent 发起商家请求]
B --> C[商家识别请求来源]
C --> D[验证相关购买条件]
D --> E[支付方处理交易]
E --> F[商家按条件交付]
商家需要知道什么？
| 问题 | 例子 | 它不能单独证明什么 |
|---|---|---|
| Agent 身份 | 请求来自哪个 Agent 服务 | 用户批准了具体商品 |
| 用户或账户识别 | 是否能对应商家的已有客户 | 对本次付款已有有效授权 |
| 购买授权 | 用户对商品、价格、时间设了什么条件 | 银行或支付网络一定批准 |
| 支付凭证 | 本次使用什么受限凭证 | 商品一定会按承诺交付 |
同一个产品可能处理其中多层，但不要把这些证据混成“Agent 已认证，所以什么都能买”。
Visa TAP 与 AP2 的不同问题
Visa Trusted Agent Protocol 文档介绍 Agent 请求签名、消费者识别与支付相关信息等机制，帮助采用该协议的商家验证相关消息。AP2 规范则定义 Checkout 和 Payment Mandate，用于表达与验证购买及付款授权。
它们关注点不同，是否能在某个产品组合使用，要看具体集成。Visa 的产品介绍也说明其能力处于开发和部署过程中，不保证各市场均可用。
验证时应该看哪些边界？
签名不只是检查“存在”。验证方还要根据适用协议检查签发方、接收方、有效期、用途和内容是否一致。权限记录也要与本次交易关联：允许买鞋，不自动等于允许买任意商品。
同时，身份信息可能涉及隐私。商家是否需要完整信息、能否只接收完成交易所需字段，取决于系统设计和规则；文章里的角色图并不要求所有参与方看到同一份数据。
如果产品声称“可信 Agent”，可以追问：信任的是哪个身份、由谁验证、验证适用于哪些交易，以及授权过期或被撤销后如何处理。