Agent Wallet

Agent 錢包和「普通 EOA 錢包」有什麼根本差別？為什麼不能直接把 MetaMask 的私鑰給 Agent 用？

這是最核心的問題。表面上都是「一個有私鑰的以太坊地址」，但設計邏輯完全不同：

普通 EOA 錢包（MetaMask、硬體錢包）的設計假設：有一個人類在每筆交易前親眼確認——「這筆轉帳對嗎？金額對嗎？地址對嗎？」人類是最後一道安全門。因此 EOA 錢包沒有內建的程式化操作限制，私鑰可以授權任何金額、任何地址的任何操作。

Agent 錢包的設計假設：沒有人類在每筆操作前確認——Agent 是完全自主執行的。因此安全邊界必須在程式碼層內建，不依賴人類確認：金額上限硬編碼（超過 $100 的操作必須暫停等待人工確認）、目標地址白名單（Agent 只能和白名單裡的合約互動）、每日累計限額（防止長時間運行的 Agent 在沒有人監督的情況下累積大額操作）。

為什麼不能把 MetaMask 私鑰直接給 Agent：一旦私鑰被 Agent 持有，Agent 的 LLM 推理若被 Prompt Injection 污染，攻擊者可以讓 Agent 授權任何金額轉到任何地址——沒有程式化的護欄阻止它。這等同於把一張沒有限額的信用卡交給一個可能被駭客操控的機器人。

正確做法：用專門的 Agent 錢包，在程式碼層設置所有操作邊界，把這個錢包和你的主資金隔離，只放「幾天的運作資金」。

Agent 錢包有哪四種主流架構？各自適合什麼場景？

架構一：EOA + 程式碼護欄（最簡單） 直接用一個普通 EOA 地址，把私鑰存在後端（AWS Secrets Manager、環境變數加密），程式碼層實現所有安全邊界（金額驗證、白名單、每日限額）。成本最低、部署最快，適合早期 Agent 和低資金量場景。缺點：私鑰集中在一個地方，後端如果被攻陷，私鑰就洩漏。

架構二：MPC 錢包（多方計算） 私鑰被拆分成多個「碎片」分散存放（例如 2-of-3：Agent 持有一片、你的手機持有一片、服務商持有一片），簽署交易需要多個碎片合作，任何一個碎片單獨洩漏都不能完成簽署。Privy、Turnkey 提供商用 MPC 錢包服務。適合中高資金量的 Agent，解決了「私鑰集中」的問題，但增加了服務商依賴。

架構三：智能合約錢包（Safe / ERC-4337） 用智能合約實現多簽或條件授權邏輯：Agent 的操作請求被提交到合約，合約按照預設規則執行（需要多簽才能超過上限、只允許和白名單合約互動）。安全性最高，規則透明可審計（在鏈上），但 Gas 費更高，部署更複雜。適合高資金量、需要鏈上可審計性的機構級 Agent。

架構四：Coinbase AgentKit 託管錢包 Coinbase 的 MPC 基礎設施托管私鑰，透過 SDK 提供標準化的 Agent 錢包功能。對 Base 鏈的整合最深，Paymaster 可以讓 Agent 用 USDC 付 Gas（不需要持有 ETH）。適合快速原型和 Base 鏈策略，但資金由 Coinbase 托管（有交易對手風險）。

Agent 錢包的 Gas 費問題怎麼解決？Agent 自己付 Gas 有哪些設計模式？

Gas 費是 Onchain Agent 最容易忽略但最影響用戶體驗的問題。設計不好的 Agent 錢包需要持有多種鏈的 ETH/SOL 作為 Gas，手動補充 Gas 費，且難以預測 Gas 消耗。主流的四種解決設計：

1. ETH 儲備（最基礎）：Agent 錢包持有一定量的 ETH（或目標鏈的原生代幣）作為 Gas 儲備。設定低水位線告警（低於 0.01 ETH 時通知補充）。簡單，但需要跨鏈部署時每條鏈都要維護 Gas 儲備，管理成本隨部署鏈數線性增加。

2. Paymaster（ERC-4337 帳戶抽象）：智能合約錢包（ERC-4337 模式）支持 Paymaster 機制——第三方 Paymaster 合約代付 Gas，Agent 只持有 USDC，Gas 費從 USDC 扣除（Paymaster 在後端兌換成 ETH 支付礦工）。Coinbase 的 Base 鏈、zkSync 都有 Paymaster 支持。這讓 Agent 的財務邏輯更乾淨：只需要 USDC，不需要管理多種 Gas 代幣。

3. Relayer 服務（無 Gas 模式）：Agent 生成未簽署的交易，提交給 Relayer（如 OpenZeppelin Defender），Relayer 代替支付 Gas、廣播交易，從 Agent 的 USDC 餘額中扣回成本。適合不支持 ERC-4337 的鏈（如 Solana 的 Jito 服務）。

4. Sponsorship（適用特定場景）：某些 DeFi 協議（如 Aave 的 GasZip）在用戶與協議互動時免 Gas，費用由協議吸收。Agent 在這些協議上的操作可以零 Gas 費，但只限特定協議支持的操作。

實際建議：Base 鏈上部署優先考慮 Paymaster（AgentKit 內建支持）；多鏈部署用 Relayer 服務統一管理；只在 ETH 主網操作且不想依賴第三方時選 ETH 儲備模式。

Agent 錢包的私鑰洩漏了怎麼辦？緊急響應流程是什麼？

Agent 錢包的私鑰一旦洩漏，後果比普通錢包更嚴重——因為 Agent 可能 24 小時不間斷運行，攻擊者可以立刻利用私鑰進行操作，且你可能沒有即時的人工監控。完整的緊急響應流程：

第一步（0-5 分鐘）：立刻停止 Agent 服務進程。不管是什麼原因懷疑洩漏，先停止——停止 Agent 服務不能撤回已廣播的交易，但能防止 Agent 繼續廣播新交易。用 kill 或停止 Railway / Cloud Run 的服務實例。

第二步（5-10 分鐘）：撤銷所有 ERC-20 授權。即使服務已停止，如果 Agent 錢包地址對任何代幣合約有 approve 授權，攻擊者仍然可以直接調用合約把代幣轉走。用你的主錢包，對所有已授權的代幣合約調用 approve(agentAddress, 0) 撤銷授權。可以用 revoke.cash 快速查詢和批量撤銷。

第三步（10-30 分鐘）：把 Agent 錢包的剩餘資金轉到新地址。在停止服務後、撤銷授權後，立刻把 Agent 錢包裡的剩餘資金轉到一個全新的、從未使用過的地址（不是你的主錢包——因為如果攻擊者已在監視你的轉帳行為，主錢包也可能被標記）。

第四步（30-60 分鐘）：根本原因分析。從日誌裡找「私鑰怎麼洩漏的」——是後端被攻擊（代碼倉庫、環境變數）、還是 Prompt Injection 讓 Agent 把私鑰輸出到了不安全的地方（這是一種極端罕見但存在的攻擊場景）。根本原因決定了修復方案。

第五步：換新 Agent 錢包重新部署，不要重用原來的地址——即使資金已轉移，舊地址的操作歷史可能讓攻擊者推斷你的策略邏輯。