Agent 钱包:面向 AI Agent 的会话与权限模型

一个进行链上交易的 AI agent，只差一次签名就能动用真实资金。它已经读取了市场行情，通过某个 DEX 选好了路径，准备执行交易。要安全地实现这一点，关键在于一个问题：如果这个 agent 出错、被劫持，或者干脆是有 bug，会发生什么？它能不能把钱包里的资金转空？你能不能在造成损失之前把它拦下来？

要为 agent 配置带权限控制的钱包，应给 agent 一个受限会话，而不是私钥。对于编码 agent 或内部自动化流程，使用 Alchemy CLI 中的 Agent Wallets：运行 alchemy wallet connect，在控制台批准允许的操作和过期时间，用完后可立即撤销该会话。如果你的产品是让自己的用户把权限委托给 agent，使用 Wallet APIs session keys，它在 EIP-7702 智能钱包之上提供按代币的支出上限、合约白名单、gas 限额和过期时间。两种方式下，agent 都不会持有 owner 的密钥。

什么是 agent 钱包？它和普通加密钱包有什么区别？

普通钱包假设每一笔交易都由一个人来审核并用只有他自己持有的密钥签名。agent 钱包的假设正相反：由 AI agent 或自动化程序持续签名，没有人每次都点击批准，而资金的所有者（个人或公司）保留最终控制权。

两者的区别在于围绕签名密钥的权限模型，而不是钱包里的余额或地址：agent 被允许做什么（受限的能力范围）、被允许做多久（有时限的会话），以及出问题时你能多快切断它。

Agent Wallets 直接处理了这三个问题：

• 受限的能力范围：一个 CLI 会话只包含你授予的特定签名方法，比如转账、swap、跨链桥接，或合约调用。将一个密钥限制在某个合约的特定函数上，属于 Wallet API 的 session-key 权限，不属于 CLI 的能力范围。
• 有时限的会话：每一次授权都带有过期时间，即使没人主动撤销，访问权限也会自动失效。
• 快速关停：通过 Alchemy 控制台或使用 alchemy wallet disconnect 撤销一个 CLI 会话，会立即在验证层生效，不需要交易。

无论你是直接使用 Agent Wallets CLI 产品（覆盖 EVM 和 Solana），还是基于底层的 Wallet APIs session-key 原语为自己的用户搭建功能，受限的能力范围和过期时间都会出现。无需挖矿交易即可立即关停，这是 CLI 路径的特点。而移除一个 Wallet API session key，则是一次链上卸载操作。

agent 钱包如何让私钥不接触到 agent？

为 agent 设计安全的交易流程，意味着要把普通钱包捆绑在一个密钥里的三件事分开：托管（谁持有私钥）、授权（允许做什么）、控制（谁能批准或关停）。

• Turnkey 将托管保留在硬件安全隔离环境（secure enclave）内，并在同一个隔离环境中运行其策略引擎，因此只有在请求通过规则检查后才会产出签名，agent 本身从不接触密钥。
• Crossmint 和 Cobo 则把一个钱包拆分为一个 owner key 和一个 agent key（Cobo 使用的是跨多个独立方的 MPC，而非单一密钥），使 agent 的密钥只能在 owner 设定的限制范围内起作用。
• Privy 将密钥保存在带有密钥分片的安全隔离环境中，并在 agent 与签名之间放置一个策略引擎（限额、白名单和人工审批）。其 Agent CLI 让 agent 获得对某个钱包的受限访问，而不会暴露私钥或凭证。
• Coinbase Agentic Wallets 将私钥保存在 Coinbase 的隔离环境基础设施中，绝不会暴露给 agent 的 prompt 或 LLM，并通过每个会话和每笔交易的支出上限来约束 agent。
• Alchemy 在 CLI 中内置了同样的分离机制：本地生成的 session signer 负责认证 agent，而实际的私钥则由独立的托管方持有，因此 agent 完成认证和签名的全过程都不会接触到私钥。

具体流程是这样的。

• 运行 alchemy wallet connect，CLI 会在本地生成一个 P-256 密钥对，该密钥对永远不会离开你的机器。
• 你在 Alchemy 控制台批准该会话，这一步会把该公钥作为一个签名者附加上去，并限定其能力范围与你设置的过期时间。
• 钱包的实际私钥保存在一个嵌入式钱包合作方那里，默认是 Privy。
• 每一次签名调用都要经过两步检查：Alchemy 的后端构建托管方所期望的确切负载，你的 CLI 在本地对其签名，只有当会话仍然有效时，请求才会到达托管方。agent 从未接收或经手过私钥。

