MetaMask 把代理錢包變成受控自動化

我拆 MetaMask Agent Wallet 的方法論：先管權限、再做模擬、最後才談自動化。

我盯 agent wallet 很久了，老實說，很多 demo 都卡在同一個爛點：看起來很會做事，一碰到錢就開始裝死。它可以幫我把交易草稿寫好，也可以把理由講得頭頭是道，但真正要按下簽名那刻，我還是得自己盯著螢幕。那種「好像自動化了、其實還在陪跑」的感覺，我已經看膩了。MetaMask 這次的 Agent Wallet，讓我第一次覺得他們不是只想蹭 AI 名字，而是真的在處理這個尷尬地帶。

這份洞察的起點是 CryptoBriefing 這篇文章，裡面整理了 MetaMask 的 Agent Wallet、保護覆蓋與框架支援。來源沒有提供瀏覽數、星數或書籤數，我就不亂掰。真正值得看的是它怎麼把政策、模擬、威脅檢查和保護機制串成一條線。

MetaMask 先承認一件事：agent 不該預設值得信任

“The wallet provides agents with dedicated transaction accounts while enabling users to define spending limits, approved protocols, and operating policies before execution begins. Any transaction that exceeds those parameters or is flagged as potentially malicious requires human approval through 2FA before proceeding.”

翻譯一下就是：MetaMask 沒有假裝 agent 天生可靠，它直接把 agent 當成有權限的員工，不是拿到整個倉庫鑰匙的神。先給它一個可用的工作範圍，再把花費上限、協議白名單、操作政策先寫好。超出範圍？回來問人，還要 2FA。

我很吃這套，因為我一直覺得 agent 最像的是 production 裡的 cron job，不是什麼魔法生物。cron job 會跑，但你不會讓它隨便改整個資料庫。你會限制它能碰什麼、記錄它做了什麼、出事能不能撤。agent wallet 也一樣，先定權限，再談效率。

實操寫法很簡單：把「能做什麼」寫在前面，不要等模型自己悟。先列出允許的合約地址、允許的協議、單筆上限、日上限，然後把任何超出規則的動作都設成人工確認。你如果連這層都不想做，那你不是在做自動化，你是在做風險外包。

• 用 route 來設 spending cap，不要只看 wallet 總額。
• 白名單只放真的要用的 protocol，不要偷懶寫「all DeFi」。
• 把 human approval 設成預設，不是例外。

這不是保守，這是務實。因為 agent 一旦接上錢包，錯一次就不是 prompt 寫歪而已，是資產真的會動。

模擬不是附加功能，是避免自爆的最低標準

“MetaMask Agent Wallet incorporates multiple layers of protection, including transaction simulation, Blockaid-powered threat detection, Smart Transactions MEV protection, and Transaction Protection coverage of up to $10,000 per month for eligible transactions.”

也就是說，它不是只問「agent 想不想做」，而是先問「這筆如果真的送出去，會發生什麼事」。我比起任何 agent 的自信解釋，更信 transaction simulation。因為模型很會講漂亮話，但鏈上路徑不會騙人：滑點、授權、轉帳稅、奇怪的 token 行為，全部都會在模擬裡露餡。

我自己碰過類似的坑。交易 bot 在 code review 看起來很乾淨，結果一上鏈才發現某個 token 有 transfer tax，或某個 approval pattern 讓風險範圍比想像中大一截。那種時候你才會知道，問題不是 agent 會不會講理，而是它有沒有先看過真實路徑。

MetaMask 這裡還接了 Blockaid 的 threat detection，這點我覺得對。模擬只能告訴你「結果長什麼樣」，不能自己判斷「對方是不是壞人」。Blockaid 本來就是做錢包安全、釣魚與詐騙檢測的，放進 agent flow 裡，等於多一層意圖檢查，不只是算數學。

實操寫法：任何 agent 交易都先走 preflight。先模擬，再比對預期與實際 token flow，最後才允許送出。如果 call data 在 review 跟 send 之間被改掉，直接擋下來。別讓 agent 用「我覺得可以」當送錢理由。

• 先 simulate，再 sign，不要反過來。
• 把預期餘額變化和實際路徑做 diff。
• call data 一旦變動，直接重跑檢查。

