Jev 是"模型内置的 harness"吗？——System One 决策模型的原理、设计与边界

"Loop 是免费的，Harness 是昂贵的。" —— 《AI圈突然都在聊 Loop、Graph Engineering》

"模型越聪明，你越需要一个可靠的缰绳。" —— 《从 CoT 到 ReAct，再到"会自己思考"的模型》

前面几篇（Harness 即一切、Loop Engineering、ReAct 深度解析、把提示词当代码写）反复落在同一个结论上：价值重心在 harness，不在 loop，也不全在模型。

最近 TypeSafe AI 发布的 Jev 在 agent 圈里传得很快。LangChain、Cloudflare、Langfuse 几天内就接入了；browser-use 拿它做了一个"最快最便宜的 web agent"；还有人拿它让 LLM 自己写 harness。看到这些，很自然会冒出一个问题：

Jev 是不是就是"模型内置的 harness"？harness 是不是终于被做进模型里了？

本文先把 Jev 的原理和设计讲清楚，再回答这个问题。先把结论放在这里：不是，方向正好反过来。 Jev 不是"模型里装了 harness"，而是"harness 里装了一个专门的模型"。它把 harness 中最难写好的那一格，也就是语义判断，从手写规则和昂贵的 LLM 调用里拿出来，做成了一个又快又便宜、带类型、带概率的函数。

一、Jev 是什么：一个不生成文本的模型

一句话定义（来自 TypeSafe 的官方表述）：

Unstructured or structured state in → typed probabilistic decisions out. 输入任意状态，输出带类型、带概率的决策。

它不生成文本。你事先定义好"允许的答案空间"，Jev 读完状态，只在这个空间里给出答案和概率分布。TypeSafe 把这类模型叫做 System One Model，名字取自 Kahneman 的"系统 1 / 系统 2"：

TypeSafe 在分类任务上宣称的数字是：比同类 LLM 推理快约 200 倍、成本低约 400 倍。

1.1 三个原语

Jev 只暴露三种"问题类型"，这就是它的全部接口：

LangChain 集成里的调用长这样：

from langchain_typesafe import Noul, TypeSafeClassifier

classifier = TypeSafeClassifier()
response = classifier.invoke({
    "state": "Deploy failed, customers see 500s",
    "questions": {
        "urgent": Noul(instructions="Does this need attention now?"),
    },
})
# -> {"urgent": {"type": "noul", "noul": 0.999}}

注意输入的形状：一个 state，加一组有名字的问题。state 就是"你会摆在专家面前让他判断的全部材料"，可以是字符串、JSON、对话记录或数据库记录。问题之间相互独立：问题 A 的答案不会偷偷影响问题 B 的评估。

1.2 官方给的心智模型："五秒专家判断"

TypeSafe 的文档把 Jev 适合的任务描述为：一个懂行的人不查资料、不写推理、不做计划，五秒钟内就能给出的判断。 他们还给了一张六问自测表：

5–6 个"是"适合用 Jev，3–4 个部分适合，0–2 个就该换别的工具。

最后一条权重最高：结果是给机器消费的。 这一条几乎就是 harness 里"判断节点"的定义。

二、原理：为什么"不会说话"反而是优势

Jev 的具体网络结构 TypeSafe 没有公开。下面把已公开的事实和基于事实的推理分开写。

2.1 封闭输出空间：把"格式幻觉"从结构上消灭

用 LLM 做判断，我们在把提示词当代码写里用过一整套手法：结构化输出、JSON 锁边界、"绝对语气 = 类型约束"、只许输出一行。它们都在做同一件事：把一个开放的生成器，硬压成一个封闭的函数。 这种压制靠的是模型"愿意配合"，所以总会漏：多一个逗号、选项名拼错、在 JSON 前面加一句 "Sure! Here's..."。

Jev 把这件事从"约束"变成了"结构"。它的输出层只覆盖你定义的那几个选项，根本没有能力输出集合外的值。这就是 TypeSafe 说的 "zero hallucinations"。

但他们自己也特意强调：

