Ontology 四问与懒生长

观点：Palantir 的 Ontology 真正值得学的不是 Object/Property/Link 的建模术，而是它回答的四个问题：AI 需要理解什么、依据什么判断、能执行什么、什么情况下允许执行。

作者花一周读遍 Palantir 官网资料，用一个库存案例把四层讲穿：三个系统都显示”库存 100”，但实物库存、可售库存、在途库存是三种东西——数据打通不等于理解业务（Data）；明天可承诺量=实物-预留-质检+在途能到，这是判断规则（Logic）——但这条规则里能算死的加减必须交给代码跑，让大模型心算精确账是常见翻车，Logic 层的活法是确定的计算走代码、判断空间才留给 Skill 按上下文推理；AI 说”可以”不算数，真把 60 件库存锁住才算（Action）；60 件自动锁、6000 件要审批、10 万元退款压根不该放权——权限不是最后补的配置，本身就是业务逻辑，而且边界要落在工具权限、API 权限、审批流和审计日志上，写进 prompt 里”提醒模型谨慎”等于没设（Security）。顺带一张 Palantir 架构速览（2026-09 快照，引用前回源）：Ontology 被官方称作整套体系的 heart，等于”语言加引擎加工具链”——定义业务世界、让它可查询可计算可修改、再给人和 Agent 当入口；外围 Foundry 偏数据运营、AIP 是大模型与 Agent 平台、Apollo 管部署交付。

洞察：Ontology 在大模型时代重新走红，是因为”人”这个缓冲层被抽掉了。 以前系统割裂没事，因为最后做判断的是懂业务的老员工；现在 Agent 要直接查系统、做判断、执行业务，藏在老员工脑子里的业务理解就必须变成 Agent 能获取的上下文。大模型给了 Agent 推理能力，但企业得告诉它正在推理的是一个怎样的世界。

启示：范式反转——别先建本体再上应用，先跑起来再让它长。 只有一个 Agent 一个场景时，用 Skill/Tool/MCP 直接跑，禁止为”以后要建本体”提前抽象；等重复信号冒出来再动手，而且三种重复各有各的抽法——多个 Agent 对同一个 order、customer 定义不一，就抽成公共数据层；多个 Skill 重复写同一条确定规则，就抽成公共代码或工具；多个 Agent 各自封装同一个退款、锁库存动作，才抽成公共业务动作。本体是长出来的，不是建出来的。这条对我们库同样成立：标签体系、卡片分类都别预先设计完美，让重复出现的模式自己浮出来。

提醒： 作者读的是官网二手资料，无客户部署案例，Palantir 实战细节未验证；“四问”框架是好的思考工具，但别当成实施路线图——大多数企业（包括个人）远没到需要正式 Ontology 的阶段。懒生长是次序策略不是终态哲学：高合规、从零起步的关键交易系统里，Security 和 Data 恰恰必须前置建模；“判断空间放 Skill 推理”隐含模型可靠的前提，把必须确定的计算错放进推理链就丢了审计性；个人小工具链没有共享业务状态，套四问会过度工程——Action 和 Security 两问在那儿是空转。

---

📺 AI产品千媚《Ontology 企业 AI 转型的解药？》，抖音，2026-09-20 · 原视频 · 库内 2026-09-20-Ontology企业AI转型的解药 · 速览 速览/2026-09-20-Ontology企业AI转型