Tool use 與 MCP：Agent 能動手之後，怎麼守住操作邊界

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

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

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

前面五篇都在談 agent 怎麼取得資料。從這一篇開始，它不只會讀，還能真的去改資料、建工單或寄信。風險也從這裡開始明顯增加。

我自己寫過幾個 MCP server。把工具交給模型之後，很快就會發現：

會使用工具的 agent 如果判斷錯誤，影響不只是一段錯誤回答。它可能改到資料、動到錢，或送出收不回來的內容。

因此工具不能接上就算完成。接下來會從 function calling 講到 MCP，再看哪些檢查一定要放在真正執行之前。

先搞懂 function calling 的本質

模型其實不會自己連到外部 API。一次工具呼叫通常是這樣發生的：

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

真正的控制點在第 3、4 步之間。模型只會輸出「想呼叫什麼、準備帶哪些參數」，實際執行的是 runtime。是否放行、參數要檢查什麼、需不需要先讓人確認，都可以在這裡決定。這層如果什麼都不檢查，才等於把控制權交給模型。

模型只把結構化的工具呼叫意圖送到中間的 runtime；runtime 先檢查權限與參數，通過後才用獨立控制線啟動右側的訂單、資料庫與寄信系統，模型本身沒有直接操作外部系統

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 的好處理解成「串接比較方便」。實際放到公司環境後，另一個好處更明顯：工具終於能集中管理。

MCP 把散落在程式各處的 function，整理成一份可以盤點、審核與版本控制的工具清單。

資安若問「這個 agent 到底能操作哪些系統」，團隊可以直接查看 tool registry，不必回頭 grep 整個 codebase。第 11 篇談治理時，還會用到這份清單。

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

三條讓 agent 安全動手的紀律

把工具接上只是開始。讓它能上 production，靠的是下面三條——它們其實是同一條路徑上的三道閘門：

flowchart TD
    T["模型決定要呼叫某個工具"] --> B{"這個工具<br/>會不會改變世界？"}
    B -->|"唯讀"| R["直接執行<br/>錯了只是給錯資訊"]
    B -->|"會寫"| A{"高風險動作？"}
    A -->|"是"| H["human-in-the-loop<br/>把真實參數攤開給人看"]
    H -->|"人按確認"| I["帶 idempotency key 執行"]
    A -->|"否"| I
    I --> F{"逾時或失敗？"}
    F -->|"重試"| I
    F -->|"留下半套狀態"| C["rollback 或補償"]

注意那條從 重試 繞回執行的線——它一定會發生，所以 idempotency key 不是選配。

會改變世界的工具呼叫依序通過三個安全站：先把唯讀查詢與寫入動作分流，再將真實參數攤在透明檢查盤上由人類確認，最後以同一把 idempotency key 合併重試並用回復機構處理半套狀態，只有一次受控動作抵達外部系統

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

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

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

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

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

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

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

人工確認不是每個動作都要加，而是留給出錯代價高的操作。關卡必須放在執行前，也要把收件人、數量、金額、內容等真實參數完整呈現；只寫「agent 準備寄信」並不足以讓人判斷風險。

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

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

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

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

這些都是分散式系統早就遇過的問題。差別只是現在多了一個可能自行決定重試的元件，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」的工具（這等於把資料庫鑰匙交出去），而是給「查詢某使用者的訂單（已內建只能查他自己的）」這種意圖明確、權限和範圍已經框死的工具。把危險收在工具內部，而不是指望模型自律。

同一張不可信指令送進 agent 後，左邊的萬用鑰匙能打開整座資料庫保險庫、暴露所有抽屜與控制器；右邊的精密工具只能穿過受限開口碰到單一使用者的訂單抽屜，其餘資料與控制面仍保持上鎖

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