2026年7月19日

Palantir 风格无人系统：从传感器到任务的 Ontology 闭环

最初我想做一张三维态势图，把无人机、机器狗、无人车和固定相机都放进去。

地图做出来后，问题反而更明显了。它能告诉我设备在哪里，却回答不了几件更重要的事：两台设备看到的是不是同一件事？为什么推荐这架无人机？谁批准了任务？执行结果又该写回哪里？

如果这些问题没有答案，系统仍然只是一个好看的监控大屏。

我后来把重点从“如何展示设备”转到了“如何描述这个世界”。这也是我开始认真理解 Ontology，也就是本体的原因。

Class 这个类比只对了一半

用程序员熟悉的方式看，Ontology 确实很像面向对象：

Palantir 的文档也是这样区分 Object Type 和 Object 的：前者定义现实对象的结构，后者保存某个具体对象的主键和属性值。Palantir Types reference

在我的第一版里，Asset 是类型，D-02 是一架具体无人机。它有 74% 电量，搭载 RGB 和热成像，当前处于空闲状态。机器狗 R-03、无人车 V-04 和固定相机 C-17 也先放在 Asset 下。

这样建模有一个直接好处：任务推荐可以面向能力，而不是面向设备型号。系统要找的是“在线、具备热成像、电量足够、允许进入目标区域的设备”。以后换一款无人机，只要仍能提供这些属性，原来的任务流程就不用重写。

如果几类终端以后出现完全不同的状态机、权限和动作，再拆成不同的 Object Type，并用共同接口描述它们。是否拆分，不取决于外形，而取决于业务行为。

Class 的类比到这里就结束了。Ontology 还需要描述对象之间的关系、允许执行的动作、约束动作的规则，以及每次变化留下的记录。它更接近一套能运行的业务模型，而不是一组数据结构。

无人系统每天会产生大量检测框、轨迹和遥测。如果把它们直接送入任务系统，误报和重复任务很快就会失控。

我把数据分成了三步：

Observation → Incident → Mission

Observation 是一次带来源和时间的观测。例如，固定相机在 10:03 看到烟雾，无人机在 10:04 看到同一位置温度异常。图片和视频属于 Evidence，位置、电量和链路质量属于 Telemetry。

多条观测经过时空归并后，才可能形成 Incident。Incident 是需要处理的事件，有状态、负责人、优先级和证据集合。

Mission 才是要执行的任务。它响应某个 Incident，由某台设备执行，并经历创建、审批、下发、完成或取消。

这层区分看起来简单，却挡住了一个常见错误：模型输出的是事实线索，不是执行命令。

我把这套逻辑做进了一个可操作的无人系统模拟沙箱。其中一条演示链路是园区烟雾处置：

如果操作员继续处置，系统会推荐携带水雾消防胶囊的 D-05。任务仍需人工审批。投放完成后，再由 D-02 用热成像检查温度是否下降。

这里最关键的不是烟雾识别，而是发现、确认、处置、复核都进入了同一条证据链。每一步知道自己依赖哪些对象和规则，也知道结果该更新哪个 Incident。

另一个演示场景是异常重型车辆进入周界。固定相机 C-22 提供 RGB 观测，D-11 提供 LiDAR 轮廓复核。系统可以记录目标的位置、速度和证据，但身份始终标为“未确认”，后续只生成远距观察建议，交给人处理。

两个场景共用同一套对象、关系和任务状态机。这比增加两个独立页面更有意义。

为了检查建模是否真的可读，我在沙箱里做了两种视图。

三维地图负责空间关系：设备、事件、FOV、任务路线和执行状态。本体工作台负责业务关系：谁观测了什么、事件发生在哪里、哪条规则约束了任务、谁正在执行。

点击 D-02 可以看到电量、载荷、传感器、位置和当前任务；点击一条建议，可以沿着 Observation、Incident、Rule 和候选设备逐层回查。

如果一条推荐只能显示一个分数，却找不到来源证据和未入选原因，那就还称不上可解释。

AIP 也不是“把所有判断交给大模型”。设备端的检测模型负责产生观测，融合服务负责生成 Incident，电量、地理围栏和设备能力仍由确定性规则检查。

AIP 在这里主要做三件事：

硬约束不能只写在提示词里。提示词可以解释规则，却不能代替规则。

Palantir 的公开资料把 Foundry 定位为数据运营底座，把 AIP 定位为连接生成式 AI 与实际运营的平台，把 Apollo 定位为持续交付工具链；Gotham 则是建立在相同 Ontology 能力上的领域应用。平台概览、AIP、Foundry 与 Apollo

对应到这个项目，Foundry 的思路落在数据、Ontology、规则和审计上；Gotham 的思路落在态势与任务界面上；AIP 负责解释和生成草案。Apollo 暂时不是重点。

目前的版本使用 Node.js、Three.js 和内存状态，设备、观测与证据都是 Mock 数据。它没有真实接入 MAVLink、ROS 2、消息总线、时空数据库和权限系统，AIP 也只是受控模拟。

所以它不是 Palantir 的复刻，更像是抽出了一条最小骨架：

多源感知 → 统一对象 → 事件融合 → 规则推荐
→ 人工审批 → 任务执行 → 结果回流 → 审计

这条链路跑通后，我对本体的理解也清楚了很多。

Asset 可以看作 Class，D-02 是实例。但只有当它的观测能支持一个 Incident，Incident 能触发受规则约束的 Mission，执行结果又能回到系统时，本体才不只是一份 Schema。

对无人系统来说，本体的作用就是让不同终端共享同一个世界。AI 应该在这个世界已经被描述清楚之后再进来。

本文来自一个非官方 Mock 项目的实现记录。