文｜新立場

今年 3 月 6 日上午十點，深圳騰訊大廈樓下開始排隊。人們帶着電腦，等騰訊雲工程師幫自己安裝 OpenClaw，首批八十多人在十點開始排隊，到十一點，數百個預約號已經發完。據騰訊方面提供的信息，當天有近千名開發者和 AI 愛好者來到現場。隊伍裏有退休航空工程師，還有小學四年級的學生。

OpenClaw 是開源軟件。騰訊提供的 Lighthouse 雲端部署方案，最快只需要五分鐘。另一邊，社交平台上已經有人做起代裝生意。遠程安裝報價一般在 50 至 100 元，上門服務通常在數百元。軟件可以免費獲取，部署工具也越來越簡單，人們卻依然願意為安裝和配置付費。

六個月後，騰訊又做了一件相似的事。9 月 10 日，騰訊雲推出 FDE 工程師認證，培訓合作伙伴完成智能體項目的需求分析、方案設計、應用搭建、交付實施與安全合規。同一天，月之暗面宣佈 Kimi 企業合作伙伴計劃，與傳統 IT 服務商、系統集成商共同培養前線部署工程師。

火山引擎的公開招聘頁面上，也出現了幾種不同的 FDE：有人負責 Agent 的開發部署，有人負責模型選型與推理優化，還有人專門進入客戶現場，弄清楚客戶究竟需要解決什麼問題。

在大模型商業化中，一直有一段很難省掉的工作，即模型可以通過API提供給成千上萬家企業，企業卻各有自己的ERP、數據庫、權限體系和業務流程。模型可以同時升級，客戶的系統和組織卻無法同步改變；模型賣出去以後，往往還需要有人跟進去，幫助它進入具體的工作環境。

因此，「FDE熱」暴露的問題是，如果每增加一家客戶，都要多派幾名工程師，那大模型公司最終會變成什麼樣的公司？

同一個模型，接不進同一家公司

大模型最初看起來是一門接近標準化的軟件生意。

把能力封裝在 API 後面，制定統一的價格和調用方式，客戶自行完成開發。模型升級一次，所有使用同一版本的客戶都能受益。

但模型進入企業以後，工作通常沒這麼簡單。假設一家企業希望 AI 幫忙審核合同，工程師真正開始實施時，首先要搞清楚合同存在哪裏、誰可以讀取、審核標準來自哪份制度、哪些部門有權修改，最後由誰批准。

模型即使準確發現合同中的異常條款，也未必有權訪問原始文件，更無法自行決定企業內部的審批程序。換一家客戶，這些問題往往要重新回答。

傳統軟件行業長期面對「企業越大，歷史系統越多，定製需求越複雜，交付工作也越重」的問題。開發一套產品可能只需要做一次，部署到不同企業，卻需要重複投入大量人力。

大模型沒有消滅這些問題，只是把它們重新暴露了出來。

Palantir 很早就把解決這道難題的工作變成了一種產品開發方法。「human equivalent of backpropagation」——人類版的反向傳播：工程師儘可能靠近客戶實際面對的問題，與核心研發團隊共同工作，再把現場不斷產生的反饋送回平台，形成新的產品能力。

理解這套方法，可以從 Palantir 的三種角色開始。Echo 要找到客戶真正需要解決的問題，協調業務人員和管理層；Delta 負責讓技術方案運行起來，包括數據基礎設施和實際應用；Dev 則與前兩者協作，把已經驗證的解決辦法開發成可供更多客戶使用的平台能力。

三種角色存在交叉，但形成了從現場發現問題到產品開發的協作鏈條。

火山引擎今年公開招聘的 FDE，體現了類似的分工。通用 FDE 要在客戶環境裏連接 API 和數據系統，從應用原型一直做到生產級 Agent，還要建設評估和可觀測體系。算法方向的 FDE 則進一步負責模型選型、微調和推理優化，並把客戶遇到的技術問題轉化為方舟與 Seed 的產品需求。

火山引擎還專門招聘 FDE Echo，這個崗位的重點是訪談和觀察客戶，把模糊、零散的業務反饋整理成可以驗證的產品機會，招聘要求甚至明確寫入了至少五年的解決方案諮詢工作經驗。

這類崗位的出現，很大程度上是為了縮短客戶需求在組織內部傳遞的距離。過去，一家企業說「月底對賬太麻煩」，需求可能先由銷售人員接收，再交給售前、產品經理和研發團隊，幾輪傳遞以後，研發收到的也許只剩下「需要增加一個財務接口」。

但客戶遇到的問題，可能與接口本身毫無關係。是兩個部門採用不同的數據口徑，還是歷史記錄缺失？究竟應該增加接口、調整流程，還是讓 AI 代替人工覈對？工程師離客戶太遠，很難判斷。

