上一篇文章《記憶，是智能體的“靈魂”》討論了滴普科技 FastAGI 這一類企業智能體平臺需要怎樣的記憶機制—— AI 在企業里“記什么”，知識的載體應該長什么樣。 這一篇，我想接著討論模型本身的 Plan 能力—— AI 在企業里“怎么想、怎么動”，規劃的依據應該長什么樣。 這是企業智能體落地里面一條相對被低估、但越來越清晰的主線。

Plan（規劃）能力，是 Agentic Model 這一代真正的核心能力——給定一個目標，模型便能自主決定要做什么、按什么順序、調用什么工具、何時停止、如何修正。它本質上是模型內化的一種推理策略（Reasoning Strategy）。這件事，通用模型目前在 Coding、個人助理、Web 瀏覽這些公開領域，已經做得相當不錯——它們靠的是公開語料里上千億token 的“任務做法”積累。

但當我們讓 Agent 在企業里真正替代或輔助一個具體專業崗位完成具體工作，如做一次故障診斷、規劃一次商品促銷、完成一項跨系統的業務推理時會發現：通用模型的 Plan 能力，在這些場景里并不會僅僅以“模型再變強一點”的方式簡單延伸過去。它和企業級業務規劃能力之間，差的不是能力檔位，而是一種語義底座——企業的本體、規則、規程、因果等，這些從來不在公開語料里。

這一篇內容就是要把這件事講清楚——什么是企業級 Plan 能力，通用模型 Plan 能力在企業 AI 落地中哪些場景夠用、哪些場景不夠，真正需要補全什么。

企業級 Plan 能力本質上不是替代通用模型 Plan 能力，而是在它之上建立更高一層的業務語義能力。在文章后半部分，我會把滴普科技 Deepexi 企業大模型，作為產業上一種具體的工程實踐放進來討論。

一 · 企業級長任務相對于公開領域長任務，在工程上是另一種結構

企業級長任務和公開領域任務，從工程上看，不只是“難度更高”，而是另一種結構。具體來說，企業級長任務具備的四個核心特征導致兩者差異明顯。

特征一：多跳因果鏈跨多個數據源，且鏈路是“語境動態生成”的

企業里大量的真實業務推理是 5 跳、10 跳、20 跳的長鏈路。一次故障診斷從現象到根因可能要跨 6 個數據源，一次銷售復盤從結果到行動可能要追 8 跳。更關鍵的是，這些鏈路不是“查表能查到的固定故障樹”。同一類故障在不同企業、不同產線、不同時間點，合理的追溯路徑完全不同。鏈路是依賴具體語境動態生成的，這些鏈路并不都是寫在手冊中能被檢索出來的字段。

同樣的癥狀，不同的根因路徑。 某激光設備制造商和某新能源車企焊裝產線，都出現了“伺服過載報警 + X 軸定位漂移 + 節拍下降 8%”的相同癥狀。但前者的真實根因是車間隔壁的等離子焊機諧波干擾，后者的真實根因是 MES 里 72 小時前的車型切換參數同步問題。這兩條路徑不在任何一份 SOP 里——它們是這兩家企業本體里“邊該怎么走”的程序性知識。區分它們需要的不是更多的文檔，而是本體層面的程序性理解。

企業有成百上千份 SOP、操作規程、合規手冊，它們在寫的時候各管一攤，沒有人保證它們之間是完全一致的。當任務推理走到關鍵決策點時，經常面對的不是“按某一份 SOP 辦事”，而是“兩份 SOP 給的指令沖突，哪一份優先”。

這種仲裁不是在某一份文檔里能查到答案的，比如“反洗錢合規”和“客戶體驗提速”兩套規則在同一筆交易上沖突時，哪個優先取決于企業的本體里這兩類規則的元層級如何定義。

特征三：任務推理動態展開的本體子圖，token 預算裝不下

一次企業級長任務推理，在多跳推理過程中動態展開的相關本體子圖——所有相關實體、實體間關聯的邊、每條邊的語義、相關 SOP 的元層級關系——經常達到幾十萬 token 量級。即使是 1M context 的模型，把任務推理過程中動態展開的本體子圖全部塞進 prompt，工程上也并不經濟、效果上也不可靠。

