从 AI Agent 到链上权限边界：ERC-8004 正在改变什么？

随着 DeFi、账户抽象和 AI Agent 等应用的发展，链上授权正在从一次性的签名确认，逐渐演变为一种可以长期生效、反复使用的执行权限。同时，新的变化也在发生：AI Agent 已经开始具备自动请求服务、自动完成支付的能力，例如 x402 协议通过 HTTP 402 状态码，让 Agent 能够在无需人工介入的情况下，用稳定币为资源和服务即时付费。这使得链上行为不再是孤立的交易，而是持续运行的自动化协作过程。

在这种背景下，授权问题被进一步放大。当前 Web3 体系中的授权方式仍然边界模糊、表达粗糙，往往只解决能不能用资产，却难以回答具体允许做什么、做到什么程度。ERC-8004 正是在这一背景下被提出。它并不定义新的资产，也不改变交易或支付如何执行，而是尝试为链上行为建立一套可被系统理解和校验的权限模型，让授权本身成为可描述、可约束、可管理的对象。

从更大的系统视角看，ERC-8004 与账户抽象和 x402 等自动化支付协议并非竞争关系，而是处于不同层级的分工协作：x402 解决的是行为发生后的价值交换问题，而 ERC-8004 关注的是行为发生之前，谁被允许行动、权限是否越界。在 DeFi、AI Agent 以及企业和 RWA 等场景中，这种权限先行、支付随后的结构，有望推动授权从资产级走向行为级，为更复杂、长期的自动化协作提供可控基础。尽管在学习成本、钱包支持和用户体验上仍面临现实挑战，ERC-8004 并非短期叙事工具，而是一个关乎 Web3 能否承载复杂系统运行的底层标准。

1.ERC-8004 的提出动因

随着链上基础设施不断演进，资产上链与交易执行相关的能力持续被抽象和强化。从 ERC-20、NFT，到多签钱包与账户抽象（ERC-4337），用户参与链上活动的门槛不断降低，账户本身也变得越来越智能。

但在这一进程中，一个基础问题始终没有被系统性解决：授权机制本身几乎没有发生实质演进。在早期 Web3 中，授权意味着一次私钥签名。用户通过签名表达“我同意”，无论是转账、合约调用还是 approve 操作，授权都被视为一次性确认行为，风险边界完全由用户自行承担。

然而，今天的链上环境已经发生了变化。在 DeFi 场景中，approve 往往长期有效；在自动化策略和 Session Key 体系下，授权会被反复使用；在 AI Agent 或 Bot 执行交易的模式中，用户甚至不再直接参与每一次操作。授权正在从一次性确认，演变为一种持续存在的执行能力，更像是把做某件事的权力交出去一段时间。

问题在于，当前 Web3 的基础设施，几乎没有为这种长期授权状态提供清晰、统一的约束方式。权限范围模糊、授权难以撤销、风险不可预期，成为大量安全事件的源头。与此同时，账户抽象进一步放大了这一矛盾：当账户可以自动执行交易、由第三方代付 Gas 时，它到底能做什么、不能做什么反而变得更加不清晰。

正是在这样的背景下，ERC-8004 被提出。它试图补上 Web3 长期缺失的一环：为授权本身建立一套清晰、可约束、可被系统理解的权限模型。

2.ERC-8004 的核心内容

ERC-8004 的切入点，并不在资产形态或交易执行方式上，而在于授权是否能够被单独描述、独立校验，并在系统层面持续管理。

2.1 ERC-8004 定义了什么？

根据 Ethereum Improvement Proposals（EIP）官网定义：ERC-8004 是一种标准协议，用于在以太坊上发现、选择并交互可信赖的 autonomous agents。它通过链上注册、声誉与验证机制，构建无需事先信任即可去中心化交互的 agent 基础设施。

这里的 autonomous agents 并不限于 AI Agent，而是指任何可被授权、可独立执行行为的主体，如合约、自动化脚本、多签或服务进程。ERC-8004 关注的是执行主体是否具备明确授权和权限边界的能力，AI Agent 只是其中典型应用之一。

从更通用的角度看，ERC-8004 并非新的资产标准或账户类型，而是一种链上权限表达与校验的框架，用于描述某主体在何种条件下允许执行哪些行为，并在操作前进行验证。因此，ERC-8004 关注的不是“钱是什么”或“交易如何执行”，而是“哪些行为被允许”。它不会创建新资产或改变现有资产属性，只是在资产和账户之上增加了一层清晰可验证的权限规则。

此外，ERC-8004 并非账户抽象（ERC-4337）的替代。账户抽象关注交易如何执行，而 ERC-8004 解决的是交易发生前的权限判断。若说账户抽象让账户更灵活，ERC-8004 则为这种灵活性设定了明确边界。

ERC-8004 的核心在于将授权从隐含在签名中的动作，转变为可被清晰描述、独立校验并持续管理的权限对象。

