动态本体 + 本体 MCP:把 OpenClaw接入东海 ADIZ 空情研判的 MVP 实战

PART 01

背景：智能体不是缺数据，而是缺一层业务语义

这个项目一开始并不是从前端页面开始的。

如果只是做一个演示，我们完全可以先把 Cesium 地球拉起来，再把几架飞机、几条航迹、几段情报报文画到图上。页面会很快有样子：东海防空识别区、空中目标、历史航迹、预测航迹、威胁等级、OpenClaw 对话框。这些东西都能看见，也都能讲。

但真正的问题不在这里。

真正的问题是，当 OpenClaw 收到一句自然语言任务，比如：

基于当前态势，预测空中目标未来进入防空识别区的概率。

它应该怎么理解这个任务？

它是直接去查态势表吗？还是先找目标？目标的“当前态势”来自哪个字段？防空识别区是一个地图图层，还是一个业务对象？“进入概率”是按距离算，按航向航速算，还是要结合历史航迹、机型、情报报文和保障关系？如果目标已经在 ADIZ 里面，系统还要不要继续输出“未来进入概率”？

这些问题不是提示词能长期解决的。提示词可以让模型写出一份看起来合理的报告，但很难保证每次都沿着同一套业务语义、同一套数据 lineage 和同一套动作边界运行。

所以我们先做了一层动态本体。

PART 02

什么是动态本体

在这个 MVP 里，我们把动态本体定义为：

动态本体是数据、业务和智能体之间的运行时语义层。它把多源数据映射为业务对象和对象属性，通过 Link 表达对象之间的业务关系，通过函数在本体空间内完成计算，并通过动作机制输出受治理的决策建议。

这句话里有五个关键点。

第一，本体是运行时的，不是静态文档。它不是画完图给人看的，而是 OpenClaw 真正要调用的业务空间。

第二，本体以对象为中心。目标、航迹点、情报报文、空域区域、威胁评估、抵近事件，都要变成对象。

第三，数据源连接的是对象属性，而不是直接连接智能体。态势表里的heading、speed、lat/lon，航侦报文里的正文和置信度，技侦报文里的来源可靠性，GeoJSON 里的 ADIZ 边界，都要落到对象属性上。

第四，对象之间要有 Link。一个空中目标有航迹点，被报文支撑，位于或接近某个区域，被某个威胁评估结果引用。这些关系不能只写在说明文档里，而要成为可查询、可计算的关系。

第五，函数在本体空间里运行。抵近识别、意图推断、历史相似航迹检索、证据链生成、威胁评估、进入 ADIZ 概率预测，都不是散落在外面的脚本，而是本体函数。

这就是我们理解的“动态”：对象会随数据流更新，关系会随任务空间生成，函数会基于当前对象空间计算，智能体通过 MCP 调用这些能力，前端再把运行状态可视化出来。

PART 03

项目想定：东海 ADIZ 多源空情研判

这次 MVP 的想定方向选在东海防空识别区。

区域边界采用六个坐标点构成多边形：

北纬 33 度 11 分、东经 121 度 47 分
北纬 33 度 11 分、东经 125 度 00 分
北纬 31 度 00 分、东经 128 度 20 分
北纬 25 度 38 分、东经 125 度 00 分
北纬 24 度 45 分、东经 123 度 00 分
北纬 26 度 44 分、东经 120 度 58 分

这些点不是简单画在地图上的参考线，而是进入了AirspaceZone对象。Cesium 上看到的 ADIZ边界、虚线、多边形填充，只是这个对象的可视化结果。后续判断目标是否进入 ADIZ、是否抵近 ADIZ、是否沿边界平行侦察，都基于这个区域对象计算。

空中目标设计为 10 个以上，包括 RC-135V/W、F-16CM、F-22A、E-3G、KC-135R、P-8A、MQ-4C、U-2S、E-8C、B-52H 等。它们从横田空军基地、嘉手纳空军基地、群山空军基地等方向出现，执行不同任务：边界平行 ISR 侦察、抵近试探、存在巡逻、预警支援、加油支援、海上巡逻侦察和高空持续监视。

态势数据模拟10分钟数据流，每5秒一个航迹点。这样目标不是一个静态点，而是一段随时间变化的轨迹。前端播放时，航迹线只显示已经发生的部分；未来预测航迹不会提前出现，避免把预测当成现势。

情报数据分为四类：