這意味著模型必須靠“權重里已經內化的結構”來導航，它不能依賴每次都把完整本體塞進 prompt，必須在面對一個任務時，憑借內化的本體結構知道“該往哪條邊走、哪條邊可以先剪掉”。

特征四：“該停在哪”本身就是一個推理動作

企業級長任務里，“什么時候停止追溯、切換到給出結論”是一個獨立的推理動作。停早了，根因沒找到，答案是表面的；停晚了，會陷入無限回溯，token 消耗暴漲，用戶體驗崩潰等情景中。

這種“該停在哪”的判斷，依賴模型對本體里某些邊類型的語義識別，比如某條邊表示“這是一個根因節點”（意味著推理可以終止），某條邊表示“這是一個中間假設”（意味著推理還要繼續）。這種邊的程序語義，無法靠把邊的名字塞進prompt 來傳遞——必須靠模型對邊類型的內稟理解。

這四個特征加起來，描繪了企業級長任務的真實工程現實。它們和公開領域任務的差別，不是“難度檔位”的差別，是“任務結構”的差別。后面要討論的所有工程取舍，都建立在這四個特征上。

二 · 通用 Agentic Model 的能力延伸到 B 端，無法在深度業務崗位成為 AI 員工

Agentic Model 在公開領域已經證明了自己在通用業務領域的 Plan 能力：給定目標后，模型可以拆步驟、選工具、觀察反饋、修正路徑，直到任務完成。像Coding、網頁操作、個人助理等場景之所以效果驚艷，背后有幾個隱含前提：工具語義大體在公開訓練分布內；任務目標可由通用常識拆解；工具反饋能被模型直接理解；停止條件也相對清晰。

但當這套能力延伸到 B 端，尤其進入制造、零售、醫療、金融、供應鏈等深度業務崗位時，這些前提會被打破。企業里的工具不是公開工具，字段不是通用字段，流程不是單線流程，反饋也不全是自然語言反饋。模型即使能調通很多系統，仍可能無法完成企業業務里的邏輯推理。

失效條件一：業務對象不在訓練分布內

第一章的故障診斷例子已經說明，同樣的報警癥狀，在不同企業可能走向完全不同的根因路徑。真正決定診斷方向的，不是模型能不能查到 MES、PLC 日志、設備臺賬和維修記錄，而是它是否理解這家企業自己的設備結構、工藝路徑和故障因果鏈。

如果不理解“報警碼”“參數組”“工位編號”背后的企業語義，通用 Agentic Model 的 Plan 能力就會退化為基于字段名的猜測。它能生成排查清單，卻難以判斷哪條邊是癥狀到部件，哪條邊是部件到原因，哪條邊會構成根因證據。

失效條件二：業務目標是派生結果

零售經營復盤中，區域總監問：“華東大區銷售額完成率 73%，差 270 萬，明天會議討論什么行動？”通用模型容易回答：“加大促銷、優化產品組合、提升客單價。”問題在于，“銷售額”不是可直接操作的動作，而是銷量、均價、渠道結構、促銷節奏、庫存可得性等多個杠桿共同作用后的結果。

正確的規劃應先識別“銷售額”是派生量，再沿企業本體反向追溯到可執行杠桿，并判斷這些杠桿組合起來能否補上270 萬缺口，是否打穿毛利約束。通用模型知道公式，不等于知道在業務推理中看到派生量時，要觸發反向追溯。

失效條件三：業務動作受多目標多規則約束

企業任務往往不是“完成”就可以，而是要在多目標、多約束、多規則沖突下，合規完成。零售目標分解里，深度促銷可能會拉高銷量，但也會壓低毛利和均價；商品結構上移可能會提升均價，但也會降低轉化；直播投放可能帶來銷量，但也會改變渠道費用結構。金融合規中，客戶體驗、反洗錢、額度占用、黑名單篩查在同一筆交易上時，也會發生沖突。

這類任務需要先把動作折算到同一組約束等式和規則優先級里，判斷是否存在可行域。否則模型可能給出若干單獨看都合理，合在一起卻互相打架的建議。從企業角度看，這不是可執行計劃，只是并列建議。

