LLM 路由和护栏怎么做？Jev 与大语言模型的协作实例

利益与证据披露：PandaNpc 正在开发使用 Jev 的 Agent 决策层。下文分别引用 TypeSafe 官方文档、官方 cookbook，以及我们仓库中的真实 Jev 调用和合成场景校准。我们的校准使用脚本化假 LLM provider，不能代表真实用户流量或完整生产链路的性能。

LLM 路由可以这样做：先让 Jev 判断请求属于哪类、风险有多高，再由代码决定交给普通函数、专业 LLM，还是人工审阅。 Jev 也可以放在检索与生成之间筛选证据，或放在 LLM 输出之后检查结果。它返回的是封闭选项、评分和概率；开放式回答、代码生成与长推理仍由 LLM 完成。TypeSafe 对 coding agents 的说明明确指出，Jev 不能直接替换 Claude Code 或 Codex 背后的聊天模型。

这篇文章用一个客服请求、一条 RAG 问答流水线和我们自己的 Agent 校准记录，解释两类模型究竟在哪里交接，以及低置信结果为何必须有明确去处。

Jev 能判断什么，LLM 继续负责什么？

截至 2026 年 9 月 23 日，TypeSafe 模型页列出的稳定模型为 jev-1.13.0。API 接受一个 state 和一组 questions，通过 POST /v1/systemone 返回对应的结构化 answers。jev-latest 当日指向 1.13.0，但别名会随版本改变；校准过阈值的系统宜固定版本并记录响应中的实际模型 ID。

Noul 没有独立的 confidence 字段；不能把一个 Noul 概率直接写成“模型置信度”。Score 也不该拿来计算精确金额。金额、日期比较、配额和权限检查应留在确定性程序中，官方已列出 Jev 1.13 的这些边界。

一次调用的最小形状

下面的请求形状与官方 API 参考一致，示例问题是本文构造的说明性配置，没有在本文为它做在线实测：

{
  "model": "jev-1.13.0",
  "state": {
    "message": "My order was charged twice. Please help me get a refund.",
    "account_note": "Customer asks about an order charge"
  },
  "questions": {
    "intent": {
      "type": "choice",
      "instructions": "What does state.message primarily request?",
      "criteria": {
        "refund": "Money returned for a charge",
        "information": "An explanation only",
        "other": "Neither option fits"
      }
    },
    "asks_refund": {
      "type": "noul",
      "instructions": "Does state.message explicitly ask for money back?"
    }
  }
}

实际系统还应先用代码检查扣款记录是否属于同一订单、是否允许退款。上例只用于判读用户意图；用户要求退款不等于退款资格已被证实，更不构成直接执行退款的授权。

用 Jev 做 LLM 路由：三种交接路径

TypeSafe 官方意图路由实例把客服请求先交给 Jev 判断意图与复杂度，然后由代码分流：查订单状态走数据库函数；产品问题与退换货分别走加载了不同资料的专业 LLM；复杂投诉或低置信结果进入人工队列。这正是 Jev 与 LLM 最容易理解的协作：前者给出结构化判断，后者只在需要生成解释或对话时出场。

落地时可以按下面的顺序设计，而不是让模型自由决定所有动作：

1. 先定义路径：列清楚普通函数、各专业 LLM、人工审阅能处理的请求，并给 Choice 留 other 或同类兜底选项。
2. 把事实放进 state：用户原话、账户状态、订单记录分别成字段；不要把来源不明的网页文字当系统指令。
3. 一次问窄问题：意图用 Choice，风险或紧急程度用 Score，需要确认的单点事实用 Noul。官方建议同一 state 的多个独立问题可在同一请求并行评估。
4. 由代码作最终路由：先检查权限和硬规则，再看 Jev 的概率与本业务校准过的阈值；低置信或缺证据的请求走人工或补问。
5. 记录结果并复查：保存模型版本、问题版本、概率、最终去向和人工纠错结果，才能判断阈值是否合适。

图源：TypeSafe AI《Introducing System One Models & Jev》，2026-09-15。四个工作流由 TypeSafe 自建，指标按工作流等权汇总；评测方法见 TypeSafe workflow evals。

官方这张图可以帮助理解它为何强调“把多个窄判断装进程序工作流”。图上的纵轴沿用厂商的“accuracy”命名，但其参考答案来自两个大模型的预测概率共识，并非经过人工核实的唯一正确答案；成本与指标也取决于这四个工作流及厂商的评测方法，不能换算成“任意场景都能省多少”。

