AVIP · A2B 子协议

是什么

A2B 是 AVIP 的 Agent 对 Business 支付执行子协议。它规定了 AI Agent 如何代表用户或组织向 Web2 商户付款:资金由链上智能合约托管,整条流程的每一步都要对着签名 Intent 做策略校验。

A2B 里的对手方是一个传统 Web2 商户 —— 它有公开的 API 或 webhook,但没有 DID、没有链上身份、没有密码学签名。协议要做的,是约束 Agent 和 Platform,让 Web2 一方不被盲目信任,既拿不走用户的钱,也不会让用户失去追索权。

A2B vs A2A。 A2A 编排两个都签名的 Agent 之间的双向交换;A2B 构造的是单向清单 —— 只有 Agent 签名,商户的交付由 Platform 加目击数据来佐证。详细对比见 AVIP 总览。

提供什么

三幕流程

• 第一幕 在链上登记 Agent 可以做什么(订单创建、资金预扣)。
• 第二幕 把真正的工作过一遍策略门,每次工具调用产出一条 ActionTrace 记录。
• 第三幕 把 Trace 汇成 Merkle 根,锚定 CompletionProof,清单打满才放款。

每一幕都产出链上证据。任一幕失败或超时,资金默认走退款路径 —— 用户永远不会失去托管权。

端到端工作流

上面的三幕流程是宏观形态。下面的端到端工作流展示 Action Gateway 如何对每次工具调用把关、合约清单如何逐槽推进,以及「交付或退款」的分支落在哪里:

只有当链下 Gateway 与链上合约同时同意时,资金才会向前推进;其余任何路径 —— 调用被拒、交付失败、或超过截止时间 —— 都会回到重试或由合约强制执行的退款。

步骤 1:Intent 与链上订单创建

A2B Intent 在通用 AVIP Intent 基础上扩展了支付执行相关的字段:

签名后,Platform 调 A2BOrderGateway.createOrder(intentHash, userAddr, maxAmount, deadline, data)。这会在链上登记订单,状态 = CREATED。后续任何一步偏离签名 Intent 都会被 Gateway 拒绝,或被合约拦下。

链上订单就是资金容器。没有合约清单推进,商户拿不到任何钱;而清单推进的前提是 Gateway 策略和合约自身不变式同时点头。

步骤 2:策略门控执行(Action Gateway)

Agent 所有工具调用都要走 Action Gateway —— 一个绑定到签名 Intent 的链下策略引擎。

每次调用,Gateway 都会校验:

• 工具在 Intent 的 allowedTools 里。
• 调用参数与 Intent 的 scope 和 maxAmount 一致。
• 依赖的前置工具已经成功(比如 wallet.deposit 在 bitrefill.createInvoice 之前)。
• 截止时间还没到。
• 金额超过 requiresConfirmAbove 时,存在用户确认记录。

Gateway 给每次调用写一条 ActionTrace 记录,字段如下:

这些记录组成哈希链,以 Merkle 根收尾。篡改任一条都会让后面每个哈希失效、打破链上的 auditRoot。

Gateway 拒绝的调用也会持久化。deny 记录对审计至关重要 —— 它们证明系统是在拒绝越界尝试,而不是悄悄略过。

步骤 3:合约清单与结算

链上订单按一条固定的格子序列往前走。每个格子对应一次状态变更,而状态变更只在 Gateway 批准了对应工具调用时才可能发生。

每次转换都是对 A2BOrderGateway 的一次独立链上交易。合约会拒绝不按清单顺序的转换(比如还没 INVOICE_COMMITTED 就想到 PAID)。

资金触到商户之前,合约必须看到一条金额 ≤ 存款的已提交发票,并且支付交易本身是从那条发票的字段构造出来的。 意思就是 Platform、Agent、商户三方都不能独立构造出一个不同的收款地址或金额。

其他终态:

步骤 4:完成证明与密封交付

商户确认交付时,有两件事在同一步里发生:

1. 构造并锚定 CompletionProof,里面包含:

   • intentHash —— 签名 Intent 的哈希
   • auditRoot —— 所有 ActionTrace 记录的 Merkle 根
   • deliveryHash —— 商户侧交付确认的哈希
   • verdict —— DELIVERED / FAILED / EXPIRED
   • anchorTx —— Proof 写入 AnchorRegistry 的交易

2. 商户交付物(如礼品卡码)用信封加密密封:

   • 一个新的对称密钥加密交付物
   • 对称密钥再用用户的长期公钥加密
   • 产生的 redemption_ciphertext 被保存;明文永远不存
   • 只有用户私钥能拆开信封

链上记录只存密文的哈希。密文本体在链下(Platform 数据库、IPFS 或用户设备)。这种设计让敏感的商户交付物保持私密,同时"确实交付了"这件事可核验。

超时自助退款:expireOrder

如果 deadlineUnix 过了订单还没关,任何人都能调 A2BOrderGateway.expireOrder(intentHash)。合约会:

• 校验 block.timestamp > deadline
• 把订单状态推到 EXPIRED
• 把存入的 USDC 转回用户智能账户

退款不需要 Platform、Agent 或商户参与。只要世界上还有一个以太坊兼容节点,用户就能找回自己的钱。这就是协议层面的"抗跑路"。

部分失败也是一样:Agent 存完款就消失了,截止时间就是安全阀。

每笔交易的链上数据

一笔完整执行的 A2B 订单会产出多条链上记录:

一笔典型已交付订单会在 A2B 部署的 EVM 主网上产生若干次链上状态转换,外加一次 CompletionProof 锚定。

每个锚定下的富化数据

链上每条记录只存 32 字节哈希,而哈希背后的数据通过 ATEL 验证 API 发布:

• GET /verify/v1/tx/{txHash} —— 按交易哈希查任意已锚定数据
• GET /verify/v1/anchor?key={anchorKey} —— 按锚定键查

API 从返回数据重算哈希,确认是否和链上锚定对得上。第三方只要有一个交易哈希就能端到端审计整笔订单。

零信任审计命令

SDK 暴露三条命令,把审计逻辑在本地复现:

atel bitrefill verify-intent <intentId>
# Verifies the Intent's Ed25519 signature and checks that the on-chain
# Order exists with matching intentHash, userAddr, maxAmount, deadline.

atel bitrefill audit <intentId>
# Fetches all ActionTrace records, recomputes the Merkle root locally,
# compares against the on-chain auditRoot.

atel bitrefill proof <intentId>
# Fetches the CompletionProof anchor transaction, decodes the JSON,
# compares against the Platform-side verdict.

三条命令都是只读,跑在公开端点和区块链上。它们故意不需要 Platform 认证 —— 用户只要有 intent id 就能跑。

与 A2A 的关系

A2B 和 A2A 共享同一套密码学底座:

• 都用 DID + Ed25519 签名做 Agent 身份。
• 都用 AnchorRegistry 模式做链上承诺。
• 都产出第三方可核验的 CompletionProof 结构。
• 都支持 expireOrder 风格的超时兜底。

A2B 和 A2A 的差异:

两个子协议产出的证据,下游消费者(合规 API、跨平台审计流水线、第三方验证者)可以统一处理。

给集成方

• 想接入新商户到 A2B?从 A2B · 商户接入 开始。
• 想深入了解链上合约?看 Pro File · 智能合约。
• 想审计一笔历史交易?看 A2B · 零信任审计。