4 月 9 日，阿里雲在北京召開了 AI 勢能大會。在大會現場，阿里雲智慧集團資深副總裁、公共雲事業部總裁劉偉光現場宣佈百鍊上線業界首個全生命週期 MCP 服務，無需使用者管理資源、開發部署、工程運維等工作，5 分鐘即可快速搭建一個連線 MCP 服務的 Agent（智慧體）。百鍊平臺首批上線了高德、無影、Fetch、Notion 等 50 多款阿里巴巴集團和三方 MCP 服務，覆蓋生活資訊、瀏覽器、資訊處理、內容生成等領域，可滿足不同場景的 Agent 應用開發需求（體驗可點選：https://bailian.console.aliyun.com/?spm=5176.29619931.J__Z58Z6CX7MY__Ll8p1ZOR.1.74cd521ccuvANG&tab=mcp#/mcp-market）。

又是 MCP！這個最近頻繁被關注、被討論的協議。

MCP 的英文全稱是 Model Context Protocol（模型上下文協議），這是由 Claude 的母公司 Anthropic 推出的一項開放標準協議。官方解釋是“其目標是為大型語言模型提供一種開放、標準化的方式，以便與外部資料來源、工具和服務進行連線。”簡單理解，MCP 相當於大模型領域的“HTTP 協議”，其並不繫結任何大模型，這意味著使用者可以在支援 MCP 的工具中，用任何大模型呼叫 MCP 服務。

在 MCP 爆火之前，Function Call 函式呼叫模式也被眾多開發者廣泛採納。由於不同廠商對於 Function Call 的標準、最佳化方式和迭代路徑均不統一，開發者可根據規則自由定義函式和 API 呼叫方式，這其中就會出現不通用的問題，導致普及困難且需要重複開發，這再次凸顯了 MCP 標準化的重要性。即便是不支援 Function call 的模型，開發者都能夠透過 MCP 協議的方式來呼叫任何一個服務，而這也讓我們進入了工具使用的平權時代。

DeepSeek 的爆火被很多媒體認為是開啟了“AI 平權”的新篇章，MCP 的出現則給我們帶來了工具使用的平權化。以阿里的 Qwen 系列為代表的開源模型，其表現出來的深度推理能力越來越強，這也讓模型逐漸具備使用複雜工具的能力。在 Function call 時代，不同模型的外掛 Function call 使用是閉源的，MCP 則解決了這一問題。

對於工具提供者來說，一個工具透過 MCP 協議可以被更廣泛的整合，這極大提升了工具的供應範圍。對於模型提供商來說，其上的工具 / 應用生態會極大繁榮，使用者可以利用這些工具 / 應用來解決更復雜的問題。

隨著 OpenAI、阿里雲接連宣佈在產品中整合 MCP 協議，我們可以預見未來將會有更多廠商加入。那麼，工具平權之後，這些廠商彼此之間的差異性會體現在哪裡呢？

從應用視角出發，我們可以將 MCP 理解為相對底層的服務，其下就是雲服務，其上就是模型層。模型層有一個很重要的工具是模型選擇工具，其結合使用者請求選擇 MCP 並將其執行完成，再透過加工處理的方式給到使用者結果。最上面一層就是目前大家現在常說的 Agent。在 MCP 之前，由於每家產品的 API 整合都千差萬別，這意味著 Agent 的開發者需要做大量的定製整合工作，MCP 的出現也讓我們看到了 Agent 生態越來越繁榮的可能性。

如果結合上述分層來看，除 MCP 之外的每層都是可能出現差異性的。在媒體採訪環節，阿里雲百鍊高階產品專家徐志遠表示，Agent+MCP 落地有兩個非常關鍵的問題：一是模型本身的能力是否足夠，比如是否支援深度推理，是否能對複雜的任務和工具進行排程；二是 MCP 的服務是否能穩定、可用、高效的提供。

