滴普科技赵杰辉：本体大模型，企业级智能体落地的产品化探索

上一篇文章 《记忆，是智能体的“灵魂”》 讨论了滴普科技 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 办事”，而是“两份 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 万缺口，是否打穿毛利约束。通用模型知道公式，不等于知道在业务推理中看到派生量时，要触发反向追溯。 失效条件三：业务动作受多目标多规则约束 企业任务往往不是“完成”就可以，而是要在多目标、多约束、多规则冲突下，合规完成。零售目标分解里，深度促销可能会拉高销量，但也会压低毛利和均价