Jev 模型路由：如何给 Claude Code、Codex 和 Gemini 设定任务边界

把 Jev 接入编码 Agent，最常见的误区是让它回答“哪个模型最好”。这不是一个稳定的工程问题：任务范围、是否允许写入、验证成本和错误代价都会改变答案。

更好的用法是把它变成一个小而明确的决策器：它只输出任务该走哪条路径、是否需要批准，以及判断有多确定；Claude Code、Codex、Gemini 或其他执行模型再负责计划、改代码、调用工具和验证结果。

TypeSafe 的官方说明也划出了这条边界：Jev 不生成文本或代码，也不是编码 Agent 的替代品；它适合承担路由、分类、评分与 guardrail 这类结构化判断。查看 Jev 与编码 Agent 的职责边界

路由的产物应该是一份“操作合同”

一个可审查的路由器不只是选模型，而是为下一步声明条件。最小的输出可以包含三项：

route: quick_answer | coding_task | deep_review
approval: required | not_required
confidence: 0.00–1.00

随后由应用把这份结果映射为确定动作。例如：

路由结果	允许的后续动作
`quick_answer`	解释、定位信息、格式整理；默认不写文件
`coding_task`	处理边界明确的修改，并运行预先指定的验证
`deep_review`	先给出计划和影响范围，再执行并保留验证记录
`approval: required`	停止自动执行，等待人工确认

这里的重点不是把某个模型贴上“快”或“强”的标签，而是让团队能回答：为什么这个任务被允许走到写入、提交或外部调用？一旦规则需要调整，改的是这份合同，而不是散落在提示词里的直觉。任务要如何拆到能独立路由和验收，可参考 Codex Subagents 的任务拆分方法。

复杂度和风险必须分开判断

复杂度描述完成任务要付出多少推理与工具工作；风险描述做错后会发生什么。它们经常不同步。

• 给一个函数补注释：复杂度低、风险也低。

• 一次生产数据库迁移：描述可能很短，风险却很高。

• 分析一段长日志：复杂度可能高，但通常不需要写入权限。

因此，不要用单一分数直接选择模型。至少让路由器分别判断“需要多深的执行能力”和“这一步是否可以自动执行”。应用层再用明确的优先级处理：风险否决自动化，复杂度决定被允许后使用哪条执行路径。

if approval == "required":
request_human_approval()
elif route == "quick_answer":
run_read_only_path()
elif route == "coding_task":
run_standard_coding_path_with_tests()
else:
run_deep_review_path_with_plan_and_verification()

这段伪代码刻意把“是否批准”放在前面。否则，一个被判断为简单的任务也可能绕过本该存在的安全门。

低置信度不是失败，而是一条受控出口

路由最危险的时刻不是“不知道”，而是把不知道伪装成确定。应在调用前定义低置信度的处理方式，例如：

• 补充必要状态后重新判断，例如变更文件范围、目标环境和是否包含密钥；

• 在只读路径上继续，但禁止写入与外部工具调用；

• 升级到带计划和验证要求的执行路径；

• 直接请求人工确认。

阈值不应凭感觉设定。先收集一批历史任务，让人工标注预期路径和是否应批准；再比较 Jev 的判断与实际结果。高风险任务更应该优先优化“错误自动放行率”，而不是追求尽可能少的人工介入。

用四个指标验证路由有没有价值

路由是否值得保留，取决于它是否改善了工作流，而不是它是否看起来更聪明。测试时可同时观察：

指标	它回答的问题
首次验证通过率	任务是否被送到了合适的执行路径
人工改判率	路由规则在哪些任务上不可靠
不安全自动放行率	高风险操作是否绕过了批准流程
单个完成任务的成本与时延	分流是否真的换来了合理的资源消耗

将这些指标按任务类型拆开看。把所有任务平均后，一个对简单问答很有效、却常误判写入任务的路由器，很容易显得比实际更好。