situation_feed：结构化态势表，记录目标、机型、国别语义、位置、高度、航向、航速和时间戳。
recon_report：航天侦察影像判读报文，描述机场部署、训练、维修、保障车辆、起飞准备等。
sigint_report：技侦监听报文，描述数据链、雷达、通信、电子信号和周期性回传。
open_source_geo：开源地理与公开动态，包括 ADIZ 边界、基地坐标、新闻和社交媒体线索。

这些数据故意不是一种格式。态势是结构化表，航侦和技侦是文本报文，开源地理是 GeoJSON 和动态线索。我们要验证的正是：动态本体能不能把这些异构数据变成可运行的业务对象空间。

PART 04

总体架构

本项目可以分成五层：多源数据层、动态本体层、本体函数层、本体 MCP 层、OpenClaw + Cesium 交互层。

这张图体现了项目的主线：数据不是直接喂给OpenClaw，OpenClaw也不是直接查数据库。数据先进本体，本体准备对象和关系，函数在本体空间计算，MCP 把这些能力暴露给 OpenClaw，Cesium 再把运行态展示出来。

PART 05

本体对象定义

本项目的核心对象不是从数据库表反推出来的，而是从业务问题里抽出来的。

AirTarget是空中目标。它包含目标 ID、名称、平台类型、国别语义、起飞机场、任务类型、当前威胁等级、最新位置和 SIDC符号编码。一个 RC-135、一个 F-16 或一个 KC-135，在本体里首先都是 AirTarget，只是属性不同、关系不同、函数判断不同。
TrackPoint是航迹点。它记录目标在某一时刻的经纬度、高度、航向、航速。一个目标会有一串航迹点，通过HAS_TRACK_POINT Link 连接。这样我们才能讨论“历史航迹”“当前点位”“未来预测”，而不是只看一个静态坐标。
IntelReport是情报报文。航侦文本、技侦文本、开源动态都可以实例化为情报对象，但会保留类型、来源、正文、置信度、来源可靠性和关联目标。这样做的好处是，威胁评估不是一句“情报显示”，而能追溯到具体报文。
AirspaceZone是空域区域。东海 ADIZ、关注区、边界线都属于区域对象。区域对象的核心属性是 geometry和coordinates。这让 ADIZ 不再只是前端图层，而是函数可以读取和计算的业务对象。
ThreatAssessment是威胁评估对象。它不是原始数据，而是函数输出，包含威胁等级、置信度、规则版本、证据、人工复核标记和 lineage。
ApproachEvent是事件对象。抵近、进入、边界平行飞行等，都可以成为事件对象。事件对象让系统能够把“运动学变化”提升成业务事实。

PART 06

数据源如何映射到本体

动态本体落地时，最容易被忽略的是字段级映射。

我们没有简单地说situation_feed对应 AirTarget，而是明确到字段：target_id映射到 AirTarget.targetId，target_name映射到 AirTarget.name，target_type映射到 AirTarget.platformType，country映射到 AirTarget.affiliation。这里的country不是普通国家字段，而是业务语义标签：red表示对抗方，unknown表示身份未确认，neutral表示中立，blue表示己方。

lat/lon/altitude_m会进入 TrackPoint.position，同时最新航迹点会投影为AirTarget.latestPosition。heading和 speed会进入运动属性，供抵近识别和概率预测函数使用。

航侦报文和技侦报文进入IntelReport。正文进入rawText，报文类型进入 reportType，置信度进入confidence，来源可靠性进入sourceReliability。在证据链里，系统可以计算confidence * sourceReliability，避免把所有报文都当成同等可信。

ADIZ GeoJSON 进入 AirspaceZone.geometry。这一步让区域边界既能显示在 Cesium 上，也能参与函数计算。比如 predict_adiz_entry_probability会用这个多边形判断目标是否已经在 ADIZ 内。

这就是本体作为“数据与业务之间桥梁”的意义：数据不是消失在模型上下文里，而是落在明确的对象属性上，并且能被追溯。

PART 07

Link：对象之间的业务关系

对象只是第一步，Link 才让本体变成业务网络。

AirTarget HAS_TRACK_POINT TrackPoint：让目标拥有时间序列。
AirTarget SUPPORTED_BY_REPORT IntelReport：让目标与情报报文建立支撑关系。
AirTarget LOCATED_IN_OR_NEAR AirspaceZone：让目标与 ADIZ、关注区建立空间关系。
AirTarget ASSESSED_BY ThreatAssessment：让目标与威胁评估结果连接。
ThreatAssessment USES_EVIDENCE_FROM IntelReport：让研判结论能回溯到证据。