Never interpret "zero hallucinations" as "zero errors."

消灭的只是类型错误（输出不在集合里），不是语义错误（在集合里选错了）。这句话后面讲风险时还会用到。

2.2 并行问题：不是自回归

LLM 回答五个问题，要么调五次，要么在一次生成里依次写出五个答案，后写的答案会受先写的答案影响。Jev 的文档明确说，同一请求里的多个问题是对同一个 state 并行、独立评估的。

合理的推测是：state 编码一次，每个问题（带上它的 instructions 和选项）作为查询，在同一份表示上各自读出一个分布，类似"一个编码器 + 多个可配置的读出头"。这也解释了速度：没有逐 token 解码，就没有自回归延迟。 一次判断的成本接近一次编码的成本。

对 harness 设计者来说，这带来一个很实际的好处：一次调用可以问 N 个正交的问题，而且问题之间不串味、可以单独测试。

2.3 RLCD：训练目标是"概率要诚实"

Jev 用 RLCD（Reinforcement Learning for Calibrated Decisions） 训练。公开信息只有名字和目标：让输出的概率真正代表不确定性。

"校准"（calibration）的含义很具体：在所有给出 0.8 的判断里，大约 80% 应该是对的。 要让 RL 把模型推向"诚实"，奖励函数得满足一个数学性质，叫严格适当评分规则（strictly proper scoring rule），比如对数分数 log p(真实答案) 或 Brier 分数。它们的共同性质是：只有当你报出你真实相信的概率时，期望奖励才最大。 虚张声势（明明没把握却报 0.99）和过分谦虚（明明有把握却报 0.6）都会被扣分。

RLCD 的具体奖励 TypeSafe 没有公开，但"calibrated decisions"这个目标决定了它必然属于这一类。

为什么校准对 harness 这么重要？ 因为 harness 是代码，代码需要阈值：

risk = jev(state, {"danger": Score(levels=[...])})
if risk.confidence < 0.5:
    escalate_to_human()        # 模型自己都没把握 → 交给人
elif risk["danger"].score >= 2:
    deny()
else:
    allow()

一个没校准的 0.9 对代码毫无意义，你没法在它上面设阈值。校准后的概率才是能写进 if 里的数字。 这是 Jev 和"让 LLM 输出一个 1–10 的分数"最本质的区别：LLM 报的 7 分是文本，Jev 报的 0.7 是有统计含义的量。

TypeSafe 也提醒了另一面：calibration ≠ correctness。 校准保证的是"概率越高越常对"，不保证任何一次具体判断是对的。

2.4 一张图看 LLM 与 Jev 的分工

                 开放生成（System 2）                    封闭判断（System 1）
               ┌─────────────────────┐              ┌──────────────────────┐
  state ──────►│  LLM: 逐 token 解码  │──► 文本 ──►  │ 解析 / 正则 / 重试    │──► 决策（可能失败）
               └─────────────────────┘              └──────────────────────┘

               ┌─────────────────────────────────────────────────────────────┐
  state ──────►│  Jev: 编码一次 → 各问题并行读出 → 封闭集合上的校准分布        │──► 决策（类型保证）
               └─────────────────────────────────────────────────────────────┘

上面那条路里，"解析 / 正则 / 重试"这一格本身就是一小段 harness，专门用来收拾 LLM 输出的烂摊子。Jev 直接把这一格删掉了。

三、设计哲学：控制流留在代码里

TypeSafe 推荐的架构只有一行：

deterministic code → Jev semantic judgement → deterministic code

他们甚至明确说，System One 是 "AI-powered software rather than agent architecture"：是"被 AI 增强的软件"，不是"agent 架构"。

这句话值得细读。主流 agent 范式（ReAct、deep agents）让 LLM 掌握控制流：下一步做什么、调哪个工具、何时停下，都由模型在文本里决定，harness 只负责执行和兜底。Jev 的主张相反：

