概述¶
问题¶
AI 代理正在成为自主的经济参与者。它们购买算力、访问 API、获取数据并支付服务费用——所有这些都不需要人工干预支付流程。但现有的支付基础设施是为人类设计的，而不是为代理设计的。
考虑一个具体场景：一个 AI 研究代理需要查询 50 个不同的数据提供商，每个都需要按查询付费。代理必须：
- 确定自己是否有权花钱
- 选择正确的商户和支付方式
- 执行支付
- 证明支付已获授权
第 1 步是未解决的问题。x402 解决了第 2-4 步。LedgerFlow 解决了第 1 步。
大规模的困惑代理问题¶
没有适当的授权，任何被劫持或产生幻觉的代理都可能耗尽其所有者的钱包。提示注入攻击可以诱骗代理在非预期商户上花钱。被委托有限资金的代理可能越权。
传统解决方案在这里失败：
- API 密钥授予无限权限，无法表达细粒度约束
- OAuth 令牌为人类交互流程设计，不适合自主代理
- 钱包签名需要每次交易的人工审批，破坏了自动化
解决方案¶
LedgerFlow 引入了授权令（Warrant）——紧凑、签名、自包含的授权令牌，约束了 AI 代理可以支付的内容。
授权令，而非凭证¶
授权令不是密钥或密码。它是来自发行者（人类或更高信任度服务）的签名声明，意思是：
"这个代理，由这个签名密钥标识，被授权进行符合这些约束的支付，在这个时间窗口内，针对这些商户，不超过这些金额。"
代理在 x402 支付负载旁边出示授权令。商户密码学验证授权令。无需查找、无需在线检查、热路径无需分布式状态。
核心属性¶
| 属性 | 描述 |
|---|---|
| 自包含 | 验证所需的一切都在授权令自身中 |
| 短期有效 | 默认过期时间以分钟计，而非小时 |
| 密码学绑定 | 由发行者签名，可离线验证 |
| 单调递减 | 委托只能缩小，不能扩大权限 |
| 轨道无关 | 商户永远不知道结算是在链上还是通过交易所 |
定位¶
LedgerFlow 存在于 x402 旁边，而非其内部。
职责边界清晰：
- x402 定义商户-代理支付合约
- LedgerFlow 定义人类-代理授权合约
- Facilitator 跨轨道执行结算
商户只说 x402。LedgerFlow 数据作为 x402 扩展字段传输。Facilitator 隐藏所有轨道复杂性。
LedgerFlow 的独特之处¶
对比基于令牌的 IAM¶
| 维度 | 令牌 IAM | LedgerFlow |
|---|---|---|
| 权限范围 | 广泛范围，难以约束 | 默认类型化约束 |
| 委托 | 撤销密集，有状态 | 单调，无状态验证 |
| 代理意识 | 非为代理设计 | AI 原生约束类型 |
| 结算 | 无支付集成 | x402 原生 |
对比临时预算控制¶
| 维度 | 预算控制 | LedgerFlow |
|---|---|---|
| 执行方式 | 应用逻辑 | 密码学保证 |
| 审计轨迹 | 仅内部日志 | 签名证明链 |
| 可移植性 | 供应商特定 | 协议级标准 |
| 延迟 | 数据库查询 | 仅 CPU 验证 |
设计原则¶
- 保持 x402 纯净 — LedgerFlow 永不改变 x402 语义
- 仅 CPU 验证 — 商户端验证无需网络调用
- 保持自包含 — 授权令携带验证所需的一切
- 类型化约束 — v1 不使用通用表达式语言
- 小步快跑 — 一个授权令格式、一个证明格式、一个扩展命名空间
- 延迟复杂性 — 撤销、一致性令牌和关系图是未来扩展
架构¶
[ 人类 / 发行者 ]
|
| 签发 LedgerFlow 授权令
v
[ AI 代理 ]
|
| 1. 接收 x402 PaymentRequired
| 2. 选择 x402 报价
| 3. 附加 LedgerFlow 授权扩展
v
[ 商户服务器 ]
|
| x402 中间件
| + LedgerFlow 验证器
v
[ 扩展的 x402 Facilitator ]
|
| 选择结算轨道
| - EVM
| - Solana
| - 交易所 / 托管
| - 传统网关
v
[ 结算完成 ]