OpenAI Presence 為什麼只能“駐場交付”?前沿實驗室集體轉向 FDE 的訊號

一句話答案:OpenAI 之所以不讓企業自助購買 Presence、堅持由工程師駐場交付,是因為大模型能力正快速商品化,企業 AI 真正的落差已經從"模型強不強"轉移到"能不能在你的業務裡跑通"——而後者無法被打包成一個 API 賣給你。據 The Register 報道,OpenAI 官方對 Presence 的定性很直接:"暫不作為自助產品提供"(not yet available as a self-serve product),而利潤"可能藏在管道里"(margin in the plumbing)。這對每一家想落地 AI 的公司都是一個值得讀懂的訊號。

OpenAI Presence 是什麼?為什麼只能由 Forward Deployed Engineers 交付、暫不自助?

先給答案:Presence 是 OpenAI 面向企業推出的即時 agent 服務,橫跨語音與聊天;它不開放自助,是因為交付本身被 OpenAI 定義成一件需要工程師"駐場"完成的事,而不是買個賬號就能開通的 SaaS。

據 The Register 報道,OpenAI 於 2026 年 7 月 22 日釋出 Presence,首批聚焦三類場景:客服、外呼銷售,以及高風險的內部流程。真正的關鍵約束寫在交付方式裡——OpenAI 官方原文表述為:

"Deployments are led by OpenAI Forward Deployed Engineers and select global systems integrators. Presence is not yet available as a self-serve product." (交付由 OpenAI 的 Forward Deployed Engineers 與精選的全球系統整合商主導;Presence 暫不作為自助產品提供。)

換句話說,連 OpenAI 都不認為"把模型能力做成 agent"就等於"企業能直接用起來"。為了證明這套東西真能跑,OpenAI 拿自己做了樣板:據 The Register,Presence 已經在執行 OpenAI 自家的英文電話客服——能核驗來電者身份、呼叫賬戶上下文、執行獲批動作(處理賬單、賬戶變更、符合條件的退款),必要時再轉接真人。這套"先在自己身上跑通,再駐場幫客戶跑通"的路徑,正是駐場交付的典型形態。

同一釋出也見於 OpenAI 官方公告《Introducing OpenAI Presence》(2026-07-22 釋出,此處為 Internet Archive 官方頁面存檔)的一手資訊,可與上述報道交叉印證。

前沿實驗室為什麼集體轉向"駐場交付"?模型商品化後,錢在哪?

先給答案:因為模型能力正在趨同、被商品化,差異化和利潤從"模型層"下移到了"管道層"——也就是整合、落地與編排。誰能把 agent 真正嵌進客戶的業務流程,誰才拿得到這部分價值。

這不是一句口號,而是 OpenAI 用組織結構投的票。據 The Register 報道,Presence 的交付主體是 OpenAI 去年成立的諮詢臂——"OpenAI Deployment Company and Forward Deployed Engineers",而 OpenAI 在今年 5 月收購了諮詢公司 Tomoro,以此擴編這支"技術安裝勞動力"(technical installation workforce)。報道對這條商業邏輯的概括很到位:

"As AI models become commoditized, maybe there's margin in the plumbing." (當 AI 模型被商品化,利潤也許就藏在管道里。)

"管道"(plumbing)一詞值得咂摸:它指的不是模型本身,而是把模型接進真實系統、對齊真實流程、扛住真實風險的那一層工程與諮詢工作。這恰好印證了一個我們反覆講的判斷——模型是原料,價值在落地。關於 FDE 到底是什麼、以及"按價值交付"如何區別於賣工時,可以讀我們的定義文《什麼是 AI FDE 與價值交付》;本篇是它的新聞驅動續篇——當前沿實驗室開始親自照著 FDE 劇本做,這個模式就從"一種主張"變成了"行業訊號"。

FDE 駐場交付和傳統 IT 外包有什麼區別?

先給答案:兩者最大的區別在結算邏輯和關係結構。傳統外包按工時或交付物結算、甲乙方隔離、專案驗收即結束;FDE 則嵌入客戶團隊、按業務結果對齊、上線後持續迭代,並把每一個失敗案例沉澱成可複用的組織能力。它不是"外包 2.0",而是另一種交付契約。

維度	FDE 駐場交付	傳統 IT 外包
結算邏輯	對齊業務結果 / 價值	按工時或交付物
與客戶關係	嵌入客戶團隊、共擔目標	甲乙方、需求—驗收隔離
迭代方式	上線後持續調優、共生進化	專案交付即結束
知識沉澱	bad case → 可複用組織能力	隨專案結束流失
適配物件	高不確定、需深度上下文的 AI 落地	需求明確、可規格化的工程

