FDE 讓烂尾 Agent 回正軌

以前大家盯著模型會不會答，現在我只看它能不能真的把流程跑完。

我做過太多 Agent 專案了。模型挑好了，工具也接上了，demo 跑起來還挺像那回事。結果一進真實流程就開始歪：業務說它“很聰明”，但工單照樣卡住；工程師說“再調 prompt”，產品說“先別動架構”，最後每個人都覺得問題在別人身上。最煩的是，這種專案看起來不是壞掉，是一直半死不活，像一台會喘氣的紙箱機。

後來我看到一篇知乎文章，標題很直接，叫 《OpenAI花40亿雇FDE，你接手烂尾Agent - 知乎》。它把 OpenAI 的 Deployment Company、Tomoro、前沿部署工程師（FDE）這條線講得很白。我看完第一個反應不是“哇好新”，而是“對啦，這才像真的交付”。

你缺的不是更會講話的模型，是能把它塞進流程的人

OpenAI成立Deployment Company，融资40亿美元，收购咨询公司Tomoro，派出“前沿部署工程师”（FDE）进驻企业，手把手帮客户调系统。

翻譯一下就是：Agent 專案死掉，通常不是因為模型不夠強，而是沒人把它放進企業流程裡，還順手把一堆髒活收掉。資料怎麼進來、權限怎麼控、失敗怎麼退、人工怎麼接、日誌怎麼追，這些才是最容易把專案拖死的地方。

我以前也踩過這坑。做內部客服 Agent 的時候，我整天盯著回答品質，覺得只要回得像人就行。結果客服同事第一個抱怨的不是“不夠聰明”，而是“它會改錯工單狀態”“它不知道什麼時候該停”“它一失敗就把整條鏈路卡死”。那時我才真的懂，Agent 不是聊天產品，它是流程產品。

FDE 這個思路有意思的地方，在於它承認一件很現實的事：企業裡最值錢的，不是模型參數，是把模型接進真實系統的人。這個人要懂業務，也要懂整合，最好還願意蹲現場看人怎麼用。OpenAI 這種做法，本質上就是把“售後”前置成“交付”。

實操上我會先做一件很土但很有效的事：每個 Agent 專案一定要有一個落地 owner，而且不是 PM 兼著，也不是單純的 prompt 工程師。這個人要扛四件事：

• 輸入從哪來，格式是什麼，髒資料怎麼處理。
• 輸出給誰看，誰確認，誰兜底。
• 失敗時退回哪一步，超時怎麼算，誰來告警。
• 上線後怎麼驗收，標準不是“能聊”，而是“能完成任務”。

如果你團隊裡沒人願意接這個角色，我會很直接地說，這案子大概率還停在 demo。不是模型不行，是沒人對最後結果負責。

別再問它聰不聰明，先把交付鏈路畫出來

文章裡提到 OpenAI 和 Anthropic 都在往企業裡扎，這不是巧合。模型公司一開始賣能力，後來賣結果。結果怎麼來？靠一條能跑通的交付鏈路，不是靠更花俏的 prompt。

我很常看到團隊一上來就問“怎麼讓 Agent 更聰明”。這問題太虛了。真正該問的是：它在哪個節點做決定？哪些決定必須可解釋？哪些動作必須人工確認？哪些步驟可以自動化，哪些步驟一定要保守？這些不先講清楚，Agent 再強也只是會亂跑的實習生。

我跑過一個採購審批 Agent 的 PoC，最開始做得很炫：自動讀信、抽需求、配供應商、產生審批單。結果一到財務流程就翻車，因為我們沒畫清楚“誰能改預算”“誰能改供應商”“審批失敗後信件回哪”。模型把資訊抽出來了，但系統不知道下一步該怎麼走。後來我把整個流程拆成狀態機，問題立刻少一半。

這就是 FDE 思路提醒我的地方：先把交付鏈路畫出來，再談智能。你可以先寫清楚這幾項：

• 觸發條件：使用者點了什麼，系統收到了什麼事件。
• 決策點：模型在哪些節點輸出建議，哪些節點直接執行。
• 審批點：人在哪一步介入，介入後怎麼繼續。
• 回滾點：失敗後撤銷什麼，保留什麼。