很多所謂 AI wallet，其實只是包了一層很會聊天的簽名介面。MetaMask 至少有在往控制系統那邊靠，而不是只做漂亮 UI。

有保護上限，才有人敢把 agent 接到真錢上

來源提到 eligible transactions 最多有每月 $10,000 的 Transaction Protection coverage。我不會把這東西當成神奇保險金，因為它本質上只是最後一道防線。但它有一個很現實的效果：它會改變人怎麼用這個產品。

當使用者知道有損失上限，會比較敢試 automation。當開發者知道有保護層，會比較敢把 agent 接進 live workflow。這不是消滅風險，是降低進場門檻。我很少看到產品團隊把這件事講清楚，大家老愛把 coverage 講成亮點，卻不講它其實是在幫 adoption 降心理阻力。

但我還是要潑冷水：不要拿 coverage 當主防線。真正該先有的，還是 policy、simulation、threat detection、approval。保護覆蓋只是你前面都失手之後，還能少流一點血的那層網。

實操寫法：如果你在評估帶保護機制的產品，直接把條款當合約看。問清楚哪些交易算 eligible、哪些鏈算在內、是不是你要的交易型態、出事後怎麼 claim。你如果自己做產品，也別在規則沒寫清楚前就亂承諾 coverage，最後只會變成客服地獄。

我最在意的是，安全機制要看得見。使用者不用翻三層設定才知道出事怎麼辦，這種產品我通常不太信。

Guard Mode 和 Beast Mode，其實是兩種信任模型

“The launch introduces two operating modes. Guard Mode emphasizes oversight through policy enforcement and approval workflows, while Beast Mode offers a more streamlined experience for users seeking greater automation.”

翻譯一下就是：MetaMask 沒有裝傻說所有人都要同一種用法。有人要嚴一點，有人要快一點。它乾脆把這兩種心態拆成兩個模式，至少不會把「更安全」和「更慢」混成一團。

我很討厭很多工具在這裡偷換概念。它們把「少一步確認」說成「更成熟」，把「多一道審核」說成「比較笨」。其實不是。Guard Mode 是給新策略、新合約、新 prompt 用的。Beast Mode 是給已經跑順、失敗模式很無聊的流程用的。兩者不是高下之分，是風險階段不同。

我自己的做法也差不多。新 workflow 一律先開嚴格模式，等我看過幾輪成功案例、知道它會在哪裡犯錯，再把某些步驟放鬆。這跟部署權限、CI 權限、金鑰輪替是一樣的邏輯：先保命，再提速。

實操寫法：你的 agent 工作流至少要有兩層信任。第一層要能 review、simulate、approve；第二層才允許減少摩擦，但前提是前一層已經證明穩定。你如果沒辦法把這件事寫進工具裡，通常就代表你把實驗和正式環境混在一起了。

• 新 agent、新合約，一律走 strict mode。
• 重複性高、已驗證的流程，才考慮快模式。
• 模式切換要進 log 和 audit trail。

這種分法看起來很無聊，但無聊才是好事。因為錢包不該靠賭。

支援既有框架，才是真的能落地

“Built for crypto-native traders, developers, and automators, the wallet supports leading agent frameworks including OpenClaw, OpenAI Codex, Claude Code, Nous Research Hermes Agent, Cursor, and related environments.”

也就是說，MetaMask 沒打算逼大家搬家。它想直接接進你原本就在用的 agent 工具裡。這點我覺得比「我們有 AI」重要太多，因為 agent 生態本來就碎得很。有人用 coding assistant，有人用 autonomous task runner，有人自己串一堆 prompt orchestrator，還有人只想在 editor 裡把事情做完。

這裡我特別在意 OpenAI Codex、Claude Code、Nous Research Hermes、Cursor 這幾個名字。因為如果錢包只能活在某個專屬 runtime 裡，那 adoption 很快就會卡住；但如果它能掛在既有框架底下，開發者就能保留自己熟悉的 orchestration layer，只把安全層標準化。

我自己的理解是：agent 決定意圖，wallet 決定能不能真的簽。這條線一定要分開。你可以換 Codex，也可以換 Cursor，甚至換成本地 agent，但你的簽名政策不該跟著重寫一次。

