沉寂了一段時間的「龍蝦」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。
這也是為什麼錢包產業過去累積的私鑰管理、數位簽名、身分驗證與權限隔離能力，可能會在 Agent 時代獲得新的意義。
因為這些技術表面上是在解決「怎樣安全地簽一筆鏈上交易」，背後處理的其實是一個更加普遍的問題：如何證明一項行動，確實獲得了某個主體的真實授權。
今天，這項行動可能是轉出 1 ETH。未來，它也可能是寄送一封郵件、修改一份檔案、使用某個數位身分、購買一項服務，或者允許 Agent 在未來一週持續執行某套自動化策略。
這些行為並不一定全部發生在區塊鏈上，但底層關係非常相似，也就是 Agent 正在以使用者的名義調用一種屬於使用者的能力。
因此，Sigil 的意義也未必只侷限於 Crypto。
當 OpenClaw、Hermes 以及更多運行在個人裝置或雲端環境中的 Agent，逐漸連接電子郵件、即時通訊、行事曆、檔案、瀏覽器、終端和支付工具時，「如何證明這一次行動確實經過使用者授權」會變成一個越來越普遍的問題。
因此 Sigil 未來也可能從鏈上交易延伸至資料存取、身分使用、檔案修改、內容發布、服務購買和自動化任務。
總的來看，作為 imToken 與 OpenClaw 的共同探索，Sigil 試圖把 imToken 過去十年在自託管、錢包和數位簽名領域累積的經驗，帶入自主 Agent 開始進入真實執行環境的新階段。
它不替代 Agent，也不取代錢包。
它站在二者之間。