跳到主要內容

MCP 宣布對大廠真實影響：慢火燉煮的基礎設施革命

SAP、Shopify 和 Salesforce 等軟體巨頭近期積極擁抱或建立 MCP (Model Context Protocol, 模型上下文協定)，不僅僅是技術上的跟風，更是企業軟體商業模式與互動典範的重大轉移。

這些 SaaS 巨頭（或是其生態系開發者）陸續宣布支援或整合 MCP 時，股票市場並沒有出現像「發布全新殺手級產品」那樣一夜暴漲的戲劇性波動。

在華爾街與機構投資人的眼中，支援 MCP 屬於「底層基礎設施升級」與「防禦性護城河策略」，它不是短期的炒作題材（不像推出某個冠上 AI 名稱的聊天機器人那麼吸睛），而是確保公司未來五到十年不會被 AI 時代淘汰的關鍵保命符。

大家心中的問題，這些大廠放棄掙扎了嗎？
先說結論：他們絕對沒有捨棄原有的 UI（使用者介面）和系統流程。

相反地，他們是在做「系統擴容」——把原本「只給人類操作的軟體」，升級為「也能讓 AI 代理（AI Agents）無縫操作的基礎設施」。

1. 意義上有什麼不同？為什麼是現在？

在過去，企業軟體的護城河是「功能齊全的 UI」加上「綁定用戶的專屬工作流」。但隨著大型語言模型（LLM）的崛起，互動模式改變了，這帶來了幾個根本性的差異：

  • 統一對接標準，終結 API 碎片化： 過去如果要讓 AI 幫忙查 Salesforce 的資料，開發者必須針對 OpenAI、Anthropic、Google 各寫一套 API 串接邏輯。MCP 就像是「AI 界的 USB Type-C」，提供了一個標準協定。Salesforce 或 SAP 只要提供一個 MCP Server，所有的 AI 模型就能以安全、標準化的方式讀取其上下文與數據。

  • 從「軟體作為目的地」到「資料即服務」： 過去，業務員必須「打開（登入）」Salesforce 才能工作。未來，業務員可能在 Slack 或自建的 AI 助理中打字：「請幫我總結客戶 A 昨天的會議，並更新他在 SAP 裡的報價單。」AI 透過 MCP 在背景完成一切。SaaS 巨頭意識到，未來的入口可能不再是他們自家的 App 畫面，而是各種對話框。

  • 捍衛「真實資料來源 (System of Record)」的霸主地位： 這些公司知道，他們真正的價值不在於「按鈕設計得多好看」，而是裡面儲存了企業最核心的客戶、庫存、財務資料。透過 MCP 讓 AI 容易存取這些資料，能讓他們的系統在 AI 時代變得更不可替代（更黏）。

2. 他們捨棄原有的 UI 和系統流程了嗎？

完全沒有。但它們的定位發生了降維與分化：

  • UI 的角色轉變：從「唯一入口」變成「深度管理與專家後台」

  • 日常、低難度任務（Chat-driven）： 交給 AI 透過 MCP 處理。例如：查庫存、更新聯絡人資訊、生成報表。使用者不需要再進入層層疊疊的選單。

  • 複雜、高風險、需人工檢核任務（UI-driven）： 仍然依賴原生 UI。例如：SAP 中複雜的全球供應鏈節點配置、Shopify 的全站版型設計、或是 Salesforce 的底層權限控管。這些需要「全局觀」和「精確點擊」的操作，傳統 UI 依然是最高效的。

  • 系統流程的進化：從「僵化的線性流程」變成「AI 的工具箱」

  • 傳統的系統流程（如：建立訂單 $\rightarrow$ 扣庫存 $\rightarrow$ 發通知）是寫死的代碼。

  • 導入 MCP 後，這些流程變成了 AI 可以隨時呼叫的「工具 (Tools)」。AI 可以根據使用者的模糊指令（例如：「處理退貨並給客戶發個安慰信」），自動編排這些流程。流程沒有被捨棄，只是被 AI 重新組合與觸發了。

以下為你解析這背後的重大意義，以及他們 UI 與流程角色的轉變：

資本市場對他們具備 MCP 能力的解讀，以及對長線股價的實質影響，主要體現在以下三個維度：

1. 消除「被邊緣化」的恐懼（守住既有估值）

  • 市場心理： 投資人最怕的是這些傳統企業軟體在 Agentic AI（代理型 AI）時代變得封閉、難以串接，導致企業客戶將資料轉移到更靈活的新創平台。

  • 股價影響： 具備 MCP 就像是向華爾街宣告：「我們依然是企業運作的心臟。」例如 SAP 透過 MCP Catalog 讓其龐大的資料庫（System of Record）能被 AI 代理直接讀取，這成功消除了市場對其「技術落後」的疑慮，穩固了支撐其股價的基本盤。如果他們固步自封拒絕開放標準，股價絕對會面臨外資機構降評的巨大壓力。

