OPENNEXUS玖衍科技能力介绍 v6
玖衍科技 · OpenNexus
DECISION OS · 问答优先 · 相关技术深读 · v6

OpenNexus · 面向 LVC 的决策操作系统

玖衍科技以 OpenNexus，把「看见 → 研判 → 推演 → 决策 → 行动/复盘」串成可演示、可验收的闭环；本页以问题导向理解系统：先结论、再展开，按您关心的链路查阅。

产品一句话：在亚秒级窗口内，把 ACMI / DIS / DDS / OSINT / 遥测等多源数据，变成可推演、可裁决、可复盘的结构化战场上下文。

SEE
看见
→
ORIENT
研判
→
SIM
推演
→
DECIDE
决策
→
ACT
行动/复盘
L0
观测输入
KYQB·雷达·UAV
L1
融合裁决
MDW·JUDGE
L2
指挥一张图
战脑 COP
L3
智能参谋
Gradio·RAG
L4
仿真本体
Command·DB3K
系统闭环 · 心智图
看见（L0）→ 研判（L2 COP）→ 推演（L4 CMO）→ 决策（L3 AI）→ 行动/复盘
KYQB/RADAR/UAV → 战脑一张图 → Command+DB3K505 → Gradio/RAG → 杀伤链→BDA
──────── MDW 战术总线（ACMI / DIS / DDS / JSON）贯穿 ────────
为什么能做成 问题导向理解系统 → 打开在线演示 相关技术深读 技术附录（按需展开）

v6 · 问题导向 · 从哪来/为什么/怎么做 · 先结论后细节

WHY WE BUILT IT

为什么 OpenNexus 能做成

复杂 LVC + AI + 仿真系统能落地，靠的不只是代码量，而是站在甲方视角准确分解需求，再用乙方技术栈按里程碑验收交付。其中 FDE（前沿部署工程师）模式是核心组织机制之一。

甲方视角
需求分解
→
FDE
现场翻译
→
Gate
可验收切片
→
乙方工程
技术落地
→
演示
闭环验收

🎯 FDE 做什么

  • 站在甲方一侧：把「一张图、一条链、可推演、可复盘」拆成可演示、可签字的里程碑
  • 站在乙方一侧：把里程碑映射到 Brain / CMO / Gradio / WPF 的真实接口与 Gate
  • 消除语义断裂：指挥员说的「打击」= fusedId + ATO + Command 指令，不是 PPT 动词
  • 联调在场：管道连没连、decision_ready 绿没绿、映射 commit 了没有——现场判读，不靠邮件扯皮

⚙️ 工程上如何兑现

  • 不变量先行：WPF :5000 写口、fusedId SSOT、禁止双推 plan_id——写进文档与 verify 脚本
  • 最小可见链路 MVL：子系统 API → BFF → 图层 → Gate HUD，每步可探活
  • 2 周迭代 + Gate 手册：Wave 验收，degraded 可观测，不假装全绿
  • 产品先演示后签约：1020 万意向均基于已有在线 Demo，不接无产品支撑的预研合同

🔗 与 Palantir FDE 同构

Palantir 的 FDE 驻场把「业务问题」翻译成 Ontology 上的对象与动作；我们的 FDE 把「作战指挥问题」翻译成 DB3K505 本体 + fusedId 映射 + atomic_tasks + LvFlightPlanV1。差别在垂直领域，结构同构：需求在甲方语言里，执行在乙方系统里，中间靠可审计契约。

✅ 一句话总结

能做成 = FDE 准确分解需求 × 乙方技术栈按 Gate 交付 × 在线 Demo 可验收。 不是堆功能清单，而是每一轮都能指着屏幕说：这一步对应您刚才提的那条要求。

↓ 按问题理解系统能力 · 在线演示 · 交付体系

SYSTEM · 问题导向

问题导向理解系统

按您关心的链路组织内容：每条先给一句话结论，再补「从哪来 / 为什么 / 怎么做」，展开后是对比表、数据流与工程要点；需要一页深度论述时进入「相关技术深读」。支持搜索与主题筛选。

