如何为Jev构建AI代理工具链：六种角色与九条实战规则

Jev是TypeSafe AI推出的一种特殊模型——它不生成文本，只回答你提出的结构化问题，并返回概率值。开发者们正在探索如何将这个"没有记忆、没有手脚、没有声音的快速裁判"嵌入到AI代理的循环中。本文基于对上百篇社区讨论的分析，梳理出六种典型的Jev应用模式、一个被大规模审计的失败案例，以及九条来自实战的工程规则。

Jev的核心机制与定位

Jev的运行方式与众不同。你向它发送一个状态和一组带类型的问题（从选项中选择、在量表上打分、判断为真的概率），它会在一次并行请求中回答所有问题。每个答案是一组概率值，你的代码可以据此做出分支判断。一次调用只需几百毫秒，成本仅为几分之一美分。

这个模型没有对话能力，不能调用工具，也不会记住上一次调用。因此，任何超出单次决策的逻辑都必须由你的代码来维护。简而言之，Jev是一个快速裁判——它审视你提供的状态，从你列出的选项中回答你写下的问题，其余一切由代码完成。

所以，一个Jev工具链包含三个部分：你放入状态的内容、你如何措辞问题并构建选项、以及你的代码如何处理答案。

什么是带类型的问题（typed questions）？

所谓"带类型"，是指每个问题都预先声明了答案的取值空间——是从有限选项中择一（分类）、在连续量表上打分（回归到某个区间），还是判断某命题为真的概率（二元或多值概率）。这种约束让模型无法用自然语言"发挥"，只能输出归一化后的概率分布。相比让 LLM 自由生成再解析文本，带类型问题把解析错误、格式漂移和幻觉统统排除在外，也让下游代码可以直接用 argmax 或阈值比较来做分支，而不必写正则或再调用一次模型。代价是灵活性：你必须在调用前就穷举出所有可能选项，一旦真实情况落在选项之外，模型只能被迫在错误菜单里挑一个，这正是后文"规则二"强调要放入"以上都不是"的原因。

为什么是"一次并行请求"而非逐题调用？

Jev 把同一请求中的所有问题当作一批并行推理任务处理，二十个问题与一个问题的延迟几乎相同，且输出 token 不单独计费，这是它相对逐题调用 LLM 的核心成本优势。但并行也带来一个结构性限制：问题之间彼此不可见，后续问题无法引用前面问题的答案。因此凡是存在依赖关系的判断——比如"先决定是否搜索，再根据搜索结果判断是否完成任务"——必须拆成两次调用，由代码在中间串联。理解这一点是正确设计 Jev 工具链的前提：它擅长的是对同一份状态的横向多角度体检，而非纵向的多步推理链。

六种典型的Jev应用角色

分析社区中最热门的讨论后，Jev在工具链中的位置可以归纳为六种角色。在所有这些模式中，Jev从不自主行动：代码构建选项列表，Jev做出选择，代码执行结果。每种模式也都定义了当Jev不确定时的处理规则。

1. 路由器（Router）

在昂贵的模型运行之前，Jev决定调用哪个模型。开发者@dani_avila7发布了一个Claude Code修改版，用Jev分类子代理模型、努力程度和主模型。关键细节是：主模型只在会话开始时路由，以避免破坏缓存。LangChain以ModelRouterMiddleware的形式提供了相同思路。

2. 安全门（Gate）

对每个命令执行前的安全检查。@rauchg报告称，fx自动模式审查器在Jev上的运行速度比之前使用的小型LLM快5到18倍，且更准确。LangChain的AutoModeMiddleware是开源版本。一个能在几百毫秒内响应的安全门可以每次调用都运行，而慢速的安全门最终会被关闭。

3. 选择器（Selector）

用于计算机操作和浏览器操作。Jev看不到屏幕——工具链负责观察、构建候选列表，Jev选择一个ID，然后工具链执行并重新观察。@trycua给出了最清晰的循环描述：驱动观察、感知解析（如需要）、客户端构建候选、Jev选择一个ID、驱动执行并验证新状态。@awlevin用OCR框作为选项列表实现了这一点，据其数据每步约0.003美元、1.5秒，并在需要输入文字时交接给小型LLM。

