沉寂一段时间后，「龙虾」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 直接控制浏览器。
难点也正出在这里。在现有交互范式下，行业很容易落入两种极端。
一种是全盘放权：把私钥，或者一枚长期有效且权限足够大的 Session Key 直接交给 Agent，由它自行判断并执行。这样的自动化体验最好，但风险也最集中。一旦遭遇提示词注入、恶意网页、环境污染，或者模型本身出现理解偏差，错误就可能沿着整个执行链传递，最后变成真实操作。
在普通互联网环境中，这种错误也许只是发错一封邮件，或者删错一个文件；放到链上，一笔错误交易往往不可逆。
另一种极端则是完全不放权。每一个操作、每一次子调用都弹出签名窗口，让用户逐一确认。安全性确实提高了，但自动化的意义也会明显下降。
如果一个 Agent 需要替用户完成一套复杂 DeFi 策略，中间包含多个步骤，而每一步都要用户拿起手机逐个 Approve，那么用户只是从「自己点按钮」变成了替 Agent 不断盖章的「人工验印机」。
换句话说，Agent 的自由度既是效率来源，也是新增风险来源。问题的核心并不在于要不要把权限交给 Agent，而在于授权粒度与验证机制是否具备动态弹性。传统权限管理往往是二元的，要么允许，要么拒绝；但 Agent 面对的任务显然更复杂。
同样是一笔交易，10 美元和 10 万美元不同；与长期使用的协议交互，和突然授权一个陌生合约不同；完成一笔用户明确要求的 Swap，和 Agent 自行决定把资产跨到另一条链，也不是同一个风险等级。
Agent 越能自主行动，权限就越不能只是一个简单开关。真正需要的是一套能让它在边界内自由行动、越界时自动停下来的安全机制。
OpenClaw 之外，行业开始讨论「可验证授权」
文章提到，OpenClaw 并没有忽视这个问题。目前它已经提供多层权限机制，例如插件可以在具体操作执行前暂停并要求用户确认；涉及主机命令时，还有独立的 Exec Approvals 和 Allowlist。
与一次性交出全部工具和权限相比，这已经向前迈出了一步。但当 Agent 真正进入支付、交易和资产管理场景，一个更细的问题会出现：允许 Agent 使用某项能力，和授权 Agent 完成某项具体行动，并不是一回事。
允许 Agent 使用浏览器，不等于允许它在任何网站购买任何东西；允许 Agent 访问邮箱，不等于允许它以用户名义给任何人发邮件；同样，允许 Agent 调用钱包，也不该等于允许它将任意金额发送到任意地址。
这意味着，Agent 时代的权限体系可能要区分两个问题：
- 能力权限：Agent 能不能使用浏览器、终端、邮箱或钱包；
- 行动授权：Agent 在某个时刻准备执行的那件事，是否真的在用户允许范围内。
真正的难点，是让 Agent 在明确边界内保持自动化效率，同时在它要越过边界时，把决定权重新交回用户。
imToken 探索 Sigil：把「你看到什么，就签署什么」落到执行层
这也是 imToken 正在探索 Sigil 的原因。文章称，Sigil 的核心并不是再给 Agent 增加一道传统意义上的「确认弹窗」，而是尝试通过可验证签名与细粒度权限控制，在用户和 Agent 之间建立一层可被明确约束的安全护栏。
其中一个关键原则是「What you see is what you sign」，也就是你看到什么，就签署什么。
按这一思路，用户可以预先授予 Agent 一定范围内的权限，让低风险、符合既定策略的行为自动完成；当操作触及资金额度、陌生协议，或者其他关键权限边界时，再暂停执行，把具体请求交还给用户确认。
而这类确认不能只停留在一句模糊提示，比如「Agent 准备执行交易，是否同意」。用户真正需要看到的是这笔操作里实际变化的关键参数，包括使用什么资产、金额是多少、交互对象是谁，以及最终准备执行什么动作。
只有当用户看到的内容、授权的内容和系统最终执行的内容能够一一对应，一次确认才有实际意义。
围绕这一点，Sigil 还尝试引入 Passkey、生物识别、单次签名、短有效期以及请求参数绑定等机制。文章给出的方向是，让关键授权不仅能被用户理解，也能被系统验证。
在这种设计下，一份授权不只是「有人点了确认」，还可以继续回答几个问题：谁批准了、批准了什么，以及最后真正执行的，是不是当时看到的那件事。
从这个角度看，Sigil 想解决的不是怎样让 Agent 少做一些事。相反，它想解决的是：在不拿走用户最终控制权的前提下，怎样让 Agent 可以放心地多做一些事。
钱包的角色变化：从管理资产到管理 Agent
如果把视角再往后拉一步，这也是钱包正在面对的一次角色变化。
文章称，自以太坊诞生以来，imToken 钱包亲身经历并见证了两个关键阶段：从管理单一私钥的 1.0 时代，演进到通过账户抽象（AA）优化交互体验的 2.0 时代。
随着 OpenClaw 2.0 等自主 Agent 普及，钱包正在进入第三代演进，需要继续帮助用户管理一个个会自主判断、持续工作的 Agent。
这也是为什么钱包行业过去积累的私钥管理、数字签名、身份认证与权限隔离能力，可能会在 Agent 时代获得新的意义。因为这些技术表面上解决的是「怎样安全地签一笔链上交易」，背后处理的其实是一个更普遍的问题：如何证明一项行动，确实获得了某个主体的真实授权。
今天，这项行动可能是转出 1 ETH；未来，也可能是发送一封邮件、修改一份文件、使用某个数字身份、购买一项服务，或者允许 Agent 在未来一周持续执行某套自动化策略。
这些行为未必都发生在区块链上，但底层关系相似：Agent 正在以用户名义调用一种属于用户的能力。
因此，文章认为，Sigil 的意义未必只局限于 Crypto。
当 OpenClaw、Hermes 以及更多运行在个人设备或云端环境中的 Agent，逐渐连接邮件、即时通信、日历、文件、浏览器、终端和支付工具后，「如何证明这一次行动确实经过用户授权」会变成越来越普遍的问题。
在这个方向上，Sigil 未来也可能从链上交易延展到数据访问、身份使用、文件修改、内容发布、服务购买以及自动化任务。
按文中表述，作为 imToken 与 OpenClaw 的共同探索，Sigil 试图把 imToken 过去十年在自托管、钱包和数字签名领域积累的经验，带入自主 Agent 开始进入真实执行环境的新阶段。
它不替代 Agent，也不取代钱包，而是站在二者之间。