• 控制流归代码：if / for / while、状态机、重试、超时，全由程序员写死；
• 语义缺口归 Jev：代码不会写的那几个 if 条件（"这句话是不是在要求退款？"），交给 Jev；
• 开放生成归 LLM：真需要写文字、做推理的时候，才调用大模型。

用把提示词当代码写里的话说，那篇文章追求的是"把提示词写成函数"，Jev 则是一个本来就只能当函数用的模型。那篇里的"一个 system role 只做一件事：粒度即稳定性"，在 Jev 这里成了硬性要求：问题必须是原子的（Atomic）。

四、把 harness 拆开，看 Jev 落在哪一格

要回答"Jev 是不是 harness"，先得把 harness 拆开。综合前几篇，一个 agent harness 大致有五个部件：

前几篇重点讲了动作（"精准 tools 即精准上下文"）、控制流（"拓扑便宜，harness 贵"）和护栏（"唯一不该退潮的部分"）。"判断"这一格一直被默认交给主 LLM：让大模型在 Thought 里顺便决定。

这其实是个很别扭的安排。一个 harness 里的判断点远比想象中多：

所以 Jev 在 harness 里的位置很清楚：它是"判断"这一格的专用硬件。 类比一下：

• 代码里的 if x > 0 是数值谓词，CPU 一条指令就算完；
• 代码里的 if is_refund_request(msg) 是语义谓词，以前要么写一堆脆弱的正则，要么花几秒几分钱调一次 GPT；
• Jev 让语义谓词便宜到可以像数值谓词一样随手写。

这对Loop Engineering里的结论是一个直接补充。那篇说"拓扑决定能表达多复杂的流程，harness 决定这流程靠不靠谱"。Jev 恰好作用在两者的交界处：图的边上的条件。LangGraph 里的 conditional edge 以前要么是写死的规则，要么是一次 LLM 调用。现在它可以是一次 0.3 秒的 Jev 调用，而且返回的概率可以直接拿来比阈值。

五、核心问题：Jev 是"模型内置的 harness"吗？

5.1 先分清两个方向

"harness 和模型的关系"在前几篇里其实已经出现过两条相反的路：

方向 A：内化，把 harness 训进大模型的权重。 ReAct 深度解析第 6 节讲的就是这条路：CoT 被 o1 用 RL 训成了内生的长推理，ToT 的"换条路"成了 R1 的自发行为，ReAct 的 Thought 侧也在内化。今天的 agentic RL（在真实工具环境里训练模型调用工具、规划、自我纠错）是这条路的延续。如果真有"模型内置的 harness"，指的应该是这个： 原来写在 prompt 和框架里的 SOP，被训练吸收进了一个通用大模型。

方向 B：外化，把 harness 里的某一类功能拆出来，做成专用模型。 这是 Jev 走的路。它没有让大模型更会管自己，而是从大模型身上拆下了一类工作（快速、有界的判断），交给一个专门训练的小模型，并且把控制权交还给代码。

两条路的对照：

5.2 所以答案是

Jev 不是"模型内置的 harness"，而是"harness 内置的模型"。

说得更精确一点：

1. Jev 自己没有 harness 的任何"骨架"部件。 它不循环、不调工具、没有记忆、不决定下一步做什么。它甚至没有"下一步"的概念，每次调用都是无状态的单次判断。把它单独拿出来，它什么也做不成。
2. Jev 是 harness 里一个可学习的零件。 它替换的是 harness 代码里那些本该语义化、却只能写成正则的 if 条件。
3. Jev 加强了"代码掌握控制流"这个立场。 这和方向 A 的趋势（让模型接管越来越多的控制）是反着走的。

5.3 但这个误会从哪来？它说对了一半

之所以会有"Jev 是内置 harness"的直觉，是因为它确实让一件原本属于 harness 工程师的工作从手写变成了学习：

• 以前：工程师手写 BLOCKED_COMMANDS = ["rm -rf", "mkfs", ...]，这是人把判断硬编码进 harness；
• 现在：jev(cmd, {"danger": Score(...)})，判断标准来自一个训练过的模型，工程师只定义问题和答案空间。