失效條件四：停止點由企業本體決定

企業級推理不是越長越好，也不是越短越好。故障排查停早了，會停在“檢查電機負載”這類表面結論；停晚了，又會在所有可能部件之間無限擴展。訂單履約和合規審計也一樣：什么時候證據足夠、什么時候還只是中間異常、什么時候必須切換到人工復核，都不是通用語言能力能穩定判斷的。

真正決定停止點的是企業本體里的邊類型：有些邊表示中間假設，有些邊表示根因確認，有些邊表示需要人工復核，有些邊表示可以進入處置模式。沒有“邊的業務語義 -> 下一步推理動作”的穩定映射，Plan 的觀察－修正閉環會在關鍵節點斷掉。

所以，Agentic Model 延伸到 B 端后的主要斷點，不是工具數量不夠，也不是上下文窗口不夠大，而是業務語義層Plan能力缺位。模型可以接入更多系統、調用更多 MCP 工具、讀取更多 SOP，但只要不知道企業本體里哪些對象、邊、規則和約束應該觸發什么推理動作，就無法穩定完成企業業務的邏輯推理。

企業智能體 落地不能把通用 Agentic Model 直接當成深度業務崗位的 AI 員工，而是要讓 Plan能力跑在企業本體語義空間里，先解決“在企業里該怎么想”。

三 · 企業智能體落地需要分層Plan能力

Agentic Model 的 Plan 能力延伸到 B 端后，在企業智能體 落地時需要的是一個具備兩層 Plan 能力的模型——這是同一個模型內部的兩層：上面一層是業務語義層 Plan能力，負責“干什么”；下面一層是通用執行層 Plan能力，負責“怎么干”。兩層各司其職、協同工作，但融合在同一套模型權重里。

企業智能體需要增加業務語義層Plan能力

業務語義層 Plan（業務推理策略）——它的輸入是“業務任務”，輸出是“業務意圖序列”。它思考的是：這是個什么業務問題？在企業本體里需要走哪條推理路徑？這一步在業務上算成功嗎？現在該收斂了，還是繼續？觸發了哪條規則、需要什么仲裁？它的語義底座是企業本體。

通用執行層 Plan（工具調用策略）——它的輸入是“業務意圖”，輸出是“工具調用序列”。它思考的是：用什么工具實現這個意圖？參數怎么傳？出錯了怎么重試？返回怎么解析？它的語義底座是通用工具集——這正是 Agentic Model + Harness 在 C 端已經做得非常好的事情。

下面這張圖把這兩層 Plan 能力在 Deepexi 這種本體大模型內部的結構關系畫出來——它們不是兩個獨立的模型，而是同一套模型權重里融合的兩種推理模式。

圖 1 本體大模型的兩層 Plan 架構 —— 業務語義層 + 通用執行層在同一套權重里融合

業務語義層Plan能力和通用執行層 Plan能力的協作流程

一個企業級任務進來——業務語義層 Plan 在本體里定位任務（這是什么類型的業務問題、涉及哪些實體）→ 拆解出業務級別的子任務（先做反向追溯、再做約束求解、最后做收斂判斷）→ 對每個子任務形成“業務意圖”（比如“在銷售本體里從銷售額節點沿 actionable_via 邊走到杠桿層”）→ 把業務意圖交給通用執行層 → 執行層把意圖翻譯成工具調用序列、跑工具、拿結果 → 業務語義層評估結果在業務上是否達成意圖 → 決定下一步業務動作。

上一節講的四個失效條件，本質上都是因為沒有業務語義層 Plan的情況下——通用 Agentic Model 直接把業務任務當工具調用任務來處理，跳過了“干什么”這一層。

而業務語義層和通用執行層這兩層之間的協作是高頻發生的——每一跳推理都可能反復切換：業務語義層提出意圖、通用執行層調工具、業務語義層評估結果、生成下一個意圖。如果完全拆成兩個獨立模型，業務意圖、工具反饋、本體語義都要反復在外部消息中顯式傳遞，工程復雜度和語義損耗都會顯著上升。