4. 验证器（Verifier）

@omarsar0将Jev放在其工具链的/goal功能后面：检查目标是否真正完成。这比之前使用的推理模型便宜得多，因此可以更频繁地运行。他帖子下的一条回复很有价值：在代理声称"完成"时检查抓住了虚假完成，但每轮都检查会"开始否决代理需要尝试的步骤"。

5. 顾问（Advisor）

@kunchenguid的compact-adviser实际上不压缩任何东西。它只回答一个问题：你是否处于可以安全压缩的任务边界。他手工标注了40个真实会话的检查点，据此调整提示词，并让阈值动态变化：当窗口大部分为空时偏向精确率，随着窗口填满转向召回率，因为错误地说"否"的代价在增长。

6. 分诊（Triage）

@redp314用一次调用审查PR。14项类型化检查返回概率值：硬编码密钥、涉及认证、删除测试、描述是否匹配差异。代码将其转化为BLOCK/安全审查/小问题/合并，关键检查上0.35到0.65之间的任何结果都会转给人工或更大的模型。他的成本是每个PR 0.00007美元。

一个被审计的失败案例

社区中最火的一篇帖子（360万次浏览）展示了第七种角色：压缩。对每个工具调用打分，丢弃无关的，无需摘要提示词。一条转发声称一个会话从近100万token降到8.6万token，仅用一秒。

然后人们开始测量它。@Teknium在公开的Nous压缩评估上运行后发现：评分学到的东西可以用一行代码写出来——移除工具调用。而且它会衰减：第一轮释放一半窗口，下一轮释放四分之一，然后更少，因为它唯一能移除的就是已经移除过的东西。

他的数据对比普通摘要：保留115K token对55K，召回率76%对79%，在相同预算下Jev排序与普通近期性方法打平，77.8对77.8。独立测试者@servasyy_ai报告了相同的模式：当他用总是回答0的假模型替换Jev时，Claude Code压缩插件的行为完全相同。原帖的多条回复还指出了第三个问题：每次过滤历史记录都会导致提示缓存未命中。

@Teknium明确表示这是该压缩策略的问题，而非Jev本身的问题。在它走红之前没有人测量过这个工具链，从外部看，无论内部评分是否有效，演示看起来都一样。

为什么"提示缓存未命中"会成为致命问题？

主流 LLM 推理服务对重复出现的前缀内容提供缓存，命中后这部分 token 按极低折扣价计费甚至免费。代理循环中，系统提示词和早期对话通常构成一个稳定且庞大的前缀，正是缓存的主要受益者。而压缩工具链的核心动作是重写历史——删除或替换中间的对话内容，这会改变前缀，使缓存全部失效，后续每一轮都要按全价重新支付整个上下文。所谓"省下的 token"往往被重新计算的缓存成本抵消。这解释了为什么会话中途切换主模型的路由器同样被诟病：模型变了，缓存前缀的归属也随之改变。任何编辑历史或更换模型的方案，都必须把缓存重算成本纳入收益计算，否则账面节省可能只是幻觉。

九条实战工程规则

规则一：代码构建菜单，Jev指路

绝不让它凭空发明选项——它做不到。每个有效的选择器都在代码中构建候选列表：来自DOM、OCR框、可访问性树、检索器或工具注册表。并且每次操作后都要重建，因为一次点击会改变屏幕上的内容。否则，正如@0xCodila所说，模型是在从昨天的菜单中点菜。每个问题的选项上限是255个，更大的列表需要先用代码过滤明显不匹配的，再对剩余项打分，最后在候选名单中选择。

规则二：把退出选项放进菜单

Jev总会选一个东西。如果"以上都不是"不是选项，你就会得到一个自信的错误选择。@CodingGarden构建了一个完全没有LLM的工具调用聊天机器人，在选项列表中处理这个问题：一个选项说"完全没有提到设备或房间"，另一个说"多个工具调用可以满足此请求"，任一选项都会触发后续问题而非直接操作。

规则三：提供它无法知道的事实

