智能体经济：身份、委托与机器支付

付费智能体是一条交易路径，不是新的法律主体。设计这类系统时，不该笼统地问智能体是否「可信」，而要判断几项彼此独立的决定是否一致：哪套软件发出了请求，哪位委托人给予了授权，商户是否接受，付款是否成功，以及承诺的商品或服务是否已经交付。

这些决定会留下不同的证据。身份不能证明权限，权限不能证明意图，付款不能证明交付，签名记录也不能证明模型安全。混淆这些界限，或许能做出流畅的演示，却会留下无法解决的争议。

从角色入手，不要先看协议

一笔交易可能涉及六个角色：

• 委托人： 尝试购买所代表的个人或组织；
• 智能体工作负载： 选择并调用操作。模型、运行时和服务身份不一定属于同一家运营方；
• 商户或资源服务器： 为商品定价、执行访问策略并记录履约情况；
• 授权服务器： 或凭证签发方，记录委托人允许了哪些操作；
• 支付服务商： 验证或执行付款指令；
• 清算网络： 在机构或账户之间转移最终价值。

同一组织可以同时承担多个角色，但各项决定仍然彼此独立。商户依据自身策略独立决定是否接受智能体、授权书和订单。支付服务商也会独立决定是否授权或清算资金。任何一方的决定都不能证明另一项决定已经发生。

这延续了 第 56 章 对身份认证、授权、凭证与实际效果的区分。商务交易在此基础上增加了价格、支付状态、履约，以及失败后的恢复。

身份不等于权限

RFC 9421 规定的 HTTP 报文签名，让接收方可以验证 HTTP 报文中指定部分是否由某个密钥持有者签署，并确认这些部分在传输途中没有被篡改 (Backman et al. 2024)。它不能识别人类委托人，也不会授予购买权限。当前的 Web Bot Auth 工作把 HTTP 报文签名与智能体标识和密钥发现结合起来。截至 2026 年 8 月，其协议仍是正在推进的互联网草案，不是 RFC；工作组章程也明确说明，终端用户认证不在范围内 (Meunier and Major 2026; Internet Engineering Task Force 2026)。Visa 的可信智能体协议（Trusted Agent Protocol, TAP）同样使用 RFC 9421 签名识别智能体，并定义了可选的消费者和支付证据。它是一项 Visa 规范，不是所有商务协议共用的通用身份层 (Visa 2026)。

OAuth 不只是应用程序标识机制，而是一套授权框架。访问令牌代表具有特定范围和期限的委托访问权 (Hardt 2012)。RFC 8693 令牌交换可以表达委托关系并区分主体与行动方，RFC 9396 富授权请求则可以承载结构化的授权细节 (Jones et al. 2020; Lodderstedt et al. 2023)。这些标准提供了重要的构件，但它们本身不会为所有购物指令定义一套可移植的含义，不会迫使商户接受指令，也不能证明订单已经履约。

因此，验证方需要分别回答两个问题：

1. 身份认证： 哪个密钥、工作负载、客户端或服务签署了这项请求？
2. 权限验证： 哪位委托人允许在什么期限内，面向哪个目标接收方，对什么资源执行什么操作？

即使其中任一问题得到有效答案，接收方仍须依据自身业务规则决定是否接受。

授权书是一项有边界的指令

商务授权书的范围必须足够窄，让验证方无需还原整段对话就能作出判断。最基本的记录应写明委托人、智能体工作负载、目标接收方、允许的操作和资源、最高金额和币种、签发时间和到期时间、对商户或商品的条件、所需的审批规则、是否允许再次委托、幂等键或随机数，以及撤销引用。记录还要指明这些字段采用哪项策略或模式解释。

AP2 把这个思路用于付款证据。其现行规范定义了开放式结账授权书、封闭式结账授权书和付款授权书。在没有人即时参与的流程中，用户可以先签署开放式约束，智能体随后再把选定的结账细节写入授权书。验证方可以借助这些产物核对订单、付款指令与此前的授权，但它们不会自行完成清算，也不会自行分配法律责任 (Agent Payments Protocol 2026)。

