AI 代理用區塊鏈當信任層

這篇拆解 AI 代理怎麼把區塊鏈當信任層，最後給你一份能直接複製的安全模板。

我玩 AI 代理一陣子了，老實說，最卡的地方不是模型不會講話，是大家太快把權力塞給它。demo 一做，像人一樣下指令、像人一樣呼叫錢包、像人一樣自動執行，表面很順。可我每次都會多問一句：它如果亂轉一筆錢、亂打一次合約、或在錯的時機做了對的事，誰收拾？通常答案都很空，差不多就是「模型會自己判斷」。我對這種說法很不耐煩，因為錢包不是玩具，鏈上操作也不會因為你 prompt 寫得漂亮就自動安全。

後來我看了 Toshendra Kumar Sharma 在 Blockchain Council 的文章，整個脈絡就清楚了：區塊鏈不是拿來當 AI 的大腦，而是拿來當信任層。身份、權限、付款、協作、稽核，這些才是它該做的事。AI 代理負責想，鏈負責卡住它、驗證它、留下證據。這篇我就是照這個框架拆，順便把我會真的拿去用的安全寫法整理出來。

區塊鏈不是腦袋，它是裁判

“Blockchain gives autonomous software agents a trusted environment for identity, payments, coordination, smart contract execution, and auditability.”

翻譯一下就是：區塊鏈不是讓代理變聰明，它是讓代理的身分、權限、付款和結果有地方可查。這差很多。很多團隊一開始就想把推理、記憶、資金、執行全塞進同一個系統，最後不是難審就是難救。

我自己最常看到的錯誤，是把鏈當成「多一層儀式感的資料庫」。不對。鏈比較像規則引擎加收據本。代理可以在鏈下決定要做什麼，但真正的提交、驗證和記錄，應該由鏈來收尾。你如果把這兩件事混在一起，設計很快就會鬆掉。

文章裡提到代理會感知輸入、推理目標、再採取動作，這描述沒錯，但工程上更重要的是：哪一步在哪裡做。推理放鏈下，因為它貴、也需要彈性。結算放鏈上，因為它要可驗證、可追蹤。身份和授權最好也要有鏈上錨點，不然你根本不知道到底是誰在動錢。

我之前做過一個可以調整 token 部位的錢包代理，第一版很勇，能看餘額、選路徑、送 swap。結果一模擬壞行情，我就看到它還是能用「看起來合理」的方式一路把損失放大。那時候我才真的懂，問題不是 prompt 不夠會說話，是權限放太鬆。後來我把權力收回合約，設硬上限、白名單和明確的批准門檻，事情才像樣。

實操寫法很簡單：把架構拆成三層。第一層是鏈下推理，只負責規劃和工具選擇。第二層是鏈上約束，負責權限和結算。第三層是稽核層，把 prompt、政策決策、交易 hash 都留下來。你如果講不清楚每層的邊界，通常代表設計太鬆。

• 模型推理盡量留在鏈下。
• 花費上限、角色檢查、執行規則放進合約。
• 把簽名動作和 hash 存起來，方便事後重建。

智能合約讓代理停止自由發揮

“Once a transaction is confirmed, the outcome is recorded on-chain and can be independently verified.”

白話就是：一旦上鏈，結果就不是你口頭說了算。這就是智能合約在這裡的重要性。AI 代理擅長調整，合約擅長拒絕亂來。你兩個都要，但不能混成一坨。

文章拿 DeFi 當例子很合理。代理可以盯流動性池、借貸協議、價格變化，然後調整部位或移動資金。這確實有用，因為市場跑得比人快。但真正防止它亂飛的，是合約把行為限制在你設定的範圍內。只能在目標區間內 rebalance，只能在預算內調 collateral，只能在驗證過的 off-chain 事件之後觸發函式。

我很喜歡這種做法，因為它直接拆掉一個幻想：不是「模型會知道什麼該做」，而是「模型會提出一個看起來合理的動作，合約再判斷允不允許」。這兩件事不能混在一起。模型負責提案，合約負責說不。

最麻煩的是 deterministic settlement。鏈上執行不是比誰更聰明，而是把最終狀態講清楚。做交易、管 treasury、或任何不能隨便回滾的事，這點都很重要。你如果寫過 bot，知道那種「大致正常，遇到波動就開始發瘋」的感覺，這裡就是解法。

實操寫法：先定義代理能碰的 action space，再讓它碰錢包。不要給它 raw transaction 權限。改成一組狹窄的 callable functions，每個參數都有限制。每次送出前先跑 simulation，失敗就直接擋掉，不要讓它自己重試到成功為止。

• 白名單合約與 function selector。
• 每筆、每日、每交易對手都設上限。
• 每次 state-changing 交易都先 preflight simulation。

