Cloudflare Agents Week 把一个问题推到了前台：当 AI agent 不只是回答问题，而是能调用工具、购买服务、部署资源、触发工作流时，它到底应该以什么身份行动？
Agent Wallets 这类发布容易被误读成“给 agent 一个加密钱包”。这只是最表层的形式。更重要的问题是代理身份层：一个非人类执行体如何被授权、如何被限制、如何留下可审计记录、如何在事故后撤销权限。
过去的 SaaS 系统通常只有两类主体：用户和服务账号。AI agent 介于两者之间。它代表用户意图，但不是用户本人；它能自动行动，但又不像传统服务账号那样只执行固定逻辑。这个混合身份会挑战现有权限模型。
为什么用户账号不够
最简单的做法是让 agent 使用用户的 token。很多早期集成就是这样：用户 OAuth 授权后，agent 拿到访问令牌，然后替用户操作 Gmail、GitHub、Notion、Stripe 或云平台。
这个做法上线很快，但问题明显。
第一，权限过大。用户 token 往往可以执行很多操作，而 agent 当前任务只需要其中一小部分。
第二，责任混淆。日志里看起来是用户操作，但真实执行者是模型和工具链。
第三，撤销困难。用户可以撤销整个应用授权，却很难只撤销某个任务、某个 agent 或某次会话。
第四，预算缺失。用户账号没有天然表达“这次任务最多花 10 美元、最多创建 2 个资源、只允许访问这个项目”的能力。
第五，审计粒度不够。传统审计日志记录 API 调用，却不一定记录 agent 的自然语言意图、模型输出、工具参数和确认步骤。
Agent Wallets 的意义，就是让这些问题不能再被绕过去。只要 agent 能花钱，权限模型就必须变得更精细。
钱包只是 capability 的一种
开发者应该把钱包理解为 capability，而不是账户余额容器。Capability 的核心是“被授予的有限能力”。
一个 agent capability token 至少应该描述：
- 代表谁：用户、组织、项目还是服务账号。
- 做什么：可调用哪些工具和 API。
- 在哪里做：限定资源范围、区域、仓库、数据库或商户。
- 花多少：金额、次数、token、时间或资源额度。
- 到什么时候：过期时间和会话边界。
- 如何确认：哪些动作需要人类二次确认。
- 如何撤销：撤销后是否立即停止正在运行的任务。
钱包能力只是其中之一。它可以是“允许购买不超过 5 美元的 API credit”，也可以是“允许为这个部署任务支付一次域名验证费用”。如果 agent 拿到的是无限钱包，那不是 agent wallet，而是把用户银行卡交给随机自动化脚本。
一个更合理的身份模型
可以把 agent 身份分成四层。
第一层是 human principal，也就是授权的人或组织。
第二层是 agent instance，也就是某次具体任务运行。它有唯一 ID、模型版本、工具集合和开始时间。
第三层是 capability grants，也就是这次运行被授予的有限能力。
第四层是 action ledger，也就是实际工具调用、支付、写入和外部副作用记录。
结构化来看：
{
"humanPrincipal": "user_123",
"agentInstance": "agent_run_789",
"purpose": "renew staging database backup storage",
"capabilities": [
{
"tool": "billing.purchase_credit",
"limitUsd": 20,
"expiresAt": "2026-08-14T12:00:00Z",
"requiresConfirmationAboveUsd": 5
},
{
"tool": "cloudflare.kv.write",
"resourcePrefix": "staging/",
"maxWrites": 3
}
]
}这个结构比普通 API key 更接近 agent 需求。它把“谁”“为了什么”“能做什么”“最多做到哪里”放在同一个对象里。
Agent Wallets 会改变支付接口设计
传统支付接口假设调用方是人或服务器。人会看确认页，服务器会执行确定逻辑。Agent 则不同：它可能根据模型判断选择商品、服务、资源规格和付款时机。
因此，支付接口需要多出几类字段。
第一是 intent。支付不是孤立动作，必须记录自然语言任务和结构化目的。例如“为本次测试购买 10 美元推理额度”。
第二是 quote。agent 不应该直接付款，它应该先拿报价，再由策略判断是否允许。
第三是 policy result。系统要记录这次付款为什么被允许，是低于额度、命中白名单，还是经过人工确认。
第四是 revocation path。如果购买的是可撤销资源，例如订阅、云资源、临时 token，应记录如何自动清理。
一个 agent 支付流程应类似：
agent requests quote
-> policy engine checks capability
-> user confirmation if needed
-> payment executes
-> ledger records purpose and receipt
-> cleanup policy schedules review这比传统 checkout 更繁琐，但 agent 场景必须这样做。因为模型可能误解任务，也可能被 prompt injection 引导去购买不需要的东西。
安全边界：不要让模型持有秘密
一个常见错误是把 API key、wallet key 或 session token 放进模型上下文，让模型“自己决定怎么用”。这在安全上很糟糕。
模型应该只输出意图和参数，真正的签名、付款和 API 调用应该由受控工具层完成。模型不需要知道私钥，也不需要知道完整访问令牌。它只需要知道“有一个 purchaseCredit 工具，可在策略允许时购买额度”。
工具层需要做这些检查：
- 参数 schema 校验。
- capability 匹配。
- 金额和频率限制。
- 商户或资源白名单。
- 风险动作二次确认。
- 幂等键。
- 审计日志写入。
这样即使模型被诱导输出危险参数，工具层也能拦住。Agent Wallets 的安全性不应建立在“模型不会犯错”上，而应建立在“模型犯错时系统不会执行越权动作”上。
审计日志要记录意图
普通审计日志常常记录“POST /payments 200”。这对 agent 事故调查不够。你需要知道模型为什么付款、基于什么证据、用户授予了什么能力、策略引擎如何判断。
一个合格的 action ledger 至少包含：
- agent run id。
- human principal。
- capability id。
- model name 和版本。
- natural language intent。
- tool name。
- sanitized args。
- policy decision。
- external receipt。
- rollback 或 cleanup 状态。
这不是为了合规好看，而是为了事故时能回答三个问题：谁授权的，agent 为什么这么做，系统为什么允许执行。
对开发者的落地建议
第一，不要等钱包功能上线才设计身份层。现在就把 agent run id、tool call id、user principal 和 capability grant 分开。
第二，把预算对象变成一等公民。预算不只是 token 成本，也包括金额、写入次数、资源创建数、邮件发送数和外部 API 调用数。
第三，所有外部副作用都要幂等。agent 重试时不能重复付款、重复部署或重复发邮件。
第四，高风险动作默认需要确认。金额可以低到 1 美元，确认门槛不应只看金额，还要看不可逆程度。
第五，设计撤销和冻结机制。用户点击停止后，正在运行的 agent 应该失去 capability，而不是等当前循环自然结束。
长期影响
Agent Wallets 指向的不是一个单点产品，而是一套新的 Web 基础设施。未来网站可能不只区分 human user 和 bot，还会区分不同等级的 delegated agent：只读 agent、可写 agent、可支付 agent、组织内部 agent、第三方托管 agent。
这会影响登录、OAuth、API 设计、风控、账单、审计和客服。今天很多系统的权限模型还停留在“用户授权应用”，但 agent 时代需要“用户授权某个 agent 在某个任务里做某些事”。
结论
Cloudflare Agent Wallets 真正暴露的问题，是 agent 缺少标准身份层。钱包让这个问题更紧迫，因为一旦 agent 能花钱，错误就会从体验问题变成经济损失。
开发者现在最应该做的，不是急着给 agent 接钱包，而是把身份、权限、预算和审计从模型调用里拆出来。模型负责理解和建议，工具层负责执行和限制，策略层负责授权和拒绝，账本负责留下证据。只有这个边界清楚，agent 才能从 demo 走向生产。