方向评审：责任层

Isometry 应该做 Agentic Payment 的责任层吗

现有支付系统已经能处理付款本身。新的问题是：当 Agent 代人花钱时，谁确认它按委托做事，出错后谁处理。

本文的判断：支付系统回答“这笔钱能不能付”；责任层回答“这笔钱是否符合这次委托”，并把补救流程提前写清楚。

不是钱包不是新支付轨道不保证 Agent 永远正确重点是边界、拦截、证据和补救

一、定义

责任层到底做什么

它放在用户意图和最终付款之间。它不替 Agent 做推荐，而是在付款发生前，把可承保的委托条件变成明确检查；付款后留下证据，并把退款、赔付或追偿送到正确的责任方。

明确委托

把“帮我买合适的”拆成金额、商户、商品、时间、审批、退款条件等可验证条款。

付款前检查

商户报价或最终订单不符合条款时，阻止支付、要求确认或转人工，而不是事后解释。

留下证据

保存用户授权、Agent 身份、报价、购物车、审批、Token 范围和最终扣款，用于裁决。

安排补救

按预先写明的规则退款、先行垫付、进入卡组织争议或向商户追偿；具体承保范围仍待拍板。

用户 / 企业

提出任务与边界

最多花多少
可以买什么
何时需要审批
必须满足哪些条件

→

Isometry 责任层

把委托变成可执行责任

条件编译与确认（谓词化、电路化）
支付前规则校验
证据包与责任路由
赔付、退款、追偿流程

→

支付轨道

移动资金

银行卡
银行转账
稳定币
其他支付方式

→

商户

接受订单并履约

价格与库存
税费与配送
退款与售后
订单状态

稳定币可以用于内部准备金、垫赔、托管和结算，但用户不需要因此变成加密货币用户。用户侧可以多轨执行，责任标准保持一致。

二、问题

为什么付款成功不等于交易正确

传统支付主要验证资金、凭证、身份和商户风险。Agent 带来的新问题是：凭证完全合法、金额也不异常，但订单依然违反了用户交给 Agent 的任务。

例子：凌晨两点，航班取消

付款合法不等于符合委托

用户给 Agent 的任务

“自动重订：总价不超过 $400，今晚 22:00 前到东京，最多一次中转，必须可退款。”

Agent 找到一张 $365 的机票。

它有两次中转，因此违反用户明确条件。

但银行卡是真卡、金额正常、航司也是真商户。

不同系统会看到什么

卡

凭证和交易看起来合法，因此可能授权。

链

签名有效、余额足够，因此可以结算。

店

订单和付款都到了，因此可以出票。

责

两次中转不符合委托，因此付款前应拦截；如果承保交易被误放行，进入预定补救。

缺口不是“钱怎么付”，而是“这笔合法付款是否符合这次委托，以及不符合时谁负责”。

三、现有方案

现有方案解决了很多事，但不等于责任层

责任层不能建立在“别人没有权限、Token 或 Mandate”这个假设上——这些能力已经在出现。真正需要证明的是：是否仍缺一个跨支付轨道、带支付前否决和补救责任的产品。

Wallet / x402 / Tempo机器付款与稳定币结算

已经解决

让 Agent 或程序在 HTTP 请求中完成付款；适合 API、内容和按次计费。Tempo 的公开文档重点是 Challenge → Pay → Receipt 的机器支付流。

还没直接解决

买了什么是否符合人的商业任务，以及后续的退款、赔付和追偿。例子：研究 Agent 付 $0.02 调 API 很合适；旅行 Agent 买错航班时，签名正确也不能解决责任。

信用卡欺诈风控 / 3DS身份、凭证与欺诈判断

已经解决

验证消费者、识别盗卡、账户接管、异常金额与商户风险。3DS 的核心目标是防止无卡交易欺诈。

还没直接解决

卡是否被合法持有人允许 Agent 按某项具体任务使用。例子：$365 航司交易是真实的，但“最多一次中转”不是卡组织传统授权字段。

Scoped Token / Visa / Mastercard / StripeAgent 身份、限额、商户与指令控制

已经解决或正在逼近

受限 Token、Agent 识别、金额与商户控制、用户指令匹配、风险信号和争议证据。它们已经覆盖了责任层的很多控制零件。