自動付款有用，但也很會出事

“Circle has demonstrated patterns where agents can hold USDC and make autonomous payments.”

這句很容易讓人眼睛發亮，因為一旦代理能持有 USDC，它就能自己付 API、資料、算力、訂閱費，甚至付另一個 agent 的工錢，不用人類一直按 approve。這確實方便，等於把軟體從建議系統拉成經濟體的一員。

但我也看過太多團隊在付款這件事上翻車。能付，就代表也可能付太多、重複付、付錯人、或任務結束了還在付。文章提到的 guardrails 很務實：日限額、核准供應商、多簽、緊急暫停。這些不是裝飾，是差別在「有用的 treasury bot」和「有性格問題的錢包」之間。

我最反感的是有人想靠 prompt discipline 解決付款風險。這真的不行。prompt 不是支付政策。只要代理碰得到 custody，你就要把規則放在 protocol 或 contract 層。代理可以提案，但真正放行要有另一個系統照硬規則判斷。

如果是 machine-to-machine commerce，穩定幣的價值就更明顯。像 USDC 這種資產，拿來做微付款、訂閱、按量計費比較正常，不會今天一小時一個價。文章提到 agent marketplace、cloud usage、subscriptions，我覺得方向是對的。支付通道不是難點，難的是別讓代理超支。

實操寫法：把「可以提案付款」和「可以放款」切開。付款門檻寫進 code，不要只寫在 README。新供應商要二次簽核，定期付款要設 expiry，超過閾值要人類簽字。這些規則寫不進去，就別說你有安全設計。

• 用穩定幣做可預測的代理支出。
• 高於門檻就走 approval workflow。
• 緊急暫停和撤權路徑要簡單到你半夜也會用。

多代理協作要的是法庭，不是聊天室

“Blockchain supports secure collaboration among multi-agent systems by enabling identity, incentives, task allocation, and verifiable records without a central broker.”

這段我很買單，因為它比較像系統設計，不像行銷話術。只要代理超過一個，協作問題就會冒出來：誰接單、誰付款、誰驗證、誰背鍋。你如果沒有答案，那你不是在做系統，你是在堆一群會講話的 bot。

區塊鏈在這裡的價值，是給所有代理一個共享事實來源。A 代理可以發起分析，B 代理可以提供算力，C 代理可以驗證結果，合約則負責記錄誰做了什麼。這對跨團隊、跨組織尤其有用，因為沒人想信別人的私有 log 檔。大家都想要能獨立檢查的紀錄。

我自己做分散式工作流時也碰過這種事：一個服務產出結果，另一個驗證，第三個付款。沒有共享帳本時，爭議最後都變成 email 考古。上鏈之後，爭議至少會變成 contract question。還是很煩，但至少比較有邏輯。

重點不只是記錄結果，而是協調激勵。如果任務需要抵押，合約可以先扣著。如果驗證錯了，合約可以 slash。如果交付完成，合約就釋放款項。這比期待每個 agent 都自動守規矩實際多了。

實操寫法：把鏈用在任務分配、付款釋放、爭議證據。重推理和資料處理留在鏈下。每個 agent 都要有鏈上身份、允許的任務類型、和 payout 規則。凡是需要驗證的任務，先把 verifier 寫清楚，再開始做。

• 每個 agent 綁一個鏈上身份。
• 會失敗的工作要有 escrow 或 collateral。
• 爭議流程先寫好，不要等出事才補。

DAO 治理需要的是韁繩，不是王冠

“A DAO may delegate limited voting authority to an agent under strict rules.”

這裡最容易失控。是，代理可以幫你整理提案、檢查政策一致性、甚至建議怎麼投票。不是，這不代表你該把金庫鑰匙丟給它，然後把這叫做治理創新。

文章的平衡感我覺得剛好：有限委派、嚴格規則、不可竄改紀錄。這才是正解。代理可以處理例行參數變更，也可以把風險提早攔出來，但重大 treasury 決策還是要人類明確限制權限。不然你只是把治理包裝成自動化表演。

我看過 DAO 工具一路漂到這個坑裡。說法都一樣：讓 agent 處理瑣事嘛。問題是瑣事只要規則不夠清楚，就會在某天變成燒錢大事。代理如果能投票，就要有 policy envelope：它能碰哪些類別、超過什麼門檻要 review、什麼情況自動升級給人。

區塊鏈在這裡的價值是稽核。代理如果投錯票，你至少要知道是模型輸入爛、政策失誤，還是權限 bug。鏈上 log 不會幫你變聰明，但至少讓你有機會還原現場。沒有這個，你只是在猜。

