Jev 判定层深入
把类型化判定与决策执行嵌进 LLM CLI

🎯一句话判断：CLI 回路上的判定原语，不是回路的大脑

📡交互契约：一次 POST = 一个 state + 一组并行问题

整个交互方案只有一个端点：POST https://api.typesafe.ai/v1/systemone，携带 Authorization: Bearer $TYPESAFE_API_KEY。请求体三个字段：state（字符串、JSON 对象或文本数组，约 64k token）、model（如 jev-latest）、questions——一个 id → 类型化问题的映射。响应把答案按相同 id 放回 answers，外加 usage.input_tokens / output_tokens。

{
  "state": "客户三天的 Stripe 集成一直失败，正在丢单，请尽快处理",
  "model": "jev-latest",
  "questions": {
    "department": {"type": "choice", "instructions": "哪个团队处理",
                   "criteria": {"billing": "支付订阅问题", "technical": "bug 与集成问题",
                                "sales": "价格与账户问题"}},
    "frustration": {"type": "score", "instructions": "客户的挫败程度",
                    "criteria": ["平静陈述", "不满但克制", "强烈愤怒"]},
    "is_urgent":   {"type": "noul", "instructions": "消息是否传达紧迫性"}
  }
}
→ answers: department={choice:"technical", confidence:0.78, probabilities:{…}},
           frustration={score:1.0, confidence:1.0, probabilities:{…}},
           is_urgent={noul:1.0}   + usage{input:392, output:65}

两个交互设计决定了它在 CLI 回路里的形态：

• 并行扇出近乎免费。一次调用里塞多个问题是官方鼓励的用法（speculative fan-out）：官方 parallel-questions cookbook 把 13 个问题打进一次请求，相比逐个调用便宜 12.2 倍、快 10.0 倍，且答案不变。这意味着每个回路分叉点都可以「顺手多问几个」——主问题做路由，旁路问题做审计与日志特征，不产生额外往返。
• 无会话、无生成。Jev 不流式输出、不持有对话状态、不调用工具；CLI 每轮需要什么判定就构造什么 state 发什么问。SDK 侧 TypeSafeClient 与 AsyncTypeSafeClient 对偶提供，Python ≥3.10 直接 pip install typesafe-sdk。

🧱判定原语速查：三种类型化答案与置信度

置信度不是「另一个概率」：choice/score 的 confidence 由概率分布的形状坍缩而来——质量全压在一个选项上趋近 1.0，摊平则趋低。这是第二根决策轴：答案告诉你「是什么」，置信度告诉你「敢不敢执行」。官方推荐三档：高置信自动执行、中置信确认或补证据、低置信路由给人或回退默认路径——阈值随出错代价升降。Noul 没有这个字段，0.5 附近就是真正的不确定，代码要自己设阈值。

🔀分层架构：判定归 Jev，决策执行归代码，生成归 LLM

把 Jev 装进 llmcli 的本质是一次职责重排。原回路里 LLM 身兼三职：读懂语义、做判断、生成动作；这导致判断不可归因、解析易碎、置信度无从谈起。嵌入 Jev 后三层各司其职：

这个三层分工也是官方四个架构模式的自然组合：speculative fan-out（一次扇出多问）、confidence-gated routing（置信度作第二轴）、composite scoring（原子分按代码权重合成）、intent routing（分类后分派给确定性逻辑 / 专家 LLM / 人）。四种模式在 CLI 上各对应一个挂载点，见下节。

🪝llmcli 回路上的六个挂载点

三个挂载点值得展开，因为官方 cookbook 给出了可直接复用的结构：

技能选择（progressive disclosure 版）。问题域很现实：CLI 把 skill 名册截成一行一条塞进系统提示词（Hermes 默认截到 60 字符），「编辑 pptx」和「撰写 pptx」看起来一样，agent 常加载错技能或在无匹配时硬猜。方案是两次请求：第一次用 choice 对全部 182 条索引扇出排序、并挂几个 noul 问「这一轮是否需要 skill」；第二次只把 top-3 技能换完整描述再选一次，仍可全部否决。胜出者只占系统提示词里一行建议位，名册本身不动、前缀缓存不破。

函数参数绑定。CLI 的工具大多是普通函数，签名里的 Literal 参数天然是封闭集：每个枚举参数一个 choice，每个布尔一个 noul，set 型参数对每成员一个 noul，开放参数（int、自由文本）根本不问、留默认值。官方 10 个交易函数展开成每条命令 54 个问题、一次请求完成；stated 型 noul（「用户提到了这个维度吗」）让未提及参数落回函数默认值。由此得到的是对签名天然合法的工具调用——没有 JSON schema 解析失败这回事。