它没有记忆，也没有时钟。@ctatedev发现Jev不知道今天的日期，将日期加入状态后，他的一个答案从0.35跳到了0.94。它也只接受文本，上下文窗口约32K token。这个限制正是@servasyy_ai的压缩和磁盘清理实验失败的地方：为了适应限制必须削减内容，而一旦内容被削减，模型就是在盲判。如果证据无法放入状态，答案就是附带概率的猜测。

规则四：一次请求问完所有问题

同一请求中的问题是并行回答的，所以二十个问题大约和一个问题耗时相同，且输出token是免费的。Rosson的PR审查是一次调用中的14项检查。需要注意的是：问题之间无法读取彼此的答案。如果某个决策依赖于搜索结果，先运行搜索。

规则五：上线前定义"不确定"的含义

上述每位构建者都必须定义这一点：Rosson将关键检查上0.35到0.65之间的结果转给人工或更大的模型；@DeRonin_设定低于0.5升级、0.85以上才执行不可逆操作；Kun Chen随着上下文窗口填满而移动阈值；@servasyy_ai手工标注了300个判断，发现所有255个置信度90%以上的答案都是正确的，而中间地带的样本太少无法得出结论。置信度不是准确率百分比，把它当作在哪里花费昂贵模型资源的指南。

规则六：备一个小型LLM

Jev不会写文本。一旦任务需要文字（输入URL、填写表单字段、解释发现），工具链就要交接。@awlevin为type_text调用一个小模型，Browser Use对输入字段也这样做，Rosson只对Jev标记的PR运行第二遍LLM。结果是昂贵模型的调用频率大大降低。

规则七：尊重提示缓存

在会话中途切换主模型的路由器会丢弃缓存的提示词，节省也随之消失。这就是为什么Claude Code路由器只在会话开始时路由主模型，也是为什么压缩演示的回复中充满了"你破坏了缓存"的评论。任何编辑历史或切换模型的工具链都必须将缓存未命中的成本计算在内。

规则八：在关键节点检查，而非每轮都查

廉价的检查诱使你不断运行它们。验证器的报告说不要这样做：在代理声称"完成"时检查能抓住虚假完成，但每轮都检查会开始否决代理需要尝试的步骤。把裁判放在决策点：不可逆工具调用之前、声称完成时、任务边界处。

规则九：相信之前先用笨基线测量

压缩演示与"保留最近消息"打平。一个插件在模型总是回答0时表现相同。经得起考验的项目都是先测量的：Kun Chen在调整提示词前手工标注了40个会话，LangChain在写一个字之前对每个裁判的每个案例运行了100次。一个简单的测试：用固定答案或抛硬币替换Jev后重跑。如果结果看起来一样，Jev就没有贡献。另外，在责怪模型之前检查循环的其余部分。在@0xCodila收集的Browser Use数据中，将浏览器协议调用从1092次减少到101次对任务时间的改善比模型替换更大。

来自个人测试的补充

我在一个拥有免费裁判的任务上测试了其中一些想法——国际象棋，其中引擎可以给每个决策打分。有两个未在其他地方看到的结果：当Jev在自己的首选之间犹豫时，其概率接近抛硬币，但以两种顺序询问"A比B好吗"，大约三分之二的情况下能选出更好的那个。另外，在拥有相同答案的情况下，对是/否否决权重的加权远高于简单乘法，可以将损失减少近一半，且零额外调用。这是来自单一领域的小样本，应视为线索。但它确实让我相信，代码如何处理答案值得与提示词同样多的关注。

模型成本现在几乎为零，工作已经转移到了工具链上。

不对称判断与"翻转顺序"技巧的直觉

作者提到的两个发现，实际都指向同一个认知偏差：模型对"A 优于 B"和"B 优于 A"这两个等价命题的回答并不对称。当 Jev 在首选之间犹豫、概率接近 0.5 时，分别以两种顺序提问并取一致结果，相当于两次独立采样对冲了位置偏差，因此约三分之二的情况下能选出真正的更优项。这本质上是把一次低置信度判断转化为一次多数投票。而对比"是/否否决权加权"远强于简单乘法，则说明概率值不应被当作独立的乘数直接相乘——否决类信号带有特殊权重，简单相乘会稀释它的警戒作用。这类线索虽来自国际象棋单一领域，但提示了同一件事：答案的后处理逻辑与提示词设计同样重要。