Forward-Deployed Engineering（FDE）
Forward-Deployed Engineering（FDE） 是把工程師直接放進客戶工作現場，從流程理解、系統整合、原型實作一路做到上線與持續修正的部署模式。BusinessNext 2026-08-11 以 OpenAI、Anthropic、Google、AWS、Microsoft 與 Palantir 的 FDE 招募與部署趨勢為背景，並將它和硬體業的 FAE（Field Applications Engineer）對照；文中的職缺、採用比例、企業投入與 95% 試辦失效數字均是媒體整理或外部來源歸屬，不是本 wiki 的獨立 benchmark。
核心問題：最後一段導入
FDE 解決的不是模型能否在 demo 中回答問題，而是 AI 能否接上客戶的既有系統、資料、權限、法遵與員工流程。客戶懂自己的 domain 與 system，模型供應商懂模型與工具，但兩邊各懂一半；FDE 站在中間，把真實工作拆成可操作的流程，先做出能動的版本，再依現場回饋修到使用者真的能用。
這使 FDE 成為 agent-ready-data-governance 的現場執行層：文件是否過期、資料能否被讀取、誰有權限呼叫哪個系統，以及輸出如何回到工作流程，都要在真實環境中驗證，而不是留在產品簡報裡。
最小工作迴圈
可重用的 FDE loop 是：
- 走進現場：訪談真正執行流程的人，找出卡點、例外與隱性規則。
- 畫出系統邊界：盤點資料來源、既有 API、權限、法遵、人工核准與失敗處置。
- 快速做可運作原型：先讓流程跑起來，不把需求分析停在報告或架構圖。
- 以現場反應迭代：觀察任務完成、錯誤、延遲與使用者採用，持續修正整合。
- 留下可接手能力：把部署知識、工具、操作規則與維護責任交給客戶團隊。
- 回饋產品與模型團隊：將現場 failure cases 帶回上游，改善產品、harness 與後續部署。
這個 loop 與 loop-engineering 的 discover → execute → verify → iterate 相近，但 FDE 多了一個外部客戶與現場脈絡：驗證不只測工具輸出，也要測權限、組織採用、工作交接與上線後的責任鏈。
FDE 與 FAE 的關係
FAE 早已存在於半導體與硬體產業，從零組件選型、設計導入、測試、除錯到量產爬坡陪客戶完成導入。文章以聯發科的 turnkey 模式為例，指出晶片、參考設計、軟體、開發工具與測試支援能否變成可出貨產品，依賴深入客戶研發與測試現場的 FAE。
FDE 與 FAE 不完全相同：FDE 面對的是 AI 模型、企業資料、工具呼叫與工作流變更；FAE 更常圍繞硬體元件、製程與量產。但兩者共享一個可重用的商業邏輯：不是交付產品就結束，而是陪客戶做到成功。這也連到 taiwan-ai-reindustrialization：台灣既有硬體業的現場整合能力，可能成為 AI 軟體進入製造與企業流程時的比較優勢，但這是產業命題，不是已驗證的競爭力結論。
與標準化 SaaS 的取捨
標準化 SaaS 追求「一次開發、多數客戶自行使用」，FDE 的價值則來自深入不同客戶的資料、系統與例外。AI 的通用性越高，最後一段導入可能越複雜；若只把工具交給客戶，權限、文件、流程與變更管理的問題會被推回客戶自行承擔。
因此 FDE 不是無條件增加顧問人力。採用前要確認：
- 哪些現場差異是可重用的產品能力，哪些只是一次性客製。
- FDE 的部署經驗是否能沉澱成文件、skills、connectors、測試案例或產品改進。
- 客戶團隊是否能在部署後自主維運，而非永久依賴外部工程師。
- 現場客製的成本，是否能由更高的採用率、留存、任務完成率或 workflow KPI 支撐。
這使 FDE 與 ai-native-enterprise-governance 的 role → owner → sandbox → trace → KPI 鏈條相連：工程師可以協助導入，但不能模糊誰擁有資料、誰核准動作、誰承擔上線後責任。
EgentHub：超級個體與客戶能力擴散
BusinessNext 2026-08-27 的 EgentHub 案例把 FDE 從「陪單一客戶上線」推進到「把部署能力教會客戶」。受訪者描述一個不到 10 人的團隊服務逾 200 家企業，團隊多數成員以 FDE 角色把模糊需求在約 30 分鐘內收斂成具體場景，梳理散落在 Email 與老師傅經驗中的隱性知識，再依長文、tool calling、多模態等任務差異組合模型；文中的人數、客戶數、效率與營收均是受訪者／媒體案例，不是獨立 benchmark。
案例也將 FDE 的交付物拆成兩層：先和紡織、電子製造等客戶拆解訂單、圖面、查料、報價等流程，再把工作封裝成多個 agent，讓客戶的業務、工程、人資、採購能在內部複製給下屬。這使 FDE 不只是客製部署人力，而是 agent-ready-data-governance 的現場蒸餾與 agent-skills 的組織擴散層；要避免每案重新手工服務，還要把場景、模型選擇、驗收規則與交接責任沉澱回產品與 ai-native-enterprise-governance。
AI Ark 判準
看到企業 AI 導入案例時，若來源只列模型、API 或 demo，不足以判斷是否有 reusable workflow。更有價值的訊號是它是否說清楚：
- 真實使用者與現場流程由誰觀察；
- 資料、權限、法遵與既有系統如何接合；
- 原型如何被測試、否決、修正與部署；
- 上線後誰維護、誰接手例外，以及哪些知識會回饋到產品；
- 成效是否以任務完成、錯誤率、採用、週期時間或其他 workflow KPI 驗收。
FDE 因而應被視為 deployment pattern 與 customer-integration capability，不是一個職稱熱度排行榜，也不是把所有企業導入都改名成顧問服務。高風險、不可逆或涉及敏感資料的動作，仍需 agent-experience 的明確控制面、harness-engineering-for-ai-coding 的驗證，以及具名 owner 的人工核准。