為什麼 LLM 不直接執行工具，而是輸出一個「請求」讓後端去執行？這個設計是技術限制還是刻意的安全選擇？
這是一個設計上的刻意選擇，不是技術限制。LLM 在技術上可以設計成直接調用外部系統，但這樣做有幾個根本性的問題：
第一，安全性：如果 LLM 能直接執行工具，一旦它被 Prompt Injection 攻擊（惡意指令注入），攻擊者就能直接讓它執行任意操作。現在的設計讓攻擊者只能影響 LLM 輸出「請求」，但你的後端可以在執行前驗證這個請求是否符合安全規則。
第二，可控性：把執行層放在後端，你可以動態地改變「哪些工具可以在什麼條件下被調用」，而不需要修改 LLM 本身。比如你可以在市場劇烈波動時暫時停用所有「寫入工具」，這個控制在後端直接實施，LLM 不需要知道。
第三，可審計性：後端的每次工具執行都可以完整記錄（調用了什麼、帶什麼參數、回傳了什麼、執行結果如何）。如果 LLM 直接執行，這些日誌就散落在 LLM 的推理過程裡，難以追蹤。
第四，跨模型可移植：把工具定義在後端，你可以無縫切換底層 LLM（從 GPT-4 換成 Claude，或換成開源模型），工具本身不需要重寫。
這個「LLM 說、後端做」的設計模式，是目前 AI Agent 架構的基本共識，也是為什麼 MCP 這樣的標準能夠存在的原因——它標準化的是「LLM 怎麼表達請求」，不是「工具怎麼執行」。
工具的「schema」（結構描述）設計得好不好，對 Agent 的性能有多大影響？
工具 schema 的設計對 Agent 的推理品質有巨大影響，這個點在很多技術文件裡被低估了。
什麼是工具 schema：就是你告訴 LLM「這個工具叫什麼名字、能做什麼、需要什麼參數、每個參數的類型和含義是什麼」的說明文件。LLM 的 Thought 步驟讀這份說明來決定要不要調用這個工具、怎麼傳參數。
設計得差的 schema 帶來什麼問題：工具名稱模糊（tool_1、execute_thing）讓 LLM 不知道這個工具能做什麼；參數說明不清楚讓 LLM 傳錯參數格式；沒有說明「什麼情況下應該用這個工具」讓 LLM 在不合適的時機調用它。
好的 schema 設計應該包含：清楚的工具名稱（動詞+名詞，例如 get_eth_price、sign_transfer_transaction）；每個參數的詳細說明（類型、格式、範例值、有效範圍）；工具的適用場景描述（「當你需要查詢 ETH 的現價時調用此工具」）；以及返回值的格式說明（這讓 LLM 知道如何解讀工具的回傳結果）。
實際測試顯示，同樣的 Agent 任務，工具 schema 優化後，工具調用的準確率可以提高 30-50%，LLM 誤用工具的頻率大幅下降。在加密場景，工具調用準確率直接影響交易的正確性——這不是小事。
如果一個工具調用的請求被安全閥門攔截了（例如超出金額上限），Agent 會怎麼處理？它能理解「被拒絕」這件事嗎？
這是多 Agent 和 Tool Use 設計裡一個容易被忽略的問題：被攔截的工具請求，應該怎麼回報給 LLM？
如果你的後端攔截了一個工具請求但什麼都不回應，LLM 可能會認為工具調用「卡住了」，然後重試，形成重試迴圈。或者它可能繼續推理，但基於「我不知道工具執行結果如何」這個不確定狀態，做出錯誤的後續決策。
正確的設計是讓後端在攔截請求時，回傳一個有意義的錯誤訊息給 LLM——例如：「工具請求被拒絕：請求金額 $500 超出設定的每日上限 $100。請拆分為較小金額或等待用戶手動確認。」
現代的 LLM 可以理解這類錯誤訊息，並在 Thought 步驟中調整策略——它可能會拆分請求、選擇不同的工具、或直接告訴用戶「這個操作超出了我的授權上限，需要你確認」。
設計建議：每個工具在拒絕執行時，都應該回傳清楚的、人類可讀的錯誤原因，而不只是 error code。這讓 LLM 能夠做出有意義的調整，而不是在不確定狀態裡亂推理。安全攔截的目的不只是「防止壞事發生」，還要讓 Agent 能優雅地從被攔截中恢復。
MCP Server 和「工具」是同一件事嗎？我開發 Agent 時什麼情況下需要自己寫 MCP Server？
這兩者有關係但不是同一件事。
「工具」是一個廣義的概念——任何 Agent 可以調用的外部能力都是工具，不管用什麼技術實作。你可以用最原始的方式定義工具：在 LangChain 的 Python 程式裡直接寫一個函數，用 @tool 裝飾器標記，LangChain 會自動把它轉換成 LLM 能理解的 schema。這個工具沒有 MCP Server，但完全可以運作。
MCP Server 是工具的一種「標準化打包和分發方式」。把工具封裝成 MCP Server，任何支援 MCP 的 Agent 框架（LangChain、ElizaOS、Claude）都能直接使用這個工具，不需要為每個框架各自整合一次。MCP Server 讓工具變成「可跨框架、可跨 Agent 復用的服務」。
什麼情況下需要自己寫 MCP Server：你想讓你的工具被多個不同框架的 Agent 共用；你想讓工具可以被外部的 Agent（不是你自己的）付費使用（透過 ERC-8257 和 x402）；或者你想提供工具給社群（就像在 npm 發布一個 package）。如果你只是為自己的 Agent 開發一個內部工具，不需要共用或商業化，直接在框架裡定義函數就夠了，不需要 MCP 的複雜度。
AI Agent 最核心的能力不是「思考」，而是「行動」。思考只是 LLM 的文字預測；行動才是讓 Agent 和真實世界產生連接的機制。Tool Use（工具調用）就是這個機制的實作方式——它定義了 Agent 如何發出一個「我想做某件事」的請求，外部系統如何執行，以及結果如何回來影響 Agent 的下一步推理。
理解 Tool Use 的運作原理，不只是技術問題。在加密場景，Tool Use 的設計直接決定了「Agent 能不能在你不知情的情況下動你的資產」這件事。
Tool Use 的概念很直觀：你給 LLM 一份「工具清單」，告訴它「你可以調用這些工具」。工具可以是任何東西——查詢 ETH 現價的 API、讀取 Aave 存款利率的函數、簽署一筆交易的介面，甚至發送一封 email 的能力。
實作層面，這個過程分四步：第一，你在 System Prompt 或 API 參數裡告訴 LLM 哪些工具存在、各自的名稱、功能描述和參數格式。第二，LLM 在推理過程中，如果判斷「我現在需要調用某個工具」，它不是直接執行工具，而是輸出一段結構化的「工具調用請求」——通常是 JSON 格式，指定要調用哪個工具、帶什麼參數。第三，你的應用程式（不是 LLM）讀取這個請求，真正執行工具（呼叫 API、執行函數、讀取數據庫）。第四，把工具的回傳結果塞回 LLM 的上下文，讓 LLM 繼續基於這個結果推理。
關鍵點：LLM 本身不執行任何工具。它只是「說」它想做什麼，真正執行的是你的後端程式碼。這個設計看起來像繞路，但它是整個安全性的基礎——因為執行層在你的控制下，你可以在那裡加入任何安全驗證邏輯。
你可能同時看到「Function Calling」（OpenAI 的術語）和「Tool Use」（Anthropic Claude 的術語）這兩個說法，讓人困惑它們是否是不同的東西。
本質上，兩者解決的是同一個問題，機制幾乎相同。差異主要在 API 設計和格式細節。OpenAI 的 Function Calling（後來改稱 Tool Use）在 GPT-4 時代就有，格式上用 functions 參數傳入工具清單；Anthropic 的 Tool Use 在 Claude 3 系列正式推出，格式上用 tools 參數。MCP（Model Context Protocol）則是在這之上再加一層標準化——不是替代 Function Calling 或 Tool Use，而是讓工具的定義和分發標準化，讓同一個工具可以被不同的 LLM 和 Agent 框架調用。
從使用者角度，最需要知道的是：不管底層用哪個模型，現代的 AI Agent 幾乎都透過類似的機制讓 LLM 調用工具。框架（LangChain、ElizaOS、AutoGen）只是在這個機制上加了一層便利的封裝。
Tool Use 最重要的安全問題不是「工具能不能被調用」，而是「工具被調用的結果有沒有被驗證」。幾個關鍵的安全設計維度：
工具的分類管理：把工具分成「只讀工具」（查詢價格、讀取鏈上狀態、搜尋數據）和「寫入工具」（簽署交易、移動資金、修改設定）。只讀工具出錯的後果是資訊錯誤；寫入工具出錯的後果可能是資產損失。兩類工具應該設計不同的授權和驗證機制。
工具的參數驗證：LLM 輸出的工具調用請求需要在執行前驗證參數合理性。如果 Agent 要求調用「轉帳」工具，但參數裡的收款地址不在白名單、金額超過設定上限——這個請求應該被攔截，而不是直接執行。
工具調用的日誌：每一次工具調用（包括請求參數和回傳結果）都應該被完整記錄。這是事後審計的基礎——如果 Agent 做了一個你不理解的操作，日誌能讓你追溯到底是哪個工具調用、帶了什麼參數、回傳了什麼。
工具回傳的可信度驗證：工具回傳的結果不應該被無條件信任。如果一個價格查詢工具突然回傳「ETH = $0.01」，這個結果應該觸發異常處理，而不是讓 Agent 基於這個錯誤資訊做出下一步決策。Prompt Injection 攻擊的核心機制就是污染工具的回傳結果。
在加密 Agent 的實際部署中，工具設計遵循幾個常見的模式。第一，分層授權：查詢工具（DEX 價格、鏈上狀態、Gas 費估算）不需要額外授權，Agent 自由調用；計算工具（策略評估、風險計算）同樣自由；執行工具（簽署交易、移動資金）必須通過額外的授權閥門——可以是金額閾值（超過 $100 需要確認）、時間鎖（非工作時間的大額操作延遲確認）、或白名單合約。第二，工具沙箱：在一個隔離的測試環境先「空跑」（dry run）工具調用——模擬交易執行結果但不真正廣播到鏈上，讓 Agent 在確認預期結果後再實際執行。第三，費用上限檢查：在執行任何涉及 Gas 費的鏈上工具之前，先用 Gas 估算工具計算費用，並和預設的「最大可接受 Gas 費」比較。費用超出預期就拒絕執行，避免在 Gas 費高峰期造成意外的成本超支。
如果你在使用或評估任何 AI Agent 服務，Tool Use 的設計質量直接影響你的資產安全。評估一個 Agent 系統的工具設計時，問這幾個問題：這個 Agent 的工具清單有沒有明確區分「只讀」和「寫入」工具？寫入工具（特別是鏈上簽署）有沒有獨立的授權驗證？工具調用有沒有完整的日誌記錄可供審計？工具的回傳結果有沒有合理性驗證，防止異常結果被直接採用？如果這些問題都能被清楚回答，這個 Agent 系統在工具設計上是值得信任的；如果回答模糊或沒有答案，謹慎給它真實資金的授權。