1. 什么是 Jev
Jev 是 TypeSafe AI 推出的首个 System One 模型。它不是聊天机器人，也不是 Harness，而是一个专门为软件提供快速、结构化判断的 模型。
Jev 接收两类输入：
- State（状态）：需要判断的文本或结构化数据。
- Questions（问题）：针对该状态提出的、具有明确输出类型的问题。
它不会生成文章、代码或推理过程，而是直接返回类型确定的答案、概率分布及置信度。应用程序可以把这些结果用于分支、排序、路由和权限控制。
Note
Jev 不是缩写。TypeSafe AI 表示，该名称来自英国经济学家 William Stanley Jevons。其背后的隐喻是「杰文斯悖论」：当一种资源的使用效率显著提高、成本下降后，总需求反而可能上升。TypeSafe AI 认为，更低成本的机器判断会催生更多自动化场景。
可以把 Jev 理解为高性能分类器吗
可以将「高性能分类器」作为理解 Jev 的第一层近似，但这个说法并不完整。更准确地说，Jev 是一个面向自然语言状态的低延迟、类型化概率判断模型。
分类只是其中一种能力：
Choice用于多分类，Noul用于二元语义判断，Score用于按照有序标准评分。因此，Jev 更接近一个面向软件决策的分类与评分引擎。Jev 的主要优势是低延迟、输出类型确定、概率可见并且容易被程序消费，而不是对所有分类任务都具有更高的准确率。实际准确率仍取决于业务数据、问题定义、候选项、阈值和模型版本。
Jev 的基本数据流如下：
2. 为什么需要 System One 模型
传统 LLM 的核心能力是生成文本。即使使用 Structured Output 或 Tool Calling，模型通常仍需逐 Token 生成结果，然后由程序解析、校验并执行。
但 Agent 循环中存在大量不需要长文本的高频判断：
- 下一步应该调用哪个工具？
- 当前页面中应该点击哪个控件？
- 这段内容是否与当前任务相关？
- 当前结果是否通过验收？
- 这次操作是否具有较高风险？
- 当前任务是否已经完成？
如果每一个小判断都交给大型推理模型，会引入额外延迟、成本和 上下文 消耗。Jev 的目标不是取代推理模型，而是将这类边界清晰的判断从开放式文本生成中拆出来。
| 维度 | Jev | 传统 LLM |
|---|---|---|
| 核心任务 | 快速、结构化判断 | 开放式理解、推理与生成 |
| 输入 | State + Typed Questions | Prompt、消息与工具结果 |
| 输出 | 类型化值、概率分布、置信度 | 自由文本或结构化文本 |
| 适合的问题 | 分类、评分、过滤、路由、门禁 | 规划、解释、写作、编码、复杂推理 |
| 结果消费方 | 程序直接读取 | 人类阅读或程序解析 |
| 典型位置 | Agent 循环中的决策层 | Agent 的规划和生成核心 |
这里的「System One」来自《思考，快与慢》中 System 1 的类比，强调快速、聚焦的判断；它不是对人类认知系统的严格复刻。
3. 三种决策原语
Jev 通过三种 TypeSafe Primitive 表达问题。一次请求可以同时包含多道问题；每道问题都会基于同一个 State 独立评估。
| 原语 | 适用问题 | 主要返回值 | 示例 |
|---|---|---|---|
Choice | 从有限候选项中选择一个 | 选中项、各项概率、置信度 | 将工单路由到账单、技术或销售团队 |
Score | 按有序标准进行评分 | 连续分数、等级概率、置信度 | 判断用户情绪处于平静、沮丧还是愤怒 |
Noul | 判断一个陈述是否成立 | 「是」的概率，范围为 0 到 1 | 判断消息是否要求退款 |
3.1 Choice
Choice 适合封闭候选集。例如，浏览器 Agent 已经从页面提取出当前可点击元素，Jev 只负责从这些候选项中选择下一步动作：
候选动作 = [点击登录, 打开帮助, 返回首页]候选集由应用程序提供，因此 Jev 不会返回列表之外的动作。但这只保证输出属于候选集，不保证它选择的动作一定正确。
3.2 Score
Score 用于有序等级，而不是互不相关的类别。例如：
0 = 平静
1 = 沮丧但克制
2 = 非常愤怒返回值可以位于等级之间，程序也能读取每个等级的概率分布。若选项之间没有顺序关系，应使用 Choice。
3.3 Noul
Noul 用于二元判断，返回陈述为真的概率。例如，返回 0.92 表示模型认为「该消息要求退款」成立的概率较高。
Noul 不是普通布尔值。应用程序需要根据风险设置阈值，例如：
noul >= 0.90：自动进入退款审核
0.60 <= noul < 0.90：要求人工复核
noul < 0.60：不进入退款流程阈值应通过真实业务数据验证，不能把示例数值直接用于生产环境。
4. 一次请求如何工作
下面是一个简化的客服工单请求。它同时询问路由、情绪等级和紧急程度：
{
"model": "jev-latest",
"state": {
"message": "我的付款连续失败三天，订单已经受到影响，请尽快处理。"
},
"questions": {
"department": {
"type": "choice",
"instructions": "应该由哪个团队处理？",
"criteria": {
"billing": "付款、账单或退款问题",
"technical": "软件错误或集成问题",
"sales": "价格、升级或新客户问题"
}
},
"frustration": {
"type": "score",
"instructions": "客户表现得有多沮丧？",
"criteria": ["平静，只是在陈述事实", "感到沮丧但保持克制", "非常愤怒"]
},
"is_urgent": {
"type": "noul",
"instructions": "这条消息具有明确的紧迫性"
}
}
}请求通过 POST https://api.typesafe.ai/v1/systemone 发送。返回结果的结构大致如下：
{
"model": "jev-1.x.x",
"answers": {
"department": {
"type": "choice",
"choice": "billing",
"probabilities": {},
"confidence": 0.0
},
"frustration": {
"type": "score",
"score": 0.0,
"probabilities": {},
"confidence": 0.0
},
"is_urgent": {
"type": "noul",
"noul": 0.0
}
}
}上面的返回值只用于展示字段结构，数字不是对示例工单的实际推理结果。生产代码应读取概率和置信度，再结合本地规则决定是否执行、补充信息或升级处理。
5. Jev 在 Agent 中的位置
Jev 更适合作为 Agent 的决策层或验证层，而不是替代整个 Agent：
LLM：理解目标、规划步骤、生成代码或文本
Jev：在明确候选项中快速选择、评分和判断
程序：执行动作、控制权限、验证结果和处理失败常见组合方式包括：
- 工具路由：从当前允许的工具中选择一个。
- 动作选择：从 DOM、无障碍树或游戏状态提供的候选动作中选择下一步。
- 安全门禁：判断操作是否敏感、不可逆或需要人工确认。
- 结果验收：判断目标是否完成、证据是否充分、结果是否需要复核。
- 上下文筛选：对候选文件、日志或 工具结果 进行相关性评分。
- 任务分流：按类别、风险和置信度路由到不同处理流程。
一个合理的 Agent 循环是：
Jev 负责「在已有边界内判断」，程序负责「定义边界并承担最终控制权」。高风险操作仍应使用权限校验、确定性规则和 Human-in-the-loop。
在实际接入时，Jev 通常不会替代 Agent 的主模型。常见做法是将 Jev 封装成工具，让 Agent 在需要分类、评分或选择时调用。完整链路如下：
接入方式取决于 Agent Harness：
| Agent 能力 | 推荐接入方式 |
|---|---|
| 支持 AI_Terminology > MCP | 注册 Jev MCP Server，将判断能力暴露为工具 |
| 支持自定义工具或插件 | 使用 TypeSafe SDK 封装 Choice、Score 和 Noul |
| 只能执行命令 | 安装 Jev CLI，通过 Shell 调用并读取 JSON |
| 自研 Agent | 直接调用 TypeSafe System One API |
下面以支持 MCP 的 Agent 为例，使用社区项目 jev-cli。该项目同时提供命令行工具和名为 jev-mcp 的 stdio MCP Server。
第一步：获取 API Key
在 TypeSafe Console 创建 API Key。Jev 是云端服务，因此即使适配器运行在本地，发送给 Jev 的 State 仍会离开本机。
第二步：安装并认证
macOS 可以使用 uv 安装：
brew install uv
uv tool install jev-cli
jev auth set
jev auth testjev auth set 会通过隐藏输入读取 Key，并存入用户配置目录，不需要把凭证写进项目仓库。
第三步：注册 MCP Server
不同 Agent 的 MCP 配置路径不同，但核心配置相同：
{
"mcpServers": {
"jev": {
"command": "jev-mcp"
}
}
}重启 Agent 或重新加载 MCP 配置，并确认 jev 工具已经出现。如果 Agent 找不到命令，先在终端执行：
command -v jev-mcp再把 MCP 配置中的 command 改为该命令返回的绝对路径。原因是从图形界面启动的 Agent 不一定继承终端中的 PATH。
第四步：验证调用
可以先让 Agent 执行一个边界明确的判断：
调用 Jev 的 Noul 判断当前 Git diff 是否包含身份认证或权限控制相关修改，
返回概率和模型原始结果，不要仅凭该结果自动批准变更。也可以使用 Choice 对任务进行分流：
调用 Jev，从 bug_fix、refactor、feature、documentation 中选择最符合当前
Git diff 的变更类型，并返回各候选项的概率。看到 Agent 实际调用 jev MCP 工具并返回概率，才说明接入成功。普通自然语言回答不能证明 Jev 已被调用。
第五步：约束使用场景
Agent 不会因为 MCP Server 已安装就自动在每个决策点使用 Jev。可以在 AGENTS.md、Harness Rules 或 System Prompt 中补充：
当任务需要在封闭候选集中分类、对有序等级评分或判断一个明确陈述时，
优先考虑调用 Jev。不要用 Jev 生成文本、编写代码或替代安全校验。
高风险操作不得仅根据 Jev 的概率自动执行。这个集成中的职责边界是：
Agent 的主模型：理解目标、规划、生成和解释
Jev：提供 Choice、Score、Noul 类型的概率化判断
Agent Harness：决定是否调用工具并消费结果
本地规则与用户：控制权限、阈值和最终执行Warning
jev-cli是独立社区项目，并非 TypeSafe AI 的官方集成。使用前应审查源码、固定版本，并确认凭证存储和数据传输方式符合项目的安全要求。
6. 什么场景适合 Jev
适合 Jev 的问题通常具备以下特征：
- 输入可以表示为文本或 JSON。
- 输出空间可以提前定义。
- 判断目标单一、边界清晰。
- 需要频繁调用，对延迟或成本敏感。
- 程序能够根据概率和置信度采取不同策略。
- 错误可以通过复核、回退或本地规则控制。
典型场景包括：
- 工单分类和消息路由。
- 搜索结果重排和内容过滤。
- Agent 工具选择与任务完成度判断。
- 风险识别、内容审核和安全门禁。
- 浏览器、桌面或游戏中的候选动作选择。
- 大规模数据记录的标签、评分和初筛。
7. 什么场景不适合 Jev
以下任务不应直接交给 Jev：
- 撰写文章、邮件、代码或解释。
- 开放式规划与多步复杂推理。
- 没有明确候选项或评价标准的问题。
- 需要读取图片、音频或视频的任务。当前 Jev 只接受文本输入。
- 要求单次判断绝对正确的高风险决策。
- 需要模型给出完整证据链或推理过程的任务。
如果一个问题需要同时权衡多个独立因素，应先拆成多个原子问题，再由代码组合结果。不要把「分析整个问题并决定最佳方案」直接塞进一个 Noul 或 Score。
8. awesome-jev-projects 是什么
awesome-jev-projects 不是 Jev 模型的源码，也不是 TypeSafe 官方 SDK。它是一个社区维护的 Jev 开源项目目录和架构雷达。
该仓库的主要价值是：
- 按浏览器操作、代码导航、上下文压缩、模型路由、安全门禁等领域整理项目。
- 标记每个项目中「Jev 在哪里做决定」。
- 链接到固定 Commit 的源码证据，减少项目描述与真实实现不一致的问题。
- 提供搜索页面和 Agent Skill，帮助开发者按场景查找参考实现。
阅读该仓库时，应把它当成案例索引，而不是 Jev 能力与性能的权威证明。项目描述、性能数据和安全性仍需要回到对应源码、测试和官方文档中逐项验证。
9. 总结
Jev 的核心不是「更小的聊天模型」，而是另一种软件接口：
给定状态和有限类型的问题，返回程序可以直接消费的概率化决策。
它适合承担 Agent 中高频、原子化、边界明确的判断，让 LLM 专注于规划和生成，让本地代码继续掌握执行与安全控制。
从工程视角看，Jev 最重要的价值不是“永远正确”，而是把不确定判断变成类型明确、概率可见、可以设置阈值和回退策略的数据。