给 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-jarvis2026 年 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带probabilitiesscore带legend与confidence。判断结果可以直接进程序逻辑不需要任何 NLP 解析层。这正是社区把它称为「智能 if 语句」的原因if (jev.should_reply_now 0.97) { … }。Laya 走的是同一条 System One 路线但它把「结构化」的粒度放在了另一层不是由远端模型保证输出格式而是通过本地的结构约束层把输入状态整理成统一 schema再交给后端做封闭集判断。换句话说Laya 的卖点是「判断之前的状态规整」——把散落在各处的上下文用户输入、工具结果、历史记录折叠成可判定的结构Jev 的卖点是「判断之后的输出规整」——无论问题多开放都折叠成选择/评分/真值三类结果。二者在工程语义上是互补的但在架构选择上分道扬镳。二、结构化判断能力对比题目集设计与置信度语义Jev 的能力边界由「题目集」决定。以本仓库为例cn/tools/jev/questions.py 定义了一套固定 7 问的判断题目集覆盖聊天辅助决策的全部关键判断题目类型语义literal_questionnoul对方最新消息是否纯字面、无潜台词true_intentchoice6 类真实意图测试关心、发泄愤怒、请求行动、寻求解释、闲聊、收尾danger_levelscore1–9 级冲突/关系危险度should_reply_nownoul下一条消息是否应包含实质内容best_actionchoice7 类最佳动作查历史、道歉、承诺、解释、认同、少说、定计划she_needschoice对方此刻需要什么道歉/行动/解释/关心/无事tension_resolvednoul关系张力是否已解除关键设计点在于每个 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去重后的历史消息注意两个细节消息只取最近 10 条——snapshot.messages.takeLast(10)上下文预算被显式压缩到判断所需的最小窗口扩展字段按需携带——background关系描述、联系人备注、知识库命中笔记和history去重历史只在非空时写入 state且带字符预算上限ContextBuildercn/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/systemoneOpenRouter 上是alpha/decisions任何本地网关都可以按同一协议代理。本仓库的设置页cn/app/src/main/java/com/jev/probe/SettingsActivity.kt和 Prefs.kt 把这条接入矩阵完整暴露了出来提供商预设端点模型备注OpenRouter…/api/alpha/decisionstypesafe/jev-1.13默认博查 Jevhttps://jev.bocha.cn/v1/systemonebocha-jev-v1协议同 TypeSafe限时免费TypeSafe 直连https://api.typesafe.ai/v1/systemonejev-latest官方直连Vercel AI Gateway…/v1/systemonetypesafe-ai/jev网关聚合OpenCode Zenhttps://opencode.ai/zen/v1/systemonejev-1.13输出免费输入 $0.042/M一次判断约 1000 输入 token这是「判断层」的接入。值得注意的是本仓库把 Agent 拆成了两条独立路由判断走 System OneJev生成走 OpenAI 兼容的 chat/completions默认 DeepSeek 起草候选回复、Jev 再给候选排序。JevClient.draftAndRank()cn/app/src/main/java/com/jev/probe/jev/JevClient.kt把这两条路由编排成一个原子操作先让生成模型起草 N 条候选N1 时再让 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 排序、风险判断综合上面的对比把结论落成一张可直接抄的决策表决策维度选 JevSystem One 托管/网关选 Laya本地结构化判断判断类型单轴 choice / score / noul封闭枚举同三类额外支持多层分级评分上下文形态自定义state自由度最高框架 schema 约束缺字段报错早上下文预算调用方自行压缩本仓库为 10 条消息 1500 字符预算框架内规整随 schema 自动裁剪延迟约 1 秒/次仓库实测口径毫秒级可重复调用本地进程内调用无网络 RTT成本约 $0.00004/次判断输入 1000 token输出免费档本地推理成本近似为零硬件自持部署远端 API 兼容网关OpenRouter/博查/TypeSafe/Vercel/Zen本地库/本地服务可完全离线大模型接入判断/生成两条独立路由各配各的判断本地化生成走 OpenAI 兼容接口数据边界上下文发送至所配服务商需评估隐私判断层数据不出设备针对三类典型场景的具体建议① 模型路由与工具门控高频、低延迟敏感场景决定一个请求该走哪个模型、一个工具调用该不该放行。这类判断 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考