📖 本文约 3772 字 · 预计阅读时间 13~16 分钟
Palantir 把 Ontology 炒火了，但国内别把它当成知识图谱V2.0
很多企业做 Agent 的第一步，是把业务对象、关系、规则整理成一个漂亮的本体。然后发现：Agent 能回答"供应商是什么"，但回答不了"这个供应商延迟了，我该怎么办"。
一、每天都在发生的场景
以一个常见的业务场景为例：供应商延迟交付。
没有本体时，流程通常是这样：
采购员发现供应商延迟，需要登录 ERP 查订单、登录邮件看沟通记录、在 Excel 里算影响范围、再手动发邮件催货。整个过程中，数据分散、判断依赖个人经验、动作无法沉淀。换个采购员，处理方式可能完全不同。
很多企业觉得，只要建了本体，这个问题就能解决。
于是他们开始建模：供应商、采购订单、物料、库存、产线、合同，对象和关系画得清清楚楚。业务规则也写了不少：什么情况下算延迟、延迟多久要升级、哪些物料有安全库存。
本体看起来很完整。
然后采购员问 Agent：
"供应商 S-1024 的这批物料延迟了，会影响下周生产吗？我要不要现在切换供应商？"
Agent 的回答可能是：
"供应商 S-1024 是合规供应商，合作等级为 A，当前有 5 个未结采购订单。物料 M-301 的采购订单 PO-7802 原计划 7 月 28 日到货，数量 2,000 件。"
信息很全，但采购员真正想知道的是：
这批物料对应哪些生产工单？
库存还能撑几天？
这个供应商历史上延迟过多少次？上次怎么处理的？
替代供应商有没有现货？切换要多久？
这个决策要不要走审批？
Agent 一个都没答。
问题不在本体。本体告诉你"供应商是什么"、"采购订单是什么"、"它们之间怎么连"。但它不告诉你：现在这个供应商、这个订单、这批物料，正处在什么状态里。
Agent 不是笨，是它手里只有一本静态词典，没有实时地图。
二、本体能做什么，真的不能做什么
我们先 honest 一点：Ontology 本来就不是为了回答"现在该怎么办"而设计的。
它擅长的是三件事：
概念定义供应商、采购订单、物料、库存分别是什么
关系定义供应商供货给采购订单，物料组成产品，库存位于仓库
语义统一把 vendorid、suppliercode、provider_no 统一成"供应商编号"
这三件事是企业 AI 的地基，但只是地基。
Agent 真正要回答的业务问题，绝大多数是运行时问题：
这个订单现在卡在哪一步？
这个供应商最近有没有延迟？
库存还能撑几天？
同样延迟的两个供应商，为什么处理方式不一样？
切换供应商要触发哪些审批？
这些问题依赖的不是"定义"，而是当前世界的状态。
你可以把本体理解成企业的"户口本"：上面写了谁是谁、谁和谁什么关系。但户口本回答不了"这个人现在在哪里、在干什么、今天适不适合出差"。
三、为什么 Palantir 的 Ontology 也没能完全解决这个问题
第一篇我们讲过 Palantir 的 Ontology 为什么火。它确实比传统知识图谱更进一步——Object Type、Link Type、Action Type、Function、Interface 把"业务对象 + 关系 + 可执行动作"统一到一个平台里。
但 Palantir 的 Ontology 仍然是平台内的语义层。
它的数据要导入 Foundry，Action 要跑在 Foundry 里，Object 不是标准 SQL 表，Action 不是标准 REST API。它解决的是"在一个封闭系统内如何把业务语义和操作统一起来"，但没有解决"企业真实世界的状态怎么实时进入语义层"。
国内企业要学的不是 Palantir 的平台，而是它背后的一个思想：本体不能只定义世界，还必须能感知世界、连接世界、推动世界变化。
这就是我们想说的：
Ontology 不是终点，而是企业世界模型的第一层。
四、缺了什么：一张对比表就能看清楚
同样是"供应商"这个对象，静态本体和运行时本体看到的东西完全不同：
| 维度 | 静态本体 | 运行时本体 |
| — | — | — |
| 身份 | 供应商名称、编号、等级、合作状态 | 当前是否处于观察期、是否有未结质量异常 |
| 关系 | 供应商供货给采购订单、物料 | 当前未结订单数、本月已交付订单数 |
| 状态 | 状态枚举：active / suspended | 最近一次延迟天数、当前逾期金额 |
| 事件 | 无 | 过去 90 天是否延迟、是否变更过等级 |
| 上下文 | 无 | 历史延迟案例、专家处理先例、审批例外 |
| 动作 | 定义了"可以发起催货" | 现在能不能催、由谁确认、催完要通知谁 |
看出差别了吗？
静态本体回答"供应商是什么"，运行时本体回答"这个供应商现在怎么样、该怎么办"。
要让 Agent 从"知道定义"变成"能判断"，至少要补四层：
五、缺了四层，不是三层
数据连接层：Data Fabric
本体再漂亮，接不上 ERP、WMS、邮件系统、质量系统的真实数据，Agent 就是在空中楼阁里推理。
Data Fabric 不是 ETL，也不是中台。它是一个逻辑数据连接层：每个本体对象绑定真实数据源、更新频率、信任策略和冲突解决规则。
比如"采购订单"要同时连接：
ERP 里的订单主数据
WMS 里的入库记录
邮件系统里的供应商沟通记录
质量系统里的来料检验结果
没有这一层，后面所有状态都是 stale 的。
世界状态层：World State
每个业务对象，不能只定义它"是什么"，还要知道它"现在怎么样了"。
比如"供应商 S-1024"的运行时状态包括：
当前未结采购订单数
最近一次延迟天数
当前逾期金额
待处理质量异常数
是否处于观察期
World State 要回答的是：业务世界的当前快照是什么。
事件流层：Event Stream
业务世界不是静止的。采购订单被创建、供应商确认交期、物料入库、质量异常被发起、供应商等级被调整，这些都是事件。
Agent 要知道：
这个供应商过去 90 天延迟过几次？
这个订单从创建到现在经历了哪些状态变更？
当前延迟是由哪一次事件推进到的？
事件流回答的是"怎么走到现在的"。
一个只有 World State 没有 Event Stream 的 Agent，就像一个只能看体检报告、不能看病历的人。你知道供应商现在逾期 5 天，但不知道它过去是每次都逾期 1 天、还是这次突然恶化。
上下文图谱层：Context Graph
这是最被低估的一层。
上下文图谱记录的不仅是事实，还包括：
谁批准了这个例外？
为什么这个供应商可以延迟 7 天而不切换？
上次类似情况是怎么处理的？
这个判断的置信度有多高？
这个决策后来有没有被推翻？
它让 Agent 从"检索已知事实"升级到"理解当前情境"。
举个例子：两个供应商都延迟了 5 天。静态本体只能判断"都延迟"。World State 能告诉你"逾期金额分别是多少"。Context Graph 能区分：
供应商 A 是长期战略合作方，过去 3 年履约率 98%，这次是因为不可抗力，已经承诺下周补齐，且替代供应商交期要 45 天；
供应商 B 是首单试用，联系不上，没有历史记录，且替代供应商有现货。
这两个供应商的处理方式，显然不应该一样。
六、完整链路长什么样
回到供应商延迟交付这个场景。如果四层都补齐，流程会变成这样：
语义层：定义"供应商""采购订单""物料""库存""生产工单"等对象，以及它们之间的关系。
数据编织层：从 ERP、WMS、邮件系统、质量系统接入实时数据，形成统一视图。采购订单不再只是一个编号，而是关联着物料、库存、生产计划、历史交付记录。
世界状态层：实时知道每个订单的当前状态、每个物料的库存水位、每个供应商的履约健康度。
事件流层：记录订单从创建、确认、发货、入库、质检到结算的全过程，以及供应商等级变更、合同续签等关键事件。
上下文图谱层：记录历史延迟案例、专家处理先例、审批例外、替代供应商评估结果。
Agent 执行层：系统检测到供应商延迟后，Agent 汇总影响范围和候选方案；在人工确认后，才通过受控 Action 发起催货或供应商切换流程。
这才是 Agent 能真正干活的状态。
七、为什么我们总掉进这个坑
这个坑非常普遍，几乎每一个从知识图谱/本体切入 Agent 的团队都会踩。
原因有三个：
第一，本体看得见、摸得着，成就感强。
画一张完整的本体图，团队成员都能看懂，老板也能点赞。但 Data Fabric、World State、Event Stream、Context Graph 这些运行时层，短期内看不到漂亮成果，接起来又脏又累。
第二，很多厂商也在强化这个错觉。
有些平台告诉你："只要建好本体，Agent 就能理解你的业务。"这句话只说了一半。本体是理解业务的前提，但不是充分条件。
第三，静态数据比动态数据好拿。
业务制度、数据字典、ER 图相对容易收集。但实时订单状态、事件日志、决策上下文，往往分散在十几个系统里，口径还不一致。
所以很多人下意识地选择先做"看起来完整"的本体，把更难的部分往后放。
八、我们的解法：把本体升级成"运行时语义层"
我们现在的做法，不是否定本体，而是让本体从"静态定义"进化成"运行时语义层"。
具体做四件事：
第一，每个对象必须绑定数据源和状态
在建本体的时候，除了定义对象和属性，还要明确：
这个对象的数据从哪个系统来？
更新频率是多少？实时、小时级、还是 T+1？
有哪些业务状态？状态之间如何流转？
每个状态的数据质量和信任策略是什么？
比如"供应商"不只是一个实体，而是一个有合作等级、履约健康度、风险状态的运行时对象。
第二，规则必须引用运行时数据
业务规则不能写成"供应商延迟就催货"，而要写成：
"当供应商等级为 A，且关键物料延迟天数超过 3 天，且库存水位低于 7 天安全库存，且没有进行中的替代方案审批时，触发升级提醒。"
这里的"延迟天数""库存水位""进行中的替代方案审批"，都是 World State 和 Event Stream 里的数据，不是静态本体里的定义。
第三，事件必须被捕获、被关联、被解释
不是简单地把系统日志存下来，而是要把事件和本体对象关联起来。
一次"供应商等级变更"事件，要关联到：
哪个供应商？
谁操作的？
从哪个等级变到哪个等级？
依据是什么材料？
触发了哪些后续动作？
这样 Agent 才能回答"为什么这个供应商现在被降级了"。
第四，把决策上下文也建模
不要把上下文当黑盒。
我们把常见的决策场景也纳入语义层：
这个决策依赖哪些对象和状态？
谁参与了决策？
有没有例外审批？
置信度和风险等级是多少？
后续有没有被复核或推翻？
这样 Agent 下次遇到类似情况，可以参考历史先例，而不是每次都从头推理。
九、给企业落地者的四条建议
如果你正在做企业 Agent 或者本体工程，这四条建议可能帮你少踩坑：
不要把本体当终点。
本体只是第一步。从第一天开始，就要规划 Data Fabric、World State、Event Stream、Context Graph 怎么接、怎么更新、怎么治理。
优先做一个小闭环。
不要试图一次覆盖全公司所有业务。选一个业务域，比如供应商交付、客户投诉、财务审批，把"本体 + 数据连接 + 状态 + 事件 + 上下文"跑通，让 Agent 真正回答一个运行时问题，比建一百个类更有价值。
规则要写得具体，能落地。
避免"供应商有风险就提醒"这种模糊规则。好的规则必须能指出：风险从哪个字段来、阈值是多少、触发什么动作、谁需要确认。
先回答"现在是什么"，再回答"该怎么办"。
很多 Agent 项目失败，是因为一上来就想让 Agent 做决策。先做状态感知，让 Agent 能准确描述当前世界，再逐步加入判断和建议。
十、写在最后
本体是企业 AI 的重要基础设施，但它不是全部。
真正让企业 AI 活起来的，不是"定义得多完整"，而是"能不能连接真实数据、感知当前状态、追踪变化事件、理解决策情境"。
Palantir 把 Ontology 炒火了，但它没有告诉你的是：Ontology 只是企业世界模型的入口。真正难的，是入口后面那一大片运行时语义层。
这也是为什么我们一直强调：不要只建本体，要建一个能运行的"企业世界模型"。
本体，只是这个模型的第一层。
END
