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:
bash
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?"
}
}
}'
返回:
json
{
"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):
python
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 的错误路由)。
- 多标签先竞争后验证(见上)。
- 能力边界纪律:只问文本里可观察的模式;不问"哪个模型能答对",不问"失败在哪一步"。
五、复现
测试代码与数据已开源(去掉密钥后):
jev/
├── eval/ # 评测框架:12 个脚本、24 份报告
├── mcp_server.py # 封装成 MCP 工具:注入扫描 / 命令风险 / 候选重排
├── skill_router.py # skill 门控(Jev 选 skill 并加载)
└── REPORT.md # 完整技术报告
bash
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 真正需要的:一个便宜、稳定、可以每条消息都过一遍的快思考层。