这些 Link 不是图谱上的装饰线，而是函数运行路径。一个函数可以从 AirTarget出发，沿 Link 找到航迹点、情报报文、区域对象，再组合计算。OpenClaw 后续问“为什么 TGT-041 是高威胁”，系统也能沿 Link 找到对应证据链。

PART 08

本体函数：让本体从“能描述”变成“能研判”

本体如果只有对象和关系，还只是静态模型。真正让它动态起来的是函数。

detect_approach_events：用来识别目标是否抵近 ADIZ、进入 ADIZ，或者沿边界平行飞行。它会读取目标航迹点，计算经纬度变化、持续时间、平均速度、航向变化、高度方差和采样数量。
infer_intent：用来推断意图。比如 RC-135V/W 沿 ADIZ 东侧边界平行飞行，且航侦和技侦报文都指向侦察活动，那么意图可以判断为边界平行 ISR 侦察。F-16CM 高速向ADIZ 收敛，但身份未确认且只有单源情报支撑，则更适合判断为抵近试探，并保留人工复核。
find_similar_tracks：用来找历史相似航迹。它让系统不只看当前 10 分钟，而能把当前模式放到历史样例里比较。
build_evidence_chain：用来生成证据链。它返回规则版本、支撑报文、来源可靠性、加权置信度、相似案例和数据 lineage。这是系统能不能让人信服的关键。
assess_threat：用来输出威胁等级。它综合目标阵营语义、平台类型、运动模式、情报支撑、历史相似航迹和规则策略，输出 high、medium、low，并判断是否需要人工复核。
predict_adiz_entry_probability：用来预测进入 ADIZ 的概率。它会随时间轴实时重算。这里有一个重要修正：如果目标当前点位已经在ADIZ 多边形内，概率必须是 100%，状态为 already_inside_adiz。例如 TGT-017 已经在防空识别区内，系统就不能再输出一个“未来进入概率 80%”。这个细节说明本体函数不是为了生成漂亮分数，而是为了遵守业务事实。

PART 09

本体 MCP：OpenClaw 如何使用本体

为了让 OpenClaw 调用本体，我们实现了 Ontology Runtime MCP Server。

它暴露的工具包括：

MCP 工具	作用
list_ontologies	列出可用本体
match_ontology	根据自然语言任务匹配本体
create_task	创建研判任务
get_data_contract	返回本体需要的数据源契约
prepare_workspace	拉取并准备任务数据空间
run_function	执行本体函数
explain_result	返回证据链和 lineage
propose_action	生成受控动作建议

OpenClaw的运行链路因此变成：

这条链路的价值在于，OpenClaw 不是直接访问底层数据，而是进入一个受控的业务语义层。它知道该使用哪个本体，知道本体需要哪些数据，知道可调用哪些函数，也知道哪些动作只能提出建议、不能直接执行。

军事场景里这个边界非常重要。当前 MVP 明确限制为 decision_support_only。高风险动作，比如直接作战控制、武器分配、自动拦截执行，不会由智能体直接触发，只能生成建议或进入人工复核。

PART 10

Cesium前端：本体运行态控制台

前端不是简单态势大屏，而是本体运行态控制台。

Cesium 加载 Esri 影像底图，显示东海 ADIZ、多边形区域、目标点位、历史航迹、预测航迹和情报标记。空中目标图标采用接近 MIL-STD-2525B 的空中目标符号，不同阵营用不同外形和颜色表达。目标每 5 秒更新一个点位，航迹线只跟随已经发生的航迹增长。

页面上有多个工具栏：区域属性、目标列表、OpenClaw、AI 研判、情报、运行日志、目标详情、数据源情况、本体情况。所有工具栏都支持显示/隐藏、拖放和缩放。刷新页面后会按默认位置重新部署，避免重叠和挤压。

其中“本体情况”工具栏最重要。它展示的不是普通知识图谱，而是动态本体的运行结构：数据源连接对象属性，属性实例化对象，对象之间通过 Link 建立业务关系，函数消费对象并输出事件和研判结果。这个图谱未来可以扩展成业务专家建模界面，让专家不写代码也能定义对象、属性、Link、函数和动作策略。

PART 11

一次完整研判如何发生

