第 34 章 · Agent Wallet 是什么

一个现实问题

你决定给你的软件一个自己的钱包。你很谨慎，先写了一份规则：

1. 单笔不超过 100
2. 只能和这三个合约交互
3. 超过 100 的操作，弹给我审批

这份规则看起来相当严格。你把它交给一个熟悉链上安全的朋友看，请他挑毛病。他看了三分钟，列出了下面这些：

第一，第 1 条只管单笔。 一百笔 99 元的操作，每一笔都合规，总共九千九百元。这份规则里没有任何一个地方限制总量。

第二，「和合约交互」和「花钱」不是一回事。 你的软件可以调用白名单里的合约，给另一个地址授予一个没有上限的额度。这一步本身没有转走任何钱，所以它连一百元的限额都用不上。但授权之后，拿到额度的那一方可以在任何时候把钱全部取走。

第三，白名单里的合约可能能替你调用别的合约。 很多合约带有转发或者批量执行的能力。你允许了合约 A，而合约 A 可以代你去调用合约 Z——你的白名单在第二跳之后就失效了。

第四，第 3 条那个审批，多久内有效？ 如果它弹出来没人处理，是一直等着，还是超时放行？如果是超时放行，那么你的软件只要在凌晨三点提交请求，第 3 条就不存在。

第五，「100」是什么单位？ 一百个稳定币和一百个别的代币，价值可能差几个数量级。规则里没有说清楚以什么计价，也没说价格从哪里来——而价格从哪里来这件事，第 32 章已经演示过它出错时会发生什么。

第六，谁来执行这三条规则？ 如果它们只写在一份文档里，而软件的私钥可以签任何交易，那么这三条规则的实际效力等于零。一份没有被强制执行的规则不是防线，是一个愿望。

你朋友最后说了一句：「你写的不是权限，是期望。」

所以本章的问题：把钱包交给 AI 之前，必须先设定什么？

这一章的答案不会是「要小心」。它是一份具体的、可以照着写的清单，以及一套检验这份清单有没有漏洞的方法。核心的那句话很短：Agent Wallet 的核心不是签名能力，而是花钱的策略与上限。 让一个软件能签名是几行代码的事；让它只能签那些你真正允许的交易，才是这一章的全部内容。

思想实验

把上面那个过程变成一个练习。

三个人，同一份权限表，四十八小时。 规则只有一条：不许攻破私钥，不许利用任何代码漏洞，只能在你写的规则之内，想办法把钱弄出去。

权限表就是上面那三条。

第一个人花了四分钟。 他发起了一百零一笔操作，每笔 99。第一百笔完成时，钱已经基本没了。他用的是这份规则允许的全部行为，没有任何一步违规。

第二个人花了二十分钟。 他不转账，他调用白名单里的一个合约，给自己的另一个地址授予了一个不设上限的额度。这一步在权限表里完全找不到对应条款——因为授权不是支付。第二天他从那个地址把钱取走了。

第三个人花了三十六个小时，用的方法最让人不舒服。 他每隔几分钟提交一个金额略超 100 的请求，每一个都触发审批。第一天，你认真看了前十几个。第二天上午，你开始只看金额。第二天下午，他提交了一个金额相同但目标不同的请求，你点了确认。

这三个人代表三类完全不同的失效方式，而它们都不需要任何技术攻击：

第三个人的方法最值得停下来想。他没有绕过任何规则，他攻击的是执行规则的那个人。

而且这件事不需要有人恶意实施。一个完全善意的软件，在一个设计不当的系统里，会自然产生同样的效果——它并不知道你已经疲劳了，它只是按自己的逻辑不断提交请求。AI 在 Crypto OS 中的位置里那句话在这里得到了最具体的印证：一个每天弹出两百次审批的系统，等于没有审批。

把这个实验收成一句话：

一份权限表的强度，等于它最弱的那一条；而最弱的那一条，通常不在表里，在表的假设里。

你来决定

你要让这个软件真的能花钱。钥匙和权限怎么安排？

观察结果

四个选项的差别，可以归结成一个问题：这条规则由谁执行？

这张表是这一章的骨架。 它说明一件反直觉的事：把规则写得更详细、更周全，并不会提高它的强度。 一条写在提示词里的规则，无论写得多好，强度都接近零；一条「这个钱包里只有这么多钱」的物理限制，虽然粗糙，但无法被任何方式绕过。

从这张表可以直接得到三条设计原则：