2.2 ERC-8004 的核心机制框架

要理解 ERC-8004 的核心机制，可以先抛开复杂的技术实现，把它理解为一份“链上权限说明书”。在传统的授权逻辑中，用户往往只是做出一个笼统的决定：“我同意你操作我的资产。” 至于具体能做什么、能做多少、做多久，系统并不会进一步区分。而在 ERC-8004 的框架下，一次授权不再是模糊的同意，而是被拆解为一组可以被清晰描述、并由系统强制执行的规则。这份“权限说明书”，通常包含以下五类关键信息。

授权主体（Who）：谁被允许执行？

首先要明确的，是谁被授予了执行权限。在 ERC-8004 中，被授权的对象不再局限于一个固定的钱包地址，还可以是合约、自动化 Agent，甚至是用于短期操作的 Session Key。这使得授权可以适配更多复杂场景，例如：让某个策略合约在限定范围内执行操作，或让 Agent 在无需反复签名的情况下完成特定任务。重要的是，权限始终是授予给“某个明确的主体”，而不是被模糊地交出去。

可执行行为（What）：允许做什么操作？

其次，是被允许执行哪些行为。传统授权往往是全有或全无，一旦授权，就默认允许合约在权限范围内自由调用。而在 ERC-8004 的设计中，授权可以精确到具体的行为类型，例如只允许执行 swap、transfer，或某一类函数调用，而不是默认开放所有可能操作。ERC-8004 回答的不是能不能用，而是能用到哪一步。

约束条件（Under what conditions）：在什么条件下才能执行？

这是 ERC-8004 区别于传统授权的关键部分。在权限说明书中，授权通常会附带明确的限制条件，例如：单笔或累计的金额上限；执行频率或次数限制；只能作用于特定协议、池子或合约地址等。这些条件并不是事后监控规则，而是执行前必须满足的前置条件。一旦条件不成立，操作本身就无法被执行。

生效与失效规则（When）：权限什么时候成立、什么时候终止？

ERC-8004 还引入了清晰的时间与生命周期概念。授权可以被设定为：（a）只在特定时间段内有效；（b）使用一次后自动失效；（c）随时可被撤销。这让授权不再是给出去就收不回来的长期负担，而是一种可被精细管理的临时能力。

校验方式（How enforced）：规则如何被真正执行？

最后，也是最容易被忽视的一点：这些规则是如何被执行的。ERC-8004 的核心思想，是在操作发生之前进行权限校验。如果某个行为不符合事先定义的权限规则，系统会直接拒绝执行，而不是在问题发生后再追究责任。这也正是 ERC-8004 与传统风控逻辑的根本差异所在。

2.3 ERC-8004 新增的能力类型：以前为什么做不到？

表面看，ERC-8004 只是让授权更细化，但早期以太坊授权模型其实无法表达复杂的授权逻辑。传统授权只检查某个地址是否被允许操作，一旦授权通过，能做什么、多少、什么时候做，都无法被系统识别。

ERC-8004 的核心突破在于，将授权从“身份判断”升级为“行为判断”。系统开始判定一次操作是否符合用户设定的权限边界，而不只是确认谁发起的。这让授权天然包含金额、频率、范围和有效期等条件，无需依赖用户事后撤销或人工监控。

当授权逻辑结构化后，它首次具备了可组合和可复用的能力。多步骤、跨协议的操作可在授权阶段被明确限制，而非留给执行时临时判断。正因如此，ERC-8004 才真正为 Agent 场景打开空间。自动化程序不再需要“无限授权”，而被限制在清晰、可验证的行为范围内，越界则拒绝执行。

ERC-8004 新增的不是简单的“更安全授权”，而是让授权逻辑可被系统理解和执行，这是其与传统授权机制的本质区别。

3.ERC-8004 的潜在应用方向

ERC-8004 并不是为某一个具体产品而设计的标准，它更像是一种授权能力的通用语言。因此，它的应用价值，并不体现在单一场景的爆发，而体现在多个体系在授权复杂化后，对同一类能力的共同需求。

DeFi：从“资产级授权”走向“行为级授权”

在当前 DeFi 体系中，最常见的授权方式依然是“一次性授权、无限额度”。比如用户为了做一次 swap、借贷或质押，需要先对合约进行 approve，本质上是把资产的控制权整体交出去。这在体验上很高效，但风险也很直观：一旦合约被升级、被攻击，或被用在用户未预期的逻辑中，授权本身就会成为风险放大器。ERC-8004 授权的对象不再是资产，而是具体行为。例如用户可以要求：不是我允许这个合约无限使用我的 USDC；而是我允许它在 24 小时内，用不超过 1,000 USDC，完成一次 swap 操作。虽然部分项目已尝试限制授权范围和时长，但目前大多是各自为政。ERC-8004 的价值在于将行为级授权标准化，实现可复用、可组合的权限管理，从根本上提升风险控制能力。

