知识图谱

动态本体的第二次迭代：从“能研判”到“会成长”

2026 年 8 月 14 日

从“能研判”到“会成长”，动态本体迭代聚焦轨迹预测进化、函数自生长与经验沉淀，实现智能体系统能力跃升。核心内容： 1. 空中目标轨迹预测模型重构（粒子Monte Carlo+多因素融合） 2. 动态本体函数拆分为可进化的OpenClaw Skills 3. 智能体系统经验沉淀与可视化优化（轨迹、函数、系统三维成长）

昨天那版东海防空识别区空情研判 MVP，解决的是第一个问题：让OpenClaw 不再直接面对一堆表、报文和地图图层，而是先进入一个动态本体空间。态势数据、航侦报文、技侦报文、开源地理和历史案例，先被映射成 AirTarget、TrackPoint、IntelReport、AirspaceZone、SimilarTrackCase这些对象；对象之间再通过 Link 连接；OpenClaw 通过 MCP 调用本体函数，完成威胁评估、证据链解释和 Cesium 可视化输出。

今天这次迭代，重点不再是“有没有本体”，而是继续往前走一步：本体里的计算能力怎么变得更准？函数怎么随着使用不断进化？智能体系统怎么沉淀经验，而不是每次从零开始？

我们做了四件事。

第一，重写了空中目标轨迹预测和进入 ADIZ 概率模型。原来更接近启发式规则，现在改成 ENU 坐标下的粒子 Monte Carlo 预测，再把运动学命中概率、情报置信度、历史相似航迹、目标语义和保障 Link 先验做融合。

第二，把动态本体中的“函数”拆成了 OpenClaw 可以渐进式加载的 Skills。本体仍然定义函数签名、输入对象、输出对象和治理策略，但具体实现放进 Skill 目录：SKILL.md、scripts/、references/。这样函数不再只是固定脚本，而是可以随着项目使用继续沉淀。

第三，明确了智能体成长的三条线：OpenClaw 记忆系统成长，Skills经验成长，动态本体模型自身成长。三者不是一回事，也不能混在一起。

第四，重新组织了“本体情况”工具栏的可视化。现在它更接近 Palantir 动态本体的分层表达：数据层、语义层、动能层、动态层、应用层。看图时，业务专家能更快理解系统里每个要素处在什么位置。

PART 01

轨迹预测：先把经纬度问题变成局部坐标问题

空中目标进入防空识别区的概率，不能直接用经纬度差值粗算。经纬度是球面坐标，纬度和经度的距离尺度并不一样，尤其在东海这种区域范围内，直接用 Δlon和 Δlat做速度、转向和外推，会把几何误差带进概率模型。

所以我们先把目标轨迹点从经纬度转换到局部 ENU 坐标。这里的ENU 是 East-North-Up，本项目当前只用水平面的East 和 North 两个分量。

对最近 6 到 12 个航迹点，按 5 秒采样间隔估计运动状态：

PART 02

Monte Carlo：用粒子统计“是否命中 ADIZ 多边形”

东海 ADIZ 在本体里是 AirspaceZone对象，其边界来自六个坐标点构成的多边形。我们把 ADIZ 多边形也转换到 ENU 坐标：

这一步很重要。比如 TGT-017 已经在东海 ADIZ 里，那么它“未来进入 ADIZ 的概率”不能再是 60%、80% 或 95%，而应该是 100%。这是业务事实优先于预测模型。

如果目标尚未进入 ADIZ，则做 20 分钟预测。每条粒子轨迹按 5 秒一步前推，当前实现采样 4000 条粒子。每条粒子会在 CV、CT、Singer 三类模型之间采样：

统一的位置推进公式是：

PART 03

平台参数：不同飞机不能按同一种机动假设外推

RC-135、F-16、F-22、E-3、KC-135 不应该共用一套运动噪声。大型 ISR 平台和战斗机的速度、转弯率、机动扰动差别很大。我们在 Skill 的references/platform_params.md里放了一张平台参数表，当前作为 MVP 假设。

