企业官网建设流程全解析

给 Agent 装「判断器」：Laya 与 Jev 的 System One 路线横评，结构化判断、部署方式与选型决策表

【免费下载链接】jev-chat-jarvisThe chat decision assistant: before you reply, Jev reads the chat, judges intent and risk, and drafts replies you fill in with one tap. You press send. Android · Windows · macOS · iOS | 聊天辅助决策工具：先看懂对方再回复，发不发由你。项目地址: https://gitcode.com/gh_mirrors/je/jev-chat-jarvis

2026 年 9 月，TypeSafe AI 以 4000 万美元种子轮融资结束两年隐身，发布了「不生成文本、只做判断」的 System One 模型 Jev；几乎同一周，围绕同一路线还出现了另一条同样值得关注的开源实现 Laya。社区里把这类模型称作「智能 if 语句」：它不写代码、不写回复，只在封闭集合内输出选择、评分与真值估计，把 Agent 里最高频、最重复的判断从通用大模型上卸载下来。本文结合真实仓库源码（jev-chat-jarvis）与社区情报，逐项对比 Laya 与 Jev 在结构化判断、上下文传入、部署方式上的差异，并给出路由、RAG 排序、风险门控等场景的选型决策表。

一、同一个目标：把「判断」从「生成」里拆出来

传统 Agent 的决策链路是「大模型读上下文 → 生成一段文字 → 程序解析文字里的意图」。这条链路有两个已知痛点：一是慢，二是贵，三是不可控——模型在回答问题时顺便把答案写成了散文，判断结果只能靠解析 prompt 输出里的关键词来还原。

Jev 的路线是彻底砍掉「生成」这一步。它的请求体只包含state（上下文状态）和questions（问题集），每个问题被显式声明为三种类型之一：

• noul：是非判断（是/否），返回带概率的真值估计；
• choice：封闭集合选择（如从 6 个意图里选 1 个），返回每个选项的概率分布；
• score：分级评分（如 1–9 的危险等级），返回分数与置信度。

响应不是一段文本，而是一个结构化 JSON——choice带probabilities，score带legend与confidence。判断结果可以直接进程序逻辑，不需要任何 NLP 解析层。这正是社区把它称为「智能 if 语句」的原因：if (jev.should_reply_now == 0.97) { … }。

Laya 走的是同一条 System One 路线，但它把「结构化」的粒度放在了另一层：不是由远端模型保证输出格式，而是通过本地的结构约束层把输入状态整理成统一 schema，再交给后端做封闭集判断。换句话说，Laya 的卖点是「判断之前的状态规整」——把散落在各处的上下文（用户输入、工具结果、历史记录）折叠成可判定的结构；Jev 的卖点是「判断之后的输出规整」——无论问题多开放，都折叠成选择/评分/真值三类结果。二者在工程语义上是互补的，但在架构选择上分道扬镳。

二、结构化判断能力对比：题目集设计与置信度语义

Jev 的能力边界由「题目集」决定。以本仓库为例，cn/tools/jev/questions.py 定义了一套固定 7 问的判断题目集，覆盖聊天辅助决策的全部关键判断：

关键设计点在于每个 choice 的 criteria 都是封闭枚举的：例如true_intent明确写到「如果对方在测试你是否记得某事，即使措辞像请求也要选confirm_you_care」「分手、删好友、别跟我说话属于vent_anger，永远不是close_topic」——判断规则不是靠模型临场发挥，而是由调用方把领域知识编码进题目。这带来两个直接结果：一是结果可校验（概率分布可进断言），二是题目集本身是可校准的资产。仓库里配套了 cn/tools/jev/calibrate.py，用一个带标注的labeled_set.json批量跑题、生成校准报告，报告里区分 noul/choice/score 三类键分别统计——这是把「判断质量」当工程指标来管理，而不是当玄学。

Jev 的置信度语义也非常明确：choice返回每个选项的独立概率，score返回置信度，noul返回0..1的真值估计。消费方可以设定阈值（比如danger_level >= 8或tension_resolved < 0.5时拦截自动回复），把「风险判断」变成可配置的护栏参数。