Q1 · 仿真选型
为什么用 Command，比 AFSIM 好在哪？
不是全面碾压，是教学演示 + LVC + AI 闭环总成本更低
Q2 · AI 可信
提示词工程与指挥员信任如何做？
封闭原子任务 + 条令溯源 + HITL，不是模型更大
Q3 · 流程
子系统怎么接力？ATO 怎么接？
浏览器只打 Brain BFF；LvFlightPlanV1 为中间契约
Q4 · 模式
为何分成 LVC 训练 / 实战？
同一壳子、两套风险策略：auto vs 人审 + JUDGE
Q5 · MBSE
装备/行为/条令/电磁模型如何分层？
以 DB3K505 为装备本体的轻量 MBSE
Q6 · 想定
一键生成初始态势怎么做？
观测→本体绑定→映射注入→再挂一键决策
Q7 · 统一库
各系统如何共用统一库？
DB3K505 + fusedId + mapping-registry 咬合
Q8 · 规模
DB3K505 有多少实体？
约 1.69 万平台 + 3.2 万+ 挂载方案
Q9 · 可视
十万级多实体怎么看得动？
KYQB 视口聚类 + Tacview LOD/强制聚合
Q10 · RAG
Brain RAG 用了哪些知识库？
ZSSC / 条令 / rag:8091 / MD / 手动 Pin
Q11 · 总线
中间件用到了哪些通信技术？
ACMI·DIS·DDS·NamedPipe·JSON，E2E<200ms
Q12 · 提示词
Gradio 如何把态势迭代成可执行决策？
Y-0/Y-1 选型 → 分层 Prompt → 多战区 LLM → atomic_tasks
Q13 · 执行链
多 LLM 如何让 Command 兵力动起来？
atomic_tasks → WPF 蜂群 → TacticCommandMapper → NamedPipe
Q14 · 杀伤链
Brain 单目标多轮 ATO / 飞行计划怎么生成？
每轮锁一个 fusedId → Command 生成接口 → 飞轮下一目标
没有匹配的问题，试试换关键词或点「全部」。
Q1

为什么使用 Command？比 AFSIM 好在哪？

›
结论：不是「Command 全面碾压 AFSIM」，而是在「教学演示 + 方案论证 + LVC 铰链 + AI 参谋闭环」路线上，Command 更省总成本、更能快速建成可讲解的端到端系统。AFSIM 更偏美军工程分析与高保真插件生态。
ORIGIN · 从哪来教学演示 + LVC 铰链 + AI 闭环要可编辑本体与 GUI 想定；战场失败常卡在「讲不清、接不上」，不是卡在 6-DOF 波形。
WHY · 为什么Command 总成本更低、教员上手快、10 种原子任务易挂 Mission/Doctrine；AFSIM 更适合工程分析副引擎，而非整条杀伤链换壳。
HOW · 怎么做锚定 DB3K505 + Command 写口；未来 AFSIM 可经 MDW/DIS 侧挂进战脑，而不是替换 AI–COP–执行链。

各擅什么

维度Command / CMOAFSIM
定位中高保真、战区—战术；能算、能演、能讲工程—任务多分辨率；易写 C++ 到波形/6-DOF
想定GUI + 条令/任务可视化；教员上手快文本脚本；强在批跑分析
装备库可编辑全球库，本项目锚定 DB3K505依赖社区/自建，工程师门槛高
教学联合作战推演、方案对比、AI 参谋联训型号论证、传感器/干扰工程验证

对本项目的硬理由

  • 本体论已建成：映射 / Gradio / ACMI / ZBSJ 都以 DB3K505 为统一库，换 AFSIM = 重建 Ontology
  • LVC 铰链已落地：Brain → 异构枢纽 → Command Mapping → MDW ACMI → Tacview / JUDGE
  • AI 闭环要「简单动作语言」：10 种原子任务更容易挂到 Command Mission/Doctrine
  • 教学可讲解性：地图上看得见平台、航迹、挂载、条令触发

严谨并存表述

Command = 作战人员/教学的使命级推演壳 + 可编辑本体；AFSIM = 工程分析可扩展框架。未来可用 AFSIM 作高保真副引擎经 MDW/DIS 进入战脑，而不是替换整条 AI–COP–杀伤链。

CommandAFSIMDB3K505教学

专题深读 → CMO 仿真选型 · 附录 CMO · 本体论

Q2

AI 决策如何可信、可审计？（总览）

›
结论：信任 = 可审计的封闭动作语言 + 条令溯源 + 实时编制绑定 + 人在回路——不是「模型更大」。LLM 只被允许说「蜂群听得懂的普通话」。
ORIGIN · 从哪来无约束 LLM 会发明平台、坐标与复合任务；指挥员要的是可签字草案，不是聊天幻觉。
WHY · 为什么信任来自封闭动作语言 + 条令溯源 + HITL，不是参数规模；参谋写原子任务，司令权在人审与门禁。
HOW · 怎么做ZSSC 白名单 → Doctrine → Top5 fusedId → 10 种原子任务；禁双推 plan_id；live 关键打击强制人审。

提示词是多层约束栈

【ZSSC 战术注册表】tactic_id 白名单 →【战术指导】doctrine / lesson →【战略打击目标】战役级（与战术分层） →【战术待毁目标】Brain Top5 fusedId →【挂载分配规则】Ready 时长门禁 →【输出格式】仅 10 种原子任务 + reasoning →【当前战场态势】ORBAT