仍需验证的缺口

是否存在一个通用、跨轨道的产品，明确承诺：某类委托条款被系统误放行时，先给用户补救，再追到最终责任方。例子：有证据能证明错单，不等于今天就有人把钱先退给用户。

AP2 / Mandate 协议表达授权与生成审计轨迹

已经解决

把 Checkout Mandate、Payment Mandate 等凭证串起来，表达用户约束并形成可验证的审计链。

还没直接解决

协议本身不等于运营者、准备金或理赔团队。例子：审计链证明 Agent 越过了 $400 上限，但仍需要某个主体决定、垫付并追偿。

Canton / Daml权利义务、授权与账本完整性

已经解决

可以精确表达合约参与方、授权、义务、状态与一致性，是责任对象和证据的潜在技术底座。

还没直接解决

技术底座不会自动成为承保人。例子：账本可以证明“谁同意了什么”，但证明责任和向用户退款是两件不同的事。

竞争风险：Stripe、Visa 和 Mastercard 正在向指令匹配、Agent 身份、Token、风险信号与争议能力扩张。因此 Isometry 不能只做 Permit 或 Policy Engine；如果窗口存在，它应该来自补救责任、跨轨道编排和具体场景中的承保能力。

四、适用对象

哪些客户可能需要责任层

真正需要这一层的，是那些 Agent 一旦花错钱、自己就要收拾的人：平台、企业、支出方和商户。他们的共同点是——额度、Token 和欺诈风控都拦不住“合法但不符合委托”的交易，而真出了事，没人愿意从零搭一套兜底和理赔。

AI Agent 平台 / 应用方对外发 Agent，出事第一个被找

现在的问题

例子

购物或助理类 Agent 替用户下了单——买错型号、订了不可退的酒店、或重复付款。用户只会找平台；平台得自己翻日志、联系商户、判断要不要退钱，还要扛口碑。Payment API 只解决“付得出去”，不解决“付错了谁收拾”。

责任层能补什么

可能的价值

把付款前规则、证据包、Claim 路由和先行赔付交给独立责任层。平台不必从零搭金融与理赔运营，也能对用户给出明确的兜底承诺。

高客单垂直 Agent差旅、票务、B2B 采买，单笔金额大

现在的问题

例子

差旅 Agent 在航班取消时自动重订机酒，单笔上千、时间紧、且多是不可退票价。一旦订得不符合委托（超预算、改签条款不符），钱已经出去，损失真实又难追回。

责任层能补什么

可能的价值

扣款前按预算、可退改、到达时间这些硬条件拦截；真出错且在承保范围内，先垫付给用户、再向责任方追偿。金额越大、越不可逆，这层越值钱。

企业采购 / 财务要的是政策执行，不只是额度

现在的问题

例子

采购 Agent 用公司卡买了 $900 SaaS，金额没超卡限额，但供应商不在合格名单、也没有 PO。卡风控只看欺诈和额度，不会替 CFO 执行内部政策。

责任层能补什么

可能的价值

把供应商、PO、成本中心、审批阈值、发票要求变成付款前硬闸门；交易后留下能直接用于对账与合规的审计证据。

费控 / 支出平台Ramp、Brex 式，想给客户上 Agent 支出

现在的问题

例子

想让客户的 Agent 自动支出，但 Agent 一旦花错，赔付、争议和合规就全压到平台头上；自建一套承保与理赔，既慢又不是主业。

责任层能补什么

可能的价值

以嵌入方式接入责任层，把闸门、证据和赔付变成底层能力。对外仍是自己的品牌，却不必亲自扛兜底所需的资本与牌照。

商户 / 交易市场想安全接住 Agent 流量

现在的问题

例子

Agent 下单 20 件而不是 2 件，或买了明显超出用户意图的东西。商户只看到有效 Token 和成功付款，发货后才被投诉，还分不清错在 Agent 越权、平台误放行，还是自己履约。

责任层能补什么

可能的价值

每张 Agent 订单都带委托范围、报价快照和订单 Hash；出问题能快速定责，减少错单、拒付和无谓的客诉拉锯。

写清楚把自然语言意图变成可裁决条款。

