FDE 是前線部署工程師（Forward Deployed Engineer）。本文談的 AI 供應商型 FDE，是進到客戶工作環境，親手把 AI 做進實際流程的工程師：弄清楚使用者要完成什麼任務，寫應用與工具，接上客戶的資料和既有系統，再把它做到能測試、部署、使用和接手。
假設客戶說：「讓客服直接用 AI 問訂單狀態。」FDE 要做的，是和客服確認現在怎麼查單，跟系統工程師讀訂單 API，寫出有權限控制的查詢工具，再用正常、缺資料和出錯的案件測試。交付時，除了客服能用的畫面，還要有接手團隊能跑的測試、部署方式和查錯說明。這個查單需求是說明用的假設案例，沒有實際部署或量測。
正式職缺已把這些工作寫得很具體。Cohere 的 Agentic Platform FDE 職缺要求把模糊業務問題變成有成功條件的流程，接工具、API 和資料，並處理應用的可靠性、安全與評測。Anthropic 的倫敦 FDE 職缺則直接列出在客戶系統寫生產應用，以及交付 MCP server 等技術產物的工作。MCP server 可以讓 AI 應用透過約定介面使用工具或資料，具體要做哪種接口，仍看產品與客戶環境。
這類工作由 FDE 和客戶、供應商團隊一起完成。各家公司安排會不同，不能把它理解成一個人包下所有職務。
先把「想用 AI」談成一件能做的事
客戶說要查訂單，可能只是想知道出貨了沒，也可能要客服解釋為什麼物流一直沒更新。FDE 會請客服重放一件實際任務，看看資料從哪裡找、哪些步驟重複、遇到不一致時找誰確認。若訂單和物流來自兩個系統，更新時間也不同，這就是程式要處理的條件，不能把兩個狀態拼起來就當成答案。
接著和業務負責人選首版範圍。例如先查有權查看的訂單，只回答狀態和資料更新時間；查不到或資料有衝突就回到原流程，先不修改訂單。哪些輸出可以接受、什麼情況要人工接手，也一起定下來。FDE 可以提出技術上做得到的選項，是否擴大到改單、取消或退款，仍由有權決定業務規則的人批准。
這段工作會留下首版範圍、要接的資料與系統、人工接手方式，以及後面拿來驗收的場景。團隊才能對著同一件事開發，而不是各自想像「做個 Agent」代表什麼。
讀接口、寫工具，再把模型放到適合的位置
首版談好後，FDE 要和客戶工程師讀 API 文件及資料欄位結構（schema），確認用什麼資料識別訂單、各狀態代表什麼、資料多久更新，以及登入者的身分怎麼帶進查詢。接著寫 connector，也就是連接系統的程式，或把查詢包成模型能呼叫的工具。欄位對錯、回傳格式、權限拒絕和接口超時，都得在聯調時處理。
模型可以讀懂客服問的是哪件事，但即時訂單狀態要向訂單系統查。退貨政策或操作手冊，則可以按需要用 RAG：先檢索相關資料，再讓模型根據找到的內容回答。這兩種資料用途不同，不能用一份舊文件替代即時訂單結果。
步驟已經確定時，可以把查詢、核對和回覆排成固定 workflow。若下一步需要根據查到的結果再選工具，可以考慮讓 Agent 動態決定。FDE 要能解釋選這個做法的原因，再用任務測試它，未必每個需求都要做成多個 Agent。Sierra 在 2024 年的工程文章也區分了資料檢索、系統 API 和執行順序。Sierra 把這類相鄰工作稱為 Agent Engineer；這裡借當時的說明看工程方法，具體產品與分工仍要看目前環境。
寫到這裡，團隊應該拿得到能執行首版任務的應用、接口與測試。模型對幾筆範例資料回答得像樣，還看不出它接真實系統後能否工作。
用評測和執行紀錄找出錯在哪裡
查單助手回答錯誤，可能是找錯訂單、工具回傳不完整、狀態規則寫錯，也可能是模型誤讀。FDE 要沿著執行紀錄（trace）看輸入、呼叫了哪個工具、系統回了什麼，以及最後怎麼產生答案，再決定改哪一段。
Cohere 的 FDE Nastya Kats 在 2026 年 8 月的文章中舉過一個例子：客戶的會議簡報 Agent，指令引用了不存在的工具，有些工具又處理不了需要的上下文。她描述的處理包含重建 Agent、修改支援工具，以及調整 Slack integration，讓它能承載更大的上下文。這是公司內部工程師的自述，沒有提供修復前後成功率；能看見的是 FDE 實際動到了 Agent 和整合程式。
回到查單假設，可以把正常訂單、物流延遲、無權查閱、接口超時和範圍外要求做成評測用例。每個用例先寫清楚預期結果，必要時由客服和業務負責人確認，再測資料是否正確、權限是否守住、遇到問題有沒有停在約定範圍，以及回覆多久出來。
改完後重跑測試，把這次錯誤也留下，避免後續修改又讓它發生。這段要交出的，是可重跑的評測、錯誤原因和修復結果。模型答案聽起來順，還不足以通過整件任務的驗收。
部署之後，讓使用者能用、維護者能接
進到客戶環境，還有部署、權限與故障處理的工作。FDE 要和 IT、安全及維護團隊確認存取授權、執行環境和紀錄方式，測試多個人使用時的負載，以及接口失敗時系統會怎麼做。監控要能讓人看見錯誤和延遲；發生問題後，誰處理、何時回到原流程或恢復上一版本，也要安排好。這些細節是這個假設案的交付建議，實際安排由團隊按風險和職權確認。
OpenAI 的阿布達比 FDE 職缺明確把工作寫到原型之後：穩定生產與客戶採用。客服開始試用，可能發現答案正確，卻還得切回原系統核對欄位。FDE 得看他需要怎樣的資訊和操作，把問題帶回實作；是否能用新流程完成符合範圍的任務，比登入過幾次更能說明採用情況。
Cohere 前面那篇文章還把客戶能自己操作、評測、排錯和擴充，列為交付目標。因此，交接除了文件，也可以和客戶工程師一起跑測試、部署一次、查一次故障，讓對方知道下一步怎麼做。測試集、接口說明、部署與恢復方法，以及後續支援的聯絡方式，要交到有人維護的地方。
圖解：KeepInAI。查單助手的交付示意；本文假設案例，實際分工依團隊而異。
現場問題如果來自供應商產品本身，FDE 還要和核心工程師查缺口、修接口，或把需求帶回產品團隊。查詢工具、評測用例和部署方式，有些也能整理成下一個團隊可用的內容。能不能進核心產品，仍要經過相應的產品與程式審查，不能因為一位客戶需要就直接改成共用功能。
從這些工作倒推，需要哪些能力
這類 FDE 有明確的工程門檻。Cohere 和 Anthropic 前面的正式職缺，都要求實作 AI 應用與客戶系統；能溝通需求，還得能把談好的東西寫出來、測過並處理故障。能力可以從前面幾段工作來看：
| 要能做什麼 | 可以拿出哪些證據 |
|---|---|
| 讀寫程式、接資料與 API，讓應用能部署和查錯 | 可跑的程式、connector 或工具接口、測試與部署說明，以及一次實際修復。語言、全端深度和基礎設施要求看職缺。 |
| 選 AI 用在哪一段，用評測找錯 | 說清模型、檢索、工具與固定流程的分工；拿出評測用例、預期結果、錯誤紀錄和修復後的回歸測試。 |
| 把業務問題拆成有範圍的任務 | 實際流程、首版做什麼與先不做什麼、驗收場景，以及為什麼選這個方案。 |
| 和不同團隊一起交付，讓客戶接得下去 | 共同確認的規則與接口、重要決定、試用回饋、交接說明，以及接手者自己跑測試或查錯的紀錄。 |
從後端、全端或資料工程過來，可以用已有的 API、資料與可靠性經驗，再補證自己如何問清需求、處理使用回饋。PM、實施和售前的流程、領域與協作經驗，也能用；若目標職缺要求親手寫生產程式，這段工程證據還是要拿出來。按實際做過的事盤點，不能只憑舊職稱判斷誰缺什麼。
沒有真實客戶時，模擬專案也可以展示實作、評測與查錯方法，記得明說是模擬。沒有實際採用或量測，就不要填進客戶成果或節省數字。
也不必把所有 AI 技能都當成必修。這些來源主要談應用、整合、部署和評測；從零訓練基礎模型、深度數學、特定框架，要看目標職缺是否需要。差旅、駐場、值班與長期維運同樣要逐份確認。工作有可靠性要求，不會自動變成永久一人值班的安排。
AI 導入時，FDE 主要負責哪一段
如果企業同時有業務、PM、核心工程和 IT 團隊，FDE 主要負責現場的技術拆解、實作、系統整合與驗證：把使用者的工作接到供應商的模型和產品，處理接入後的問題，帶到約定的部署、試用與交接狀態。這是本文依來源提出的協作方式，各家公司可能合併職務，仍要在專案裡確認決定權。
業務負責人定目標、資源、優先順序和業務規則，PM 協助把範圍、進度和驗收組織起來；PM 並不因此自動有權批准所有規則。FDE 要把技術限制、依賴和風險說清楚，和他們選可做的首版。真正使用系統的人則帶來任務和回饋，讓團隊看見它在工作中哪裡有用、哪裡卡住。
客戶的資料與系統工程師提供資料來源、欄位和 API 的正確解釋，與 FDE 聯調，並維護各自負責的系統；核心或平台工程師處理共用能力與平台架構，審查哪些修正能進產品。安全、IT 和營運在各自職權裡確認授權、環境、上線與故障接手條件。FDE 可以動手協作，也要把超出自己權限的決定帶到對的人面前。
團隊分工還會影響你是不是親手建置。例如 Anthropic 慕尼黑的 Applied AI Engineer 職缺安排整合夥伴建置，本角色在部署期間持續擔任技術顧問。同樣是客戶側的技術工作，這個相鄰職稱就採用另一種配置；談職缺或合作範圍時，還要確認自己親手做哪一段、跟誰一起交付。
要確認一個專案裡的 FDE 工作，就拿一件任務來談：由誰確認規則、誰寫與維護接口，FDE 親手交哪段程式和測試，使用者怎麼試，出問題後誰接手。把這些對到具體人和成果，才知道這次 AI 導入需要 FDE 做到哪裡。