2. 引爆看不見的 API 流量紅利（推升實質營收）

  • 市場心理： 人類員工一天頂多在 Salesforce 或 SAP 裡點擊幾百次，但 AI 代理不知疲倦，會在背景全天候、高頻率地進行交叉比對與流程觸發。

  • 股價影響： MCP 讓 AI 存取資料變得極度容易，這將帶來暴增的系統呼叫（API Calls）與雲端運算需求。這些巨頭可以順勢推出針對 AI 代理的「專屬計費模式」，或要求客戶升級到更高階的運算訂閱方案。這種系統底層用量的變現，會實打實地反映在未來幾個季度的財報（如 ARR 年度經常性收入）上，這才是推升股價穩健上漲的真正燃料。

3. 搶佔「機器人經濟」的預設通道（提升本益比與想像空間）

  • 市場心理： 以 Shopify 為例，他們非常激進地擁抱 MCP，甚至推出了互動式的「MCP UI」，讓商店的購物車、庫存都能無縫被 Claude 等 AI 讀取與操作。

  • 股價影響： 這讓 Shopify 的敘事從「提供給人類逛的電商開店平台」，悄悄升級為「全球 AI 買手預設的交易引擎」。向資本市場證明自己能吃下未來的機器人訂單，能讓華爾街願意維持甚至給予他們更高的科技股本益比（PE Ratio），因為市場看到了全新的增長曲線。

總結

「宣布支援 MCP」這件事在股市中不會引發投資人或機構瘋狂追捧，因為它太技術導向、太偏向開發者端了。一般人其實看不懂，但對於看得懂技術趨勢的機構投資人來說，這是一粒強效的定心丸。

它對股價的影響是長線發酵的。

我相信很快就會在他們未來的財報會議（Earnings Call）上，頻繁聽到執行長們把「AI 代理透過 MCP 與我們系統的互動次數成長了 X 倍」作為業績亮點。當這些無形的互動正式轉化為財報上的數字時，資本市場的真實獎勵就會隨之而來。

SAP、Shopify 和 Salesforce 建立 MCP，是因為他們看清了未來的趨勢：與其強迫人類去學習他們複雜的系統，不如讓 AI 直接學會怎麼操作他們的系統。 這是一場搶奪「AI 時代底層資料庫」話語權的戰爭。

目前相信，這是企業軟體架構的一次大解構與重組。

留言

張貼留言

這個網誌中的熱門文章

Vibe Coding：為什麼 Junior 更快上手？Senior 要如何追趕？

現象層面（市場觀察） 最近有篇文章討論 junior & senior 開發者在 AI 時代的角色轉變，非常熱門。 身為 Cympack 產品開發團隊 ，我們也一直關注這個議題，在閱讀這篇文章時觀察到一些有趣的現象，對我們來說，這正好反映出 AI 正在改變開發生態，junior 借力 AI 快速成長、senior 則需要在 「架構思維」 與 「多 agent 協作」 中找到新定位，其中有些啟發（insight) 可以跟大家分享。 為什麼 Junior 更容易上手 vibe coding？ 心智負擔低 → Junior 沒有太多傳統 code workflow 的框架包袱 敢於嘗鮮 → Gen Z / 年輕工程師天生習慣用 prompt-based 工具、跟 LLM 互動 少「優雅程式設計」的束縛 → 不太糾結「這樣寫會不會不夠優雅」，反而 embrace 快速迭代、快速出成果 反觀 Senior： 熟悉大型系統設計 有豐富的「工程正統流程」知識（架構設計、測試策略、效能優化、設計模式） 對 AI 生成 code 的品質 / 維護性通常比較保留 部分 10+ 年資深工程師，對 prompt engineering 沒那麼熟練，還在觀望 技能面（未來的關鍵能力） Vibe coding 本質上 = prompt engineering + AI co-pilot 管理能力 能力項目 誰目前比較有優勢？ Prompt 撰寫 / AI 互動 Junior 較強（熟悉 chat-based 流程） 系統設計 / 架構把關 Senior 較強 AI 生成 code 驗證 / Bug 察覺能力 Senior 較強（能看出潛在問題） 快速疊代 / Hackathon 式開發 Junior 較強 長期維護性 / 穩定性 Senior 較強 總結 Junior 確實更快適應 vibe coding，並且更習慣以 「chat-based coding」 的工作流開發。 Senior 擁有驗證 AI 產物與系統設計的深度能力，但若不主動練習 vibe coding，長期會逐漸落後於新一波開發潮流。 就如同在 GAI 技術年會分享，希望帶給各位的感受， 『與 AI 協...
張貼留言
繼續閱讀>>

