结账究竟在断言什么
结账流程不是带提交按钮的数据录入表单，而是一场同意仪式。当买家点击下单时，他们在某一特定时刻、针对某一特定交易对手，同时断言四件事：
- 此商品，以此价格，按此条款。
- 我是持有该支付工具的本人。
- 我此刻授权这笔扣款。
- 我接受商家所展示的取消与退货政策。
流程中的每一个字段——购物车行项目、税费行、配送预估、条款复选框——都是为了让这一断言可读、可归属。按钮就是签名。
已存储的支付凭证是先前同意事件的残留。存档的卡不是可复用的能力，而是一份记录：某个人在更早的某个时点，授权某商家在特定条件下向该工具扣款。凭证编码的是被授予的权限，而非一般性的交易权利。
驱动结账流程的浏览器 Agent 正在重放一套为人类同意而设计的序列。它填写字段、点击按钮，产生一个看起来像同意事件的请求。但 Agent 无法产生底层的断言，它只能模拟商家系统被构建为读作同意的那层表面。模拟与断言之间的落差，正是授权模型断裂之处。
为什么 Agent 可读的结账会改变威胁模型
一旦 Agent 能解析商品页面，读取价格与承诺支付之间的距离就坍缩了。抓取与购买融合为同一种能力。一个能提取价格、SKU 和配送窗口的 Agent，已具备构造有效订单所需的一切。唯一剩下的屏障就是结账流程本身——而这道屏障是 UI 约定，不是安全边界。
预订与库存系统是围绕人类节奏的争用而设计的。限量商品受到人类阅读、决策、输入与确认这一摩擦的保护。这种摩擦并非附带产物，它就是限流器。Agent 将其转化为吞吐量竞赛。当众多 Agent 瞄准同一库存时，争用模型发生反转：原本假设买家缓慢而审慎的系统，如今面对以机器速度涌来的、语法上有效的订单。商家的队列深度、重试逻辑和预订 TTL 从未按此规模设定。
更深层的损失是信号。商家的分析栈通过一组行为线索来区分浏览会话与购买会话：停留时长、页面深度、支付步骤的犹豫、反复修改购物车。这些线索是商家判断人类在场并同意的唯一可靠指标。Agent 不产生其中任何一项，或者只把它们作为自身控制回路的产物而产生。商家失去了区分一个意图购买的会话与一个正在代他人购买的会话的能力——也随之失去了施加正确风险处置的能力。
限定范围的消费凭证作为接口
对 Agent 而言，正确的接口不是结账表单，而是一份编码了委托边界的凭证。
限定范围的消费凭证至少应沿四个轴设限：
- 商家：凭证仅对具名交易对手或具名商家类别有效。
- 金额上限：单笔交易的最大值，理想情况下还有凭证生命周期内的累计最大值。
- 商品类别：对可购商品的限制——品类、SKU，或商家可据以校验的已声明意图。
- 有效期：硬性有效窗口，过期后凭证即失效。
关键在于，该凭证是依据用户意图记录签发的，而非在结账时铸造的。意图记录是人类的断言：他们想要什么、向谁要、在什么边界内、持续多久。凭证是这份记录向商家可验证形式的投影。在结账时铸造会重蹈最初的错误——它会把购买时刻当作同意时刻，而同意实际上早于 Agent 的活动。
结算应在既定窗口内可逆，并以意图记录作为争议凭据。如果 Agent 在声明的边界之外交易，商家与签发方应能在不依赖 Agent 自身日志的情况下重建被授权的内容。意图记录是事实基准；凭证是主张；结算是核对。
一种具体机制
将凭证视为一个已签名的结构化令牌，具有商家限定的受众，以及一组以谓词表达的约束：
{
"issuer": "intent-registry.example",
"principal": "user-42",
"audience": "merchant-7",
"intent_ref": "intent-9f3a",
"limits": {
"amount_ceiling": "currency-scoped",
"aggregate_ceiling": "currency-scoped",
"item_classes": ["consumables", "household"],
"not_before": "timestamp",
"n
商家验证签名，将受众与自身身份核对，将商品与声明的类别核对，将金额与上限核对，将当前时间与窗口核对。任一谓词不通过，交易即在授权层被拒绝——而非在 UI 层，在那里 Agent 只需换个输入重试即可。
诚实的权衡是：这把复杂性推给了商家。商家必须接入意图注册表、验证签名，并维护争议的核对路径。小商家不会这么做。另一种选择——让结账对浏览器 Agent 敞开——则把复杂性以拒付和争议扣款的形式推给支付网络和持卡人。问题不在于复杂性是否存在，而在于由谁吸收。
## 商家侧的契约
商家应发布一个区别于人类界面的、面向 Agent 的结账界面。不是隐藏端点，而是语义明确的文档化接口：
- **速率与重试语义**：每窗口允许多少请求、期望何种退避、429 意味着什么以及应等待多久。无视这些的 Agent 会被拒绝，而非被静默限流。
- **来源标头**：每个 Agent 请求都携带一个标头，标识委托主体与凭证签发方。商家由此可将请求归属到某个人和某个签发机构，而非一个不透明的客户端。
- **声明意图日志**：Agent 声明的意图与订单一同记录。这使得在无需 Agent 配合的情况下也能核对——商家拥有自己对所声明内容的记录，结算可据此校验。
这份契约不是礼节，而是商家保留授权信号的最低要求。没有它，商家就只能读着一个模拟的同意事件，并寄望于模拟是忠实的。
令人不安的结论是：浏览器 Agent 是商业授权的错误抽象。它们是被应用于一个具有特定同意要求领域的通用工具。领域不应迁就工具，而应暴露一个与其实际需求相匹配的接口：一种有界的、可归属的、可逆的委托——以及一份使该委托可验证的商家侧契约。
在该接口存在之前，每一次 Agent 驱动的结账都是一场由无法同意的当事方执行的同意事件。那不是工具调用，而是一个带有结算轨迹的范畴错误。
_封面照片：Jakub Pabis / Pexels。_