Agent Factory 回顾：你能帮我购物吗？
Source: Dev.to
（请提供您希望翻译的正文内容，我将为您翻译成简体中文。）
快速入门指南
使用下面的时间戳跳转到您感兴趣的章节。每个片段都包含简短概述以及指向节目备注相关部分的链接。
| 时间戳 | 部分 | 摘要 |
|---|---|---|
| [01:43] | 信任问题 | 为什么需要信任 AI 票务代理来处理您的金钱和个人数据。 |
| [02:29] | 为什么当前支付堆栈对代理失败 | 三个核心挑战（授权、代理错误、问责）以及代理支付协议（AP2）如何解决它们。 |
| [04:33] | 角色与关注点分离 | AP2 生态系统中的四个专门参与者以及为何购物代理从不处理原始卡片数据。 |
| [06:15] | 可验证凭证（VCs） | 三种授权类型（购物车、意图、支付），作为协议的加密证明。 |
| [08:03] | 合同对话模型 | 逐步演示有人在场的购买流程，从委托到最终授权。 |
| [13:07] | 问答 – 信任与注册表 | 允许列表、去中心化注册表以及网络标准身份验证如何融入短期和长期路线图。 |
| [14:42] | 支付级安全 | AP2 在 A2A 和 MCP 之上提供的“支付级”保证。 |
| [16:03] | 退单保护 | 已签署的购物车授权如何在错误商品被批准时保护商家和用户。 |
| [18:04] | 实时演示 | 人在场流程的逐步演示（视频链接）。 |
1️⃣ 信任问题 (01:43)
“如果有一个代理能够在演唱会门票一开售就为你购买怎么办？你想要两张票，最高花费 200 美元，并且视野良好。要让代理充当你的票务购买者，你必须交出完整的请求 以及 你的信用卡信息。你怎么能确保代理不会买 200 张票 或向你收取一辈子的橡胶鸭费用？”
该情景说明了阻碍代理驱动商业的 信任危机。
方案预览： Google 的 Agent Payment Protocol (AP2) —— 一个开放的“信任层”标准，构建在现有支付基础设施之上。
2️⃣ 为什么现有支付方式不适用于代理人 (02:29)
| 挑战 | 以人为本的系统 | 代理人视角的缺口 |
|---|---|---|
| 授权 | 浏览器和 UI 让用户直接控制。 | 代理人需要编程式、预先批准的授权。 |
| 代理错误 | UI 错误是可见的；用户可以取消。 | 静默失败可能导致不想要的购买。 |
| 问责制 | 退款追溯到个人。 | 对自主行为没有明确的审计追踪。 |
AP2 通过在代理人、商户和支付合作伙伴之间提供安全、可验证的通信渠道来解决这些问题。它目前作为 A2A（代理对代理）协议的扩展 提供，并依赖代理人使用 模型上下文协议（MCP）。
👉 了解更多: AP2 技术概览 (PDF)
3️⃣ 角色与关注点分离 (04:33)
协议将职责划分为四个专门角色：
- 购物代理 – 您的 AI，负责发现商品并协调购买。
- 商户端点 – 卖家的 API，接收购物车数据和最终订单。
- 凭证提供者 – 安全的数字钱包（例如 PayPal、Google Pay），存储支付凭证。
- 商户支付处理器 – 为支付网络生成最终授权令牌。
关键： 购物代理 永不 看到原始信用卡号，因此 不需要 PCI 合规。支付数据仅在凭证提供者和处理器内部保留。
4️⃣ 可验证凭证 (VCs) (06:15)
VCs 是经过加密签名的数字收据，用于证明已达成的协议。AP2 定义了三种授权类型：
| VC 类型 | 使用场景 | 证明内容 |
|---|---|---|
| Cart Mandate | 用户在场（用户审查购物车） | 用户已批准购物车的确切内容。 |
| Intent Mandate | 用户不在场（例如，购票代理） | 用户授权带有限制的意图（例如，“支出 ≤ $200”）。 |
| Payment Mandate | 所有支付 | 支付网络能够看到有 AI 代理参与，从而满足合规要求。 |
5️⃣ 合同式对话模型 (08:03)
人类在场流程（逐步）
- 委托 – 你告诉代理：“买两张演唱会门票。”
- 发现与协商 – 代理联系商家端点以建立临时购物车。
- 完成购物车 – 代理向你的 Credential Provider 请求支付方式。你只能看到掩码后的引用（例如，后 4 位数字）。
- 带授权的授权 – 代理向你展示最终购物车。
- 签署 – 你对 Cart Mandate 进行加密签名 → 不可否认的合同。
- 购买 – 代理将已签名的授权转发给商家。
- 支付处理器 – 使用该授权从 Credential Provider 获取支付令牌并完成交易。
信任机制（短期）： 手动 allow‑lists（允许列表）已批准的代理/商家。
长期愿景： 利用开放网络标准（HTTPS、DNS 所有权）实现自动化身份验证。
6️⃣ Q&A – 信任与注册表 (13:07‑14:42)
- Higher‑level trust for payments – AP2 在基础的 A2A/MCP 协议之上增加了“支付级别安全”。
- Decentralized registries – 短期内使用允许列表；未来将依赖去中心化的信任注册表和基于 DNS 的验证。
- Industry alignment – 所有角色（商户、凭证提供者、处理器）已经存在；Shopping Agent 是唯一的新参与者。
7️⃣ 退款争议保护 (16:03)
情景： 代理向你展示蓝色鞋子，你想要青色，但你点击了“批准”。
解决方案： 已签署的 购物车授权 精确记录了你批准的内容（蓝色鞋子）。商家现在拥有加密证据，保护他们免受欺诈性退款争议，同时你也免受未经授权的代理行为的影响。
8️⃣ 实时演示 – 人员在场流程 (18:04)
观看演示： [YouTube link – Human‑Present AP2 Flow]
演示逐步演示了第5节中描述的每个步骤，展示了 UI 提示、凭证提供程序交互以及最终授权。
📚 进一步阅读与资源
- 代理支付协议 (AP2) 规范 – [GitHub repo]
- A2A（代理对代理）协议概览 – [Link]
- 模型上下文协议 (MCP) 文档 – [Link]
- 可验证凭证数据模型 1.0 – [W3C Recommendation]
讨论摘要
-
演示场景
- 用户与一个发现产品的代理进行交互。
- 然后 凭证提供者（PayPal） 介入。
- 用户通过 PayPal 选择了运输和付款信息，而代理仅看到一个引用。
- 用户签署了 购物车授权书，完成购买。
-
时间戳:
[19:43]
与现有框架的兼容性
-
关键问题： 这是否兼容像 LangGraph 或 CrewAI 之类的框架？
-
答案： 是。
- Prateek 确认 Agent Payment Protocol (AP2) 是框架无关的。
- 只要你的代理能够通过 A2A（Agent‑to‑Agent）或 MCP（Merchant‑Credential Provider）进行通信，就可以使用 AP2。
-
时间戳：
[21:13]
入门
- 访问 GitHub 仓库（链接由 Prateek 提供）。
- 选择你的角色 – 商家、凭证提供者等。
- 浏览所选角色的示例代码。
展望未来：动态谈判
“我想要那件缺货的红色连衣裙。我需要在明天之前… 我愿意多付30 %。”
- 商家的代理可以解读此 意图。
- 如果连衣裙有货，代理可以自动完成交易。
- 结果：
- 本来失去的销售转变为已完成的订单（含加价）。
- 用户收到他们想要的确切商品。
这种愿景说明 安全支付基础设施 是迈向能够执行真正有用的现实任务的代理的基础步骤。我们正从简单的、程序化的网络转向 对话式、合约式网络，AP2 提供了所需的框架。
行动号召
- 查看 Agent Payment Protocol 的 GitHub 仓库。
- 确定 你在这个新兴生态系统中可以扮演的 角色。
- 立即开始构建！