JEV · DECISION MODEL · WEB SECURITY

Jev 最近为什么这么火？我把它用在了 Web 安全上

发布日期：2026-10-02 · 主题：Jev / Agent / Web 安全 · 专题页 · JevSec 项目页

最近一段时间，Jev 在 Agent、Guardrail、Eval、Routing 这些方向里出现得越来越频繁。

如果只看名字，很容易把它理解成“又一个更快、更便宜的小模型”。但真正让我觉得它有意思的地方并不是这个。

Jev 更像是在强调一种和普通 LLM 完全不同的使用方式：

不要让模型写一大段话给人看，而是把当前状态交给模型，让它返回程序可以直接使用的结构化判断。
Application State
        ↓
Typed Questions
        ↓
Decision / Score / Probability
        ↓
Code decides what to do

这个思路最近在 Agent 领域很容易找到应用。例如，一个 Agent 下一步要不要调用某个工具，一次 Tool Call 是否风险过高，一段 Tool Result 是否值得信任，当前任务应该路由给哪个模型，以及某个动作应该 Allow、Ask 还是 Deny。

而我最近在想另一个问题：

这种“Decision Model”思路，能不能拿来做 Web 安全？

于是就有了 JevSec。

GitHub: ccjmcc/jevsec · JevSec 展示页

Jev 到底和普通 LLM 有什么不同

普通 LLM 最自然的接口是 Prompt → 一段自然语言。比如问“这段访问日志有没有问题”，模型可能生成一整段分析。

这段话给人看很舒服，但如果你想把它接进软件系统，程序真正需要的通常只是类似：

{
  "should_review": true,
  "category": "auth_anomaly",
  "risk": 0.78
}

或者甚至只需要：

ALLOW
REVIEW
BLOCK

Jev 这类 Decision Model 的重点，就是让模型输出从“文本”变成“决策”。这也是为什么它很适合被接进 Agent Loop：Agent 每一步真正需要的往往不是一篇作文，而是一个可执行的判断。

为什么我觉得它特别适合安全场景

安全系统里其实到处都是决策问题：这个请求要不要拦，这个 IP 要不要进入观察名单，这一段行为值不值得人工复核，这个 Session 是否明显偏离正常行为，多个弱信号叠加后是否应该升级风险。

传统规则系统的优点是可控、可解释、稳定，但很多行为很难写成一个简单的 if。

正常访问
→ 登录失败
→ 再次失败
→ 登录成功
→ 访问以前没访问过的敏感路径
→ 短时间接口遍历

每个动作单独拿出来都可能正常。真正可疑的是这些事情按这个顺序发生。

JevSec 想做的事情

JevSec 不是一个新的 WAF，我现在甚至越来越不想叫它“AI WAF”。

成熟 WAF，例如 OWASP CRS，更擅长 SQLi、XSS、Path Traversal、Command Injection 等单请求层面的规则判断；JevSec 更希望看多个请求组成的顺序、频率、状态变化和路径变化。

Your WAF sees requests. JevSec sees behavior.
Nginx / JSONL
        ↓
Privacy-aware Parser
        ↓
Behavior Window
        ↓
Static Rules + Local Jev / Qwen3-4B
        ↓
Hybrid Decision
        ↓
BENIGN / REVIEW / HIGH_RISK / UNCERTAIN
        ↓
SQLite + Dashboard

本地 Jev + Qwen3-4B

JevSec 当前使用本地 Jev 兼容运行层，后端模型固定为 Qwen3-4B-Instruct-2507。

我没有先上 14B、32B 或更大的云模型，因为我真正想验证的是：一个普通开发者自己机器上能跑的小模型，到底能不能给安全系统提供有意义的增量。

安全日志本身又非常敏感，所以 JevSec 会先做 Privacy-aware Normalization。Cookie、Authorization、Password、API Key 等原始敏感值不会直接作为模型上下文长期保留，Session / User 也会先做伪匿名化。

第一轮真正让我冷静下来的 Benchmark

JevSec 早期跑过一些很漂亮的 synthetic benchmark，但后来我越来越觉得，如果数据也是自己设计的，模型可能只是在识别“我设计出来的异常”。

于是我加入 CSIC 2010 HTTP 数据，重新构造了一套半真实 replay benchmark。

JevSec benchmark

方案RecallPrecisionObserved FPR检出异常
Static Rules20.69%100.00%0.00%30 / 145
Local Jev / Qwen3-4B23.45%97.14%0.95%34 / 145
JevSec Hybrid26.90%97.50%0.95%39 / 145

最直观的结果是 Static Rules 检出 30 个异常窗口，而 Hybrid 检出 39 个。也就是这一批测试数据里，Hybrid 检出的异常窗口数量相对增加约 30%。

真正的问题：AUROC 只有 0.454

Static Rules  AUROC = 0.522
Qwen3-4B      AUROC = 0.473
Hybrid        AUROC = 0.454

AUROC 接近 0.5，说明当前风险分数还没有很好地把正常和异常排序开。

所以 Hybrid 在当前 threshold 下额外捞到了一些异常，并不等于模型已经真正理解了哪些行为更危险。

这也是为什么 JevSec 目前仍然定位为 Research Alpha / Shadow Mode / Human Review，而不是 Production Blocking。

Jev + Sequence Context 可能才是关键

当前很多上下文仍然是聚合统计，比如 login_failures、unique_paths、request_count、sensitive_path。但 Web 行为安全真正重要的东西，很可能是顺序。

LOGIN_FAIL
→ LOGIN_FAIL
→ AUTH_SUCCESS
→ NEW_SENSITIVE_PATH
→ BURST_ACCESS

所以下一步准备做 Sequence Context：把请求转换成隐私安全的事件符号，再把有顺序的 State 交给决策层，而不是继续无限增加原始日志和 Prompt 长度。

Jev 和 Agent 爆火之后，我更关心“决策层”

Agent 真正落地以后，很快会遇到很多“判断”问题：它该不该执行这个动作，这个 Tool Call 安全吗，这个结果可信吗，现在该不该让人确认，这个任务值不值得升级到更贵的模型。

这些问题本质上都不是生成，而是决策。

当 AI 从“聊天”走向“执行”，真正缺的也许不是更多会说话的模型，而是更可靠的决策层。

JevSec 只是我把这个思路放到 Web 安全里的一个实验。

现在可以看什么

说明

JevSec 是我的开源实验项目；文中提到的 Jev 生态方向并不代表与 JevSec 存在官方合作或背书关系。本文中的 benchmark 是 JevSec 自身半真实 replay 评测，不是对 Jev 官方产品能力的测评。