整个流程就是：看现在啥情况 → 做决定 → 去执行 → 检查结果 → 进入下一步。
现在所有人都在拼命优化大模型本身。但 Jev Engineering 优化的是：大模型每次调用之间，那些没人管的决定。
每个 Agent 最后都会碰到同一个岔路口：当前状态摆在这儿 → 有好几条路能走 → 但最后只能选一条。
Jev 的做法是：把“做决定”变成专门的一层，而不是每个小决定都丢回昂贵的大模型问一遍。
于是循环就变成了：
- 大模型负责推理、动脑子；
- Jev 负责拍板、做选择；
- 工具或者 Agent 负责干活；
- 干完活，状态更新；
- Jev 再根据新状态决定下一步。
一旦“做决定”变成单独的一层，你就可以单独给它跑分、批量处理、检查它靠不靠谱。
一句话总结：别让贵的大模型啥都干。让它负责想，让 Jev 负责选，让工具负责干，选完再更新状态，再继续选。
你的Agent里有多少调用根本不需要大模型来回答，以及怎么一步一步把它们换成Jev。一共十步，每一步解决一个问题。
先分清哪些调用是“写作文”，哪些是“做选择题”
第一个动作很简单：把你Agent里所有模型调用列出来，分成两堆。
判断标准只有一条——这次调用的输出是在生成文字，还是在做选择。
举例来说，一个电商客服Agent打开网页后需要判断点击哪个按钮。常见做法是把网页状态发给GPT或Claude，模型生成一段文字：“根据当前页面，我应该点击右下角的Checkout按钮”。然后软件从这段文字里提取“Checkout”这个词，再调用浏览器工具完成点击。
但从软件系统的角度看，它真正需要的信息只是“第三个按钮”。
生成文字的部分——写回复邮件、写代码注释、写总结报告——留给大模型。
做选择的部分——选哪个工具、分配给哪个部门、判断风险高不高、决定是否转人工——交给Jev。
还有第三类：精确规则。比如“10步之后停止”、“金额超过500元就转人工”——这些直接写在代码里，什么模型都不用调。
你需要做的就是打开你的Agent代码，找到每一个llm.call()或model.generate()，然后问自己：“这次调用是在写一段人类可以读的文字，还是在帮软件做一个判断？”
如果是后者，它就不该用大模型来做。
给Jev的输入必须是证据，不是感觉
Jev不会自己去找上下文。它只看你给它的东西，你给什么它就判什么。
所以第二个动作是设计一个结构化的状态对象，里面必须包含五样东西：目标是什么、已经完成了什么、有哪些可用资源、约束条件是什么、当前缺什么。
举个具体例子——你让Agent写一份关于三款AI工具的晨间简报：
state = {
"goal": "Compare three AI-agent tools in a morning briefing.",
"completed_work": "No sources collected yet.",
"available_workers": ["Researcher", "Writer"],
"constraint": "Save drafts for review. Do not publish."
}
这个状态里没有模糊的感觉，全是证据。Jev拿到之后就能做出一个有依据的判断。
如果你给的是“用户好像不太满意，可能想退款，情绪比较激动”这种描述，Jev返回的结果也会是模糊的。如果给的是“客户购买时间7天前，金额380元，发送了一封邮件包含‘退款’关键词，情绪词检测为负面”，它就能给出一个清晰的判断。
状态的质量决定了决策的质量，这句话在Jev身上比在任何模型身上都成立。
先在一个问题上试三次，再考虑接线
不要一上来就把Jev塞进生产代码。
打开TypeSafe的Playground，粘贴你的状态，问一个最简单的Choice问题：“哪个工人应该下一步行动？”选项设三个：research、write、review。
看它返回什么，看置信度是多少。
如果答案错了，先改状态，不要改模型。把状态里的证据写得更具体，缺什么信息就补什么信息，然后再问一次。
同一个问题跑三次。独立测试者发现，同一批732个决策跑三遍，只有24%的答案三次完全一致。一个第一次打0.03分的帖子在三次运行中都打0.03分，但一个打0.72分的帖子在下一次变成了0.68分。
Jev不是确定性的。同一个输入，两次运行可能给出不同的结果。
所以在你把它接入生产之前，必须知道它在你的场景里有多稳定。如果同一个问题三次答案差别很大，说明你的状态设计有问题，或者这个问题本身就不适合用Jev来做。
三个问题类型覆盖你Agent里90%的判断
Jev只有三种输出格式。
Choice从你定义的选项里选一个，最多支持255个选项。Score给你一个评分，可以设三档、五档或者连续值。Noul返回一个0到1之间的概率值，代表某个陈述成立的可能性。
这三类覆盖了软件里几乎所有“不需要生成文字”的判断。
Choice管路由：哪个工人干活、分配给哪个部门、选哪个工具。
Score管排序：这个来源相关度多高、这个候选人多匹配、这个风险等级多少。
Noul管门控：要不要批准、是不是安全、需不需要人工介入。
三种类型全部返回类型化的值，加上校准过的置信度分数。代码拿到这个值可以直接做分支判断，不需要解析自然语言，不需要容错处理。
一个风控系统可以让Jev判断某个用户退款风险为低、中还是高，模型返回“高风险75%”。软件拿到“高风险”和“75%”两个值，前者直接做分支，后者决定要不要转人工审核。
这就是为什么Jev不需要“说话”。当输出格式是你预先定义好的类型，它根本不需要生成文字来描述结果。
用漏斗把大列表缩到一个
Jev真正显出威力的时候，不是单个问题，而是把多个问题串成一个漏斗。
假设你要从一份候选人名单里选一个人。名单可能有几十甚至上百个。
第一层用规则筛掉明显不合格的——学历不达标、工作经验不足、期望薪资超出预算。这一层不需要任何模型。
第二层用Jev的Score给剩下的人排序。每个候选人拿状态数据和评价标准，Jev返回一个0到1的匹配分。
第三层用Jev的Choice做最终选择。把排名前几的候选人放在选项里，让Jev挑出最合适的那一个。
每一层都很便宜。Score一个候选人的成本不到0.001美元。Choice的成本同样很低。
而最终到顶部的那个决策是经过层层筛选的，每一步都有证据支撑，每一步都可以追溯。
这个漏斗模式可以套在任何“大列表缩到一个”的场景上——选工具、选模型、选路由路径、选回复模板。
让Jev坐在共享状态和工人之间
现在把Jev放到Agent团队的正确位置上。
架构是这样的：一个共享状态保存目标、进度和已收集的证据。Jev读取这个状态，决定下一步该做什么。一个调度器把Jev的决定交给对应的工人。工人完成工作后把结果写回共享状态。循环继续。
Jev从不生成任何东西。它只决定哪个工人干活，以及什么时候干。
代码看起来大概是这样：
decision = jev.choice(state, question) # which worker?
if decision.confidence >= 0.85:
dispatcher.send(decision.option, state)
else:
dispatcher.send("human_review", state) # escalate
这个“首席幕僚”模式的关键在于置信度阈值。阈值不是一个拍脑袋的数字，需要根据你的业务场景用历史数据校准。
一个语音银行的例子：意图判断的置信度低于0.6一律转人工；但查余额这类低风险动作，0.6的置信度就够了，因为最坏结果不过是用户再听一遍余额。
阈值随风险分层——高风险决策要求高置信度，低风险决策可以容忍更多不确定性。
三个问题一次问，别让它们排队
你的调度器可能同时需要三个决策：哪个工人干活、这个任务多紧急、需不需要人工审批。
如果这三个问题都读取同一份状态，而且彼此不依赖对方的答案，那就一次性发给Jev。
results = jev.batch(state, [
choice("which worker acts next?"),
score("how urgent is this task?"),
noul("does this need approval?")
])
三个决策在一次往返中全部解决，不需要串行等待。
但有一个硬约束：并行的问题之间不能读取彼此的答案。如果某个决策需要用到另一个决策的结果，它们必须串行执行。
如果一个决策依赖于一次新的搜索结果，那先跑搜索，拿到结果更新状态，再发决策请求。
这个约束逼着你把Agent的决策依赖关系画清楚。哪些是独立的、哪些有前置条件、哪些可以并行。画清楚之后，你的Agent架构本身就会变得更简洁。
在顶部和底部各加一道门
Jev可以被放在harness的两个位置，形成两层防护。
顶部是模型路由器。当一个请求进来，路由器先问Jev一个问题：这个请求简单还是复杂？需要哪个级别的模型来处理？Jev返回一个Choice结果，代码根据结果把简单请求路由到便宜模型，复杂请求才交给前沿模型。
底部是Auto Mode门。在执行任何工具调用之前，Jev先判断这个调用是否安全。LangChain已经为这个场景推出了AutoModeMiddleware，可以在工具执行前拦截危险调用。
guardrail = AutoModeMiddleware(tools=["bash"])
agent = create_agent("openai:gpt-5.6-luna",
middleware=[guardrail])
一个bash命令要执行之前，Jev先判断它是否安全。一个写文件操作要执行之前，Jev先判断它是否符合用户的原始意图。
这两个位置的大模型调用都消失了——本来为了问“这个请求简单吗”或“这个命令安全吗”需要调用一次前沿模型，现在全部由Jev以决策定价完成。
用打分来压缩上下文，不用写摘要
这是Jev最反直觉的用法。
传统的上下文压缩方式是让大模型阅读整段对话历史，然后写一份摘要。这是生成任务，慢，而且有损。大模型写摘要的时候可能丢掉关键细节，也可能保留无关的闲聊。
Jev的方式完全不同。它给每条历史记录打一个相关性分数，然后丢掉低分的。
一个叫fast-jev-compaction的开源插件把Claude Code的/compact命令从“让模型写摘要”改成了“给旧工具调用逐项打分”。压缩几乎瞬时完成，实测上下文减少75%到82%。
一位开发者测试了用Jev压缩一个Claude会话：从将近一百万Token压到86K，耗时大约一秒。如果用前沿模型做同样的事，大约需要一分钟。
原因在结构层面：摘要是生成任务，需要逐Token输出新文本；过滤是决策任务，只需要给每条记录打一个“留”或“删”的标签。
一个需要“写”，一个只需要“选”。后者的速度优势是结构性的。
但这里有一个需要警惕的失败模式。如果一个Agent反复问“我刚才丢掉了什么”，那就证明过滤太激进了。过滤的阈值需要根据实际使用情况调整，不能一次调完就不管了。
算一笔42美分对44美元的账
最后一步是算账。
假设你的Agent每天做一万次决策——选工具、判相关、定优先级。每次决策平均消耗1,000个输入Token。
全部走Jev：10,000次乘以1,000 Token等于10,000,000 Token输入。按每百万Token $0.042计算，总成本$0.42。
全部走GPT-5.6 Terra：同样10,000,000 Token输入，按每百万Token $2.00计算，输入成本$20.00。如果每次都产生200 Token的输出，按$12.00每百万Token计算，输出成本$24.00。总计$44.00。
42美分对44美元，相差大约105倍。
独立测试者Omar Mujahid跑了49个任务、8,225个项目，发现Jev在42个任务上追平或超过了一个小型快速LLM的基线，延迟大约是后者的七分之一，成本大约是后者的四分之一。
Jev在推理、知识和重排序任务上领先最大，在计数和大规模选项分类任务上落后。
Jev的校准误差大约是基线的一半，只保留它最有信心的那半数答案，准确率平均提升7.6个百分点。
但有一个发现值得注意：Jev在120个代码生成的数学题上得了0.75分，和它在GSM8K上的0.72分差不多。这说明Jev不是靠记忆来答题的，它确实在做推理。
Jev的名字来自杰文斯悖论——经济学家William Stanley Jevons发现，当蒸汽机的燃料效率提高、煤炭价格下降之后，英国的煤炭消耗量反而暴增了。
TypeSafe用这个名字是在赌一件事：当AI决策成本降到几乎为零，开发者会把它塞进以前舍不得用AI的场景里。
以前你只在关键节点调用模型。现在你可以每一步都调用——每一步验证输入安全性，每一步检查输出质量，每一步评估置信度。
但这也意味着一个新的问题：如果Jev本身有大约30%的准确率差距，这些小错误在一条长决策链里会不会累积放大？
Omar Mujahid在独立测试报告里写了一句需要加粗的话：Jev在49个任务中只有6个领先是统计上清晰的，其余差距在误差范围内。
六个清晰领先，一个清晰落后，剩下42个在噪音里。
所以真正的问题不是Jev好不好，而是：在你的具体场景里，它比你现在用的方案好多少，或者差多少？
这个答案只有你自己跑了才知道。