一间作战室讲透 Palantir 本体论
从 1940 年的不列颠之战，到今天的 Foundry 与 AIP
用一间作战室讲清本体与行动。
Ontology 是把组织要做的决策，用“名词（对象、属性、链接）+ 动词（动作、函数）+ 规矩（权限）”建成一个大家共用、能写回现实的数字孪生。
离场时，能用一句话说清 Palantir 的本体是什么。
情报、状态与指挥需要同在一张工作台上。
在聊天框打 A 或 B，倒计时结束一起回车
A，有，性能不差。后面再看为什么“有雷达”仍不等于“能及时拦截”。
先确认有预警手段，再看如何把信息变成行动。
拦截率：出动后成功找到并接触敌机的比例；不是击落率，也不是指令正确率。
英国赢的不是雷达，而是把雷达变成决策的系统。今天讲的本体，就是把这间屋子软件化。
先把报告看明白
报告从哪里来，怎样归组，再交给谁。
先有来源和判断依据，再有共同对象。
| 较早：编号 / 时间 / 站 / 格网 / 架数 / 英尺 / 方向 | 后续：编号 / 时间 / 站 / 格网 / 架数 / 英尺 / 方向 |
|---|---|
| R01 / 10:02 / 多佛尔 / K8 / 20+ / 13000 | R06 / 10:08 / 多佛尔 / K8 / 30+ / 15000 / 西北 |
| R02 / 10:03 / 莱伊 / K8 / 30+ / 15000 | R07 / 10:09 / 佩文西 / J8 / 12 / 21000 |
| R03 / 10:04 / 多佛尔 / K8 / 20+ / 13000 | R08 / 10:10 / 莱伊 / K7 / 约40 / 14000 |
| R04 / 10:05 / 莱伊 / K9 / 10+ / 20000+ | R09 / 10:14 / 多佛尔 / J7 / 30+ / 15000 |
| R05 / 10:06 / 佩文西 / H8 / 约10 / 8000 | R10 / 10:14 / 莱伊 / J8 / 12+ / 20000 / 西北 |
独立来源补身份
| 来源 | 记录了什么 |
|---|---|
| 观察 O1 / 10:14 | 大机群：K8 → K7 → J7，向西北；看清敌方标志。 |
| 观察 O2 / 10:14 | 小机群：K9 → J8，向西北；看清敌方标志。 |
| 己方通报 / F1，10:07 | 253 中队自报约10架、8000英尺，经过 H8 返航。 |
| 测向站 / D1，10:07 | 对己方无线电信号交叉定位，约 H7；与 H8 相邻，只支持大致位置。 |
雷达、测向补位置；观察、己方通报补身份。声音不能单独判敌。
地图补位置
一个点是一份报告。
同格报告错开摆放，便于看清。
所有点同色；不表示时间、批次或敌我。
每个来源掌握一部分事实；报告数不等于飞机批数。
在聊天框只打一个数字，暂不揭晓。
依据：十份雷达报告，以及 O1、O2、F1、D1。
先记下判断，随后对照归组依据。
一个点不是一架飞机；虚线仅表示归为同一候选目标，不是飞行路线。
时间、高度只是线索；还须核对位置、方向、规模与独立来源。
先回想 s08 提交的数字，再揭晓归组结果。
H21：R01/02/03/06/08/09；O1识别敌方。
H22：R04/07/10；O2识别敌方。
F05：R05；F1确认己方返航，D1佐证位置。
H21/H22/F05 是核对后共同编号；颜色呈现结果，不生成身份事实。
发现 → 核对汇总 → 分配区域资源 → 起飞与引导 → 回报
Freya，1939
德国已经具备雷达探测能力；把探测接入战斗机指挥与引导，仍是另一项系统工作。
珍珠港，1941
美军雷达发现来机，却被当作预期己方飞机。接到报告后怎样解释与升级，同样影响结果。
接下来分清三种角色：滤报节点、Group区域指挥、Sector扇区执行；雷达站、观察站与测向站是信息来源。
信息要经过正确的岗位与判断，才能变成行动。
滤报室 Filter Room
| 必要背景 | 设在战斗机司令部 Bentley Priory（本特利修道院），是信息处理团队与工作节点。 |
|---|---|
| 主要任务 | 接收雷达报告，交叉核对、排除重复、形成可共享的目标记录。 |
| 掌握的信息 | 各站报告、时间与估计位置，及相互核对后的来袭态势。 |
| 交给谁 / 边界 | 向相关作战室传递核对结果；滤报职责不等于对飞行员下令。 |
滤报负责把报告说清楚，保留来源与不确定性。
Group 大队级区域指挥
| 必要背景 | 防空体系按地域分工；第11大队作战室位于 Uxbridge（阿克斯布里奇）。11是编号。 |
|---|---|
| 主要任务 | 比较区域威胁和可用中队，协调所属扇区的应对与资源分配。 |
| 掌握的信息 | 经核对的区域目标态势，以及所属扇区与中队准备情况。 |
| 交给谁 / 边界 | 把应对决定交给相关Sector执行，向上级报告区域情况；不同于逐架无线电引导。 |
Group 解决区域内优先应对哪里、调哪些资源。
Sector 扇区管制
| 必要背景 | Group之下划分扇区；扇区站联系所属机场与中队。Sector是防区，不是飞行队伍。 |
|---|---|
| 主要任务 | 在区域指挥安排下，组织所属中队起飞，以无线电引导接敌，并接收执行回报。 |
| 掌握的信息 | 与辖区有关的目标更新、所属中队准备与飞行状态、无线电和飞行员回报。 |
| 交给谁 / 边界 | 向所属飞行员传递指令，向Group反馈情况；不能擅自调走其他扇区资源。 |
Sector 把区域决定转成具体起飞与引导，并反馈现场变化。
在聊天框打 A、B 或 C。
按职责传递，执行后回报。
传递的终点是明确责任和行动，再把执行结果传回来。
| 岗位 | 负责范围 | 能做 | 不能自行做 | 向谁报告 |
|---|---|---|---|---|
| 来源岗位 | 本站观测 | 报告、补正观测 | 据单站信息指派中队 | 对应接报岗位 |
| 滤报团队 | 报告核对 | 去重、归组、传递记录 | 代替管制官向飞行员下令 | 相关作战室 |
| Group管制 | 本防区 | 确定应对、协调扇区资源 | 把看见目标等同于已完成拦截 | 上级司令部 |
| Sector管制 | 本扇区 | 组织起飞、无线电引导 | 擅自调其他扇区资源 | Group |
| 中队 / 飞行员 | 获派任务 | 执行并回报现实状态 | 替上级分配全区资源 | Sector |
历史职责的课堂概括。软件沙盘另作简化：大队角色提交“指派拦截”，扇区角色负责引导；不是历史岗位权限的逐项复原。
看见什么、负责什么、允许做什么，需要分别定义。
共同对象
共同编号，成为可持续更新的业务记录。
对象、属性、链接，是共同表达业务的基础。
| 概念 | 本例 | 表达什么 |
|---|---|---|
| 对象 | 目标 H21；中队92 | 可持续指认的具体业务事物 |
| 属性 | H21：约30+架，15000英尺；92：5分钟待命 | 该对象当前掌握的特征与状态 |
| 链接 | H21 — 来源报告 — R09 | 两个对象间有依据的关系 |
H21 是稳定编号；R09 是其中一份来源报告。报告更新后，仍可以谈同一个 H21。
此时92尚未接到拦截任务，因此还没有“92 — 拦截 — H21”的已成立关系；提交有效动作后再建立。
用对象指认事物，用属性描述状态，用链接表达已知关系。
| 报告内容 | 上报时间 | 当前查看时间 | 信息年龄 |
|---|---|---|---|
| D1：253中队约在 H7 | 10:07 | 10:14 | 7分钟 |
应说“7分钟前报告约在H7”；要判断当前位置，还要找更新报告，或明确说明估计依据与不确定性。
读属性时，也要读它的时间；旧位置不能直接冒充当前位置。
接到命令后，预计还需5分钟准备好起飞；不是飞行时长，也不是已升空。
在聊天框打 A、B 或 C。
92中队是对象；5分钟待命是当前状态。接令后先记“已受命出击”，实际离地回报后才记“已升空”。
资源有没有准备好，要看当前状态及其更新时间。
| 工作视图 | 共同对象的范围 | 工作重点 |
|---|---|---|
| 全局态势 | 跨区域目标与资源 | 区域压力与支援 |
| 区域调度 | 本区H21与所属资源 | 优先级与可用资源 |
| 扇区执行 | 本辖区目标与中队 | 当前指令与执行回报 |
同一个H21、同一来源与更新时间；按工作选择范围和字段。
可见范围管“能读什么”；动作权限管“能做什么”。看见不等于能指派。
共享对象，按工作组织视图；读取权限与执行权限分别控制。
动词
光看得见还不够，要能改变现实。
只有名词的系统叫看板；
有了动词，它才是操作系统。
92 中队 名词 ＋ 拦截 动词 ＋ 敌机 21 批 名词 ＝ 一个完整的决策
Palantir 的说法：数据是名词，动作是动词，合起来才是一句完整的话。
做什么、对谁做
动作：指派拦截。参数：中队 92、目标 H21。
当前能不能做
中队为 2 或 5 分钟待命；目标为敌方；信息不超过 10 分钟；中队没有未结束的拦截任务。
谁能下令
教学角色：大队管制官提交指派，扇区角色负责引导。
通过后留下什么
记为“已受命出击”，保存“92 — 拦截 — H21”及操作日志。
动作把对象、条件、授权与结果放在一起。
在聊天框输入 A、B 或 C，先不发送；5秒后一起发送。
没有合格中队，提交条件不满足。
B：绕过了规则。
C：把尚未授权的自动派遣当成既定流程。
先满足提交条件，再执行动作。
无权限
当前角色不能下这类命令。
把情况交给有权限的管制官处理，保留原有权限边界。
提交条件不满足
例如没有合格待命中队。
报告资源不足，请其协调准备或支援；真实状态更新后再检查。
先辨原因，再找有权限的人协调资源。
输入
中队与目标的位置、方向、状态
函数 Function
按规则或模型计算
输出
预计会合点、建议航向
函数负责计算，动作负责执行决定。
提交命令
有权限的人提交“92 中队拦截 H21”，规则检查通过。
更新中队状态
5 分钟待命 → 已受命出击；实际离地后再更新为“已升空”。
保存链接与日志
建立“92 — 拦截 — H21”；留下谁、何时、基于哪版记录下令。
下一次读取
同事看到“已受命”，不会再把 92 当成空闲中队重复派遣。
决定写回共享记录，下一轮决策从新状态开始。
语义要素（名词）
对象、属性、链接
动能要素（动词）
动作、函数、动态安全
本体代表的是企业的决策，而不只是数据。
工具
把这间屋子软件化，需要哪些部件？
4 决策与 AI
管制官下令；计算拦截建议；
运筹学小组复盘
AIP：Logic、Chatbot Studio、Evals；
结合函数与动作参与决策
3 应用
三级标图桌、状态板、天气板；
同一批对象的不同工作页面
Workshop、Object Explorer；
Quiver、Map、Vertex、OSDK 自建应用
2 本体
航迹木牌、中队状态、拦截关系；
共同编号与下令规矩
对象、属性、链接；动作、函数、权限；
在 Ontology Manager 中定义与管理
1 数据
雷达、观察哨、无线电测向；
汇总并核对来自不同来源的报告
Foundry 覆盖数据、本体与应用；
Data Connection 接入，Pipeline Builder 整理
交付与运行四层的共同支撑
电话局铺设并维护地下专线
Apollo：把整套软件持续交付到
云、本地、断网和边缘环境
↓ 写回：决策调用动作，改变共享对象状态，再供应用读取。
四层共同支持决策，动作把决定写回共享记录。
本体定义业务
92 中队、H21、待命状态、指派动作与执行规则。
Workshop 搭页面
用表格、地图和按钮，连接这些对象和动作。
员工在页面操作
选中队与目标；提交后由本体动作检查并保存。
Workshop 是 Foundry 中搭建业务应用的工具。
学员在聊天框打 A、B 或 C；讲者按 C 留出 5 秒作答。
B，本体动作：检查权限与中队状态，保存指派并更新共享记录。
页面发起请求，本体动作承接业务规则。
| 产品或工具 | 作战室里相当于 | 一句话 |
|---|---|---|
| Data Connection、Foundry | 电话线与共同工作台 | Data Connection 接入系统；Foundry 覆盖数据、本体和应用 |
| Pipeline Builder、Code Repositories | 滤报室的合并规则 | 清洗、合并、实体解析 |
| Ontology Manager | 规定木牌写什么、谁能下什么令 | 本体：定义对象、链接、动作、函数和权限 |
| Workshop、Object Explorer、Quiver、Map、Vertex | 标图桌、状态板 | 应用：在本体之上搭界面、做分析 |
| OSDK | 允许外单位按同一套编号接入 | 应用开发：用代码开发自己的应用 |
| AIP | 坐在同一张桌边的 AI 参谋 | 大模型读同一批对象，受同样的权限约束 |
| AI FDE | 会自己拉线、做木牌的助手 | 用对话方式建管道、改本体，变更等人审核 |
| Apollo | 电话局工程队 | 交付与运行底座：把软件部署到云、本地、断网和边缘环境 |
| Gotham | 面向另一类任务的平台 | 政府、情报和国防平台，不单独对应一层 |
重点理解本体怎样支撑 AIP，其他工具按职责定位。
读同一批对象，用同样的函数
受同一套权限约束
本教学场景：建议先存为情景，由人确认；低风险动作可按授权开放
本体是 AI 的上下文，也是 AI 的护栏。
AI 参谋提出建议后，谁来按确认？在聊天框打“人”或“AI”
本教学场景由大队管制官（人）确认。AI 起草建议；确认时重查权限与当前条件，再执行动作。低风险动作可按授权开放。
AI 可起草建议，授权的人负责确认。
人
本体不是买来的，是和一线一起长出来的。
Goodchild / IWM CH 15337，公有领域
Biggin Hill 拦截实验：科学家与飞行员同场迭代约七个月，摸索出等角拦截法
防空演习后，Bawdsey 研究站负责人 A. P. Rowe 判断：雷达技术上可行，运营效果远未达标。专门研究“如何用好它”的小组成立，“运筹学”一词由此诞生
扇区管制官多由退役或伤愈的飞行员担任，因为飞行员不听“坐办公室的”
答疑图解：等角拦截法技术可行不等于运营可用，这就是 Palantir 要把工程师派到一线的原因。
1936 年起在 Biggin Hill 的拦截实验中摸索出的快速估算法：让战斗机与敌机的航线构成等腰三角形，两条航线在顶点会合。
经验和算法绑定对象，由有权限的人调用。
Echo 定义决策，Delta 搭起本体，Dev 把它做成平台。
“Delta”源自 Palantir 早年业务拓展团队按北约字母表命名的传统；“Echo”也是北约字母，一般认为出处相同。官方强调，Delta 做的工程工作远多于顾问。
Dev 复用平台能力，Delta 面向客户组合能力。
在聊天框打 Echo、Delta 或 Dev
Delta。一个客户，多种能力，负责接数据、建本体、搭应用。Echo 负责弄清该做哪些决策并推动一线用起来；Dev 负责把这套能力做成所有客户都能用的平台。
Echo 定义决策，Delta 落地，Dev 建平台。
AI FDE 可协助什么
FDE（现场部署工程师）负责把软件接入客户现场工作。AI 可协助建管道、改本体、写函数；变更默认走分支，等人审核。
讨论题与参考答案
在聊天框打一个词：AI 参与后，人的价值应转向什么？
人的重点：定义要支持的决策、建立一线信任、对结果负责。
人的价值转向定义决策、建立信任、承担结果。
FDE 已成为行业模式，例如富士通于 2026 年 9 月宣布成为 Palantir 的 Global FDE Partner。
与 Palantir 本体对照：92 中队现在能否受命拦截 H21？决定后怎样回写？
擅长：让结构、字段和约束一致
关系模型用表、行和键组织记录；编号唯一，状态、报告时间和查看时间各有清楚定义。
还需补：把定义接到实际操作
对齐各系统里的 92 与 H21；接入最新状态，配置授权、指派动作和执行结果回流。
关系模型以表、行和键组织关联资料；字段与约束先立稳，再接入共同决策。
与 Palantir 本体对照：92 中队现在能否受命拦截 H21？决定后怎样回写？
擅长：关联查询、逻辑表达与推理
关系模型可查表间关联；图谱连接业务事实。W3C 是标准组织，OWL 是本体语言。
还需补：把候选变成受控的指派
核对当前待命与信息时效；执行时检查授权，保存指派关系、状态和日志。
W3C 是标准组织，OWL 是语言；关系与推理能找候选，提交仍要校验。
与 Palantir 本体对照：92 中队现在能否受命拦截 H21？决定后怎样回写？
擅长：统一实体、关系和分析口径
各张报表按同一套待命、辖区和时间条件，计算“可用中队数”，也能下钻查看 92。
还需补：让这一次指派真正生效
提交时重查 92 的当前状态；由有权的人执行动作，更新任务并接收结果。
统一分析口径帮助看清局面，执行还要校验这一刻的条件。
与 Palantir 本体对照：92 中队现在能否受命拦截 H21？决定后怎样回写？
擅长：检索材料，生成有依据的解释
找出 H21 的报告、92 的值班资料和指派规则，帮助讲清“为什么建议派它”。
还需补：把建议接到可控的业务工具
核对材料对应的对象与时间；经授权调用指派动作、复核条件，再接收执行结果。
把依据找出来很有价值；要采取行动，就把工具和权限接好。
| 技术路径 | 擅长什么；本例还要核对什么 |
|---|---|
| 关系模型、数据字典 | 用表、键和约束组织资料，也能表达关联；再对齐跨源身份、最新状态、授权与写回。 |
| 知识图谱、RDF / OWL | 连接事实、查询关系并表达逻辑；候选指派前仍核对来源、当前状态和授权。 |
| BI 语义层 | 共享业务实体、关系和指标口径；仍要核对刷新时间，并在提交时重查条件。 |
| 聊天、RAG | 检索材料、解释依据并辅助建议；行动前将资料对准对象和时间，再调用受控工具。 |
| 工作流编排、WDL | 编排步骤、依赖、触发与自动化；WDL 含义依生态，仍核对实时状态、授权和失败处理。 |
| 数字孪生 | 整合现实实体、流程与数据，可用于模拟；动作和现实干预取决于具体系统。 |
| 操作型本体 | 连接对象、关系、规则、安全与动作；仍需对齐数据、外部写回并核验回执。 |
技术可组合；共同检验标准是同一对象、当前状态、受控动作和结果回流。
谁要决定什么？
运营负责人怎样分配原料、保哪些订单？
要看见什么？
供应商、原料、库存、产线与受影响订单。
依据从哪来？
供应商、仓储、生产和履约系统怎样对齐？
谁能改变什么？
比较替代方案；授权人员审核后执行重分配。
结果怎样回来？
接收各系统回执，保留决策依据供下一次使用。
先明确要作的决定，再补齐对象、依据、动作和反馈。
Onyx 是官方文档中的虚构医疗器械制造商；五问为课程依据案例整理的分析工具，并非官方命名框架。
Ontology 是把组织要做的决策，用“名词（对象、属性、链接）+ 动词（动作、函数）+ 规矩（权限）”建成一个大家共用、能写回现实的数字孪生。
| 案例 | 选择更合适的修正 | 揭晓后核对 |
|---|---|---|
| ① 每份报告 都新建一个 H21 |
A 只按名称合并 B 保留报告，核对后关联共同目标 C 删旧报告，只留最新 |
答案 B 报告有来源与时间；共同目标有持续身份。 |
| ② 表里能关联 92/H21 就让所有人直接指派 |
A 检查授权、当前条件后执行动作 B 能看见，就能指派 C 先改状态，之后再补审批 |
答案 A 能关联、能查看，都不等于有权改变。 |
| ③ 下令后直接标“已升空” 也不等执行回报 |
A 命令日志可代替回报 B 只改页面，不改记录 C 分开受命与升空，回报后更新 |
答案 C 决定与现实要区分；结果进入下一轮决策。 |
课堂题：逐题在聊天框打一个字母，讲者分别揭晓。
共同身份、受控动作、结果回流，让模型真正支持组织决策。
企业的本体由中台统一建，还是业务部门各建？在聊天框选：集中、下放、混合
参考：共用关键对象与规则；业务团队在分支提改动，经评审后合并。
治理既要保持共同语言，也要容纳一线改进。
AI 读取航迹与中队，起草建议
暂存为“情景”：待确认方案，不等于已执行
人确认时重新检查权限与当前条件；失败就停止执行
AI 的读取、建议和执行范围，都要明确授权。
| 五问 | Onyx：官方文档中的虚构医疗器械制造商 |
|---|---|
| 1 决策 | 断供后重分配原料；比较对各产品线与客户订单的影响。 |
| 2 看见 | 连接供应商、原料、库存、产线、工厂与订单；敏感信息仍受权限限制。 |
| 3 数据 | 接入供应商、仓储、生产、配送与客户履约系统，对齐业务对象。 |
| 4 改变 | 替代方案先存情景、人审后执行；按接收系统分别配置写回方式。 |
| 5 回来 | 监测各系统响应，记录谁依据什么作了决定，为复盘与后续改进提供材料。 |
选出方案只是一步；把结果接回来，下一轮才有可靠依据。
五问为课程整理；官方案例中的接口、连接器与异步文件写回，并不意味着跨系统同时成功。
先决策，后名词；
有名词，配动词；
动词要有规矩；
结果要能回来。
谢谢｜答疑
Andy 任旭
航迹＝对同一架飞机或同一批机群的持续跟踪记录。一个点是一次位置报告；多个时刻的位置连起来，才形成路线。H21 指这批机群，不是一架飞机。
| 中文 | 英文 | 作战室里的例子 |
|---|---|---|
| 对象类型 | Object type | 航迹、中队、机场、扇区 |
| 对象（实例） | Object | 航迹 H21 |
| 属性 | Property | 架数、高度、中队状态 |
| 链接类型 | Link type | 中队—拦截—航迹 |
| 对象集 | Object set | 11 大队辖区内所有敌方航迹 |
| 动作类型 | Action type | 指派拦截 |
| 提交条件 | Submission criteria | 被派中队须为 2 分钟或 5 分钟待命 |
| 中文 | 英文 | 作战室里的例子 |
|---|---|---|
| 函数 | Function | 等角拦截法算出的引导航向 |
| 接口 | Interface | “可指派的作战单元”：战斗机中队、高炮连都具备 |
| 写回 | Writeback | 下令后状态板自动翻牌 |
| 情景 | Scenario | AI 参谋暂存、待人确认的建议 |
| 标记 | Marking | 只有特定级别能看到的信息 |
| 决策血缘 | Decision lineage | 谁、何时、依据哪一版标图下的令 |
| 语义要素与动能要素 | Semantic / Kinetic elements | 木牌与状态板 / 命令与算法 |
链接只显示和点击跳转，不预取
