MCP 怎麼把提示詞變工作流

Model Context Protocol，簡稱 MCP，最近很常被拿來聊。原因很簡單，AI 不缺會講話的模型，缺的是能真的做事的接法。Zoho 這篇文章就把這件事講得很直白：從 prompt 到 production，中間差的是控制、權限，還有確認流程。

講白了，AI 助手要進公司系統，不是會回答就夠。它得知道能讀什麼資料，能動哪些工具，還要知道什麼時候先問一句。這就是 MCP 想處理的問題。

如果你做過串接 API、CRM、試算表、信箱，你大概懂那種痛。每個系統都一套規則，最後不是在補洞，就是在補洞的路上。MCP 想把這層變成標準介面。

MCP 到底在做什麼

MCP 是一種協定。它讓 AI app 可以用一致方式，去找外部資料和工具。不是每家廠商自己發明一套接法，然後大家各自維護。

你可以把它想成 AI 客戶端和伺服器之間的結構化對話。客戶端可能是聊天介面，也可能是 agent runner。伺服器則把資料庫、內部 Semantic Kernel 類型的能力，或公司內部 Claude 工作流包成可呼叫的服務。

Zoho 特別提到 elicitation。這個詞聽起來很硬，其實很實用。意思就是，伺服器可以先跟客戶端要缺的資訊，或要求使用者確認，再往下做。

• 遇到資訊不完整時，不用瞎猜。
• 遇到敏感動作時，可以先停一下。
• 流程中途有變數時，還能接著跑。
• 客戶端可以收精準輸入，不用靠猜測。
• 權限和動作邊界會更清楚。

這點很重要。Demo 可以靠想像力撐住。Production 不行。真的上線後，助手碰到的是客戶資料、帳單、工單、內部文件。這時候一個誤動作，就不是笑笑而已。

為什麼 elicitation 很實際

Zoho 的寫法我覺得不錯，因為它沒有把 elicitation 包裝成玄學。它就是一個控制點。當 AI 準備寄信給客戶時，系統可以要求確認。當它缺日期區間時，伺服器可以直接問，不用亂補。

這種設計比把所有東西塞進一段超長 prompt 更穩。prompt 很方便，但一旦流程有多個步驟、幾個工具、還有審批需求，就很容易變脆。你今天加一個欄位，明天改一個格式，整串就開始抖。

企業要的不是會即興發揮的助手。企業要的是能問問題、能等確認、能照流程走的系統。這也是 MCP 比傳統 function calling 更像「工作流底座」的地方。

“The important thing is not the machine’s ability to think, but its ability to do what you want it to do.” — Steve Jobs

這句話放在這裡很貼。AI 不是只要會講。它要能在正確的邊界內做事。MCP 的價值，就是把「會講」和「能做」中間那段接起來。

對內部工具團隊來說，這也少掉很多臨時接線。少一點客製 glue code，少一點散掉的權限邏輯。對使用者來說，助手先問再做，這其實比較像正常人，不像亂按按鈕的腳本。

和舊式整合方式比，差在哪

如果把時間拉回 2023、2024，你會看到很多 AI 整合都很土炮。不是自寫 plugin，就是每家服務各接各的 function calling。能動是能動，但維護成本很高。

MCP 想做的是標準化這一層。客戶端不用學每一個系統的怪脾氣。只要對 MCP server 講話，就能拿到資料、呼叫工具，或要求下一步確認。

你可以這樣看：

• 自寫 API 串接： 快，但每個系統都要重做一次。
• Function calling： 好用，但常綁在單一產品裡。
• MCP： 把工具和資料來源放進共通協定。
• Elicitation： 讓系統先補資料，再繼續執行。
• 權限設計： 比把權杖全丟進 prompt 裡安全。

這種差異在企業很有感。因為真正麻煩的不是模型會不會回答，而是它能不能安全地碰資料。誰能讀，誰能改，誰要先確認，這些都比回答速度更重要。

如果你看 Microsoft Semantic Kernel、LangChain、還有各家 agent 框架，就會發現大家都在解同一題。只是 MCP 想把這題變成協定層，而不是每個團隊自己發明一套。

資料、權限、審批，才是上線重點

