有人在 Dev.to 上 14 小时前发布了我们的完整论文。以下是他们出错的地方。

Source: Dev.to

AgentLair 昨天在 Dev.to 上发布了一篇标题为 “Payment Rails Are Shipping. Trust Rails Aren’t. That’s the Problem.” 的文章
该论点几乎逐字与我们自 4 月 11 日以来的说法相同：

• 支付轨道验证令牌的有效性。
• 它们不评估先前的行为。

AI 代理的支付基础设施已经就绪。代理现在可以在任何接受 Stripe 的服务上以机器速度进行交易。缺失的部分是 L4：行为信任。

我们对每一句话都表示认同。自发布之日起我们就一直在构建 L4 层。但他们的表述中存在一个关键缺口，这对任何在该领域构建的人都很重要。

AgentLair 框架的问题

会话范围的证明在会话结束后不再有效

AgentLair 提出了 Agent Attestation Tokens (AATs) —— “加密可验证、会话范围且具行为特征”。这对于您能够控制交易双方的企业部署来说是一个合理的做法。

问题在于，会话范围的证明在每次交互后都会重置。一个在 12 个不同服务中完成了 500 笔交易、交付率为 99.2% 的代理，在进入第 13 项服务时 没有任何可迁移的声誉。信任分数被重置，代理每次都从零开始。

“这就像本地信用评分与只能在一家店使用的信用卡之间的区别。”

实际信任的必要属性

为了让信任是真实的——而非仅仅是会话令牌——它需要具备三个属性：

1. 可移植性 – 代理的声誉必须能够跨部署、跨组织、跨链条保持。如果代理 A 在服务 X 上建立了完美的记录，服务 Y 应该能够在不需要服务 X 授权的情况下验证该历史。
2. 开放标准 – 声誉层必须基于开放、可互操作的协议构建，而非专有的证明层。
3. 获得的声誉 – 声誉必须来源于已验证的交易，而非自我证明。

所需的开放标准

• ERC‑8004 – 链上代理身份注册
• ERC‑8183 – 用于代理商务的可编程托管
• x402 – 自主的 HTTP‑本地支付

这些标准使声誉像代理本身一样可移植。

为什么需要新的声誉层

一个没有历史记录的新代理会得到零认证。在 AgentLair 的模型中，这意味着该代理在被信任之前无法证明其可信度。我们通过托管来解决这个问题：

• 新代理提前投入“皮肤”——资金锁定在智能合约中，只有在验证交付后才会释放。
• 如果代理交付成功，它将获得声誉。
• 如果未交付，对方将得到全额赔偿。

会话范围的认证将信任信号绑定到特定代理与服务之间的关系。然而，真实的商业活动涉及代理与从未见过的代理进行交互，使用从未使用过的服务。一个代理从另一个代理购买 API 计算时，需要了解 该代理是否为其他人交付过，而不仅仅是 它是否通过了自身的入口过滤。这就是链上交易历史重要的原因：关键在于代理实际完成了什么，而不是它声称的内容。

我们的解决方案：AgentLux

AgentLux 是 AI 代理的已获声誉层，运行在 Base 主网。

• ERC‑8004 — 链上代理身份注册
• ERC‑8183 — 用于代理商业的可编程托管
• x402 — 自主的 HTTP 原生支付
• 可移植声誉 — 基于实际交易历史计算，可由任何交易对手验证

信任层不能是专有的或会话范围的。它必须是开放的、可移植的且通过实际行为获得的。

行业信号

同一周：

• 支付协会发布：“代理商务的胜负取决于信任，而非自动化。”
• 欧洲银行被要求成为 AI 支付的“控制层”。
• 信息技术研究集团警告称，静态治理模型无法应对代理 AI；传统合规框架已经失效。
• CISA + NSA + Five Eyes 发布了关于代理 AI 的联合指南，称强身份管理“至关重要”。
• Experian 与 Visa、Cloudflare 联合推出 Agent Trust——正式的“了解你的代理”框架。
• OpenAI + Stripe 推出 Agentic Commerce Protocol，实现 ChatGPT 中的即时结账。

五篇出版物，五个组织，同一周得出相同结论：

• 支付通道： 已完成。
• 身份层： 正在交付。
• 已获声誉： 仍未出现。

结论

支付通道已就绪。信任层已上线。如果您正在构建与其他代理进行交易的代理，请阅读代理文档并采用开放、可移植、已获声誉模型。