2026 年 9 月 28 日，Meta 在官方新聞室發布了〈Launching Meta Enterprise Platform〉，宣布將 Meta Enterprise Platform 設為新的企業 AI 業務支柱，並由剛離開 MongoDB 的 CJ Desai 領軍。這篇短公告真正要問的，是 Meta 能否把既有的模型、Agent 與商業觸點，變成企業願意部署並持續付費的產品。先看它說了什麼，再分清已有能力與尚待驗收的承諾。
Meta Enterprise Platform 宣布了什麼？
Meta 執行長 Mark Zuckerberg 把這項計畫稱為公司的下一支柱。官方列出首批方向：Muse 個人 Agent、Meta Business Agent、Muse API 與 Muse Code。對外承諾是把這些能力帶給企業與開發者；對內則設立 Chief Enterprise Platform Officer，讓 CJ Desai 直接向 Zuckerberg 報告。這是一張產品組合與組織責任的路線圖，讀者不宜把名單理解成每項功能都已整合為同一套可採購服務。
Today we are starting the next major pillar of our business, Meta Enterprise Platform
中文：Meta 正啟動下一個主要業務支柱，也就是 Meta Enterprise Platform。
Mark Zuckerberg，Meta 官方公告，2026 年 9 月 28 日
「starting」值得留意：新聞稿的重心是啟動新業務，而非展示一份可供企業逐項驗收的採購規格。Meta Enterprise Platform 的成敗，接下來仍要看交付範圍、資料邊界、價格與服務承諾如何落地。
新平台接上了哪些既有產品？
這不是 Meta 第一次對企業談 Agent。6 月 3 日的 Meta Business Agent 公告已介紹面向 WhatsApp、Messenger 與 Instagram 商家對話的 Agent，還另有供企業建立、客製與部署代理的 Business Agent Platform。Meta 當時稱，企業能把 Agent 接上 Shopify、Zendesk 等系統；這是 Meta 對自家平台能力的描述，並非本文的獨立實測。
另一端，9 月 8 日的 Muse 發布文章將 Muse 描述成能代辦個人任務、連接應用的 Agent，並說明其 Secure VM 權限與監督設計。想看個人產品的完整機制與風險，可讀 AlphaLab 的Muse 個人 Agent 分析；想理解模型與程式開發端的關係，可接著看Muse Spark 1.3 與 Muse Code 解析。個人產品的安全描述，不能直接替企業版背書：企業還需要自己的資料處理、權限、稽核與採購文件。
CJ Desai 的任務：把技術拼成企業產品
MongoDB 的 9 月 28 日公告證實，Chirantan「CJ」Desai 即日卸任執行長，前任執行長 Dev Ittycheria 暫代職務；Meta 則在同日宣布 Desai 將加入，擔任 Chief Enterprise Platform Officer。兩份第一手公告相互對上了人事變動。
products and services that companies can deploy
中文：企業能在自身業務中部署的產品與服務。
CJ Desai，Meta 官方公告，2026 年 9 月 28 日
Desai 這句話把題目從「模型有多強」移到「客戶能不能接入自己的流程」。他的企業軟體經歷，讓這項任命有清楚的組織邏輯；但經歷與職稱並不能代替產品驗收，也無法證明企業會因為 Meta 的社群規模就採用它。
AlphaLab 的判讀：入口很強，採購仍要逐關過
第一關：觸及客戶，不等於拿到企業系統權限
Meta 在訊息、社群與廣告有龐大商業觸點，Business Agent 因此有天然的接待與銷售場景。企業若要讓 Agent 查庫存、改訂單或處理退款，難題就變成身分授權、系統整合和錯誤復原。前者是流量優勢，後者是企業軟體的交付能力；兩者都要有，平台才可能留在日常流程裡。
第二關：安全宣示，要轉成客戶能檢查的邊界
Desai 在公告中表示，安全與隱私會從一開始納入企業產品。這是 Meta 的設計承諾。採購方需要進一步看到：哪些資料可進模型或日誌、管理員如何限制工具權限、敏感操作由誰批准、如何稽核與撤銷。若答案只停在個人 Muse 的 Secure VM 敘述，企業仍無法判斷自身環境的風險。
第三關：比起產品清單，更要看可重複交付的成果
Muse、Business Agent、API 與 Code 覆蓋了使用者、商家、開發者三端，組合有想像空間。更嚴格的驗收方式是選一個流程：例如客服回覆後建立工單。先記錄人工處理的時間、錯誤與升級率，再讓 Agent 在受限權限下跑相同任務，最後把失敗、人工接手與實際總成本一起算。若部署後仍需大量人工補救，產品清單再長，也只是較昂貴的展示。
現在值得追蹤的三個訊號
第一，Meta 是否公布企業版各元件的正式供應範圍、價格與服務承諾。第二，能否拿出企業資料治理、權限與稽核文件，讓客戶真正做安全審查。第三，是否有清楚定義任務、基準線與失敗成本的客戶案例，而非只展示對話數或觸及人數。對正在選供應商的團隊，先用一個低風險流程做受控試點，要求可匯出紀錄與人工接手機制，再決定擴大。
若你正在評估 Meta Enterprise Platform，先把「能接觸多少人」與「能安全完成哪一件工作」分開打分；下一次產品更新，重點對帳後者。