Palantir市值翻34倍的秘密武器——Ontology，用一张工单给你讲明白
作者：谯洪敏｜DTALK
导读：让 AI 参与业务，既要让它认识业务里的“名词”，也要定义它可以参与哪些“动作”。
上篇我们聊了 Palantir 的 FDE 模式，今天继续拆解它的核心技术底座——Ontology（本体论）。
很多人一听到“本体论”就头大，觉得这是哲学课的东西。别怕，咱们用一张维修工单，就能把它讲明白。
派工这件事，AI 真的懂吗？
假设你负责一个维修团队。系统里有一张工单 W007：某台设备需要维修。你想把它派给张工，但派之前得确认几件事：
- 张工资质够不够？
- 张工那个时间段有没有空？
- 这张工单是否仍待分配？
- 谁有权限确认派工？
如果只把几张数据库表扔给 AI，它可能生成一段看起来很像样的建议。但真正执行时，问题就来了：数据里的“人员”到底指谁？“空闲”按哪个时间段判断？派工会改动什么？谁有权提交？
Palantir 官方文档把 Ontology 描述为连接数据、逻辑、行动和安全的系统。对象和关系让业务名词有了共同含义；规则、动作和权限则决定系统能怎样改变业务状态。
先把业务里的“名词”讲清楚
可以先认识三个概念：对象、属性、关系。
对象（Object）是需要管理的业务实体。在这个教学案例中，“工单 W007”和“工程师张工”是两个对象。设备、班次和维修资质也可以按实际需要单独建模。
属性（Property）描述对象的状态和特征。工单有故障类型、优先级、创建时间和状态；工程师有团队、资质和可用时间。字段含义要跟业务人员核对：你以为“有空”是没有被派工，调度员可能还要看请假、路程和现场任务。
关系（Link）把对象连起来。工单关联设备，也可以指派给工程师。使用者能顺着关系查看“这张工单涉及什么设备”“谁正在处理”，不必先弄懂底层表怎么连接。关系用外键还是连接表存储，是具体实现的选择。
从认识对象，到改变业务状态
看清工单和人员后，还要定义一次合法的派工操作：目标工单是谁、候选工程师是谁、预计时间是什么、谁在提交。
这时会遇到两个容易混淆的概念：Function 与 Action。
在本文的派工方案里，可以先用 Function 根据排班和资质计算候选人，或检查时间冲突。它承载可复用的计算和业务逻辑，也能用于查询、聚合等场景，并不限于 Action 内部。[2]
Action 则定义一次受控的业务变更。例如“将 W007 指派给张工”：检查提交条件和权限，更新指派关系与工单状态，并记录结果。[3] 如果还要写入外部工单系统，必须配置并验证相应集成。
用一句话记住本文的流程：先算出建议，再按规则提交变更。建议和执行是两个不同的结果，不能把模型说“已派工”当作系统真的派工成功。
AI 可以获得多大的行动空间？
AI 可以帮忙理解报修描述、归纳维修要求，或解释为何推荐张工。资质是否有效、排班是否冲突、工单是否关闭，则要用明确的业务逻辑和实时系统状态校验。
审批强度取决于动作风险。跨团队或涉及重要设备的派工，可以先交给调度员确认；低风险且规则明确的辅助操作，可以在授权和验证充分时自动执行。这是方案选择，不是所有 AI 动作都要人工点击的固定规定。[4]
真正上线时，还要检查权限、测试规则、关注数据质量，并确认外部系统返回的结果。如果写入失败，界面应该显示失败或待处理，不能用一句自然语言回复冒充成功。
没有 Palantir 环境，也能先练业务建模
拿一张纸或表格，做三步练习：
- 写下“工单”和“工程师”，为它们各选几个必要属性，再画出指派关系。
- 写下“指派工单”需要哪些输入、谁能操作、何时必须拒绝、成功后应看到什么变化。
- 走一遍三种情况：张工资质合格且有空；张工正在处理别的任务；W007 已被另一位调度员分配。
异常路径常常能暴露原先漏掉的规则。这份纸面模型还不是生产系统，但能成为沟通、开发和测试的共同依据。之后选数据库、API、工作流或模型，每一项技术才有明确用途。
我们希望在筹备中的 FDE 课程里，把这样的业务建模练习与原型、评估、交付连起来。能解释清楚一个动作为什么可以执行、失败后怎样处理，就是扎实的一步。
欢迎留言“FDE＋你想建模的业务动作”，例如派工、调货、退款或线索分配。下一篇继续用这个案例，讨论一个可验证的小项目怎样推进到交付。
我翻译为中文的官网本体架构图
参考资料：[1] Palantir：The Ontology system；[2] Functions overview；[3] Action types overview；[4] AIP Logic overview。
企业级AI课程报名通道
课程咨询请联系王老师微信 13817350334。
添加王老师微信，并回复“企业级AI 课”（企业内训同），咨询课程安排与团队参训。
带着一个业务问题来，把 AI 应用的第一步走清楚。