更根本的是，業務語義層評估通用執行層的輸出時——“這個工具調用結果在業務上算成功嗎？”“返回的這堆字段在企業本體里對應什么？”——需要業務語義層能“看懂”執行層正在做的事。在同一個模型里，兩層共享內部表征（同一套對企業本體、對工具、對業務規則的內化理解），這種評估是天然進行的；如果拆成兩個模型靠 prompt 傳遞，信息會逐層丟失。

所以業務語義層在決定“下一步該走哪條邊”時，需要知道當前手里有哪些工具能力可用、每條工具的邊界在哪里。這種“知道自己手里有什么牌”的能力，在同一個模型里是最佳的工程實踐，把兩層 Plan 的能力融合到同一套權重里，通過訓練讓模型學會在不同任務情境下激活不同的推理動作。

業務語義層 Plan 和通用執行層 Plan 不是兩個串行的模型，它們是同一個模型內部的兩種推理模式，由訓練把兩種“邊類型 → 推理動作”的條件反射融合到同一套權重里。 這是本體大模型這一代和“通用模型 + 外掛規劃器”路線的根本差異。這里說的同一個模型，指的是 Deepexi 內部面向企業任務時業務語義層 Plan能力與通用執行層 Plan能力的融合；FastAGI 層面的多模型協同，則是Deepexi 與通用語言模型、代碼模型、多模態模型之間更大范圍的分工。

講清楚兩層 Plan 能力的協作之后，接下來要回答的是：業務語義層 Plan 能力具體需要在模型權重里編碼什么能力。

從上一節四個失效條件反推，它至少需要內化四種推理策略，這些本質上都是“看到企業本體里的某種結構特征，觸發對應推理動作”的條件反射。當然在實際企業業務場景中，則需要內化更多的推理策略。

• 第一，識別派生量節點，觸發反向追溯。看到銷售額、利潤率、完成率等結果型指標時，模型不能停留在指標解釋，而要沿企業本體反向追溯到可操作的杠桿層，把“銷售額差 270 萬”翻譯成城市銷售經理真正能執行的動作組合。
• 第二，識別約束等式，觸發多目標求解。看到“銷售額 = 銷量 × 均價”“毛利 = 銷售額 - 成本”等業務公式時，模型要觸發約束求解和副作用排查，而不是把公式復述一遍。當目標之間發生數學沖突時，要判斷可行域；如果不可行，要說明哪個目標必須松動、松動到什么程度。
• 第三，識別根因節點，觸發推理終止和處置模式切換。當本體節點已經構成確認性根因時，模型要停止繼續追問“為什么”，轉入“怎么修、需要哪些資源、是否需要人工介入”。如果當前節點仍是中間假設，則繼續追溯。
• 第四，識別動態語境，選擇追溯路徑。同一個業務癥狀，在不同企業本體里的合理路徑可能完全不同。模型必須基于相鄰設備布局、參數變更歷史、批次切換記錄等私有結構特征，動態生成本次追溯路徑，而不是套用公開手冊里的通用故障樹。

圖 2 業務語義層 Plan 的多種推理策略示意 —— 看到企業本體里的某種結構特征， 觸發對應推理動作

這幾種策略在 Deepexi 內部不是拼接的獨立模塊，而是訓練進同一套權重里的業務語義反射能力。它們解決的是業務語義層Plan“在企業本體里該怎么想”的問題；通用執行層 Plan 再負責把這些業務意圖翻譯成具體工具調用。兩層協同，企業級智能體才能穩定完成長任務推理。

四 · Deepexi：本體大模型的產品答案

講到這里，我必須把滴普科技自己的產品放進來——這是這一篇的“立場披露”段落。和上一篇一樣，我不是在做第三方陳述，是在講我們自己的產品定位。

Deepexi 企業大模型，是我們針對前面討論的“企業級 Plan 能力”做的具體回答。我把它的產品形態從四個維度講清楚——產業站位、產品組件、訓練數據范式、訓練架構分層。

產業站位：Deepexi 是企業級 Plan 能力的承載者

