当结账向代理开放时，发生了什么变化
完成购买的浏览器代理并非在点击表单。它是在行使被委托的消费权限。用户已将选择商家、组装购物篮、选择存储的支付方式并确认总额的能力交给了一个软件进程。从法律意义上讲，这是一种委托-代理关系，被压缩成一系列 DOM 事件和网络调用的轨迹。
然而，商家看到的只是一个会话。它看到 user-agent 字符串、cookie、设备指纹和支付令牌。它看不到委托人。用户看到的是一个结果：订单确认、扣款、预计送达时间。用户看不到为产生该结果而订立的合同。而代理在轨迹中途接受的条款——商家当前的服务条款、退货政策、仲裁条款、订阅续订条款——除了代理的上下文窗口外，无人可见，而该窗口在运行结束时即被丢弃。
这就是结构性变化。结账过去是点击确认：人类阅读（或不阅读）条款页面并点击按钮。点击即同意，页面即记录。现在，同意由模型生成，页面可能从未呈现给人类，而记录是一段无人保留的令牌序列。同意问题已从用户界面事件转变为机器协商的合同，而过去用于记录它的工件并未随之迁移。
为什么设置开关不够
常见的机构应对措施是设置开关：代理平台中的一个开关，表示代理是否可以交易，可能还带有商家允许列表。这不是同意模型，而是能力标志。
商业中的同意不是全局的。它是按交易、按商家和按金额区间划分的。用户可能授权代理从已知供应商处购买替换滤芯，最高不超过适度的上限，并单独授权在查看购物篮后从陌生商家处进行更高金额的一次性购买。单个开关无法表达这种区别，也无法表达定期订阅续订与首次购买之间的差异。授权是有形状的：委托人、代理、商家、范围、上限、有效期。布尔值没有形状。
撤销也有同样的问题。如果同意的唯一表示是开关，撤销就意味着翻转开关并希望代理能观察到。但运行中的代理可能已经组装了购物篮、选择了支付方式，并正在等待确认步骤。撤销必须能够在运行中途进行，这要求授权是一个可寻址的对象——可以在轨迹飞行过程中被命名、查找和失效的东西。开关不可寻址。它是一种状态，而非记录。
争议暴露了第三个失败。当扣款被质疑时，问题不是用户上个月的设置是什么。问题是代理在接受时刻接受了哪些条款，以及这些条款是否在用户授予的范围内。条款页面会变化。商家会在不通知的情况下更新仲裁条款、补货费和续订措辞。用户上次访问时的条款记录并不能证明争议交易中实际达成的协议。如果没有按交易的工件，争议处理过程除了商家当前页面和用户的回忆外，没有任何可推理的依据。
同意账本草图
解决此问题的机制是同意账本：一个仅追加、可查询的记录，记录每一次消费权限的委托，在授权被行使的时刻写入。
每条记录至少应包含以下字段：
entry_id 唯一、单调递增
principal 授予权限的个人或组织
agent_id 行使权限的软件身份
merchant_id 交易对手
scope 例如：一次性购买、订阅续订、退货
amount_ceiling 代理可承诺的最高总额
currency ISO 代码
expiry 授权失效的时间戳
terms_hash 接受时呈现的条款摘要
terms_uri 条款文档的位置
timestamp 条目写入的时间
parent_entry 用于撤销和修改
条款哈希是承重字段。它不需要存储完整的条款文档，只需一个可与商家发布的版本历史进行核对的摘要。如果商家后来更改了页面，哈希仍能标识接受时生效的版本。terms_uri 为争议处理过程提供了检索它的指针。
条目是仅追加的。撤销不会修改原始授权；它会写入一条新条目，其 parent_entry 指向该授权，范围标记为 revoked。原始条目仍可查询。这很重要，因为争议可能需要确定同意不仅被撤回，而且是在何时撤回的，以及代理是否在撤销生效之前已经提交了交易。仅追加日志能回答这个问题；可变标志会抹去它。
账本必须能被利益不同的两方查询。用户需要在一个视图中看到其代理行使的每一次委托，包括上限和有效期，并撤销任何仍然有效的委托。商家的争议处理过程需要检索特定交易的条款哈希和范围，同时不能看到用户的其他授权。这是一个读取授权问题，而非存储问题，也是最有可能在首次实现中被低估的部分。
一个具体的交互：代理到达结账页面，商家页面呈现条款，代理计算摘要并写入一条账本条目，包含商家、范围、上限和哈希。支付授权携带 entry_id。如果用户在代理等待确认步骤时撤销，撤销条目被写入，代理下一次读取账本时返回已撤销状态，导致其放弃轨迹。如果
k-network-cables-f7a795-35eb46.jpg)
诚实的权衡
同意账本为每次代理结账增加了延迟和依赖。写入条目、哈希条款和检查撤销是往返操作，而人类点击按钮则无需付出这些代价。如果账本不可用，代理要么失败关闭——放弃合法购买——要么失败开放，这违背了初衷。设计必须做出选择，而两种选择都有代价。在轨迹的每一步都查询账本会拖慢代理；仅在授权时查询账本会错过运行中途的撤销。实际的折衷方案是在授权时写入，并以有界间隔轮询撤销，接受一个已撤销授权仍可能提交的窗口。该窗口应在条目中说明，而非隐藏。
还有隐私成本。消费委托账本是一份丰富的行为记录。应限定范围，使商家只能看到与其交易相关的条目，并且用户保留导出和删除自己条目的能力，但须遵守争议保留要求。仅追加并不意味着不朽；它意味着删除本身也是一条条目。
与商业风险的交互
标记代理商务的银行和卡组织所反应的不仅仅是欺诈率。它们反应的是工件的缺失。一直依赖授权点有真人存在的风险模型，现在面对的是一个没有委托人、没有可读同意和没有条款记录的会话。欺诈信号很弱，因为从网络的角度看，合法模式和滥用模式看起来完全相同：软件使用存储的凭证，没有人类参与。
同意账本并不能消除这种模糊性，但它为风险系统提供了可评分的东西。携带 entry_id 且具有匹配授权、合理上限和有效期的授权，与没有来源的授权是不同的对象。随着时间的推移，工件的存在本身成为一种信号，而其缺失成为拒绝的理由。率先采取行动于此的机构并非对代理持谨慎态度；它们正在构建使代理商务对已管理它的系统而言可读的记录。
条款更新不是答案。账本才是。
来源
封面照片：Jakub Pabis / Pexels。