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

四步升级：从静态本体到可成长系统

昨天那版东海防空识别区空情研判 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 动态本体的分层表达：数据层、语义层、动能层、动态层、应用层。看图时，业务专家能更快理解系统里每个要素处在什么位置。

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

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

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

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

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

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

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

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

统一的位置推进公式是：

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

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

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

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

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

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

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

Sevent是当前运动事件得分，比如 boundary approach、boundary parallel pattern、non approach or low attention。

Prior_threat来自当前威胁等级：

Prior_country来自国别语义：

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

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

为什么把本体函数改成 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 负责实现：

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

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

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。

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 版本算的”。这对后续审计、回放和模型迭代很关键。

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

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

第一条线是 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 让业务语义空间持续扩展

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

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

之前的图更像对象图：左边是数据源，中间是对象，右边是函数和输出。这个图能说明数据源如何映射对象，但业务专家看起来还不够接近 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 是报告和审计视图。它们消费本体输出，但不应该替代本体本身。

现在这版架构的意义

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

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

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

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

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

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

下一步

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

• 第一，把 Skill 的 references 继续补强。尤其是平台参数、历史案例、误判案例、情报权重、复核规则，都应该从代码里逐步迁移到可读、可审计、可迭代的 references。
• 第二，把 Skill 运行结果回写成更完整的本体对象。目前结果已经能返回 probability、CI、factor、lineage，但还可以进一步实例化为 AdizEntryProbability对象列表，并在对象图里支持查询。
• 第三，把专家反馈纳入成长闭环。比如专家认为某次概率偏高，系统不应该只改一行代码，而要记录：
  • 这次为什么偏高
  • 是平台参数问题
  • 是历史相似案例问题
  • 是情报权重问题
  • 还是本体 Link先验问题
  然后决定该进入 OpenClaw memory、Skill references，还是动态本体模型。

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