无信任代理的失败之处，以及我为何构建无信任代理增强版

decipherclub 发布于 2026-06-05 阅读 143

本文分析了ERC-8004标准在多链环境下的局限性：每个链上的代理身份和声誉彼此孤立，缺乏跨链关联。

ERC-8004 赋予了 Agent 身份，但它忘记了 Agent 不止活跃在一条链上。

该标准发布三个月后，已有约 20 万个 Agent 在 23 条以上的链上注册。这个数字看起来像是被广泛采用了。仔细一看，这更像一个问题。

这些 Agent 中的每一个都注册在每条链的单例合约上。Base 上的一个 Agent 与 BSC 上的同一个 Agent 共享同一个操作者、同一个代码库以及相同的过往记录——但链上没有任何证据能表明这一点。身份无法跨链转移，声誉也无法跨链转移。

我自己的 Agent 就遇到了这个问题。它部署在三条链上，有三个不同的 Token ID、三个不同的声誉评分，链上没有任何东西表明它们是同一个实体。

这篇文章并非要拆解 ERC-8004。该标准解决了一些实际问题——身份、声誉、验证——并且在单链上解决得很好。但 Agent 早已不再局限于单链。

所以，让我们做两件事：首先，仔细看看 ERC-8004 在 Agent 跨链时究竟在哪些地方失效了；然后，看看我构建的 Trustless Agents Plus (TAP) 系统是如何在不要求任何人放弃该标准的前提下填补这个空白的。

我们直接进入正题。

分区问题

让我借用另一个领域的概念。

城市规划中有一个概念叫分区碎片化——当一个都市区被分割成数十个独立的辖区，每个辖区都有自己的建筑规范、许可证和发证机构时，在一个区获得执照的承包商要到三英里外的下一个区工作，就必须重新申请、重新认证、重新证明能力。证书不互通，声誉不互通，卡车上的牌照在跨过辖区边界后也毫无意义。

ERC-8004 在规范中内置了分区碎片化。

注册表被设计为每条链上的单例合约。在以太坊主网上注册的 agentId=42 的 Agent，与 Base 上 agentId=17 的同一个 Agent 没有任何链上关联。不同的链，不同的合约，不同的 tokenId。

唯一的跨链机制是链下的 Agent Registration File（Agent 注册文件）——一个 JSON 文件，Agent 的所有者在该文件的 registrations[] 数组中自行声明在其他链上的注册信息。自行声明、链下存储、无法被任何其他链上的智能合约验证。如果 IPFS 的固定失效或 HTTPS 端点宕机，所有的跨链身份声明也会随之消失。

该规范构建了名牌，但没有构建护照。

这就是理解后续所有内容的心智模型：ERC-8004 是一个名牌，它告诉你一个 Agent 在某一条特定链上自称是谁；护照则是另一回事——一种被每个辖区认可的单一身份，并且附有可验证的历史记录。Agent 需要护照，而该标准只提供了名牌。

ERC-8004 碎片化的两个面

这种碎片化并非抽象概念，它恰好出现在两个地方，而这两个地方都对 Agent 的经济活动至关重要。

1. 身份碎片化

假设我们的 Agent 在 Base 身份注册表中注册，它获得了一个 tokenId，而这个 tokenId 只存在于 Base 上。

现在，Arbitrum 上的一个客户端想在委托一笔交易之前验证这个 Agent 的身份。该客户端无法从 Arbitrum 查询 Base 注册表。该规范中没有跨链身份桥——没有消息传递协议发布过公开的 ERC-8004 跨链身份产品。我们检查了所有六个（LayerZero、Chainlink CCIP、Hyperlane、Wormhole、Axelar），结果为零。

客户端唯一的备用方案是该 Agent 自行声明的 Agent Registration File——一个托管在链下的 JSON 文件，上面写着“我在 Base 上也注册为 agentId=42”。没有链上证明，也没有将两个注册关联起来的签名。对于一个名为“无信任 Agent”（Trustless Agents）的标准来说，这恰恰是一个信任假设，且出现在了错误的位置。

这并非未来的问题。BNB Chain 已经推出了 BAP-578——一个基于 ERC-8004 构建的链特定声誉标准，但它无法与以太坊或 Base 的声誉注册表互操作。这种模式已经开始运作：当基础标准不提供跨链原语时，每条链都会构建自己的扩展，结果就是 N 个不兼容的孤岛。

2. 声誉孤岛

现在来看第二个面，这才是真正让 Agent 付出实际代价的地方。

假设我们的 Agent 在 Base 上交易了 500 个预测市场，准确率为 79%。这个交易记录作为反馈条目存在于 Base 声誉注册表中。

当同一个 Agent 在 Arbitrum 上接任务时，这些声誉都不会随之转移。giveFeedback() 函数要求 msg.sender 与注册表在同一个链上。该规范中没有跨链反馈路径，没有聚合层、索引器或预言机将 Agent 在其工作的各个链上的声誉整合起来。