严格禁止（防胡作非为）

  • 禁止复杂任务类型（如 STRATEGIC_STRIKE、COMPLEX_MISSION）
  • 只能输出 10 种原子任务：MOVE / PATROL / ATTACK / ESCORT / INTERCEPT / AVOID / RTB / REFUEL / HOLD / FOLLOW
  • 禁止模板坐标、(0,0)；Readying>15min 禁作战起飞
  • 未映射 / strikeReady=false → 不得当真打击；友军 ORBAT 空 → 阻断推送
  • Gradio 直推与 Brain strat-close 禁止同一 plan_id 双推

指挥员看到的信任层

信任层指挥员看到什么
条令溯源 ZSSC这条任务对应哪套战法
Doctrine Pack 硬约束红线条文进了决策上下文
DB3K505 本体论打的是库里真型号，不是幻觉平台
reasoning + 会话日志当时喂了什么、模型回了什么
HITL关键打击不黑盒自动放行

口播：「不是让大模型当司令，是让它当参谋写可执行原子任务草案；条令 ID、装备库、人审三道闸决定它不能乱作。」

PromptOpsHITLZSSC原子任务

专题深读 → PromptOps 可信 · Q12 · Q13 · Q14

Q3

各子系统如何交互？ATO / 飞行计划怎么接？

