為什麼每個 AI 代理都需要錢包

代理程式可以在完全不碰資金的情況下提出建議。但執行是另一回事。一旦代理程式需要支付資料費用、購買算力、重新平衡部位或在鏈上結算交易，就需要一個地方來持有資產、授權資金移動，並在資金實際移動前執行限制。這個地方就是錢包，這也是 MetaMask Agent Wallet 與 Coinbase 的 AgentKit 在 2026 年相繼推出的重要原因——兩者都旨在賦能代理程式與新興數位經濟。Coinbase 也協助推廣了 x402 支付協議，許多代理程式現在都使用它來支付 API、算力和資料費用。

執行型代理程式是否需要錢包，這個問題已有定論。真正值得探討的是：代理程式使用錢包時，控制權究竟在誰手上？使用者是否持有可匯出的金鑰並直接設定代理程式的限制？還是代理程式的執行路徑在運行期間始終綁定於服務商的基礎設施？MetaMask Agent Wallet 採取的是第一種方式：一個具備可程式化防護機制的自託管錢包，專為付諸行動的代理程式而生。

若想了解基礎知識，請參閱什麼是 Agentic 錢包，再深入了解技術架構，請參閱 AI 代理程式如何在不碰你金鑰的情況下完成交易。若想比較各產品，請參閱 2026 年最佳 Agentic 錢包。本文聚焦於：為何錢包層對任何付諸行動的代理程式而言已不可或缺，以及為何託管方式決定了代理程式自主性的真實程度。

從建議型代理程式到行動型代理程式的轉變

只產出文字的代理程式無需接觸資金。它的輸出只是建議，仍需由人類來執行。這是目前大多數已部署代理程式的預設形態，也是它們的天花板：只能提供建議的代理程式，在每個財務步驟上仍需要人類介入，這大幅限制了它實際能完成的工作量。

現在正在建構的代理程式截然不同。它們監控 DeFi 部位並直接進行再平衡；它們在多個服務商之間比價算力或資料，並即時支付給當下最便宜的那一個；它們直接執行交易，而不只是描述交易。這些行動都需要同一種底層能力：以代理程式的運作速度在鏈上持有並移動資產，無需等待人類解鎖下一步。

這種能力不來自語言模型，而來自錢包。代理程式的推理能力可以無限精進，但若沒有持有並授權資金移動的方式，它終究只是一個建議引擎。錢包將決策轉化為行動，這正是為何這個類別在短短數月內，從開發者的實驗性探索，演變為 MetaMask、Coinbase、Cobo 和 OKX 的正式產品線。

代理程式實際交易所需的條件

要從建議走向行動，代理程式需要三樣東西：可供提領的餘額、在執行過程中支付所消耗資源的方式，以及無需人類逐筆確認即可在鏈上執行的能力。

第二個需求比聽起來更新穎。軟體向來需要支付基礎設施費用，但通常是透過人工管理的發票、訂閱或儲存的信用卡，而非由代理程式本身在任務執行中途發起支付。呼叫付費 API、向其他模型購買推理服務或提取授權資料的代理程式，需要即時結算這些費用。x402 填補了這個缺口：這是一個基於 HTTP 402「Payment Required」狀態碼的開放協議，讓伺服器可以請求付款，客戶端在同一次交換中完成結算，無需事先建立帳戶，也無需人工在中途審核。MetaMask Agent Wallet 目前在買方端支援 x402，讓代理程式可以直接從其錢包支付 x402 閘控的端點。x402 獨立於錢包本身：它定義的是支付如何定價與結算，而非誰持有金鑰或代理程式被允許花費多少。這個問題仍由錢包負責。

綜合以上，這就是人們所說的 Agentic Commerce（代理商務）或機器對機器支付的含義：軟體以程式碼的速度向軟體付費，購買過去需要人類持信用卡才能取得的服務。這一切若沒有底層的錢包，都無法運作。

託管問題

一旦確認行動型代理程式需要錢包，更值得探討的問題是：誰來控制它？目前市場上可見三種模式，處於不同的可用階段，各自對這個問題給出不同的答案。

各類產品的託管用語不盡相同，服務商對自身模式的描述也相當公允。Coinbase 將 Agentic Wallets 稱為在可信執行環境（TEE）內保護的非託管錢包，並搭配可程式化消費限額與 KYT 篩查。OKX 對其 Agentic Wallet 的描述如出一轍：金鑰在 TEE 內管理，從不暴露給模型。Cobo 則將其 Agentic Wallet 定位於基於 MPC 的金鑰分割，以及為「具備細粒度策略控制的企業級自動化」而建構的 Pact 強制執行策略引擎。這些都是合理的安全模式，MetaMask Agent Wallet 同樣使用 TEE 支援的基礎設施來保護簽署。本文關注的區別比「TEE 與非 TEE」更為具體：使用者是否持有可匯出的金鑰與退出路徑，還是代理程式的執行在運行期間始終綁定於服務商運營的錢包。

