Tool use 與 MCP：當 agent 能動手操作系統，邊界該怎麼劃

從 PoC 到 Production：企業 AI Agent 系統工程第 6 / 12 篇

本篇是「從 PoC 到 Production：企業 AI Agent 系統工程」系列的第 6 / 12 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。

這是「從 PoC 到 Production：企業 AI Agent 系統工程」系列第 6 篇（共 12 篇）。上一篇：權限感知檢索。

前面五篇講的是 agent 怎麼「知道」事情——RAG、向量、權限。這一篇開始講 agent 怎麼「做」事情。而這是整個系統裡風險陡升的地方。

我自己寫過幾個 MCP server，把工具接給模型用。寫完之後最深的體會是一句話：

Tool-using agent 真正可怕的地方，不是它會講錯話——講錯話頂多丟臉。是它能操作外部系統。它用錯工具，是真的會改到資料、動到錢、送出收不回的東西。

一個只會聊天的 agent 出包，是回答錯誤。一個會動手的 agent 出包，是生產事故。這一篇就是談怎麼讓它戴著手套動手。

先搞懂 function calling 的本質

很多人以為 agent 「呼叫了 API」是模型自己連出去打的。不是。實際流程是這樣：

1. 你給模型一份「可用工具清單」（每個工具的名字、用途、參數格式）
2. 模型看了問題，決定「我想呼叫 query_order，參數 order_id=12345」
3. 模型把這個「意圖」用結構化格式吐出來——它只是「說它想呼叫」
4. 你的程式碼（agent runtime）真正去執行這個呼叫
5. 把結果餵回給模型，它再決定下一步

關鍵在第 3、4 步之間：模型只是「表達意圖」，真正執行的是你的 code。這個分界超重要，因為它告訴你——控制權在你手上。模型想呼叫什麼是它的事，要不要真的執行、執行前檢查什麼、要不要先問人，全是你 runtime 這層的責任。把這層責任交回去自己手上，是 production tool use 的起點。

MCP：把「agent 能做什麼」變成一份可盤點的清單

MCP（Model Context Protocol）是一個讓工具和模型之間用標準介面溝通的協定。你把工具包成一個 MCP server，任何支援 MCP 的 client——Claude、ChatGPT、Gemini、Cursor、VS Code、Microsoft Copilot——都能用同一套方式接上去。

這裡有個關鍵轉折值得講清楚：MCP 雖然是 Anthropic 在 2024 年底提出的，但它沒有停在「Claude 自家規格」。2025 年 3 月 OpenAI 官方採納、4 月 Google DeepMind 跟上，到 2026 它已經交給中立基金會治理、變成跨廠商的共通標準。這件事對企業很重要——你押注一個治理地基，最怕綁死在單一 vendor 上；MCP 變成中立基礎設施，正是它值得押的原因。

我寫 MCP server 的經驗裡，它的價值常被低估成「方便接」。但對企業來說，MCP 真正的意義是治理面的：

MCP 把「這個 agent 能做哪些事」從散落在 code 各處的一堆 function，變成一份可以盤點、可以審核、可以集中管理的工具清單。

這在企業裡是地基。當資安問你「你們的 AI agent 到底能操作哪些系統？」，你能掏出一份清單，而不是回去 grep 全部 codebase。第 11 篇講治理時，這份「tool registry」就是核心。

（想動手體會，可以看我寫過的 15 分鐘做一個 MCP server 和什麼是 MCP。）

三條讓 agent 安全動手的紀律

把工具接上只是開始。讓它能上 production，靠的是下面三條。

一、Action Boundary：先分清楚「讀」和「寫」

每個工具上線前，先問一個問題：它會不會改變世界？

唯讀工具（查訂單、搜尋文件、看狀態）：風險低。錯了就是給錯資訊，不會留下副作用。
會寫的工具（建訂單、改設定、刪資料、寄信、轉帳）：風險高。錯了會留下收不回的副作用。

這條線要在設計時就劃清楚，並且對兩邊用不同的嚴格程度。唯讀工具可以放手讓 agent 自由用；會寫的工具，每一個都要套上後面兩條紀律。一個常見且務實的起手式是：讓 agent 預設只有唯讀工具，寫入工具要明確、逐個開通，而不是一股腦全給。

二、Approval Flow：高風險動作，讓人類按一下

對會造成重大副作用的動作，插入一個 human-in-the-loop（HITL）確認關卡：agent 準備好要做什麼、把它攤開給人看，人按確認才真的執行。

「我要把這 200 筆訂單標記為取消，確認嗎？」→ 等人點頭。
「我要寄這封信給全體客戶，內容如下」→ 等人點頭。

這不是不信任 agent，是承認它會錯，而且某些錯誤的代價大到不該由機率決定。設計上的重點是：approval 關卡要卡在「執行前」，而且要把 agent 打算傳的真實參數完整呈現給審核者，不能只給一句模糊的「它要寄信」。

哪些動作要 approval、哪些可以放行，本身是個風險分級——這會在第 11 篇的治理框架裡系統化。

三、Idempotency 與 Rollback：為「它一定會重試」做準備

Agent 會重試。網路斷了、逾時了、它覺得上次沒成功——它會再呼叫一次。如果你的寫入工具不是 idempotent，這就是重複下單、重複扣款、重複寄信的來源。

Idempotency：同一個操作做兩次，結果跟做一次一樣。常見做法是帶一個 idempotency key，後端認得「這個操作我處理過了」就不重複執行。
Rollback / 補償：萬一一連串動作做到一半失敗（建了訂單但扣款失敗），要有辦法回復或補償，不能留下半套狀態。

這些其實都是分散式系統的老問題。呼應第 2 篇那句話：LLM app 還是個 distributed system，只是多了一個會自己決定重試的元件，反而讓 idempotency 比以前更不能省。

還要注意一個 2026 的現實：主流 API（OpenAI tool calls、Anthropic tool use、Gemini function calling）模型一輪可以同時吐出多個 tool call，runtime 要能並行執行再一起餵回。這讓 idempotency 從「nice to have」變成「不做會出事」——重試已經會製造重複副作用，再疊上平行呼叫，重複的機率是乘起來的，不是加起來的。你以為的「一筆扣款」，可能是兩個平行呼叫各自重試後變成的四筆。

別把工具設計成「薄薄一層包 API」

最後一個實務建議。很多人把工具做成「一個工具對一個 API endpoint」，把模型當成在填 API 參數。這常常不好用，因為：

模型可能填出危險的參數組合（一次撈全表、刪太多）。
工具的「用途描述」寫不清楚，模型就會亂用。

好的工具設計，是站在「agent 想完成什麼任務」的角度，提供剛好夠用、邊界內建的能力。例如不要給一個「執行任意 SQL」的工具（這等於把資料庫鑰匙交出去），而是給「查詢某使用者的訂單（已內建只能查他自己的）」這種意圖明確、權限和範圍已經框死的工具。把危險收在工具內部，而不是指望模型自律。

為什麼這條這麼重要，2026 的資安現場給了更硬的理由：廣義工具（任意 SQL、任意 shell）是 prompt injection 最愛的放大器。攻擊者不需要攻破你的系統，只要想辦法讓模型「想呼叫」一次帶惡意參數的工具，就直接命中真實資料庫。把工具收窄成意圖明確、權限框死的形狀，等於把 injection 的攻擊面從「整個資料庫」縮到「這個使用者的訂單」——攻擊面小一個數量級。這也是 OWASP 把 Excessive Agency（給 agent 過多權限與自主性）單獨列為 LLM 應用十大風險之一的核心：危險不在模型會不會學壞，在你給了它多大的權限去做壞事。