工作原理
从签名 Intent 到密封交付,一笔 A2B 交易用户视角的完整流程,每一步都有密码学审计。
工作原理
本页从用户视角走一遍完整的 A2B 交易。协议级规范见 Protocol · A2B 子协议。
一笔交易长什么样
一笔 A2B 订单走三个阶段,每个阶段都产出链上证据。
你的角色主要在两端 —— 批准最初的额度,以及(可选)读取交付物。中间的部分都由密码学强制,不需要你盯着。
阶段 1 · 你声明 Agent 可以做什么
你(或者你用的应用)创建一个 Intent,大意是:
"我要我的 Agent 在这个截止时间之前,针对这类商户,花不超过 X。如果金额超过 Y,先暂停并询问我。"
最关键的是三个字段:
maxAmount—— 上限。Agent 无论如何都不能花超过这个数。deadlineUnix—— 硬过期。到时没完成,资金自动回来。requiresConfirmAbove—— 可选阈值。超过此数的金额,要你在带内确认之后才能付。
Intent 用 Agent 的 DID 密钥签名、哈希后写入链上的 A2BOrderGateway 合约。从这一刻起,合约和 Action Gateway 都会拒绝额度外的任何动作。
阶段 2 · Agent 在策略门下执行
Agent 现在开始干活:查商户目录、选商品、提交发票、付款给商户。Agent 的每次工具调用都要过一道 Action Gateway。
每次调用,Gateway 会:
- 检查工具在 Intent 的白名单里。
- 检查参数在 scope 和预算内。
- 检查前置的必需工具已经成功。
- 检查截止时间还没到。
- 如果金额超过
requiresConfirmAbove你还没批准,暂停并推送给你。
批准或拒绝,每一次决策都写成一条 ActionTrace 记录。这些记录哈希链接,构成防篡改的审计记录。如果有人事后想改,链就断了,审计根也对不上链上的值。
与此同时在链上,订单顺着一条固定清单棘轮推进:
每次转换都是一次独立交易。合约强制顺序 —— 不能跳格、不能乱序。这就是 A2B 抗跑路的原因:钱到不了商户,除非存在一张已提交发票、金额在存款内,而且支付交易是从那张发票的字段构造出来的,没人能偷偷换收款方。
阶段 3 · 结算、密封交付、锚定证明
商户确认交付时,三件事同时发生:
-
审计根写上链。 阶段 2 所有 ActionTrace 的 Merkle 根,作为
confirmDelivery交易的一部分锚定。这根从此进入永久记录。 -
交付物被密封。 如果商户返回的是礼品卡码、收据、预订确认号 —— 任何敏感内容 —— 都会用信封加密锁到你的公钥。只有你的私钥能拆开。加密后的 blob 在链下,链上只锚定它的哈希。
-
CompletionProof 被锚定。 这是一条链上记录,把 intent hash、审计根、交付哈希、裁决(
DELIVERED/FAILED/EXPIRED)绑在一起。第三方用它就能重建整笔交易,算是主收据。
你的仪表盘显示交付。审计徽章转绿。结束。
出问题时会发生什么
A2B 的设计让每种失败模式都有明确的恢复路径。
| 情形 | 会发生什么 |
|---|---|
| 阶段 1 之后 Agent 沉默 | 截止时间到 → 任何人调 expireOrder → USDC 回到你的智能账户 |
| 商户报告交付失败 | 订单转为 FAILED → 资金退款路径打开 |
| Platform 中途掉线 | 只要你还能联网,expireOrder 照样可以直接打到合约上 |
你不小心超过 requiresConfirmAbove | Gateway 暂停等你确认;不确认的话,订单过期自动退款 |
| 审计根和链上对不上 | 审计徽章变琥珀;SDK audit 命令会报告不匹配 |
| 交付延迟但最终到货 | 付款后工具不受截止时间限制 —— 门关了商户还能继续交付 |
"只有你能做到"的保证
A2B 有一条核心属性:只有两把密钥重要:
- Agent 的 DID 密钥签 Intent。万一泄露,只有未来的订单有风险 —— 已经签上链的旧订单仍然被那把签名锁住。
- 你的私钥拆密封交付。ATEL 看不到你的礼品卡码;被入侵的 Platform 也没办法悄悄偷走。
Platform、Gateway、商户都在合约约束下干活。把它们任何一个关停,协议依然保证要么退款、要么交付,不会是损失。
另见
- A2B · 零信任审计 —— 自己核验任一笔已完成订单
- A2B · FAQ —— 最常被问到的疑虑
- Protocol · A2B 子协议 —— 协议规范