Jev 于 2026 年 9 月 15 日发布，目前仍属于 early access；公开价格为 $0.042 / 1M input tokens，output 免费，官方速度宣传约 70–500ms。这些速度、成本和准确性指标目前应视为厂商/公开测试口径，不宜直接等同于经过独立基准验证的结论。
Agent 以循环（Loop）的方式运行：LLM 决定接下来要做什么，工具执行相应操作，模型评估执行结果，然后继续这个循环，直到任务完成。
最初，将 Agent 和 LLM 集成到软件应用中并不容易，因为软件依赖结构化数据和可预测的接口。后来出现了两个关键的基础能力，使这一过程变得容易得多：
- Tool Calling（工具调用）：允许模型发出结构化请求，并接收结构化结果。
- Structured Outputs（结构化输出）：允许模型返回结构化结果。
但是，即使具备了这些能力，Agent Loop 仍然存在速度慢、成本高的问题：每一个决策都需要再次调用模型。
这时候，Jev 出现了。
Jev 是 TypeSafe AI 发布的一种新型模型。TypeSafe AI 声称，与同类 LLM 相比，Jev 在分类任务上的推理速度最高可快 200 倍，成本最高可降低 400 倍。
本文将介绍 Jev 的工作方式、它在 Agent Loop 中所处的位置，以及如何通过 LangChain 使用 Jev。
一、Jev 是什么？
Jev 实际上并不是一种传统的 LLM，因为它不会生成文本。
TypeSafe AI 团队将它称为一种 System One Model。
System One 模型是一类专门用于快速进行结构化决策的 AI 模型，使软件可以直接使用这些决策结果。System One 模型会评估一个 State（状态），并返回具有明确类型的答案以及概率。
Jev 使用一种称为 RLCD（Reinforcement Learning for Calibrated Decisions，面向校准决策的强化学习） 的方法进行训练。
你的代码可以利用 Jev 返回的结果来决定 Agent 下一步应该做什么，而不需要针对每一个决策都调用一次完整的 Chat LLM。
要调用 Jev 模型，需要向它发送：
- 一个 State，即上下文；
- 针对这个 State 提出的问题。
下面是 TypeSafe 官方文档中支持工单（Support Ticket）示例的一个单问题版本：
{
"model": "jev-latest",
"state": "Hi, I've been trying to connect my Stripe account for 3 days and it keeps failing. I'm losing sales. Please help ASAP.",
"questions": {
"is_urgent": {
"type": "noul",
"instructions": "The message conveys urgency or time-sensitivity"
}
}
}该示例返回的 urgency（紧急程度）结果如下，这里省略了响应中的其他部分：
{
"is_urgent": {
"type": "noul",
"noul": 0.999
}
}
这意味着模型认为该消息属于紧急情况的概率为 99.9%。
应用程序可以利用这一结果，对该工单进行优先级排序。
Jev 支持三种问题类型
目前 Jev 支持三种 Question 类型：
1. Choice
从一组预定义选项中选择一个。
返回：
- 每个选项对应的概率；
- 一个整体 Confidence Score（置信度）。
例如：
Low
Medium
High
模型可以判断输入属于哪个选项。
2. Score
按照预先定义的等级，对输入进行评分。
例如：
Low
Medium
High
它会返回：
- 一个连续的 Score；
- 底层概率分布；
- Confidence Value（置信度）。
3. Noul
回答一个 Yes/No 类型的问题。
返回某个陈述为真的概率。
例如：
Does this request require immediate attention?
模型可能返回：
Yes: 0.97
表示模型认为该陈述为真的概率为 97%。
一个重要特性：一次请求可以提出多个问题
Jev 可以针对同一个 State，一次提出多个问题。
更重要的是：
System One 模型会并行评估同一个请求中的所有问题。
增加问题数量几乎不会增加响应时间，成本则只增加额外问题所对应的 Token，而这些 Token 的成本很低。
因此，你可以针对同一个 Support Ticket 同时询问：
Is it urgent?
Is it related to billing?
Does it require human intervention?
Is it a security issue?
Should it be escalated?
而不是依次调用多个模型。
总体而言，与传统 LLM 不同，Jev 既不受文本生成过程的限制，也不受顺序式决策过程的限制。
二、如何在 LangChain 中使用 Jev
LangChain 的模型接口具有 Provider Agnostic（与模型提供商无关）的特点，因此非常适合在支持数千种其他集成和模型提供商的同时使用 Jev。
LangChain 的 Jev 集成通过 TypeSafeClassifier 暴露 Jev。
你向 .invoke() 传入 State 和 Questions，然后得到的是分类结果，而不是聊天响应。
首先安装：
pip install langchain-typesafe
然后设置：
TYPESAFE_API_KEY
接下来可以进行调用：
from langchain_typesafe import Noul, TypeSafeClassifier
classifier = TypeSafeClassifier()
response = classifier.invoke(
state=(
"The deploy failed twice and customers are seeing 500s. "
"Can someone look now?"
),
questions={
"urgent": Noul(
instructions="Does this need attention right now?"
),
},
)
urgency = response.nouls["urgent"].noul
这里的 State 可以是：
- 文本；
- 结构化数据；
- LangChain Messages。
因此，你可以非常方便地在 Agent 的某个 Node 或 Middleware Hook 中调用 Jev，并直接使用 Agent 已经拥有的上下文。
你还可以将这种能力构建到：
- Custom Middleware；
- Tools。
之中。
三、Jev 的应用场景
Jev 并不是一个可以直接替代 LLM 的模型。
它不会生成文本，但它可以处理我们今天经常使用 LLM 完成的各种分类任务，同时具有更低的延迟和成本。
因此，更合理的使用方式是：
让 LLM 驱动 Agent 的开放式推理和内容生成，让 Jev 在 Agent 运行过程中负责快速、结构化的决策。
1. Model Routing——模型路由
简单的信息查询，并不需要使用与复杂 Debugging 任务相同的模型。
LangChain 提供了 Model-Routing Middleware（模型路由中间件），可以让 Jev 对请求进行判断，并根据你定义的标准选择模型。
例如：
from langchain.agents import create_agent
from langchain_typesafe.experimental.middleware import (
ModelChoice,
ModelRouterMiddleware,
)
router = ModelRouterMiddleware(
choices={
"fast": ModelChoice(
model="openai:luna",
criteria="Direct lookups, extraction, and localized changes.",
),
"powerful": ModelChoice(
model="openai:sol",
criteria="Architecture and high-stakes decisions.",
),
},
instructions="Choose the least costly model that can complete the task.",
)
agent = create_agent(
"openai:gpt-5.6-luna",
middleware=[router]
)
这里的 Router 会根据最新的一条用户消息选择模型，并在整个 Agent Run 中使用该模型。
与此同时：
- Probability；
- Confidence；
仍然可以保留在 Agent State 中。
因此，Agent 可以根据任务复杂度，在不同模型之间进行动态路由。
四、Auto Mode——自动模式
Agent 本质上仍然是不完全可靠的。
Agent 可能收到错误的指令——无论这种错误是自然产生的，还是来自一个有意进行攻击的攻击者——从而导致 Agent 被诱导去执行我们原本不希望它执行的操作。
像 Claude、Codex、Cursor 这样的 Coding Harness，都已经提供了某种机制：
在执行危险操作之前，对该操作进行分类判断。
这种机制逐渐帮助我们建立对 Agent 的信任。
但是，到目前为止，这种 Classifier（分类器）通常隐藏在这些 Harness 的闭源部分中。
现在，随着一种成本低、性能高的 Classifier Model 出现，我们可以将同样的模式应用到所有 Agent 中。
例如：
from langchain.agents import create_agent
from langchain_typesafe.experimental.middleware import (
AutoModeMiddleware,
)
guardrail = AutoModeMiddleware(
tools=["bash"]
)
agent = create_agent(
"openai:gpt-5.6-luna",
middleware=[guardrail]
)
AutoModeMiddleware 使用 Jev 检查 Agent 即将执行的 Tool Call 是否属于具有风险的决策。
如果发现风险，它可以在 Tool 真正执行之前阻止该调用。
因此，其运行模式可以理解为：
Agent
│
↓
LLM 决定调用 Tool
│
↓
Jev
│
├── Safe ─────→ 执行 Tool
│
└── Risky ────→ Block
五、开始使用 Jev
LangChain 团队表示，他们对 Jev 以及它所带来的可能性感到非常兴奋。
目前已经出现了一些有趣的项目：
- Browserbase 的 Kyle Jeong 正在使用 Jev，让 Browser Use Agent 以极低的成本运行；
- Jarrod Watts 构建了一个实时交易 Agent；
- Ryan Vogel 正在大规模使用 Jev 进行 Email Triage（邮件分类/分流）。
现在几乎每周都会发布新的模型，但 Jev 所获得的关注度明显超出了普通新模型。
LangChain 团队期待看到开发者如何将 LangChain 与 Jev 结合起来构建新的应用。
六、总结
Jev 并不是另一个试图与 GPT、Claude 等通用 LLM 竞争的聊天模型。
它解决的是 Agent Architecture 中另一个问题：
Agent 不仅需要“思考”和“生成”，还需要大量快速、低成本、结构化的判断。
传统 Agent：
User
↓
LLM
↓
Decision
↓
Tool
↓
Result
↓
LLM
↓
Decision
↓
Tool
↓
...
每一次 Decision 都可能需要调用一次 LLM。
Jev 则提供了另一种架构：
因此，可以形成一种更加明确的职责分工：
LLM：
- Open-ended Reasoning
- Generation
- Planning
- Complex Problem Solving
Jev：
- Classification
- Routing
- Scoring
- Risk Detection
- Guardrails
- Fast Decisions
最终，Agent Harness 可以把两类模型组合起来：
这也是 Jev 最值得关注的地方：它不是单纯提供一个更快的分类模型，而是在 Agent 架构中把“推理”和“决策”这两类工作进一步解耦。
原文：What Is Jev? A Guide to TypeSafe AI’s System One Model 本文在原文基础上结合最近对AI Harness架构设计的学习，进行了部分补充。
系统学习AI Agent和Harness的架构设计学习：《AI Agent 架构设计与工程实践指南》——从 LLM、Agent、Harness 到 Mini Claude Code – 编程开物