沉寂了一段時間的「龍蝦」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 不斷蓋章的「人工驗印機」。
In other words, the intermediate flexibility is both the source of the Agent's improved efficiency and a new source of risk.
From this perspective, the core issue is not about whether to delegate authority to Agents, but whether the granularity of authorization and the verification mechanism can be dynamically flexible, as traditional permission management is binary (either allow or deny), while the tasks faced by Agents are clearly much more complex.
同樣是一筆交易，10 美元和 10 萬美元不同；與長期使用的協議交互，和突然授權一個陌生合約不同；完成一筆用戶明確要求的 Swap，和 Agent 自行決定把資產跨到另一條鏈，也不是同一個風險等級。
因此，Agent 越能自主行動，權限就不能只是一個簡單的開關。
真正需要的，是一套能夠讓它在邊界以內自由行動，越過邊界時自動停下來的安全機制。
二、如何為自主 Agent 建立一條「可驗證」防線？
事實上，OpenClaw 並沒有忽視這個問題。
Currently, it provides a multi-level permission system, for example, plugins can pause and require user confirmation before executing specific actions, and when it comes to host commands, there are also independent Exec Approvals and Allowlist, among others.
相比將所有工具和權限一次性交給 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。
這也是為何錢包行業過去累積的私鑰管理、數位簽名、身份認證與權限隔離能力，可能會在 Agent 時代獲得新的意義。
這些技術表面上是在解決「怎樣安全地簽一筆鏈上交易」，背後處理的其實是一個更加普遍的問題：如何證明一項行動，確實獲得了某個主體的真實授權。
今天，這項行動可能是轉出 1 ETH。未來，它也可能是發送一封郵件、修改一份文件、使用某個數字身份、購買一項服務，或者允許 Agent 在未來一週持續執行某套自動化策略。
這些行為並不一定全部發生在區塊鏈上，但底層關係非常相似，那就是 Agent 正在以用戶的名義調用一種屬於用戶的能力。
因此，Sigil 的意義也未必只局限於 Crypto。
當 OpenClaw、Hermes 以及更多運行在個人設備或雲端環境中的 Agent 逐漸連接郵件、即時通信、日曆、文件、瀏覽器、終端和支付工具時，「如何證明這一次行動確實經過用戶授權」會變成一個越來越普遍的問題。
因此 Sigil 未來也可能從鏈上交易延展至數據訪問、身份使用、文件修改、內容發布、服務購買和自動化任務。
總的來看，作為 imToken 與 OpenClaw 的共同探索，Sigil 試圖將 imToken 過去十年在自託管、錢包和數位簽名領域積累的經驗，帶入自主 Agent 開始進入真實執行環境的新階段。
它不替代 Agent，也不取代錢包。
它站在二者之間。