架构师（JiaGouX）
我们都是架构师！
架构未来，你来不来？
人的一生，几乎都在不断判断、不断做决定。早上看天气决定带不带伞，看到漂亮妹子要不要上去搭讪？工作中看到一个异常决定是继续观察，还是马上处理。同事找你借钱，你是不借还是不借呢？
很多时候，答案并不需要一篇完整的解释，只需要在几个选项里做出一个足够可靠的选择。Agent 也一样。它真正消耗的调用，往往不只在最后生成回复，还花在运行过程中的一连串小问题上：
这张工单该进哪个队列？
这条命令属于哪种风险？
检索到的片段真的回答了问题吗？
测试通过以后，任务可以结束了吗？这些问题需要理解自然语言，却不需要生成一段自然语言。过去它们常常和规划、写作、工具调用一起交给通用大模型，再从回复里解析出一个标签、一个布尔值或一个分数。
TypeSafe 于 2026 年 9 月 15 日公开了 Jev，并将它归入 System One Model。Jev 接收一段文本或 JSON 状态，按照预先声明的问题和答案空间返回类型化结果与概率。它不负责写文章，也不负责把任务从头做到尾。
把它放进 Agent 架构里看，变化落在一个很具体的地方：语义判断可以从生成调用里单独拿出来，成为运行时能记录、评测和替换的一层。
生成文字、做语义判断、执行动作，处在同一条链路的不同位置
先看一条 Agent 运行链
拿客服工单举例。用户说：“我的卡被扣了两次，昨天还没退款。”系统需要理解这句话，找到订单，查询退款状态，还要决定后续路径。
通用大模型适合做这些工作：提取信息、理解上下文、规划下一步。运行时还会遇到一些更窄的问题：工单属于支付、技术还是销售？是否紧急？要不要转人工？检索到的政策条款能不能支撑当前判断？
如果每个问题都调用通用大模型，调用链大致是：输入上下文，生成一段文字，解析文字，检查格式，失败后重试。问题本身可能只有三个候选答案，系统却付出了完整生成链路的代价。
Jev 放在中间这一段：
当前状态
↓
通用模型：理解、规划、生成
↓
Jev：选择、评分、判断
↓
策略代码：比较阈值、组合条件、选择分支
↓
工具或人工：执行下一步
↓
外部结果写回状态Jev 不接管 Agent Loop，也不直接操作工具。它把当前状态变成代码可以读取的结果，策略代码再根据风险、权限、资源状态和失败回退决定下一步。
状态进入判断层，结果再交给代码、通用模型或人工处理
Jev 的接口，核心是三个问题原语
TypeSafe 的公开文档把 Jev 的问题类型分成三个原语。写问题时，开发者先声明答案空间，模型再在这个范围内做语义判断。
Choice 用于从预定义选项中选择一个。工单分流、模型路由、工具选择都属于这一类，返回结果通常还包括每个选项的概率。
Score 用于在开发者定义的尺度上评分，例如把相关性、质量或风险分成低、中、高，或者使用更细的有序等级。
Noul 用于判断一个命题成立的概率，例如“是否需要人工审核”“这条命令是否具有破坏性”。它在接口上接近布尔判断，输出仍然保留不确定性。
同一份状态可以带上多个相互独立的问题。比如一次读取工单，同时判断队列、紧急程度和是否涉及退款政策。三个结果可以一起返回，后面的代码按需取用。
同一份状态可以同时提出 Choice、Score 和 Noul 问题
这和“让通用模型返回 JSON”有相似之处，区别在于边界更早被写进问题定义。结构化输出要求模型把自然语言组织成指定格式；Jev 连答案类型、候选集合和概率字段一起限定。程序拿到结果后可以直接进入分支，不必再从解释段落里猜模型到底选了什么。
接入时，先把问题写窄
官方 API 的调用形态很简单：一个 state，一个模型名，再放入多个问题。HTTP 端点是 POST https://api.typesafe.ai/v1/systemone，模型使用 jev-latest；Python SDK 要求 Python 3.10 以上，默认也调用这个模型。下面这个例子同时问了工单应该交给哪个团队、客户有多焦虑，以及是否表达出紧迫性：
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient
client = TypeSafeClient()
ticket = "我的 Stripe 已经连续 3 天连不上，订单都快丢了，请尽快处理。"
response = client.system_one(
state=ticket,
questions={
"department": Choice(
instructions="Which team should handle this ticket?",
criteria={
"billing": "Payment or subscription issues",
"technical": "Bugs or integration problems",
"sales": "Pricing or account questions",
"other": "None of the above",
},
),
"frustration": Score(
instructions="How frustrated does the customer appear?",
criteria=[
"Calm, just stating facts",
"Frustrated but civil",
"Very angry, strong language",
],
),
"urgent": Noul(
instructions="The message conveys urgency or time-sensitivity",
),
},
)返回值里，department 有 choice、各选项的 probabilities 和 confidence；frustration 有 score、档位说明和概率；urgent 的 noul 是 0 到 1 之间的概率。代码可以把它们组合成策略：技术队列且 urgent.noul >= 0.8 时提升优先级，department.confidence 落在灰区时转人工复核。
这里有两个容易混淆的细节。Noul 的 0.5 表示“是和否各半”，不是中等程度；需要表达程度时，应当用 Score。Choice 也最好保留“其他”选项，避免输入不属于候选集合时被迫选错。
一次请求可以并行评估多个问题，问题数量增加对响应时间的影响相对有限。实际接入时，仍要把状态裁到问题真正需要的范围，避免每个判断都携带整段会话。
Akshay Pachaar 把它比作一个带语义的 switch。这个比喻有用：普通 switch 已经知道值和分支，Jev 处理的是代码能拿到文本，却不能仅靠字符串比较判断含义的状态。分支仍写在程序里，Jev 只把自然语言状态变成选项、等级或概率。
先别把 Jev 当成 random.choice
最近有个挺好玩的梗：有人说 Python 里早就内置了一个“Jev 模型”，从 random 里导入 choice 就能让程序选择，而且一次只要几十微秒。评论区又补了一句：这种判断题的准确率，高达 50%。这里的耗时说的是随机函数调用，和 Jev 的模型性能没有关系。
from random import choice
choice(["billing", "technical", "sales"])这个玩笑刚好把边界照了出来。random.choice 解决的是“从给定选项里随机取一个”；它不读取工单内容，也不知道“扣了两次款”更像支付问题。Jev 解决的是“根据文本或 JSON 状态，判断哪个选项更符合语义”，并把概率一起返回。
两者的函数形状看起来接近，输入、目标和失败方式却完全不同。业务只需要抽样时，random.choice 更合适；代码已经拿到候选值，却无法靠字符串和规则判断含义时，才有语义判断的空间。所以 Jev 的价值不在于把 choice 做得更快，而在于把“为什么选这个”变成可以观测和评测的信号。
输入状态先变成受限结果，再由策略代码决定是否放行、复核或回退
一个具体落点：上下文压缩不必先做摘要
编码 Agent（coding agent）的上下文压缩很适合检验这套分工。会话里有大量 tool_use 和 tool_result，真正占空间的往往是文件列表、测试日志和命令输出。把整段历史交给通用模型做摘要（summary），确实能缩短文本，但路径、错误码和参数也可能被改写成一句模糊的概括。
fast-jev-compaction 选择了另一条路：用户消息和助手消息保持原样，只处理工具调用及其结果；先按 tool_use_id 配对，再对每一组提出两个窄问题：
keepCall：知道这个工具调用发生过，对后续任务还有帮助吗？
keepResult：这个工具结果的全文还需要保留吗？两个 Noul 的概率进入一棵很小的决策树：
keepResult >= threshold
├─ 是：调用和结果都保留
└─ 否
├─ keepCall >= threshold：保留调用，结果截断
└─ 否：调用和结果一起删除两个窄问题对应三种确定动作：原样保留、保留调用并截断结果、整体删除
这个动作比摘要更容易测试。保留首条消息和最近若干条消息作为固定锚点；旧工具结果先做截断，状态预算仍不够时，再按顺序压缩输入、折叠旧文本、合并旧调用。Jev 只负责给每组历史一个保留概率，重建消息列表、计算压缩收益和写回上下文都由代码完成。
工程上还要留一个退路：Jev 请求失败、返回格式异常、概率落在灰区，或者这次压缩根本没有带来收益时，回退到原有摘要流程或直接保留原始对话记录。运行记录至少应包含压缩前后大小、上下文处理阶段、请求次数和最终动作，这样才能分辨问题出在判断、预算还是策略。
它与规则、分类器各自解决什么
把 Jev 接进系统前，先看问题是不是需要语义模型。
日期比较、金额计算、字段是否为空、权限检查、字符串匹配，这些已有确定实现的逻辑，直接写代码更快，也更容易测试。一个普通的 if 已经能稳定解决的问题，不值得额外增加模型调用。
传统分类器适合标签稳定、样本充分、输入分布相对固定的场景。Jev 更像一个按需定义的语义判断接口：问题、候选项和判定标准可以跟着业务状态变化，不必为每一个小分支单独训练一个分类器。代价是它仍然需要校准、评测和兜底，不能因为接口类型安全就跳过这些工程工作。
通用大模型仍然适合开放式任务：写回复、生成代码、解释原因、制定计划，或者在答案空间尚未确定时继续探索。Jev 先把答案空间收窄，运行时拿到的是可以直接读取的结果，不必再从一段解释里猜它到底选了什么。
三个插槽：路由、门禁和验证
在 Agent Loop 里，Jev 有三个位置比较容易落地。
模型路由。 简单查询、信息抽取和小范围修改，不一定需要最强模型；架构分析、长链路排错和高风险任务又需要更强的推理能力。Jev 可以根据请求状态选择 fast 或 powerful 等候选模型，把路由依据从提示词里的隐含判断拿出来，变成可记录的输入、选项和概率。
工具风险判断。 工具调用执行前，可以把命令、参数和当前仓库状态交给 Jev，判断它是只读、可回滚还是具有破坏性，也可以单独检查是否修改 Git 历史、触碰生产资源或删除文件。低风险且高置信度的调用继续执行，危险或不确定的调用进入确认、沙箱或人工路径。权限、沙箱和测试仍然要保留，它们负责那些代码可以确定验证的规则。
结果验证。 Agent 说“任务完成”并不等于任务真的完成。Jev 可以针对运行状态判断测试是否已经通过、是否反复执行同一动作、输出是否符合某条策略，或者是否需要复核。能用硬性测试验证的地方仍然应该使用硬性测试；语义判断适合补上那些规则无法直接表达的部分。
这三个位置的共性是：它不写最终业务内容，只给运行时提供下一步分支需要的信号。
四个开源项目，刚好对应四种落点
把概念放进真实项目里，会更容易看出 Jev 的边界。下面四个项目的共同点，是把“需要理解语义、但答案空间并不大”的小问题单独交给 Jev，执行和状态管理仍由原来的程序负责。
Jev 不替代生成、搜索和执行，而是把其中的语义小判断单独抽出来
浏览器操作：jev-ultrafast。 网页上每一步都有一组当前可用的按钮、输入框和链接，Jev 选择下一步该操作哪个控件，代码负责真正点击和填写。需要生成文字时，项目再调用辅助模型。这里的分工很清楚：Jev 选动作，文字模型写内容，浏览器自动化层执行动作。
信息流过滤：Your Signal。 插件把已经显示在时间线上的帖子文本交给 Jev，判断它和用户设定的主题、实用性或推广偏好是否相关，再决定高亮、淡化、折叠或隐藏。它处理的是“这条内容对我有没有用”，不负责核实图片和外链里的事实。
搜索筛选：Jev Search。 搜索服务先取回链接，Jev 再判断来源、时间范围和标题摘要是否贴近问题，最后把相关性结果交给界面展示。联网的是搜索服务，Jev 负责选择和筛选；相关性高，也不等于内容已经被核实。
上下文压缩：fast-jev-compaction。 这个项目让 Jev 判断旧工具调用和结果还值不值得保留，程序据此保留原文、截短结果或删除整组记录。它和前面的例子相似：模型只给保留价值，消息列表怎么重建、压缩是否带来收益，仍由代码负责。
这四个项目可以看成同一张架构图的四个切口：控件选择、内容相关性、结果筛选、历史保留。它们都没有让 Jev 变成一个全能 Agent，反而把 Agent 里原本混在一起的小判断拆得更细。
“快”来自接口变窄
TypeSafe 的公开材料给出了 Jev 的延迟、价格以及与通用模型工作流的对比倍数；LangChain 的文章展示了把它接进 Harness 做工具检查和循环控制的方式。这些数字来自厂商材料和特定评测，不能直接当成所有系统的性能保证。
按 TypeSafe 当前公开口径，Jev 的端到端延迟约为 70 到 500 毫秒，输入价格为每百万 token 0.042 美元，输出不另收费；材料还给出了约 200 倍的速度差和约 400 倍的成本差。这些数字取决于对比工作流、输入状态和网络条件，适合用来理解产品定位，不适合直接写进自己的容量预算。
它可能更快的原因并不神秘：不生成长文本，候选项在调用前已经确定，同一状态的多个独立问题可以并行评估，返回结果也不需要经历“生成解释、解析字段、格式失败、再次重试”的链路。
评估时也不能只看单次模型延迟。状态长度、网络、并发、重试、二次复核和人工处理都会进入端到端耗时。更有意义的比较是整条运行链：加入 Jev 后少了哪些生成调用，又增加了哪些校准、回退和观测成本。
概率能进入策略，但必须先校准
Jev 返回概率，是因为“选中了哪个选项”还不足以支撑生产决策。工单被分到支付队列，可能是 0.52 对 0.46 的险胜，也可能是 0.98 的明显判断。这两种结果不应该走同一条自动化路径。
一个常见的策略分层是：高置信度且低后果的分支自动继续；中间区间调用更强模型或要求确认；低置信度进入人工或补充信息路径。阈值应当来自接近真实分布的样本，而不是直接把 0.8 当成通用标准。
还要区分两种“不会出错”。Jev 可以保证返回值落在声明的 schema 内：定义了支付、技术和销售，就不会凭空返回第四个部门，也不会把标签写成一段破损文本。它仍然可能在合法选项中选错，甚至带着很高的概率选错。类型安全解决的是输出形状，不能替代判断质量。
接入可以从一个小分支开始：选答案空间有限、失败可回滚的场景，把问题定义、候选项、输入状态和预期答案固化成评测集；先影子运行，只记录 Jev 的概率，不改变现有行为；再按置信度区间统计实际错误率，决定自动化阈值。模型版本、问题定义和阈值也要进入运行记录，方便重放和比较。
Harness 要为这层判断补上什么
JGX 前面讨论 Harness 时，重点放在模型之外的运行控制：上下文怎样组织，工具怎样挂载，循环怎样恢复，结果怎样验证。Jev 加进来以后，Harness 还要把“判断输入”和“策略动作”接起来。
先说回放。触发判断时的状态、问题定义、候选项、模型版本、概率分布和最终分支，都应该进入运行记录。否则一次路由错误发生后，只能看到结果错了，无法复现当时 Jev 看到了什么。
再说策略显式化。p > 0.8 只是一个条件，不是完整策略。动作是否可撤销、是否涉及隐私、是否需要二次确认、超时和灰区怎样处理，都应该写在配置或代码里，而不是藏在提示词或某次对话里。
最后是失败回路。工具失败、外部状态变化、人工拒绝或新证据出现后，系统要更新状态，再重新判断重试、换工具、回退还是结束。Jev 提供的是当前状态的语义信号，运行时仍然负责保存事实和恢复流程。
上下文决定判断看到了哪些事实，Jev 把这些事实映射成受限结果，Harness 再把结果放回可回放、可验证的执行循环。
判断层拿到的上下文越贴近问题，结果越容易复核和回放
从哪个分支开始接入
我会先选一个低风险、候选项有限、结果容易核对的判断：检索范围选择、工单分流、搜索结果相关性、工具结果是否保留。这样的分支即使暂时回退到原有模型或人工路径，也不会让系统失去控制。
需要长篇解释、多步隐式推理、精确计算、计数、日期比较或未知值抽取的问题，不适合直接交给 Jev。答案空间不断变化时，可以先让通用模型或代码产生候选，再用 Jev 在候选集合里做选择；能由确定性程序完成的部分，仍然留在程序里。
放回架构图里，Jev 可以看作 Agent 运行时的一个新插槽：通用模型处理理解、规划和生成，Jev 处理有限答案空间里的语义判断，策略代码组合条件并选择分支，Harness 记录状态、调用工具并处理回退和验证。
这个分工不会自动带来可靠性。它带来的好处是，原本埋在一次通用模型调用里的小判断，可以被单独观测、单独评测，也可以在需要时替换成规则、分类器或另一个模型。对生产系统来说，这种边界本身就比“再加一个更强的聊天模型”更值得拆开研究。
参考资料
TypeSafe AI：《Introducing System One Models & Jev》（https://typesafe.ai/blog/introducing-system-one-models-and-jev） TypeSafe AI 文档：《Primitives》（https://docs.typesafe.ai/primitives） TypeSafe AI 文档：《Quick start》（https://docs.typesafe.ai/introduction/quickstart） TypeSafe AI 文档：《Example use cases》（https://docs.typesafe.ai/concepts/use-case-map） LangChain：《Building a Harness with Jev》（https://www.langchain.com/blog/building-a-harness-with-jev） AIAGI：《一万字 Jev 工程实践长文：把 Agent 的“判断题”从大模型里拆出来》（2026-09-21，含 fast-jev-compaction工程拆解）Akshay Pachaar：《Jev Clearly Explained》（https://x.com/akshay_pachaar/status/2101037514945597645） hsn8086：《random.choice 与 Jev 梗》（https://x.com/hsn8086/status/2102017980246962397） 阿蔺 A-Lin：《Jev 入门指南：三张图说透、4 个开源项目、API Key 手把手获取》（https://x.com/alin_zone/status/2102005271849734462） Elvis Saravia：《Jev 入门指南》（https://x.com/omarsar0/status/2101774405521301681）
如喜欢本文，请点击右上角，把文章分享到朋友圈
如有想了解学习的技术点，请留言给若飞安排分享
因公众号更改推送规则，请点“在看”并加“星标”第一时间获取精彩技术分享
·END·
相关阅读：
- Harness 到底管什么：模型外面的三条工程边界
- 向量数据库已死？Claude Code、Cursor 为什么都在重做 RAG
- 一万字 Jev 工程实践长文：把 Agent 的“判断题”从大模型里拆出来
版权申明：内容来源网络，仅供学习研究，版权归原创者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢!
架构师
我们都是架构师！
关注架构师(JiaGouX)，添加“星标”
获取每天技术干货，一起成为牛逼架构师
技术群请加若飞：1321113940 进架构师群
投稿、合作、版权等邮箱：[email protected]