所以如果把"harness"狭义理解为"harness 里的判断逻辑"，那 Jev 确实是把 harness 的判断逻辑模型化了。准确的说法是：Jev 是 harness 的判断层被做成了模型，而不是 harness 被做进了模型。 骨架（控制流、工具、记忆、护栏）仍然在外面，而且更需要人来设计。

5.4 最有意思的证据：JevHarness，"System 2 编译出 System 1"

GitHub 上的 JevHarness 项目把这个关系演示得非常清楚：

1. 编写期：一个 LLM（System 2）针对具体任务写一份 Python harness，内容包括：从观察里算特征的代码、要问 Jev 的问题、把 Jev 的答案组合成动作的决策逻辑、记忆结构；
2. 运行期：harness 冻结，每一步只跑特征代码 + 并行的 Jev 请求，不再调用 LLM；
3. 进化期（可选）：收集完整轨迹和奖励，让 LLM 反思、改写 harness，用 GEPA 在候选版本之间选优。

在宝可梦对战的例子里，五轮反思后胜率从 25%（3/12）升到 75%（9/12），单步决策中位延迟约 568ms。

这个结构几乎就是 Loop Engineering 里 autoresearch 的翻版：一个可改写的程序 + 一个可度量的指标 + 一个自动循环，只不过被改写的对象从 train.py 换成了 harness.py。它清楚地说明了三者的分工：

LLM (System 2)        ── 写 harness：把"怎么想"编译成代码 + 问题清单
harness (code)        ── 掌握控制流、特征、记忆、组合逻辑
Jev (System 1)        ── 在运行期回答那些代码写不出的语义谓词

大模型的推理被"编译"进了 harness 代码，Jev 负责执行其中的语义判断。 这里没有任何东西被"内置进模型"。恰恰相反，推理被导出成了可读、可改、可 diff 的代码。

六、三个落地样本

6.1 LangChain：Router + Tool Gate

LangChain 的示例 harness 在标准 agent loop 上只加了两个 Jev 节点：

• Request Router：用 Choice 判断请求复杂度，简单的走 gpt-4o-mini，复杂的走 gpt-4o；
• Tool Gate（AutoModeMiddleware）：在工具执行前，用 Score 按 low / medium / high 给调用评风险，高风险的（比如删账号）直接拒绝。

路由这件事以前有个悖论：为了省大模型的钱，先调一次大模型来判断要不要用大模型。 Jev 用一个便宜两三个数量级的判断把这个悖论解开了。

6.2 browser-use 的 jev-ultrafast：Jev 当"手"，小 LLM 只管"嘴"

这是一个把分工推到极致的 web agent：

1. 一次浏览器调用拿到带编号的可交互元素快照；
2. 一次 Jev 请求同时给出"做什么操作"和"点哪个元素"的概率；
3. 执行器在动手前重新校验页面是否已变、点击目标是否被遮挡；
4. 只有当操作是 TYPE_TEXT 时，才调用小 LLM 生成要输入的文字。

在 Google Flights 上完成一次苏黎世→伦敦的搜索只用 7.1 秒；对比实验里中位耗时从 9.45s 降到 7.09s，浏览器协议调用从 1092 次降到 101 次。

注意第 3 步：Jev 做判断，执行前的校验仍然是确定性代码。 这正是"deterministic code → Jev → deterministic code"的样子。

6.3 一次独立的 benchmark：它擅长什么、不擅长什么

一位开发者用 jev-1.13.0 在 10 个公开数据集上跑了约 22,500 次调用（总成本 $2.19），结果很有代表性：

强项全是局部、有界、一眼可判的任务；弱项全是需要跨步推理、需要建模另一个模型的任务。这与"五秒专家判断"的定位完全吻合，也再次说明 Jev 当不了 harness 的"大脑"：失败归因、下一步规划这类事，它做不了。

同一份报告里还有两条对 harness 设计很有价值的经验：

