AI Agent 不只是需要一個錢包

最近讀到 Christian Crowley 等六位作者在 a16z crypto 發表的 《The missing infrastructure for AI agents: 5 ways blockchains can help》^[1]。他們把 AI Agent 的身分、治理、支付、信任和使用者控制放在一起討論。我尤其認同，問題不能被縮成「讓 Agent 能付款」這一件事。

文章有兩句很直接的話，也是我想回應它的原因：

“The bottleneck for the agent economy is now identity, not intelligence.”

（譯：Agent 經濟的瓶頸，如今是身分，而不是智慧。）

“Scale without verification is a liability that builds over time.”

（譯：沒有驗證就擴大規模，是一筆會隨時間不斷累積的負債。）

我大體認同這兩個判斷。當 Agent 不再只是聊天視窗裡的助手，而是開始代表人和組織呼叫服務、花錢、交付結果時，舊網際網路確實缺少一些基礎設施。但我還想把重點往前挪一步。AI Agent 不只是需要一個錢包。

ArcBlock 長期投入去中心化身分、Blockchain 和應用基礎設施。

支付是最容易看見的情境。一個 Agent 呼叫 API、買一份資料、完成一項服務，然後自動付款，這當然很重要。可在它付款之前，系統應該先能回答幾個更基礎的問題：它是誰，代表誰，誰授予了它權限，權限到什麼範圍，出現異常後誰能核對發生過什麼。沒有這些問題的答案，錢包只是一把被交給程式的鑰匙。

我認同五個問題，但它們其實是一條責任鏈

Crowley 等六位作者把身分、治理、機器支付、可驗證信任和使用者控制分開講，這樣很有幫助。對我來說，在真正運作的 Agent 系統裡，它們往往不是五個獨立的產品類別，而是一條連續的責任鏈。

Agent 先要有身分，別人才能知道它是誰。它有了身分，才談得上誰能夠授權它。授權有了範圍，才知道它能花多少錢、能呼叫哪些服務、能不能代表一個團隊簽發某種結果。發生了操作之後，記錄才有辦法被驗證、對帳和追溯。最後，使用者才能判斷自己究竟是在使用一個 Agent，還是把自己交給了一個不透明的平台。

ArcBlock 與此自然銜接。我們長期採用 DID，Decentralized Identifier，可以把它理解為不依賴某個平台臨時帳號、可長期沿用且可被驗證的身分識別碼。核心不是給每個對象多貼一個加密標籤，而是讓人、裝置和未來的 Agent 都能擁有這樣的身分。DID Connect 是圍繞身分、登入和簽名互動的基礎；DID Spaces 則是使用者的資料空間。它們都不是為了今天的 Agent 臨時拼出來的概念，而是在處理身分、授權和資料不應天然附屬於某一個平台或某一次應用安裝的問題。

這也是我不太喜歡「Blockchain 能不能讓 Agent 付款」這種問法的原因。它把最容易示範的一步，當成了最難的一步。真正難的是委託。

小額熱錢包能限制損失，卻不能解釋授權

今天的機器支付協議，例如 x402，解決了一件很實際的事：讓服務請求和付款可以在同一條機器流程裡完成。小額餘額、虛擬卡或受限 wallet 也都有價值。這裡的 hot wallet 指連接在線上程式上的錢包或帳戶，它們至少能把最壞情況下的損失壓低。

但它們不會自動回答：這個 Agent 為什麼能花這筆錢？它受誰指派？允許它花在哪些服務上？預算、時間、次數和撤銷條件在哪裡？如果一個團隊發現異常消耗，能不能沿著證據找出是哪一項授權、哪一個 Agent、哪一次呼叫出了問題？

這不是 Agent 出現後才有的問題。我們在做去中心化應用時，早就遇到過類似的矛盾：不能要求使用者為每一筆自動化交易都重新拿出錢包簽名，也不能把使用者的主私鑰長期放在線上服務裡，讓程式自行決定一切。前者無法自動化，後者很難談安全邊界。

因此，我們長期在思考的不是「怎樣讓程式代替使用者拿著錢」，而是怎樣把身分、委託範圍、額度、規則和責任鏈拆開表達。DID 可以提供身分與驗證關係；委託或能力模型，也就是說明一份憑據具體能做什麼、不能做什麼的規則，負責定義範圍與約束；Verifiable Credentials，或 VC，可以作為帶簽名、可獨立驗證的證據載體。這樣，Agent 即使需要使用自己的受限憑據，也不必把使用者的主私鑰託管給一個常駐線上服務。

我並不認為這會讓風險憑空消失。它只把問題從「某個程式拿著一把鑰匙」變成「誰在什麼條件下交出了哪一把受限的鑰匙」。後者至少可以被討論、檢查和撤回。

帳本的價值，往往在付款之後才開始顯現

PaymentKit 是 ArcBlock 已有的支付抽象層。支付本來就不是新問題，Agent 讓它變得更重要，是因為一筆付款會拉出更多問題。

想像一個團隊同時使用多種 AI 服務。不同的 Agent 在呼叫外部工具，員工也在使用 API key，最後帳單又從另一個系統裡出來。某天金額不對，你看到的通常只是幾份彼此獨立的記錄：供應商帳單、信用卡交易明細、內部日誌。到底是服務方計費出了問題、某個 key 被濫用、員工超出了權限，還是內部系統沒有把授權傳對，往往很難說清。

我不認為答案是把所有日誌都寫到 public chain。那既不必要，也不合理。我們更傾向這樣判斷：記錄應該隨著信任邊界分層。

Receipt、invoice、服務交付、第三方服務呼叫，以及誰授權、誰使用、如何消耗等資訊，都可以用 VC 這類可驗證資料格式表達，再依情境保存在合適的帳本層。這裡的 ARC 是 Agentic Realm Computer，也就是 ArcBlock 正在建構的面向人和 Agent 的執行環境與計算架構。這是我們希望 ARC 逐步承接的方向，不是說完整的鏈端介接、鏈上結算和多層流程今天已經全部交付。

這樣的記錄也不會自動證明一個服務做得對，更不會自動替人承擔責任。它的作用更樸素：當一個 Agent 世界開始複雜到人不可能逐筆盯住時，至少讓重要動作留下能由適當的相關方驗證的證據。

鏈應該是證據邊界，不是每個動作的目的地

a16z 文章提到，隨著自動化執行變得便宜，驗證會變得昂貴。我同意。人不可能靠所謂 human in the loop，也就是由人逐筆介入複核，去審查成千上萬個 Agent 的每一次呼叫。

不過，Blockchain 在這裡的價值不該被說成「它產生信任」。Blockchain 可以提供持久證據、共同帳本和可執行的約束條件；正確性、服務品質、爭議處理和最終責任，仍然需要系統設計和人來承擔。把這兩件事混在一起，反而會把討論說得太輕鬆。

所以，不是每個 Agent 都必須上鏈。如果一個 Agent 只是在本地整理一份草稿，最簡單的工具通常就是最好的工具。但當它代表使用者或組織跨系統行動，涉及錢、權限、可驗證的交付或多方對帳時，身分、委託和記錄就不該只留在某一家平台的後台裡。

這也是我從那篇文章裡讀到、但想補上的一句話：支付只是入口。對 Agent 更根本的基礎設施，是一條可驗證的委託鏈。它要讓我們回答清楚：誰在行動，誰授權了它，它能做什麼，出了問題後又能如何核對。

參考