让语义判断成为系统组件：Jev 与 Harness 架构集成实战

TypeSafe 最近放出的 Jev，让我重新打量起 Agent 系统里一类再普通不过的事——判断。

一段材料是否相关、一个动作有没有偏离任务、两次搜索是否只是在换一种说法。这些场景都需要理解语义，却未必需要生成一段解释，更不需要完整的推理链条。

Jev 正是为这类任务而生的模型。想理解它的价值，得先看看它和熟悉的生成式 LLM 到底差在哪里。

Jev 把"判断"直接做成了软件接口。

生成式 LLM 的基础工作方式是逐个生成 token。它既能分析问题、编写代码，也能通过结构化输出约束结果。既然现在 LLM 已经能按 JSON Schema 返回数据，Jev 的差异就不能简单概括成"终于可以稳定输出 JSON"了。

TypeSafe 在官方文档里介绍了另一条后训练路线：RLCD（Reinforcement Learning for Calibrated Decisions，面向校准决策的强化学习）。这条路线把决策及其概率校准直接作为训练目标。Jev 接收状态和问题，直接返回带类型的判断与概率，不产出回答、代码或推理解释。官方把这类模型称为 System One。

它提供三个基本接口：

接口	适合的问题	输出含义
Choice	这段材料属于哪一类？	一个选项，以及各选项的概率
Score	按明确标准，这段材料有多大价值？	各等级的概率，以及等级编号的加权平均
Noul	需要回答是或者否	"是"的概率

Choice 和 Score 还会返回 confidence，而 Noul 没有独立的 confidence 字段。

这里有两个容易混淆的地方。Score 是相对于你定义等级打出的分数，Noul 则代表某个命题成立的概率。noul = 0.8 不能理解成"完成了 80%"。同样，confidence 是根据概率分布形状计算出来的指标，也不要直接读成"正确率"。

概率校准关心的是：在足够多且可比较的预测里，那些被赋予 80% 概率的事件，实际发生比例是否真的接近 80%。它既不保证某一次判断正确，更不保证换到你的业务数据之后依然成立。

这比让模型在回答末尾写一句"我有 80% 信心"可靠得多，也更适合系统调用，但依然绕不开业务层面的评估。

Jev 的另一个特点是，同一份 state 可以同时回答多个问题。各问题独立评估，前一个回答不会成为后一个问题的隐藏上下文。官方称，增加问题对响应时间的影响很小，不过输入 token 仍会随之增加。

截至 2026 年 9 月 20 日，官方列出的价格是每百万输入 token 0.042 美元，输出免费；文档称多数查询约 100 毫秒完成。当然，这些都是官方口径，真实系统里还得算上网络、排队和重试带来的延迟。

由此可以推导出最适合它的任务形态：输入已经准备好，问题足够具体，答案范围可以预先定义，而且这类判断会被反复调用。

典型场景包括分类、候选项匹配、语义去重和按标准评分。至于复杂诊断、跨文件推理、生成修复方案，仍然得靠生成式模型；计数、日期比较和预算计算，则直接交给代码处理。官方也明确列出了 Jev 在数值精度、多跳关系和无关长上下文上的短板。

把这种任务形态放进 Harness，位置就变得非常清晰了。

Harness 是模型外围负责状态、工具调用、权限、预算和执行反馈的运行系统。其中有些判断可以靠精确计算完成，有些则必须理解内容本身。

比如"已经执行了五次"可以直接计数，但"这五次其实都在调查同一个方向"就需要语义判断了。后者正是 Jev 的候选职责。

Harness 中的位置	Jev 可以提供的信号	代码继续负责的事情
工具或 Skill 路由	当前任务与候选能力是否匹配	过滤不可用能力，检查权限，执行调用
Context 选择	材料是否相关、重复，是否直接支持某个判断	来源验证、原始记录、上下文预算
循环监测	新计划是否重复已有方向	次数、时间和费用上限，暂停与恢复
结果复核	某个具体结论是否得到给定材料支持	测试结果、版本一致性、成功条件

以上都是基于模型特性的架构建议。至于值不值得替换现有规则或模型，还得逐项验证。

以 Diagnose Agent 为例。它拿到一条新的 Observation 后，需要决定这条材料是否值得进入下一轮分析。如果把每条搜索结果都塞进上下文，后续模型就得不断重新处理重复信息。

调用之前，Harness 先检查剩余预算，并确认材料的来源和版本。随后 Jev 回答两个局部问题：它和当前假设是什么关系，以及它是否重复了已知材料。