先拦截在钱离开前拥有真正的否决权。

留证据保存一份双方都能用的交易证据。

可补救让“谁先退、谁最终承担”成为产品流程。

五、未定问题

这些还没有定，不能写成结论

目前比较确定的是“责任缺口”这个方向；授权规则如何形成、承保到哪一步、谁出资本、从哪类交易开始，都需要继续验证。

1. 授权规则谁来定？

A. 用户 / 企业直接填写结构化条件。

B. Isometry 把自然语言编译成规则，再由用户确认。

C. 商户或行业提供标准模板，再由用户修改。

当前倾向（非结论）：B + C；用户拥有目标，Isometry 负责把语义写清。

2. Isometry 承保什么？

A. 只保本应拦截却误放行的情况。

B. 再保商户提供的关键事实错误。

C. 再保航班延误、配送迟到等现实结果。

当前倾向（非结论）：先做 A；B 需要追偿关系，C 已接近保险。

3. 谁提供赔付资本与牌照？

A. Isometry 自有准备金和合同保证。

B. 与保险公司、Issuer 或 PSP 合作。

C. 商户押金、Escrow 或交易级风险准备金。

必须单独完成法律、监管和资产负债设计；“赔”不能只是产品文案。

4. 支付轨道怎么选？

A. 卡优先，复用消费者和商户已有习惯。

B. 稳定币优先，获得可编程结算和垫付。

C. 对用户多轨，对内部使用稳定币调度资金。

当前方向：多轨执行，统一责任标准；不强迫用户使用稳定币。

5. 赔付如何裁决？

A. 完全确定性规则自动裁决。

B. 硬规则自动裁决，灰区转人工。

C. 依赖模型判断用户“真实预期”。

当前倾向（非结论）：B；模型可以整理证据，但不应成为最终赔付法官。

6. 第一种可承保交易是什么？

A. 低金额、可退款、有锁价 Quote 的消费。

B. 有明确企业政策的采购与 SaaS 支出。

C. 时间紧迫、条件明确的旅行重订。

选择标准应是“条款客观、证据稳定、可阻断、可追偿”，而不是先按客群做 GTM。

六、风险与防御

如果这本质上是保险，会不会被人骗赔

我们其实在卖一种“错单兜底”，这让它在经济上很像保险，也就继承了保险最古老的对手——骗赔与道德风险。值得说清的是：责任层的骗赔面比传统赔付保险更窄，因为它在付款前就拦截，并且只按事先确认的客观条款裁决，可赔的事实在损失发生前就已钉死。但骗赔面仍然存在、只是更窄：上一节承保 A→B→C 每扩一步，都会把它重新放大。

例子：明明想要，却想反悔骗赔

可赔的事实必须提前钉死

骗赔者的算盘

“反正有兜底——先让 Agent 买下来，事后再说一句‘这不符合我的意图’，把钱要回来。”

商品在预算内、也在授权商户范围内，用户其实想要。

收货后声称“Agent 买的不符合我的真实意图”，发起索赔。

期待责任层像无条件退货一样，把钱原路退回。

责任层为什么不接这单

责

裁决只看付款前已确认的客观条款。

验

金额、商户、可退条件都客观满足 → 没有违约 → 不进入赔付。

退

真想退货，那是商户退货政策的范畴，不是责任层承保的“错单”。

传统保险常被“事后叙述损失”钻空子；责任层把可赔的事实在付款前钉成客观条款，索赔不能靠事后改口。

道德风险：委托放水故意把条件写松或写矛盾

责任层的防御

只承保“按客观条款本应拦截、却被系统误放行”的情形：条款写得松，就没有被违反的边界，也就没有可赔的错单。条款还由系统编译、需用户确认，放水会被显式标出。

攻击与残余风险

攻击者把“可以买什么”写得很宽，或留下自相矛盾的条款，让 Agent“在授权内”买下本不想要的东西，再以“它本不该买”为由索赔。残余风险在语义模糊地带，要靠模板和确认环节继续收紧。

买家反悔：伪造“不符合意图”想要的东西，事后改口说买错

责任层的防御

裁决依据是付款前已确认的客观条款；客观满足即不赔。这正是与传统赔付最不同的一点——可赔事实被提前钉死。

