先不要從 OpenAI 開始。
從一家餐廳開始。
晚上七點半，外送平台的單子一直跳，前台客人排隊，後廚的牛肉麵已經出到第 47 碗。老闆站在出餐口，手上拿著一張被湯汁弄皺的點餐單，問了一句：「為什麼又少放一份滷蛋？」
這時候，如果有人跑來說：「我可以幫你把菜單文案寫得更好看」，老闆大概不會太感動。
因為餐廳真正卡住的，不是菜名不夠漂亮。
是前台點單、後廚備料、庫存、排班、外送、客訴，全部接不起來。滷蛋少放，可能不是廚師忘記，而是庫存表沒更新；庫存沒更新，可能是昨天外送退單沒記回去；退單沒記回去，可能是平台、POS、Excel 各記一套。
這很像很多企業導入 AI 的狀態。
大家以為自己缺一個更聰明的模型。結果真正痛的地方，是資料散在不同系統，流程卡在不同部門，責任藏在不同人的腦袋裡。
AI 能幫你寫一封漂亮 email，但業務還是要自己去 CRM 查客戶、去 Slack 問交期、去 Excel 找報價、再回頭判斷這封信到底能不能寄。
所以企業 AI 的問題，從來不只是「模型會不會回答」。
而是它能不能進到那個會出錯、會延遲、會互相踢皮球的工作現場。
企業 AI 不是幫你把菜名寫漂亮，而是進後廚重排出餐線。
最聰明的模型，為什麼還需要人進現場？
這就是 FDE 變重要的地方。
FDE 可以理解成 Forward-Deployed Engineering，或 Deployment Engineering。中文說「部署工程」有點乾，但意思很簡單：他們不是坐在遠端寫 demo，也不是做完售前簡報就離開。
他們要把模型帶進真實流程裡。
不是只看高層簡報，而是看一張工單怎麼進來；一筆訂單怎麼被修改；一份合約誰可以看；一個客訴什麼時候要升級；一個 AI 建議如果被員工覆蓋，理由要不要留下來。
換成餐廳比喻，FDE 不是來幫你設計新菜色的人。他比較像那個捲起袖子走進後廚的人：看點餐單從哪裡來，庫存怎麼扣，外送退單怎麼記，尖峰時段誰有權限插單，哪一步可以交給系統先做，哪一步一定要人按確認。
這也是為什麼 OpenAI 和 Anthropic 最近的企業動作值得放在一起看。把這些官方公告視為產品方向訊號，它們都在往同一個方向靠近：模型能力正在被包進更完整的企業部署方法裡。
OpenAI 成立了 Deployment Company，明確強化 Forward Deployed Engineers 這種部署角色。Frontier 則被定位成企業建置、部署、管理 agent 的平台，裡面談到 shared context、onboarding、feedback、permissions 和 boundaries。
Anthropic 這邊，則透過和 DXC 的合作，準備訓練大量 Claude-certified FDE，把 Claude 帶進銀行、航空、保險、製造、政府這類流程更重、風險更高的產業。MCP 這類標準，也在處理另一個更底層的問題：AI 到底要怎麼接上企業裡分散的工具和資料。
這些動作如果分開看，像是企業合作、平台功能，或大型客戶案例。但放在一起看，它們指向一個更實際的問題：
如果以前每家公司都要變成軟體公司，那 AI 時代，每家公司下一步要變成什麼？
每家公司都是軟體公司，然後呢？
「每家公司都是軟體公司」這句話流行過很長一段時間。
它不是說每家公司最後都要去賣軟體，而是說，銀行、零售、物流、教育、製造、醫療，最後都會靠軟體重新組織自己的工作方式。
所以企業開始買 SaaS、建資料團隊、做內部系統，把原本靠 Excel、Email、會議和老員工記憶維持的流程，一段一段寫進軟體裡。
但 AI agent 出現之後，下一步不只是再買更多軟體。
因為很多公司現在的問題，不是沒有系統，而是系統太多，流程沒有真的接起來。
客服有 ticket 系統，業務有 CRM，財務有 ERP，產品有 Jira，文件在 Google Drive，討論在 Slack 或 LINE。每個工具都說自己是 single source of truth，最後真相還是要靠一個資深同事把所有東西串起來。
業務員還要先從 CRM 匯出 Excel，再貼到聊天機器人裡問問題，這不是整合。真正的整合，是他打開客戶頁面時，系統已經把過去往來、付款風險、客服抱怨、交期延誤和下一步建議放在右側。
客服主管也一樣。
如果她每天早上還要打開 300 張未結案工單，自己判斷哪些是重複投訴、哪些可能違約、哪些該升級給銷售、哪些只是文件沒寫清楚，那 AI 摘要再漂亮，也只是幫她把雜訊整理得比較整齊。
真正有價值的是：系統先把高風險的 20 件排出來，附上原因、原始紀錄和建議處理路徑，主管再決定要不要採納。
這才是「每個工作流都可能變成 agent system」的意思。
不是整家公司突然變成 AI 公司。
而是那些重複、高價值、跨系統、又需要判斷的工作流，開始被拆成一條任務鏈：模型讀上下文，工具執行動作，資料提供依據，權限劃出邊界，人類負責審核與回饋。
企業要的不是一個更會說話的模型，而是一套更會收斂責任的流程。
Agent 不是聊天機器人，是一條會跑的出餐線
很多人聽到 agent，會想到很科幻的數位員工。但在企業裡，更務實的理解是：agent 是一個在特定範圍內，能讀上下文、使用工具、根據目標推進任務，並在必要時把問題交回給人的工作單元。
它不是神，也不是多一個聊天框。
它比較像一條會跑的出餐線。
前台點單進來，系統知道這桌不能吃花生。後廚備料時，庫存系統知道今天牛肉只剩 12 份。外送單延遲，平台訊息會回到客服工作台。客人抱怨少放滷蛋，系統能查到是點單漏選、後廚漏放，還是外送途中退單重開。
如果這條線沒有接好，再會寫文案的 AI 也只能把道歉信寫得好聽，卻不知道滷蛋到底是誰漏的。
企業裡也是同一件事。
模型答錯，不一定是模型笨。可能是同一個客戶在 ERP 叫「台灣分公司」，在 CRM 叫「TW Branch」，在客服系統又叫「台北辦」。AI 只是把這些混亂照單全收。
在 B2B SaaS 裡，這種情況更常見。客戶成功經理看到一張 enterprise support ticket，表面上只是「系統登入異常」，實際上牽涉到 SLA、合約續約、資安審查、implementation delay，還有產品團隊正在修的一個 bug。AI 如果只讀 ticket 內容，很容易把它當成一般客服問題；真正有用的是把 CRM、billing、CSM note、product issue 和合約條款串起來，判斷這是不是一個 churn risk。
所以企業 AI 的難處，不是把答案寫出來，而是讓答案出現在正確的權限、資料和流程裡。
FDE 的工作，就在這個地方。
他不是只問：「要不要加一個 AI chatbot？」
他會問：「這張工單從進來到結案，中間經過哪些人？哪些資料可以自動讀？哪些決策要留下紀錄？哪些建議可以直接寫回系統？哪些動作一定要人批准？」
這些問題不炫。
但真正的企業 AI，大多卡在這裡。
不是 PoC 很漂亮，而是正式環境很髒
很多 AI 專案在 PoC 裡都很好看。
丟 20 份 PDF，模型可以摘要。丟一段客服紀錄，模型可以分類。丟一份合約，模型可以抓風險。會議室裡大家點頭，覺得這東西應該很快就能上線。
然後一進正式環境，問題就開始冒出來。
誰能讀這些 PDF？舊版本合約要不要排除？摘要要存在哪裡？業務能不能把模型回答直接轉寄給客戶？如果 AI 標錯風險，法務要怎麼覆蓋？覆蓋理由要不要保存？下次類似合約進來，系統會不會記得這次修正？
這些問題沒有 demo 那麼性感。
但它們決定 AI 到底能不能從「看起來很強」變成「每天有人敢用」。
OpenAI 的 Tax AI 案例很適合看這件事。這個案例不是在展示模型懂稅法，而是在展示專家修正如何被產品化。
重點不是一句「AI 會報稅」。真正重要的是，會計師的修正被保存成 source、extraction、citation、mapping、correction trace，進一步轉成 eval 和工程任務。
換句話說，專家的人工修正沒有消失在一句「這裡不對」裡，而是變成系統可以學習的材料。
這也是 FDE 和 agent deployment 最關鍵的地方：feedback 不能只停在抱怨。它要能變成 trace、eval、test case 和下一輪改進。
錯誤如果不能被追蹤，就不能被改進。
餐廳也是一樣。客人抱怨少放滷蛋，如果店員只是在群組裡罵一句「今天後廚又出包」，下週還是會少放。真正有用的是回頭看：是哪個平台的單？哪個時段？哪個品項？是備料不足、標籤不清，還是出餐檢查沒有設計好？
FDE 可能是補丁，也可能是新常態
這裡也有一個值得懷疑的地方：如果 AI 產品真的成熟，為什麼還需要這麼多人進企業現場？
FDE 可能代表 AI 產品還不夠標準化。就像有些 SaaS 看起來是產品，其實背後靠大量 customer success、solutions engineer 和 professional services 才能交付。
但另一面也要承認：企業工作本來就不是乾淨的 API。
越高價值、越專業、越有風險的流程，就越多例外、權限、責任和歷史包袱。金融、保險、醫療、製造、政府，不可能只靠一個 self-serve 按鈕完成部署。
所以 FDE 可能同時是補丁，也是新常態。
說它是補丁，是因為它暴露出 AI 產品還沒辦法完全自助落地。模型公司需要用人力服務，把還不夠標準化的部署問題包起來。
說它是新常態，是因為只有進入現場，模型公司才知道哪些流程真的有價值，哪些錯誤會反覆發生，哪些人工修正可以轉成 eval，哪些部署模式最後能沉澱成平台能力。
這不是「AI 公司變成顧問公司」那麼簡單。
比較準確地說，是 API 正被放進一個更完整的企業部署包裡：模型、agent runtime、connector、MCP、資料權限、治理、FDE、系統整合，以及持續改進的 eval loop。
真正的問題，是誰定義工作流
因為當 AI 真的進入企業工作流，它會決定 ticket 的優先級、誰能覆寫 AI 判斷、覆寫紀錄會不會進入下一版 eval，也會決定外部 AI 平台在多大程度上掌握一家公司做事的方法。
以前導入軟體，很多時候是把已經存在的流程搬進系統。
現在導入 agent，可能是重新決定流程本身。
客服單進來，誰先看？AI 能不能先分類？分類錯了誰修？修正會不會留下來？下次同樣客訴出現，系統會不會自動升級？哪些客戶不能讓 AI 自動回覆？哪些內容一定要主管批准？
這些不是單純的技術設定。
這是在重新分配工作裡的權力：誰能定義流程，誰能覆寫判斷，誰擁有修正紀錄。
所以，下一階段的企業 AI，真正值得問的不是「AI 會不會取代 SaaS」，也不是「每家公司會不會變成 AI 公司」。
這些說法都太大，也太空。
更具體的問題是：
哪些工作流會先被 agent 化？
哪些流程必須保留人類判斷？
哪些企業會因為 AI 變得更自主，哪些企業反而會更依賴外部 AI 基礎設施？
當模型公司、FDE、顧問、SI、SaaS 和企業內部團隊一起重寫工作流時，誰會掌握新的流程定義權？
如果上一個時代的關鍵句是「每家公司都是軟體公司」，那 AI agent 時代的下一句，可能是：
每個高價值工作流，都有機會變成一個 agent system。
但真正關鍵的不是它能不能變。
而是誰來設計它，誰來治理它，誰擁有它留下的資料與修正紀錄，又由誰承擔它造成的後果。
企業 AI 最後爭奪的，可能不是聊天框的位置，而是工作流的定義權。