## 预算检查在模型内部 你会把你的信用卡交给 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 实地指南](/zh/guides/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（代理支付协议，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 实地指南](/zh/guides/ap2-field-guide/) - **代码库：** 项目发布时公开