實操寫法：把治理委派當成 scoped API key。給它窄權限、過期時間、和 review 條件。每次看了什麼提案、做了什麼建議、投了什麼票，都要記錄。DAO 如果事後查不到這條路徑，代表委派太大。

混合架構才是正常答案

“Most practical architectures use a hybrid model: AI reasoning runs off-chain, while blockchain handles settlement, verification, identity, and access control.”

這句我真的想印出來貼在會議室。因為大多數團隊一開始都會想走極端，結果不是算力太貴，就是鏈上太痛。比較務實的答案幾乎永遠是 hybrid。

也就是說，模型推理留在鏈下，像是跑在 Amazon Bedrock 這種服務上；鏈則負責它最擅長的事：記錄狀態、強制權限、完成結算。文章也提到 Circle 的自動付款模式，還有公鏈基礎設施做可驗證動作，這套 stack 我覺得合理，因為它把昂貴的智能和不可逆的動作分開了。

我做過最順的系統，通常都不是把 agent 當成一個大黑盒，而是當成一個 planner，加上一條很硬的 policy boundary。planner 可以亂想，boundary 不行。那條邊界要包含 least privilege、transaction simulation、rate limit、監控，還有 emergency kill switch。少一個都不太對。

實操寫法：把鏈上 surface area 壓到最小。記憶、檢索、推理都放鏈下。custody、settlement、permissions 放鏈上。兩邊都要監控。只要代理行為變了，你要能立刻分辨是模型變了、資料變了，還是合約規則變了。

• 鏈下：inference、retrieval、planning、orchestration。
• 鏈上：identity、custody、settlement、constraints。
• 永遠要有監控、告警和快速關機的方法。

可抄的模板

# AI Agent + Blockchain 安全模板

## 目標
做一個能提案、能執行區塊鏈動作的 AI 代理，但不要讓它有無限制的錢包控制權。

## 預設架構
- 鏈下：模型推理、檢索、規劃、工具選擇
- 鏈上：身份、權限、結算、稽核紀錄
- 政策層：交易模擬、限額、批准、撤權

## 元件
1. Agent Planner
   - 讀取使用者意圖
   - 產生候選動作
   - 不直接簽交易

2. Policy Engine
   - 檢查允許的合約
   - 強制執行支出上限
   - 擋掉未知對手方
   - 超過門檻就要求批准

3. Simulation Layer
   - 執行 preflight simulation
   - 比對預期與實際狀態變化
   - 拒絕不安全或不明確的呼叫

4. Execution Wallet
   - 最小權限
   - 只保留任務所需資金
   - 可立即暫停或撤銷

5. Audit Log
   - 儲存 prompt、model output、policy decision、tx hash
   - 記錄 timestamp、chain、contract、function、amount
   - 留下人類可讀的批准或拒絕理由

## 安全規則
- 只允許白名單合約和 function selector
- 設定單筆與每日支出上限
- 新供應商或新合約地址要人類批准
- 重複動作要有 rate limit
- 加一個能暫停所有外發交易的 kill switch
- 定期輪換金鑰
- 分離 planner credentials 與 custody credentials

## 範例 policy
yaml
agent_name: treasury-bot
mode: propose_and_execute
allowed_chains:
  - ethereum
  - base
allowed_contracts:
  - 0xYourWhitelistedContract1
  - 0xYourWhitelistedContract2
max_tx_value_usd: 250
max_daily_value_usd: 1000
require_human_approval_over_usd: 250
require_simulation: true
allow_new_counterparties: false
emergency_pause_enabled: true

## 執行流程
1. 使用者或系統建立任務。
2. Agent 提案交易。
3. Policy engine 檢查規則。
4. Simulation 執行。
5. 若安全，由 execution wallet 簽名並送出。
6. Audit log 記錄全部內容。
7. 監控系統對異常發告警。

## 不要這樣做
- 不要讓模型拿著 full funds 的 hot wallet
- 不要因為交易看起來簡單就跳過 simulation
- 不要把 prompt 當成安全政策
- 不要讓失敗後無限制重試
- 不要把治理投票和 treasury custody 混在一起

## 最小人工接管
- 暫停所有交易
- 撤銷錢包權限
- 凍結新的對手方批准
- 匯出稽核歷史
- 輪換金鑰並重新部署政策規則

我喜歡這個模板的地方，是它把 agent 當成有用的員工，不是神奇操作員。它可以提案，可以執行，但不能偷吃自己沒賺來的信任。這種設計才撐得住真的錢。

來源我拆的是 Blockchain Council 上 Toshendra Kumar Sharma 的文章。我上面講的架構判斷和模板，是我根據原文再加上我自己會真的放進 production 的安全邏輯整理出來的。