签名凭证也有同样的边界。W3C 可验证凭证数据模型规定了表达声明并附加安全机制的方法。其验证模型不能证明声明为真，也不能要求验证方接受。验证方仍须检查凭证状态并执行自身业务规则 (Sporny et al. 2025)。授权书是决策所需的证据，不是决策本身。

协议名称掩盖了不同职责

智能体商务项目之间确有重叠，但并不是一个强制性协议栈中可以互换的层。与发布时的宣传相比，各机制承担的职责及其边界更适合用来比较：

• RFC 9421 与 Web Bot Auth： 负责请求认证和智能体识别，不证明委托人的权限或意图，也不代表商户接受；
• OAuth、令牌交换和富授权请求： 负责受保护资源的授权与委托，不代表订单、付款或交付已经完成；
• ACP 与 UCP： 负责商品、结账、订单和能力协作，不构成一条通用的支付或清算轨道；
• AP2： 提供结账与付款授权的交易证据，不负责清算、商户接受或法律责任；
• Visa TAP： 在其方案内提供智能体识别和可选的商务证据，不是跨方案的通用身份或授权机制；
• x402 与 MPP： 通过 HTTP 协商支付与协调清算，不会带来需求、利润、交付或争议解决。

现行 ACP 规范让商户仍是记录系统，并允许支付处理器协商如何提供凭证。付款与清算仍由商户的支付服务商处理 (Agentic Commerce Protocol 2026)。UCP 涵盖能力发现、结账、订单、支付令牌交换和身份关联，也可以选择与 AP2 组合 (Universal Commerce Protocol 2026)。ACP 和 UCP 属于结账协作，AP2 提供交易证据，TAP 在其方案内识别智能体，x402 与机器支付协议（Machine Payments Protocol, MPP）提供支付交互。实现可以组合使用这些机制，但各项规范并不构成一张通用依赖图。

小额支付的经济性因何改变

HTTP 标准至今仍把 402 状态码保留给未来用途 (Fielding et al. 2022)。更早的系统已经证明，技术上可以完成金额极小的数字支付。1995 年发表的 Millicent 使用经纪方签发的代用券来降低小额交易成本 (Glassman et al. 1995)。真正棘手的是买方为小额购买投入的注意力。Szabo 指出，决定、监控和处理一笔小额购买所需的心智成本可能高于商品价格，并提醒人们，配置购物智能体只是转移了部分工作 (Szabo 1999)。

委托可以摊薄一次决策的成本，但不会让决策变成零成本。设

$$o_{\mathrm{agent}}(n) = \frac{c_m}{n} + c_a ,$$

式中，$n$ 是一份授权书覆盖的购买次数，$c_m$ 是创建和维护这份授权书的成本，$c_a$ 是每笔购买的智能体成本，包括监控、复核和异常处理。再把它与每笔购买的人类决策成本 $c_h$ 比较。只有在 $c_m/n+c_a<c_h$ 时，委托才会降低决策开销。所有成本必须采用同一种单位和同一个核算期，例如每月多少美元或每周多少分钟。这是一项决策模型，并不声称任何符号都有通用数值。

商户面对的是另一条门槛。假设 $n$ 项请求共用一次清算或处理批次，则每项请求的简化净利润为

$$m_n = p(1-r) - \frac{f}{n} - c ,$$

式中，$p$ 是价格，$r$ 是按比例收取的费率，$f$ 是每批固定费用，$c$ 是每笔请求的履约成本。各项仍须采用同一种单位和同一个核算期。批处理可以降低 $f/n$，却不会降低履约成本，也不会创造需求、消除损失或免除退款与争议成本。第 76 章 给出的完整经济账必须明确计入这些项目。

跟踪交易，也要跟踪证据

设计时真正有用的单位，是包含重试与补救的端到端的一次交易尝试。

每次尝试都要保留授权书版本、经过认证的请求方、报价、商户决定、支付服务商响应、履约结果和效果回执。不要把它们压缩成一个 success 标志。有用的状态包括拒绝、需要付款、已授权、已清算、已履约、失败、未知、已退款和有争议。有些状态属于访问控制，有些属于资金，还有些属于交付，因此各自的时间戳和权威来源也不同。