我再補一句我自己的習慣：每個 Agent 專案我都先寫一頁“失敗說明書”。先寫怎麼壞，不先寫怎麼好。因為真正決定專案能不能活下來的，往往是失敗時怎麼收拾，而不是成功時 demo 多漂亮。

收購諮詢公司不是裝腔，是在補工程空白

很多人看到“收購諮詢公司”會覺得有點滑稽，好像模型公司開始學傳統 IT 外包了。說真的，我一開始也嫌棄。但後來我發現，這事其實很誠實。因為企業落地本來就不是純技術活，它永遠混著流程、組織、權限、合規和人情世故。

Tomoro 這種公司如果真被 OpenAI 收進去，價值不在於 PPT 多漂亮，而在於它知道怎麼進企業、怎麼拿系統權限、怎麼跟業務部門說人話、怎麼把一堆半成品接口拼成能用的東西。很多 AI 團隊死就死在這裡：工程師會寫 code，但不會改組織裡的流程。

我以前就吃過這種虧。技術上我們已經把 Agent 接到 CRM、知識庫和工單系統，結果上線前兩週才發現，銷售團隊根本不想改原本的提交流程。我們以為自己在做整合，實際上是在逼人換工作習慣。最後只能加一層旁路模式，先讓 Agent 在邊緣場景跑，再慢慢往核心流程靠。

這件事給我的教訓很直接：企業 Agent 的推進順序要反過來想，先旁路，再嵌入。實作時我會這樣排：

1. 先找一個不影響主流程的邊緣場景。
2. 讓 Agent 先做建議，不直接執行。
3. 把人工確認點放前面，先收集失敗樣本。
4. 穩了之後，再把低風險動作交給系統自動完成。

諮詢公司在這裡的作用，就是幫你少踩一輪組織上的坑。技術團隊通常高估接口、低估協調成本；諮詢團隊剛好相反，他們知道怎麼把“能不能用”變成“願不願意用”。

FDE 的本質，是把客戶成功寫進架構裡

我很喜歡 FDE 這個概念，不是因為名字聽起來厲害，而是它終於把一件被忽略很久的事擺上桌：客戶成功不是銷售後面的附屬品，它應該是架構的一部分。你做的每個 Agent，都要預設有人會失敗、有人會誤用、有人會繞過流程。

如果你看過成熟的企業軟體團隊，就知道他們很少把“部署完成”當終點。真正的終點是：客戶自己能穩定跑起來。FDE 做的事情，就是把這段灰色地帶補上。它不是在賣“聰明”，而是在賣“可持續使用”。

我在一個售後知識助手專案裡就把這思路用很重。沒有先追求模型回答多像專家，而是先做三層保護：第一層檢索命中率，第二層置信度閾值，第三層人工兜底。模型不確定時就直接提示“建議轉人工”，不裝懂。剛開始業務方還嫌它保守，後來他們發現，少犯錯比偶爾驚豔更重要。

你如果也想把這套思路落到團隊裡，我會建議把“上線”拆成三個角色：

• 構建者：負責模型、工具、接口。
• 部署者：負責權限、環境、監控、回滾。
• 陪跑者：負責看失敗樣本，跟業務一起改流程。

如果這三個角色全壓在一個人身上，他大概率會被拖死。Agent 專案最煩的地方就在這裡：表面上像技術案，實際上是跨職能案。你不承認這件事，後面一定返工。

真正值錢的是現場調試，不是遠端幻想

文章裡那種“派人進企業手把手調系統”的畫面，看起來很傳統，甚至有點笨。但我越做越覺得，這種笨辦法通常最有效。因為大部分 Agent 問題，根本不是 code 裡一眼看得出來的，而是在現場才會露餡。

像使用者會不會亂填欄位、業務會不會故意跳步、系統會不會在老舊接口上超時、權限會不會因為組織調整突然失效，這些你坐在辦公室想不全。得有人站在現場看 log、看人怎麼點、看誰在罵系統，才知道問題到底在哪。