Laya 在这方面的差异在于：它对评分类判断的建模更接近「分层回归」——同一问题可以附带多层级的评分标准，且评分结果按层聚合；而 Jev 的score是单题单轴（一个 1–9 或 1–10 的轴）。如果你的场景需要「多维度拆解后加权」（例如同时评估相关性、时效性、权威性三个维度再合成排序分），Laya 的分层模型更贴合；如果只需要单轴阈值判断，Jev 的模型更省 token、延迟更低。

三、上下文传入方式：state 的形态就是架构的形态

这是两条路线差异最明显的地方，也是选型时必须先回答的问题：你的上下文长什么样？

Jev 的请求模型是state + questions二元组。本仓库 Android 端在 cn/app/src/main/java/com/jev/probe/jev/JevQuestions.kt 的buildState()中给出了一个生产级的 state 形态：

val chat = JSONObject() .put("relationship", relationship) .put("messages", msgs) // 最近 10 条，每条约 {from, text} .put("latest_from", latestFrom) // "me" / "other" val state = JSONObject().put("chat", chat) // 可选扩展：background（关系+联系人备注+知识库命中） // 可选扩展：history（去重后的历史消息）

注意两个细节：

1. 消息只取最近 10 条——snapshot.messages.takeLast(10)，上下文预算被显式压缩到判断所需的最小窗口；
2. 扩展字段按需携带——background（关系描述、联系人备注、知识库命中笔记）和history（去重历史）只在非空时写入 state，且带字符预算上限：ContextBuilder（cn/app/src/main/java/com/jev/probe/core/kb/ContextBuilder.kt）里BUDGET_CHARS = 1500，超过预算先丢最旧历史、再丢整条笔记，绝不发半条。

更讲究的是失败降级：JudgeClient.postDecisions()（cn/app/src/main/java/com/jev/probe/jev/JudgeClient.kt）在携带background/history的请求遇到 4xx 时，会去掉这两个字段原样重发一次——「一个未验证的字段最多降低分析质量，但绝不打断分析」。这是对上下文扩展最稳妥的工程姿态：新特性可灰度、可回退。

Laya 的上下文传入方式则相反——它是「先给你一个 schema，再让你填」。调用方需要把上下文按预定义的字段结构组织（对话消息、候选动作、工具结果分别归位），再一次性提交；判断结果与 Jev 同样结构化。差异的实质是：Jev 把「上下文规整」的自由留给调用方（你的 state 想怎么拼就怎么拼，只要 questions 对得上），Laya 把「上下文规整」的约束收进框架（字段不齐可能直接判不了）。如果你有高度定制化的领域状态（比如本仓库的聊天快照 + 知识库命中 + 联系人档案），Jev 的自由度更友好；如果你的上下文天然规整（比如标准的多轮对话、标准动作集），Laya 的约束反而能帮你尽早暴露缺字段的问题。

四、本地部署与大模型接入：两条完全不同的路径

社区情报里大量讨论 Jev 的「本地部署」，需要先澄清一个事实：Jev 官方模型本身不是本地权重，它是一系列兼容网关背后的托管模型。真正「本地化」的是接入方式——协议是公开的POST /v1/systemone（OpenRouter 上是alpha/decisions），任何本地网关都可以按同一协议代理。本仓库的设置页（cn/app/src/main/java/com/jev/probe/SettingsActivity.kt）和 Prefs.kt 把这条接入矩阵完整暴露了出来：

这是「判断层」的接入。值得注意的是，本仓库把 Agent 拆成了两条独立路由：判断走 System One（Jev），生成走 OpenAI 兼容的 chat/completions（默认 DeepSeek 起草候选回复、Jev 再给候选排序）。JevClient.draftAndRank()（cn/app/src/main/java/com/jev/probe/jev/JevClient.kt）把这两条路由编排成一个原子操作：先让生成模型起草 N 条候选，N>1 时再让 Jev 选最优。这正是「快与慢」混合架构的落地形态——快系统（Jev）负责门控与排序，慢系统（大模型）负责真正需要创造力的生成。