工程師離現場越遠，對問題的判斷越容易依賴二手描述。

FDE試圖把工程師重新推到業務面前。參與實際流程、親手搭建方案，再把反覆出現的問題帶回研發。如果這套機制能夠正常運行，前一個項目留下來的經驗，就有機會成為後一個項目直接調用的產品能力。

這是FDE和普通項目外包最容易拉開差距的地方。一個項目做完，只留下收入和一套客戶專屬代碼，交付就只是交付；如果還能留下連接器、工作流模板、評測方法和新的平台能力，這筆人力成本纔有可能被後續客戶攤薄。

同時，這也是大模型公司開始重新重視FDE的商業原因。單純提高Token調用量，只能說明企業使用了更多模型能力，模型真正進入客服、財務、研發、供應鏈等核心流程以後，企業還需要長期維護數據接口、權限規則、評估體系以及員工操作方式。

這些環節決定了 AI 能否成為企業日常運營的一部分，也決定了模型公司需要為每家客戶投入多少交付資源。但緊接着，客戶越多，需要進入現場的工程師也可能越多。一個模型可以服務十萬家企業，一個工程師卻無法同時完成十萬家企業的部署。

因此，騰訊、字節、Kimi 和 OpenAI 走出了不同的路徑。

騰訊、字節、Kimi，誰來承擔交付成本？

9 月 10 日，騰訊雲推出 FDE 認證，同時啓動合作伙伴招募。騰訊把需求分析、方案設計、Agent搭建、交付實施和安全合規整理成培訓與考覈內容，依託ADP平台，幫助合作伙伴建立企業級智能體交付能力。官方給出的定位很明確，這套認證主要面向合作伙伴專業工程師和個人開發者。

這其實是 IBM、微軟、SAP 都做過的事：把交付渠道化。

騰訊當前的選擇，首先解決的是交付半徑。ADP不需要為每一家企業配備自己的工程師，合作伙伴越多，可以進入的行業和客戶也越多。對擁有龐大雲生態的騰訊來說，這套體系比完全依靠自有FDE擴張更符合既有的商業基礎。

但渠道可以複製工程師，項目經驗並不會自動複製。

一家合作伙伴為某家銀行開發了一套特殊的權限流程，另一傢伙伴服務第二家銀行時，可能重新碰到相似的問題，如果項目經驗長期沉澱在不同服務商的代碼庫和實施團隊裏，平台能夠快速增加的主要還是交付人數。

騰訊接下來需要把FDE生態做成一套「越交付越省力」的系統。

合作伙伴在現場重複遇到的問題能否穩定進入ADP，ADP更新後的能力能否再回到整個夥伴體系，決定了這張交付網絡最後沉澱下來的是人力規模，還是產品能力。

字節選擇了一條更貼近內部研發的路徑。

字節則公開招聘了一組分工不同的 FDE，火山引擎的通用、算法與 Echo 崗位，分別覆蓋應用工程、模型優化和客戶需求發現。飛書商業化也在招聘 FDE，讓工程師進入客戶工作場景，使用飛書 AI 工具搭建工作流，並沉澱標準化方案和模板。

內部團隊最大的優勢是反饋距離短。工程師在客戶現場發現檢索效果不理想，可以直接將問題帶回模型和平台團隊；如果問題出在協作流程，也有機會從飛書產品側尋找解決辦法，客戶現場與產品研發之間少隔一層，信息損耗自然更小。

但這條路同時意味着，更多交付成本需要留在自己的組織裏。

做完第一個銀行項目，第二家銀行的工作量能減少多少；進入汽車和零售以後，銀行項目積累下來的經驗還能複用多少。這些問題最終都會體現到FDE的人效上。

對自建FDE團隊的公司來說，工程師數量增長本身沒有太大意義。更重要的數據，是相似項目所需的人天有沒有持續下降。

如果項目越來越多，FDE團隊也按照相近的比例擴張，業務規模擴大了，組織同樣會越來越重。只有現場經驗持續變成標準組件、平台能力和行業模板，自建團隊離研發更近的優勢才能真正兌現。

Kimi乾脆跳過了這一步，把合作伙伴放在了企業交付計劃的核心位置。9 月 10 日，月之暗面宣佈與華勝天成、金山雲、亞康股份、亞信科技、中軟國際等企業合作，共同培養 FDE 隊伍。Kimi 提供模型、Hosted Agents 運行底座和工程方法，合作伙伴負責發揮已有的行業知識和客戶服務能力，共同完成項目交付。

Kimi 可以藉助它們已經建立的客戶關係和交付隊伍，進入自己尚未深耕的行業。但在這種合作中，一個 Agent 為什麼在客戶現場運行不順利，究竟是模型的問題、工作流設計的問題，還是歷史系統的問題，最先了解情況的往往是合作伙伴。客戶現場的信息怎樣回到 Kimi，就成為這套合作模式中的一個關鍵環節。

