# 从一行「聪明的 if」到会自己决策的 AI 代理 > 我们花了两年时间，把越来越大的语言模型塞进软件的每一个判断里。但也许，软件真正需要的从来不是"会写文章"的模型，而是一个"只做判断题"的模型。 如果你也在写 AI 软件，大概率遇到过这个尴尬：为了让程序"聪明一点"，你把一个个大模型挂在了每一个 `if` 前面。结果呢——响应慢了 800 毫秒，账单涨了 30 倍，输出还经常不稳定，同一个输入两次给出不同答案。 TypeSafe.ai 的旗舰模型 **Jev** 给出了一条完全不同的路：把"判断"这件事，从生成式大模型里拆出来，交给一个**只做结构化决策、返回概率、每次成本不到一分钱**的"System One"模型。 这篇文章拆清楚三件事：Jev 到底是什么、它的三种问题原语怎么用 --- ## 我们滥用大模型做"判断题" 在聊方案前，先承认痛点。当软件需要一个**有边界的判断**时——这条工单该分给谁？这句用户输入是不是提示注入？——我们习惯性地把整个 LLM 请出来。 这带来三个结构性问题： | 痛点 | 表现 | 代价 | | :--------------- | :----------------------------- | :----------------------------------------- | | **贵** | 一次 yes/no 判断也要跑完整推理 | 100 万次 yes/no 在 SOTA 模型上要**$3,500** | | **慢** | 生成式推理链路长 | 每个判断拖慢主流程数百毫秒 | | **不确定** | 输出是自然语言，要再解析 | 同样输入多次结果不同，难以工程化 | 核心矛盾是：**我们要的是一个可被代码消费的类型化答案，但给的却是一个会写散文的生成器。** --- ## Jev —— "它不写，它只判断" TypeSafe.ai 对自己的定位非常清醒： > **It does not write. It decides.（它不写内容，它做决策。）** Jev 是 TypeSafe 的 **System One** 模型。你向 API 发送一个 `state`（状态）和一组**类型化问题**，大约 300 毫秒后，你拿回**类型化的答案 + 概率**，而不是一段文本。代码可以直接拿这些概率去做分支判断。判断可以无处不在,每次按键、每次工具调用、每个代理轮次，都能嵌一个决策，而不用纠结成本。 ### 三种问题原语 Jev 把"判断"严格收敛成三种类型，确保输出永远是代码能直接消费的结构化数据： | 类型 | 你问什么 | 你得到什么 | 典型场景 | | :--------------- | :------------------------------------ | :----------------------------------------------------------------------- | :---------------------- | | **Noul** | 一个是/否问题（可附 yes/no 标准） | `yes` 的概率（0–1） | 门控、标志位、聪明的 if | | **Choice** | 从你定义的（最多 255 个）选项里选一个 | 选中项、每个选项概率、`confidence` | 分类、路由 | | **Score** | 在 2–10 个描述的层级中定位 | `score`（可落于层级间）、`legend`、`probabilities`、`confidence` | 评分、风险、严重程度 | 还有一个贯穿始终的机制——**置信度（Confidence）**。Jev 返回答案的同时，附上一个独立的"我有多大把握"信号。于是代码有了第二个坐标轴：答案告诉你**"是什么"**，置信度告诉你**"要不要照做"**。 --- ## 从 if 到自主代理 ### 纯代码调用 Jev 代码主控，Jev 做有边界的判断。 - **L1 单点决策**：最朴素的"聪明 if"，用 `noul` 做是/否判断——比如拦截提示注入。 - **L2 多选分类**：一次调用里并行问多个 `choice`，对工单做分流。 - **L3 复合评分**：每个因素一个 `score`，权重留在代码里——比如工单优先级 = 紧急度×0.4 + 影响面×0.3 + … - **L4 置信度门控**：答案说"是什么"，置信度说"执不执行"。`<0.5` 交人工，`>0.9` 免确认自动跑。 - **L5 意图与模型路由**：在昂贵的模型 / 浏览器 / 人工之前，先做一个廉价的 Jev 决策来分流。 ### 代理无感知的钩子 把 Jev 藏进 coding agent 的事件钩子里，代理自己并不知道在被检查。 - **L6 护栏钩子**：植入 `tool_call` / `tool_result` 钩子，危险命令在代理无感的情况下被静默阻断。 - **L7 该不该压缩**：每轮结束自动问 4 个问题，判断上下文是否该压缩，代理完全不知情。 ### 代理主动调用的工具 Jev 从"看不见的保镖"变成"代理主动伸手去拿的工具"。 - **L8 廉价读文件**：给代理 `ask_jev_file_*` 工具，让它**不加载文件本身**也能问关于文件的问题，省 context 又省钱。 - **L9 规模化文件**：对数百个文件每个并行发一次 Jev 调用，再只打开最相关的那个。 - **L10 自主化 Jev**：只暴露一个 `ask_jev` 工具，代理自己传 `state`、`paths`、`command`，**甚至自己编写问题**——自主跑测试、分类失败、给自己的 diff 打分。 --- ## 分工，各司其职 把十级阶梯抽象出来，真正有价值的不是某一层，而是它暗示的**职责划分**： | 角色 | 负责什么 | 不该负责什么 | | :-------------- | :----------------------- | :----------------------- | | **代码** | 数字、阈值、确定性逻辑 | 模糊的有边界判断 | | **Jev** | 有边界的判断 | 开放推理、写文章 | | **Agent** | 需要推理和创作的开放工作 | 廉价、高频、需确定的判断 | 一个常被忽视的洞见：**不要为了"让 AI 更自主"就把所有判断塞给大模型。** 把有边界的判断下沉给 Jev，把昂贵模型的算力留给真正需要推理和写作的开放任务，整套系统的成本、延迟、可预测性同时改善。 Loading... # 从一行「聪明的 if」到会自己决策的 AI 代理 > 我们花了两年时间，把越来越大的语言模型塞进软件的每一个判断里。但也许，软件真正需要的从来不是"会写文章"的模型，而是一个"只做判断题"的模型。 如果你也在写 AI 软件，大概率遇到过这个尴尬：为了让程序"聪明一点"，你把一个个大模型挂在了每一个 `if` 前面。结果呢——响应慢了 800 毫秒，账单涨了 30 倍，输出还经常不稳定，同一个输入两次给出不同答案。 TypeSafe.ai 的旗舰模型 **Jev** 给出了一条完全不同的路：把"判断"这件事，从生成式大模型里拆出来，交给一个**只做结构化决策、返回概率、每次成本不到一分钱**的"System One"模型。 这篇文章拆清楚三件事：Jev 到底是什么、它的三种问题原语怎么用 --- ## 我们滥用大模型做"判断题" 在聊方案前，先承认痛点。当软件需要一个**有边界的判断**时——这条工单该分给谁？这句用户输入是不是提示注入？——我们习惯性地把整个 LLM 请出来。 这带来三个结构性问题： | 痛点 | 表现 | 代价 | | :--------------- | :----------------------------- | :----------------------------------------- | | **贵** | 一次 yes/no 判断也要跑完整推理 | 100 万次 yes/no 在 SOTA 模型上要**$3,500** | | **慢** | 生成式推理链路长 | 每个判断拖慢主流程数百毫秒 | | **不确定** | 输出是自然语言，要再解析 | 同样输入多次结果不同，难以工程化 | 核心矛盾是：**我们要的是一个可被代码消费的类型化答案，但给的却是一个会写散文的生成器。** --- ## Jev —— "它不写，它只判断" TypeSafe.ai 对自己的定位非常清醒： > **It does not write. It decides.（它不写内容，它做决策。）** Jev 是 TypeSafe 的 **System One** 模型。你向 API 发送一个 `state`（状态）和一组**类型化问题**，大约 300 毫秒后，你拿回**类型化的答案 + 概率**，而不是一段文本。代码可以直接拿这些概率去做分支判断。判断可以无处不在,每次按键、每次工具调用、每个代理轮次，都能嵌一个决策，而不用纠结成本。 ### 三种问题原语 Jev 把"判断"严格收敛成三种类型，确保输出永远是代码能直接消费的结构化数据： | 类型 | 你问什么 | 你得到什么 | 典型场景 | | :--------------- | :------------------------------------ | :----------------------------------------------------------------------- | :---------------------- | | **Noul** | 一个是/否问题（可附 yes/no 标准） | `yes` 的概率（0–1） | 门控、标志位、聪明的 if | | **Choice** | 从你定义的（最多 255 个）选项里选一个 | 选中项、每个选项概率、`confidence` | 分类、路由 | | **Score** | 在 2–10 个描述的层级中定位 | `score`（可落于层级间）、`legend`、`probabilities`、`confidence` | 评分、风险、严重程度 | 还有一个贯穿始终的机制——**置信度（Confidence）**。Jev 返回答案的同时，附上一个独立的"我有多大把握"信号。于是代码有了第二个坐标轴：答案告诉你**"是什么"**，置信度告诉你**"要不要照做"**。 --- ## 从 if 到自主代理 ### 纯代码调用 Jev 代码主控，Jev 做有边界的判断。 - **L1 单点决策**：最朴素的"聪明 if"，用 `noul` 做是/否判断——比如拦截提示注入。 - **L2 多选分类**：一次调用里并行问多个 `choice`，对工单做分流。 - **L3 复合评分**：每个因素一个 `score`，权重留在代码里——比如工单优先级 = 紧急度×0.4 + 影响面×0.3 + … - **L4 置信度门控**：答案说"是什么"，置信度说"执不执行"。`<0.5` 交人工，`>0.9` 免确认自动跑。 - **L5 意图与模型路由**：在昂贵的模型 / 浏览器 / 人工之前，先做一个廉价的 Jev 决策来分流。 ### 代理无感知的钩子 把 Jev 藏进 coding agent 的事件钩子里，代理自己并不知道在被检查。 - **L6 护栏钩子**：植入 `tool_call` / `tool_result` 钩子，危险命令在代理无感的情况下被静默阻断。 - **L7 该不该压缩**：每轮结束自动问 4 个问题，判断上下文是否该压缩，代理完全不知情。 ### 代理主动调用的工具 Jev 从"看不见的保镖"变成"代理主动伸手去拿的工具"。 - **L8 廉价读文件**：给代理 `ask_jev_file_*` 工具，让它**不加载文件本身**也能问关于文件的问题，省 context 又省钱。 - **L9 规模化文件**：对数百个文件每个并行发一次 Jev 调用，再只打开最相关的那个。 - **L10 自主化 Jev**：只暴露一个 `ask_jev` 工具，代理自己传 `state`、`paths`、`command`，**甚至自己编写问题**——自主跑测试、分类失败、给自己的 diff 打分。 --- ## 分工，各司其职 把十级阶梯抽象出来，真正有价值的不是某一层，而是它暗示的**职责划分**： | 角色 | 负责什么 | 不该负责什么 | | :-------------- | :----------------------- | :----------------------- | | **代码** | 数字、阈值、确定性逻辑 | 模糊的有边界判断 | | **Jev** | 有边界的判断 | 开放推理、写文章 | | **Agent** | 需要推理和创作的开放工作 | 廉价、高频、需确定的判断 | 一个常被忽视的洞见：**不要为了"让 AI 更自主"就把所有判断塞给大模型。** 把有边界的判断下沉给 Jev，把昂贵模型的算力留给真正需要推理和写作的开放任务，整套系统的成本、延迟、可预测性同时改善。 最后修改：2026 年 10 月 02 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