这些数字让规模变得具体：整个生态系统中存在约 19.4 万条声誉反馈，每一条都被锁定在其起源链上。一个在以太坊上有良好记录、在 Arbitrum 上记录干净的 Agent，当新的消费者在 Base 上遇到它时，它在以太坊或 Arbitrum 上的记录都得不到任何认可。

ERC-8183——Agentic Commerce Protocol（Agent 商业协议）——让这个问题更加棘手。其 ReputationGateHook 根据 ERC-8004 声誉评分来控制提供资金的权限，并且该功能已在 Base 上上线。这是迄今为止声誉注册表最具体的生产用途，但它仅限于同一条链。一个部署在 Base 上的 Hook 无法读取 Agent 在以太坊主网上的声誉，除非借助链下中继。

该规范为 Agent 提供了一个声誉系统，然后它又把这个系统逐链隔离了起来。

所以，以下是这个差距的诚实总结：ERC-8004 在发现方面做得很好——一个最小的链上身份 Handle，可以解析为 Agent Card——但它没有处理跨链身份，也没有处理跨链声誉。一旦 Agent 在超过一条链上运行，这两个缺口就会同时出现。

一个真正的解决方案必须提供什么

在构建任何东西之前，我需要明确地知道什么才能真正填补这个空白。三个要求，仅此而已。

Agent 的一个规范化的身份——一个锚点，其运作的每条链都可以指回它。

一个聚合的声誉评分——一个数字，反映 Agent 在所有链上的表现，而不是五个互不关联的数字。

链上可验证的读取——不是由操作者控制的链下 JSON，而是智能合约可以实际查询和信任的身份与声誉。

ERC-8004 给了我们 Trustless Agents。

于是，我构建了 Trustless Agents Plus——TAP。

TAP 如何填补空白

TAP 是两个部署在 Push Chain 上的智能合约。它不替代 ERC-8004——每条链上的注册表保持原样不变，本地注册、Agent Card 和每条链上的反馈均不改变。TAP 在现有基础上叠加了一层规范化的身份和声誉层。

两个合约承载了整个设计。

TAPRegistry —— 规范化身份层

Agent 只需注册一次。注册发生在 Push Chain 上，但 Agent 可以使用其现有钱包从任何支持的链上完成注册并支付 Gas——无需桥接、无需新钱包、无需获取 Gas 代币。

agentId 是确定性的，它直接源自 Agent 的通用执行账户（UEA）地址——uint256(uint160(ueaAddress)) % 10_000_000。身份 Token 是灵魂绑定的：不可转让，永久绑定到获得它的 Agent 身上。

每条链上的 ERC-8004 身份通过 bind() 链接到这个规范化身份。Agent 签署一条 EIP-712 类型化数据消息，证明他们在另一条链的 ERC-8004 注册表上控制着同一个密钥。签名涵盖了链命名空间、链 ID、注册表地址、绑定的 Agent ID、一个 nonce 和一个截止时间——因此，针对一个绑定的泄露签名无法被重放用于另一个绑定。同时支持 EOA（ECDSA）和智能钱包（ERC-1271）签名，所以多签和 AA 钱包无需变通即可进行绑定。

这就是护照：一个规范化的身份，每条链上的注册都通过密码学方式与之关联——在链上可验证，而不是在 JSON 文件中声明。

TAPReputationRegistry —— 跨链声誉聚合器

第二个合约解决了孤岛问题。

授权的报告者提交每条链的声誉快照。每次提交都会根据 TAPRegistry 的绑定进行验证——报告者不能为 Agent 从未绑定的链注入声誉。然后，合约在小数精度之间进行归一化，并推导出一个单一的评分，范围在 [0, 10,000] 基点之间，综合了质量、数量、链多样性和惩罚扣分。

聚合评分和每条链的详细数据都是公开的。需要单一信任门的消费者读取评分；需要特定上下文信任的消费者则读取 getChainReputation() 并使用原始的每条链数据。

以下是整个系统在一个图表中的示意：

    每条链的 ERC-8004 注册表              结算链 (Push Chain)
    +------------------+                    +---------------------------+
    | 以太坊            | --bind (EIP-712)-> |        TAPRegistry        |
    | boundAgentId=17  |                    |   canonicalId=4_928_371   |
    +------------------+                    |   灵魂绑定, UEA 锚定      |
    | Base             | --bind (EIP-712)-> |                           |
    | boundAgentId=42  |                    +---------------------------+
    +------------------+                    |   TAPReputationRegistry   |
    | Arbitrum         | --bind (EIP-712)-> |   评分: 7,578 基点        |
    | boundAgentId=8   |                    |   3 条链, 1,000 条反馈    |
    +------------------+                    +---------------------------+
           ^                                              ^
           |                                              |
      本地反馈                                 REPORTER_ROLE 快照
      (未改变)                                  + 经绑定验证

那么这在实践中意味着什么呢？一个 Agent 只需注册一次，通过签名绑定其现有的 ERC-8004 身份，之后，任何在 Push Chain 上的合约都可以同步地、以零边际成本读取该 Agent 的一个身份和一个声誉评分。

值得关注的设计选择