這是將自託管原則應用於新型使用者的體現。服務商運營的基礎設施可以真正安全，但只要代理程式在其上運行，它就始終是每筆交易信任路徑的一部分：無論服務商的初衷多麼良善，該基礎設施都可能凍結、限速或變更條款。自託管設計讓使用者保留匯出或恢復路徑，並直接定義代理程式的限制，而非單純依賴服務商持有的帳戶。對於代表他人自主行動的代理程式而言，這個區別決定了其自主性是隨使用者而行，還是受限於服務商的執行環境。

自主而不魯莽：可程式化防護機制

自託管本身並非完整的答案。一個沒有任何限制的自託管錢包，會讓代理程式在使用者餘額允許的範圍內為所欲為，這本身就是一種風險。真正的答案是將自託管與預先設定的可程式化防護機制相結合：消費上限、白名單協議、會話限制、單筆交易限制，以及記錄代理程式每個行動及其原因的日誌。

防護機制讓授予代理程式常設授權成為可能，無需逐筆手動審核。消費上限在不危及帳戶的情況下限制錯誤交易的損失。協議白名單將代理程式限制在使用者已審核的合約範圍內。會話與單筆交易上限限制了單一被入侵的提示或惡意回應所能造成的損害，而可稽核的日誌讓每個行動事後都能重建。這一切都不需要放棄自主性，而是定義自主性運作的邊界。

在實際應用中，目前有兩種運作模式：預設的保守模式，執行設置時設定的每日消費限額和協議白名單，對任何超出這些規則或被威脅掃描標記的行為暫停並要求雙重驗證；以及第二種選擇加入的模式，在策略邊緣情況下給予代理程式更大的彈性，同時仍阻止明顯的惡意交易。在 MetaMask Agent Wallet 中，這兩種模式分別稱為 Guard Mode 和 Beast Mode。無論哪種模式，防護機制都由使用者在代理程式啟動前定義，而非由代理程式在執行過程中協商。

MetaMask Agent Wallet：專為代理程式打造的自託管錢包

MetaMask Agent Wallet 是一個專為 AI 代理程式打造的自託管錢包，其核心設計理念是：金鑰由使用者持有，而非 MetaMask。這個錢包讓代理程式能夠在 EVM 鏈和 Hyperliquid 上執行兌換、永續合約、預測市場、質押和流動性提供，全部透過同一個自託管錢包完成。

每筆支援的 EVM 交易在上鏈前都會經過安全管道：交易模擬、由 Blockaid 驅動的 Transaction Shield 威脅掃描，以及 Smart Transactions MEV 保護。無論使用者選擇哪種運作模式，這個管道都會運行：預設的 Guard Mode 對任何超出使用者消費限額或協議白名單的行為要求雙重驗證；Beast Mode 則在策略邊緣情況下給予代理程式更大的彈性，同時仍阻止惡意交易並將其提交雙重驗證審核。金鑰受可信執行環境保護，同時使用者可隨時匯出；通過管道的符合資格交易受 Transaction Protection 保障，每月最高賠付 $10,000 美元，須符合資格條件、限額及條款。

MetaMask Agent Wallet 目前以 CLI 為主，可整合至 Claude Code、Codex、OpenClaw、Hermes、OpenCode 和 Cursor 等代理程式框架。現已透過早期存取計畫開放使用，正式版即將推出。若想完整了解一筆交易如何在該架構中從指令走到執行，請參閱 AI 代理程式如何在不碰你金鑰的情況下完成交易。

這對建構代理程式群的開發者意味著什麼

群體（Swarm）場景是託管問題複雜度倍增之處。單一代理程式持有服務商金鑰，是一個信任節點。由十幾個代理程式組成的群體，各自獨立交易，這種暴露風險成倍放大——若它們共用一個服務商持有的錢包，單一被入侵的代理程式或基礎設施事故就可能同時影響整個群體。

自託管架構為開發者提供了兩種控制爆炸半徑的方式。每個代理程式可以擁有自己專屬的錢包，設有獨立的消費限額，以實現最乾淨的隔離與稽核軌跡。或者，單一使用者錢包可以向每個代理程式授予有範圍限制的委託權限——預先定義資產、金額、期限和約束條件——這樣資本就不必分散到各個獨立資助的錢包中。許多生產系統兩者兼用：一個資助錢包用於廣泛執行，以及針對較窄、重複性任務（如透過 x402 支付資料或算力費用）的有範圍委託。無論哪種模式，使用者而非第三方，始終是群體中任何代理程式可執行操作的最終依據——且託管出錯的代價，受使用者自身策略的約束，而非服務商基礎設施的約束。