检索增强生成：Jev 在 LLM 回答前筛证据

TypeSafe 的 RAG passage cookbook提供了更具体的多模型实例：OpenAI embedding 先召回段落，Jev 对每个“问题＋段落”问四个 Noul——是否相关、是否包含可用于回答的证据、是否反驳问题中的前提、是否试图给回答模型下指令。代码按顺序处理四项概率，决定把该段落放进证据区、冲突证据区，或丢弃；最后由 Claude Sonnet 5 写答案。

这一步解决了一个常见问题：向量相似度高的段落未必可用。它可能只用了相似词，也可能是一段论坛帖里夹带“忽略前文”的提示注入。cookbook 的示例将注入检查放在路由规则最前面，同时提醒阈值是针对那份语料选的起点，不是所有 RAG 应用的默认值。其演示数字来自 2026-08-27 的 jev-1.12，不能当作当前 jev-1.13.0 的新评测结果。

生成之后还可以做一层核对。TypeSafe 引文核对 cookbook先用程序找引用原文，再用 Jev 判该段是否支持、反驳或没有提及生成的主张。它能把值得复查的引文挑出来；模型判断本身仍可能出错，不能把“通过检查”写成事实保证。

我们的 Agent 校准：低置信升级会卡在哪里？

PandaNpc 仓库里，Jev 客户端、问题题库与编排器将 Jev 用在 Agent 的意图识别、候选修改打分、完成条件核对和提交判断。客户端还对超时、429、5xx 做有限重试，对请求预算与过期结果设限；执行权限由编排器和受控工具层掌握，不由 Jev 的一句判断直接授予。

我们在 2026-09-22 用 jev-1.13.0 对 19 个合成 turn 各跑一次 shadow、一次 enforce，合计 38 次运行，记录了 165 条真实 Jev 决策。这份内部校准报告及保存的真机响应使用脚本化假 LLM provider，因此这些数据只说明受控场景中的决策表现。它们不能证明真实用户请求下的整体成功率、节省比例或端到端延迟。

最有价值的发现不是平均速度，而是一个“看似安全”的门槛造成堵塞：在 enforce 的 19 个 turn 里，有 13 个在 Q2“信息是否足够开始修改”处，因为 Noul 概率落入原定的 0.15–0.85 不确定区间而升级；LLM Worker 没机会执行后续步骤。校准记录显示，34 条标注为信息充分的 Q2 决策中，许多概率在中段。报告建议把复杂的 Q2 拆成更原子的判断，或调整升级规则；这些是建议，不是已经部署的阈值。

我们的题库把入口判成 answer_only、inspect、modify 或 out_of_scope；在写入路径上，Worker 提出的候选修改先由 Score 排序，最后的内容与改动摘要再经过验收和提交判断。这些只是决策点：能否实际读写对象，仍由受控执行器按阶段发放权限。Jev 无权自己放宽工具白名单，也不能绕过提交前的一致性检查。

校准数据揭示了另一个取舍。在 shadow 模式里，Jev 会给出答案和完整分布，但不改变 Worker 原本的执行路径；在 enforce 模式里，答案会影响是否继续、升级或丢弃。把 shadow 的准确率直接当 enforce 的完成率会看错系统：Q2 的升级会提前截住任务，令后续候选打分、验收和提交题目根本没有机会出现。因此这份报告把每题分布、升级方向和最终状态分开读。

候选修改中有个具体对照：同一 turn 里，精确修改目标的候选得到 2.94 分，而用整文件覆盖的候选得到 0.38 分；高分候选被选中。这个例子只说明该合成情境下评分题区分了两个方案。反过来，一个证据被截断的候选得到 2.27 分，不能因为数值看起来“还不错”就忽略其低置信和截断标记。我们的代码将证据不全单独标识，避免模型仅凭被保留的前缀作出确定性写入判断。

我们还把“选择哪个候选”和“允许它写入”拆成两个不同步骤。候选通过 Jev 打分后，受控执行器只在 ACT/modify 阶段开放写工具；签发的一次性票据绑定工具调用 ID、当前修订号、目标对象哈希和参数摘要。候选文本就算诱导模型“忽略限制”，也拿不到越过这几项检查的工具权限。这是我们从代码级集成得到的经验：概率判断决定哪条路值得走，副作用权限则由可复查的程序条件决定。

