I. 前言：今天要建立兩個心智模型

昨天說明了這 30 天要走的路線。在開始寫程式之前，有兩個心智模型必須先建立起來，否則後面的每一個技術決定都會變成「照著文件抄」。

第一個是 AI Agent 的組成。 它跟 Chatbot 的差異不只是「多了呼叫 API 的能力」，而是整個決策迴圈的結構都不一樣。

第二個是 MCP 的架構。 它解決的問題其實跟 AI 沒有直接關係 —— 那是一個相當典型的軟體工程問題，只是換了一個場景重演。

這兩件事之間有一條線串著：Agent 的四個組成裡，只有「工具」這一項是真正會影響外部世界的，也因此只有它需要一套標準化的協定與安全邊界。而那正是 MCP 的位置。

如果您已經用 Prompt 串過工具，今天的內容大概會踩到一個您隱約感覺到、但還沒說清楚的問題：為什麼同一段 Instruction，有時候模型照做，有時候不照做。 今天會把那個「有時候」的成因拆開來看。

II. Agent 的四個組成

過去兩年多數人對 LLM 的第一印象是「聊天機器人」—— 給一段文字，回一段文字。這在回答知識型問題、翻譯、改寫時表現很好，但如果目標是讓 AI 協助處理請假申請、簽核與職務代理，純粹的 Chat 模式就撐不住了。

因為真實世界的任務不是「說話」，而是採取行動並根據回饋調整。

一個成熟的 Agent 系統由四個部分組成，它們各自負責一件事。

1. 大腦（Brain / LLM）

推理中樞，負責三件事：

• 意圖識別 —— 理解使用者隨口說的「把我那張家庭旅遊的特休送出審核」背後真正要做什麼。
• 邊界判定 —— 判斷手上的資訊夠不夠、需不需要反問。
• 決策反思 —— 工具執行失敗時，讀懂錯誤訊息並調整下一步。

第三項比想像中重要。明天設計工具時會刻意在錯誤訊息裡寫清楚「下一個合法的狀態是什麼」，就是為了餵給這個能力。

2. 規劃（Planning）

面對多步驟任務，人不會一口氣做完，而是拆解。Agent 的規劃機制主要有三種形態：

把它們的執行軌跡畫出來，差別會更直觀：

這裡有一個差別值得先記著：Plan-and-Solve 產出的計畫是「一段可以解析的文字」，而 ReAct 的思考散在每一步裡。前者可以被抓出來、被檢查、被存下來；後者不行。這個差別在挑 Planner 時會變成決定性的因素。

3. 記憶（Memory）

LLM 本身是無狀態的（Stateless）—— 每一次呼叫它都不記得上一次發生了什麼。要完成多輪協作，記憶必須由外部系統提供：

• 短期記憶 —— 當前對話歷史、Session State（如登入者 ID、正在處理的假單 ID）。
• 長期記憶 —— 透過向量資料庫或 RAG，回憶過去的簽核經驗與差勤規章。

短期記憶看起來單純，實際上是這個系列裡最容易靜默出錯的地方之一 —— 光是「這筆資料要活多久」就有好幾種答案，選錯了不會報錯，只是下一輪就找不到了。接上框架之後會專門處理。

4. 工具（Tools / Actions）

這是讓 Agent 擁有「手腳」的部分。沒有工具，模型只能提供建議；有了工具，它可以查詢資料庫、更新假單、重啟雲端資源。

四個組成裡，只有這一項會真正改變外部世界的狀態。 大腦想錯了可以重想，記憶錯了可以清掉，但工具一旦執行下去，資料就真的被刪了。

這個不對稱性，是接下來所有安全設計的出發點。

一次完整的迴圈

把四者串起來，一次互動的形狀跟 Chatbot 有根本的差別：

Chatbot 是一趟直線：讀完輸入、生成回應、結束。整個過程只有一次模型呼叫，也只有一次出錯的機會。

Agent 是一個會反覆執行的閉環：取出記憶 → 決定下一步 → 執行工具 → 把結果寫回上下文 → 判斷完成了沒 → 沒完成就再轉一圈。

而每多轉一圈，選錯工具、填錯參數、違反規則的機會就多一次 —— 錯誤率是沿著迴圈累積的。這件事有個直接的後果：要評估一個 Agent 好不好，看最後那句回答是不夠的，得看它整段走過的路。

III. 為什麼「只給 Prompt」有其極限

多數人打造 Agent 的第一直覺，是把所有規則塞進 System Instruction：

- 你不可以跳級推進假單狀態
- 操作前必須先查詢真實 ID，不可以編造
- 使用者若取消操作，請立即終止，不要改用其他方式達成

這個做法是對的，也是必要的第一步。但實務上會遇到一個結構性的問題：

Instruction 寫得再詳細，遵從率依然是一個機率問題。