平台	速度扰动	航向扰动	最大转弯率参考
RC-135V/W	35 km/h	4°	1.2°/s
F-16CM	70 km/h	9°	4.5°/s
F-22A	80 km/h	10°	5.0°/s
E-3G	30 km/h	3°	1.0°/s
KC-135R	25 km/h	3°	0.8°/s
P-8A	40 km/h	5°	1.8°/s
MQ-4C	20 km/h	2°	0.7°/s
C-130J	25 km/h	3°	1.0°/s

这张表不是权威性能表，而是工程上的先验参数。它的意义在于：模型知道一个 F-16 可能做出更激烈的航向变化，而 RC-135、E-3、KC-135 这类平台更可能保持稳定航路。后续如果实测数据积累更多，这张表可以被持续校正。

PART 04

证据融合：概率不是单纯运动学

仅靠运动学会漏掉很多业务语义。

一个目标向 ADIZ 靠近，可能是训练、巡逻、误入，也可能是有组织的抵近试探。如果它有航侦报文支撑、有技侦监听支撑、有历史相似案例，并且与加油机、预警机、护航机存在保障关系，那么它进入 ADIZ 或在边界附近持续行动的先验就不一样。

Shistory是历史相似案例中的最高相似度。比如当前航迹与历史boundaryparallelisr或 fighterpatrolnearboundary模式接近，就会给模型提供历史先验。

Sevent是当前运动事件得分，比如 boundaryapproach、boundaryparallelpattern、nonapproachorlowattention。

Prior_threat来自当前威胁等级：

威胁等级
high	+0.18
medium	+0.10
low	-0.08

Prior_country来自国别语义：

国别语义
red	+0.08
unknown	+0.10
neutral	-0.12
blue	-0.18

Priorsupportlink来自本体Link，而不是简单加分：

支援 Link 类型
support_enabler	+0.16
escort_or_counterair	+0.12
isr_collection_chain	+0.10
none	0.00

这里特别强调一点：保障关系不是“看到 KC-135 就直接加 10%”。它是本体 Link 形成的任务持续性先验，在 logit 空间参与融合。这比简单 bonus 更稳定，也更容易解释。

PART 05

为什么把本体函数改成 Skills

昨天的模型里，本体函数还是本体 runtime 里的固定函数。今天我们改了一个关键设计：本体中仍然声明函数，但具体函数实现绑定到 OpenClaw Skill。

也就是说，本体里现在是这样一种关系：

Ontology Function Declaration

assess_threat@0.1.0

predictadizentry_probability@0.2.0

Skill Binding

assess-threat

adiz-entry-probability

functions.json里增加了 skillBinding：

