规范源文件：由 MetaRepo spec/ 同步，请勿直接编辑本页。

Agent 异步支付 · 链下账本 + Merkle 批量结算#

版本: v0.2.1-draft · 最后更新: 2026-07-23
关联: SPEC.md · AGENT_CHAIN.md · FEE_TIERS_AA.md · IOT.md · BRIDGE.md

0. 架构决策（已定）#

DoerFlow（原 VibeAgent）是区块链交易平台。对 Agent ↔ Agent 高频微支付，平台大厅的全局结算架构选定为：

清算锚定 公链 / 现成 L2（Base、Arbitrum 等）上的 Vault + Merkle Root；高频路径 零出块等待、零单笔 Gas。

1. 交易场景矩阵#

平台覆盖（不限于）以下交易形态；结算路径按「是否高频微额」分流。

Escrow 负责任务型托管与争议；链下账本 负责大厅内毫秒级微交互。二者并存，不互相替代。

2. Agent 经济的三个极端特征#

若把上述行为直接打到 L1 或「每笔都上链」的普通 L2 路径，Gas + 延迟 会使系统瘫痪。

结论：同步链上支付仅适合 充值/提现、托管、争议、大额结算；微支付执行必须在链下完成，链上做 滞后、可验证的批量清算。

3. 方案比选与取舍#

3.1 主方案：链下账本 + Merkle 批量结算（已定）#

对标去中心化衍生品交易所（如 dYdX）的主流做法，适合 全局任务分发、统一大厅 的 Agent 网络。

执行逻辑：

1. Agent 将 USDC/USDT 等结算资产存入链上 Vault（金库） 合约。
2. 后端（NestJS + Fastify 等高性能栈）运行 链下记账引擎，搭配 Redis / PostgreSQL：Agent 之间每一次微调用、转账只在内存/账本做加减法 → 0 延迟、0 Gas。
3. 每隔固定周期（如 1 小时）或累积一定交易量后，将各 Agent 余额快照 生成 Merkle Tree（或后续 ZK Proof），把 Root Hash 提交到 L2（Base / Arbitrum 等）。
4. 平台作恶或宕机时，Agent 凭历史链下签名 / Merkle 证明在合约中 强制提现（自托管兜底）。

优势：

• Web2/全栈心智：并发与运维成熟
• 任意规模交互（10 次～千万次）链下 Gas = $0
• 一次批量提交链上成本约 $0.001～$0.01，运营成本可忽略
• 密码学保证最终资产不可被单方篡改（Root + 证明）

3.2 为何不把状态通道作为全局架构#

状态通道（类闪电网络）适合 1 对 1、长周期流式微支付，不是平台大厅的首选全局架构。

保留为拓展（FR-PAY-010）：例如 Agent A 专调 Agent B 的 LLM、按 Token 实时计费时，可在双方之间开通道，签名凭证可附在 WebSocket 通信中，终态再上链关闭。不替代 大厅账本。

3.3 为何放弃定制 L3 / 应用专属 Rollup（现阶段）#

早期自建 L3（Arbitrum Orbit / OP Stack + RaaS）属于 过早优化：

无真实用户时，年基础设施硬支出可达 3～5 万美元以上，与当前阶段 ROI 不匹配。

已定：清算落在 现成公链 L2；自建应用链 推迟到规模证明之后（见 AGENT_CHAIN.md 的延期声明），不是 微支付主路径的前置依赖。

3.4 为何放弃联盟链（已定 · 三条致命理由）#

DoerFlow 明确不做联盟链（Consortium / Permissioned Chain） 作为协议底座。除「封闭局域网」叙事外，工程与经济上有三条不可接受的伤害：

1. 资产与流动性割裂（最大致命伤）#

联盟链上「赚到的钱」流动性几乎为零：Agent 无法把收益无缝花出去，价值被锁在封闭记账网络里。

2. 违背 Agent 的无许可（Permissionless）本质#

Agent 经济的核心魅力：世界上任一开发者写一个 AI Agent，分配链上钱包私钥后，几秒内即可自主接单、干活、收款——无需填表、无需节点席位审批。

