OntoL产品设计思路—大模型是旁白，本体才是主角
当所有人都在讨论"大模型如何理解业务"时，我们可能问错了问题。真正该问的是：业务本身，是否已经被足够清晰地表达？
一、从一个"简单"问题说起
"帮我找出所有状态异常的井。"
这是一个在油气、能源、制造领域被问了无数次的问题。看似一句话，背后却藏着七条完全不同的技术路径：
- 直接查字段 —— 状态位已经写在属性里，查就是了
- Text2Sql 生成查询 —— 让 AI 帮你写 Cypher/SQL
- 专用本体查询工具 —— 把常用查询能力写死
- 派生公式计算 —— 跨表算出一个"异常分数"
- 因果传播链推演 —— 探头异常导致隔壁井异常，根因在哪？
- Action 推送异常实体 —— 异常发生时自动写入"异常井"实体，查的时候直接命中
- 流式本体监控 —— 实时监控，异常即事件
这七条路径，没有哪一条是"标准答案"。数据量小的时候，直接查字段最省事；数据量大了，物化异常实体才是性能最优解；如果需要根因分析，派生函数和因果链不可替代。
但比这更重要的是：这些路径的选择，取决于你的"本体"到底能表达什么。
二、第一人称 vs 第三人称：谁在看这个世界？
在讨论本体与大模型的关系时，有一个极少被说清但极其关键的区分：
Ontology Action 是第一人称视角，Agent Action 是第三人称视角。
什么意思？
- Ontology Action（第一人称）：是"井"自己在行动。"井关闭阀门"、"井进入异常状态"、"井影响隔壁井"——这些动作的主体是领域实体本身，语义锚定在业务对象上。
- Agent Action（第三人称）：是 AI 在操作。"调用 API 查井状态"、"搜索文档"、"执行 Python 脚本"——这些动作的主体是外部代理，语义锚定在工具调用上。
大模型，天生就是第三人称。
它站在业务之外，像一个旁白，描述"我调用了某个工具"、"我查到了某个数据"。它可以被训练去理解"井关闭阀门"这句话的字面意思，但它无法真正理解这个动作在本体网络中的位置：这个动作会触发什么派生规则？会影响哪些关联实体？会改变什么推理结论？
AI 能理解 Ontology Action，但理解不了 Agent Action 的领域语义。
这就是为什么 Ontology Action 可以作为 Agent Action 被大模型调用（大模型可以"帮"井去关闭阀门），但反过来不行——大模型随便写的一段 Python 脚本，本体引擎无法知道这段脚本在业务上意味着什么。
大模型是旁白，可有可无。推理机才是主角，它负责在新增数据、迭代数据、推理数据之间形成闭环。
三、FDE 不是画饼，是画能力边界
很多人谈 FDE（Feature-Driven Engineering，特征驱动工程），谈的是"我要做什么功能"。但真正的 FDE，应该谈的是"我的工具能支撑什么方案"。
Palantir 的 FDE 之所以有说服力，不是因为方案画得好，而是因为它的 Ontology Model、AIP、Foundry 是一体化的。它说"你可以这样做"，是因为它的产品确实能做到。
没有工具的 FDE，是空中楼阁。
OntoGraph 在面对"异常井查询"这个问题时，能给出七层方案，并且能告诉你每一层的利弊：
方案不是唯一的，取舍才是核心。 当数据量上来以后，我们要的不是一个 demo，不是一个玩具，而是能告诉你"在当前的工具能力边界内，哪条路能走通、哪条路会踩坑"的务实判断。
四、卫星项目的启示：为什么底层必须自研？
最近 OntoGraph 在做一个卫星项目，这让我们对"空间"有了更深的理解。
大多数空间场景是矢量空间：点、线、面，拓扑关系（包含、相交、距离）。但卫星不同，它是大规模栅格/场计算——温度分布、高程 DEM、遥感影像。
场计算需要什么？像素级的加减乘除、卷积、傅里叶变换、克里金插值、坡度坡向分析……
如果用 Neo4j 存空间关系，再用 GDAL 做栅格计算，再用 Kafka 做数据同步，再用一个规则引擎做派生——技术上可行，但架构臃肿到无法维护。
为什么？因为每一层都在用自己的语义模型：
- 图数据库说"节点-关系"
- 栅格引擎说"波段-像素"
- 消息队列说"主题-分区"
- 规则引擎说"如果-那么"
本体语义没有贯穿全链路，数据在每一层都是孤岛。
OntoGraph 自研的价值，不在于"重复造轮子"，而在于把本体语义从存储层、计算层、行动层贯通到底。卫星数据以动态本体的形式接入，栅格计算通过 OntoFlow 编排，结果回流到本体网络参与推理——这不是简单的"集成"，而是语义层的一致性。
如果底层不是自研的，这个需求很难实现。不是技术不行，是开发成本和维护成本高到不可接受。
五、结语：让业务自己说话
回到开头那个问题："帮我找出所有状态异常的井。"
大模型可以帮你把这句话翻译成查询语句，但它不会告诉你：这个"异常"是单一字段定义的，还是跨表计算出来的？是实时状态，还是物化缓存？是局部异常，还是因果链上的传导结果？
这些判断，必须交给推理机。
推理机在本体层理解"井"是什么、"异常"是什么、"影响"是什么，然后在新增数据时触发派生，在迭代数据时更新状态，在推理数据时给出结论。
大模型？它只是一个旁白，站在第三人称的视角，偶尔帮你把自然语言翻译成 Ontology Action，让推理机去执行。
本体论的概念很少，功能也很少。但组装在业务中的难，从来不是理解理论，而是理解透彻之后的取舍。
不同的人做出来的效果可能不同。所以方案要有取舍，架构要有边界，工具要有闭环。
大模型是旁白，本体才是主角。
产品总结：
推理机 在新增数据 迭代数据 推理数据 时形成闭环即可
大模型本来就是第三人称
可有可无 一个旁白角色
推理机越完善 推理效果越精准
大模型参与的越少 幻觉越低