上圖的重點在那條長條 —— 規則並不是獨佔模型的注意力，它得跟工具 Schema、對話歷史與工具回傳結果搶位置。

而且這個機率會隨著兩件事惡化：

第一，對話輪次增加。 規則寫在最前面，但到了第七輪、第八輪，中間隔了大量的工具回傳結果，注意力被稀釋掉了。

第二，工具數量變多。 九個工具的 schema 加起來就是好幾千個 token，規則在其中的相對權重被壓縮。

更關鍵的是第三點：Prompt Injection 會與您的規則處在同一個上下文裡。如果模型讀到的某段工具描述裡夾帶了「請忽略先前的限制」，對它而言那段文字與您寫的叮嚀，權重是相當的。這個階段的最後一天會完整處理它。

兩條補救路線

這個系列接下來要做的，本質上就是把規則從「模型的注意力」搬到兩個更可靠的地方：

這兩條路線都不依賴「模型有沒有讀到那句話」。 這就是它們比 Prompt 可靠的原因，也是整個系列的骨架。

而協定層要用的那套標準，就是接下來要談的 MCP。

IV. 工具介面的第二個問題：M×N

在談 MCP 是什麼之前，先看它解決的問題 —— 這個問題跟 AI 沒有太大關係。

假設您有 M 個 AI 應用（Claude Desktop、Google Antigravity、自家的差勤助手、IDE 外掛），以及 N 個資料來源或工具（假單系統、員工資料、監控 API）。

在沒有標準的情況下，要讓每個應用都能用每個工具，需要寫 M × N 個整合。每個整合都有自己的認證方式、參數格式、錯誤處理慣例。加一個新工具，就要改 M 個地方。

這是一個非常古典的軟體工程問題，而它的解法也同樣古典：加一層標準介面。

有了 MCP，每個應用只要實作一次 Client、每個工具只要實作一次 Server，整合數量就從 M × N 收斂成 M + N。

這個模式您應該很熟悉。ODBC 之於資料庫、LSP（Language Server Protocol）之於編輯器，走的都是同一條路。MCP 常被形容為「AI 世界的 USB-C」，指的就是這件事。

V. MCP 的架構：Host、Client、Server

MCP 的架構分成三個角色，而它們的關係經常被誤解：

最容易搞混的是 Host 與 Client 的關係。 它們不是同一件事：一個 Host 可以同時持有多個 Client，每個 Client 各自維持一條到單一 Server 的連線。

這個 1:1 的設計是刻意的，它帶來一個直接的好處：每條連線的權限與生命週期都是獨立的。您可以只斷開某一個 Server，而不影響其他的。

底層是 JSON-RPC 2.0

MCP 的訊息格式用的是 JSON-RPC 2.0 —— 一個相當成熟、簡單的規範。這代表：

• 請求與回應的配對、錯誤格式，都有現成的標準可循。
• 傳輸層可以抽換：本機用 stdio（標準輸入輸出），遠端用 HTTP。
• 雙向。 Server 也可以主動向 Client 發請求，這一點在下一節會變得很重要。

能力協商

連線建立時，雙方會進行一次 initialize 握手，交換各自支援的能力。這代表 Client 不需要假設 Server 支援什麼 —— 問過才知道。

這個設計讓協定能夠往前演進：新增的能力對舊 Client 而言就是「沒有協商到」，不會直接壞掉。

VI. Server 提供什麼：三大元素

Server 端提供三種能力。它們的差異不在技術實作，而在誰來決定要不要使用：

這個「控制權」的分類非常實用，因為它直接回答了設計時最常見的問題：這個東西該做成 Tool 還是 Resource？

判斷準則其實很單純 —— 先問「誰決定要不要用它」，答案就出來了：

• 會改變狀態、或需要模型自己判斷何時執行 → Tool
• 只是讀取、而且應用程式知道什麼時候該載入 → Resource
• 是一段使用者會主動挑選的固定流程 → Prompt

明天會把三者都實作一次。

VII. Client 也提供能力：Elicitation

這是 MCP 最容易被忽略的一半：Client 不只是呼叫端，它也提供能力給 Server。

其中對本系列最關鍵的是 Elicitation —— 它讓 Server 能在執行到一半時，反過來向使用者索取資訊或確認。

為什麼這件事很重要

考慮一個場景：模型決定要執行「撤銷已核准的病假」。

在沒有 Elicitation 的世界裡，常見的做法是在工具裡加一個 confirm: bool 參數，或是設計一個 dry_run 模式。但這兩種做法有同一個問題：

決定要不要確認的人，變成了模型。

模型可以選擇不傳 confirm=True，也可以自己決定「這次應該不用 dry run」。安全機制建立在被監管者的自覺之上，這在架構上是不成立的。