攻击与残余风险

交易客观符合条款，用户却在事后声称“不符合我的真实意图”，试图把一笔正常消费包装成错单来索赔。残余风险：条款没覆盖到的“软意图”本就不该进入承保范围。

与商户 / 开发者合谋串通制造“错误”再私分赔款

责任层的防御

承保 A 只认系统自身的误放行，合谋很难落到 A 上；再以向商户追偿、押金 / Escrow 和声誉惩罚抬高合谋成本，让它对双方都不划算。

攻击与残余风险

用户与商户（或 Agent 开发者）串通，故意制造一个“商户关键事实错误”或假报价来触发赔付，事后私分。一旦扩展到承保 B（商户事实），合谋面就会立刻变大。

伪造纠纷：假未达、假错件经典拒付欺诈的 Agent 版本

责任层的防御

报价快照、订单 Hash 与履约信号组成的证据包让伪造可被拆穿，并需商户侧确认后才进入赔付。

攻击与残余风险

货已正常收到，却谎称未送达或收到错件并发起索赔——这是信用卡拒付欺诈在 Agent 场景里的翻版。这一类最接近传统保险，应放在最后做，并把欺诈率直接计入定价。

逆向选择 + 工业化薅羊毛最差的 Agent 与脚本化索赔涌入

责任层的防御

按委托类型做风险定价、设每账户敞口与频次上限、对索赔模式做异常检测，并从“违约机器可验证”的交易类别起步。

攻击与残余风险

最不可靠的 Agent、最松的用户最有动机来用这层兜底；脚本还能批量制造看似合规的索赔来薅准备金。关键是用风险定价和敞口限额，让成本精准落到制造风险的账户上。

核心取舍：承保范围越窄、越贴近客观条款和付款前拦截，可骗赔的面就越小——被闸门挡下的交易根本没有“赔”可骗。一旦把承保从 A（系统误放行）扩展到 B（商户事实）乃至 C（现实结果），就会重新继承传统保险的道德风险与骗赔，必须用资本、定价、追偿和限额实打实地兜住。

七、需要判断什么

这次要判断的不是某个 API，而是三个产品判断是否成立

如果不同意其中任何一条，方向都应该调整；如果基本同意，下一步才是把开放问题变成可验证的产品实验。

判断一：缺口是责任，不是支付管道

Agentic Payment 的稀缺价值来自用户和机构敢于委托，而不只是 Agent 能把钱转出去。

判断二：控制必须连接补救

单独的 Permit、Token 和规则会被平台与网络吸收；Isometry 必须把闸门、证据和补救连成产品。

判断三：跨轨道，而不是稳定币界面

稳定币可以成为内部资金工具，但责任标准应覆盖卡、银行与链上结算，不要求客户先成为加密货币用户。

最简单的产品定义：Isometry 让人和公司能够把“可以自动做，但做错会很麻烦”的付款任务交给 Agent。

资料和边界

公开资料依据与边界

以下不是竞品矩阵，只用于确认各类方案目前公开覆盖的能力，以及我们不能夸大的地方。资料检查日期：2026-06-19。

展开：支付网络、协议与基础设施的公开能力

EMVCo 3-D Secure：面向无卡交易消费者认证与欺诈防护。
Visa Intelligent Commerce：Agent Token、用户指令匹配、网络级控制与争议信号；产品仍在部署中。
Mastercard Agent Pay Acceptance Framework：Agent 注册、身份验证、Token 与商户接受框架。
Stripe Agentic Commerce Suite 与 Shared Payment Tokens：商户、Checkout、Fraud、受限支付凭证与多支付方式。
AP2：Checkout / Payment Mandate 与人不在场交易的可验证审计链。
Tempo Agentic Payments：基于 MPP 的 HTTP 内联付款与稳定币结算。
Canton / Daml Ledger Integrity：合约一致性、授权、签署方和义务表达。

研究边界：我们只能根据公开产品和文档判断。尤其 Visa、Mastercard、Stripe 正在快速演进，因此“没有责任层”不能作为永久结论；Isometry 必须用真实承保、Claims 运营或跨轨道责任编排来证明差异。