TAP 内部的三个决策值得拿出来讲，因为正是它们让这个设计站得住脚。

灵魂绑定而非可转让

ERC-8004 发行的是可转让的 ERC-721 Token。TAP 重写了整个转移表面，无条件地使其回退。

原因是信任的连续性：如果 agentId #42 用两年时间积累了 8,000 基点的声誉，然后出售了该身份，新所有者会继承他们未赚取的信任。灵魂绑定杜绝了这种情况。代价是真实的——二级市场和通过转移进行委托的功能不复存在——但缓解措施是干净的：Agent Card 可以对委托的操作者进行编码，而不触及身份本身。

真正持久的跨链惩罚

ERC-8004 完全没有惩罚机制。TAP 引入了一个 SLASHER_ROLE，具有累积的严重程度扣减功能。

关键特性：即使相关的绑定被移除，惩罚记录仍然存在。在链 A 上被惩罚的 Agent 无法通过解绑 A 并重新绑定来逃避惩罚。正面声誉与活跃的链接绑定，负面声誉与身份绑定。你不能通过重新排列绑定来洗白不良记录。

使用 Push Chain 而非消息传递层中继

显而易见的替代方案是将 TAP 部署在现有的 L1 上，并通过 LayerZero、CCIP 或 Hyperlane 中继绑定事件。我选择了 Push Chain，原因是一个原语：通用执行账户（Universal Executor Accounts）。

在大多数跨链架构中，一个网关合约代表用户进行调用——msg.sender 变成了网关，而不是用户。身份在关键时刻丢失。使用 UEA，用户自己的账户进行调用。TAP 从 UEA 地址派生出 agentId，这将规范化身份锚定到 Agent 操作者的真实跨链身份，而不是一个中间人。

在此基础上，还有费用抽象——无需桥接即可用 ETH、SOL 或 BNB 支付 Gas——以及通过通用网关（Universal Gateway）实现源链调用。最终效果是：Agent 构建者可以从他们现有的钱包、使用他们原生 Gas Token 进行注册、绑定和查询声誉，并且身份从头到尾得以保留。

这个权衡是诚实的：Push Chain 目前支持以太坊、Arbitrum、BNB、Base 和 Solana——五条链，并非全部。TAP 的覆盖范围目前受限于此。

这对构建者意味着什么

如果你在超过一条链上运营一个 Agent，那么你现在就在为碎片化付出代价，无论你是否已经命名了这种成本。

你 Agent 触及的每一条新链都会增加另一个互不关联的身份和另一个孤立的声誉评分。你在以太坊上赢得的声誉在 Base 上对你不起作用。这不是当前实现的怪癖——这正是 ERC-8004 的每条链单例合约设计所规定的做法。

TAP 并不要求你拆除任何现有的东西。每条链上的注册表继续履行它们的职责。TAP 添加的是 ERC-8004 遗漏的一层：在链之间跳转时仍然有效的一个身份和一个声誉评分。

TAP 已在 Push Chain 的 Donut 测试网上线。通过 create-8004-tap-agent，只需几分钟即可注册一个 Agent、绑定你现有的 ERC-8004 身份并查询聚合评分。

ERC-8004 给了 Agent 一个名牌。多链 Agent 需要一个护照——而这正是 TAP 旨在填补的空白。

干杯，解读者们。

延伸阅读

干杯，解读者们。

ERC-8183: 一份给新手的 Agent 商业指南 ERC-8183: 一份给新手的 Agent 商业指南 机器现在可以雇佣其他机器了。 不是通过 API 密钥、订阅，或人类点击支付屏幕上的“批准”。而是通过一个以太坊标准——将托管、评估和可执行的服务协议内置到智能合约中。 ERC-8183 就是 Agentic Commerce Protocol。它定义了 AI 如何... 那么，“Trustless Agents”到底在做什么？ 那么，“Trustless Agents”到底在做什么？ ERC-8004 并非你所想的那样。 大多数人听到“无信任 Agent”就认为该标准开箱即用地提供了无信任。事实并非如此。它提供的是一种更谦逊、且——说实话——在此阶段更有用的东西：一个协调原语，赋予链上 AI Agent... TAP 实际上是如何在底层工作的 TAP 实际上是如何在底层工作的 详细概述了我是如何为链上 AI Agent 制作我的 TAP 项目的。 上周我介绍了 TAP——为碎片化的 ERC-8004 Agent 提供的规范化身份和聚合声誉。 本周将深入探讨。 我分解了每个组件：TAPRegistry 如何从单个钱包推导出确定性 Agent ID，如何... Trustless Agents Plus - 深度解析 Trustless Agents Plus - 深度解析 AI Agent 正经历一场多链身份危机。 在这场危机中，同一个 Agent 在三条不同的链上表现为三个不同的实体，并且没有链上机制可以证明它们是同一个。 ERC-8004 赋予了 AI Agent 链上身份。 已有超过 20 万个 Agent 在 23 条以上的链上注册，相比之前...

  • 原文链接： decipherclub.com/where-t...
  • 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
微信扫码分享

相关文章

0 条评论

登录后发表评论