22,500 次 API 调用、$2.19、10 个公开数据集。本文先讲 Jev 是什么、怎么用，再讲我们对它的理解和想落地的场景，最后用测试数据说说我们对它的"再认知"。
一、Jev 是什么：一个"决策模型"，不是聊天模型
Jev 是 TypeSafe AI 发布的第一个 System One 模型（当前 jev-1.13.0）。它的行为形态和 LLM 完全不同：
| 聊天 LLM | Jev | |
|---|---|---|
| 输入 | prompt | state（上下文）+ 类型化 questions |
| 输出 | 自由文本 | 类型化答案 + 概率分布 + 置信度 |
| 用途 | 生成、推理、对话 | 分类、检测、评分、路由、验证 |
| 可靠性 | 可能胡说 | 输出被约束在你声明的选项内 |
| 延迟/成本 | 秒级 / 高 | ~0.3s / 约 $0.00004 一次 |
| 上下文 | 很长 | state + questions 共享 ~32k tokens |
三种原语，对应三种职责：
| 原语 | 回答什么 | 返回 | 我们的定位 |
|---|---|---|---|
| noul | 是/否 | 0~1 概率 | 门卫：放行 / 拦截 / 升级 |
| choice | 从闭集选一个 | 选中项 + 概率分布 + confidence | Router：意图、skill、agent、工具 |
| score | 按有序 rubric 打分 | 概率加权分数 + legend | 排序器：RAG 召回、记忆、候选重排 |
一句话理解：LLM 负责"生成"，Jev 负责"判断"——而且是带概率、能被代码直接消费的判断。
（官方对原理只公布了三个词：新架构、新 sampler、RLCD 训练算法，细节未公开。本文只谈可观察行为。）
二、怎么用：一次 HTTP 调用
最底层就是一个 POST：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
curl -X POST https://api.typesafe.ai/v1/systemone \ -H "Authorization: Bearer $TYPESAFE_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "state": "I was charged twice for order A-104. Please refund the duplicate.", "model": "jev-latest", "questions": { "refund": { "type": "noul", "instructions": "Does the message ask for money back?" } } }' |
返回：
|
1 2 3 4 5 |
{ "model": "jev-1.13.0", "answers": { "refund": { "type": "noul", "noul": 0.99 } }, "usage": { "input_tokens": 312, "output_tokens": 18 } } |
实际工程里用 SDK 更顺手（Python：pip install typesafe-sdk）：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
from typesafe_sdk import Choice, Noul, Score response = client.system_one( state={"task": "帮我查一下飞书文档里的内容"}, questions={ "skill": Choice( instructions="哪个 skill 最适合处理 `task`？", criteria={"lark-doc": "飞书云文档读写", "ego-browser": "浏览器操作"}, ), }, ) response.answers["skill"].choice # "lark-doc" response.answers["skill"].probabilities # 各选项概率 response.answers["skill"].confidence # 分布集中度 |
上手时要知道的三个限制：
- choice 选项数上限 255，更多要分块/两阶段；
- 只接受文本（不支持图片/音频/视频）；
- 官方明示英语为主，中文/韩文等准确率会打折（我们的测试也验证了，见下文）。
三、我们的理解：它是 harness 的"快思考层"
Agent harness 的本质是在循环里不停做窄判断：这条消息安全吗？该加载哪个 skill？这个命令能跑吗？检索回来的哪些片段该进上下文？回答满足请求吗？
这些判断高频、边界明确、要概率——如果每次都调前沿大模型，延迟和成本都不可接受。卡尼曼的"快/慢系统"刚好对上：Jev 是 System One（快、便宜、每条都过一遍），大模型是 System Two（慢、贵、负责复杂推理）。
想落地的场景（按 harness 生命周期）
输入层
- 注入扫描：用户消息 / 工具返回 / 检索内容（工具输出里藏指令是当前最薄弱的攻击面）
- 意图识别（选流程）与请求风险分级（高风险升级确认）
上下文层
- 文件/片段/记忆按相关性重排（RAG 精排层）
- 压缩前判断哪些内容必须保留
动作层（最核心）
- skill / 工具 / agent 路由：目录已知时选一个
- Bash 命令风险门控：破坏性 / 触密 / 外发 / 不可逆
- 工具调用一致性与参数校验；局部循环检测（重复、无进展）
输出层
- 回答满足度校验、引用/事实是否被上下文支持
离线层
- 轨迹批量打标（只打局部标签：工具报错、格式违规、重复动作）
一句话：模型提供校准过的局部判断，代码持有控制流。
四、数据实证：测试之后，我们修正了这些认知
我们搭了一套 harness 化评测（数据集 → 构造 questions → 并发调用 → 指标报告），跑了 10 个公开数据集、约 22,500 次调用，总成本 $2.19。
4.1 超出预期的强项
① 间接注入检测（最强项）——InjecAgent 真实数据，1,105 条：
| 阈值 | 精确率 | 召回率 | 良性误报率 |
|---|---|---|---|
| 0.50 | 100% | 89.8% | 0% |
| 0.10 | 100% | 100% | 0% |
② 检索重排——BEIR SciFact，60 查询 × 15 候选：
| 排序器 | Recall@5 | MRR | Hit@1 |
|---|---|---|---|
| BM25 | 74.2% | 0.622 | 50.0% |
| Jev 重排 | 90.0% | 0.843 | 78.3% |
③ 目录路由——SNIPS 意图 97.9%、Banking77（77 类）80.3%、MetaTool（199 工具目录）k=5 相似干扰 96.5%。
④ 命令风险门控——自建 130 条命令集，4 个正交 noul + 代码组合：危险拦截 100%、误伤率 1.8%（单问句方案误伤 14.5%）。
4.2 明确不适合的方向
| 任务 | 结果 | 结论 |
|---|---|---|
| 预测"该用强模型吗" | 准确率 51%（无信号） | 对"模型能力边界"的元推理不是它的活 |
| 长轨迹失败归因 | AUROC 0.56 ≈ 随机 | 跨步骤因果 + 长上下文不适合 |
| 非英语任务 | 韩语 R@1 48.9% vs 英语 61.5% | 语言折扣真实存在，中文场景需专项验证 |
4.3 一次完整的实战：Skill Router 从 60% 到 76%
背景：skill 目录越塞越大，我们想让 Jev 在请求进来时决定"要不要加载、加载哪个"。
用 SkillRetBench（501 个真实 skills、1,250 条查询、官方附带基线表）做同数据集同口径对比：
| 指标（macro） | BM25 | 官方 LLM 基线 | Jev（初版） | Jev（最终版） |
|---|---|---|---|---|
| Recall@1 | 38.0% | 30.2% | 60.4% | 75.8% |
| Recall@10 | 59.8% | 55.6% | 87.6% | 93.0% |
| nDCG@10 | 53.4% | 45.1% | 60.3% | 70.2% |
R@1 是最强基线的 2 倍。但过程中有个"失败得很值"的实验：
- v1 单选：每块选一个 → 多技能组合（一次需要选 2~3 个技能）只有 9%；
- v2 多选（每个候选单独问 noul）：只到 15%，比单选还差——诊断发现 noul 分数全挤在 0.5x，独立打分没有竞争性，排名变成噪声；
- v3 混合：先让 choice 在小范围里"竞争"出候选（每块 top-3 → 15 个），再对这 15 个用 noul 逐个"验证"是否进集合 → 多技能组合直接到 81%。
这条经验后来成了我们最重要的工程规律之一：多标签判断 = 先 competition 后 verification。
4.4 与"最好的模型框架"比是什么水平
同一候选集（SkillRouter 论文 top-20）上的公开数据：GPT-4o-mini 当 listwise judge 只有 67.3%、GPT-5.4-mini 66.0%、通用 reranker Qwen3-Reranker-8B 71.4%，而专用微调流水线 74.0%。论文原话是 LLM-as-judge "not competitive"。
通用大模型直接做排序，打不过专用重排器。 而 Jev 零样本、无训练，在"金标在候选集内"的条件下命中 86.9~89.3%，处于同一档位甚至更高（口径不同，供参考）。
4.5 测试之后，我们总结的六条工程规律
- criteria 就是决策边界：把"施压"和"合法维权"混进一个 criteria，模型给你 0.47 的模糊概率；拆成两个正交问题后变成 0.04 / 0.96。
- 正交拆分 + 代码组合 > 单问句：命令门控误伤率 14.5% → 1.8%；工具相关性判定 59.5% → 77%。
- 高分区可信，低分区不等于安全：注入检测里 ≥0.1 分的样本 90%+ 是恶意，但 0~0.1 分桶里仍有 16.6% 恶意混入——生产必须留人工复核带。
- confidence ≠ correctness：高置信只代表模型确信它在按你的定义判断；criteria 写歪了它照样自信（我们见过 conf=1.0 的错误路由）。
- 多标签先竞争后验证（见上）。
- 能力边界纪律：只问文本里可观察的模式；不问"哪个模型能答对"，不问"失败在哪一步"。
五、复现
测试代码与数据已开源（去掉密钥后）：
|
1 2 3 4 5 |
jev/ ├── eval/ # 评测框架：12 个脚本、24 份报告 ├── mcp_server.py # 封装成 MCP 工具：注入扫描 / 命令风险 / 候选重排 ├── skill_router.py # skill 门控（Jev 选 skill 并加载） └── REPORT.md # 完整技术报告 |
|
1 2 3 4 5 |
git clone https://github.com/Aitejiu/jev-harness-lab cd jev-harness-lab/jev uv venv --python 3.12 .venv && uv pip install -r requirements.txt # 在仓库根目录放 .env：TYPESAFE_API_KEY=<你的key> .venv/bin/python eval/run_skillretbench.py --variant hybrid --per-setting 100 |
全部实验：~22,500 次调用、52M tokens、$2.19。所有数据集公开可复现；部分官方基线为模拟实现（文中已注明）；阈值需在自己的数据上重新标定。
结语
把 Jev 放进 harness 的正确姿势，不是"让模型做决定"，而是：
模型提供校准过的局部判断，代码持有控制流。
它能做那些"人不假思索、但代码写不出来"的判断——这句话有没有攻击性、这个片段相不相关、这个请求该走哪条路。它做不了把判断串成因果链的事。
这恰好是一个 harness 真正需要的：一个便宜、稳定、可以每条消息都过一遍的快思考层。