基於此，MCP 服務本質上對映的是各軟體廠商、工程廠商以及工具提供商的 API 服務，所謂的 API 服務最基礎是 host 在雲上，因此阿里雲未來會提供更堅實的雲基礎能力和彈性化的 MCP 能力，讓所有軟體廠商提供的 MCP 均可以實現高效供給。此外，阿里雲將透過彈性、按量計算和出色的排程能力讓使用者實現“即點即用的 MCP 服務供給”，大幅降低供給成本。

有供給就會有消費，MCP 也是一個雙端的故事。這裡的消費就是 Agent，阿里雲百鍊平臺為使用者提供了端到端的 Agent 構建能力，可以幫助使用者快速將應用轉化成 Agent 的方式，相當於將 MCP 的應用搭建的完整流程在阿里雲的平臺內實現了閉環，來幫助 MCP 服務最終落地。

既然 MCP 聽起來是一個很不錯的故事，為什麼還是有很多軟體的 API 介面沒有 MCP 化呢？

在今天，我們與各類 AI 工具互動時最喜歡的方式是什麼？我相信大部分人都會選擇自然語言的方式，只需要輸入文字指令，AI 工具就可以自動流轉，這是對使用者而言最簡便的方式，但過去的很多 API 介面只是介面，並沒有轉換成容易被理解的文字形式。比如，我們告知模型，“當用戶查詢天氣時呼叫 A 介面”和“這個介面可以查詢天氣，你可以透過三種方式完成天氣的查詢，繼而完成 x 項任務”這兩種表述模式存在很大區別。

怎麼理解這種區別呢？作為一個 APP，高德比較常用的方式是地圖導航、打車等。當高德 MCP 化之後，使用者不需要繁雜的資源部署和運維工作，且無需編寫程式碼讓大模型呼叫和接管工具，直接在百鍊平臺上選擇通義千問大模型和高德 MCP 服務，即可快速搭建一個具備城市旅遊美食規劃的 Agent 應用。該 Agent 不僅能完成基礎的地圖資訊查詢任務，它可根據使用者需求查詢目的地天氣、規劃一日遊行程、搜尋美食店鋪推薦、導航或打車到對應店鋪等，真正意義上實現了 AI 和真實世界的互動。

因此，當軟體進行 MCP 化時，第一個難點就是判斷清楚其 API 介面和服務對於模型的價值如何更好地表述出來，使用者從模型視角會如何使用這項服務，這也是 Software for AI 的設計思路。第二是如何 MCP 化，包括但不限於語言化以及更多清晰的 schema 定義。基於此，MCP 化是需要一定時間來實現的。

隨著使用者對 Agent 逐漸產生感知，多 Agent 協作也成為大家十分關心的問題。坦白來講，多 Agent 和 MCP 其實是兩個方向的事情，多 Agent 目前要解決的並不是通訊問題，而是規劃的有效性問題。如果大家瞭解 Manus 的任務執行過程（不瞭解的使用者可以檢視 AI 前線往期試用影片：https://www.infoq.cn/video/grceDHIRrLJBWjvMw4v2），其虛擬機器呈現出來的就是每個任務的規劃步驟，這個步驟的合理性、有效性是很關鍵的。

即便這個規劃過程沒問題，在後續執行過程中大家會發現該任務需要訪問使用者的私域賬號才可以進一步檢視資訊（AI 前線的試用影片也體現了這一過程，此處不展開），當前的 Agent 產品大多無法與人類產生協同，無法詢問使用者是否可以用賬號登入某平臺檢視資訊。當然，我們可以選擇放棄所有私域的內容，但很多時候私域的內容往往更有價值。MCP 讓 Agent 可以更好地訪問各類軟體，但並沒有解決規劃路徑和執行策略中的問題。

總結來看，MCP 帶來的核心改變是讓很多基於人來設計的 API 介面逐漸變為“模型友好”的方式，Software for AI 會成為一個非常重要的趨勢，Agent 生態會基於此進入快速發展狀態。底層雲平臺的能力、模型的能力以及 Agent 構建能力都將成為差異化競爭的重要部分。阿里雲以及百鍊平臺已經將整個服務搭建完善，實現了端到端的完整閉環，這也是阿里雲致力於讓千行百業都建立起生產級 AI 應用的重要一步。