级联升级（SDE cascade 模式）。小模型先做，Jev 判定结果是否可信，可信即返、不可信升级大推理模型——拿大部分质量只付小部分成本。这正是「判定与执行解耦」的经济学含义：判定层便宜且校准，才谈得上按置信度分配昂贵的生成预算。

📊实测证据：官方 cookbook 的四组数字

另两个值得记下的 cookbook：实体对齐（450 个候选对，一个 score 加三个伴生 noul 标出分歧字段）；层级分类（用 choice 概率做 beam search 走深专利/生物医学层级，正是并行判定的一个变体）。

💻决策执行层的代码骨架

判定层在回路里的调用点收敛成一个薄封装——构造 state、扇出问题、按置信度分派。示意骨架：

class DecisionGate:
    def __init__(self, ts: TypeSafeClient):
        self.ts = ts

    def route(self, state, questions, act_threshold=0.5,
              review_threshold=0.25, default="web_search"):
        """判定 → 置信度分级 → 执行映射，全部在代码里。"""
        ans = self.ts.system_one(state=state, questions=questions).answers

        route = ans["route"]                      # Choice 答案
        if route.confidence >= act_threshold:
            return route.choice                   # 高置信：直接执行
        if route.confidence >= review_threshold:
            return self.confirm_or_gather(state, route)  # 中置信：确认/补证据
        return default                            # 低置信：回退默认路径

# 单轮回路 = 判定点串联，生成只在真正需要处发生
def agent_turn(req):
    gate.route(state=req, questions={
        "route":   Choice("该请求适合哪条处理路径", criteria=ROUTES),
        "skill?":  Noul("本轮是否需要加载某个技能"),
        "harmful": Noul("该请求是否要求破坏性操作"),
    })
    # harmful.noul > 0.3 → 走人工确认；skill? → 触发二次精读；route → 分派

三条工程纪律从官方文档直接推出：原子问题——一问一次直觉判断，多因子拆成多问题由代码加权；criteria 承担语义——每个选项/层级/真假判定都写描述，裸标签表现显著更差；置信度门槛随代价分层——不可逆动作（删库、发邮件、跑湿实验队列）用最高档阈值。

🔬AI4Science 应用：科学智能体的判定层

上篇已经论证过 Jev 在 AI4Science 的定位是「判断层而非生成层」。结合本篇的 CLI 嵌入视角，判定层对科学智能体的价值集中在回路的可控性上——科学管线的每步都有「该不该继续」的门：

⚠️jev-1.13 锯齿边界与 CLI 侧对策

共同主题一句话：判定给 Jev、算术与生成给代码和 LLM、阈值随代价分层——这既是官方建议，也是把这层嵌进 CLI 后仍可控的原因。

🔗与 RRSI 的连接：判定层是可演化 harness 的组件

把本文与上一篇 RRSI 报告放在一起看，关系很直接：RRSI 的组件词表里 client_tool 与 control_flow 两类正好对应 Jev 判定的两个挂载方式——作为可调用的判定 API 工具，和作为控制流分叉的守门逻辑。类型化判定对演化 harness 还有个隐性好处：可归因性。harness 分叉依赖「LLM 返回 JSON」时，一次错误路由无法归因是模型判错还是解析出错；换成带概率分布的类型化判定后，每个分叉点都有可回放、可统计的数字证据——演化器的分析师模块可以直接消费这些日志特征。判定的确定性本身就是 harness 可演化性的前提之一。

📚来源与核验说明

• 交互契约：docs.typesafe.ai/introduction/quickstart（端点、请求/响应字段、SDK 用法，2026-09-29 抓取）；API 端点与字段与 typesafe-ai skill 文档一致。
• 边界声明：docs.typesafe.ai/introduction/coding-agents（Jev 非 CLI 主模型替代）。
• 置信度语义：docs.typesafe.ai/confidence（confidence 由分布形状坍缩、三档执行建议）。
• 实测数字：cookbooks/skill_suggestion（182-skill、488 请求、16.8%→7.3% 与 9.8%→4.0%）、cookbooks/function_calling（10 函数 54 问/命令）、cookbooks/parallel_questions（12.2×/10.0×）、cookbooks/rerank_typesafe（5%→18%、38%→62%）。均为官方发布的实验结果，非本站复现。
• 失效模式：docs.typesafe.ai/model-jaggedness/jev-1.13（2026-09-17 审阅版）。
• 前篇：《Jev 与 TypeSafe System One：AI4Science 工作流中的可编程判断层》（三原语、state 设计、四条 AI4Science 管线策略，本篇不重复展开）。
• 证据边界：skill/CLI 挂载点的数字来自官方 cookbook 在其既定 harness 与模型组合上的测量；迁移到自定义 llmcli 需重测阈值。AI4Science 节为架构迁移分析，非生物基准实测。