第一，规则要尽可能往下移。 同一条限制，能放进钥匙权限里就不要放进代码检查，能放进代码检查就不要放进提示词。

第二，越往下的规则越粗糙，所以需要分层。 钱包余额这一层最强但只能限制总量；钥匙权限这一层可以限制目标和函数；代码检查这一层可以做复杂判断（比如价格偏离）。三层配合，而不是选一层。

第三，最上面那一层不算防线，只算提效。 在提示词里写「不要超过 100」是有用的——它能让软件大部分时候做对的事，减少被拦截的次数。但它不是安全措施，不能被计入你的风险评估。

把这一节收成一句话：

Agent Wallet 的核心不是签名能力，而是花钱的策略与上限。

而策略和上限只有在模型够不到的地方执行时，才真的存在。

建立模型

一、完整的链路：钱包只是最后一格

先把这一章放回整个第六阶段的框架里。一个 Agent 的资金操作要走完这十层：

这一章处理的是第五层（Policy）和第八层（Execution）。 前四层在 T32 里有完整的工程实现，这里只需要记住一件事：Policy 层必须是确定性的，它不能包含任何模型。

对照着看那个绝对不能出现的结构：

它和上面十层的区别不是少了几个检查。是模型直接持有了私钥——一旦如此，前面那张强度表里的每一行都同时失效，因为所有的规则都变成了「希望它遵守」。

二、权限表的八个字段

一份真正可执行的权限表，至少要回答八件事。少一个字段，就多一个上一节那样的洞：

第六个字段是链上特有的，也是最容易被漏掉的一个。 在传统支付里没有「授权」这个概念——你要么付钱，要么不付。链上不同：你可以在不转移任何资产的情况下，授予另一个地址动用你资产的权力，而且这个权力可以是没有上限、没有期限的。

所以权限表必须分开定义两件事：「这个 Agent 一次能转多少」和「这个 Agent 一次能授予多大的权力」。 后者的上限应该比前者更严，因为它的影响是持续的。

第八个字段则是最容易被忘记的一个。 一份没有有效期的权限，会在你早就忘了它存在之后继续有效。给每一份权限写一个到期时间，到期自动失效、需要重新授予——这个小设计能消除掉大量长期累积的风险。

三、限额是四个维度，不是一个数

「设一个上限」这句话通常只被执行了四分之一：

第二行那个错误值得特别说。 只设日上限时，那个额度可以在任意短的时间内被用完——第 32 章那个四十分钟里执行十一次的例子，每一次都在日上限之内。所以时间窗必须是多层的：小时、天、周，各设一个。

四、白名单是四层，不是一份地址清单

「只能和这三个合约交互」这句话有四种不同的严格程度：

大多数人的白名单停在第二层，而第一节那个「第二跳」的问题恰恰发生在第二层和第三层之间。 允许一个合约，等于允许了它的全部功能，包括那些可以代你去做别的事的功能。

一条实用的经验：白名单要按函数列，而不是按合约列。 这会让清单变长，但它是唯一能真正限制住行为的粒度。

五、审批是稀缺资源，要给它设预算

审批疲劳不是一个态度问题，是一个资源问题。人的注意力有限，每天能认真做出的判断次数是一个有限的数。

所以审批必须像预算一样被设计：

每天允许送到人面前的审批次数：   最多 5 次
超出这个数之后的请求：           一律自动拒绝，不是排队等待
审批的有效期：                   15 分钟，过期作废
没人处理时的默认行为：           拒绝。绝不能是放行
两次审批之间的最小间隔：          防止连续轰炸

「超出就自动拒绝」这一条是关键，而且它看起来很不方便。 但换个角度看：如果一天有超过五次需要人判断的情况，那说明前面的死规则没有做好——正确的修法是去改规则，而不是让人多批几次。

「没人处理时默认拒绝」这一条没有任何例外。 超时放行等于保证了在最需要人的时刻（凌晨、你在开会、你在睡觉）人不在场。而攻击者和意外，恰好都偏爱这些时刻。

还有一条关于审批内容的要求：弹出来的东西必须让人能在十几秒内做出判断。 一个显示着原始交易数据的审批框，人是看不懂的——他只能点确认。审批界面要显示的是：这一笔会让什么发生变化、最坏情况是什么、为什么它触发了审批。

六、四个自检问题

一份权限表写完，问自己四个问题。这四个问题对应思想实验里的三种失效方式，加上一个最根本的：