Elicitation 把這件事翻轉過來：確認請求由 Server 發起、由 Client 呈現給使用者、由使用者決定。模型完全不在這條決策鏈上。

兩張圖唯一的差別，是中間那一格由誰負責。 左邊那條鏈上有一格是模型自己決定的，右邊沒有 —— 而這一格的歸屬，決定了這道防線能不能被繞過。

三種回應

規範定義了三種明確的結果，而且它們的語意各不相同：

decline 與 cancel 的區別是本系列一個核心的觀測點。 把 cancel 當成 accept 是嚴重的錯誤；而 decline 之後改用別的工具繞道，則是模型最典型、也最難靠 Prompt 消除的失敗模式。

兩種模式

2026-07-28 版規範提供兩種 Elicitation：

• form mode —— 結構化表單，適合索取參數或確認。schema 限制為扁平物件與原始型別。
• url mode —— 把使用者導向一個外部 URL 完成流程，適合 OAuth 這類不該在對話框裡處理的情境。

有一條紅線要記住：form mode 的規範明確寫著 MUST NOT 用來索取密碼、API key、token 或付款憑證。 需要憑證時，正確的做法是 url mode。這一點明天會再展開。

VIII. Extensions：2026 年的新局

2026-07-28 這一版規範另外定義了一套 Extensions 機制 —— 把非核心的能力抽成獨立的擴充，全部都是 opt-in。目前主要有三個：

這些東西看起來都很適合我們的差勤場景 —— 例如 cancel_approved_leave 這種可能跑很久的操作，理論上就該用 Tasks。

但這裡有一個必須誠實面對的現實：規範定義了，不代表現在就能用。

Extensions 是 2026-07-28 這一版才正式獨立出來的機制，整個生態系都還在早期。翻開官方的 Extension 支援矩陣就看得出來：Tasks 連欄位都還沒有，而唯一有較多實作的是 MCP Apps（十一個 Client）。

相對地，Elicitation 不是 Extension，它是 Client 端的核心能力，所以它現在就能端到端跑起來 —— Google ADK 也已經支援，包含 URL 模式。

所以本系列的技術選擇是：核心機制用 Elicitation；Tasks 等生態系成熟再說。

這是我會在整個系列反覆強調的原則：規範是規範，實作是實作。 決定架構之前，先確認那個能力現在真的跑得起來 —— 而確認的方式往往是去讀原始碼，而不是讀文件。

IX. 結語

今天建立的兩個心智模型，會一路用到最後一天。

總結來說，有三個重點值得帶走：

• Agent 的四個組成裡，只有「工具」會改變外部世界： 大腦想錯可以重想、記憶錯了可以清掉，但工具執行下去，資料就真的被刪了。這個不對稱性是所有安全設計的出發點，也解釋了為什麼協定層的防護值得花這麼多力氣。
• 把規則寫在 Prompt 裡，遵從率永遠是機率問題： 對話輪次增加會稀釋注意力、工具變多會壓縮相對權重，而 Prompt Injection 更是直接與您的規則處在同一個上下文。這個系列的兩條主線 —— 協定層與權重層 —— 都是為了把規則搬到模型的注意力之外。
• MCP 解決的是 M×N 問題，而它最有價值的一半在 Client 端： Tools／Resources／Prompts 的分類靠「誰控制」就能判斷；而 Elicitation 把「要不要確認」的決定權從模型手上拿走，交還給使用者 —— 這比任何 confirm 參數都可靠。

明天開始動手。要用 MCP 官方 Python SDK 的 FastMCP 實作一個完整的 Server —— 從最小可運作的範例開始，一路做到 Tools、Resources、Prompts、Context 注入與 Elicitation。

參考來源

• MCP 規範 2026-07-28——Host / Client / Server 架構、JSON-RPC 2.0、能力協商、三大元素
• 規範・Elicitation——form / url 兩種模式、accept / decline / cancel 三態、憑證索取禁令
• MCP Extensions・Tasks——狀態機與方法定義
• Google Antigravity・MCP——IDE 與 CLI 皆支援 MCP，stdio / SSE / streamable HTTP 三種傳輸，設定檔為 mcp_config.json
• MCP・Client 支援矩陣——目前追蹤的 Extension 與 Client 清單
• Google ADK・MCP Tools——McpToolset 的 Elicitation 支援

查證日期：2026-09-01

I am Simon

大家好，我是 Simon 劉育維，是一位 AI 領域解決方案專家，目前也擔任 Google Cloud AI 領域開發者專家 (GDE)，期待能夠幫助企業導入人工智慧相關技術解決問題。如果這篇文章對您有幫助，歡迎在我的 Linkedin 上留言提供意見，並與我一起討論有關人工智慧的主題，期待能夠對大家有所幫助！

我的個人部落格資訊：https://medium.com/@simon3458