以 TGT-017 为例。

态势流中，TGT-017 是一架 F-16CM 类目标，身份未确认，沿东海 ADIZ 北段持续收敛。航迹点进入 TrackPoint，目标属性进入AirTarget，航侦报文进入IntelReport，ADIZ 边界进入 AirspaceZone。

OpenClaw收到预测任务后，通过 MCP 匹配到 air_target_threat_assessment本体，准备工作区，然后调用 predict_adiz_entry_probability。函数读取当前时间步的目标位置，先做 ADIZ 多边形内点判断。由于 TGT-017 当前已经在 ADIZ 内，函数直接输出：

target_id: TGT-017probability: 1.0status: already_inside_adizallowed_effect: decision_support_only

这比单纯输出“高概率进入”更符合业务语义。因为系统判断的不是一个抽象风险分，而是一个本体事实：目标已经进入该区域。

如果目标还没有进入 ADIZ，函数会继续融合当前航向航速、历史航迹、情报加权置信度、目标类型、国别语义和保障关系，输出动态概率。随着 10 分钟态势流播放，概率会实时变化，OpenClaw 对话框中的预测列表也会跟着刷新。

已关注

关注

重播分享赞

视频详情

PART 12

踩坑与修正

这个 MVP 做下来，有几个地方很典型。

第一个坑是把未来航迹提前画出来。这样看起来信息更多，但会误导用户，以为预测航迹是已经观测到的航迹。后来我们改成历史航迹随时间推进，预测航迹只在数据流结束后出现。

第二个坑是把目标进入 ADIZ 当成概率问题。TGT-017 已经在区内时，系统还输出 70% 或 80%，这在业务上是错的。后来本体函数增加了多边形内点判断，已进入就是 100%。

第三个坑是前端工具栏一开始采用固定三列布局，隐藏后会留下黑色区域。后来改成 Cesium 全屏底图，所有工具栏浮在地图上，并支持拖放、缩放和隐藏。

第四个坑是本体图谱一开始只展示对象，缺少数据源到对象属性的映射。用户真正关心的是：这个属性来自哪个数据源、哪个字段、哪张表、哪条报文。后来我们把数据源、属性槽、对象、Link、函数、结果对象放到同一张图里。

这些修正都指向同一个原则：系统不能只“看起来智能”，而要在业务语义上站得住。

PART 13

这个 MVP 验证了什么

这个项目验证了三件事。

第一，动态本体可以成为智能体和业务系统之间的桥。OpenClaw 不需要每次从原始数据开始猜业务含义，而是进入一个已经定义好对象、属性、Link、函数和动作边界的业务空间。

第二，本体 MCP 可以成为智能体调用本体能力的标准入口。通过 match_ontology、prepare_workspace、run_function、explain_result、propose_action，智能体的每一步都有业务语义、证据链和权限边界。

第三，前端应该展示本体运行态，而不是只展示最终报告。目标、航迹、情报、区域、函数、证据链、预测结果和动作建议，都应该能在一个操作台里被观察和解释。

PART 14

后续方向

下一步最值得做的是本体建模工具化。现在对象、属性、Link、函数和动作主要靠开发配置，未来应该让业务专家通过可视化界面建模。专家可以定义“飞机”“区域”“事件”“威胁评估”等对象，配置字段映射，建立 Link，声明函数输入输出和动作策略。

第二是数据接入真实化。当前数据是合成想定，但结构上已经按数据库表、文本报文、GeoJSON 和开源动态组织。后续可以接入真实数据库、消息队列、文档库和历史航迹库。

第三是函数能力增强。当前预测是可解释启发式，适合 MVP 验证。后续可以加入更严谨的轨迹预测、时序相似度、图查询、意图识别模型和不确定性估计。但这些模型仍然应该运行在本体空间里，输出可解释、可追溯、可审计的结果。

PART 15

总结

这次 MVP 的核心不是 Cesium，也不是某个预测公式，而是把智能体接入复杂业务系统的一条工程路径。

数据先进本体，变成对象和属性；对象通过 Link 形成业务关系；函数在本体空间里计算事件、意图、威胁和概率；MCP 把这些能力暴露给 OpenClaw；Cesium 把整个过程展示出来；动作则始终受策略和人工复核约束。

一句话概括：

我们不是让OpenClaw 直接面对一堆空情数据，而是让它进入一个可计算、可解释、可治理的东海 ADIZ 动态本体。