ARTICLE · 1096288
【连载1】面向 AI+ 兵棋 | 解密 System1:作为概率编程载体的 Jev‑like 族
第 0 章｜范式变革：兵棋 AI 为什么不能只接入 LLM，还需要概率编程内核载体
第 1 章 | 理念与定位
第 2 章 | 模型架构的数学原理
第 3 章 | 概率与置信度计算
第 4 章 | 结构化决策映射
第 5 章 | 置信度校准与训练（RLCD）
结束语
2026 年 9 月，AI 开发者社区发生了一件很有标志性的事件。9 月 15 日，TypeSafe AI 对外发布闭源 API 产品 Jev，它不做对话、不写文稿，放弃了主流大模型赖以生存的文本生成能力，主打面向结构化任务的快速概率研判，上线之后迅速在技术圈内传播开来。仅仅三天之后，ConvAI Innovations 就发布了遵循 Apache‑2.0 协议的开源对等实现 Laya。两套产品对外暴露完全一致的调用接口，内核遵循同一套 System1 技术范式，由此构成了我们所说的 Jev‑like 软件族。
很多人第一眼把它当成又一款分类模型，但剥开外壳之后会发现，它真正的定位，是一套概率编程内核载体。放到兵棋 AI 接入这个具体场景下，这套新范式带来的启发值得我们认真审视。
兵棋推演的运行环境本身就充满不确定性。侦察信息残缺、对手存在欺骗行为、态势要素错综复杂，大量研判任务本质上是在处理不完全信息。现在行业内很普遍的做法，是直接把 LLM 生成式大语言模型作为兵棋系统唯一的 AI 内核。可这条技术路线在实际落地时，会暴露出很难绕开的固有短板。
LLM 的目标是输出完整自由文本，想要拿到研判结果，只能依靠提示词约束输出 JSON，再由程序做解析提取。模型给出的置信度并没有经过严格概率校准，输出的数字只能作为参考，不能直接喂给兵棋推演或者蒙特卡洛不确定性分析模块。反观传统的概率编程方案，例如手工搭建贝叶斯网络，又需要专家逐条编写条件概率表，很难直接消费侦察报文、态势描述这类非结构化文本，维护成本居高不下。纯规则系统泛化能力有限，普通强化学习更偏向输出动作，拿不到可审计、可复用的中间研判概率。
因此，兵棋 AI 系统不应当只接入生成式 LLM，需要双内核架构。LLM 负责文本生成、方案撰写、开放式构想；而 System1 作为专门的概率编程内核载体，可以专门承担原子化的不确定性态势研判，输出经过校准的后验概率分布。
Jev‑like 软件族的深度参与者 Nandakishor 早在 2025 年就先后发了两篇 arXiv 预印本，完成了前期思想验证。
第一篇 arXiv:2502.12876 ，题目是Continuous Learning Conversational AI: A Personalized Agent Framework via A2C Reinforcement Learning。论文提出把决策信号和自然语言生成进行解耦，智能体不一定非要输出文本，完全可以直接输出内部决策表征。但原型版本没有抽象出通用概率原语，训练也没有使用严格恰当评分规则，输出打分缺少统计校准，距离工程可用的概率编程载体还有明显差距。
第二篇 arXiv:2503.23303 ， SalesRLAgent: A Reinforcement Learning Approach for Real‑Time Sales Conversion Prediction and Optimization。这篇在真实业务环境完成验证，证实放弃文本生成、直接输出概率的方案，工程效果优于 LLM 加提示词的基线。但它属于垂直场景定制模型，没有提炼出 Choice、Noulli、Score 这一套通用原语，也没有通用的温度缩放校准体系，并不具备通用概率编程运行时的完整能力。
综合来看，两篇预印本证明了「跳过生成、直接输出决策概率」这条路走得通，却没有补齐通用抽象和概率校准两块关键拼图。而后续发布的 Jev‑like 软件族，正是把这两块短板补上，做成了可以拿来直接调用的概率编程载体。
LLM 对应的是 System2 慢思考模式，依靠串行逐 token 自回归生成，擅长开放式文稿撰写、推演方案构思、开放式问题求解。但这套机制并不适合大批量、高频次的原子概率研判任务。
Jev‑like 则对应 System1 快思考模式，依靠双向编码器完成单次前向传播，接口返回字段里 output_tokens恒等于 0，全程不做任何文本生成。它以概率编程载体的身份对外提供 Noulli、Choice、Score 三类原子概率查询原语，直接返回经过校准的概率分布。
从概率编程的视角看，System1 并不是普通的深度学习分类器，它更像一个运行时环境。三类原语就相当于它的查询语句，上层业务编排好查询条件，送入模型之后，直接消费返回的后验分布。
综合来看，在兵棋推演场景中，AI + 兵棋同时接入 LLM + System1，二者能力互补，可以共同完成兵棋推演链条当中开放式生成、原子概率研判、不确定性推理的完整工作流。
第一步： LLM 承担开放式侧的全部工作
第一，生成研判所需要的候选假设集合。System1 只能在给定候选集合之内做概率查询，不会自己发明新假设，候选假设的构思、枚举由 LLM 完成；第二，处理非结构化原始情报，解析侦察报文、自然语言态势描述；第三，高层任务规划，编排需要执行哪些概率查询，组装送入 System1 的 state 状态信息与 questions 查询集合；第四，把上层模块输出的推理结果，翻译、整理为可读的推演报告与自然语言解释。
第二步：System1 承担概率侧的查询工作
接收上层编排完毕的状态数据与查询原语，执行 Noulli、Choice、Score 三类原子概率查询，原生输出经过温度缩放、RLCD 训练校准后的完整概率分布，再把结构化的研判结果回传给上层系统，供给主动推理模块、结构因果模型、仿真计算模块消费。
整套协同的完整逻辑链条是概念层面的流程，不存在我们自行编写的业务实现，全部组件接口逻辑来自仓库文档：
LLM 或者兵棋上层调度模块解析原始情报，生成研判候选假设，组装 state 状态与 questions 查询集合；
将查询送入 System1，执行批量概率查询，拿到一整套校准后的研判概率分布；
研判概率输出给上层：一方面流入主动推理模块做不确定性评估，另一方面作为软证据输入结构因果模型 SCM；
上层模块产出指挥员关键信息需求、因果查询结果；
再交由 LLM 转化为自然语言推演材料，完成一轮循环迭代。
从 Laya 仓库原始文档中，我们可以找出两条非常关键的边界：第一，System1 不会生成不在候选列表中的假设，候选集合必须由外部模块输入；第二，System1 只做条件概率查询，本身不执行因果推理，因果图结构、干预规则仍然需要兵棋领域专家预先定义。
第三步：研判概率支撑兵棋语境下的主动推理
主动推理的核心思想，就是系统不能一味被动接收情报输出结论，而是要能够识别自身研判的不确定性，基于不确定性提出信息收集需求，指导下一步信息获取。
System1 输出的不只是一个最大概率结论，而是完整的概率分布，同时提供经过校准的 answer_confidence 指标。上层模块就可以基于这套结果，量化当前研判的不确定程度：计算概率分布的熵，读取 answer_confidence 最大置信度。
当 answer_confidence 低于业务设定阈值，代表各个竞争假设之间区分度不足，研判不确定性很高。此时系统就可以生成关键信息需求，明确需要补充哪些情报来区分相互竞争的假设。当获取新情报之后，更新系统状态，再次编排查询送入 System1，迭代更新整套研判概率分布。
整个过程所依赖的底层算子，就是仓库内置的 answer_confidence、confidence_from_probs 两个函数。confidence_from_probs 输出的熵型集中度指标语义在不同原语之间并不统一，跨研判任务做置信门控，只能使用 answer_confidence ，不能使用熵计算得到的 confidence 。
第四步：研判概率作为结构因果模型 SCM 的软证据输入
在兵棋相关的因果建模工作当中，传统结构因果模型 SCM 经常会遇到一个现实阻碍：很多关键态势变量属于潜变量，无法直接观测。传统 SCM 大多只能接收布尔确定观测或者单点先验概率，很难直接消化来自侦察、态势研判带来的整套不确定性分布，先验值往往只能依靠人工经验填写，主观成分很重。
System1 在这里扮演的角色，就是为 SCM 提供软证据分布。二者分工边界非常清晰：
System1 负责条件概率查询：针对无法直接观测的潜变量，基于兵棋态势、情报状态输出后验概率分布；这一步只做条件概率计算，不涉及任何因果运算；
SCM 接收这套完整概率分布作为软证据，完成内部信念更新；之后就可以执行三类经典因果运算：普通观测推理、do(·) 算子干预推理、反事实推演；
SCM 输出的节点后验结果，可以反馈回上层调度，用于下一轮状态与查询的构造，形成闭环。
System1 不会生成因果图，图的结构、干预规则依旧需要兵棋领域专家定义。System1 解决的瓶颈，是给 SCM 供给来自非结构化态势、侦察报文的可信软证据，而不是替代因果建模本身。
但我们必须客观看待 System1 的能力边界，它不是万能的，不会凭空创造假设，也无法自动完成因果推演；如果兵棋系统只搭载 System1，就会缺失开放式构思、自由文本理解、报告生成这类能力。反过来，如果只接入生成式 LLM，又很难拿到可直接用于仿真推演、不确定性分析的校准后概率。
因此，兵棋 AI 更合理的技术路线，并不是二选一，而是构建 LLM + System1 的双内核协同架构。两个内核各司其职，分工配合，把开放式生成、概率查询、上层推理环节串联起来。
这套实践，为依托嵌入结构因果的主动推理框架（Causal AIF）搭建理想兵棋系统 “博望定远架构” ，完成了关键技术验证。
（未完）
在后续连载中，我们将以 Laya 源码为基础，进一步解读 Jev-like 软件族的关键思想与技术。为简化论述，我们省略了分层结构与数据流、多语言路由机制、短名单与嵌入相似度、推理加速路径、Hook 生命周期等内容，专注于模型框架的数学原理，也不关注 Jev-like 软件族生态之间的性能比较。文中代码的提取、解读与绘图，部分使用 Qwen3.8-Max 专家团完成。