想象一下，未来你只需要告诉 AI Agent：「帮我把钱包中一半的可用资金，都加仓 ETH」。
Agent 随即开始读取余额、搜索流动性池子、比较报价并构建交易路径，几十秒后，它向你发来一条消息：「找到了合适的买入方案，是否确认？」
你回复了一个「Yes」。
但就在这一刻，你究竟批准了什么？它选择了哪个交易池，预计成交价格和滑点是多少，调用了什么协议，使用哪个钱包和多少资产，又是否包含代币授权或其他附加操作？这些信息你都没有真正看见，只是选择相信 Agent 对这笔操作的概括。
这正是 AI Agent 从「回答问题」走向「替人行动」之后，逐渐暴露出来的一类新风险：Agent 已经可以浏览网页、登录账户甚至完成支付和链上签名，但用户最终面对的授权界面，却往往仍然只是一条模糊的聊天消息，以及一个几乎不包含有效信息的确认选项。
一句「Yes」，开始决定你的资金、数据与设备。
因此在 imToken 最新的品牌升级中，Store、Send、Stake 之外，出现了第四个 S——Sign，如果说前三个 S 分别对应资产保管、价值流动和网络参与，那么 Sign 所要解决的，就是当越来越多软件开始代表用户行动时，用户如何继续掌握最终的知情权、批准权与控制权。
而 Sigil，正是 Sign 命题下第一个早期探索的 POC 产品，它提出的核心原则非常有意思： What you see is what you sign——你看到什么，就签署什么。
一、当 Agent 开始行动，钱包为什么需要重新理解 Sign？
过去，加密钱包所面对的大多数签名风险，主要来自用户看不懂交易内容。
一笔链上交易，在底层可能只表现为复杂的合约地址、函数参数和十六进制数据，普通用户很难直接判断它意味着转账/兑换，还是某种更危险的资产操作。
因此，钱包需要将原始数据解析成人能够理解的信息，让用户在签名之前看到详细的信息（延伸阅读《 以太坊力推「所见即所签」：为什么 Clear Signing 是 AI 时代必需的能力补丁？ 》），Clear Signing，也就是「清晰签名」或「所见即所签」，正是为了解决机器数据与用户理解之间的差距。
但 AI Agent 带来的问题更加复杂。
因为用户看不到的，已经不再只是一笔链上交易，而可能是一整条由 Agent 自动规划和执行的操作链路。
正如上文所述，一个 Agent 为了完成「帮我把目前一半的流动资金都加仓 ETH」这样的目标，可能需要读取钱包余额、搜索链上池子、调用第三方工具、执行脚本并完成交易， 在这个过程中，用户既不可能逐条检查所有底层请求，又必须在资产真正兑换之前作出最终决定。
当前不少 Agent 所采用的授权方式，是在聊天窗口中发来一段简短说明，再等待用户回复「Yes」「确认」，或者点击一个普通按钮。
这种方式看似完成了用户授权，实际上仍然存在一些明显问题。
首先，它是一个黑箱，用户知道自己批准了某件事情，却不一定知道具体批准了多少金额、哪个收款方，以及 Agent 最终替自己签署了什么，真正的操作参数被隐藏在一句高度概括的自然语言之后，用户确认的只是一个模糊意图，而不是即将发生的真实动作。
其次，聊天回复并不等于数字签名。只要有人能够接触已经登录的设备，无论是拿到了手机、控制了聊天账户，还是在用户身旁直接代为操作，都可能输入一个「Yes」。系统最多只能确认这条消息来自某个账户，却无法确认它确实由账户所有者本人授权。
更棘手的是，确认界面本身也可能被伪造。如果 Agent 可以自行生成批准消息，那么发起操作的一方，同时也控制了向用户展示操作内容的界面，它完全可能遗漏关键参数、使用模糊措辞，甚至展示一项看似无害的操作，却在后台提交另一项请求。
这就形成了一个明显的信任悖论， 我们希望通过确认界面限制 Agent，却又让 Agent 自己决定用户在确认时能够看到什么。
当 Agent 只负责总结文章或整理信息时，这种不透明可能只会带来错误答案，但当它开始接触账户、资金、文件系统和终端环境，一次模糊批准造成的后果，就可能从「回答不准确」升级为真实的资产损失、数据泄露或设备风险（延伸阅读《 Sign 不只签名：当 AI Agent 替你签名，谁还握着控制权？ 》）。
因此，AI Agent 时代需要的并不是更多「Yes」按钮，而是一套能够证明「用户看到了什么、用户批准了什么，以及系统最终执行了什么」的签署机制。
二、Sigil：位于 AI Agent 与钱包之间的签名护盾
这也是 imToken 最新推出的 Sigil 要做的事情—— 将自己定义为一道位于 AI Agent 与钱包之间的安全护栏。
它并不试图阻止 Agent 自动执行所有任务，相反，用户可以在首次设置时明确授权 Agent，规定哪些低风险操作可以自主完成，哪些敏感操作必须暂停，并等待用户进行一次独立、明确且可验证的批准。
在设定好的边界内，Agent 仍然可以快速行动。
但 只要涉及用户标记为敏感的操作，特别是花费资金或签署交易，Sigil 就会暂停流程，将真实请求解析成清晰的确认卡片，并发送到用户的 Telegram， 用户需要通过 Passkey 和生物识别完成签署，操作才会继续执行。
总的来看，整个流程可以被概括为四步：
- Agent 发起操作： 它可以继续浏览网页、预订服务、发送请求或准备一笔交易，与普通 Agent 的工作方式没有区别；
- 判断是否触发预先设置的安全策略： 如果属于允许 Agent 自主完成的低风险操作，流程可以继续；如果涉及发送消息、删除文件、运行代码、花费资金或链上签名等敏感行为，Sigil 就会暂停执行，并解析这项请求。
- 用户通过 Passkey 明确批准： 一张清晰的确认卡片会被发送到 Telegram，其中直接展示商户、金额、接收方以及其他关键参数，用户看到的不是 Agent 自己撰写的一句说明，而是从真实操作中解析出来的结构化内容。
- 最后，只有在 Sigil 网关验证用户签名后，Agent 才能继续执行， 没有用户批准，任何资金和签名都不会移动；
这套机制的关键，并不只是多增加了一次生物识别，而是重新建立了展示、签署与执行之间的关系： 展示的是实际请求，用户签署的是展示出来的内容，系统最终执行的也必须是已经签署的请求。
一旦三者不一致，Sigil 就会阻止操作。
说到底，Sigil 并没有要求用户逐项批准 Agent 的所有动作，而是通过策略设置，让用户提前决定哪些行为可以自动完成，哪些行为必须由本人批准，且用户可以直接选择 Relaxed、Balanced 或 Strict 等不同安全级别，也可以进入 Custom 模式，对每类操作单独设置规则。
以 Balanced 模式为例，部分低风险度的行为可以不经过额外批准，而涉及到高资产安全相关的代码运行或终端命令，则必须经过 Sigil 确认。
至于花费资金和签署交易，无论用户选择哪种安全策略，始终需要本人批准。
这是 Sigil 不会让步的一条边界。
三、从 Crypto 到 AI Agent，Sigil 想守住什么？
围绕「What you see is what you sign」，Sigil 进一步提供了三层保障。
首先是用户能够准确看见自己在签什么，譬如在 Sigil 的确认卡片中，协议、金额、接收方等参数会被解析成清晰的字段，用户不需要信任 Agent 的概括，也不需要面对无法理解的原始数据。
这张卡片本身就是用户的授权内容。以开头的 ETH 交易为例，用户最终看到的不应只是一句「买入 ETH」，而应包括实际使用的资产和金额、交易接收方、关键交易参数，以及其他需要用户理解的操作信息。
对于现实支付场景，同样不应该只展示「确认支付」，而应清楚列出商户、金额和收款方，毕竟展示内容越接近真实操作，用户的授权才越有意义。
与此同时， 真正能够签署的人只有用户本人，这是因为 Sigil 使用 Passkey 作为批准操作的安全入口，并通过设备生物识别确认用户身份， 因此即使有人拿到了已经登录 Telegram 的设备，能够看到确认消息，也不能仅凭输入一段文字或点击普通按钮完成批准。
换句话说，Passkey 与用户本人绑定，而不是与「当前拿着手机的人」绑定。值得一提的是，Sigil 同时采用无助记词设计，用户不需要额外保管或输入一组新的助记词，也不需要把钱包私钥直接交给 Agent，真正控制批准能力的，仍然是用户自己的 Passkey 与生物识别。
此外，Sigil 的确认页面不是由 Agent 临时绘制的普通消息，而是一个经过注册的独立模块，其内容被固定在链上，并在沙箱环境中渲染。这意味着， Agent 不能在发起敏感操作之后，自行替换页面、修改展示逻辑，或者伪造一个外观相似的确认界面来诱导用户签署。
发起请求的一方，不再同时控制展示请求的界面，再配合单次签名、较短有效期，以及对请求参数进行哈希绑定，Sigil 可以确保确认卡片中的内容与最终等待执行的请求相互对应，使得签名不能被长期复用，请求参数也不能在用户批准后被悄然更换。
只要预览内容与实际请求不一致，操作就会被拦截。
因此把 Sigil 放在这一背景下看，它就不只是一项新的钱包功能，而是 imToken 对 Sign 命题展开的一次产品化探索，所关注的是另一个更基础的问题： 当 Agent 开始做事时，如何确保它仍然在用户允许的范围内行动？
在 Crypto 场景中，这种需求尤其直观——未来链上 Agent 可以帮助用户完成定期投资、收益管理、费用支付、头寸调整和风险监控，甚至根据预设条件，在多个协议之间自动执行操作，那就更需要考虑当 Agent 行为偏离用户预期时，能否被立即阻止。
与此同时， Sigil 的意义也并不局限于 Crypto，目前无论是 OpenClaw、Hermes，还是未来更多运行在个人设备和云端环境中的 Agent， 都在逐渐接入邮件、即时通信、日历、文件、浏览器、终端、支付工具和各类在线服务。
虽然这些操作不一定发生在区块链上，但它们的底层关系并没有本质区别，那就是 Agent 以用户的名义调用一项属于用户的能力，因此 Sigil 未来也可能从链上交易延展至数据访问、身份使用、文件修改、内容发布、服务购买和自动化任务。
这也解释了 为什么钱包行业过去所积累的能力，可能在 AI Agent 时代获得新的价值 ——私钥管理、数字签名、身份验证、权限确认和资产安全，过去主要服务于链上交易，但它们所处理的更本质问题，一直都是如何证明一项行动获得了某个主体的真实授权。
当 Agent 开始大规模替人行动时，这套能力有机会从 Crypto 世界进一步延伸，成为用户管理智能身份、自动化任务和机器权限的一项基础设施。
因此，作为 imToken 与 OpenClaw 的共同探索，Sigil 试图把 imToken 过去十年在自托管、钱包和数字签名领域积累的经验，带入自主 Agent 开始进入真实执行环境的新阶段。
它不替代 Agent，也不取代钱包。
它站在二者之间。
写在最后
总的来看，AI 正在让行动能力变得越来越廉价。
过去需要用户在多个应用之间反复切换，经过搜索、填写、确认和支付才能完成的事情，未来可能只需要一句自然语言指令，便可以由 Agent 自动拆解和执行。
但「能够替用户行动」与「已经获得用户有效授权」，始终是两回事。
因为真正决定一个智能系统是否值得信任的，不只是它能够完成多少任务，而是用户是否始终能够理解它、限制它，并在必要时让它停下来，从这个角度看，Sign 不是阻碍 Agent 效率的一道多余流程，相反，它可能是 Agent 真正进入资产和现实服务之前，最重要的一层信任基础。
Store 让用户拥有资产，Send 让价值自由流动，Stake 让用户参与开放网络，而 Sign 要解决的，是当越来越多机器开始替人行动时，用户如何继续保有最后的决定权。
Sigil 的价值，也正在于把这项看似抽象的控制命题，第一次推向一个可以通过真实 demo 进行验证和持续完善的产品。
让我们拭目以待。