• 正交分解 + 代码组合，胜过一个大问题。 把"这条命令危险吗"拆成几个正交的原子问题，再用代码组合，误报率从 14.5% 降到 1.8%；
• 多标签任务"先竞争、再验证"。 先用 Choice 让候选互相竞争，再用 Noul 逐个复核，技能路由从 9% 提到 81%。

这两条和把提示词当代码写里"提示词是可组合的函数（Lambda 演算）"是同一个道理。原子问题交给模型，组合交给代码。 组合逻辑一旦写进代码，就可以测试、可以 diff、可以回放。

七、边界与风险：护栏不能只交给一个概率

7.1 Jev 也会被注入

VentureBeat 报道了 Octomind 的一个测试：在一次"是否拦截这条命令"的判断里注入一个伪造的"已批准"字段，拦截概率从 0.76 掉到 0.48，confidence 从 0.64 掉到 0.22。TypeSafe 自己也承认，刻意写来操纵模型的内容"可以移动答案"。

这是 2.1 节那句 "zero hallucinations ≠ zero errors" 的直接后果：类型安全不等于语义安全。 Jev 输出的永远是一个合法选项，但攻击者可以影响它选哪个。

7.2 所以护栏要分层

ReAct 深度解析里说过，BLOCKED_COMMANDS、is_safe_path 这类安全边界是 harness 中唯一不该退潮的部分。Jev 出现之后，这句话要更精确一些：

第 0 层：确定性硬护栏    BLOCKED_COMMANDS / 路径白名单 / 权限隔离   ← 不可被说服
第 1 层：Jev 语义闸门    Score(风险) + confidence 阈值             ← 覆盖规则写不全的长尾
第 2 层：人工确认        低 confidence 或高风险时升级              ← 对真正有后果的动作兜底

Jev 适合放在硬规则和人之间，扩大覆盖面，而不是取代硬规则。 一条经验法则：凡是"被说服就会出事"的判断，都必须有一层不接受说服的确定性代码兜底。模型再准，也是可以被说服的。

同一篇报道给出的工程建议也值得照做：

1. 全量记录：state、问题定义、选项顺序、模型版本、概率与 confidence；
2. 固定模型版本，避免判断标准悄悄漂移；
3. 对抗测试：打乱选项顺序、喂恶意输入，看结果是否稳定；
4. 隔离权限：不同工作负载不要共用一套权限；
5. 有后果的动作保留人工检查点。

Jev 有一个 LLM 不具备的优势：它的每个判断都是一个带概率的结构化记录，天然可以审计。 用好这个优势，本身就是 harness 工程的一部分。

7.3 能力边界

再总结一次 Jev 做不了的事，它们都是 harness 骨架里仍然需要人和大模型负责的部分：

• 多步推理、规划、失败归因 → 仍然是 System 2（大模型）的工作；
• 查外部信息 → 仍然是 tools 的工作；
• 生成任何文字 → 仍然是 LLM 的工作；
• 控制流、状态、重试 → 仍然是代码的工作。

八、把 Jev 放回前几篇的全景图

ReAct 深度解析第 7 节画过一张"能力在内、结构在外"的演化图。加上 Jev，这张图多了一个维度：

                       内化进通用大模型                  外化成专用组件
                       （方向 A）                         （方向 B）
                  ◄──────────────────────       ──────────────────────►

怎么想（推理）     o1 / R1：CoT、搜索、反思         —（没有理由外化）
                  被 RL 训进权重

判断（语义谓词）   主 LLM 在 Thought 里顺便判断      Jev：路由 / 放行 / 选工具 / 重排
                                                  被 RLCD 训成专用 System 1 模型

动作（碰世界）     —（无法内化，世界不在权重里）      tools / MCP：永远在 harness

控制流             agent 自主决定下一步               代码 / 状态机 / LangGraph

护栏               —（被说服就会出事）                确定性规则 + Jev 闸门 + 人工

这张图说明，"模型越来越强，harness 就可以越来越松"只说对了一部分：

