跳到主要內容
NTPU AI Learn

GoAI 101 · 模組 4

工具、API、MCP 與政府資訊系統

AI 從「會說話」變成「可以查資料、叫工具、執行任務」後，要如何控制？

開始第一節
  • 時長60 分鐘
  • 難度核心
  • 先備知識建議先完成模組 1-3
已完成 0 / 5
同步我的進度加入梯次後，進度可跨裝置保存，講師也能看到

資訊

加入後，你已完成的模組編號會連同「學員代碼」傳送給講師，講師可以看到你的進度。請使用講師提供的代碼，不要輸入姓名、公司機密或其他個資。進度資料與該梯次的其他資料一起保存。

學習目標

  • 說明 Tool Use、API、MCP 的基本概念與差異，以及 RAG／API／MCP 各自的角色。
  • 理解 Tool Discovery、Tool Calling、schema、arguments、result 與 provenance 的運作方式。
  • 理解 Read / Write 權限與 Least Privilege 原則。
  • 辨識哪些工具行動需要核准、哪些禁止，並判斷整合邊界與高影響行動。

Connect：Tool Use、API、MCP

10 分鐘

Tool Use、API 與 MCP

AI 可以透過 Tool Use 呼叫外部能力，不再只是產生文字。API 是系統之間既有的介接方式；MCP（Model Context Protocol）提供標準化的工具發現與呼叫機制，讓不同的 AI 系統可以用一致的方式連接各種工具與系統。

RAG、API、MCP 的角色分工
技術主要角色範例
RAG取回知識內容，協助 AI 回答問題從法規知識庫取回相關條文
API系統之間既有、特定用途的介接方式公文系統提供的查詢進度介面
MCP標準化的工具發現與呼叫機制，可串接多種工具AI 透過 MCP 查詢多個不同系統，而不需要為每個系統客製介接

資訊

三者常被混用，但角色不同：RAG 負責「知道什麼」，API/MCP 負責「可以做什麼、查什麼」。一個 Use Case 可能同時用到三種技術。
自我檢測

下列哪一個描述最能說明 RAG 與 API/MCP 的角色差異？

下列哪一個描述最能說明 RAG 與 API/MCP 的角色差異？

重點: Tool Use 讓 AI 從「只會說話」變成「可以查資料、叫工具」，但角色分工（RAG 取知識、API/MCP 做事）必須先想清楚，才能談控制。

Tool Discovery 與 Tool Calling

12 分鐘

Tool Discovery 與 Tool Calling 怎麼運作

MCP 讓 AI 在實際呼叫工具前，先完成 Tool Discovery：確認目前有哪些工具可用、各自的用途、限制與需要的參數。接著透過 Tool Calling 依照工具定義的 schema 傳入 arguments，取得結構化的 result，並標明結果的 provenance（來源）。

Tool Calling 的基本流程
  1. Tool Discovery：確認有哪些工具可用
  2. 依 schema 準備 arguments
  3. 呼叫工具
  4. 取得結構化 result
  5. 標明 provenance，供人工查核
  • schema：定義一個工具需要哪些參數、參數型別與限制，讓 AI 不能隨意傳入任意格式的資料。
  • arguments：AI 依照 schema 實際傳入的參數內容，應該可以被記錄與事後查核。
  • result：工具執行後回傳的結構化結果，不是未經處理的原始輸出。
  • provenance：結果來自哪個系統、哪個時間點查詢，讓人工可以回頭驗證。
自我檢測

某工具呼叫回傳的結果沒有標明資料來源的系統與查詢時間，只有一段文字結論。這會造成什麼問題？

某工具呼叫回傳的結果沒有標明資料來源的系統與查詢時間，只有一段文字結論。這會造成什麼問題？

重點: Tool Discovery 與 Tool Calling 的每一步（schema、arguments、result、provenance）都應該是可檢查、可追溯的，而不是一個黑箱呼叫。

權限控制原則

12 分鐘

權限控制的核心原則