我先說 Deepexi 不是什么——它不是另一個通用大模型。我們沒有去和 Claude、GPT、Qwen、DeepSeek 這些通用模型在通用語言能力、通用推理能力上做對標。那個賽道已經有頂級玩家在做，通用語義這一面也是它們的強項。它也不是“通用模型 + 企業 RAG”的封裝產品。RAG 解決的是事實性知識檢索，不解決企業本體的程序性推理。

Deepexi 是企業級 Plan 能力的承載者——一個專門基于企業本體語義做長任務規劃與推理的本體大模型。它和通用模型是協同關系，不是競爭關系——通用模型在公開語義空間上做通用執行Plan，Deepexi 在企業本體語義空間上做業務語義Plan，兩者協同完成企業級長任務。

Deepexi 在大模型領域里專做一件事——把企業本體的程序性知識訓練進模型權重，讓企業級 Plan 跑在企業本體語義底座上。 通用模型把成本端 token 單價壓下來，Deepexi 把價值端的企業 Plan 準確率提上來。

Deepexi 不只是一個模型權重，它包含一個具體的本體承載組件——Deepexi Foil。這個組件的演進路徑本身就反映了滴普這幾年的工程積累。Foil 在 Deepexi 里承擔的角色，本質上是業務語義層 Plan 運行時的本體接入點——模型跑業務語義層 Plan 時，從 Foil 讀企業本體結構；Plan 推理產出的新本體結構，沉淀回 Foil。

Foil 模塊原本是 FastData 平臺（滴普 8 年來的核心數據底座）中負責本體建模和非結構化數據處理的部分。在過去幾年的客戶落地中，FastData Foil 是 FDE 工程師做客戶本體 schema 整理的核心工具。它處理兩類輸入：一類是企業里大量的非結構化知識文件（SOP、規程、維修手冊、故障案例庫），另一類是和業務專家共同抽取出來的本體 schema 草稿。

2026 年我們做了一次架構整合——把 Foil 模塊從 FastData 中拆出來，整合進 Deepexi，改名為 Deepexi Foil。原因很簡單：本體處理這件事和大模型推理本質上是一件事的兩面——本體是大模型推理的底座，大模型推理的產出又會反過來更新本體。把它們放在同一個產品里，工程上更順。

整合后的 Deepexi Foil 在 Deepexi 里承擔三個具體角色：

• 第一，非結構化知識的輸入端。企業的 SOP、規程、維修手冊等非結構化文件，通過 Foil 進入 Deepexi 的本體處理鏈路。
• 第二，本體生成結果的承載端。Deepexi 在客戶環境里抽取、推理、更新出來的本體結構，沉淀在 Deepexi Foil 里，作為后續推理的可讀可改基礎。
• 第三，FDE 工程師持續工作的存儲載體。即使在 Deepexi 替代了相當一部分 FDE 工作之后，業務專家和 FDE 工程師仍然需要做本體的精修、規則的添加、特殊場景的標注——這些工作的產出，繼續存儲在 Deepexi Foil 里。

Deepexi 的能力建立在 Deepology 這個企業本體數據集上。Deepology 的三個范式，不是孤立的數據形態，而是直接對應業務語義層 Plan 能力的三層訓練目標：

• 范式一是靜態結構層：實體 + 關系 Schema。這一層告訴模型這個 domain 里有哪些實體類型、它們之間存在哪些類型的關系、關系上攜帶哪些屬性。它訓練的是模型“識別業務對象”的能力——直接對應第二章失效條件一（業務對象不在訓練分布內）。模型先學會一個 domain 的“本體語法”，知道這個行業里都有哪些“名詞”和“動詞”。
• 范式二是路徑模板層：核心推理路徑定義。這一層用自然語言列出本體里幾條典型的多跳推理鏈路，告訴模型在這個本體里“合法的多跳路徑長什么樣”——不是單向的因果鏈，而是帶回路、帶評估閉環的真實業務推理結構。它訓練的是模型“識別多跳推理路徑”和“識別約束等式”的能力——對應失效條件二、三（派生量反向追溯、多目標約束求解）。
• 范式三是現象級實例層：層級化樹狀/圖譜狀結構。這一層是帶條件分支、帶終止判斷的具體推理軌跡——從現象級問題名稱開始，逐層展開“父級子現象 → 子現象 → 排查點 → 部件 → 原因 → 解決方案”。它訓練的是模型“識別停止點”的能力——對應失效條件四（停止點由企業本體決定）。模型學會在這種具體場景下，怎么走完一條完整推理路徑、什么時候該終止、什么時候該切換到處置模式。