›
结论：浏览器只打 /api/brain/v1/*；Brain BFF (:9101) 是主铰链。ATO 中间契约 SSOT 是 LvFlightPlanV1（JSON）；战略计划另走 atomic_tasks → WPF。
ORIGIN · 从哪来子系统直连浏览器会产生旁路写口与双推；ATO 与战略计划若无中间契约，联调只能靠口头对齐。
WHY · 为什么Brain BFF 作唯一编排铰链，把「看图—批计划—下发—回写」收成一条可探活路径。
HOW · 怎么做浏览器只打 /api/brain/v1/*；ATO SSOT 用 LvFlightPlanV1；战略轨 atomic_tasks → WPF :5000。

生态铰链

浏览器 → Brain BFF :9101 ├─ Gradio :7860（战略决策） ├─ CMO-Agent WPF :5000（Command 写口） ├─ MDW :9005 · JUDGE · 观测五源 ├─ ZBSJ / ZSSC / RAG └─ 映射：commit → UDP:4244 → :4242 MappingService

指挥员：从进入到下令

  1. 看图 → 看威胁 Top5 → 映射入库（db:*）
  2. 要方案（杀伤链 / 一键决策）→ 批 ATO（训练可自动，实战 pending）
  3. 看执行 → 看毁伤（JUDGE / BDA）回写 COP

LvFlightPlanV1 关键字段

schemaVersion · planId · side · missions[].flights[].waypoints · atomicTasks · meta

BFFATOLvFlightPlanV1杀伤链

专题深读 → 杀伤链与 ATO · 附录 战脑 BFF · 闭环数据流

Q4

为何分成 LVC 训练 / 实战两套模式？

›
结论：不是两套软件，是同一指挥壳、两套风险策略。训练把流程跑通；实战强制异构执行 + 人审 + JUDGE 裁决。
ORIGIN · 从哪来训练要敢试打，实战演示要守审批与裁决权威；同一 UI 若只有皮肤切换，风险边界会漏。
WHY · 为什么LVC 职责分离：train 跑通流程，live 验证异构执行 + HITL + JUDGE，便于教学对照。
HOW · 怎么做opMode 切换执行体/裁决源/ATO 批准策略；live 更强调 db:* commit 与 BDA 等 JUDGE。
LVC 训练 train实战 / 演示 live
默认 executorcmo（推演）ygxt（异构实装）
裁决CMO 内置 / 推演JUDGE
ATO 批准可 auto_approvedpending 人工批
BDA训练可 force-unlock必须等 JUDGE
目标安全试打、AI 联训验证实装链路与审批纪律

设计理由：安全边界 · LVC 职责分离 · 教学对照 · 裁决权威 · 映射本体论约束（live 更强调 db:*）。

trainliveJUDGEHITL

专题深读 → LVC 训练/实战 · 附录 OODA / opMode · 安全治理

Q5

Command 基于模型的系统工程：各模型如何分层？

›
结论：工程上采用「以 DB3K505 为装备本体 SSOT + 多模型层耦合」，等价于面向作战仿真的轻量 MBSE（少 SysML 字样，重可验收模型视图）。
ORIGIN · 从哪来装备参数、条令、行为、电磁、裁决若各建一套模型，AI 与仿真会对不上号。
WHY · 为什么以 DB3K505 为装备本体做轻量 MBSE：少 SysML 字样，重可验收模型视图与主键。
HOW · 怎么做任务/条令/行为/装备/电磁/裁决分层挂接；参数进库不进权重黑盒。
任务/作战视图 ATO · Mission · Kill Chain · COA 条令/ROE 视图 Doctrine Pack · ZSSC · CMO Doctrine 行为/Agent 视图 10 类原子任务 · 航点 · 状态机 装备/物理视图 DB3K505 平台/传感器/武器/签名 电磁/频谱视图 JAM/RADAR · ECM/ESM · J/S 裁决/效应视图 JUDGE · CEP/SSPk · BDA

装备参数不进 AI 幻觉；仿真实体存在权在 Command；条令进上下文而不是进权重黑盒。

MBSEDB3K505Doctrine

专题深读 → 本体与 DB3K · 本体论页 · 四层能力

Q6

一键生成初始战场态势想定：如何完成？

›
结论：不是魔法式「自然语言从零吐出完整官方想定」；而是「观测 → 本体绑定 → 映射注入 → 想定常驻」流水线，产品上呈现为「一键起势 / 一键决策联动」。
ORIGIN · 从哪来「自然语言吐完整官方想定」不可验收；真实需求是布好棋盘再生成棋招。
WHY · 为什么先本体绑定与映射注入，禁止 AI 发明装备，才能让一键决策挂在真实 ORBAT 上。
HOW · 怎么做基线想定 → 态势种子 → db:* 校验 → Mapping 写入 → MDW 回流 → 可选一键决策。
① 基线想定（Command 模板 / brain-demo） ② 灌入 KYQB/雷达/UAV 等态势种子 ③ 本体论对齐：ACMI Type + db:##### 校验 ④ 写入仿真：UDP:4244→:4242 → [映射] 单位 ⑤ 态势回流 MDW → COP / Gradio ⑥ 可选：一键决策挂 atomic_tasks / ATO

口播：先「布好棋盘」（映射+库），再「生成棋招」（一键决策）。禁止跳过 DB3K 让 AI 发明装备。

mapping一键起势DB3K

专题深读 → 本体与映射 · 附录 闭环数据流 · 观测五源

Q7

MBSE 逻辑与各系统联系；如何使用统一库？

›
结论：统一库 = DB3K505（装备本体）+ fusedId（运行时融合 ID）+ mapping-registry（映射策略）三者咬合，不是「又一个 SQL 中台」。
ORIGIN · 从哪来各站自造 ID 时，打击链在「目标对不上」处断裂——这比模型不准更致命。
WHY · 为什么统一库 = DB3K505 + fusedId + mapping-registry，不是再建一个平行 SQL 中台。
HOW · 怎么做Command 持仿真实体权威；Brain 映射校验；Gradio 只认 DBID；JUDGE/MDW 认 fusedId。
系统怎么用同一库
Command按 DBID 实例化平台子系统（权威）
ZBSJ只读查询与能力计算，同源 DB3K_505.db3
Brain映射校验 requireDbIdForPush；不持平行库
Gradioloadout/ORBAT 只认 DBID；禁虚构平台
JUDGE/MDW按 fusedId / ObjectId 认实体

整条链共享装备主键（DBID）与运行时主键（fusedId），这就是 LVC 里「统一库」的工程含义。

SSOTfusedIdDBID

专题深读 → 统一库咬合 · 本体论 · 附录实体权威

Q8

DB3K505 里面有多少个实体模型？

›
结论：约 1.69 万可实例化平台定义 + 武器/传感器等组件 + 3.2 万+ 挂载方案（统计来源 zbsj 数据库设计文档，DB3K_505.db3）。
ORIGIN · 从哪来合作方常问「库有多大」——规模决定想定密度与查库体验，也决定是否值得锚定为 SSOT。
WHY · 为什么公开量级建立信任：约 1.69 万平台 + 3.2 万+ 挂载，足够支撑联合作战教学与方案对比。
HOW · 怎么做以 DB3K_505.db3 为源；ZBSJ 只读查询；统计口径对齐装备库设计文档。
类型记录数类型记录数
飞机 Aircraft6,933水面舰 Ship4,571
潜艇 Submarine728固定设施 Facility4,054
地面单位437卫星149
武器4,219传感器7,034
挂载方案 Loadout32,335

库级：175 表 · 18 实体主表 · 70 关联 · 72 枚举。关联表明「模型远不止主表行数」。

DB3K50516900+挂载

专题深读 → DB3K505 规模 · 在线 zbsj.opennexus.fun

Q9

KYQB 标牌聚合：十万级多实体如何显示？

›
结论：不是贴十万个字，而是分层 LOD + 强制聚合 + UI 线程预算。KYQB 管情报密度（supercluster）；Tacview 管仿真军标密度（屏幕空间聚类）。
ORIGIN · 从哪来十万级实体直接贴字会卡死 UI；教员仍要盯住关键目标。
WHY · 为什么分层 LOD + 强制聚合是密度与可讲解性的折中，不是「少画几个点」。
HOW · 怎么做KYQB supercluster 管情报密度；Tacview 按 N 阈值强制聚类/LOD 色点。
实体数 NTacview 策略
≥ 500强制标牌聚类
≥ 1000绝大多数 datablock 关闭；裁剪↑
≥ 3000LOD 色点替代军标 PNG；更强裁剪

口播：高度一拉高就聚成簇、再高变成色点；点选才展开单实体——UI 线程活得下来，教员也能盯住关键目标。

superclusterLOD聚合

体验 → kyqb.opennexus.fun · 深读总览 /tech/

Q10

Brain 里 RAG 用了哪些知识库？

›
结论：Brain 不托管向量库，做多源检索编排，结果打进 decision-context-bundle / Gradio / Copilot。
ORIGIN · 从哪来决策上下文需要条令、战例与检索证据；Brain 不应再托管第二套向量权威。
WHY · 为什么多源编排比单库堆文档更可控：ZSSC/条令/RAG/MD/Pin 各有职责。
HOW · 怎么做Brain 编排检索打进 decision-context；主路径一键决策默认多 LLM + ZSSC。
分组内容来源
ZSSC 战例战术课件、lesson本地 / zssc.opennexus.fun
条令 ROEMD + 硬约束 frontmatterdata/doctrine/
RAG 检索外部向量/混合检索:8091 → rag.opennexus.fun
MD 知识MDW/MD 检索:9005 / :8091
手动 Pin指挥员固定引用Copilot / Gradio

Gradio 旁路可走 WeKnora；主路径一键决策默认多 LLM + ZSSC，不强制 WeKnora。

RAGZSSCDoctrine

专题深读 → PromptOps / 知识约束 · rag.opennexus.fun

Q11

中间件通信技术：用到了哪些？

›
结论：NEXUS MDW (:9005) = Agent「看见战场」的神经系统：ingest → 协议识别 → 统一模型 → 视角过滤 → 多目标路由；目标 E2E <200ms。
ORIGIN · 从哪来Agent「看不见战场」时，再强的参谋也只能空转；多协议烟囱需要统一 ingest。
WHY · 为什么MDW 做神经系统：识别协议 → 统一模型 → 视角过滤 → 多目标路由，目标 E2E<200ms。
HOW · 怎么做ACMI/DIS/DDS/NamedPipe/JSON 各司其职；Command 写口仍只经 WPF。
技术用途
ACMI 2.2CMO EventExporter 实时态势；映射线
JSON / RESTOSINT、BFF、WPF IntegrationApi
TCP / UDP外置中间件；映射 :4242/:4244
DDS电战与分布式 pub-sub
DIS IEEE 1278射频 IoT；分布式互操作
NamedPipeCommand ↔ CMO_AI_Agent 默认通道
HLA产品矩阵预留联邦对接
Command ←NamedPipe→ Agent :5000 ←HTTP→ Gradio/Brain Command ←UDP ACMI:4242→ Mapping ←:4244← Brain CMO → EventExporter → MDW → Tacview + Brain
ACMIDISDDSNamedPipe

专题深读 → 中间件协议栈 · middleware.html · 在线系统

Q12

CMO-Gradio 提示词工程：态势如何迭代成可执行决策？

›
结论：不是「聊天历史多轮」，而是 Round-0 态势选型（战术+目标）→ 分层 Prompt 聚合 → 多战区 LLM 产出 atomic_tasks → 校验/绑兵 → POST WPF。指挥员看到的「迭代」= Y-0/Y-1 选型 + 可选 AutoDecisionLoop 按最新 ORBAT 再跑一轮。
ORIGIN · 从哪来聊天多轮不等于可执行决策；需要从态势「问」出战术与目标再写任务。
WHY · 为什么Y-0/Y-1 选型 + 分层 Prompt + 多战区 LLM，把迭代变成可观测流水线。
HOW · 怎么做decision_ready → Round-0 → Prompt 栈 → MultiLLM → normalize → POST WPF → 双写 Brain。

端到端流程（一键决策 / Brain 触发）

① 门禁 wait decision_ready（管道/友军/蜂群） ② 拉态 POST /api/request_state + entity_allocation_view ③ Round-0 选型 Y-0 TacticSelector（规则打分 ORBAT）→ 可选 Y-1 TacticPlannerLLM 精炼 → tactics[] + targets[] + rationale ④ PromptManager 聚合（ZSSC/条令/战略目标/战术目标/挂载/禁止项/态势） ⑤ MultiLLMCoordinator 多战区并行 LLM（每区再拼单位明细+10种任务契约） ⑥ merge / geo_anchor / W-1 normalizer（unit_ids + tactic_id + loadout） ⑦ POST WPF /api/strategic_plan → 蜂群执行（见 Q13） ⑧ 双写 Brain /strategic-plan/ingest（COP 战略任务 Tab）

Round-0：战术 / 打击目标如何从态势「问」出来

轮次组件输入输出
Y-0TacticSelectorORBAT 摘要（战机/攻击机/敌 SAM/挂载…）≤8 战术名 + ≤3 战略目标 + rationale（规则）
Y-1TacticPlannerLLMY-0 候选池 + ORBAT + 挂载规则JSON selected_tactics/targets；失败回退 Y-0
手动Gradio 勾选用户战术 + Brain inboxmethod=manual

提示词堆叠顺序（= 约束优先级）

  1. ZSSC 战术注册表 → tactic_id 白名单
  2. 【战术指导】Y-0/Y-1 或用户选中战法正文
  3. 【战略打击目标】战役/方向级（不与战术实体级混写）
  4. 【战术待毁目标】Brain Top5 fusedId；strikeReady=false → 仅 RECON/PATROL
  5. 【挂载分配规则】Ready 中禁作战起飞
  6. 【输出格式】仅 10 种原子任务 + reasoning
  7. 【当前战场态势】友军/接触/燃料弹药

战区级「第二次提问」：兵力如何进入 Prompt

每个战区 LLM 在聚合 Prompt 上再追加：本战区任务目标、本战区单位明细（位置/燃料/武器）、敌方接触、AtomicTaskFormatter 示例与禁止复合任务清单、executor_requirements（unit_type/min_count/武器需求）。

推送前代码侧「二次迭代」（非 LLM）

  • task_coordinator.merge_results — 多战区去重/优先级
  • geo_anchor — 禁模板坐标、(0,0)
  • atomic_task_normalizer — unit_types→真实 unit_ids；已装弹优先
  • 友军 ORBAT 空 → 直接阻断推送
PromptOpsY-0/Y-1MultiLLMatomic_tasks

专题深读 → PromptOps · 多LLM执行 · Q13

Q13

多 LLM 如何指挥多智能体，让 Command 兵力执行？

›
结论：多 LLM = 多个战区参谋并行写 atomic_tasks；多智能体 = WPF 蜂群（Swarm）+ 每单位 UnitTask；Command = TacticCommandMapper → CommandExecutionFacade V2 → NamedPipe 下指令。浏览器/Gradio 不得绕开 WPF 直写 Command。
ORIGIN · 从哪来单模型指挥全球 ORBAT 会丢细粒度；浏览器直写 Command 会破坏写口唯一性。
WHY · 为什么多战区并行写 atomic_tasks，WPF 蜂群作唯一执行宿主（INV-01）。
HOW · 怎么做merge/normalize → POST :5000 → Swarm → TacticCommandMapper → NamedPipe。

角色分工（勿混层）

层组件干什么不干什么
多 LLMMultiLLMCoordinator（1~5槽）按战区写 atomic_tasks不直接开管道
战略编排Gradio Orchestrator聚合、规范化、HTTP 推送不持 Command 权威实体
多智能体宿主WPF IntegrationApi :5000收计划、建蜂群、分解任务不是 Mock 第二后端
执行面TacticCommandMapper + FacadePlotCourse/AssignTarget/LaunchWeapon…—
仿真实体Command NamedPipe兵力真正机动、开火—
Theater-LLM-1 ──┐ Theater-LLM-2 ──┼─► merge → normalize → POST /api/strategic_plan Theater-LLM-N ──┘ │ ▼ WPF StrategicTaskHandler │ ┌────────────────┼────────────────┐ ▼ ▼ ▼ Swarm A Swarm B Swarm C │ │ ▼ ▼ UnitTask 分解 → TacticCommandMapper → ExecuteV2CommandsAsync │ ▼ NamedPipe → Command 兵力机动/开火

多 LLM 分兵再合

  • theater_divider 地理/功能切战区
  • LLM 数量启发：友军 ≤50→1，≤150→2，≤250→3，上限 5
  • 每战区一份单位列表，避免「一个模型指挥全球」丢细粒度
  • merge_results 冲突检测、去重、排序 → 单一 strategic_plan

WPF：计划 → 蜂群 → 指令

  1. EnsureDecisionReady 门禁
  2. 按 executor_requirements + 燃料/挂载筛兵 FilterEligibleUnits
  3. SwarmMatcher 新建或复用蜂群
  4. TaskDecomposer：atomic_task → 每单位 UnitTask
  5. TacticCommandMapper：tactic_id + task_type → CommandInstructionV2[]
  6. ExecuteV2CommandsAsync → NamedPipe → Command

为什么指挥得动：任务语言封闭（10 种原子任务）· 兵力绑定在 WPF/normalizer 完成 · tactic_id 映射指令模板 · allocation_view 闭环防重复派兵。

WPF :5000SwarmNamedPipeBrain strat-close

专题深读 → 多LLM→Command · Q12 · Q14

Q14

Brain 杀伤链：单目标多轮审核 → ATO / 飞行计划（Command 生成接口）

›
结论：战术打击链 = 串行 OODA，每轮锁一个 fusedId。Step③ 调 Command mission/create-from-brain / ato/generate 产出 LvFlightPlanV1；train 可自动批、live 舱室人工批；飞轮确认下一目标开新一轮。Gradio 战略计划是并行轨，可 ingest 进 ATO 缓存，但不替代单目标 KC。
ORIGIN · 从哪来一步 ATO 吞掉整个 Top5 不可审计；未映射目标放行会造成假闭环。
WHY · 为什么单目标串行 OODA + strikeReady 门禁，保证每条计划可回溯 fusedId。
HOW · 怎么做lock→lv-match→Command 生成 LvFlightPlanV1→审核下发→BDA→飞轮下一目标。

双轨：战略任务 vs 战术杀伤链

左栏 Top5 / mapping ── fusedId ──┬──► 右栏「战略任务」Tab（Gradio 多 atomic_tasks） └──► 右栏「杀伤链」4步（★同一时刻只服务一个 fusedId） │ ▼ kc-ato-cache → task-router / strat-close

四步杀伤链（G-KC-4STEP-01）

Step指挥员动作后端要点
① lockTop5 点选 → 锁定一个 fusedIdforce-detail；flywheel/target-confirm
② lv-match映射 commit（db:* 打击机）或选异构执行体mapping_not_committed / strikeReady 阻断
③ ato「生成 ATO / 飞行计划」优先调 Command 生成接口
④ dispatch审核通过后下发 + BDAtask-route/dispatch + JUDGE

Step③ Command 生成调用链

UI → POST /api/brain/v1/ato/generate ├─ 优先 createMissionFromBrain → POST Command /api/mission/create-from-brain ├─ 次回 POST Command /api/ato/generate └─ 降级 BFF local（Command 不可达时演示） → writeKcAtoCache + buildLvFlightPlanV1 → { atoBrief, flightPlan, atomicTasks[], planId }

缓存键 ${opMode}:${fusedId} — 每个目标每模式一条 ATO 缓存。

「多轮审核」vs「多轮打击」

  • 同目标内审核：train → auto_approved；live → pending → 舱室 POST /kc-cockpit/approve
  • 多目标多波次：飞轮 target→mapped→ato→approval→dispatch→bda → GET /flywheel/next-target → 新一轮四步链

不是一步 ATO 吞掉整个 Top5；而是一条链打完 → BDA → 确认下一目标 → 再调 Command 生成。

单目标完整生命周期

0. 情报入链 → 1. 锁定 T1 → 2. L/V 匹配 strikeReady 3. Brain → Command 生成 LvFlightPlanV1 4. 审核（train自动|live人审）→ 5. 下发 ACK 6. BDA JUDGE 回写 → 7. flywheel 下一目标 T2 → 重复 1～6
Kill ChainLvFlightPlanV1flywheelCommand API

专题深读 → 杀伤链与 ATO · 演示 brain.opennexus.fun

ABOUT

玖衍科技 · 公司概况

玖衍科技是国防仿真与智能决策领域的服务商；OpenNexus 是我们交付的产品平台（公司负责签约实施，产品负责在线能力）。我们帮客户把分散的雷达、情报、仿真和指挥系统，整合成「一张图、一条链、可推演、可复盘」的数字化战场环境。

创新专业务实可验收交付

玖衍科技（公司）

  • 商务签约、项目实施、运维保障
  • 按里程碑 Gate 验收交付
  • 国防仿真、联合训练、智能决策

OpenNexus（产品）

  • 18+ 子系统在线协同
  • 战脑一张图 + 仿真推演 + AI 参谋
  • www.opennexus.fun 为产品总控台
PRODUCTS

全链条产品体系

三大核心产品对应「装备底座 → 仿真推演 → 态势决策」，再加统一平台底座，形成从看见到行动的完整能力闭环。不必先懂技术名词，先记住这三块能帮您做什么。

ZBSJ · 装备库

装备底座

像「数字军火库」——查装备、算能力

收录战机、舰艇、导弹等装备参数，支撑想定编辑、火力计算和仿真推演。是后续一切推演的「弹药与装备清单」。

装备查询火力射程想定配置
在线体验 →
CMO · 天演仿真

智能仿真

像「虚拟战场」——推演、训练、评估

高逼真作战仿真引擎，支持百人联机、三维态势回放。可在虚拟环境中验证方案、组织训练、评估战果，不必动用实装。

作战推演联合训练三维回放
在线体验 →
战脑 · 天象决策

态势决策

像「指挥大屏」——一张图看清、辅助决策

把雷达、情报、卫星、仿真等多路信息汇聚到一张作战图上，标出威胁、辅助生成行动方案，关键步骤由人审批把关。

一张作战图威胁研判AI 参谋
在线体验 →

智能化平台底座（让上面三个产品能协同工作）

数据融合把雷达、情报、遥测等不同来源数据接到一起
战术总线各子系统之间实时传递战场信息
毁伤裁决统一判定打击结果，回写到地图和仿真
知识库 + AI条令战法检索，辅助生成行动方案
CAPABILITY LOOP

能力闭环：从看见到行动

OpenNexus 解决的核心问题不是「又一个仿真软件」，而是把看见 → 研判 → 推演 → 行动 → 复盘串成闭环。下面用业务语言说明每一步对应什么。

01 · 看见

多源信息接入

雷达发现、开源情报、无人机遥测、卫星过境……不同来源的战场信息，统一汇聚到战脑一张图上，不再各看各的系统。

02 · 研判

威胁识别与排序

自动标出高威胁目标，辅助判断谁该优先处置。指挥员在一张图上完成「看清形势」。

03 · 推演

方案仿真验证

在 CMO 虚拟战场里试打一遍：如果这样分配武器、这样航线突防，结果会怎样？先算清楚再下决心。

04 · 行动与复盘

下达任务 · 评估战果

训练模式下由仿真执行；演示模式下可对接实装链路。打击后自动评估毁伤，结果回写地图，形成复盘闭环。

SCENARIOS

典型应用场景

不管您是做训练试验、方案论证还是态势指挥，都可以按场景组合产品模块，不必一次买全栈。

场景 01

作战推演与方案论证

在虚拟环境里验证作战方案可行性，对比多种打法的效果，形成有据可依的决策建议。

组合：装备底座 + CMO 仿真 + 战脑回放
场景 02

模拟训练与导调评估

构建想定、组织红蓝对抗、过程监控、战后复盘，提升训练组织效率。

组合：CMO 仿真 + 战脑导调 + 三维回放
场景 03

多源态势融合指挥

雷达、情报、卫星等多路信息汇聚一张图，辅助威胁研判和行动筹划。

组合：战脑 + 情报接入 + AI 参谋
场景 04

联合仿真与系统对接

与已有仿真系统、实装设备通过标准协议互联，保护既有投资，增量扩展能力。

组合：战术总线 + 协议适配 + 映射对接
LIVE DEMO

在线演示入口

以下子系统均已部署在线，可直接打开体验。建议从「战脑」开始，感受一张图指挥；再进入 CMO 看仿真推演。

战脑 · 指挥一张图

态势汇聚、威胁研判、杀伤链操作

brain.opennexus.fun

CMO · 作战仿真

想定编辑、推演运行、联机对抗

cmo.opennexus.fun

开源情报

区域舆情与航迹情报接入

kyqb.opennexus.fun

装备库

装备参数查询与能力计算

zbsj.opennexus.fun

产品总控台

全子系统入口与 Gate 状态

www.opennexus.fun
ADVANTAGE

三大技术优势

技术细节见文末「技术详解」章节；这里只说明对您的业务价值。

🔗

多源融合一张图

雷达、情报、仿真、遥测不再各看各的，统一汇聚到战脑，一个目标只标一次。

⚔️

源码级仿真推演

掌握 CMO 仿真引擎源码，可深度定制想定、规则和装备，支持百人规模联机推演。

🤖

可信 AI 辅助决策

结合条令知识库生成行动建议，关键决策由人审批，AI 参谋而非 AI 替代。

COOPERATION

合作模式

我们按场景对齐需求，分阶段交付、分阶段验收，降低合作风险。

合作类型您能得到什么
能力演示在线 Demo 环境 + 战脑/CMO 现场演示 + 验收报告
模块集成与贵方已有系统对接，打通数据链路和地图显示
定制开发专属想定、装备库、情报区域、AI 决策能力定制
联合投标全套方案文档 + 可演示环境 + 技术支撑
四步流程：场景对齐 → 在线 Demo 验收 → 接口方案确认 → 分期里程碑交付 · 工程节奏见 交付体系
PLATFORM

平台四页：同一套工程语言

本体论、安全治理、交付体系与本文档共用明亮主题与 Gate 口径，互为入口。

数据本体论

fusedId · 映射 · DB3K505 · MVL

安全与治理

train/live · ACL · HITL · 审计

交付体系

阶段 0～3 · verify 脚本 · 多环境

产品门户

26+ 子系统 · 架构总览