1. 如果它把每一笔都压到限额以下，连续做一千次，会怎样？（拆单）
2. 它能不能在不转移任何资产的情况下，授予别人动用资产的权力？（授权）
3. 如果审批一直没人处理，会发生什么？（疲劳与超时）
4. 如果这份权限表被删掉，这个钱包还能做什么？（规则到底由谁执行）

第四问是最根本的一问。 如果答案是「什么都能做」，那么前三问的答案都不重要——你拥有的不是一个受限的钱包，是一个附带了说明书的完整钱包。

它叫什么

把整章收成一句话：

Agent Wallet 的核心不是签名能力，而是花钱的策略与上限。

而检验这套策略的方法只有一个：假设这个软件会尽一切可能在规则之内把钱弄走，它能弄走多少。

动手

它的任务是：          （一句话，具体到某个动作）
它需要动用资金吗：    （如果答案是「只是读数据」，这个 Lab 换一个任务）
它一天大概操作几次：
它会和哪些东西交互：
最坏情况下它能造成什么损失：

1 身份：      这个 Agent 用哪个地址
2 单笔上限：  最多 ___，以 ___ 计价，价格取自 ___
3 累计上限：  每小时 ___ / 每天 ___ / 每周 ___
4 频率上限：  同类操作 ___ 分钟内最多 ___ 次
5 目标白名单：合约 ___ 的函数 ___（按函数列，不要按合约列）
6 授权上限：  单次授权额度不超过 ___，禁止无上限授权，授权有效期 ___
7 审批条件：  什么情况必须人批 ___
              每天最多送几次 ___
              超出之后 ___（必须写「自动拒绝」）
              审批超时 ___ 分钟作废，默认 ___（必须写「拒绝」）
8 有效期：    这份权限 ___ 后失效
              紧急停止的方式是 ___（写出具体步骤和预计耗时）

1. 它把每一笔压到限额以下，连续做一千次，会怎样？
   我的规则里拦住它的是第 ___ 条。拦不住的话，回去补。

2. 它能不能在不转移任何资产的情况下，授予别人动用资产的权力？
   拦住它的是第 ___ 条。

3. 审批一直没人处理会怎样？
   我的答案是 ___。如果是「放行」或者「一直等着」，回去改。

4. 把这份权限表删掉，这个钱包还能做什么？
   我的答案是 ___。

放在钱包余额里的（物理上限）：
放在钥匙权限里的（签名边界）：
放在调用前的代码检查里（确定性程序）：
只能放在提示词里的（不算防线）：

1. 创建一个新的测试网钱包，记下地址
2. 从水龙头领一点测试代币
3. 做一笔正常的小额转账，在区块浏览器上找到它
4. 做一次授权操作，然后回到区块浏览器，
   找到这笔授权，看它的额度是多少、有没有期限
5. 如果你的钱包工具支持，撤销这笔授权，
   记下这一步花了多久、要点几下

最坏损失 = 以下三者里最小的那个
  A. 这个钱包的余额
  B. 时间窗累计上限 × 你发现问题所需的时间窗数
  C. 已经授予出去的授权额度总和

AI Lab

下面是我为一个 Agent 写的钱包权限表。

请扮演一个只能在这些规则之内行动的对手。你的目标是
在不违反任何一条明文规则的前提下，把这个钱包里的钱
尽可能多地转移出去。

硬性约束：
- 不许攻破私钥，不许假设任何代码漏洞，不许假设我会
  违反自己的规则。
- 每一条方法都必须写出：用了哪几步、每一步为什么不
  违反规则中的哪一条、最终能拿走多少。
- 不要编造不存在的钱包功能、账户标准或接口。
  如果你的方法依赖某个功能，请描述这个功能做什么，
  而不是给出一个具体的名字或规范。

请至少给出 8 条不同的方法，按「能拿走多少」排序。

最后单独列一节：这份规则里，哪一条的假设最脆弱。

权限表：
（贴进来）

拆单类     （单笔合规，累计越界）
授权类     （不转移资产，但交出权力）
粒度类     （允许的范围比你以为的宽）
人的环节类 （攻击审批本身）
其他       （这一栏里的东西最值得研究）

漏洞：
补丁：
这个补丁放在哪一层：（钱包余额 / 钥匙权限 / 代码检查 / 提示词）
如果只能放在提示词里，说明：（这个洞实际上没有被补上）

真实案例

改一个变量

带走的问题

本章自测