判断引擎落地 .NET 的四条路线、一个客户端与一份生产样本 - 张善友
内容提要
2026年9月，Jev、Laya等决策模型将“判断”从生成中剥离为独立基础设施：一次前向传播返回带概率的选项、分数或布尔值，答案空间预先锁定，并用RLCD训练校准置信度，高置信度自动执行、低置信度转人工。.NET生态随后跟进，出现NLaya、layar两个移植版，TensorSharp、Sezika两条原生路线，以及统一客户端SystemOneSharp。OpenClaw.NET的PR #246与#255演示了接入生产所需的校准、影子模式、回滚等护栏，最终收敛为纯.NET技术栈。核心规律：成本优势上限等于弃权率的倒数。
延伸解读
判断引擎的构造性保证与校准前提
文章指出，判断引擎将答案空间在调用前锁死，模型只负责在约束内填概率，因此不可能返回错误类型或畸形结构，这是构造性保证。但合法不等于正确，模型仍可能判错。校准过的置信度才是进生产的前提，Jev和Laya用RLCD训练，奖励函数为严格proper scoring rule，使模型诚实报告概率。代码可基于置信度阈值自动执行或转人工，这才是决策模型的产品形态。
Laya的零样本局限与成本优势上限
Laya虽开源且接口对标Jev，但其model card明确：零样本typed-decisions准确率仅0.362，低于多数类基线0.461；逐题型重拟合温度后平均ECE从0.466降至0.081。项目方称其为可快速特化的底座，非开箱即用引擎。此外，成本优势上限等于弃权率的倒数，若有30%判断回退大模型，整体最多省3.3倍。自托管只省单价，不省弃权。
四条.NET引擎路线的分层使用思路
文章对比了四条路线：NLaya和layar是移植版，TensorSharp和Sezika是原生实现。NLaya走生态全家桶，layar精简内核并对比ONNX与TorchSharp性能；TensorSharp用26B扩散模型单步读取，Sezika用小编码器加决策头。四者接口契约几乎一样，可分层使用：小引擎做高频路由和初筛，拿不准或需看图、常识的再交给大引擎或大模型，小引擎守门口，大引擎做终审。
生产接入的护栏与OpenClaw.NET样本
OpenClaw.NET的PR #246演示了接入生产所需的护栏：版本化rubric、脱敏、影子模式、校准ID强制匹配、回滚配置等。PR #255进一步将本地Laya服务从Python迁移为.NET 10 + NLaya，使引擎、服务、校准、评估、报告收敛到纯.NET栈。文章强调，接入门槛不在API，而在敢不敢信；校准、兜底、日志、回滚等五件事绕不开，清单是态度，护栏是实现。
Q&A
判断引擎和传统大模型调用有什么区别？
判断引擎将“判断”从生成中剥离，一次前向传播返回带概率的选项、分数或布尔值，答案空间预先锁定，没有逐token采样和JSON修复；而传统大模型调用需要生成整段文本并祈祷格式正确，容易出错和重试。
Jev和Laya在训练和校准上有什么关键设计？
两者都用RLCD（Reinforcement Learning for Calibrated Decisions）训练，奖励函数是严格proper scoring rule，使模型诚实报告概率时期望奖励最大。因此代码可根据置信度阈值自动执行或转人工，如conf >= 0.85自动路由，否则升级。
在.NET中接入判断引擎有哪四条路线？
四条路线包括：两个移植版NLaya（TorchSharp + ONNX Runtime）和layar（ONNX Runtime + TorchSharp），以及两个原生实现TensorSharp（基于26B扩散模型单步读取）和Sezika（小编码器加决策头）。
SystemOneSharp客户端的作用是什么？
SystemOneSharp是一个.NET 10的System One API类型化客户端，零运行时依赖，统一调用云端Jev和本地Laya服务器，只需更改BaseUri即可切换供应商，简化了接入不同判断引擎的流程。
OpenClaw.NET的PR #246和#255在生产接入中做了哪些工程护栏？
PR #246将Jev和Laya接入回合路由，设计了版本化rubric、脱敏管道、校准ID强制匹配、影子模式、回滚配置等；PR #255将本地Python服务迁移为纯.NET工具链，使用NLaya，统一了评估、校准和报告，实现全栈.NET。
判断引擎的成本优势上限由什么决定？
成本优势的上限等于弃权率的倒数。例如，如果有30%的判断需要回退给大模型，整体最多节省3.3倍。自托管只降低单价，不降低弃权率，因此ROI取决于用自有数据将弃权率压到多低。
