微信公众号运营助手 AGENT

HUMAN REVIEW

Jev 模型：Agent 的结构化判断层

FORMATTED

WECHAT PREVIEW

排版预览

FINAL MARKDOWN

人工终稿

# Jev 模型，Agent 的结构化判断层

Agent 的崩溃常发生在判断环节。TypeSafe 的 Jev 把结构化判断做成 Choice、Score、Noul 三个 API。本文讲清分工、概率与边界，并给出落地三步法。

## 为什么 Agent 需要一个结构化判断层

AI Agent 的崩溃常不在生成环节，而在判断环节。一句是否判断错，后面全盘皆错。2026 年 9 月，TypeSafe 发布 Jev System One，把它定位为旗舰模型，也是第一个 System One 模型。

System One 模型专门做快速、结构化决策，输入一个 state，返回类型化答案和概率。它更适合放在 Agent 流程里充当判断层，不负责长文本生成。Agent 把判断拆出来以后，格式、延迟和成本都更容易控制。

## 分诊台，state、Choice、Score、Noul 与置信度

可以把一次判断看成急诊分诊台。state 是桌上已有的信息，包括主诉、病史、检查结果。Choice 让模型从给定选项里选一个，返回选中项、每个选项概率和置信度，最多支持 255 个选项。Score 沿你定义的等级打分，可以落在两级之间，返回每个等级概率、置信度和图例，最多 10 级，分数按概率加权平均计算。Noul 回答一个是否命题，返回 0 到 1 的 yes 概率，不再单独给置信度，因为两结果的分布已经由这个数完全描述。

置信度由概率分布计算出来，不是模型额外输出的质量保证。常用做法是分成高中低三档，不同档位触发不同行为，阈值按风险和领域调整。低置信度时让 Agent 停下、转人工或走保守分支。Noul 的单一数字已经完整描述两个结果的分布，所以文档不再单独返回置信度。Choice 和 Score 则需要从多项概率分布里再抽出置信度。

[配图：图1 Jev 三原语的输入输出示意。state 承载上下文，Choice 返回选项与全概率，Score 返回分级位置与各等级概率，Noul 返回是否命题的 yes 概率。]
{{ARTICLE_ASSET:jev-primitives}}

## 责任切分，LLM、Jev、确定性代码与人工

在 Agent 架构里，LLM 负责生成候选内容和自然语言，Jev 负责结构化语义判断，使用 Choice、Score、Noul，确定性代码负责规则、格式和精确计算，高风险审批必须交给人。这样可以把生成失败和判断失败分开排查。

TypeSafe 文档把模型路由、LLM 护栏、语义代码检查、特征提取和实时应用列为典型场景。这些场景的共同点是，输入可序列化成 state，输出是少数离散判断，不要求大段文本生成。

模型路由是 Jev 的第一类落地位置。把 state 设为当前 prompt、目标模型列表和预算约束，用 Choice 从几个模型里挑一个，再把概率和置信度记进日志。低置信度时走默认模型或转人工。这样每个路由选择都有可回看的概率依据。

LLM 护栏可以放在大模型输出之后。先让大模型生成候选回复，再把用户原话、候选回复和预设规则打包成 state，用 Score 给风险等级，用 Noul 判断是否触发人工复核。Score 偏高或置信度偏低时，系统直接拦截。这样排查链路集中在结构化判断层，不用在大模型自由文本里追问原因。

[配图：图2 Agent 判断链分工示意。LLM 生成候选，Jev 输出结构判断，确定性代码做规则拦截，低置信度或高风险消息转人工。]
{{ARTICLE_ASSET:jev-agent-routing}}

## 落地伪代码，路由、分级与风控

下面是一个最小流程，state 只包含用户输入和历史。三种原语分别处理分诊路由、紧急程度和是否立即响应。代码是伪代码，不是可直接运行的 SDK 调用，字段名按 TypeSafe 文档语义描述。

```python
state = {
    "user_input": "我发烧39度，吃了退烧药还是头疼",
    "history": []
}

choice = jev.choice(
    state=state,
    question="该患者应转去哪个科室",
    options=["发热门诊", "神经内科", "在线复诊", "转人工"]
)

if choice.confidence < 0.6:
    route = "转人工"
else:
    route = choice.choice

score = jev.score(
    state=state,
    question="病情紧急程度",
    criteria=["轻微", "中等", "紧急", "危重"]
)

if score.score >= 3:
    priority = "立即处理"
else:
    priority = "常规队列"

noul = jev.noul(
    state=state,
    question="该患者是否需要在30分钟内获得医生响应"
)

if noul.probability > 0.8:
    trigger_alert()
```

