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

预算检查在模型内部

你会把信用卡给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 Business Rule Task中评估购物车。该评估发生在模型之外，在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中作为Business Rule Task运行，而不是在LLM内部。代理永远不会将策略视为可以合理化规避的文本。它看到的是一个决策结果。

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

LLM提出建议。DMN做出决定。如果你的消费策略可以被精心编写的段落所改变，那它就不是一个消费策略。

授权令，而非信任

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

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

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

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

这一集有一个配套文章，更深入地探讨了协议机制、威胁模型和故障模式：AP2 Field Guide。如果这篇文章是这一集，那么现场指南就是手册。

未在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 (Agent Payments Protocol, Google A2A team, donated to the FIDO Alliance)
• 引擎： Camunda 8（实时SaaS集群）：BPMN编排，DMN消费策略，人在回路支付台
• 模型： Claude Sonnet作为购物代理
• 密码学： 通过jose实现的SD-JWT，ECDSA P-256授权令签名
• 策略： 5条规则的DMN决策表（上限，95%接近上限的HITL，工具白名单，速度，包罗万象）
• 前端： React与AG-UI通过SSE，沿用自EP 02
• 后端： Node.js
• 配套： AP2 Field Guide
• 仓库： 剧集发布时公开