Agentic Pay：它解决什么问题
所属：第四部分 · 叠加 Agentic Pay（第 11–12 章） 前置：《支付系统》基础教程部分第 30 章（三个旧假设失效、限权支付凭证、x402）、第 8 章（3DS、令牌化、责任转移）；本课第 8 章（发卡的实时授权与规则）、第 6 章（收单） 本章新概念：四方痛点、委托支出闭环、限权凭证的三种形态、机器可读的结账
（本章和下一章涉及的产品和协议，来自 2026 年年中之前的公开信息。这个领域变化比稳定币还快，要记住的是结构，不是名单。）
一、上一章留下的问题¶
上一章最后说：模型上的钱有了法币和稳定币两种资产，但发起付款的一直是人。2025 年起 AI agent（替人执行任务的 AI 程序，下文简称 agent）开始替人比价、下单、付款。它拿到的是卡号还是余额？有权花多少？出错了谁负责？
《支付系统》基础教程部分讲 Agentic Payments 时说过，这件事让三个旧假设同时失效：验证“是不是本人”失效，因为操作者永远不是本人；逐笔授权失效，因为人给的是一个意图加一个边界；责任规则失效，因为规则表里没有 agent 这一方。那一章讲的是行业全景。本章站到 PSP 这一侧，看它具体要解决什么，以及解法接在模型的哪里。
先从星图的一次采购开始。
二、先看现象：星图让一个 agent 去买东西¶
星图的财务对采购 agent 说：给设计团队订三个月的某设计工具团队版，预算不超过 2,000 欧元，有年付折扣就选年付。
agent 开始干活：去几个商户比价，发现年付 1,680 欧元比按月便宜，选定，进入结账页。到这里为止都顺利。然后三件事同时卡住：
第一，它拿什么付。 星图能给它的只有公司卡的卡号。这等于把一把万能钥匙交给一个程序：它可以在任何商户刷任何金额。财务想给的是“这一次、这一类、不超过两千”，但卡上没有这个选项。
第二，商户把它拦了。 结账页是为人设计的：验证码、设备指纹、行为分析。agent 从数据中心的 IP 发请求，鼠标轨迹是机器的，《支付系统》基础教程部分讲 Agentic Payments 时说过，在这套信号里 agent 长得就像欺诈。商户的风控把它当爬虫拦掉，拦掉的是一个带着真实预算的客户。
第三，买错了谁认。 假设 agent 理解错了，买成了个人版；或者某个商户页面里藏了一段指令，把 agent 引到了另一家更贵的店。财务发现后去找 PSP，PSP 发现每一道验证都是“本人通过”的，卡组织的争议规则里没有“agent 买错了”这一项。
三件事分别落在付款人、商户、PSP 三方身上。再加上事后核对的人，就是全部痛点。
三、付款人、商户、PSP、事后核对各有各的痛点¶
| 哪一方 | 痛点 | 用现有工具硬凑的后果 |
|---|---|---|
| 付款人（企业或个人） | 没有“边界授权”这种东西，只能给一整张卡或一整个账户 | 把万能钥匙交给一个不能完全预测的程序 |
| 商户 | 分不清可信的 agent 和恶意爬虫；结账页只有人能走；价格和库存没有机器可读的版本 | 要么全拦，丢掉客户；要么全放，欺诈上升 |
| PSP 和发卡方 | 授权那一秒的欺诈信号全部失效；出错后责任规则空白 | 要么拒绝所有 agent 交易，要么自己扛损失 |
| 事后核对的人（企业的财务，或用户自己） | 付款成功不等于任务完成；“当时授权的边界是什么”没有记录 | 争议时各说各话，退款和对账没有依据 |
四方的痛点有一个共同根源：支付系统只认“一笔具体的付款”，不认“一个带边界的意图”。人对 agent 说的是意图加边界，agent 交给支付系统的必须是具体的一笔。中间缺一层把前者变成后者的东西。
四、解法：从委托到证据的六步闭环¶
补上那一层之后，星图那次采购变成这样：
| 步 | 发生什么 | 星图的例子 |
|---|---|---|
| 1 委托 | 人给 agent 设边界：任务、金额上限、商户类别、有效期、什么情况要问人 | 软件订阅，不超过 2,000 欧元，30 天内，超过 1,500 要通知财务 |
| 2 形成候选支出 | agent 在边界内比价、选定，形成一笔具体的候选：向谁付、付多少、买什么 | 向某商户付 1,680 欧元，买年付团队版 |
| 3 策略判断 | 系统对照委托：自动批准、拒绝，还是升级给人 | 1,680 在上限内但超过 1,500，通知财务，财务点了同意 |
| 4 生成限权凭证 | 把批准的那一笔变成一个只能用于这一笔的支付凭证 | 一张一次性虚拟卡：只限这家商户，上限 1,680 欧元，24 小时有效 |
| 5 既有执行 | 凭证进入原有的支付轨道 | 商户用这张卡走正常的卡收单流程，星图余额预留、扣除 |
| 6 证据 | 把任务、委托、候选、批准、凭证、付款、发票串成一条记录 | 财务系统里：这笔 1,680 欧元对应哪个任务、哪个委托版本、谁批准的、发票在哪 |
这六步本课叫委托支出闭环。第 1–4 步是新增的那一层，第 5 步是本课前十章讲的全部内容，第 6 步把两者接起来。
第 4 步的限权凭证是整个闭环的关键件。《支付系统》基础教程部分讲 Agentic Payments 时说它是令牌化的进一步收窄：网络令牌把万能卡号变成绑定商户和设备的钥匙，限权凭证再加金额上限、时间窗、单次使用。它在 PSP 的模型上有三种现成的形态：
| 凭证形态 | 走什么轨道 | 由模型的哪一块签发 | 适合什么 |
|---|---|---|---|
| 一次性虚拟卡 | 卡 | 发卡：限商户、限额、限期，用完即废 | 到任何收卡的商户处购买 |
| 限权付款指令 | 银行或本地轨道 | 付款端点：限收款人、限金额、限期的付款授权 | 付供应商、付发票 |
| 链上限权转账 | 区块链 | 链上付款端点：限地址、限金额的签名权限 | 机器对机器的小额高频付款 |
三种形态的共同点是凭证本身就带着边界，出界即拒，不需要事后追。
闭环里还有三条不能互相替代的判断，每一条都对应一个容易犯的错：
- 候选被批准，不等于付款完成。 第 3 步的“同意”只是允许生成凭证，付款还要走第 5 步，可能失败。
- 付款完成，不等于任务完成。 钱付了，商户可能没开通服务，或者开通的是错误的套餐。履约要另外核对。
- 撤销委托，不能逆转已完成的付款。 财务第二天撤销了委托，只能阻止还没生成的凭证，已经付出去的 1,680 欧元要走退款。
五、什么不算 Agentic Pay¶
有了六步，可以反过来判断市场上哪些东西只是零件：
| 它是什么 | 缺了哪几步 |
|---|---|
| 定时扣款、按规则自动付款的脚本 | 没有第 2 步，付款内容不是 agent 形成的，是人预先写死的 |
| 把公司卡号或 API 密钥交给 agent | 没有第 3、4 步，agent 拿到的是通用权限，不是限权凭证 |
| 只做比价、生成付款草稿，由人去付 | 没有第 4、5 步，agent 没有触发付款 |
| 一个可以被 agent 调用的付款 API | 只有第 5 步 |
| 人完整决定的一笔付款，只是用稳定币结算 | 没有第 1–4 步，稳定币只是资产，跟 agent 无关 |
判断标准不是“有没有 AI”，也不是“是否全自动”，而是人的委托能不能变成机器可执行的边界，agent 是否只拿到限权凭证，付款和任务结果是否在同一条证据里。三个都是，才是闭环。
六、接在模型的哪里¶
Agentic Pay 不是新的余额核心，也不是新的轨道。它改变的是付款指令怎么形成，不改变钱怎么走。所以本课前十章的每一块都照用，新增的只是那一层：
| 模型的哪一块 | 在闭环里扮演什么 | 要新增什么 |
|---|---|---|
| 余额核心 | 资金来源。agent 花的是星图的余额，每张凭证的使用就是核心上的一次预留 | 委托和凭证跟余额的关联：某个委托下还剩多少额度 |
| 发卡 | 最现成的凭证签发方。发卡生态那一章讲的规则引擎本来就能限商户、限额、限期 | 凭证的生命周期跟委托绑定，委托撤销时凭证同步作废 |
| 付款端点 | 银行轨道上的凭证签发方 | 限收款人、限金额的付款授权，以及它跟发票的匹配 |
| 收单 | 站在商户一侧：识别可信的 agent，提供机器可读的商品、价格、结账 | 一套让 agent 走得通的结账方式，下一章讲各家协议 |
| 链上端点 | 机器对机器场景的轨道 | 每笔几分钱的付款，按笔计费的链上转账是少数付得起的轨道 |
成因规则：agent 改变的是付款之前的决策，不是付款之后的执行，所以执行层的每一块都不用换，只需要在它们前面加一个“委托到凭证”的层，在它们后面加一条证据线。谁掌握发卡的规则引擎、付款端点的授权环节、收单的结账页，谁就已经有了签发凭证或接受凭证的位置。
这也是 PSP 在这件事上的机会所在：闭环的第 4 步和第 5 步都在它手里。
七、替人购物、企业采购、机器对机器对闭环的要求不同¶
《支付系统》基础教程部分讲 Agentic Payments 时把 agent 场景分成替人购物和机器对机器两类。站在 PSP 这一侧，还要加上企业采购这一类，因为它是 PSP 的企业客户最先遇到的：
| 替人购物 | 企业采购与付款 | 机器对机器 | |
|---|---|---|---|
| 典型任务 | 订一张机票 | 采购软件、付供应商发票 | 一个程序按次调用另一个程序的收费接口 |
| 单笔金额（按欧元或美元计） | 几十到几千 | 几百到几十万 | 可能不到一分钱 |
| 频率 | 像人购物 | 像企业付款 | 每秒可能几十次 |
| 委托来自谁 | 个人 | 企业财务或采购政策 | 程序的运营方 |
| 最合适的凭证 | 一次性虚拟卡、限商户令牌 | 限权付款指令、限供应商虚拟卡 | 链上限权转账 |
| 最合适的轨道 | 卡 | 银行、卡 | 链上稳定币 |
| 争议需求 | 有，跟人购物一样 | 有，但更多靠发票和合同 | 几乎没有，错了就不再调用 |
| 证据要接什么 | 订单和履约 | 发票、合同、预算科目 | 调用记录 |
三列的差异全部来自两个变量：单笔金额决定轨道（金额小到卡的固定成本都覆盖不了，只能走链上），争议需求决定要不要卡组织那套争议机制。这两条《支付系统》基础教程部分的 Agentic Payments 已经给过，这里加上第三条：委托来自谁决定第 1 步的边界长什么样。个人的边界是“不超过 800 美元”，企业的边界是采购政策、预算科目、供应商白名单。企业这一列的委托最复杂，也最接近 PSP 现有的企业客户。
八、这一章引出的问题¶
闭环的六步分别需要有人来做：谁替人设委托、谁签发凭证、谁让商户的结账页对 agent 开放、谁把证据串起来。2025 年到 2026 年，卡组织、Stripe、OpenAI、Google、Coinbase 和一批创业公司各自占了其中几步，并且发布了互相竞争又互相兼容的协议。
下一章把它们放回模型，看每家站在哪一格。
九、自检题¶
- 一家公司的产品是“AI 财务助手”：能读发票、比对合同、生成付款建议，财务确认后由它调用银行 API 付款。它是不是本章说的闭环？缺哪几步？
- 星图给 agent 的委托是“软件类，不超过 2,000 欧元，30 天”。agent 找到的商户是一家同时卖软件和硬件的综合电商。用一次性虚拟卡做凭证时，第 4 步能限制它只买软件吗？限不了的话，闭环的哪一步要补？
- 为什么说 PSP 在 Agentic Pay 上的机会在第 4 步和第 5 步？用本章的成因规则回答。
十、参考答案¶
先自己答完再往下看。
接近但还不是。它有第 2 步（agent 形成候选）和第 5 步（调用银行 API 执行），第 3 步由财务人工完成，也算。缺的是第 4 步：它调用的是通用的银行 API，不是限收款人、限金额的凭证，一旦它被劫持，能付的范围不受这一笔的限制。也可能缺第 6 步：付款结果是否自动跟发票、合同、任务关联，要看它有没有做。补上第 4 步，把“调用银行 API”换成“生成一笔只能付给这家供应商、这个金额的付款授权”，它就是闭环。
限不了。一次性虚拟卡能限商户、限额、限期，也能按商户类别码限制，但商户类别码是按商户登记的，一家综合电商的类别码只有一个，卡看不见它卖的是软件还是硬件。要补的是第 3 步的策略判断：在生成凭证之前，用候选支出里的商品信息判断是不是软件；以及第 6 步的证据：付款后用发票核对买的是什么。凭证的边界只能到商户和金额这一级，商品这一级要靠前后两步。
成因规则是：agent 改变的是付款之前的决策，不改变付款的执行，所以执行层照用，新增的是“委托到凭证”这一层。第 4 步签发凭证需要发卡的规则引擎或付款端点的授权环节，第 5 步执行需要余额核心、端点和收单，这些正是 PSP 已经有的。第 1–3 步可以由 agent 平台、企业软件或 PSP 做，第 6 步可以由财务系统做，唯独第 4、5 步离不开一个能签发凭证并执行付款的持牌机构。PSP 不需要造新东西，只需要把已有的能力向前接一层。
上一章：第 10 章 稳定币应用：谁在用它做什么 下一章：第 12 章 Agentic Pay 生态：玩家各站哪一格