• "怎么想" 确实在向左迁移，约束在退潮；
• "判断" 正在分叉：可以留在大模型里（慢、贵、灵活），也可以外化成 Jev 这样的专用模型（快、便宜、可审计、可设阈值）。对于高频、有界、需要给机器消费的判断，外化明显更划算；
• "动作"和"护栏" 仍然在 harness 里，而且更重了。

所以 Jev 没有让 harness 消失，它让 harness 变得更像软件：判断点显式化，每个判断点都有类型、有概率、有日志。这和 harness 的本义（缰绳）是一致的。

九、给动手的人

1. 在你的 harness 里找出所有"判断点"。 凡是现在用正则、关键词，或者"再问一次 LLM"来实现的 if，都是 Jev 的候选位置。对照第一节的六问表过一遍。
2. 优先替换高频、低风险的判断：路由、重排、意图分类、是否需要检索。这些地方省下的延迟和成本最明显，判错的代价也最小。
3. 问题要原子化，组合写进代码。 不要问 Jev "这条命令安全吗"，拆成"是否删除数据""是否影响生产""是否需要提权"几个正交问题，再用代码组合。
4. 用 confidence 做分流，而不是只看 argmax。 低 confidence 的判断，升级给大模型或人。这正是校准概率存在的意义。
5. 安全判断永远保留确定性兜底。 Jev 闸门放在 BLOCKED_COMMANDS 之后，而不是替代它。
6. 把大模型用在"写 harness"上，而不是"当 harness"。 JevHarness 的思路值得借鉴：让 LLM 离线写出判断逻辑和问题清单，运行期只跑代码 + Jev，再用轨迹和指标迭代。这比每一步都调一次 LLM 更快、更便宜，也更容易审计。

十、结语

回到开头的问题：Jev 是模型内置的 harness 吗？

不是。Jev 是 harness 内置的模型。它不循环、不调工具、不记忆、不决定下一步，它只在 harness 问它的时候，用 0.3 秒给出一个带概率的判断。

但它确实改变了 harness 的工程方式。以前 harness 里的语义判断只有两个选项：写不全的规则，或者又慢又贵、输出还要解析的 LLM。现在多了第三个选项：一个像函数一样调用、像数字一样比较、像日志一样审计的语义谓词。

前面几篇说"Loop 是免费的，Harness 是昂贵的"。Jev 没有让 harness 变得免费，但它让 harness 里最常见的那种零件（判断）便宜了几百倍。零件便宜了，工程的重心就更清楚了：控制流、工具、护栏，以及把问题拆成对的原子问题。 这些仍然要靠人来设计。

大模型负责想，代码负责管，Jev 负责判断。

参考

• LangChain Blog, What Is Jev? A Guide to TypeSafe AI's System One Model — https://www.langchain.com/blog/building-a-harness-with-jev
• SitePoint, Build Safer AI Agent Harnesses with Jev and LangChain — https://www.sitepoint.com/build-safer-ai-agent-harness-jev-langchain/
• Comprehensive project reference for TypeSafe Jev（概念、原语、六问自测表）— https://gist.github.com/pjburnhill/adf8d28efcad9df037bfdece178ef965
• DEV Community, Benchmarking Jev: what a decision model can (and can't) do in an agent harness — https://dev.to/aitejiu/benchmarking-jev-what-a-decision-model-can-and-cant-do-in-an-agent-harness-20po
• VentureBeat, Companies are putting Jev in charge of AI agent decisions — and prompt injection can influence the verdict — https://venturebeat.com/security/companies-are-putting-jev-in-charge-of-ai-agent-decisions-and-prompt-injection-can-influence-the-verdict
• browser-use / jev-ultrafast — https://github.com/browser-use/jev-ultrafast
• TianyuCodings / JevHarness — https://github.com/TianyuCodings/JevHarness

相关阅读（本站）： - Harness 即一切：模型不是不够聪明，而是是否有足够有用的 tools - AI圈突然都在聊 Loop、Graph Engineering，炒作还是新东西？ - 从 CoT 到 ReAct，再到"会自己思考"的模型 - 把提示词当代码写：Prompt Engineering 的第一性原理