Jev不是更便宜的GPT，它可能是Agent缺的那根反射神经-二趣网

Jev不是更便宜的GPT，它可能是Agent缺的那根反射神经

最近Jev很火，我一开始也怀疑：一个“不生成文本”的模型，能有多大空间？GPT、Claude都能做structured output，也能tool calling，为什么还要单独搞个Jev？

直到我把几篇资料看完，又读了GitHub上的fast-jev-compaction，自己仿写了一个小Demo，想法变了。

它最值得聊的，不是一个模型有多神，而是一个很具体的工程问题：

Agent里很多模型调用，不是为了生成答案，而是为了替代码做一次判断。

这句话如果成立，Jev就不是“更便宜的GPT”。它更像Agent系统里缺了很久的一个零件：快判断层。

一、Jev到底在解决什么问题？

聊天模型擅长生成文本。Jev刻意放弃文本生成，只返回类型化的概率决策。

它主要有三种原语：

Choice：从最多255个选项里选一个
Score：在2~10级刻度上打分
Noul：给出0~1的是/否概率

举个例子。上下文里有一段测试日志，系统只想知道“这段日志还要不要保留”。

传统大模型会输出一段解释：“这段日志包含失败原因、文件路径和鉴权相关信息，建议保留。”

人能看懂，但代码还要继续解析。

Jev的返回更像这样：

{"answers":{"result_t3":{"noul":0.87}}}

代码直接：

if(keepResult>=0.5){keepFullResult();}

核心变化就一句话：把模型输出从“文本”变成“可执行的概率判断”。

和GPT/Claude的structured output相比，差别不是“能不能返回JSON”。现在大模型都能返回JSON。真正的差别是：Jev从一开始就放弃自由文本生成，只做封闭输出空间里的概率判断。

它不是Agent的大脑，是Agent的反射神经。

二、为什么Agent需要一个快判断层？

写coding agent最容易遇到的瓶颈，不是模型不会说话，而是上下文越来越长。

一个稍微真实的修Bug过程：用户描述问题 → 搜索代码 → 读文件 → 跑测试 → 看失败日志 → 再读文件 → 改代码 → 再跑测试……每一步都往历史里塞内容。

真正撑爆上下文的，往往不是用户说的话，也不是助手说的话，而是工具结果。

传统summary有一个天然问题：它能省token，但会改写事实。

原始测试日志可能是：

FAIL order-export.test.ts Error: Timeout of 5000ms exceeded at exportOrders (/repo/src/services/orderExport.ts:42:19) Expected authorization header to be preserved.

如果被摘要成：“之前订单导出测试失败了。”

听起来没错，但关键细节全没了：哪个测试、超时阈值、具体定位、鉴权约束。

对coding agent来说，这个代价有时候很高。上下文压缩最怕的不是删掉废话，而是把关键事实改写成一句“差不多”。

用通用大模型做压缩，会遇到三层断裂：

生成成本和判断需求不匹配：系统只是想知道“这段日志还值不值得留”，这是个判断题，不是作文题。
摘要会破坏可复核性：文件路径、错误码、栈信息、命令参数，都是精确内容。摘要会把这些变成“含义相近”的描述。
置信度没有进入代码分支：通用大模型说“我有80%把握”，通常只是文本里的自我描述，不一定是经过校准的概率。

Jev的设计目标是把概率变成接口返回值，让代码可以用阈值控制行为：

概率区间	系统动作
>= 0.8	自动执行
0.5 ~ 0.8	保守处理
< 0.5	删除或回退，高风险转人工

当然，概率不是安全证明，必须用自己的数据做校准和shadow mode验证。

三、fast-jev-compaction：不做摘要，只做保留决策

fast-jev-compaction是我觉得最能说明Jev价值的项目。

它的目标不是让Jev写代码，也不是让Jev接管Agent，而是处理一个很具体的问题：

Claude Code / coding agent的历史上下文越来越大，哪些工具调用和工具结果可以删？

它的策略很克制：

用户文本不改写
助手文本不改写
工具调用和工具结果配对处理
旧工具结果要么完整保留，要么截断，要么删除
如果Jev失败或压缩收益不够，回退到原来的summary流程

它把上下文压缩拆成两个判断题：