我以前遠端做過一個跨部門協作 Agent，團隊每週都在視訊裡說“看起來沒問題”。結果真正到現場一跑，發現審批人根本沒看懂提示語，大家都在複製貼上同一段錯誤訊息。我們在會議裡吵了三週的“模型表現”，其實只是 UI 文案太裝。

所以如果你想學 FDE 的做法，我給你的建議很簡單：別只做遠端評審，盡量做現場陪跑。至少前兩週先把這幾件事做滿：

• 每天看一次失敗日誌，不要只看平均指標。
• 和一線使用者坐在一起跑一次完整流程。
• 把“使用者為什麼不用”記下來，別只記“模型答錯了”。
• 每次改動都留版本，方便回滾。

這聽起來像傳統軟體交付，但我反而覺得這才是 Agent 該有的樣子。別被“AI”兩個字騙了，真正把系統做穩的，從來不是幻覺，是現場調試。

你可以直接抄的落地模板

我把上面這些東西壓成一套模板，給那些已經接手烂尾 Agent 的人用。你不需要從頭再想一遍，先把骨架搭起來，再慢慢換零件。

這套模板的核心原則只有一個：先定交付，再定智能。順序一反，你就會一直在 prompt 裡打轉，最後把自己也繞進去。

下面這份不是給“想做 Agent”的人看的，是給“已經做了一半但快死了”的人看的。你可以直接拿去改，先讓專案活下來，再談優化。

可抄的模板

# Agent 落地 FDE 模板 v1.0

## 1. 專案目標
- 這個 Agent 具體替誰解決什麼問題？
- 成功標準不是「能回答」，而是「能完成哪一步業務動作」。

## 2. 業務邊界
- 哪些任務可以自動執行。
- 哪些任務只能給建議。
- 哪些任務必須人工確認。

## 3. 流程圖
- 觸發條件：
- 輸入來源：
- 決策節點：
- 審批節點：
- 回滾節點：
- 結束條件：

## 4. 角色分工
- 構建者：負責模型、工具、接口。
- 部署者：負責環境、權限、監控、回滾。
- 陪跑者：負責現場觀察、失敗樣本、流程修正。
- 業務 owner：負責最終驗收。

## 5. 失敗說明書
當 Agent 出錯時，必須回答：
- 它錯在輸入、推理、工具調用，還是流程設計？
- 錯誤是否可自動恢復？
- 是否需要人工接管？
- 是否需要通知相關人員？
- 是否要撤銷已執行動作？

## 6. 監控指標
- 任務完成率
- 人工接管率
- 超時率
- 回滾率
- 業務拒絕率
- 高風險動作誤執行率

## 7. 上線策略
- 第一階段：只給建議，不直接執行。
- 第二階段：低風險動作自動執行，高風險動作人工確認。
- 第三階段：穩定後擴大自動化範圍。

## 8. 每日陪跑清單
- 看失敗日誌
- 看人工接管記錄
- 看使用者回饋
- 看接口超時和權限失敗
- 看哪些步驟最容易被跳過

## 9. 複盤問題
- 今天最常見的失敗是什麼？
- 哪個步驟最拖慢流程？
- 使用者最不信任哪一步？
- 哪個動作最容易誤觸發？
- 下一版先改什麼？

## 10. 驗收標準
- 不是「模型是否聰明」
- 而是「業務是否能穩定完成」
- 不是「demo 是否好看」
- 而是「現場是否有人願意繼續用」

這份模板你拿去就能用，但我還是建議你別只複製文字。真正重要的是把它變成每週固定會問的問題：這條 Agent 鏈路到底哪裡在掉人。只要你開始這樣問，專案氣質就會變。

我見過太多 Agent 專案死在“大家都覺得差不多了”。FDE 這個思路最有價值的地方，就是它逼你承認：差不多，通常就是不行。你要嘛有人陪跑到底，要嘛就接受它繼續烂尾，中間地帶很少有奇蹟。

原始來源是這篇知乎專欄：https://zhuanlan.zhihu.com/p/2054104152914105203。我上面做的是工程化拆解和模板化整理，原文的觀點是底稿，模板和落地寫法是我自己補出來的。

相關權威連結我也一起放上：OpenAI、Anthropic、Tomoro、知乎專欄。