Coinbase 给 AI Agent 开了一个独立账户，背后藏着三个关于授权设计的新思路

让读者真正能用上的「Agent 账户」，到底应该怎么设计？

账户，而不是插件

2026 年 6 月 11 日，Coinbase 正式发布 Coinbase for Agents。1

乍看之下，这像是又一个「AI 接管你的账号」的演示——毕竟过去一年，各家公司都在说「让 AI 帮你做事」。但仔细看产品细节，Coinbase 做了一个在这个赛道里少有人明确提出的设计决策：给 Agent 一个独立账户，而不是共享权限。

具体来说，用户可以选择两种接入方式：

把 Agent 接入主账户，赋予它一定操作权限
或者，在主账户之外单独开一个「Agent 账户」，彼此隔离、互不可见

这个「隔离沙箱」选项听起来只是一个安全功能，但它实际上改变了一件更根本的事：Agent 的操作范围从「用户授权的一切」收缩成「用户主动划定的边界内」。

主账户模式下，Agent 理论上能看到你的所有持仓、历史记录、资产结构。沙箱模式下，Agent 只知道它被分配到的那一小块：你给它充了多少钱，它就只能在这个范围内动作。这不是用户体验的细节优化，而是一种信任架构的根本分叉。2

Coinbase for Agents 产品页主视觉，展示 AI Agent 通过账户执行交易的界面示意图 — Coinbase 官方博客配图：产品页主视觉 1

跟 Mastercard 上周发布的 Agent Pay for Machines（AP4M）比较很有趣：AP4M 解决的是「Agent 如何在不同系统之间携带可验证意图」的问题，偏向底层基础设施；Coinbase for Agents 解决的是「Agent 在用户自己的账户里能做什么、不能做什么」，偏向用户侧的权限设计。两者是不同层次上的不同问题，并不重叠。

x402 协议：一个被遗忘的 HTTP 状态码，和一个真实的支付悖论

在这个产品里，有一个技术设计值得单独拆一下——x402 协议。

背景：HTTP 协议里有一个状态码叫 402 Payment Required，创立于 1991 年，设计初衷是「将来某天用于数字支付」，但三十年里没有人真的把它用起来。2025 年，Coinbase 联合 AWS、Anthropic、Circle 等公司把这个状态码激活了，作为 Agent 支付的开放标准。3

x402 的运作逻辑很直接：

Agent 请求一个付费资源（比如某数据 API）
服务器返回 402 Payment Required 状态码，附带支付要求
Agent 自动用 USDC 在 Base 链上完成支付，重新发起请求
数据返回

整个流程无需登录、无需订阅、无需人工干预。对 Agent 来说，「访问付费内容」变成了和「访问免费内容」在体验上几乎一样的事。

这解决了一个 Agent 时代真实存在的结构性矛盾：订阅制是为人设计的。一个月 $29 的数据 API 订阅，假设 Agent 一个月只用三次，每次调用实际成本应该是几美分；但现有的订阅制要求你先付 $29，而且需要你去登录、绑定支付、维护账号。这对 Agent 来说是一种「产品形态不匹配」。

x402 把订阅制的门槛拆成了按调用付费的微支付，同时保持了原生的 HTTP 语义——服务方不需要改变接口设计，Agent 侧不需要维护账号体系。截至 2026 年一季度，x402 协议已累计处理超过 1.6 亿笔交易，其中超过 90% 在 Base 链上完成。2

Loading content card…

「礼品卡」模型：授权设计的新比喻

Coinbase 官方博客里有一句话，值得仔细看：「把它想成给 Agent 一张礼品卡，而不是把你的银行账号交出去。你定规则，Agent 在边界内执行。」1

「礼品卡」是个好比喻，因为它把一个关于自主性的技术问题，翻译成了用户可以直觉理解的权限模型：

礼品卡模型	传统「账号授权」模型
用户主动限定可动用资金上限	Agent 共享账户余额
Agent 看不到用户的其他资产	Agent 有账户级可见性
越权操作在系统层面被物理阻断	越权依赖 Agent 自我约束
合规检查在账户层天然内置	合规依赖事后审计

这个设计背后有一个值得思考的产品哲学：自主性和可控性并不是零和关系。

过去一年，Agent 产品的一个常见卡点是「用户不敢给」。不是不想用 Agent，而是不知道给了权限之后会发生什么、能不能收回来、损失怎么定责。Coinbase 的做法是把这个问题从「运行时靠 Agent 自律」转移到「设计时把边界刻进账户结构」——不是要求 Agent 变得更值得信任，而是要求产品在信任建立之前就给用户可控的损失上限。

「即将支持」的功能列表里，Coinbase 明确写了：最大单笔交易额、Agent 可以访问哪些服务、总支出上限。这些都是控制参数，不是 Agent 的能力参数。从产品架构角度看，这是在说：Agent 的能力边界由工程决定，但 Agent 的权限边界由用户决定。

这和近期另外几个 Agent 支付产品的设计取向形成对比。Visa 本周和 OpenAI 达成合作4、Visa 此前投资 Replit，都更偏向「让 Agent 能到达更多支付场景」；Coinbase 的这个方向则更偏向「让 Agent 在用户划定的范围里更深度地执行」。两个方向都有意义，但用户感知到的信任建立路径是不同的。

一个值得关注的监管背景：金融稳定委员会（FSB）在 6 月 10 日——也就是 Coinbase for Agents 发布前一天——发布声明，呼吁对金融领域 AI Agent 建立强力安全机制。4 Coinbase 的这个发布时机，无论是不是刻意的，都在对话这个监管信号——内置合规检查、物理边界隔离、用户定义支出上限，都是在用产品设计回答监管的担忧。

给产品设计者的三条可迁移观察

Coinbase for Agents 的具体实现离大多数产品设计者的日常工作有距离，但它处理的那些问题——Agent 的权限边界怎么设计、用户如何建立对 Agent 的信任、自主性和可控性如何共存——在接下来几年会变得高度普遍。

三条可以直接搬走的观察：

第一，隔离比限制更好建立信任。 「Agent 只能操作这个账户」比「Agent 被设置为不会越权」对用户来说更可信。前者是结构性保证，后者是行为性承诺。设计 Agent 产品时，优先考虑能通过架构而非规则实现的约束。

第二，微支付让 Agent 能访问的信息宇宙指数级扩大。 x402 这类按调用付费的协议，从根本上改变了什么样的数据源对 Agent 来说是「可经济可行地访问」的。产品经理在规划 Agent 的信息获取路径时，要开始把这类协议纳入考虑——不是每个数据源都需要订阅制。

第三，「礼品卡」是目前为止最好的授权 UI 比喻。 用户不理解「权限」，但用户理解「这张卡里有多少钱、能干什么」。如果你在设计需要用户授权 Agent 执行操作的产品，考虑用这个比喻框架来设计用户界面和用户教育——把权限做成一个可视化的「资源边界」，而不是一个「授权开关」。

Coinbase 给 AI Agent 开了一个独立账户，背后藏着三个关于授权设计的新思路

账户，而不是插件

x402 协议：一个被遗忘的 HTTP 状态码，和一个真实的支付悖论

「礼品卡」模型：授权设计的新比喻

给产品设计者的三条可迁移观察

References