2026-10-16 11:46:50 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

Jev 上手体验

原创

Tokeii
Tokeii

猫捉鱼铃酒吧

2026年9月18日 09:19
湖北

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

它不写答案，只做判断。
你把程序的当前状态丢给它，它返回一个带概率的结构化决策——剩下的活儿，还是交给代码。

最近上手了一个挺有意思的新模型：Jev。

它和我们已经用习惯的 ChatGPT、Claude 有一个非常明显的区别——它并不擅长「给人写答案」，而是专门给程序做判断。

Jev 是 TypeSafe AI 推出的第一个 System One Model。官方对它的描述很直接：输入当前状态，输出带概率的结构化决策。

它干脆放弃了大模型最核心的自由文本生成能力，把全部力气压在分类、判断、评分、路由和选择上。TypeSafe 自己的说法是：一个可以嵌进程序里的「智能 if 语句」。

这么讲还是有点抽象。我们从接口开始，再从一道最简单的题开始。

一、Jev 只有三种提问方式

先把接口讲清楚，后面的例子才好理解。

Jev 不接受「你随便问、我随便答」。你必须先把问题的形状定义死，而它只提供三种原语：

原语	你问什么	它返回什么
`Choice`	从一组候选里选一个	`choice` + 每个选项的概率 + `confidence`
`Score`	按一套评分标准打分	`score` + 概率分布 + `confidence`
`Noul`	这句话成立吗	一个 0 到 1 之间的概率

三种可以混在同一次请求里发出去，共享同一份 state。

而这一句才是关键：

每个问题都是独立、并行地对同一份 state 求值的。所以你往里加问题，不会出现上下文互相污染、越问越糊涂的情况。

这和「写一段长 prompt 让模型一口气分析完」是两种完全不同的用法。

顺带一提性能：官方给的端到端响应时间是 70ms–500ms，单个 Choice 最多支持 255 个候选项，输入 $0.042/MTok、输出免费。后面截图里那些 140ms、99ms，确实都在这个区间里。

二、第一道题：这是 Base64 还是 Base58？

假设程序收到这样一段字符串：

TG92ZWx5RGVjaXNpb24tSmV2LVRlc3QtMjAyNg==

它其实就是这句话的 Base64 编码结果：

LovelyDecision-Jev-Test-2026

换成传统大模型，我们大概会这么写 prompt：

prompt

请分析下面字符串使用了什么编码，并说明判断理由： TG92ZWx5RGVjaXNpb24tSmV2LVRlc3QtMjAyNg==

然后模型回你一段文字：

根据字符串的字符组成以及末尾的 ==，该字符串很可能采用 Base64 编码……

写得挺好。但程序真正需要的，只有一个词：

Base64

剩下那些，全是要你自己去写正则、去截断、去兜底解析的负担。

Jev 的做法是反过来的：先把答案的范围钉死。

questions

