MCP 的「USB 介面」比喻具體是什麼意思？它解決了什麼過去必須手動解決的問題？
在 MCP 出現之前，AI Agent 要使用每一個外部工具，都需要開發者寫一段專屬的整合程式碼——定義怎麼呼叫這個 API、參數格式是什麼、回傳結果怎麼解析、錯誤怎麼處理。五個工具就要五段整合程式碼；換一個 Agent 框架，這些程式碼可能要重寫。
USB 介面在電腦世界解決了同樣的問題：在 USB 出現之前，每種周邊設備（鍵盤、滑鼠、印表機）都有自己的接頭和通訊協議，要換設備就要換接頭。USB 統一了這一切——任何 USB 設備插進任何 USB 電腦就能用，不需要客製化。
MCP 在 AI 世界做了同樣的事：它定義了工具和 Agent 之間通訊的標準格式——怎麼列出工具功能（tool listing）、怎麼傳參數（JSON 格式）、怎麼回傳結果、怎麼處理錯誤。任何工具只要按 MCP 標準實作 Server，任何 MCP-compatible 的 Agent 就能直接用。
對加密世界的直接意義：一個 MCP Server 封裝了「查詢 Uniswap 某交易對價格」這個功能，任何接入 MCP 的 Agent（不管是 LangChain 還是 ElizaOS）都能直接調用，不需要各自重寫一次。
MCP Server 被惡意攻擊（MCP Server 污染）是怎麼一回事？在加密場景為什麼特別危險？
MCP Server 污染攻擊的原理：當 Agent 透過 MCP 調用一個工具時，它信任這個 MCP Server 回傳的結果是真實的。如果攻擊者控制了或偽造了一個 MCP Server，它可以在工具的回傳結果裡注入假資料——告訴 Agent「ETH 現在只值 $100」（實際是 $3,000），或者在 Observation 資料裡插入惡意指令，讓 Agent 的下一輪 Thought 被汙染，做出攻擊者希望的行動。
為什麼在加密場景特別危險：因為 Agent 的 Action 步驟可以直接簽署鏈上交易。如果 Thought 被汙染的 Agent 決定「現在是最佳買入時機」（基於假資料），它可能自主簽署一筆大額買入交易——而這筆交易在鏈上是不可逆的。傳統 Web2 的 API 攻擊最多讓你拿到錯誤資料；加密場景的 MCP 攻擊可以直接讓你的資產歸零。
防禦方式：只使用來源可驗證、有開源代碼的 MCP Server；對 MCP 回傳的價格類數據設定合理性驗證（偏離上次已知價格超過 X% 就拒絕接受）；把查詢 MCP Server 和簽署交易的 Agent 權限分開；考慮使用多個獨立數據源交叉驗證關鍵數據。
MCP、A2A（Agent-to-Agent）和 x402 這三個協議各自解決什麼問題？在加密 Agent 的技術棧裡怎麼分工？
三個協議解決的是 AI Agent 生態系統裡三個不同層次的問題。
MCP（工具調用層）：Agent 怎麼和「工具」（軟體服務、API、數據庫）溝通。MCP 定義的是 Agent 和工具之間的語言——怎麼告訴工具「我要查什麼」、工具怎麼回答「我找到了什麼」。MCP 讓工具整合標準化，一個工具的 MCP Server 可以被任何 Agent 調用。
A2A（Agent 間通訊層）：Agent 怎麼和另一個 Agent 溝通、分工協作。A2A 定義的是 Agent 之間的通訊協議——怎麼委派子任務、怎麼傳遞中間結果、怎麼協調多個 Agent 的行動。一個「主 Agent」可以透過 A2A 把任務分配給多個「子 Agent」。
x402（支付層）：Agent 怎麼在 HTTP 層完成服務付費。x402 讓 Agent 在獲得服務之前先在 HTTP 層用穩定幣完成支付，不需要人類帳戶和信用卡。
在加密 Agent 技術棧裡的分工：用 MCP 連接鏈上數據工具和 DEX API；用 A2A 讓分析 Agent 和執行 Agent 協作；用 x402 讓 Agent 自主支付數據訂閱費用。三層合在一起，Agent 才能從「取得資訊」到「做決策」到「付費執行」形成完整自主的運行閉環。
作為加密 Agent 的開發者或使用者，怎麼評估一個 MCP Server 是否值得信任？
這個問題在加密場景下格外重要，因為一個不可信的 MCP Server 可能直接影響 Agent 的鏈上操作決策。評估可信度的四個維度：
第一，來源可驗證性：這個 MCP Server 是誰開發的？有沒有公開的 GitHub 代碼倉庫？代碼是否開源可審計？沒有開源代碼的 MCP Server，你沒有辦法知道它在做什麼。已知可信的 MCP Server 通常來自知名協議官方（如 Uniswap 官方的數據 MCP）或知名基礎設施提供商（如 QuickNode、Alchemy）。
第二，數據回傳的可驗證性：這個 MCP Server 的回傳結果能不能和另一個獨立來源交叉核驗？例如，一個鏈上價格 MCP Server 的報價，能不能和另一個價格來源在 1% 以內對齊？如果偏差異常，就是警訊。
第三，最小必要工具原則：這個 MCP Server 請求的權限有沒有超出它聲稱的用途？一個「只查詢 ETH 價格」的 MCP Server 不應該需要你的錢包簽章權限。權限要求超出預期的工具應該拒絕。
第四，社群和審計記錄：這個 MCP Server 有沒有被主流的 Agent 框架社群列入推薦清單？有沒有安全審計報告？在使用任何 MCP Server 管理真實資產之前，這些都是必要的盡職調查。
MCP 在加密 Agent 裡的實際運作：一個 DeFi 監控 Agent 的工具調用流程
場景：一個監控 Agent 需要判斷「現在 Aave 的 USDC 存款利率是否值得從 Compound 移倉」。
沒有 MCP 的世界：開發者要為 Aave 資料查詢寫一段整合程式碼，再為 Compound 資料查詢寫另一段，再為 Gas 費查詢寫第三段，再為交易執行寫第四段。四個工具四套程式碼，換一個 Agent 框架還要重寫。
有 MCP 的世界：開發者直接在 Agent 的設定裡列出四個 MCP Server（aave-data-mcp、compound-data-mcp、gas-oracle-mcp、wallet-sign-mcp），Agent 的 Thought 步驟自己決定調用哪個、怎麼傳參數。整合程式碼量從四套減少到零。
實際執行過程：
aave-data-mcp 的 get_supply_apy(asset='USDC')compound-data-mcp 的 get_supply_rate(token='USDC')gas-oracle-mcp 的 estimate_gas(action='rebalance')整個流程 Agent 自主完成，每個 MCP Server 的職責清楚分離，事後可逐步審計。
MCP 的核心取捨是「標準化的便利 vs 供應商依賴」。採用 MCP 標準讓工具整合極度簡化，任何 MCP-compatible 的工具都能即插即用；但這也意味著你依賴這些 MCP Server 的可用性和可信度。如果某個關鍵的鏈上數據 MCP Server 出現故障或被攻擊，你的 Agent 就失去了資訊來源，可能做出基於陳舊資料或錯誤資料的決策。
另一個取捨：MCP 的標準化讓不同 Agent 框架之間的工具可互換，但也讓惡意 MCP Server 更容易被偽裝成可信工具——因為形式和合法 MCP Server 完全一樣，只有回傳的內容不同。標準化降低了技術門檻，也降低了識別惡意工具的門檻。因此關鍵工具（特別是涉及鏈上操作的）應該只用來源清楚、可審計的 MCP Server，不因為「方便整合」就降低安全要求。