让智能体发起付款，授权交给规则系统

AI Agent 可以替用户找商品、比价格，甚至发起购买，但「判断值得买」和「有权付款」应该分开。作者的核心主张是：让模型提出付款请求，由独立、确定性的系统决定这笔钱能不能花。

这篇文章的价值在于把「AI 钱包」拆成了程序员熟悉的工程问题：权限、幂等、状态机和审计。它没有给出实测数据或完整实现，却指出了一个关键边界：模型可以参与决策，资金权限不能跟着模型的判断一起漂移。

模型能决定买什么，为什么不能直接掌握钱包

作者给出的流程是：用户或业务意图进入 Agent，Agent 输出结构化付款请求，再经过策略与风险检查，获得受限的支付能力，交给支付基础设施执行，最终进入商户交付、账本与对账流程。

这里的「受限支付能力」，可以理解为只能在指定条件下使用的付款许可。

为什么要多隔几层？因为 Agent 做决定之前，可能读取网页、邮件、PDF、API 响应或商户描述。这些内容都可能夹带提示注入（prompt injection）：外部材料里藏着指令，诱导模型偏离用户要求。如果模型同时持有卡号、私钥、银行凭据或不受限的钱包余额，一次内容处理失误就可能变成资金损失。

安全边界应该保证：即使模型被误导，它提交的付款请求仍然要通过独立规则。

作者用下面的授权示例说明，权限应该具体到什么程度：

Agent A may spend up to ₹5,000
at SOFTWARE merchants
for PROJECT-42
until 18:00 UTC
with a maximum of one transaction.

要看的是最后一行：金额、商户类别、项目和有效期之外，还限制了最多一笔交易。仅有金额上限，并不能完整表达授权范围。

约束还可以包含指定商户、一次性或周期性付款，以及是否需要人工批准。不过，作者也明确承认，并非所有支付通道都原生支持这些限制。规则可能分别由 Agent 平台、后端策略引擎、支付服务商（PSP）、支付网络、钱包或商户执行。

落地时需要逐条确认「谁负责拦截」。把约束写进提示词，不等于已经建立了支付权限控制。

用户说过可以购买，后台还要保存什么

假设用户要求：购买下周五晚间飞往 Bengaluru 的直飞航班，价格低于 ₹9,000。Agent 可能几小时后才找到合适航班，此时只翻聊天记录判断用户是否同意，证据就太松散了。

作者建议把自然语言要求转换成持久化授权记录（mandate），在实际交易发生时据此校验：

{
  "action": "purchase_flight",
  "destination": "BLR",
  "departure_after": "18:00",
  "max_amount_minor": 900000,
  "currency": "INR",
  "nonstop_only": true
}

这里要看 max_amount_minor：金额以最小货币单位记录，900000 对应 ₹9,000，不能按 900000 卢比处理。

但这个示例并不完整。用户要求里的「下周五」没有对应的日期字段，departure_after 也没有说明时区；「低于 ₹9,000」是否包含边界金额，同样没有明确。这些缺口需要在授权落库前补齐，否则结构化 JSON 只是格式明确，业务含义仍可能含糊。

执行付款时，系统要回答的是：交易发生的那一刻，用户究竟授权了什么。模型当时如何理解用户，可以留作辅助信息，却不能取代授权记录。

作者还要求后端保存授权用户或组织、发起操作的 Agent、已有权限、评估策略、请求金额、实际成功情况、重试、人工审批，以及交付或退款结果。聊天历史、长期记忆和检索上下文都不能充当财务账本，因为它们承担的是上下文管理，无法替代持久、可核查的交易事实。

超时以后，Agent 为什么不能自己判断再付一次

支付成功了，响应却在网络中丢失，Agent 看到的只有超时。如果它推断「大概失败了，再试一次」，就可能造成重复扣款。

这里需要稳定的业务标识和幂等（idempotency）语义：多次执行尝试，仍然对应同一个经济动作。作者没有给出具体 API、幂等键生成方法或有效期，因此这部分是架构要求，还不是可以直接接入的实现方案。

超时表示结果尚未确认，不能直接当成付款失败。

付款状态也必须由后端明确管理。作者列出的正常路径包括 REQUESTED、POLICY_APPROVED、PAYMENT_AUTHORIZED、CAPTURE_PENDING、CAPTURED 和 FULFILLED，分别涉及请求、策略通过、支付授权、待扣款、已扣款和已履约。

其他分支包括 POLICY_REJECTED、REQUIRES_HUMAN_APPROVAL、PAYMENT_UNKNOWN、CAPTURE_FAILED、REFUNDED 和 REVERSED。其中 PAYMENT_UNKNOWN 尤其有用：它给「暂时不知道结果」留出了正式位置，避免系统被迫在成功与失败之间猜一个。

这些名称会随支付服务商和支付通道变化。应当保留的是明确的状态及其权威归属：由后端维护交易事实，Agent 读取结果后继续工作，不能从一段对话式工具回复里自行推断资金状态。

我的判断

我认同作者把重点放在委托权限上。一个可信的付款请求，需要说明 Agent X 代表谁、Principal Y 授权了什么动作 Z、授权在条件 C 下是否仍有效，以及本次交易是否满足条件。身份、权限和交易之间能连起来，审计才有依据。

和「让模型按提示词谨慎付款」相比，这套方案把关键控制移到了独立系统中，边界更清楚；和每笔交易都人工确认相比，它提供了在限定范围内自动执行的空间，但代价是需要建立授权、策略、状态和对账机制。

文章没有展示团队实测、攻击测试或重复扣款率的对照数据，也没说明跨系统规则如何保持一致、授权怎样撤销。这是一套架构主张，不能据此宣称某种实现已经安全。尤其是航班示例中的日期缺失，提醒我们：规则是否确定，不只取决于有没有策略引擎，还取决于授权信息是否完整。

能拿来做什么

• 给具备购买能力的 Agent 接工具时，先让它提交结构化付款请求，再由 Node 后端校验授权范围，避免把通用支付凭据直接交给模型。
• 在购买确认页面展示并保存金额、币种、商户、有效期、交易次数和审批条件，让用户确认的内容能够与后续交易逐项核对。
• 给同一购买动作分配稳定业务标识，并明确超时后的查单与重试规则；前端遇到结果未知时，应展示待确认状态，避免诱导用户再次付款。
• 把授权、策略判断、付款状态、重试和退款串成可追查记录，让客服与开发者能从后端事实判断发生了什么。