哪个钱包适合自主 agent：Alchemy、Privy 还是 Coinbase？

三者都是为自主 agent 打造的，而且都不会把私钥交给 agent。如果 agent 还需要从同一个账户获得 RPC、数据、模拟和 webhook，或者你的用户通过带支出上限的 session key 向它委托权限，选择 Alchemy。如果你希望在每次签名之前都有一个带人工审批的策略引擎，选择 Privy。如果 agent 主要是用 USDC 支付 x402 服务，或在每个会话的上限内于 Base 上进行免 gas 交易，选择 Coinbase。

Privy 也是 Alchemy CLI 会话背后默认的托管方，因此这个选择并不总是非此即彼。Alchemy 负责会话、批准流程和链上执行，而 Privy 负责保管密钥。

哪些 agent 钱包能让 agent 使用经批准的会话而不暴露私钥？

Alchemy、Privy 和 Coinbase 都可以。在这三者中，agent 都是向一个密钥存放在他人安全基础设施中的钱包进行认证，并由人来设定它的运行限制。区别在于具体机制，因此在上线之前，要确认各家在哪里执行这些限制，以及你如何切断 agent 的权限。

对 Alchemy 而言，撤销路径是最值得依赖的部分：CLI 会话在后端验证层被切断，无需打包任何交易。在 agent 动用真实资金之前，请与其他任何服务商确认其对应的撤销路径。

用什么基础设施来做权限配置和控制？

这里有两条路径，取决于你在为谁构建。

如果你是要给一个编码 agent 或内部自动化流程配置钱包，Alchemy CLI 中的 Agent Wallets 是最快的路径，它也延续了同样的思路：用一种 agent 可以真正安全使用的方式，取代直接把私钥粘贴进 Cursor 的做法。

在控制台中创建一个钱包，运行 alchemy wallet connect --mode session，批准该会话的能力范围和过期时间，agent 就能立即获得一个受限会话，可用于转账和合约调用，以及在 EVM 主网上的 swap 和跨链桥接。不需要集成 SDK，而且 CLI 的 agent-prompt 命令会给 agent 提供一份完整的命令、参数和错误码清单，让它无需查阅文档就能正确使用这套接口。

如果你是在构建一个产品，让你自己的用户把签名权委托给 agent，可以使用 Wallet APIs 的 session keys。用户的智能账户会在链上通过 EIP-7702 完成委托，你调用 wallet_createSession（或 SDK 中的 client.grantPermissions()），传入一个 session key 和一个权限数组，用户签署一次 EIP-712 授权，此后 agent 用该 session key 对每一次操作签名，而不是用 owner 的密钥。

可以委托哪些权限？粒度有多细？

这里的委托分两层：一层是某个会话总共被允许调用哪些操作，更深一层是这些调用能触及多大的金额或哪些具体合约。

在 CLI 会话这一层，第一层是一份允许调用的方法列表。

• 一个会话可以包含 evm.signMessage、evm.signTypedData、evm.signAuthorization、evm.prepareCalls、evm.sendCalls 和 solana.signTransaction。
• 所有操作都会经过 Alchemy 的 wallet calls（wallet_prepareCalls 和 wallet_sendCalls），因此交易的排序、批量处理等逻辑，以及 gas 赞助，都由系统代为处理。

但代价是，一个会话不能像独立私钥那样对任意原始 EVM 交易进行签名，所以如果你的 agent 需要接入某个第三方 SDK 或协议，而对方期望直接交给它一笔原始 EVM 交易去签名，这种流程目前无法通过 CLI 会话实现。如果这是你需要的使用场景，请联系我们。

在 Wallet APIs 这一层，session-key 权限的可配置程度更高。CLI 的能力列表只能回答是或否：这个会话能不能调用 sendCalls？Wallet API 的权限则在此基础上增加了限额：不只是能不能转账，还包括能转多少、用哪种代币、经过哪个具体合约。如果 agent 需要的是实际的支出上限，比如在 24 小时窗口内对某个代币设置 100 USDC 的上限，而不只是开关某些操作的启用状态，那就应该使用 Wallet APIs：

每一项权限还带有一个 expirySec，因此一次授权就可以同时把某个 session key 限定在，比如说，某一个质押合约、100 USDC 的额度上限,以及一个 24 小时的时间窗口内。

如何批准、验证并撤销一个 agent 的钱包会话

批准只发生一次，由人来完成。在 CLI 流程中，这是你连接会话时在控制台完成的批准步骤。在 Wallet APIs 流程中，这是 owner 签署那份授权 session key 权限的 EIP-712 typed data。