今年 1 月，醫療 AI 初創公司 Lamar Health 的 FDE Hayden Krush 在接受 FDE Hub 採訪時，談起了自己的日常工作。他負責將 AI 接入專科藥房的保險事前授權流程。有時，他要連續一周寫代碼，完成客戶的初始系統集成；有時，他一天都在回覆郵件，處理客戶不斷出現的新問題。

工作中很重要的一部分，是弄清楚客戶到底希望系統如何處理那些極其具體的例外。比如，兩名患者的姓名和出生日期完全相同，系統究竟應該選擇誰？Hayden 所在的團隊選擇將決定權留給客戶，不讓 AI 自行判斷。此外，他發現越大的功能通常越需要針對客戶做調整，一些來自客戶的小建議，比如修改一個界面，卻可能很快讓所有客戶受益。

這也是 Kimi 需要面對的，Kimi 可以藉助服務商的人進入更多企業。至於這些人在現場學到的東西，有多少最終能夠進入 Kimi 的產品，仍需要後續項目來檢驗。

OpenAI 還是經典的力大磚飛，乾脆為這件事單獨搭了一家公司。5 月 11 日，OpenAI 宣佈成立由自己持有多數股權並控制的 Deployment Company，計劃投入超過 40 億美元的初始資金。它同時宣佈擬收購 AI 諮詢與工程公司 Tomoro，交易完成後將為新公司帶來約 150 名 FDE 和部署專家。

它採用獨立公司的組織形式，同時與 OpenAI 的研究、產品和內部部署團隊保持連接。這樣既可以建立專門面向企業交付的組織，也保留現場經驗進入模型與產品研發的路徑。

超過40億美元的投入本身，就足以說明企業AI現在的成本結構：模型研發依舊燒錢，把模型真正放進一家大型企業，同樣是一門需要重投入的生意。

OpenAI沒有把這一段全部留給埃森哲、IBM或者其他系統集成商，它選擇自己控制一家專門的部署公司。它既希望擁有企業現場，又不希望龐大的項目交付完全進入基礎模型公司的主體組織。

這其實也是FDE熱潮裏很有意思的一幕：越靠近企業核心流程，大模型廠商越需要補上過去屬於企業軟件、諮詢公司和系統集成商的能力。

騰訊把其中一部分能力交給生態，字節更多留在內部，Kimi藉助傳統IT服務商，OpenAI乾脆成立一家獨立公司。

組織形式各不相同，最終都繞不開三筆賬：交付的人由誰來承擔，客戶現場的信息由誰掌握，做完一個項目以後，有多少東西可以直接留給下一次。

這三筆賬，也決定FDE最後會成為AI公司的規模槓桿，還是一個隨收入一起膨脹的成本中心。

寫在最後

Palantir已經開始讓軟件接手一部分過去由現場工程師完成的工作。今年，AI FDE逐漸獲得更多Foundry操作能力，可以處理數據、代碼、評估和平台資源。9月8日，Palantir進一步推出AIP Evolve，讓多個AI FDE Agent協同優化已經運行的AI系統。用戶可以指定成本、延遲、評估效果等目標，並設定測試數據和修改邊界，再由Agent提出改進方案。

Palantir自己在介紹AIP Evolve時說了一句話：You can't scale what only humans can fix。（只靠人才能修好的系統，很難真正擴大規模）

這句話也適用於今天的FDE。騰訊今年發出多少張認證，字節招了多少工程師，Kimi簽下多少合作伙伴，都只是早期數字。企業AI真正進入規模化階段以後，項目數量增長並不足以說明模式跑通。

第一個銀行項目需要十個人做三個月，第二個項目如果仍然需要十個人做三個月，公司的收入雖然增加了，人力成本也會跟着上升；如果第二個項目只需要五個人，一個月就能完成；再往後，數據接口、權限規則、行業評測和常用工作流都已經成為平台裏的標準能力，這門生意纔開始表現出軟件應有的複製能力。

FDE最有價值的地方，就是能把一次昂貴的現場經驗變成下一次可以直接調用的東西。

沿着這條路繼續走，未來一個FDE從銀行完成項目回來，不必再為下一家銀行從頭編寫數據接口、配置權限、處理那些似曾相識的異常。

上一個項目踩過的坑已經寫進產品，下一次，工程師仍然要走進客戶現場，但可以少做很多已經做過的事。

對今天的大模型公司來說，這大概也是FDE這筆賬最終要算清楚的地方：客戶可以一家一家拿下，交付不能永遠一家一家從頭再來。

*題圖及文中配圖來源於網絡。