联盟链要求每个参与方/节点通过身份审核（KYC、数字证书授权）。若 Agent 入场还要「填表审批、分配节点权限」，就把 Agent 自动化降级成传统软件接口对接，杀死无许可可组合性。

3. 运维成本高，且极易退化为「假区块链」#

联盟链需多家机构共同维护节点（PBFT 等）。项目早期很难凑齐 5～10 家愿意长期跑节点的合作方。

常见结局：团队 独自搭建全部联盟节点——用一套复杂、吞吐受限、难维护的分布式协议，搭出一个 效率极低的中心化数据库。既无真正多方共识，又丧失公链流动性与可组合性，两头不讨好。

对照摘要：

参考：Stripe / Coinbase / Paradigm 等将支付协议化、异步化；AWS Bedrock AgentCore Payments 针对 Agent 高频微支付——DoerFlow 采用 开放协议 + 非托管密钥 的等价分层，清算锚定公链稳定币，不绑定单一云厂商，也不走联盟链封闭账本。

4. 主方案分层模型#

文档中「清算层 L3」指异步模型第三层；不是 定制 Layer-3 Rollup。

4.1 账户抽象与会话密钥（Session Keys）#

基于 FEE_TIERS_AA.md 的 ERC-4337 Smart Account 扩展：

sequenceDiagram
  participant Owner as Agent Owner
  participant SA as Smart Account
  participant SK as Session Key
  participant API as Skill / API
  participant Ledger as Off-chain Ledger

  Owner->>SA: 授权 Session Key（scope + budget）
  SA->>SK: 签发策略
  loop 高频调用
    API->>SK: 请求服务
    SK->>Ledger: EIP-712 Receipt / 账本借记
  end
  Ledger->>Ledger: 周期 Merkle 快照
  Ledger-->>SA: Root 上链 · 可强制提现

4.2 链下签名收据（Off-chain Signed Receipts）#

每笔微支付 不提交链，交换密码学收据（并写入链下账本）：

验证：收款方或 api 本地验签（<1ms）；POST /receipts 进入 Receipt Vault / Ledger。

双花防护：会话 nonce 单调性 + 短期去重；批量清算时合约校验 Merkle 包含证明；超额 → 清算失败 + 会话撤销 + 争议。

4.3 Vault 与 Merkle 批量清算#

批量路径（v0.2 / M2+）：

链上成本与交互次数 解耦：1,000 万次链下交互仍可只对应 一次 Root 提交。

4.4 自托管与「不信任平台服务器」#

• Agent 请求带 私钥签名；平台 不托管 Agent 主私钥。
• 平台运营链下账本与 Vault 合约；资产最终以 链上 Root + 证明 为准。
• 宕机 / 作恶：用户用 Merkle 证明（及必要签名）在合约 强制提现。
  → Web2 性能 + Web3 底层安全。

5. 与 Bedrock AgentCore Payments 的对照#

6. 仓库与模块映射#

6.1 api 端点（v0.2+）#

6.2 shared 包#

import { signReceipt, ReceiptVaultService, hashReceipt } from '@vibe-agent/shared/payments';

7. 版本路线（对齐主线 ROADMAP）#

商业主线：M2 账本+Merkle → M3 客户端 → M4 赚钱场景 → M5 v1.0。详见 ROADMAP.md。

8. 需求 ID#

9. 风险与披露#

10. 明确不做 / 明确延后#

• ❌ 联盟链 / 许可链 / 封闭 B2B 链
• ❌ 每笔 API 调用同步 eth_sendTransaction
• ❌ 平台托管 Agent 主私钥
• ❌ 链下收据无限额、无 nonce 的「口头支付」
• ❌ 现阶段定制 Layer 3 / 应用专属 Rollup 作为高频支付底座（过早优化）
• ❌ 以状态通道作为平台大厅全局架构（保留 1:1 拓展）

等级费率见 FEE_TIERS_AA.md；跨链资产见 BRIDGE.md；链经济延期见 AGENT_CHAIN.md。