为什么每个 AI 代理都需要一个钱包

智能体可以在不涉及任何资金的情况下给出建议。但执行是另一回事。一旦智能体需要为数据付费、购买算力、调整持仓或在链上结算交易，它就需要一个地方来持有资产、授权资金转移，并在资金流动前执行限制规则。这个地方就是钱包——这也是 MetaMask Agent Wallet 和 Coinbase 的 AgentKit 在 2026 年相继推出的核心原因，两者都旨在赋能智能体，推动新数字经济的发展。Coinbase 还推动了 x402 支付协议的普及，许多智能体现在使用该协议来支付 API、算力和数据费用。

执行型智能体是否需要钱包，这个问题已有定论。真正值得探讨的是：在智能体使用钱包的过程中，控制权究竟在谁手中——用户是否持有可导出的密钥并直接设定智能体的权限，还是智能体的执行路径在运行期间始终依赖于服务商的基础设施？MetaMask Agent Wallet 采用的是第一种方案：一个具备可编程护栏的自托管钱包，专为执行型智能体而构建。

入门基础请参阅 什么是智能体钱包，深入了解技术架构请参阅 AI 智能体如何在不接触您密钥的情况下完成交易。如需产品对比，请参阅 2026 年最佳智能体钱包。本文重点探讨：为何钱包层对任何执行型智能体而言都已不可或缺，以及为何托管方式决定了智能体自主权的真实边界。

从建议型智能体到执行型智能体的转变

仅输出文本的智能体无需接触资金。它的输出只是建议，仍需人工执行。这是迄今为止大多数已部署智能体的默认形态，也是它们的天花板：只能给出建议的智能体在每一个财务步骤上都需要人工介入，这极大限制了它实际能完成的工作量。

而现在正在构建的智能体截然不同。它们能监控 DeFi 持仓并直接进行再平衡；能跨多个服务商比价算力或数据，并即时支付最低价；能直接执行交易，而不只是描述交易。所有这些操作都需要同一种底层能力：以智能体的运行速度在链上持有并转移资产，无需等待人工解锁下一步。

这种能力不来自语言模型，而来自钱包。智能体的推理能力可以无限强大，但如果没有持有和授权资金转移的方式，它就只是一个建议引擎。钱包是将决策转化为行动的关键——这也是为什么这一品类在短短数月内，就从开发者的探索性项目演变为 MetaMask、Coinbase、Cobo 和 OKX 的正式产品线。

智能体完成交易实际需要什么

要从建议转向执行，智能体需要三样东西：可供调用的余额、在执行过程中为所消耗资源付费的能力，以及无需人工逐一确认即可在链上执行的能力。

第二个需求比听起来更新颖。软件历来都需要为基础设施付费，但通常通过人工管理的发票、订阅或绑定的银行卡来完成，而非由智能体在任务执行过程中自主发起支付。调用付费 API、向其他模型购买推理服务或获取授权数据的智能体，需要在流程内即时结算这些费用。x402 填补了这一空白：这是一个基于 HTTP 402"Payment Required"状态码构建的开放协议，允许服务端请求付款，客户端在同一次交互中完成结算，无需账户注册，也无需人工中途审批。MetaMask Agent Wallet 目前支持 x402 的买方侧，智能体可以直接从其钱包向 x402 网关端点付款。x402 独立于钱包本身：它定义的是支付的定价和结算方式，而非密钥的持有者或智能体的消费权限——这些问题仍由钱包来决定。

综合来看，这就是人们所说的"智能体商务"或"机器对机器支付"的含义：软件向软件付费，以代码运行的速度完成交易，用于过去需要人工持信用卡才能完成的服务。没有底层钱包，这一切都无从实现。

托管问题

一旦确认执行型智能体需要钱包，更有价值的问题就变成了：谁来控制它？目前市场上可见三种模式，处于不同的可用阶段，对这一问题的回答也各不相同。

该品类中的托管术语各有差异，各服务商对自身模式的描述也较为客观。Coinbase 将 Agentic Wallets 定义为在可信执行环境（TEE）内保护的非托管钱包，并配备可编程消费限额和 KYT 筛查。OKX 对其 Agentic Wallet 的描述类似：密钥在 TEE 内管理，从不暴露给模型。Cobo 将其 Agentic Wallet 定位于基于 MPC 的密钥分割和 Pact 强制执行的策略引擎，专为"具备细粒度策略控制的企业级自动化"而构建。这些都是合理的安全模型，MetaMask Agent Wallet 同样使用 TEE 支持的基础设施来保护签名。本文关注的区别比"TEE 与非 TEE"更为具体：用户是否持有可导出的密钥和退出路径，还是智能体的执行在运行期间始终依赖于服务商运营的钱包。