下面是基于官方 Python SDK 的设计示例，展示的是接入位置，并不代表已经在我的系统里完成部署。

from typesafe_sdk import Choice, Noul

QUESTIONS = {
    ”relation”: Choice(
        instructions=”How does `candidate` relate to `hypothesis`?”,
        criteria={
            ”supports”: ”Explicit content directly supports the hypothesis.”,
            ”refutes”: ”Explicit content directly contradicts the hypothesis.”,
            ”unrelated”: ”Content does not bear on the hypothesis.”,
            ”unclear”: ”The relation cannot be determined from this state.”,
        },
    ),
    ”duplicate”: Noul(
        instructions=(
            ”Does `candidate` repeat information in `known_observations` ”
            ”without adding a new fact?”
        ),
    ),
}

state 只需要包含 hypothesis、当前的 candidate 和少量相关的 known_observations。比如说，假设是"连接池耗尽导致请求失败"，候选材料是一条等待数据库连接超时的日志。它可能支持这个调查方向，但单凭一条日志还不能证明根因。

两个问题可以在一次请求里完成：

from typesafe_sdk import RetryPolicy, TypeSafeClient, TypeSafeError

def judge_candidate(client: TypeSafeClient, state: dict):
    try:
        return client.system_one(
            model=”jev-1.13.0”,
            state=state,
            questions=QUESTIONS,
            timeout=1.0,
            retry=RetryPolicy(max_retries=0),
        ).answers
    except TypeSafeError:
        return None

这里固定了模型版本，避免别名更新之后判断行为悄悄发生变化。请求失败时返回"没有判断"，由后续流程接管。示例中的超时是 HTTP 操作超时；整个诊断步骤的截止时间仍要由 Harness 管理。

接下来，由代码解释这些信号：

def next_step(answers, *, budget_left: int) -> str:
    if budget_left <= 0:
        return ”pause”
    if answers is None:
        return ”review”
    relation = answers[”relation”]
    duplicate = answers[”duplicate”].noul
    if relation.choice == ”unclear” or relation.confidence < 0.8:
        return ”review”
    if 0.2 < duplicate < 0.8:
        return ”review”
    if duplicate >= 0.8 or relation.choice == ”unrelated”:
        return ”collect_elsewhere”
    return ”queue_for_verification”

阈值只是展示控制逻辑，不能直接当成生产配置。review 可以进入更强模型或人工复核；支持和反驳假设的材料都会进入验证队列。原始材料继续保存，筛选只影响后续处理顺序。

这个接口没有 succeeded。Jev 判断某条材料支持假设，只能说明它值得继续验证。根因是否成立，仍要检查证据链和必要的复现结果。

还要注意，同一请求中的问题独立评估，不代表这些事件在统计上相互独立。不能把"支持概率"和"不重复概率"直接相乘，就当成了最终诊断可信度。

类似地，Jev 可以为工具调用提供风险提示，但权限仍需由代码强制执行。官方明确说明，对抗性内容可能影响它的判断。不生成文本，并不意味着不会受到输入内容的误导。

接入时，我会先让它旁路运行：记录判断，保持原流程不变，再用真实样本评估。证据筛选要看关键反证的漏筛率；循环监测要看是否误停了仍有进展的任务；路由要看错误选择带来的后续成本。同时记录模型版本、问题版本和阈值，才能解释行为为什么变化。

比较对象应该包括现有规则和 LLM 方案。最终要看任务成功率与每次成功任务的总成本：一次便宜的判断，如果引发三轮无效搜索，未必真的省钱。

对中文日志和中英混合材料，还要单独测试。官方说明目前英语表现最好，其他语言不能直接沿用英语评估结果。

我认为 Jev 值得关注的地方，在于它让我们可以更细地拆分 Agent 系统中的认知工作：生成式模型负责探索和解释，Jev 承担边界明确的语义判断，代码则把这些判断组合进受约束的流程。

这也会改变 Harness 的设计重点。每一个需要理解语义的分支，都可以被单独定义、记录和评估。哪些值得自动处理，哪些必须补充信息，哪些需要升级，不再全部藏在一次模型调用里。

判断变便宜以后，工程师更需要把判定条件、错误代价和验证方式定义清楚。它们决定了这些判断最终能承担多大的责任。在云栈社区的技术讨论中，这类模型与 Harness 的集成实践也值得持续关注。