代码里建议把阈值做成配置项，不要写死在条件判断里，灰度时可以直接调档。这样能先跑通最小闭环，再逐步收紧自动范围。

## 边界，结构不越界不等于语义正确

TypeSafe 声称 Jev 放弃了字符串生成、专注于结构化输出，且因为在返回前就定义好了可能输出和结构，模型不会犯类型错误。这个保证只覆盖输出格式。它不会让业务判断自动正确。一个 Choice 依然可能把重症分到低优先级，一个 Noul 依然可能给出错误的高概率。

官方也列出 Jev 1.13 的锯齿边缘。它擅长 System One 任务，但在字面阅读、数学和计数、日期与时间比较、间接推理、大段无关状态、对抗内容、相互矛盾的指令和常识性结构不变量上可能出错。早期接入不要把这些任务直接压给 Jev，精确计算交给确定性代码，语义判断只保留离散选择。

[配图：图3 Jev 1.13 已知局限分布。横轴为任务类型，纵轴为失败风险，标注数学计数、日期比较、长上下文、对抗内容等需要自测的区域。]
{{ARTICLE_ASSET:jev-limitations}}

## 公开数字、已知局限与生态现状

Jev 当前版本是 1.13，模型 ID 为 jev-1.13.0，jev-latest 和 jev-preview 都指向这个版本。价格按输入 token 计费，每十亿 token 42 美元，约每百万 token 0.042 美元，输出 token 免费。速率限制是每秒 25 万 token，每分钟 1200 次请求。上下文长度 64k token，其中 32k 给 state 加上最长 question，输入只支持文本，可以是字符串、JSON 对象或文本数组，不支持图片、音频和视频。

厂商博客还称，Jev 在 System One 任务上达到与现有 LLM 相当的智能水平，同时快两个数量级、效率更高，端到端响应 70 到 500 毫秒，某个工作流评测显示快 193.6 倍、便宜 444.6 倍。这些速度、价格和性能数字都是厂商公开数据，产品仍处于早期阶段。上线前应在自己的业务评测集上重测，不应直接采信。

还需要补齐中文效果、数学计数、日期比较、长上下文和提示注入的本地测试。文档没有单独给出中文效果数字，传统 LLM 的提示注入风险也不会因为结构化输出自动消失。对抗样本要当作独立测试集，不能因为输出是结构化就假设注入风险自动消失。长上下文场景先降级成摘要后的短 state，避免把整段聊天记录直接塞给判断模型。

GitHub 上的 wechat-jev-hud 仓库目前实现的是微信会话捕获、OCR 和观察者阶段，已接受 Phase 0 到 Phase 4。它没有实现 Phase 5 的 Jev 调用，也没有 HUD overlay。仓库里安装了官方 TypeSafe skill，留给后续集成，文档的 live-docs gate 仍生效。这意味着现在不能把这个仓库当作现成的 Jev 微信接入方案。它只是一个实验原型，离生产可用还有明确的阶段缺口。

## 行动，三步落地检查清单

先把判断任务拆成 Choice、Score 或 Noul 能建模的问题。再跑通最小闭环，最后按风险逐步灰度，不把 Jev 当一次性替换。

- 确认任务属于结构化判断，不包含精确计算或长篇生成。
- 用官方 API 固定 state 和问题格式，先跑通三种原语的最小演示。
- 根据业务风险设置信度阈值，低置信度转人工或走保守规则。
- 建立中文、数学、日期、长上下文和提示注入的自测集。
- 高风险审批保留人工最终决策。
- 评估 wechat-jev-hud 前，先确认其未接入 Jev，不要投入生产。

**结尾：**Agent 判断层的价值，取决于它在边界外能不能停下来。TypeSafe Jev 用 Choice、Score、Noul 把判断变成可审计的 API，但类型安全只解决格式合法，不解决语义正确。先在一个窄场景里装上 confidence 分流，再用自己的数据证明它值得留在流程里。

Jev 模型：Agent 的结构化判断层

排版预览

人工终稿

与初稿的差异

文章决策面板

内容复用

创建内容任务

导入运营数据

微信文章预览

选择标题

推送到微信草稿箱