為什麼先看錢，而不是先看程式碼
過去一年關於 Agent 錢包的討論幾乎都停在「它現在可以自己付錢了」。這件事本身是真的，但它回答的是能力問題，不是依賴問題。
讀合約能知道一個 Agent 被允許做哪些事；讀資金流才知道它靠誰才做得成。這兩件事經常給出相反的印象：一份權限乾淨、不可升級的合約，背後可能是一個每週由團隊人工補款、手續費也由團隊代付的帳戶。合約沒有問題，但只要那筆補款停掉，這個「自主 Agent」下週就不動了。
我自己排順序時會先看 Gas，再看本金。理由很實際：本金可以是一次性的，查到一筆大額入帳未必說明日常怎麼運作；而手續費是每一次動作都要付的，誰在長期承擔這筆錢，誰就握著開關。這只是我的取捨，反過來先查本金也說得通，只是別只查一邊就收工。
本金從哪裡進來：四種入口
把 Agent 地址的第一筆入帳，以及之後的定期入帳，逐筆標上來源型別。常見的有四種，每一種能支持的結論都不一樣。
| 入帳來源 | 在瀏覽器上的樣子 | 能說明什麼 | 不能說明什麼 |
|---|---|---|---|
| 交易所提幣 | 來自交易所公開標註的熱錢包地址，金額與時間常呈批次 | 有人用一個通過身分驗證的帳戶出金給它 | 那個帳戶屬於誰；交易所地址由大量使用者共用 |
| 專案金庫或多簽 | 來自專案自己揭露的金庫位址，或一個多簽合約 | 供給端在專案手上，補款節奏可觀察 | 金庫的簽署人是否彼此獨立 |
| 公開募集或分配合約 | 來自一份可讀取的合約，常伴隨 Transfer 事件 | 資金路徑有規則可讀，條件寫在合約裡 | 合約之外是否另有可動用的權限 |
| 跨鏈橋或中轉地址 | 來自橋接合約，或一串只轉一次就棄用的新地址 | 資金來自另一條鏈，或有人刻意增加追查成本 | 原始出資方；中轉本身不等於惡意 |
第四列要特別冷靜。新地址中轉在鏈上非常普遍，做市、代管、隱私需求都會產生同樣的形狀，單憑它下不了任何結論，只能決定要不要往上再走一層。
另外提醒一個常見誤判：資金同源不等於同一個控制者。同一個交易所熱錢包每天都在向大量互不相干的使用者地址出金；把兩個地址因為「都收過同一個熱錢包的錢」而判成同一批人，是把交易所的規模誤讀成關聯性。
Gas 是誰付的，可能根本不經過它的錢包
在以太坊的一般交易裡，手續費由送出交易的那個帳戶支付。所以最單純的情況是：Agent 的地址自己持有原生代幣，自己付費，餘額會隨著每次動作下降——這種帳戶你可以直接從餘額變化看出它的活動成本。
但現在有兩種設計會讓這條線斷開，而它們在 Agent 產品裡都很常見。
第一種是帳戶抽象。ERC-4337 把使用者的意圖包成 UserOperation，先送進另一套流程，再由 bundler 提交真正的鏈上交易給 EntryPoint 合約；規格中另外定義了 Paymaster 這個角色，由它代為承擔手續費。結果是：鏈上那筆交易的送出者是 bundler 的地址，費用可能由 Paymaster 出，兩者都不是 Agent 自己。
第二種是元交易。ERC-2771 定義了受信任轉發者（trusted forwarder）的介面：使用者只簽名，由轉發者把交易送上鏈並付費，合約再從呼叫資料裡還原出原始簽署者。同樣地，鏈上看到的付費方是轉發者。
這兩種設計都不是問題本身，它們是為了讓使用者不必先持有原生代幣才能動作。要注意的是它們對自主性的含意：代付方可以停止代付。一個「完全自動運作」的 Agent，如果它的每一筆交易都由專案的 Paymaster 買單，那麼關掉它不需要動任何合約，只要把 Paymaster 的存款提走就行。這類停機點的完整清單，在誰能改掉或關掉這個 AI Agent？裡另有處理，本頁只負責把付費方找出來。
在瀏覽器上把這兩條線走完
區塊瀏覽器是公開鏈上資料的入口，能查到區塊、交易、帳戶與合約活動。下面的順序假設你手上只有一個地址，什麼都還不知道。
- 打開地址頁，先確認這是外部帳戶還是合約。出現合約相關頁籤的通常是合約帳戶，接下來要查的權限結構完全不同；這一層走偏了，後面全白做。
- 找第一筆入帳。部分瀏覽器會在地址概覽直接標出資金來源，但欄位名稱各站不同，也不是每個地址都顯示得出來；看不到就把交易列表排到最早一筆自己找。記下那個來源地址與交易雜湊。
- 把入帳排序，看節奏。一次性的大額、每週固定的小額、跟著用量走的不定期補款，是三種不同的營運模式，也對應三種不同的「停掉它有多容易」。
- 打開任意一筆由這個 Agent 發起的交易，看 From 是不是它自己。若不是，看交易是否送往 EntryPoint 或某個轉發者合約——這就是前一節說的代付結構，要順著找出真正的付費地址。
- 檢查 Internal Transactions（內部交易）分頁。合約之間的原生代幣移轉不會出現在一般交易列表裡，只看主列表會漏掉整條資金路徑。
- 把查到的每個地址回貼到專案自己的公開揭露裡對照。對得上就記下出處；對不上不要當成造假，先記為「揭露與鏈上不一致，待專案說明」。
整個過程請一併記下查證日期與區塊高度。資金結構是會變的，一份沒有日期的結論在三個月後既不能用，也不能被推翻。
查完之後能說什麼、不能說什麼
能說的通常是這幾句：這個地址的本金主要來自某一類來源；它的手續費由自己／某個代付方承擔；供給一旦中斷，可觀察到的動作會在多久之內停止。
不能說的比想像中多。鏈上看不到誰按了確認鍵，看不到帳戶背後的法律主體，也看不到鏈下的合約與付款。看到一個地址持續有資金進來，不代表專案財務健康——那是另一個題目，用可實現儲備與每月支出去算，寫在AI Crypto 專案 Runway：儲備與營運月數裡。
也不要把這份查證當成安全結論。資金來源清楚的 Agent 一樣可能因為權限過寬而把你的資產轉走；那條線要另外拉，動手方法在AI Agent 錢包權限：最大損失與控制設計。
資金與 Gas 查證清單
三項，查完再下結論。不評分，也不產生投資建議。若你要順手估一下這個專案的錢能撐多久，可以搭配專案 Runway 計算器，計算全部在你自己的瀏覽器完成。
檢查 01｜標記每一筆入帳的來源型別
- 查證動作
- 列出第一筆入帳與之後的定期入帳，逐筆標上交易所、金庫、合約或中轉四類之一。
- 應取得的證據
- 來源地址、交易雜湊、金額、時間間隔、查證區塊
- 會推翻判定的訊號
- 因為兩個地址收過同一個交易所熱錢包的錢，就判定它們同屬一人
- 本題判定規則
- 辨認不出的來源記「未查到」，不按產品敘事補齊
檢查 02｜找出真正的手續費付款方
- 查證動作
- 取幾筆代表性交易，確認送出者是 Agent 自己、bundler 還是轉發者，並追到實際承擔費用的地址。
- 應取得的證據
- 交易雜湊、送出地址、是否經 EntryPoint 或轉發者、代付方地址
- 會推翻判定的訊號
- 看到交易成功就認定 Agent 有能力自行負擔費用
- 本題判定規則
- 代付結構存在時，把「自主執行」的結論縮小到執行層
檢查 03｜測一次供給中斷的後果
- 查證動作
- 不必真的中斷，只需推算：若補款或代付停止，以目前餘額與平均單次費用還能執行多少次。
- 應取得的證據
- 目前餘額、近期平均單次手續費、推算次數與計算日期
- 會推翻判定的訊號
- 用單日最低費率外推長期，忽略網路擁塞時的波動
- 本題判定規則
- 結果只作為量級參考，明確標示為推算而非觀測
常見問題
Gas 由專案代付，是不是就代表這個 Agent 不是自主的？
不能直接這樣說。代付是為了讓使用者不必先持有原生代幣，屬於常見的產品設計。它說明的是：專案握有一個不必修改合約就能讓 Agent 停下來的開關。要不要因此調整對自主性的描述，取決於這個 Agent 宣稱自己自主到什麼程度。
查不到第一筆入帳的來源，該怎麼辦？
記為「未查到」並寫明卡在哪一步——是跨鏈之後斷了、來源是混合服務，還是瀏覽器沒有提供這個欄位。結論停在查得到的那一段，不要用推測往前延伸一層。
Agent 的錢包餘額很高，算是好訊號嗎？
只能說明它目前有可動用的資金。餘額高也可能代表權限過寬、該分開存放的資產放在同一個熱錢包裡。這個數字要和權限設計一起讀，單獨看沒有方向。
本檔案使用的來源
- ERC-4337: Account Abstraction Using Alt Mempool — UserOperation、bundler、EntryPoint 與 Paymaster 的角色定義；使用時仍須確認頁面日期與上下文。
- ERC-2771: Secure Protocol for Native Meta Transactions — 受信任轉發者代送交易與還原原始簽署者的介面；使用時仍須確認頁面日期與上下文。
- Transactions — 交易欄位與手續費由誰負擔的一手說明；使用時仍須確認頁面日期與上下文。
- Block explorers — 區塊瀏覽器可查到的帳戶與交易資料範圍；使用時仍須確認頁面日期與上下文。
- Ethereum accounts — 外部帳戶與合約帳戶的差異；使用時仍須確認頁面日期與上下文。