失败路径同样要设计。客户端只有在超时、网络错误、429 或 5xx 时有限重试；取消后或超出 turn 截止时间的回答直接丢弃。若 Jev 在 enforce 模式不可用，未获降级授权时不能继续；获准走 llm_only 时，执行器锁定只读。如果分支已经发生修改才失去 Jev，编排器把整轮标为失败，而不是让后续 LLM 在缺少决策层的情况下补做写入。这些路径对用户体验有代价，却使“模型暂时不可用”不会悄悄变成“写权限照旧”。

校准报告还区分了“低置信升级”和“拒绝执行”。例如一次正确的 discard 如果置信没有达到统一的 0.85 门槛，会被记为需要用户输入；这并不等于错误放行。报告据此建议把提交和丢弃的门槛拆开，不过目前仍是建议。写工作流时必须分清错误放行、错误拒绝与待审三种结果，否则同一组数据会导出错误的阈值结论。

这个案例告诉我们，Jev 与 LLM 的配合不能只画成“Jev 先判断，LLM 再干活”。每个判断都要问：不确定区间有多宽？是否会让后续处理器永远接不到任务？若输入证据被截断，能否明确升级而非猜测？在我们的实现里，state 构建器会记录 evidence_truncated，并让调用方把缺证据路径视作不确定；计数、排序等确定性计算先在代码里完成，不交给 Jev 猜。官方 Jev 1.13 已知限制也建议把计数和算术留在代码中。

LLM 护栏应该放在哪儿？

TypeSafe 的 LLM guardrails cookbook把 Jev 放在 LLM 的输入与输出两侧。它用一组 Noul 识别不同风险，用 Score 衡量严重程度，再由代码根据策略决定放行、人工复核、阻止或转交支持。输出也要检查，因为普通输入仍可能得到不合适的生成结果。

这类护栏的边界同样清楚：Jev 可以按预先写好的问题检查内容，但不是万能安全证明。官方限制文档明确提到恶意内容可能影响判断，要求写清 criteria 并测试边界。我们的合成样本中曾做 16 次针对候选参数的注入探针，记录到 0 次排序翻转；样本太小，不能推出“抗提示注入已解决”。真正决定工具能做什么的，仍是代码里的允许列表、阶段门禁和提交前检查。

什么时候适合用，什么时候不要用？

适合 Jev 的是：候选集合已知、问题可以拆成几个短判断、软件需要概率来决定自动处理或升级人工。例如客服路由、RAG 段落筛选、Agent 候选动作评分、生成结果中的引文核对。若任务要求写一封回信、改一段代码或解释复杂推理过程，就由 LLM 接手。若任务是精确算钱、比较日期或检查访问控制，程序应直接计算。模型页还说明 Jev 只接受文本，英语是当前表现最好的训练语言；中文场景需要用自己的数据评测，不能照搬英文 cookbook 的阈值。

如果想观察真实 Agent 如何处理权限与工具调用，可以先看 PandaNpc Agent；关于编码 Agent 的边界和使用场景，也可参考 Claude Code 与 Codex 对比。

读者可用一个很小的验证集起步：准备“明显可以自动处理”“明显应拒绝”“语义模糊”“包含恶意指令”四类样本；先确定人工标注，再记录 Jev 各题概率与路由结果。成功判据不是每条都自动通过，而是自动处理路径的错误率与人工升级量都落在你能接受的范围内。若模糊样本大量卡在同一题，先检查题目是否混入多个判断、state 是否太长或阈值是否按本地数据校准。

常见问题

Jev 能替换 Claude Code、Codex 或聊天模型吗？ 不能。TypeSafe 将它定位为软件内的结构化决策模型；聊天、写作和代码生成仍需 LLM。

返回类型固定，是不是就不会犯错？ 不是。固定类型减少解析和越界输出问题，但分类、评分与事实判断依旧可能出错。低置信与高风险路径应保留人工复核。

同一请求能问几个问题？ 可以把共享同一 state 的多个独立 Choice、Score、Noul 放在一次请求中。题目各自求值，复杂判断仍应拆开，再由代码组合。

中文能用吗？ 官方称支持包括中日韩文字在内的自然语言，但英语准确度目前最好。中文工作负载需要单独验证和校准。