——企业级 AI 落地，不是通用领域的简单延伸
赵杰辉 滴普科技创始人、执行董事、董事会主席兼CEO
2026 年
上一篇文章讨论了智能体的记忆机制——AI 在企业里“记什么”，知识的载体应该长什么样。这一篇，我想接着讨论模型本身的 Plan 能力——AI 在企业里“怎么想、怎么动”，规划的依据应该长什么样。这是企业智能体落地里面一条相对被低估、但越来越清晰的主线。
上一篇《记忆，是智能体的“灵魂”》讨论的是滴普科技 FastAGI 这一类企业智能体平台需要怎样的记忆机制，解决“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 办事”，而是“两份 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 边走到杠杆层”）→ 把业务意图交给通用执行层 → 执行层把意图翻译成工具调用/p>
上一节讲的四个失效条件，本质上都是因为没有业务语义层 Plan的情况下——通用 Agentic Model 直接把业务任务当工具调用任务来处理，跳过了“干什么”这一层。
而业务语义层和通用执行层这两层之间的协作是高频发生的——每一跳推理都可能反复切换：业务语义层提出意图、通用执行层调工具、业务语义层评估结果、生成下一个意图。如果完全拆成两个独立模型，业务意图、工具反馈、本体语义都要反复在外部消息中显式传递，工程复杂度和语义损耗都会显著上升。
更根本的是，业务语义层评估通用执行层的输出时——“这个工具调用结果在业务上算成功吗？”“返回的这堆字段在企业本体里对应什么？”——需要业务语义层能“看懂”执行层正在做的事。在同一个模型里，两层共享内部表征（同一套对企业本体、对工具、对业务规则的内化理解），这种评估是天然进行的；如果拆成两个模型靠 prompt 传递，信息会逐层丢失。
所以业务语义层在决定“下一步该走哪条边”时，需要知道当前手里有哪些工具能力可用、每条工具的边界在哪里。这种“知道自己手里有什么牌”的能力，在同一个模型里是最佳的工程实践，把两层 Plan 的能力融合到同一套权重里，通过训练让模型学会在不同任务情境下激活不同的推理动作。
业务语义层 Plan 和通用执行层 Plan 不是两个串行的模型，它们是同一个模型内部的两种推理模式，由训练把两种“边类型 → 推理动作”的条件反射融合到同一套权重里。
这是本体大模型这一代和“通用模型 + 外挂规划器”路线的根本差异。这里说的同一个模型，指的是 Deepexi 内部面向企业任务时业务语义层 Plan能力与通用执行层 Plan能力的融合；FastAGI 层面的多模型协同，则是 Deepexi 与通用语言模型、代码模型、多模态模型之间更大范围的分工。
业务语义层 Plan 能力需要内化的多种推理策略
讲清楚两层 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 Foil：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 里。
Deepology企业本体高质量数据集是 Deepexi 企业大模型训练的基础
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、Anthropic/OpenAI和滴普走在同一个演进方向上
这是这一节真正想说的核心——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 落地如何真正可行”这个共同的问题。
文章里所有的判断，都是滴普视角的判断，我希望它能为这场仍在进行中的产业讨论，提供一个稍微不一样的角度。
赵杰辉
滴普科技 创始人 · 董事长 · CEO
2026 年
参考资料 · 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.
举报/反馈富华优配提示：文章来自网络，不代表本站观点。