這三個范式共同構成 Deepology 的訓練數據形態。截至目前，Deepology 已經積累 108 個業務本體——這是基于過去幾年和近400 家頭部客戶合作過程中，沉淀的真實本體建模 Know-how 轉化而來。

Deepexi 訓練架構的三層分層

Deepexi 訓練邏輯的核心，也是它區別于通用模型訓練的關鍵——通用模型的訓練目標是“下一個 token 預測得準”，優化的是語言生成質量；Deepexi 的訓練目標多了一層，在企業本體上“下一個推理動作觸發得對”，優化的是上一節講的幾種推理策略的觸發準確率。

Deepexi 的訓練邏輯可以一句話概括：通用模型的訓練優化“下一個 token 的生成準確率”，Deepexi 在此之上疊加優化“下一個推理動作的觸發準確率”。

前者讓模型“會說”，后者讓模型“會想、會動”；前者是 Chat / Reasoning Model 的訓練范式，后者是本體大模型的訓練范式。

具體到工程實現，Deepexi 訓練在三個層面上做了 Plan 能力的內化，這三個層級可按照企業業務落地的復用覆蓋范圍進行劃分：

• 第一層是能力訓練：把“看到本體結構特征 → 觸發對應推理動作”的條件反射訓練進模型權重——反向追溯反射、約束求解反射、推理終止反射等等。這是通過把范式二（路徑模板層）和范式三（現象級實例層）的數據按“本體結構特征 → 推理動作”的對應關系組織成 SFT 樣本來實現的。這一層是跨企業可復用的——這些反射能力一旦訓出來，所有企業、所有行業的長任務推理都用得上。這一層是固定成本投入，邊際成本隨客戶數量趨近于零。
• 第二層是行業本體持續預訓練：制造業的“設備－工藝－物料”骨架、零售的“商品－渠道－促銷”骨架、銀行的“賬戶－合規-風控”骨架等等。這種能力在通用模型的訓練目標里沒有顯式信號，必須靠定向數據 + 定向訓練目標才能內化，使模型學會識別推理鏈路上的多種信號。這一層是跨行業客戶可復用——同一行業的客戶共享這套骨架。每加一個新行業是一次性投入，服務該行業所有客戶。這一層讓 Plan 能力學會在不同行業骨架上展開。
• 第三層是客戶本體注入：廠商的具體設備清單、SOP、配電圖、產品型號切換歷史等。這一層是每家客戶獨有的，需要在客戶環境里完成本體對齊（通過 Deepexi Foil 承載）。但這一層是體量最小的一層——前兩層已經把“重活”做完了，客戶級注入主要是把企業的具體實例數據接入到已經訓好的本體推理框架上。這一層讓 Plan 能力具體綁定到這家客戶的實例數據上。

前兩層（能力 + 行業）是跨客戶攤薄的固定成本投入，客戶數量越多，單客戶分攤越低。 只有第三層（客戶本體）是真正“每家一份”的，且是三層中體量最小的一層。 這是本體大模型在工程經濟學上能夠規模化的原因。

訓練的更多技術細節（損失函數設計、數據配比、消融實驗等）會在后續的學術論文中逐步公開，這里只做工程方向上的勾勒。

五 · 用大模型完成 FDE 的工作：產業演進的同一個方向

講到這里，可能有人會問——這條路（用本體大模型替代 FDE 工程師做企業本體抽取與規劃）是滴普一家的判斷，還是產業更廣的方向？這一節我想認真回答這個問題。

FDE 模式：產業里被反復印證的有效路徑

Forward-Deployed Engineer(FDE，前線駐扎工程師)模式由 Palantir 在 2003 年首創——駐扎在客戶現場，和客戶的業務專家、IT 工程師一起，把這家企業的工作流和模型能力做深度結合。

企業級 Plan 能力不能直接從通用模型權重里涌現，必須有人在客戶現場把這家企業的業務本體、規則、推理路徑手工實例化。