實操寫法：把 wallet integration boundary 畫清楚。讓 agent 負責提案，讓 wallet 負責 policy、validation、signing。框架層保持可替換，安全模型保持不變。這樣哪天你想換 runtime，不會整個重做一遍。

這種分工很樸素，但樸素才是能活下來的設計。

自我保管不是口號，要能撐過自動化這一層

MetaMask 說自己一直維持 self-custody，私鑰還是用戶自己管，Secret Recovery Phrase 也能由用戶自行匯出。這句我很在意，因為很多 AI wallet 會偷偷把 custody tradeoff 塞進來，然後假裝沒事。

如果 agent 拿著 key，那就不是 self-custody 了，那叫 delegated custody，只是包裝得比較好看。MetaMask 至少有把線畫出來：agent 拿的是 dedicated transaction account 和操作規則，不是整個身份控制權。人還是能撤回、能停、能把權限抽掉。

我之前自己想過一個交易工具的 wallet automation，卡住的點就是這裡。agent 一旦太強，真正的產品就變成 recovery。這很糟，因為 recovery 應該是逃生出口，不該是主功能。只要使用者還握著 key，automation 就算失敗，也不會把整個身份層一起拖下去。

實操寫法：把 signing authority 和 action planning 拆開。使用者要能撤權、能看 pending actions、能在不問 agent 的情況下退出。這些聽起來像基本常識，但很多產品做不到，因為它們一開始就把邊界畫歪了。

我會注意 MetaMask 這次，不是因為它加了 AI，而是因為它試著在讓軟體多做一點事的同時，還把原本的 self-custody 承諾留住。

可抄的模板

# Agent Wallet Policy Template（可直接抄走改掉）

## 1. 使用目的
只允許 agent 執行已模擬、已檢查、已批准的 onchain 動作。

## 2. 權限範圍
- 允許框架：OpenAI Codex / Claude Code / Cursor / 其他：[填入]
- 允許鏈： [填入]
- 允許合約： [填入地址清單]
- 禁止合約：所有未列入白名單者

## 3. 金額限制
- 單筆上限： [填入]
- 每日上限： [填入]
- 每月上限： [填入]
- 允許 token： [填入]
- 禁止 token： [填入]

## 4. 執行流程
1. 先做 transaction simulation
2. 再做 threat detection
3. 比對預期 route 與實際 route
4. 若超過任何限制，停下來等人類批准
5. 任何異常交易一律要求 2FA

## 5. 保護機制
- 啟用模擬後再簽名
- 啟用釣魚 / 詐騙檢測
- 啟用 MEV protection（若可用）
- 清楚寫出 coverage 的 eligibility 與 claim 流程

## 6. 操作模式
### Guard Mode
適用於：
- 新策略
- 新合約
- 高金額轉帳
- 行為尚未穩定的 workflow

要求：
- 必須人工批准
- 完整 audit log
- 嚴格 allowlist

### Beast Mode
適用於：
- 已驗證且重複執行的流程
- 低風險自動化
- 範圍很窄的固定任務

要求：
- 同一套 policy engine
- 只有在成功執行多次後才降低摩擦
- 模式切換必須寫入 log

## 7. 緊急控制
- 立即撤銷所有 active permissions
- 只透過 owner 的流程匯出 recovery credentials
- simulation 出現異常就暫停 automation
- 任何 malicious flag 都轉人工審核

## 8. Audit log 欄位
- Timestamp
- Agent name
- Framework
- Chain
- Contract address
- Transaction hash
- Simulation result
- Threat detection result
- Approval status
- Final execution mode

## 9. 可直接用的批准提示
只有在以下條件都成立時才批准：
- 符合允許的鏈與協議
- 沒有超出 spending limit
- simulation 結果與預期一致
- threat detection 是乾淨的
- 我確認這個動作是我真的要做的

只要有一項不符合，就拒絕並要求人工複查。

我會先把這版丟進自己的 workflow，跑一輪再修。它不花俏，但它把最重要的問題都先問完了：誰能做、能做到哪、出事誰擋、怎麼留痕。

來源 URL：https://cryptobriefing.com/metamask-debuts-ai-agent-wallet-10k-transaction-protection-coverage/。這篇是我根據來源內容做的方法論拆解；產品細節、保護機制與框架支援來自原始來源，我的部分是把它翻成開發者能直接拿去用的版本。