从哪来 · 为什么 · 怎么做
玖衍 Q13 问「多 LLM 如何落到 Command」。本节把 fan-in / fan-out 执行链写成可指着联调的管道图。
单 LLM 管不了全球 ORBAT
一次想让 AI「指挥整个战区」时，单模型 context 无法容纳全部 ORBAT 节点、武器挂载、航路约束与条令冲突——输出要么过度简化，要么 hallucinate 细节。早期尝试「一个超级 prompt 管全部」在联调中100% 出现平台 ID 错误或 Mission 互相覆盖。
必须拆：按战区/兵种/任务类型分配给并行参谋 LLM，再合并为统一 atomic_tasks 包。
并行参谋 + 唯一写口
战区并行：东/西/空/海战区各启一个 LLM 实例，PromptOps 栈注入该区域 fusedId 子集与 ORBAT 片段——各管各的，避免 context 爆炸。
WPF 蜂群为唯一写口：合并后的 atomic_tasks 只能 POST 至 WPF :5000，由 Swarm 分解为 TacticCommand，再经 NamedPipe 落地 Command——INV-01 不变量，浏览器/Gradio 不得绕过。
执行链五步
① 各战区 LLM 输出 atomic_tasks JSON → ② MultiLLMCoordinator merge（去重 fusedId、冲突 priority 裁决）→ ③ POST :5000 WPF API → ④ Swarm 战术分解 → ⑤ TacticCommandMapper → NamedPipe → Command Mission。
merge 阶段强制执行 PromptOps L5 校验：schema、条令 whitelist、禁 dual-push。
fan-in 合并 · fan-out 蜂群
fan-in：多战区 LLM 并行写 atomic_tasks，Coordinator 合并为单一计划包。fan-out：WPF Swarm 按战术单元分解，NamedPipe 并行写入 Command——全程不经浏览器。
合并规则与写口纪律
MultiLLMCoordinator 合并语义
各战区 LLM 返回的 atomic_tasks[] 经 Coordinator 做三件事：去重——同一 fusedId + task_type 保留 priority 最高者；冲突裁决——互相矛盾的 strike/escort 对，按 ZSSC 条令 priority 与 opMode 策略选留；schema 校验——未通过 PromptOps L5 的条目整包拒绝，不回退到「部分执行」。
POST :5000 与 INV-01
WPF 宿主进程监听 :5000 REST API，是唯一允许创建/修改 Command Mission 的写口。Gradio 参谋前端、Brain COP 按钮、MultiLLMCoordinator——任何执行路径最终都必须汇聚到此 POST。verify 脚本扫描 Command 侧 Mission 来源，若发现非 NamedPipe 写入即报 FAIL。这是 OpenNexus 安全与审计的核心不变量。
Swarm 与 TacticCommandMapper
合并后的 atomic_task 包进入 WPF Swarm 引擎：按 ORBAT 节点、武器挂载、航路约束分解为若干 TacticCommand 单元——每个单元对应 Command 可执行的最小 Mission 片段。TacticCommandMapper 负责 DBID 实例化、Doctrine 条令绑定与 NamedPipe 帧格式序列化。train 模式 Swarm 自动 dispatch；live 模式进入 pending 等人审（见 LVC 专题页）。
与 PromptOps / 本体的咬合
执行链的输入质量由 PromptOps 约束栈保证（十种 atomic_task、ZSSC whitelist）；对象主键由 fusedId SSOT 保证（本体专题页）。MultiLLM 层不创造新语义——只做并行生成与合并，避免「多模型 = 多标准」的烟囱复发。