Palantir 用 20 年實踐、Anthropic / OpenAI 用數十億到百億美元級別的投入，驗證了這件事的工程必要性。

滴普科技自身也是 FDE 路徑的實踐者

滴普科技在早期和 Palantir、Anthropic / OpenAI 當前強化的企業級工程服務路徑，在工程模式上有相似之處——通用模型 + FastAGI 智能體平臺 + FastData 數據融合平臺 + FDE 工程師駐場。FastData 是滴普 2018 年起的核心產品，過去8 年間，在中國市場為諸多大型企業（覆蓋先進制造、消費零售、生物醫藥、商業流通、交通、政務等領域，累計近400 家中大型客戶）構建了數據融合 + 業務運營的統一底座——這件事在工程角色上，FastData 與 Palantir Foundry 在全球市場上所承擔的角色是相似的。

Palantir 用 20 多年的產業實踐、Anthropic / OpenAI 用數十億美元到百億美元級別的投入、滴普用 8 年的中國市場落地——都用各自的方式，確認了同一個產業判斷： 在企業級 AI 落地這條路上，光有模型不夠，FDE 模式是目前為止最有效的工程范式。

這是這一節真正想說的核心——FDE 模式有效，但它的下一步演進方向已經開始浮現。我們來看幾件已經發生的產業事實。

第一件：Palantir 自己已經做出了 AI FDE。Palantir 官方文檔把 AI FDE 描述為“AI-powered forward deployed engineer, an interactive agent that operates Foundry for you through conversational commands"——一個由 AI 驅動的前線駐扎工程師，通過對話指令操作 Foundry，執行數據轉換、代碼庫管理、本體構建等任務。

第二件：Anthropic 官方宣布企業 AI 服務公司，OpenAI 的相關企業部署公司安排也由媒體披露。兩家全球最頂尖的通用大模型公司，在企業級落地上都不是簡單賣 API，而是在強化“模型 + 深度工程服務”的路徑。它們用最直接的方式說明：通用大模型 + API 調用，在企業級長任務上不夠用，必須有 FDE 工程把模型能力翻譯成業務能力。

第三件：滴普科技把 Deepexi 作為 FDE 工作中“理解企業本體、抽取本體 schema、做企業級長任務 Plan”這部分能力的模型化承載。FDE 工程師做的本體抽取與企業級長任務 Plan 設計，Deepexi 企業大模型可以承擔其中相當一部分通用工作。這不是把 FDE 工程師徹底替代（像業務專家、合規專家、特殊場景的精修工作仍然需要人），而是把 FDE 工程的“通用部分”（本體建模、Plan 模板、推理動作）向模型權重下沉，讓 FDE 工程師能從重復勞動里解放出來，專注在真正需要人去做判斷的部分。

Palantir 走的是“AI Agent 操作 Foundry 平臺”路徑——AI FDE 在 Foundry 平臺之上，把自然語言請求翻譯成對Foundry 本體對象、數據管道、代碼庫的操作；本體仍然是平臺層的可讀可改對象；Anthropic 與 OpenAI 的企業級部署布局，驗證了 FDE 這個工程范式的產業價值；

而滴普走的是“本體推理能力訓練進模型權重”路徑——邊的程序語義、推理動作的條件反射，是模型參數里編碼的能力。模型本身成為本體生成與推理的主體，Deepexi Foil 承擔本體可讀、可改、可持續沉淀的承載層。

兩條路徑的底層判斷是一致的——FDE 工作中相當一部分（本體抽取、Plan 設計、推理動作）是可以被產品化、模型化的； 但具體技術路徑有差別——Palantir 走 Agent 操作數據平臺，滴普走本體訓練進權重。 兩條路徑都是 FDE 模式基于 AI 的下一步演進。

坦誠地說，Palantir 在全球市場用 20 多年走通了這條路——它的品牌沉淀、市場地位、客戶體量，遠在滴普之上。不過我們在中國市場，基于近8 年和近400 家客戶的落地積累，在這條相似的工程演進路徑上，獨立做了我們自己的探索。

所以說用大模型本身完成 FDE 工程師的部分工作，是產業演進中一個真實的、值得關注的方向，Palantir、Anthropic / OpenAI 和滴普科技都在這條路上做了自己的探索。