{ \"encoding\_type\": { \"type\": \"choice\", \"instructions\": \"哪种编码格式最匹配所提供的输入字符串？\", \"criteria\": { \"base64\": \"标准的 Base64 编码数据，通常使用 A-Z、a-z、0-9、+、/ 以及可选的 = 填充字符。\", \"base58\": \"采用比特币风格字符集并排除 0、O、I 和 l 等易混淆字符的 Base58 编码数据。\", \"hex\": \"仅使用 0-9 和 A-F（或 a-f）的十六进制编码数据。\", \"unknown\": \"输入内容与所列的任何编码格式均不充分匹配。\" } } }

而 state 就一行：

state

{ \"input\": \"TG92ZWx5RGVjaXNpb24tSmV2LVRlc3QtMjAyNg==\" }

注意 criteria 这一块：这里写的不是 prompt，而是给每一个选项写「判定标准」。选项是什么、边界在哪，都由你定义。

跑一下，结果是这样的：


encoding\_type	Choice


base64		100%
base58		0%
hex		0%

confidence 100%

jev-latest · 140ms + 484ms · 4 options

Jev%20Playground：左边是%20state%20和%20questions，右边直接给出带概率的结构化结果

于是程序可以直接接上去：

rust

match%20encoding%20{%20 %20 %20Base64%20 =>%20decode\_base64(),%20 %20 %20Base58%20 =>%20decode\_base58(),%20 %20 %20Hex%20 %20 %20=>%20decode\_hex(),%20 %20 %20Unknown%20=>%20manual\_analysis(),%20}

这里发生的变化其实很大：

AI%20不再负责「把事情做完」。
它只回答一个问题：这是什么？
真正的%20Base64%20解码，仍然由那段跑了二十年、绝不会出错的确定性代码完成。

三、换个更容易混淆的输入，模型也会犹豫

同样的明文，换成比特币风格的%20Base58%20编码：

nbdsA7DxShmGaBYLqbprkoymkDFXuuvzA8ZL4D

state%20换掉，questions%20一个字没动，再跑一次：


encoding\_type	Choice


base58		52%
base64		36%
unknown		11%

confidence%20 37%

jev-latest%20·%2099ms%20+%20235ms%20·%204%20options

同一组%20questions，只换了%20state：这次它没那么确定

这次的结果没有上一次漂亮，但它恰恰是我觉得%20Jev%20最有意思的地方。

Base58%20只拿到 52%，Base64%20还占着 36%，整体%20confidence%20只有 37%。

模型确实「犹豫」了——而且这个犹豫是有道理的：这串字符全都落在%20Base64%20的合法字符集里，长度也不带 = 填充，光看字符组成，它本来就两边都像。

换成聊天模型，你会得到一段语气笃定、读起来毫无破绽的分析。而%20Jev%20直接把不确定性以数字的形式交了出来。

程序拿到这个数字，就可以自己定规矩：

policy

confidence%20≥%200.8%20 %20→%20 直接按%20choice%20执行%200.4%20~%200.8%20 %20 %20 %20 %20 →%20 两条路都试，用解码结果回头验证%20confidence%20<%200.4%20 %20→%20 别猜了，交给确定性校验或人工

这一条其实比「模型答对了」更重要：
一个会告诉你「我不确定」的模型，才敢放进自动化流程里。

四、换个场景：网络流量

只是判断编码，可能还看不出这种模型的价值。换到安全场景试试。

假设流量分析程序已经从%20PCAP%20里算出这么一份%20state：

state

{%20 \"protocol\": \"HTTP\",%20 \"duration\_seconds\": 7200,%20 \"request\_count\": 240,%20 \"mean\_interval\_seconds\": 30.01,%20 \"interval\_stddev\": 0.18,%20 \"same\_uri\_ratio\": 0.99,%20 \"request\_size\_mean\": 175,%20 \"response\_size\_mean\": 221,%20 \"payload\_entropy\": 7.42}

翻译成人话是：

某台机器连续两个小时在发%20HTTP%20请求，平均每 30.01%20秒 一次，时间抖动只有 0.18%20秒，99% 的请求打在同一个%20URI%20上，载荷熵%207.42。

传统程序当然可以写：

python

if%20interval%20<%2031:%20 %20 %20suspicious%20=%20True

但紧接着问题就来了：

●30%20秒一次就是恶意，31%20秒就正常？

●标准差到多少才算异常？

●HTTP%20长连接会不会影响判断？

●正常客户端的定期心跳怎么办？

规则只会越写越长，越长越不敢改。

Jev%20非常适合插在这个位置。对同一份%20state，我们可以同时问一组很窄的问题：


traffic\_behavior	Noul


这些流量是否表现出自动化%20Beacon%20行为？		0.96
现有证据是否支持%20C2%20通信？		0.81
是否存在数据外传特征？		0.12

再加一个%20Choice：


session\_type	Choice


Beacon		53%
C2		38%
Normal		4%
Unknown		3%
Exfiltration		2%

这条%20Session%20最符合哪一种行为？

注意这几个问题是各问各的：Noul%20说「像%20Beacon」的把握有%200.96，而%20Choice%20里%20Beacon%20被%20C2%20摊薄成了%200.53%20和%200.38。

这并不矛盾——前者问的是「是不是」，后者问的是「最像哪一个」。两个数字本来就该分开看，也各有各的用法。

于是流量分析软件里可以写成这样：

policy

beacon\_noul%20>%200.90%20 →%20 进入%20Beacon%20深度分析%20c2\_noul%20 %20 %20>%200.80%20 →%20 关联相同%20IP%20/%20Domain%20/%20JA3%20/%20Session

而不是把%20PCAP%20整个甩给%20AI，让它自己「分析一下」。

五、实测：131%20个模块，先砍掉%2055%20个

说个我自己踩过的坑。

LovelySpark%20里目前有 131%20个流量分析模块。问题是过去每次载入流量包，选中的模块都会一股脑全跑一遍——包里根本没有%20RTSP、没有%20WireGuard、没有%20MQTT，那些模块照样要被唤起、照样要扫一遍数据，纯属浪费。

接上%20Jev%20之后，流程拆成了两步：

1先用 tshark 把包里到底有哪些协议探出来——这是确定性的事，交给代码；

2把探测结果作为%20state%20丢给%20Jev，让它决定哪些模块值得开——这是判断的事，交给模型。

这是一个 cs流量分析.pcapng 的实际结果：


136,990已探测包数	55被取消的模块	73/131最终参与分析	4.3s决策耗时

LovelySpark%20深度分析页：Jev%20智能选项把%20128%20项收敛到%2073%20项，4.3%20秒、41254%20输入%20/%204420%20输出%20tokens

探测到的协议是%20arp、browser、cotp、dhcp、dns、http、icmp、quic、rdp、smb、tls、udp……于是%20Jev%20取消了%2055%20项明显用不上的模块，37%20项维持原样，选中数从%20128%20降到%2073。

界面上还留了一句很重要的话：

可继续手动修改；协议未识别或加密时可能保留部分选项。

这也是我想强调的：Jev%20给的是建议，不是命令。它调完之后，那%20131%20个复选框还老老实实待在那儿，我随时可以推翻它。

决策权可以给模型，执行权必须留在程序和人手里。

六、内存取证：把一个大问题拆成四个小问题

内存分析这边也是一样。假设分析程序发现了这么一个进程：

state

{%20 \"process\": \"powershell.exe\",%20 \"pid\": 4820,%20 \"parent\": \"WINWORD.EXE\",%20 \"encoded\_command\": true,%20 \"private\_executable\_regions\": 2,%20 \"rwx\_regions\": 1,%20 \"pe\_header\_in\_private\_memory\": true,%20 \"suspicious\_thread\_start\": true,%20 \"external\_connections\": 1}

传统大模型的用法大概是：

prompt

你是一名专业的内存取证专家，%20请分析这个进程是否恶意，并详细说明原因。

然后得到七百字。读着挺专业，但程序没法用——你没办法%20if%20一段散文。

取证软件真正想知道的，其实是几件非常明确的事：

●是否存在%20Process%20Injection？

●是否存在%20C2%20行为？

●是否值得继续调查？

●当前调查优先级有多高？

●下一步应该运行什么？

拆开来，正好对上%20Jev%20的三种原语：


threat\_hypotheses	Noul


是否存在%20Process%20Injection？		0.94
是否存在%20Credential%20Access？		0.12
是否存在%20Persistence%20迹象？		0.27
是否存在%20C2%20通信？		0.63


investigation\_priority	Score


critical		71%
high		22%
medium		5%
low		2%

confidence%20 84%

score%20=%200.88%20·%20这条线索的调查优先级

于是程序拿到的不再是「AI%20认为这个进程很危险」，而是一组可以直接进 if 的数字。

更有意思的是对比：Process%20Injection%20高到%200.94，而%20Credential%20Access%20只有%200.12。

这条信息同样值钱——它在告诉你：现在不必急着去翻%20lsass，先把注入这条线查透。一段散文是给不了你这种区分的。

七、然后，让%20Jev%20决定下一步跑什么

真正好玩的是把它放进循环里。

假设当前已经跑完：

pslist%20pstree%20cmdline%20netscan

还没跑的有：

malfind%20dlllist%20dump%20YARA

那就给%20Jev%20一个%20Choice：

根据当前尚未验证的调查假设，哪个操作最可能降低调查的不确定性？


next\_action	Choice


run\_malfind		78%
dump\_process		11%
inspect\_dlls		7%
run\_yara		3%
stop		1%

confidence%20 81%

程序去执行 malfind——这一步仍然由确定性代码完成——拿到：

Private%20Memory%20RWX%20MZ%20Header%20Abnormal%20Thread%20Start

这些新证据合并回%20state：

旧%20State%20 +%20 Malfind%20结果%20 =%20 新%20State

再问一次。这一次：


threat\_hypotheses	Noul


是否存在%20Process%20Injection？		0.99

下一步动作变成 dump_process。程序%20dump，接着跑%20YARA，再进入下一轮。

整个循环里，Jev%20一次内存都没有解析过。它只做了一件事：在每一个岔路口，指出往哪边走最省事。

画出来大概是这个样子：

传统分析引擎
starmem%20/%20tshark%20/%20YARA

↓

Evidence

↓

State%20Builder

↓

Jev

↓

Decision

↓

Policy%20Engine

↓

Action%20Executor

↓

新%20Evidence（回到第一步）

到这一步，它已经不太像一个「AI%20助手」了。它更像软件内部一个看不见的组件——AI%20真正参与了软件的运行逻辑。

八、CTF%20Misc%20其实是同一个形状

比如一道%20Misc%20题，给你一个 challenge.dat。

程序先自己跑确定性的那部分：

file%20strings%20entropy%20magic

得到：

state

{%20 \"extension\": \"dat\",%20 \"detected\_magic\": \"unknown\",%20 \"entropy\": 5.2,%20 \"base64\_like\_strings\": true,%20 \"embedded\_zip\_signature\": true}

然后问一句：下一步最值得做什么？


next\_action	Choice


extract\_zip		64%
binwalk		21%
decode\_base64		9%
xor\_analysis		3%
strings\_deep		2%
stop		1%

confidence%20 76%

真正的 extract_zip 由传统代码完成，解出一个 image.png，重新建立 state，再判断：

PNG Steganography? Extra Data? LSB? Metadata?

然后选择 zsteg。

于是就形成了一个很有意思的框架：

AI 决策

↓

确定性工具

↓

新证据 → 再决策

AI 负责在几十种可能里挑出最值得走的一条路，工具负责把这条路走完。

九、一条挺实用的设计原则

三个场景做下来，我总结出的判断标准其实特别简单。

设计 AI 功能之前，先问自己一句：

这件事能不能用确定性的代码做完？

能 —— 那就让代码做

计算 MD5

解析 PE

SQL 查询

计算 SHA256

解析 PCAP

字符串搜索

Base64 解码

解压 ZIP

协议解析

执行 YARA

因为这些事情都有唯一正确答案，AI 掺和进去，只会让本来 100% 可靠的结果变得不可靠。

不能 —— 而且它本质上属于判断、分类、评分、排序、路由、选择

这像不像 Beacon？这个进程值不值得调查？这些证据够不够支持 Process Injection？当前最可能是哪一种行为？哪个 Session 最可疑？下一步应该使用哪个 Skill？哪个操作最能降低调查的不确定性？

这些问题的共同点是：你写不出一个绝对正确的 if/else。

一组对照就很清楚了：

❌ 不该交给 Jev	✅ 该交给 Jev
计算这个文件的 MD5	现在值不值得算这个文件的 Hash
运行 malfind	malfind、netscan、dlllist、dump，现在跑哪个最有价值
解析这个 PCAP	这个 PCAP 里哪条 Session 最该先看