AI Agent：为自动化执行提供可验证的权限边界

随着 AI Agent 逐渐参与链上决策与执行，授权问题被放大到了一个新的层级。Agent 的价值在于持续运行与自动执行，但这也意味着它必须长期持有某种操作权限。如果缺乏清晰的权限边界，所谓的 Agent，本质上只是一个拥有用户完全控制权的自动化程序，风险并不会因为“智能”而减少。ERC-8004 为 Agent 提供一种系统级可校验的授权边界。Agent 可以被授权执行哪些操作、在什么范围内行动、是否具有时间限制，这些规则可以在执行前被验证，而不是依赖事后监控。只有当权限本身是结构化、可验证的，自动化执行才具备可信的前提。

与 x402 协议的协同：让 Agent 的行为“可授权、可结算”

在 Agent 场景中，授权之外的另一个关键问题是：当行为被允许之后，价值如何完成交换。一些应用层协议正在尝试解决这一问题，例如 x402 协议通过重新启用 HTTP 402（Payment Required）状态码，使 Agent 在请求资源或服务时，能够自动完成稳定币支付。在这种架构下，ERC-8004 与 x402 分别位于不同层级，却形成了互补关系。ERC-8004 关注的是“谁可以做什么、是否被允许”，为行为建立权限与信任边界；x402 则解决“当行为发生时，如何完成支付与结算”。前者并不依赖后者运行，后者也不以 ERC-8004 为前提，但在 Agent 经济中，两者分别承担了权限层与支付层的角色。这种分层协作，使 Agent 能够在无需人工干预的情况下，完成从权限校验到价值交换的完整流程，也避免了将身份、授权和支付逻辑混杂在同一系统中的复杂性。随着 Agent 在内容获取、数据调用和算力服务等场景中的活跃度提升，这类组合正在有望成为可扩展的基础架构形态。

企业与 RWA 场景：权限即合规的基础表达

在企业应用和 RWA 场景中，ERC-8004 的价值更多体现在合规与可解释性上。现实世界中的资产管理，往往需要清晰回答：谁在什么条件下被授权执行了哪些行为。相比资产本身是否上链，权限如何被定义和记录，反而是进入现实金融体系的关键。ERC-8004 并不直接解决合规问题，但它为权限的结构化表达提供了底层支持，使授权天然具备被审计、被追溯和被验证的可能性。这种能力不会立刻改变用户体验，却能显著降低 Web3 系统与传统组织之间的对接成本。

从这些潜在应用可以看到，ERC-8004 并不是一个“场景驱动型”的标准，而是一种随着授权复杂度上升而自然浮现的基础能力。当链上行为从单次操作，演变为持续运行的系统行为时，一个清晰、可验证的权限表达方式，几乎是不可回避的选择。

4.ERC-8004 的挑战与长期价值 

现实挑战

首先是学习成本。相比点一次授权就完事，ERC-8004 引入的是一套更精细的权限描述逻辑。无论是开发者还是用户，都需要重新理解授权在系统中的含义。这种认知成本还需要一些时间被市场吸收。其次是钱包与基础设施支持。ERC-8004 的能力只有在钱包、SDK 和执行环境理解并配合的前提下，才能真正发挥作用。在早期阶段，它更像是一种可用但不通用的能力，难以立刻形成规模效应。最后是用户体验。复杂授权如果被直接暴露给用户，只会增加操作负担。如何将一组结构化、机器可验证的权限规则，转化为普通用户能够直观理解、并愿意接受的交互方式，将直接决定 ERC-8004 是否具备大规模落地的可能。

ERC-4008 解决的不是当下，而是下一阶段

正因存在这些现实门槛，ERC-8004 并不适合作为一个短期叙事工具。它不会立刻带来用户规模的爆发，也不会直接催生新的收益模型。ERC-8004 并不试图让世界变得更快，而是让系统在复杂化之后，依然可控、可解释、可验证。它的价值不在于功能数量，而在于是否为未来的自动化、Agent 协作和机构参与，预留了一套可持续演进的权限基础。从这个意义上说，ERC-8004 不是为某一轮周期而生的标准，而是一个决定 Web3 能否承载复杂协作关系的底层能力之一。

参考

1.ERC-8004: Trustless Agents: https://eips.ethereum.org/EIPS/eip-8004 

2.Ethereum Improvement Proposals (EIPs): https://github.com/ethereum/EIPs

3.ERC-4337: Account Abstraction Using Alt Mempool: https://eips.ethereum.org/EIPS/eip-4337 

4.ERC-8004 website: https://www.8004.org 

5.How x402 Works: https://docs.cdp.coinbase.com/x402/core-concepts/how-it-works 

6.Welcome to x402: https://docs.x402.org/introduction