為什麼 AI 落地天然更貼近左列而不是右列?因為 AI 專案在籤合同那一刻,需求往往還說不清:哪個場景最該先做、模型在你真實資料上會怎麼失靈、多少環節需要人兜底,這些只有駐場跑起來才知道。這也是 OpenAI 選擇讓 FDE 主導 Presence 交付、而非直接開放自助的底層原因——需求要在現場被發現,而不是在需求文件裡被規格化。想進一步理解 FDE 的價值交付邏輯,同樣可參考《什麼是 AI FDE 與價值交付》。

為什麼企業 AI 落地必須靠駐場交付?(用失敗率反推)

先給答案:因為"買了模型"離"落地成功"還隔著一條很寬的溝。連 OpenAI 都不敢讓企業自助上 agent;而 Gartner 的預測顯示,大量客服 AI 計劃最終會被放棄。我們據此認為:缺了既懂業務又懂工程的人駐場對齊,落地失敗的風險會明顯更高。

先看資料本身:據 The Register 報道,Gartner 預測,到 2027 年,在計劃把客服轉向 AI 的組織里,將有一半放棄該計劃。需要說明的是,這條預測只給出"計劃被放棄"的比例,並未逐項歸因。

至於放棄的原因——以下是我們基於落地一線經驗的判斷,並非 Gartner 的結論:放棄往往並不是因為"模型不夠強",而更多卡在落地環節——流程沒對齊、資料沒打通、邊界情況沒人兜底、上線後無人持續調優。這些恰恰是駐場交付要解決的問題:把"能演示"變成"能長期在生產裡跑"。關於落地為什麼這麼難,可以讀《為什麼企業 AI 落地這麼難》。

反過來看:如果落地是純技術採購問題,OpenAI 完全可以把 Presence 做成自助 API 收訂閱費,規模化又省人力。它偏偏沒有——在我們看來,這恰恰說明這道溝填不填得平,很大程度上取決於人,而不只是模型。

中小企業怎麼複用大廠的 FDE 劇本?

先給答案:你不需要自建一支 OpenAI 級別的 FDE 團隊,但可以照搬它的四步方法論——先診斷真實瓶頸,再讓懂業務的工程師駐場對齊結果,從高價值或高風險的單點切入,並把每個失敗案例沉澱成可複用能力。缺自有團隊時,可以借外部 FDE。

拆成可執行的四步:

1. 先診斷,別先上工具。 在寫任何 prompt 之前,先搞清楚哪個業務環節最該先被 AI 改造、失敗的代價有多大。OpenAI 也是先在自家客服上跑通,才向外推。你可以先花幾分鐘做我們的免費 AI 診斷,測出你最該優先落地的場景,而不是被"什麼熱做什麼"牽著走。
2. 讓懂業務的人駐場對齊結果。 交付的成敗標準不是"模型接通了",而是"業務指標動了"。讓工程師嵌進你的團隊、對齊真實結果——這正是 FDE 區別於外包的地方。
3. 從單點切入,別一次全上。 OpenAI 首批只做客服、外呼、少數高風險內部流程。中小企業更應聚焦一個高價值或高風險的單點,跑通再擴。
4. 把 bad case 沉澱成能力。 每一次失敗都應變成下一次能複用的規則、知識或流程,而不是隨專案結束流失。這是駐場交付相對一次性外包的複利所在。

如果你的團隊更想自己長出這套 AI 落地能力,而不是長期依賴外部駐場,可以參考我們的課程體系。

迷你 FAQ

Q:OpenAI Presence 可以自助購買嗎? A:暫時不行。據 The Register 報道,OpenAI 明確表示 Presence"暫不作為自助產品提供",交付由 OpenAI Forward Deployed Engineers 與精選系統整合商主導。

Q:什麼是 Forward Deployed Engineer(FDE / 駐場交付)? A:一種嵌入客戶團隊、按業務結果對齊、上線後持續迭代並把失敗案例沉澱為可複用能力的交付模式,區別於按工時或交付物結算、驗收即結束的傳統 IT 外包。

Q:為什麼企業 AI 落地經常失敗? A:據 The Register 報道,Gartner 預測到 2027 年,計劃把客服轉向 AI 的組織中將有一半放棄該計劃。我們認為,落地難點往往不在模型強弱,而在整合與流程對齊——這也是駐場交付要解決的核心問題。

更多常見問題見我們的 FAQ。