Laya 的部署方式走的是真正的本地优先路线：其判断引擎可以作为本地库/服务进程内嵌（支持 macOS/Windows 本地运行），大模型接入则通过 OpenAI 兼容接口对接任意供应商。也就是说：Laya 允许你把「判断器」当作一个本地组件随 Agent 一起分发（无网络依赖、无外部计费），而 Jev 的接入天然是远端 API 形态（除非你自己搭 TypeSafe 兼容网关做代理）。如果你的约束是完全离线（内网、涉密、无外网计费通道），Laya 的本地方案有实质优势；如果接受「按量计费、毫秒级远端响应」，Jev 的接入成本更低——填一个 baseUrl + 一把 key 即可，仓库甚至为每个预设内置了连通测试按钮。

另外一个易被忽略的部署差异是密钥与数据边界。Jev 路线的密钥处理很成熟：Prefs把密钥存 App 私有 SharedPreferences，日志只记录长度、绝不记录内容；judgeKey / replyKey / visionKey三把密钥可独立配置，留空自动继承。Laya 本地部署则把「数据不出设备」作为默认假设——没有密钥就没有外传面。选型时要诚实评估自己的数据敏感度：聊天内容、关系描述、知识库命中都会随判断请求发给服务商（本仓库在 cn/PRIVACY.md 中明确声明了这一点），而本地部署可以把这个外传面压到零。

五、选型决策表：路由、RAG 排序、风险判断

综合上面的对比，把结论落成一张可直接抄的决策表：

针对三类典型场景的具体建议：

① 模型路由与工具门控（高频、低延迟敏感）场景：决定一个请求该走哪个模型、一个工具调用该不该放行。这类判断 QPS 高、上下文短、答案必须是 0/1 或少数几选一。Jev 路线更合适——公开协议下可自由切换免费档模型（jev-1.13-free），配合概率阈值做硬门控；本仓库把noul类问题（should_reply_now、tension_resolved）当护栏用的做法，可以直接平移到工具风险门控上。选 Laya 的唯一理由是极端离线环境。

② RAG 排序（上下文较长、需反复重排）场景：对候选文档/候选回复排序。Jev 的做法是把 N 个候选直接编码进 choice 的 criteria（本仓库rankQuestion()正是把三条候选回复作为reply_a/b/c的判定项），让判断模型在候选间做概率比较——候选数量少（3–5 个）时这是最优解，一次请求出排序。但如果候选量大（几十上百）需要分层粗排+精排，Laya 的多层评分模型可以少写不少分桶逻辑。要点：候选少用 Jev，候选多、要分层时用 Laya。

③ 风险判断与内容拦截（低频、高成本敏感性）场景：需要人工标注校准、结果要可审计。这是本仓库的主战场——聊天风险判断（danger_level1–9、意图分类）就是最典型的风险门控。选 Jev 的关键理由是题目集可校准：仓库用 cn/tools/jev/calibrate.py 对标注集批量跑题生成报告，判断质量是持续迭代的工程资产；同时概率输出让拦截阈值可配置、可复盘。若项目要求判断逻辑全部本地可复现（审计、合规），则转向 Laya。

六、落地形态参考：一个完整的分层 Agent 样本

如果你不确定「判断器」在真实 Agent 里到底怎么排布，本仓库是一个可以直接照抄的样本：聊天采集（无障碍/OCR）→ Jev 判断（7 问一次请求）→ 大模型起草 3 条候选 → Jev 排序 → 悬浮窗展示 → 用户确认后填入。整个链条里，Jev 承担了全部「决定」环节——读什么、信不信、多危险、回不回、怎么回、哪条最好——而大模型只负责最后一公里「写字」。

对想给自家 Agent 装判断器的团队，最值得抄的三件事是：判断与生成的路由彻底分离（各自配 endpoint/model/key）、题目集作为可校准资产管理（而非散落在 prompt 里）、判断结果的概率语义贯通到业务阈值（如danger_level >= 8即拦截）。无论最终选 Jev 还是 Laya，这三条都是 System One 路线落地的共同底座。

【免费下载链接】jev-chat-jarvisThe chat decision assistant: before you reply, Jev reads the chat, judges intent and risk, and drafts replies you fill in with one tap. You press send. Android · Windows · macOS · iOS | 聊天辅助决策工具：先看懂对方再回复，发不发由你。项目地址: https://gitcode.com/gh_mirrors/je/jev-chat-jarvis