代理支付：授权令，而非信任

预算检查在模型内部

你会把你的信用卡交给 AI 吗？为了本期项目，我这样做了。有趣的部分不在于它成功了，而在于阻止它超额消费的协议和治理层。

我遇到的问题是这样的：大多数代理支付方法都将预算检查内置于 LLM 内部，即一个系统提示词，写着“消费不要超过 X 美元”。这在结构上等同于要求某人执行自己的消费限额。决定购买的模型就是检查是否应该购买的模型。当这两个是同一个组件时，你没有控制权，你只有一个建议。

现在有一个开放协议正是针对这个问题：AP2，代理支付协议 v0.2，由 Google 的 A2A 团队构建并捐赠给 FIDO 联盟。核心操作很简单：授权令存在于代理之外。它是外部的，经过加密签名，代理无法覆盖它。代理在一个它无法自行划定也无法更改的边界内运行。

AP2 定义了一个授权令链，这条链是关键所在：购物代理、Checkout Mandate、商家代理、Payment Mandate、凭证提供商、支付处理器。每个环节都是可验证的。任何环节都不能跳过。只有当整个链条通过验证时，支付才会发生。

场景：2026 年 FIFA 世界杯四分之一决赛门票

抽象协议需要具体的购买场景，因此这个演示是一个消费者购物礼宾代理，带着一项严格的任务要求。用户签署一份授权令：两张 2026 年 FIFA 世界杯四分之一决赛的 3 类门票，每张低于 1,500 美元，总价硬性上限为 3,200 美元。代理彻夜监控模拟票务市场 TicketVault。无人值守。

当价格下降时，DMN 消费策略会在 Camunda 业务规则任务中评估购物车。该评估在模型之外，在 Camunda 中原生运行，其结果决定了后续的一切。我通过相同的治理层构建了三条路径：

路径	触发条件	DMN 结果	结果
黄金路径	价格降至 $1,350，购物车总价 $2,700	APPROVE	$2,700 收据，完全自主
人在回路	价格降至 $1,560，购物车总价 $3,120（上限的 97.5%）	HITL_REQUIRED	结账前需经支付台批准
授权令违规	现有购买 $3,500 超过 $3,200 上限	DECLINE	在到达处理器之前自动拒绝

黄金路径是大家最想看到的演示：凌晨 3 点价格下降，代理购买，早上收到收据。另外两条路径才是产品的核心。购物车总价达到上限的 97.5% 不会以技术性理由蒙混过关；它会唤醒支付台的人工审核员。而超过上限的购买不会通过巧妙的提示词来协商降低；它会在支付处理器知晓之前，由规则表拒绝。

治理层

DMN 消费策略有五条规则，我喜欢它的枯燥无趣：一个上限检查，一个接近上限触发器（将超过授权令 95% 的任何情况路由到人工审核），一个支付工具白名单，一个速度限制，以及一个兜底批准。它在 Camunda 中作为业务规则任务运行，而不是在 LLM 内部。代理永远不会将策略视为可以进行合理化规避的文本。它看到的是一个决策结果。

第三层是审计追踪，它随架构免费提供。每个授权环节都存在于 Camunda Operate 中：授权令签发、价格捕获、DMN 评估、凭证签发、收据存储。每个决策都永久保存为一个流程实例，你可以打开并回放。没有人为此编写日志代码。

LLM 提议，DMN 处置。如果你的消费策略可以被精心编写的段落所左右，那它就不是真正的消费策略。

授权令，而非信任

AP2 v0.2 定义了两种授权令类型，每种都包含一个开放阶段和一个封闭阶段。开放阶段意味着用户预先签署约束条件。封闭阶段意味着代理签署其中发生的具体交易。

Checkout Mandate。 用户预先签署商品范围、价格上限、有效期和商家白名单。在购买时，代理用具体的购物车信息（SKU、价格、结账哈希）来封闭它。商家在履行任何操作之前验证封闭的授权令。

Payment Mandate。 用户预授权支付工具：资金来源、最大金额、类别限制。代理用确切金额和结账哈希来封闭它。凭证提供商在签发支付令牌之前验证这两个授权令。

封闭步骤是加密技术发挥其价值的地方。每个授权令都通过 ECDSA P-256 签名绑定到特定交易。这两个授权令都不能重复使用，也不能伪造。链中的任何一方都可以独立验证，无需中央机构。最后一个特性使得这条链成为协议而非平台。

本期项目有一篇配套文章，更深入地探讨了协议机制、威胁模型和故障模式：AP2 实地指南。如果说本文是本期项目，那么实地指南就是手册。

未在 LinkedIn 帖子中提及的内容

本期项目仍在构建中，因此坦诚的说明比平时更重要。

该演示模拟了几个 AP2 组件。凭证提供商和完整的 A2A 传输是为了演示目的而模拟的；TicketVault 是一个虚假市场。忠实于 AP2 v0.2 的部分是评估协议的关键部分：授权令结构、签名逻辑（通过 jose 实现的真实 SD-JWT，真实的 ECDSA P-256 签名）以及各方交互。治理层则完全没有模拟：BPMN、DMN 消费策略和人在回路支付台都是在实时 SaaS 集群上运行的真实 Camunda 8。

授权令模式也特意设计为技术栈无关。Camunda 是我的引擎，但相同的先开放后封闭的授权令流程也适用于 Temporal、LangGraph、n8n 或纯 Node.js。代码库中包含一份 MAKE_IT_REAL 文档，其中提供了从该演示到生产环境 AP2 的 5 步升级路径，详细说明了要替换哪些模拟组件以及替换顺序。

另一个坦诚的说明：代码库在项目发布之前是私有的。它将与项目一起公开，同时还有演示视频。实地指南已经上线，因为协议分析无需等待我的生产计划。

发布日志

• 协议： AP2 v0.2（代理支付协议，Google A2A 团队，捐赠给 FIDO 联盟）
• 引擎： Camunda 8（实时 SaaS 集群）：BPMN 编排，DMN 消费策略，人在回路支付台
• 模型： Claude Sonnet 作为购物代理
• 加密技术： 通过 jose 实现的 SD-JWT，ECDSA P-256 授权令签名
• 策略： 5 条规则的 DMN 决策表（上限，95% 接近上限时触发人在回路，工具白名单，速度限制，兜底批准）
• 前端： 使用 AG-UI 通过 SSE 实现的 React 前端，沿用自 EP 02
• 后端： Node.js
• 配套资源： AP2 实地指南
• 代码库： 项目发布时公开