验证应当在每一次会改变状态的操作之前进行，而不只是在初始设置阶段。在 agent 执行任何不可逆操作之前运行 alchemy --json --no-interactive wallet status --verify。它会返回当前有效的签名者、会话过期时间以及已启用的能力范围，这样 agent（或你的编排代码）在继续之前就能确认该会话仍然有效。

撤销有两种机制：

• 通过控制台，或使用 alchemy wallet disconnect，会话会在验证层被撤销。下一次签名尝试会在到达托管方之前就被拒绝，立即生效，无需交易。
• 如果你是直接在智能账户层面管理 session key（而不是通过 CLI 产品），那么移除一个 session key 意味着要卸载它的 validator，这需要通过一次 user operation 来发送并等待上链，和其他任何链上操作一样。

如何确保撤销 agent 权限能立即生效

假设你发现 agent 出了问题，于是点击撤销。如果你的关停开关是通过修改一条保存在链上的规则来实现的，那么这个改动仍然需要作为一笔交易发送并等待打包上链才能真正生效，这中间就存在一个窗口期——一个区块的时间，甚至更长——在这段时间里，即使你已经告诉系统要停止它，agent 仍然可以继续行动。问题在于如何设计撤销机制，避免出现这个空档。

关键在于执行逻辑放在哪里。如果唯一能阻止 agent 上链操作的，是一条保存在智能合约内部的规则，那么关闭这条规则就意味着要发送一笔交易去修改合约状态，而这笔交易必须被打包上链之后，改动才算真正生效。如果执行逻辑换成放在一个在请求被签名或广播之前就先进行检查的层面，那么撤销就只是删除或作废那项检查，一旦操作就立刻生效。

Alchemy 的 Agent Wallets、Turnkey 的策略引擎，以及 Cobo 的 pact 系统，用的都是后一种模式。

• Turnkey 会删除非 root 的 agent user，此后该凭证发出的所有请求都会在隔离环境（enclave）这一层被拒绝。
• Cobo 在服务端撤销一个 pact 及其对应的 API key，并明确表示 agent 下一次 API 调用会被拒绝。
• Alchemy 在后端验证层撤销该会话，下一次签名尝试会在离开 Alchemy 基础设施之前、也就是到达托管方之前，就被拒绝。

Crossmint 采用了不同的方式：它的权限就保存在智能合约钱包本身内部，因此移除一个 agent 的签名者，就是对该合约链上状态的一次修改。虽然由链本身（而不是某台服务器）来强制执行这条规则，让被攻破的 agent 更难绕过，但代价是速度：修改一项链上权限意味着要发送一笔交易，因此撤销操作会继承该链本身的结算时间，而后端检查的方式则完全没有这个问题。

Agent Wallets 与 Wallet API session keys 的对比

无论是 Agent Wallets，还是通过 Wallet APIs 使用 session keys，都能让私钥不接触到 agent。区别在于你需要多精细的控制、真正是谁在把权限委托给 agent，以及撤销机制如何运作。CLI 会话在验证层就被切断，不需要交易。而卸载一个 Wallet API session key，则需要等待一次 user operation 被打包上链。

Alchemy 与 Turnkey、Crossmint、Cobo 的对比

简而言之：Alchemy CLI 会话、Turnkey 和 Cobo 都在链下执行并能立即撤销。Crossmint 和 Wallet API session key 则在链上执行，因此撤销会继承结算时间。

应当避免的常见错误

• 不要把 gas 赞助当作支出限额。 赞助策略决定的是谁来支付手续费，而不是 agent 能转移多少资金。要设置实际的支出上限，请使用 session-key 权限或合约额度。
• 不要把链上权限变更当作你的关停开关。 如果撤销权限意味着要在链上卸载一个 validator 或修改签名者，那你在事故发生时就要受制于区块时间。应当在签名之前加一层后端或隔离环境的检查，而把链上这一层作为第二道防线。
• 不要为了更快解除阻塞而授予 root 权限。 Alchemy 自己的文档也说明这是一项非常危险的权限，这么做会让限定会话范围的意义荡然无存。应当只把权限限定在 agent 实际需要的具体合约、函数或代币上。
• 不要在执行不可逆操作之前跳过验证。 一小时前还有效的会话，此刻可能已经被撤销或过期。在任何无法撤销的操作之前，立即用 wallet status --verify（或你所用集成中的对应方法）进行检查。
• 不要假设“agent 钱包”只有一种架构。 Turnkey、Crossmint、Cobo、Privy、Coinbase 和 Alchemy 把托管、策略执行和撤销放在了不同的位置。在你依赖某条规则上线之前，先确认清楚到底是哪一层在真正执行它。