这是自托管原则在新型用户场景下的应用。服务商运营的基础设施可以是真正安全的，但只要智能体在其上运行，它就始终是每笔交易信任链的一部分——无论服务商的初衷多么良好，该基础设施都可能冻结账户、限制访问或变更条款。自托管设计允许用户保留导出或恢复路径，并直接定义智能体的权限，而非完全依赖服务商持有的账户。对于代表用户自主行动的智能体而言，这一区别决定了其自主权究竟随用户而行，还是受限于服务商的执行环境。

自主而不失控：可编程护栏

仅有自托管并不是完整的答案。一个没有任何限制的自托管钱包会让智能体在用户余额允许的范围内为所欲为，这本身就是一种风险。真正的答案是将自托管与预先设定的可编程护栏相结合：消费上限、协议白名单、会话限制、单笔交易限额，以及智能体每次操作及其原因的完整日志。

护栏使得授予智能体持续授权成为可能，而无需逐笔手动审批。消费上限可以在不危及账户的情况下限制错误交易的损失。协议白名单将智能体限制在用户已审核的合约范围内。会话和单笔交易上限可以限制单次被攻击的提示词或恶意响应所能造成的损害，而可审计的日志则允许事后重建每一次操作。这一切都不需要放弃自主权——而是定义了自主权运作的边界。

在实践中，目前有两种运行模式：默认的保守模式，在设置时强制执行每日消费限额和协议白名单，对超出规则或被威胁扫描标记的任何操作暂停并要求双重验证；以及第二种可选模式，在策略边界情况下给予智能体更大的自由度，同时仍会拦截明显的恶意交易。在 MetaMask Agent Wallet 中，这两种模式分别被称为 Guard Mode 和 Beast Mode。无论选择哪种模式，护栏都由用户在智能体启动前设定，而非由智能体在执行过程中自行协商。

MetaMask Agent Wallet：专为智能体构建的自托管钱包

MetaMask Agent Wallet 是一款专为 AI 智能体构建的自托管钱包，其核心设计理念是：密钥由用户持有，而非 MetaMask。该钱包允许智能体在 EVM 链和 Hyperliquid 上执行兑换、永续合约、预测市场、质押和流动性提供——所有操作均通过同一个自托管钱包完成。

每笔受支持的 EVM 交易在上链前都会经过安全流水线处理：交易模拟、由 Blockaid 驱动的 Transaction Shield 威胁扫描，以及 Smart Transactions MEV 保护。无论用户选择哪种运行模式，该流水线都会运行：默认的 Guard Mode 要求对超出消费限额或协议白名单的任何操作进行双重验证；Beast Mode 则在策略边界情况下给予智能体更大的自由度，同时仍会拦截恶意交易并将其提交双重验证审查。密钥通过可信执行环境加以保护，同时用户可随时导出；通过安全流水线的符合条件的交易还享有 Transaction Protection 保障，每月最高赔付 10,000 美元（具体以资格条件、限额和条款为准）。

MetaMask Agent Wallet 目前以 CLI 为主，可接入包括 Claude Code、Codex、OpenClaw、Hermes、OpenCode 和 Cursor 在内的多个智能体框架。现已通过早期访问计划开放使用，正式版即将推出。如需完整了解交易如何在该架构中从指令到执行的全流程，请参阅 AI 智能体如何在不接触您密钥的情况下完成交易。

这对构建智能体集群的开发者意味着什么

集群场景是托管问题复杂度倍增的地方。单个智能体使用服务商持有的密钥，意味着一个信任节点。而由十几个智能体组成的集群，每个智能体独立交易，风险敞口成倍放大——如果它们共用一个服务商持有的钱包，单个智能体被攻破或基础设施出现故障，就可能波及整个集群。

自托管架构为开发者提供了两种控制爆炸半径的方式。每个智能体可以拥有独立的专属钱包，设有各自的消费限额，实现最清晰的隔离和审计追踪。或者，单个用户钱包可以向每个智能体授予有范围限定的委托权限——资产类型、金额、有效期和约束条件均预先定义——无需将资金分散到多个独立充值的钱包中。许多生产系统同时采用两种方式：一个充值钱包用于广泛执行，有范围限定的委托权限用于更具体的重复性任务，例如通过 x402 支付数据或算力费用。无论采用哪种模式，用户而非第三方始终是集群中任何智能体权限的最终来源——且托管出错的代价受用户自身策略约束，而非取决于服务商的基础设施。