MCP 的真正價值：為何將資料處理能力「模組化」是 Agent 導入企業的關鍵一步
MCP 的價值不只在於讓 Agent 接上資料湖，而在於把原本零散的資料處理能力封裝成可插拔、可治理的協議介面。當能力被模組化，企業導入 AI Agent 的門檻就會從繁重整合工程，下降為較可控的系統設計問題。
AI Agent 要在企業落地，最大的挑戰從來不是模型本身，而是如何與既有、複雜的資料基礎設施協作。近期 AWS Labs 推出的 MCP 實作看似只是技術細節，但我認為它揭示了關鍵的下一步：將資料處理能力從龐雜的整合工程，轉化為標準化的「能力模組」。當 Agent 與資料的互動不再是客製化的點對點串接，而是基於共同協議的服務調用時，企業導入 Agent 的門檻才能真正從工程問題，下降為更易於管理的協議問題，這將是規模化應用的轉捩點。
為什麼 Agent 接取企業資料湖如此困難？
大型語言模型（LLM）的推理能力，理論上讓打造能自主操作企業內部系統的 AI Agent 成為可能。然而，現實的阻礙遠比想像中巨大，尤其是在處理企業核心資產——資料湖（Data Lake）或湖倉一體（Lakehouse）時。問題不在於 Agent 看不懂數據，而在於數據周邊那一大堆隱性、非標準化的處理流程。
在任何一間稍具規模的企業，原始數據很少能被直接使用。它需要經過一連串的 ETL（擷取、轉換、載入）流程、品質檢驗、權限控管、格式轉換與業務邏輯聚合。這些流程往往是多年累積下來的客製化腳本與工具鏈，緊密耦合在特定的基礎設施上。
每當我們要導入一個新的 Agent 應用，例如「用自然語言生成季度銷售報表」，開發團隊就必須為這個 Agent 重複造輪，進行繁瑣的系統整合，確保它能正確地觸發那一長串處理流程。這不僅耗時費力，更讓 Agent 的擴展與維護成為一場惡夢，嚴重阻礙了 AI Agent 在企業內部的普及。
MCP 的核心價值：它如何標準化了資料處理能力？
正是在這個背景下，像 Model-centric Communication Protocol (MCP) 這樣的協議才顯得格外重要。MCP 由 AWS AI Labs 於 2024 年 5 月提出，其核心思想非常簡單卻強大：它試圖標準化的不是數據本身，而是對數據的「處理能力」。
與其讓 Agent 直接存取資料庫、觸發零散的 API，MCP 將整個互動模式重新定義為：
- MCP Client：通常是 AI Agent，它負責理解使用者意圖，並將其轉化為一個標準化的「能力請求」。
- MCP Server：一個中介層服務，它接收請求，並將其轉譯為對後端資料系統（如資料湖）的具體操作。這個 Server 掌握了所有處理數據所需的工具與權限。
換句話說，Agent 不再需要知道資料儲存在哪、ETL 腳本如何執行。它只需要用 MCP 協議的語言，向 MCP Server 說：「我需要一份符合 X 條件、經過 Y 處理的數據。」Server 就會完成所有底層的髒活。這將複雜的點對點整合，簡化成單一的、基於協議的互動。
真正的變革在於，Agent 不再需要「知道」如何處理資料，它只需要「知道」如何請求一個具備特定處理能力的 MCP 服務。
一個具體實踐：如何用自然語言操作 Lakehouse？
概念聽起來很美好，但實際落地又是另一回事。幸運的是，AWS Labs 很快地在 GitHub 上開源了一個名為 aws-dataprocessing-mcp-server 的參考實作，完整展示了這套架構的潛力。
日本技術顧問公司 Classmethod 的一篇技術實踐文章，便詳細記錄了如何將這個 MCP Server 部署到 Amazon Bedrock AgentCore Runtime 上，並與數據視覺化工具 Amazon QuickSight 結合。整個流程串起來後，使用者可以直接在 QuickSight 的儀表板上，用自然語言下達指令，例如「幫我查詢第二季 A 產品線在東北地區的銷售總額，並與去年同期比較」。
這個指令會由 Bedrock Agent（MCP Client）接收，轉換成 MCP 請求後發送給 MCP Server。Server 隨即在後端的 Lakehouse 執行對應的查詢與運算，再將結果回傳給 Agent，最終呈現在 QuickSight 的圖表上。整個過程對使用者來說，只是簡單的對話，極大地提升了數據分析的門檻。
當然，實作過程並非一帆風順。文章中也提到了幾個關鍵的技術坑點，例如為了處理大型數據流，必須將預設的 HTTP 函式庫切換為支援串流的 streamable-http；以及為了系統安全，需要謹慎處理 DNS 重新綁定（DNS Rebinding）保護機制，避免惡意網站透過瀏覽器繞過同源策略，對內部 MCP Server 發動攻擊。這些細節恰恰證明了這不僅是個概念驗證（PoC），而是已經進入了考慮實際部署可行性的階段，為企業級應用奠定了基礎。
MCP 如何將整合複雜度降維？對企業有何實質意義？
MCP 的出現，真正改變的遊戲規則是將「能力」模組化。過去，資料處理能力是散落在各個系統、腳本與服務中的隱性知識。現在，我們可以透過 MCP Server 將這些能力打包成一個個標準化的、可插拔的「工具」。
這對企業導入 Agent 意味著什麼？
- 大幅降低整合成本：一旦企業為其核心資料系統（如 Lakehouse、SAP、Salesforce）建立了對應的 MCP Server，任何新的 Agent 應用，只要它支援 MCP 協議，就能立刻與這些系統互動，無需再進行客製化的整合開發。
- 提升系統安全性：所有對敏感資料的操作都被收斂到 MCP Server 統一管理。企業可以在這個單一入口點上，實施嚴格的權限控管、日誌審計與安全策略，而不是讓權限散落在數十個 Agent 應用中。
- 加速應用迭代：產品團隊可以專注於 Agent 的核心業務邏輯與使用者體驗，而不用分心處理底層數據的存取細節。這讓 Agent 的開發與迭代速度得以大幅提升。
當我們將視角拉高，會發現這與當年 API Gateway 或 Service Mesh 對微服務架構的影響如出一轍。它們都是透過引入一個標準化的中介層，將複雜的底層實作細節抽象化，從而釋放上層應用的生產力。MCP 扮演的，正是 Agent 時代的「能力閘道器」（Capability Gateway）。這一步雖然看似微小，卻是推動 AI Agent 從實驗室走向企業規模化應用的關鍵基礎建設。
延伸閱讀
- Model-centric Communication Protocol (MCP) - arXiv
- AWS Labs - aws-dataprocessing-mcp-server on GitHub
- OWASP - DNS Rebinding
- 【実装】Amazon Bedrock AgentCore に MCP サーバをホストして Amazon QuickSight から自然言語でレイクハウスを操作する
我是江中喬，一位具有 TPM 與產品管理背景的 AI 系統建構者，目前專注於 AI 認知增強系統與多 Agent 協作架構的設計與實踐。