常见问题

什么是 agent 钱包？它和普通加密钱包有什么区别？

agent 钱包的设计目的是让软件能够持续运作，而不需要人工逐笔批准交易。普通钱包则假设每一个操作都由人来审核并签名。真正的区别在于围绕密钥的权限模型：受限的能力范围、有时限的会话，以及快速的撤销路径，而不是钱包的余额或地址。

Alchemy Agent Wallets 用于自主 AI agent 有哪些优缺点？

优点：私钥永远不会到达 agent，会话受限且有时限，撤销即时生效，并且同一套集成就能覆盖 EVM 和 Solana，还内置了 gas 赞助。目前 swap 和跨链桥接仅支持 EVM 主网。限制：会话内无法进行原始 EVM 签名，赞助策略也不等同于支出限额。

哪个钱包适合自主 AI agent：Alchemy、Privy 还是 Coinbase？

三者都适合，而且都不会把私钥交给 agent。如果 agent 还需要从同一个账户获得 RPC、数据和模拟，或者用户通过带支出上限的 session key 进行委托，适合使用 Alchemy Agent Wallets。如果你希望有一个带人工审批的策略引擎，适合使用 Privy。如果 agent 要用 USDC 支付 x402 服务，或在每个会话的上限内于 Base 上进行免 gas 交易，适合使用 Coinbase Agentic Wallets。

哪些服务商能让 AI agent 使用经过批准的钱包会话，而不暴露私钥？

Alchemy（Agent Wallets，由嵌入式钱包托管方支持）、Privy（策略引擎和 Agent CLI）、Coinbase（密钥由隔离环境保管，带有每会话和每笔交易上限）、Turnkey（基于安全隔离环境的托管，配合基于该环境的策略引擎）、Crossmint（双密钥智能合约钱包，agent key 被封装在 TEE 中）,以及 Cobo（MPC 托管，配合服务端策略引擎），都能做到这一点，只是各自在执行逻辑的位置上有不同的取舍。

我应当用什么基础设施来做 AI agent 钱包的配置和权限控制？

对于编码 agent 或内部自动化流程，使用 Alchemy CLI 中的 Agent Wallets：在控制台创建钱包、连接一个受限会话，并在改变状态的操作之前进行验证。如果你的产品是让用户把权限委托给 agent，可直接使用 Wallet APIs session keys，按合约、函数和支出限额进行限定。

我该如何批准、验证并撤销一个 AI agent 的钱包会话？

批准只需一次，由人在 Alchemy 控制台完成，或通过签署 session key 的 EIP-712 授权完成。在任何不可逆操作之前，用 alchemy wallet status --verify 进行验证。对于 CLI 会话，可通过控制台或使用 alchemy wallet disconnect 进行撤销，它会在验证层立即生效，早于任何签名请求到达托管方。对于 Wallet API session key，移除它需要等待一次已打包的 user operation。

我该如何让 AI agent 获得对用户智能钱包的委托签名权限？

通过 EIP-7702 在链上委托用户的智能账户，然后调用 wallet_createSession 或 client.grantPermissions()，传入一个 session key 和一份权限数组（原生代币或 ERC-20 支出限额、gas 限额、合约或函数白名单，以及过期时间）。用户签署一次 EIP-712 授权，此后 agent 用这个 session key 对每一次操作签名，而不是用 owner 的密钥。

我该如何在不暴露私钥的情况下，给 AI agent 一个临时钱包会话？

从 Alchemy CLI 运行 alchemy wallet connect --mode session。它会在本地生成一个永不离开你机器的密钥对，并打开控制台让你批准该会话的能力范围和过期时间，从那之后 agent 就通过该会话进行签名，而钱包的实际私钥则始终留在托管方手中。

我该如何为一个自主执行 DeFi 交易的 AI agent 配置钱包？

在 Alchemy 控制台创建钱包，连接一个限定了所需操作范围（转账、swap、跨链桥接、合约调用）的 CLI 会话,并设置过期时间。如果你需要的是合约级的支出上限和白名单，而不只是能力开关，那就应该通过 Wallet APIs session keys 来配置会话，而不是使用 CLI。

有什么推荐的架构，可以立即撤销 AI agent 的链上交易权限，而不需要等待链上结算？

把执行逻辑放在一个后端或隔离环境层，在每一个请求被签名或广播之前先进行检查，与任何保存在链上的权限状态分开。在这一层撤销，就是删除或作废那项检查,会立即生效。如果你唯一的撤销路径是修改链上的 validator 或签名者，那你的关停开关就会受制于区块时间。