Vibe Coding 協作到自建 Dev Agent？從 Claude / Codex 到 OpenHands

過去一年，越來越多工程師開始 把 AI 真正帶進工作流程 。從一開始用 ChatGPT、Claude 來問語法問題，到後來很多人愛上 Cursor，直接在編輯器裡讓 AI 幫忙改 code、補 test case、甚至自動整理 PR。這樣的開發體驗，已經大大改變了我們寫程式的方式。 更現實的是，在很多企業內部、政府單位、或涉及機密資料的專案裡， 其實根本不能直接用 Cursor 或雲端 LLM 工具。   畢竟這些服務通常會把資料傳到雲端模型做處理，萬一專案裡有未公開的技術、敏感客戶資料，或是受限於法規 （像金融、醫療、政府標案） ，直接用雲端 AI 工具就會踩 紅線 。  因此，許多團隊反而更希望 「自己架一套 Dev Agent」 ，可以在內網執行，資料完全掌握在自己手上，該整合的內部工具、該讀的私有 repo、該串的 CI/CD pipeline，全部客製化、安全可控。 這時候，像 OpenHands 這樣的開源 Dev Agent 框架就特別有價值。它的出發點不是單純的 AI 助手，而是讓你能夠打造出一個真的可以跑在自己環境裡、可以理解整個開發流程的 AI 工程師。從建置到部署，從 CLI 操作到瀏覽器查詢， 從多檔案編輯到自動測試，全部都能自己完成，甚至還能針對不同專案調整專屬的工作流。 對很多開始探索 AI 協作開發的團隊來說，這是一條 從 「AI 幫你寫一段程式」，走向「AI 幫你解決一整個任務」 的進化路徑。而且，還是在可控、可自定義、安全的環境裡完成的。 🧩 主要概述 OpenHands 是由 All‑Hands AI 開發的開源「軟體開發代理人平台」，能模仿人類工程師從建立程式、修改程式碼、執行指令，到瀏覽網頁、呼叫 API……等一整套開發流程 它提供雲端（OpenHands Cloud）與本地 Docker 運行版本，用戶能配置 LLM（如 Claude、OpenAI、Gemini…) 📚 核心特性與怎麼使用 代理人的工具能力 支援代碼編輯、命令行、執行環境、網頁瀏覽、API 呼叫—接近人類開發者完整技能。其中 OpenHands Cloud 版本提供 $50 試用額度讓大家方便使用，又或者如果自己本機有 docker 的話，可以自己Local 版本透過 Docker 自架環境。 ...
張貼留言
繼續閱讀>>

Google Gemini 全端 AI Agent 快速入門 - 打造「思考」的 AI 助理

一套從搜尋、反思到輸出的全端 AI 代理人範例，讓你看懂什麼叫 Research Agent 在 AI 工具百家爭鳴的今天，大家都在問一個問題： 「我能不能不只問 AI 答案，而是讓它像一位助理一樣，有流程、有反思、還有出處，真正幫我完成一件事？」 Google 最近釋出了一個相當具有指標意義的開源專案 gemini-fullstack-langgraph-quickstart ，正是為了解這個問題而誕生。 這套系統到底是什麼？ 這個範例不是傳統 Chatbot，而是展示一個完整的 AI research agent ： 它會根據使用者的提問，自動發想搜尋關鍵字、查資料、整合重點，最後給出答案還附上引用來源。背後的邏輯設計得非常扎實，不只是能跑，更是具備可讀性、可擴展性與可商用性。 它的流程大致如下：  1. 使用者輸入問題（例如：「抖音是否影響台灣選舉？」）  2. Gemini LLM 幫你想出關鍵字（不只是照抄問題）  3. 呼叫 Google Search API 抓資料   4. LangGraph 控制流程 → 判斷資料夠不夠 → 若不足，自動補查  5. 整合最終答案，並產生 citation（來源說明） 你可以想像這就像一位實習助理幫你寫報告， 不只輸出一段內容，而是會 去查、會判斷、會補資料，而且說明「我為什麼這樣說」 。 LangGraph 是什麼角色？ LangGraph 就是整個 Agent 背後的控制系統 。 用白話講，它幫你定義 AI 每一步要幹嘛、遇到什麼狀況該走哪條路、要不要反思、要不要再查，甚至可以定義條件邏輯與資料流動。 這就不像寫一個單純的 Chat API，而是比較像「把一個流程圖變成可以跑的程式」。 對工程師來說，它提供了從 prompt 到流程控制的設計彈性；對產品設計來說，它讓 AI 有了 「多步驟任務執行」 的能力。 技術架構與使用方式 這整套系統是 Fullstack 架構，前後端都幫你整好了，技術選型也非常實用：   前端：Vite + React + TailwindCSS + Shadcn UI  後端：FastAPI + LangGraph...
張貼留言
繼續閱讀>>