{"name": "predict_adiz_entry_probability","version": "0.2.0","input": ["AirTarget", "TrackPoint", "IntelReport", "SimilarTrackCase", "SupportRelationship", "AirspaceZone"],"output": ["AdizEntryProbability"],"riskLevel": "medium","skillBinding": {"skill": "adiz-entry-probability","version": "0.2.0","entrypoint": "skills/adiz-entry-probability/scripts/predict.py","progressiveDisclosure": true,"allowedEffect": "decision_support_only"}

本体还是负责定义：

这个函数叫什么
输入哪些对象
输出什么对象
风险等级是什么
允许产生什么效果
绑定哪个Skill

Skill 负责实现：

什么时候应该使用
如何准备输入
如何运行脚本
参考哪些参数表
踩过哪些坑
如何解释输出

这让本体和函数实现解耦了。

PART 06

Skill 的渐进式披露

新增的两个 Skill 位于：

work/ontology-runtime-mvp/skills/adiz-entry-probability
work/ontology-runtime-mvp/skills/assess-threat

每个 Skill 目录都遵循同样结构：

SKILL.md
scripts/
references/
assets/ optional

SKILL.md的YAML 前置元数据是第一级披露。它短小，只告诉 OpenClaw 什么时候该用这个 Skill：

---name: adiz-entry-probabilitydescription: Use when OpenClaw needs to estimate the probability that one or more air targets will enter the East China Sea ADIZ...version: 0.2.0ontology_function: predict_adiz_entry_probabilityallowed_effect: decision_support_only---

SKILL.md正文是第二级披露。只有当 OpenClaw 判断当前任务确实需要这个 Skill 时，才加载完整指令，比如输入输出契约、运行方法、约束和解释口径。

references/是第三级披露。它不会默认塞进上下文，只有需要调整平台参数、解释概率融合、复盘错误案例时才读取。

比如 adiz-entry-probability当前有：

references/platform_params.md
references/probability_fusion.md
scripts/predict.py

这正好适合这个项目。概率模型不是一锤子买卖。后续我们发现某类平台参数不合理、某种任务链先验偏高、某类报文权重过强，都可以沉淀到 Skill 的 references 或 scripts 里，而不是每次改 prompt。

PART 07

MCP Runtime 如何调用 Skill

OpenClaw 仍然不直接执行任意脚本。调用路径是：

OpenClaw

→ MCP run_function

→ ontology runtime 检查 functions.json

→ 找到 skillBinding

→ 准备本体对象 bundle

→ 调用 Skill script

→ 接收结构化 JSON

→ 回写本体决策对象

这样有两个好处。

第一，Skill 不能绕过本体数据契约。它拿到的是 runtime 准备好的bundle，不是自己随意查数据库。

第二，Skill 不能绕过动作权限。predictadizentryprobability的 allowedEffect是 decisionsupportonly。它可以输出AdizEntryProbability，可以触发updateprobability_overlay这种可视化动作，但不能直接执行高风险操作。

当前 runfunction("predictadizentryprobability")返回结果里会包含 Skill provenance：

{"skill": {"name": "adiz-entry-probability","version": "0.2.0","loaded_levels": ["metadata", "SKILL.md", "scripts/predict.py"],"progressive_disclosure": true}

这让研判结果不只知道“哪个本体函数算的”，还知道“哪个 Skill 版本算的”。这对后续审计、回放和模型迭代很关键。

PART 08

智能体成长：不是一个地方成长，而是三条线同时成长

如果把“成长”只理解为大模型记忆，那系统会很快变得混乱。这个项目里，我们把成长拆成三条线。

第一条线是 OpenClaw 记忆系统成长

OpenClaw 的记忆适合记录使用偏好、任务上下文、常见工作流、专家反馈和历史交互。例如业务专家经常追问“为什么 TGT-017 是 100%”，系统就应该记住：进入概率问题必须先做 ADIZ 内外判定，并优先解释 alreadyinsideadiz。

记忆系统解决的是智能体层面的连续性：下一次再做同类任务，不必完全从零开始。

第二条线是 Skills 成长

Skill 适合记录“怎么做得更好”和“哪些坑不要再踩”。比如：

好的经验：

已进入 ADIZ 的目标直接 P=1.0
平台参数要区分 ISR、战斗机、加油机、预警机
保障关系用 logit prior，不用简单百分比加成

踩过的坑：

不能直接用经纬度差值算运动状态
不能提前显示未来预测航迹
单源情报不能过度抬高置信度
数据源不要直接连对象，要说明字段映射和对象属性

这些内容放在 Skill 的 references/最合适。它们不是本体结构，也不是一次会话记忆，而是某个函数能力的工程经验。

第三条线是动态本体成长

动态本体成长不是改 prompt，也不是改算法，而是业务模型本身变丰富。比如今天我们加入了 SupportRelationship，把保障、护航、支援关系作为 Link 先验。未来还可以继续增加：

MissionPackage 任务编组对象
AirBaseActivity 机场活动对象
SensorEmission 电子辐射对象
CommandIntentHypothesis指挥意图假设对象
AirRouteCorridor 航路走廊对象
ReviewTask 人工复核任务对象

本体成长解决的是业务世界表达能力的问题。它决定系统能理解什么对象、什么关系、什么动作边界。

三条线合在一起，智能体系统才是真的成长：

OpenClaw Memory 让智能体记住上下文
Skills 让函数能力积累经验
Dynamic Ontology 让业务语义空间持续扩展

PART 09

动态本体可视化：从对象图改成五层图

今天我们也重新组织了“本体情况”工具栏。

之前的图更像对象图：左边是数据源，中间是对象，右边是函数和输出。这个图能说明数据源如何映射对象，但业务专家看起来还不够接近 Palantir 动态本体的分层。

现在我们改成五层：数据源层、语义层、动能层、动态层、应用层

数据源层

放 5 个数据源：

situation_feed
recon_report
sigint_report
opensourcegeo
historicalcasedb

这些数据源统一用黄色平行四边形表示。这里刻意统一颜色，是为了强调它们都属于“数据源”，区别不靠颜色，而靠节点名称和说明。后续如果要表达数据质量、在线状态或可信等级，可以再叠加徽标，而不是让颜色承担太多含义。

语义层

放对象和 Link：

AirTarget
TrackPoint
IntelReport
AirspaceZone
SimilarTrackCase
SupportRelationship

SupportRelationship明确作为Link 类型对象出现，表达保障、护航、支援等关系。

动能层

放 Function、Skill 和 Action：

assess_threat
predictadizentry_probability@0.2.0
skill:assess-threat
skill:adiz-entry-probability
updatecesiumoverlay
updateprobabilityoverlay

这层是今天变化最大的地方。Function 不再等同于代码实现，而是本体函数声明。真正的实现由 Skill 承担。Action 负责把本体空间里的结果输出到外部应用。

动态层

放函数输出的决策和事件对象：

ThreatAssessment
ApproachEvent
AdizEntryProbability
HumanReviewTask

这些不是原始数据，而是运行时生成的动态对象。它们会随着数据流、函数计算、专家复核持续变化。

应用层

放本体空间之外的业务应用：

Cesium Digital Earth
OpenClaw Console
Report/Audit View

这层说明本体不是最终界面。Cesium 是态势可视化，OpenClaw Console 是对话式研判入口，Report/Audit View 是报告和审计视图。它们消费本体输出，但不应该替代本体本身。

PART 10

现在这版架构的意义

今天的迭代之后，这个 MVP 的技术路线更清楚了。

动态本体负责定义业务世界：有哪些对象、属性、Link、函数声明、动作和权限边界。
MCP Runtime 负责治理：匹配本体、准备 workspace、检查数据契约、调用函数、记录 lineage、拦截高风险动作。
OpenClaw Skills 负责能力实现：把函数背后的算法、脚本、参数表、经验文档沉淀下来，并支持渐进式加载。
OpenClaw 负责智能体编排：理解自然语言任务，选择本体，调用 MCP，解释结果，继续追问或发起复核。
Cesium 负责应用呈现：显示目标、航迹、预测、ADIZ、情报标记、概率卡片和本体图。

这套分工让系统避免两个常见问题。

一个问题是“大模型直连数据库”。这样短期很快，长期会失控：字段含义不稳定，业务规则不可审计，动作边界不清晰。

另一个问题是“本体只当静态图谱”。如果本体不能运行函数，不能输出动作，不能跟智能体交互，它就只是文档，不是 runtime。

现在的方向是中间路线：本体是 runtime 语义层，Skills 是可成长的函数能力层，OpenClaw 是任务编排层。

PART 11

下一步

这次已经把 predictadizentryprobability@0.2.0和 assessthreat@0.1.0 Skill 化。下一步应该继续做三件事。

第一，把 Skill 的 references 继续补强。尤其是平台参数、历史案例、误判案例、情报权重、复核规则，都应该从代码里逐步迁移到可读、可审计、可迭代的 references。

第二，把 Skill 运行结果回写成更完整的本体对象。目前结果已经能返回 probability、CI、factor、lineage，但还可以进一步实例化为 AdizEntryProbability对象列表，并在对象图里支持查询。

第三，把专家反馈纳入成长闭环。比如专家认为某次概率偏高，系统不应该只改一行代码，而要记录：

这次为什么偏高
是平台参数问题
是历史相似案例问题
是情报权重问题
还是本体 Link先验问题

然后决定该进入 OpenClaw memory、Skill references，还是动态本体模型。

这才是我们理解的动态本体落地：不是一次性建一个漂亮图，而是让业务语义、函数能力和智能体经验一起成长。

立即咨询 JOTO

JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。联系 JOTO 获取 AI 落地咨询

想把这些做法用到你的业务里?

留下你的场景和痛点,我们帮你判断从哪一步开始。

联系我们

动态本体的第二次迭代：从“能研判”到“会成长”

立即咨询 JOTO

想把这些做法用到你的业务里?

开启企业级 AI 落地

填写需求单