權限控制的核心原則
原則說明
Read vs Write查詢資料的風險遠低於寫入或變更資料；預設先開放 Read，Write 需額外審查
Least PrivilegeAI 只取得完成任務所需的最小權限，不給予超出任務範圍的存取
核准與升級高影響行動（Write、對外發送、金流、人事）須經人工核准才能執行
日誌與可追溯每次工具呼叫都應留下紀錄，方便事後查核
  • 整合邊界：AI 可以連接哪些系統、不能連接哪些系統，應在設計階段事先明確界定，不應該在上線後才發現「原來它連得到這個系統」。
  • 高影響行動：對外發送、資料寫入、金流、人事等行動，不論表面上看起來多簡單，都應預設需要人工核准。
自我檢測

某單位想讓 AI Agent 直接取得公文系統的「發文」寫入權限，理由是「可以加快速度」。下列哪一個判斷最正確？

某單位想讓 AI Agent 直接取得公文系統的「發文」寫入權限，理由是「可以加快速度」。下列哪一個判斷最正確？

重點: Least Privilege 不是「盡量不給權限」，而是「只給完成這個任務真正需要的權限」；多給的每一分權限，都是未來風險的來源。

政府情境：查詢可以，寫入要核准

14 分鐘

政府情境：查詢可以，自動寫入不行

政府情境：查詢可以，自動寫入不行

AI 可以被授權查詢公文列管系統的進度（Read），協助承辦人掌握案件狀態；但不應預設授權 AI 直接修改結案狀態或發文（Write），這類動作需要人工確認後才能執行。另一例：AI 可以協助準備公文草稿，但正式發文需要經過具職權人員簽核與送出，不能由 AI 直接完成法定發文程序。

  • 這兩個例子說明同一個原則的兩種樣貌：「查詢」與「準備」屬於低風險、可以較寬鬆授權的行動；「寫入」與「正式發文」屬於高影響、必須保留人工把關的行動。
  • 即使 AI 準備的草稿品質很高，「草稿完成」與「正式生效」之間，仍然需要一個明確、不可省略的人工步驟。

注意

常見的錯誤心態是「AI 做得很好，所以可以讓它直接做到底」。工具整合的風險判斷，應該基於行動本身的影響範圍，而不是 AI 過去表現得好不好。
自我檢測

AI 準備的公文草稿品質持續很高，有人提議讓 AI 之後可以跳過人工簽核直接發文。下列哪一個判斷最正確？

AI 準備的公文草稿品質持續很高，有人提議讓 AI 之後可以跳過人工簽核直接發文。下列哪一個判斷最正確？

重點: 查詢與草稿準備可以逐步放寬授權；正式寫入與對外發文的人工把關，不會因為 AI 表現得好就自動失效。

實作與應用

12 分鐘

實作：Can the Agent Use This Tool?

活動 4 把模組 2 的 Workflow 中會用到的工具或系統逐一列出，並分類每個行動的權限等級，填入 Government AI Tool & Permission Matrix。

  1. 列出可能用到的工具或系統
    包含查詢用與執行用的系統。
  2. 標出每個工具的 Read/Write
    並標出資料存取範圍。
  3. 分類行動
    把每個行動分為 Read／Write／Recommend／Execute／Requires Approval／Prohibited。
  4. 標出 Owner 與 Fallback
    誰負責這個工具、出錯時怎麼處理。
  • Government AI Tool & Permission Matrix 最少欄位：Tool / System、Purpose、Data Accessed、Action、Read / Write、Role、Permission Scope、Approval Required、Logging Required、Failure Impact、Reversible?、Fallback、Owner。
自我檢測

Tool & Permission Matrix 中的「Reversible?」欄位，主要協助判斷什麼？

Tool & Permission Matrix 中的「Reversible?」欄位，主要協助判斷什麼？

重點: 把每個工具行動的風險、權限與復原能力寫清楚之後，模組 5 的治理設計才有具體的素材可以依循，而不是憑空討論「AI 可以做多少」。

另存 PDF

接下來做什麼？