Jev 工程实践：在 Agent Harness 里放一个"快思考层"

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：

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?"
      }
    }
  }'

返回：

{
  "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）：

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     # 分布集中度

上手时要知道的三个限制：

1. choice 选项数上限 255，更多要分块/两阶段；
2. 只接受文本（不支持图片/音频/视频）；
3. 官方明示英语为主，中文/韩文等准确率会打折（我们的测试也验证了，见下文）。

---

三、我们的理解：它是 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 测试之后，我们总结的六条工程规律

1. criteria 就是决策边界：把"施压"和"合法维权"混进一个 criteria，模型给你 0.47 的模糊概率；拆成两个正交问题后变成 0.04 / 0.96。
2. 正交拆分 + 代码组合 > 单问句：命令门控误伤率 14.5% → 1.8%；工具相关性判定 59.5% → 77%。
3. 高分区可信，低分区不等于安全：注入检测里 ≥0.1 分的样本 90%+ 是恶意，但 0~0.1 分桶里仍有 16.6% 恶意混入——生产必须留人工复核带。
4. confidence ≠ correctness：高置信只代表模型确信它在按你的定义判断；criteria 写歪了它照样自信（我们见过 conf=1.0 的错误路由）。
5. 多标签先竞争后验证（见上）。
6. 能力边界纪律：只问文本里可观察的模式；不问"哪个模型能答对"，不问"失败在哪一步"。

---

五、复现

测试代码与数据已开源（去掉密钥后）：

jev/
├── eval/            # 评测框架：12 个脚本、24 份报告
├── mcp_server.py    # 封装成 MCP 工具：注入扫描 / 命令风险 / 候选重排
├── skill_router.py  # skill 门控（Jev 选 skill 并加载）
└── REPORT.md        # 完整技术报告

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 真正需要的：一个便宜、稳定、可以每条消息都过一遍的快思考层。