六 · 回到 Token 經濟：協同的算式

在回到 Token 經濟之前，先回應一個被讀者經常問到的問題——Deepexi 這種本體大模型和通用模型、Coding 模型、多模態模型在企業里如何協同？

這個問題不是簡單的“多模型分工”——企業級協同有幾個獨特維度：多 Agent 間的業務語義對齊、關鍵判斷的多模型互校、跨流程的合規審計與回放、人機協作的權限治理。這些維度在通用領域的多 Agent 協同里要么不存在、要么是弱形態，但在企業里全部是硬需求。FastAGI 企業智能體平臺便是圍繞這些維度做的工程化探索，當然這是另一個獨立的話題，這里不展開，留待后續單獨討論。

所以回到上一篇文章開頭那個命題——AI 落地是一道 Token 經濟題。兩篇文章合在一起，這道題的兩端就清晰了——上一篇講的本體范式記憶，解決“價值密度端”（每個 token 攜帶精確的企業語義）；這一篇講的本體大模型，解決“Plan 準確率端”（每次推理與工具調用都基于企業本體規劃，不浪費 token 在錯誤規劃任務上）。

通用模型解決“通用智能”，把成本端 token 單價壓下來。 Deepexi 本體大模型解決“企業智能”，把價值端token 業務密度提上來。 FastAGI 把兩者協同起來，統一處理企業級長任務。 這是 Token 經濟在企業級場景里真正算得平的工程路徑。

這一篇的核心判斷——本體大模型是企業 智能體 落地的另一條主線，與通用模型協同、統一在 FastAGI 智能體平臺下，共同支撐企業級長任務的 Plan 能力，是從我們這幾年企業級 AI 落地的真實工作里反復推出來的。

Agentic Model 在公開領域取得的成就是真實的，企業級 AI 不是公開領域的簡單延伸，它有自己獨特的語義結構、獨特的失敗模式、獨特的工程化路徑。Anthropic 和 OpenAI 通過企業級工程服務公司和部署公司安排給出了它們目前的工程化答案；Palantir 用 AI FDE 給出了它的模型化探索；我們用 Deepexi 本體大模型 + FastAGI 多模型協同給出了我們的產品化答案。這些答案都在回答“企業級 AI 落地如何真正可行”這個共同的問題。

文章里所有的判斷，都是滴普視角的判斷，我希望它能為這場仍在進行中的產業討論，提供一個稍微不一樣的角度。

參考資料· References [1] 趙杰輝。 《記憶，是智能體的“靈魂”——Token 經濟時代下，企業級 AI 落地的一條主線》。 2026.（本文上篇） [2] Anthropic. "Building a new enterprise AI services company with Blackstone, Hellman & Friedman and Goldman Sachs." Press Release, May 4, 2026. https://www.anthropic.com/news/enterprise-ai-services-company [3] Bloomberg. "OpenAI Finalizes $10 Billion Joint Venture With PE Firms to Deploy AI." May 4, 2026. [4] TechCrunch. "Anthropic and OpenAI are both launching joint ventures for enterprise AI services." May 4, 2026. [5] CNBC. "Anthropic teams with Goldman, Blackstone and others on $1.5 billion AI venture targeting PE-owned firms." May 4, 2026. [6] Fortune. "Anthropic takes shot at consulting industry in joint venture with Wall Street giants." May 4, 2026. [7] Palantir Technologies. "AI FDE ? Overview." Foundry Documentation, 2026. https://www.palantir.com/docs/foundry/ai-fde/overview [8] Anthropic. Claude 3.5 / 3.7 / 4 Model Cards & Computer Use Reference. 2024—2026. [9] OpenAI. Codex / o-series for Agents Technical Documentation. 2025—2026. [10] DeepSeek-AI. DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning. arXiv:2501.12948. 2025. [11] Z.AI. GLM-4.5 Technical Report. 2025. [12] Anthropic. Model Context Protocol (MCP) Specification. 2024—2026. [13] 滴普科技股份有限公司。 FY2025 年度業績公告。 香港聯合交易所披露易。 2026.