这种区分在重试时尤其重要。付款后超时，可能表示「没有扣款」「已经扣款，但响应丢失」，也可能表示「已经扣款并履约，但回执丢失」。每项逻辑购买都要使用稳定的幂等键，拒绝重放的授权书或随机数，并在至少一次消息投递之上保证业务效果恰好发生一次。在执行不可逆操作之前预留预算，在约定效果发生时提交预算，在确认失败时释放预算。未知结果应进入对账流程，而不是自动重试。付款状态和履约状态要分开保存，使后续退款或争议能够引用原始证据。

x402 是支付协议，不是经济保证

现行 x402 规范具体使用了 HTTP 402，但没有改变标准中 402 状态码本身的定义。一个典型的第 2 版交互如下：

1. 资源服务器返回 402 Payment Required，并在 PAYMENT-REQUIRED 中提供经过 Base64 编码的 PaymentRequired 对象；
2. 客户端从可用方式中选择一种，创建付款载荷，再带着 PAYMENT-SIGNATURE 重试请求；
3. 资源服务器自行验证，或请促成方验证；
4. 验证成功后，服务器执行工作，并自行清算或通过促成方清算；
5. 服务器返回资源，并在 PAYMENT-RESPONSE 中附上清算结果。

该规范区分客户端、资源服务器和可选的促成方，并说明自身不限定网络、代币和币种 (x402 Foundation 2026)。实际使用时，每种方案仍有具体的终局性、流动性、费用、合规、隐私和退款属性。成功清算不能证明响应有用、只交付了一次，或已根据外部合同获得授权。x402 降低的是发起付款请求的集成成本，不能保证需求或正利润。第 79 章 讨论的出版方经济性仍取决于定价、可执行的访问策略和愿意付款的买方。

MPP 进一步说明，支付协议与支付工具也不能混为一谈。它同样采用 402 质询与重试流程，但可以协商稳定币、银行卡或其他支付方式 (Weinstein and Kaliski 2026)。仅凭 402 响应或协议名称，运营方无法知道哪个资产发生了转移、何时达到清算终局，也无法判断哪些退款和消费者保护规则适用。

有活动不等于经济体已经成熟

发布协议不等于生产环境已经采用。代码仓库、合作方名单、交易笔数、支付金额和受控实验测量的是不同现象，不能放在同一条增长曲线上。

Anthropic 的 Project Deal 之所以有参考价值，正是因为边界清楚。在这项内部实验中，员工使用的智能体协商了 186 笔交易，总交易额略高于 4,000 美元 (Anthropic 2026)。这项研究可以揭示该市场内部的行为，并比较指定的模型条件，却不能据此推断总体需求、商户接受度、欺诈损失或整个经济体的市场份额。要回答这些问题，需要生产环境中的分母，并注明测量期间，包括符合条件的用户、尝试下单数、接受订单数、支付金额、履约、退款、争议和损失。

模型质量仍可能改变议价结果、搜索成本和获得报价的机会。这样一来，看似纯技术的选择就会变成 第 77 章 讨论的市场力量问题。推断必须服从证据：有边界的实验可以提出测量问题，不能直接给出市场预测。

把交易契约落实到运营

在允许智能体动用资金之前，应把交易契约写成所有参与方都能记录和测试的字段：

• 权限： 委托人、智能体工作负载、目标接收方、允许的操作、金额、币种、到期时间、审批规则、再次委托规则和撤销引用；
• 订单： 商户、报价标识、商品限制、税费与交付条款、允许的替代品和报价有效期；
• 控制： 随机数、幂等键、累计预算、单笔限额、速率限制、预留、提交和释放规则，以及升级处理阈值；
• 证据： 认证请求、授权书版本、授权决定、付款状态、履约状态、效果回执和保留期限；
• 恢复： 超时负责人、对账流程、取消期限、退款路径、争议路径，以及获准重试的一方。

测试应覆盖重复投递、签名重放、结账期间撤销授权、批准后报价发生变化、部分履约、清算后交付失败、成功后响应丢失、终局性延迟，以及预算周期结束后的退款。无法对结果分类时，智能体应停止或升级处理。猜测不是恢复机制。

模型仍是这份契约内不受信任的规划器。提示词注入、工具遭到入侵和误导性商户内容属于 第 57 章 处理的运行时问题。支付控制可以限制后果，却不能阻止这些问题发生。

延伸阅读