放权还是失控？Agent 自主时代，我们需要怎样的「可验证授权」？
核心要点
- 与此同时，它也把行业带向了一个绕不开的信任困境：当 Agent 越来越能够自主决定「怎么做」，我们又该如何确保，它的每一次关键操作，都没有越过用户真正授权的边界？
- 但当 Agent 真正进入支付、交易和资产管理场景，一个更细的问题随之出现：允许 Agent 使用某项能力，和授权 Agent 完成某项具
如何在不牺牲自动化的前提下，让每一次关键行动，仍然落在用户真正授权的范围内？
沉寂了一段时间的「龙虾」OpenClaw，在 8 月 30 日发布了 2.0 版本。
按照官方的说法，这是 OpenClaw 历史上规模最大的一次更新，累计超过 1.6 万个 Pull Request，几乎触及安装、消息、记忆、Skills、模型、Automations、浏览器、原生应用、Plugins 与安全机制等整个产品栈。
但相比这些庞杂的功能列表，更值得关注的，其实是 OpenClaw 2.0 背后那条越来越清晰的演进路线：Agent 正变得越来越能真正「动手做事」。
与此同时，它也把行业带向了一个绕不开的信任困境：当 Agent 越来越能够自主决定「怎么做」，我们又该如何确保，它的每一次关键操作，都没有越过用户真正授权的边界？
一、Agent 自主权的两难：全盘放权，还是层层确认？
过去一年，AI Agent 最明显的变化，并不只是底层模型变聪明了。
随着 MCP、Skills、Plugins、浏览器控制和代码执行等基础设施逐渐成熟，Agent 开始拥有越来越多真正能够影响外部世界的「手脚」，譬如修改信息，点击按钮，或者通过 computer use 直接控制浏览器（延伸阅读《Agentic AI 拐点已至？当 AI 学会「自己行动」，如何重构 Web3 的安全边界？》）。
但问题也恰恰出现在这里，在现有的交互范式下，往往容易陷入两种极端。
一种是全盘放权，直接把私钥，或者一枚长期有效、权限足够大的 Session Key 交给 Agent，让它自行判断执行。
这种模式的自动化体验当然最好，但风险同样非常集中，一旦遭遇提示词注入、恶意网页或环境污染，又或者模型自身出现理解偏差，错误就可能沿着整个执行链一路传递，最终变成真实操作（延伸阅读《Sign 不只签名：当 AI Agent 替你签名，谁还握着控制权？》）。
毕竟在普通互联网场景，这可能只是发错一封邮件、删错一个文件，但到了链上，一笔错误交易却往往不可逆。
另一种则是完全不放权，每一个操作、每一次子调用都弹出签名窗口请求确认，安全性是提高了，但自动化的意义也随之大幅下降。
毕竟一个 Agent 帮用户完成一套复杂 DeFi 策略，中间涉及多个步骤，如果都需要用户拿起手机逐个「Approve」，那用户实际上只是从「自己点按钮」，变成了替 Agent 不断盖章的「人工验印机」。
换句话说，中间的自由度，既是 Agent 提高效率的来源，也是新的风险来源。
从这个角度看，问题的核心并不在于「要不要放权给 Agent」，而在于授权的粒度与验证机制是否具备动态弹性，因为传统的权限管理是二元的（要么允许，要么拒绝），而 Agent 面对的任务显然复杂得多。
同样是一笔交易，10 美元和 10 万美元不同；与长期使用的协议交互，和突然授权一个陌生合约不同；完成一笔用户明确要求的 Swap，和 Agent 自行决定把资产跨到另一条链，也不是同一个风险等级。
所以说，Agent 越能自主行动，权限就越不能只是一个简单的开关。
真正需要的，是一套能够让它在边界以内自由行动，越过边界时自动停下来的安全机制。
二、如何为自主 Agent 构建一条「可验证」防线？
事实上，OpenClaw 并没有忽视这个问题。
目前它提供了多层权限机制，譬如插件可以在具体操作执行前暂停并要求用户确认，涉及主机命令时，则还有独立的 Exec Approvals 和 Allowlist 等等。
相比把所有工具和权限一次性交给 Agent，这已经向前走了一大步。但当 Agent 真正进入支付、交易和资产管理场景，一个更细的问题随之出现：允许 Agent 使用某项能力，和授权 Agent 完成某项具体行动，其实不是一回事。
就像允许 Agent 使用浏览器，并不意味着允许它在任何网站购买任何东西；允许 Agent 访问邮箱，也不等于允许它以你的名义给任何人发送邮件；同样，允许 Agent 调用钱包，也绝不应该等于允许它将任意金额发送至任意地址。
所以，Agent 时代的权限体系可能需要区分两个不同的问题。一个是能力权限，即 Agent 能不能使用浏览器、终端、邮件或者钱包？另一个则是更具体的行动授权，像在这一刻，它准备执行的这件事，究竟是不是用户真正允许它做的？
那如何让 Agent 在明确的边界内充分自动化，同时在真正越过边界的时候，把决定权重新交回用户？
这也是 imToken 正在探索 Sigil 的原因。它的核心并不是给 Agent 再增加一道传统意义上的「确认弹窗」，而是尝试通过可验证签名与细粒度权限控制，在用户和 Agent 之间建立一层可以被明确约束的安全护栏。
其中一个很重要的原则就是「What you see is what you sign」，你看到什么，就签署什么。
简单来说，用户可以预先授予 Agent 一定范围的权限，让低风险、符合既定策略的行为自动完成；当操作触及资金额度、陌生协议或者其他关键权限边界时，再暂停执行，把具体请求交还给用户确认。
更重要的是，这种确认并不应该只是一句模糊的「Agent 准备执行交易，是否同意」，用户真正需要看到的，是这笔操作里实际发生变化的关键参数：使用什么资产、金额是多少、交互对象是谁，以及最终究竟准备执行什么。
因为只有当用户看到的内容、用户授权的内容和系统最后执行的内容能够对应起来，一次确认才真正具有意义。
Sigil 围绕这一点，还尝试使用 Passkey、生物识别、单次签名、短有效期以及请求参数绑定等机制，让关键授权不仅可以被用户理解，也能够被系统验证。
这意味着，一份授权不只是「有人点了确认」，而是可以进一步回答谁批准了、批准了什么，以及最后真正执行的，是不是当时看到的那件事。
从这个角度看，Sigil 真正想解决的并不是「如何让 Agent 少做一些事」。
恰恰相反。
它试图解决的是，怎样让 Agent 在不拿走用户最终控制权的情况下，可以放心地多做一些事（延伸阅读《从盲目点「Yes」，到看清再签名：Sigil 如何为 AI Agent 加上一道安全护栏？》）。
三、从管理资产到管理 Agent
如果把视角再往后拉一步，会发现这其实也是钱包正在面对的一次角色变化。
自以太坊诞生以来，imToken 钱包亲身经历并见证两个关键世代：从管理单一私钥的 1.0 时代，演进到通过账户抽象（AA）优化交互体验的 2.0 时代。
随着 OpenClaw 2.0 等自主 Agent 的普及，钱包无疑正步入第三代演进，需要进一步帮助用户管理一个个会自主判断、持续工作的 Agent。