独立解读
Agent 帮用户购物：搜索、下单和支付怎样连起来？
01商品搜索02用户确认03订单交付
类型：场景分析｜资料查阅：2026-10-28｜场景为假设
“帮我买一把适合小户型的椅子，预算 800 元以内。”这句话看起来简单，但它包含搜索、筛选、确定商品、选择地址和配送、确认总价、支付与售后。Agent 能否代劳，取决于用户授权、商家提供的信息和具体结账方式。
一次购物有六个阶段
flowchart LR
A[理解偏好与约束] --> B[发现商品]
B --> C[比较价格和条件]
C --> D[生成结账信息]
D --> E[授权与支付]
E --> F[订单交付和售后]
例如，Agent 发现一把标价 699 元的椅子。标价不是最终支付额：配送费、税费、安装费及退货规则可能改变选择。商品库存也可能在确认前变化。因此，应该在实际结账前核对商品、总价、配送地址和变更，而非只依赖搜索结果。
三种不同程度的代办
| 模式 | Agent 做什么 | 用户在哪里参与 |
|---|---|---|
| 推荐 | 搜索和比较，交出购买链接 | 用户自行选购与付款 |
| 协助结账 | 整理购物车和支付信息 | 用户审阅最终订单并确认 |
| 约束内自主执行 | 根据事先设定的条件购买 | 用户预先同意条件，例外时再确认 |
自主执行不是“Agent 想买什么就买什么”。例如用户可以限制商品型号、总额、有效期或商家；实际是否支持这些限制，以具体产品为准。出现替代商品、地址变化或超额等情况时，系统可以要求用户重新确认。
协议帮助参与方交流，但不代替商家履约
商品发现、购物车、结账和授权由不同环节组成。ACP 官方网站和 UCP 官方文档描述了 Agent 商业交互中的开放规范；AP2 流程则描述如何处理与结账和付款相关的授权记录。它们覆盖的层面有差异，不能把某个协议名称当成整条交易链的同义词；是否能组合使用需核实各实现。
以 AP2 的用户不在场流程为例，用户先对约束条件给予授权，随后 Agent 选择符合条件的具体结账内容并提供可验证的授权记录。这是规范描述，不表示每家购物网站都已支持。
买到之后，责任从哪里开始？
| 用户想知道 | 系统至少应保留什么 |
|---|---|
| Agent 为什么选这件？ | 关键条件、备选项和决策依据 |
| 实际付了多少？ | 订单总价、费用和支付状态 |
| 商品在哪里？ | 商家订单号、配送及交付状态 |
| 买错了怎么办？ | 取消、退货、退款入口和商家规则 |
支付成功并不等于发货，更不等于用户满意。商品错选、延迟交付和退货争议仍需依据商家及支付服务的实际政策处理。
一套好的 Agent 购物体验，应该让用户清楚区分“我授权了什么”“Agent 买了什么”和“商家承诺交付什么”。它的成熟程度，应以完整订单与售后能否被理解来衡量，而不只是能否自动点击付款。