keepCall：这个工具调用本身还重要吗？
keepResult：这个工具结果全文还需要保留吗？

两个概率组合起来，得到三种动作：

keep：调用和结果都完整保留
drop_result：保留调用，截断结果
drop_call：调用和结果一起删除

这个项目不是“总结器”，而是“工具历史清理器”。

它的设计分三层：

对象层：把tool_use和tool_result配成一组
判断层：为每组工具历史生成keepCall/keepResult两个问题
执行层：根据阈值执行keep / drop_result / drop_call

我跑了一下Demo，样本是一个修复订单导出超时的会话。四个工具调用，结果很符合直觉：

ID	工具	动作	keepCall	keepResult
t1	list_dir	drop_result	0.54	0.00
t2	read_file	keep	0.59	0.69
t3	execute_command	keep	0.75	1.00
t4	read_file	drop_call	0.47	0.00

压缩前后：字符数从10029降到852，减少91.5%。完整保留2个关键文件和失败日志，截断1个目录树，删除1个无关调用。

这个Demo不证明Jev比大模型聪明，但它证明了一个工程模式：

上下文压缩可以从“总结旧历史”改成“判断保留价值”。

四、怎么用？简单三步

第一步：拿API Key

路径A：TypeSafe官网waitlist，控制台创建密钥
路径B：Vercel AI Gateway，搜索jev → Enable

第二步：发起调用

请求体三个字段：state、model、questions。

curl-XPOST https://api.typesafe.ai/v1/systemone\-H"Authorization: Bearer$TYPESAFE_API_KEY"\-H"Content-Type: application/json"\-d'{ "state": "客户说：扣了两次钱还没发货，客服也没人理", "model": "jev-latest", "questions": { "urgency": {"type": "noul", "instructions": "这条消息表达紧急程度吗？"}, "department": {"type": "choice", "instructions": "该转给哪个部门？", "criteria": {"billing": "支付、退款", "logistics": "物流、发货", "support": "客服投诉"}}, "anger": {"type": "score", "instructions": "客户愤怒程度？", "criteria": ["平静", "有点烦", "很生气", "要跑路"]} } }'

返回就是结构化数据：noul: 0.96、choice: billing、score: 3.2。

第三步：用置信度做三档路由

置信度 > 80% → 自动处理
50%～80% → 转人工复核
< 50% → 升级处理

五、特点与坑，别神话它

优点：

快：端到端70~500毫秒
便宜：输入每百万token 0.042美元，输出免费
输出封闭：不会给出选项之外的答案，不会拼错字段
零样本泛化：告诉它分类标准，立刻就能判断
自带犹豫信号：置信度可以直接进代码分支

坑：

“不会幻觉”更准确的说法是：它不会输出schema之外的内容。但它仍然可能选错。这叫类型安全，不叫语义正确。
“概率可信”需要自己校准。先shadow mode跑一段时间，用自己的业务样本统计不同概率段的真实正确率，再定自动执行阈值。
中文适配一般，复杂推理弱，不能生成，不能解释。
只接受文本，图片音频得先转文字。

选型建议：

场景	适合方案
高频、输出空间固定、可回退	Jev
需要解释、复杂推理	GPT / Claude
稳定标签、大量数据	传统分类器
跨文件、多步推理	不适合Jev单独承担

一个简单判断标准：如果答案是“是”，输出选项能提前枚举吗？是否需要自然语言解释？是否高频调用？错误是否可兜底？

六、我的结论

Jev不神秘。它的很多技术零件以前就有：分类、约束输出、logits打分、概率校准、判别式路线。但它把这些东西组合成了一个清晰的开发者接口。

这个接口真正有价值的地方，是提醒我们重新拆分Agent：

哪些地方需要生成
哪些地方只是判断
哪些地方应该交给确定性代码

fast-jev-compaction是一个很好的切口。它没有试图让Jev变成另一个全能模型，而是把它放在一个很窄、很真实的位置上：判断工具历史还要不要留。

把生成留给需要表达的地方，把判断交给可控的接口，把执行还给确定性代码。

这套模式不只适用于上下文压缩，也适用于所有高频、封闭、可回退的Agent内部决策。

你会拿Jev做什么？评论区聊聊👇

（注：部分内容可能由 AI 生成）

企业官网建设流程全解析