很多人聊 AI，愛先聊模型參數。說真的，到了 production，那不是第一順位。第一順位是資料怎麼拿，權限怎麼控，動作怎麼審批。這三件事沒做好，模型再強也只是會闖禍的嘴砲機器。

Zoho 這篇文章把 MCP 的價值放在流程裡，而不是把它講成炫技工具。這點我同意。因為企業最怕的不是慢一點，而是錯一步。尤其是客服、銷售、財務、法務這些部門，錯一步就很麻煩。

你可以把 MCP 想成一種「先問再做」的規則。這和很多人心中那種全自動 agent 很不一樣。全自動聽起來很爽，但真上線時，通常會先被資安和法遵打回票。

• 讀取資料： 只開放必要欄位。
• 寫入動作： 要有明確授權。
• 高風險操作： 先確認再送出。
• 流程記錄： 要能追蹤誰叫了什麼。
• 跨系統任務： 要能保持上下文。

這也是為什麼我覺得 MCP 比單純的 prompt engineering 更像正經工程。prompt 讓模型聰明一點。MCP 讓系統可控一點。兩者不是同一件事。

如果你在做 SaaS，這裡還有產品面。支援 MCP，代表你的軟體更容易被 agent 接進去。這不是行銷話術。這是你少寫很多整合文件，客戶也少問很多奇怪問題。

這波到底在跟誰比

要理解 MCP 的位置，最好拿幾個方案比一下。不是每個方案都在解同一題，但差異很清楚。你會看到，大家都想把 AI 接進真實資料流，只是做法不同。

第一個對照是傳統 plugin。plugin 方便，卻常常綁在單一平台。第二個對照是 function calling。它很實用，但通常是單一模型服務裡的設計。第三個對照是各種 agent 框架，它們能把流程串起來，但協定層還是分散。

MCP 的重點，是把「怎麼連」這件事標準化。這樣一來，客戶端和伺服器可以各自演進，不用每次都重寫整條鏈。

• Plugin： 入口簡單，但平台綁得深。
• Function calling： 方便，但常是單家雲的語法。
• Agent framework： 彈性高，但工程複雜度也高。
• MCP： 把工具、資料、確認流程放進共通層。
• 企業導入成本： MCP 理論上更容易複用。

不過也別太浪漫。MCP 不是魔法。它還是要看生態夠不夠大。沒有足夠多的 server、client、和工具支援，標準再漂亮也只是一份文件。

所以真正的觀察點，不是它講得多好聽。是有多少公司真的把它接進 CRM、工單、文件系統、內部資料庫。那才是檢驗點。

背景脈絡：為什麼現在大家都在補這一層

這一兩年，LLM 變強得很快。可是企業一上車，就卡在整合。模型可以生成答案，但不能自己知道公司資料在哪。模型可以寫信，但不能自己判斷這封信能不能寄。

所以產業開始往「工具層」和「協定層」補。你會看到 OpenAI、Anthropic、AWS Bedrock Agents 這些方向都在往外接工具走，只是各自的路徑不同。

MCP 的位置，就像大家終於開始承認：模型本身不是全部。真正麻煩的是模型外面的世界。資料來源很多，權限很多，流程很多，還有一堆不能亂動的東西。

從這個角度看，MCP 不是在跟模型比誰更聰明。它是在補模型和企業系統之間那段很髒、很細、但又很必要的工程。

結尾：我怎麼看 MCP 下一步

我覺得 MCP 會先在內部工具、客服、銷售營運這些場景落地。原因很簡單，這些地方最需要讀資料、要確認、再執行。流程清楚，ROI 也比較好算。

如果你在做產品，現在就可以問一個很實際的問題：你的 AI 功能，是不是還在靠一堆客製 connector 撐著？如果是，MCP 值得你認真看。不是因為它很潮，是因為它可能讓你少掉一半維護地獄。

接下來我會盯兩件事。第一，MCP GitHub 生態會不會繼續長。第二，主流 client 和 SaaS 會不會把它當標配。這兩件事如果都往前走，AI 工作流就會更像正規軟體，而不是一堆 demo 拼起來的幻覺。

你如果現在就在做 agent 或企業 AI，我的建議很直接：先挑一個低風險流程試 MCP。像查資料、整理摘要、發草稿信，這種最適合。先把標準跑順，再來談更大的動作。