CSDN_Jev是什么_从Decision_Model到Web安全_JevSec

Jev 是什么从 Decision Model 到 Web 安全我用 Qwen3-4B 做了 JevSecJev 最近受到关注的地方并不只是“又一个模型”而是它强调了一种很适合 Agent 和安全系统的思路State → Decision。我把这套思路放进了一个 Web 行为安全实验项目 JevSec本文记录它的架构、Benchmark、问题和下一步。1. 为什么我开始关注 Jev最近在 Agent、Guardrail、Routing、Eval 这些方向里Jev 这种Decision Model思路越来越值得关注。普通 LLM 最自然的交互方式是Prompt ↓ 生成一段自然语言但真实的软件系统经常并不需要模型写一篇分析。程序真正想要的通常是YES / NO A / B / C 0~1 Score ALLOW / REVIEW / DENY例如 Agent 中常见的问题这个工具要不要调用 这个 Tool Call 风险高不高 这个结果是否可信 是否需要人工确认 要不要切换到更强模型这些本质上都是Decision而不是 Generation。所以我现在越来越认同一个思路模型负责模糊判断代码负责确定性控制。这也是我后来把 Jev 思路放进 Web 安全的原因。2. Jev 和普通 LLM 有什么区别假设你给模型一段访问行为登录失败 登录失败 登录成功 访问敏感路径 短时间请求多个接口普通 LLM 可能输出从当前行为来看该用户在短时间内出现多次认证失败随后登录成功并访问敏感路径存在潜在账户接管或自动化攻击风险……对于人来说这段话很好读。但对于程序来说真正有用的可能只是{should_review:true,category:auth_anomaly,risk:0.78}甚至REVIEW所以 Jev / Decision Model 这种思路更像Application State ↓ Typed Questions ↓ Decision / Score / Probability ↓ Program Logic而不是Prompt ↓ Generate Text ↓ Parse Text ↓ Retry JSON ↓ Extract Decision3. 为什么这个思路特别适合 Web 安全传统 Web 安全系统本身就有大量“判断问题”。比如这个请求要不要拦 这个 IP 要不要进入观察 这个 Session 是否偏离正常行为 这一段行为是否值得人工复核 多个弱信号叠加后是否应该升级风险传统规则非常擅长处理确定性问题。例如失败登录次数 5 AND 5 分钟内访问路径 20 THEN 风险 30规则的优点非常明显可解释可重复延迟低可审计行为稳定但问题是很多异常并不能写成一个简单的 if。例如NORMAL_PATH → LOGIN_FAIL → LOGIN_FAIL → AUTH_SUCCESS → NEW_SENSITIVE_PATH → BURST_ACCESS每条请求单独看都可能是正常的。真正可疑的是这些事情按这个顺序发生。这就是我做 JevSec 的出发点。4. JevSec 是什么JevSec 是我做的一个开源实验项目。GitHubhttps://github.com/ccjmcc/jevsec项目展示页https://www.easytool.me/jevsec/Jev / Decision Model 专题页https://www.easytool.me/jev/JevSec 不是一个新的 WAF。更准确地说它是一个Behavioral Security Triage Layer也就是放在现有 WAF 旁边专门分析跨请求行为。一句话Your WAF sees requests. JevSec sees behavior.5. WAF 和 JevSec 的分工成熟 WAF例如 OWASP CRS更擅长SQL Injection XSS Path Traversal Command Injection 异常编码 危险 Payload这些问题通常在一条 HTTP 请求里就已经有明显特征。而 JevSec 更希望关注多个请求之间的顺序 频率变化 认证状态变化 路径 Novelty Session 行为变化 规则与模型冲突 多个弱信号组合因此二者不是替代关系。更合理的架构是┌──────────────┐ HTTP Request ───→│ WAF │ │ Request-level │ └──────┬───────┘ │ ▼ Application 同时 Nginx / JSONL ↓ JevSec ↓ Behavior Window ↓ Rules Local Model ↓ REVIEW / HIGH_RISK / UNCERTAIN6. JevSec 当前架构目前结构大致是Nginx / JSONL ↓ Privacy-aware Parser ↓ Behavior Window ↓ ┌────────────────────┐ │ Static Rules │ └────────────────────┘ ┌────────────────────┐ │ Local Jev Runtime │ │ Qwen3-4B │ └────────────────────┘ ↓ Hybrid Decision ↓ BENIGN REVIEW HIGH_RISK UNCERTAIN ↓ SQLite Dashboard当前模型使用Qwen3-4B-Instruct-2507我没有一开始就换成 14B、32B 或更大的云模型。原因是我真正想验证一个普通开发者可以本地运行的小模型到底能不能给安全系统提供有意义的增量。7. 为什么坚持本地 Qwen3-4BWeb 安全日志本身很敏感。它可能包含Cookie Authorization Session 用户路径 内部接口 请求参数 业务结构所以 JevSec 不是把完整请求直接丢给模型。目前会先经过 Privacy-aware Normalization。不会直接保留到模型上下文的内容包括Cookie Authorization Password API Key 未知 JSON 字段Session / User 等标识也会先伪匿名化。模型更多看到的是request_count unique_path_count login_fail_count auth_state_change path_novelty encoding_density sensitive_path_indicator burst_pattern核心原则是保留行为结构而不是保留原始秘密。8. Benchmark第一眼其实挺好看我后来使用 CSIC 2010 HTTP 数据构造了一套半真实 replay benchmark。当前核心测试250 个 held-out Behavior Windows 145 anomalous 105 normal每个窗口12 requests其中一部分异常窗口只混入1~3 条异常请求结果方法RecallPrecisionObserved FPR检出异常Static Rules20.69%100.00%0.00%30 / 145Local Jev / Qwen3-4B23.45%97.14%0.95%34 / 145JevSec Hybrid26.90%97.50%0.95%39 / 145最直观的数据Static Rules : 30 / 145 Hybrid : 39 / 145也就是在这一批 held-out replay 中Hybrid 检出的异常窗口数量相对增加约 30%。正常窗口中1 / 105被额外送进 Review。9. 但真正关键的问题AUROC 0.454如果只看上面一张表很容易得出AI 已经明显优于规则。但继续看 AUROCStatic Rules AUROC 0.522 Qwen3-4B AUROC 0.473 Hybrid AUROC 0.454这个结果就完全没有那么漂亮。AUROC 接近 0.5意味着风险分数整体还没有很好地区分正常和异常。因此当前能得出的结论应该非常克制JevSec Hybrid 在这个 held-out replay 工作点下额外检出了一部分静态规则没有抓到的异常窗口但当前风险排序能力仍然较弱。不能说AI 比 WAF 强也不能说已经可以检测未知攻击更不能说可以直接生产自动拦截10. 为什么 JevSec 现在只跑 Shadow Mode当前 JevSec 不会自动封 IP 自动改防火墙 自动 Block 请求它现在的定位是Research Alpha Shadow Mode Human Review原因很简单。如果模型误报之后只是 Dashboard 上多一个 Review影响有限。但如果模型误报之后直接iptables DROP那就是业务事故。所以我更倾向于确定性安全逻辑 → WAF / Rules 模糊行为判断 → Jev / Model 最终控制 → Code / Human11. 当前真正的问题可能不是模型太小一开始看到 AUROC 只有 0.473 / 0.454 时我也想过是不是 Qwen3-4B 太小但后来我越来越怀疑问题可能首先出在State Representation。当前很多输入仍然是聚合统计例如login_failures 2 unique_paths 8 request_count 12 sensitive_path 1问题是下面两段行为统计值可能很接近。行为 ALOGIN_FAIL → LOGIN_FAIL → AUTH_SUCCESS → NEW_SENSITIVE_PATH行为 BAUTH_SUCCESS → NORMAL_PATH → NORMAL_PATH → LOGIN_FAIL但是它们的安全含义完全不同。所以真正丢失的信息可能是Sequence12. 下一步Sequence ContextJevSec 下一步准备把聚合特征进一步升级成隐私安全的事件序列。例如NORMAL_PATH NEW_PATH LOGIN_FAIL AUTH_SUCCESS SENSITIVE_PATH HIGH_ENCODING BURST_ACCESS ENUMERATION_PATTERN最终交给决策层的 State 可能变成NORMAL_PATH → LOGIN_FAIL → LOGIN_FAIL → AUTH_SUCCESS → NEW_SENSITIVE_PATH → BURST_ACCESS我认为这个方向其实非常符合 Jev 的设计哲学State → Decision真正重要的不是Prompt 写 3000 字还是 6000 字而是State 有没有保留真正有意义的信息13. Jev 和 Agent 为什么很搭Agent 真正进入生产以后会遇到很多类似问题要不要调用这个工具 这个工具调用安全吗 这个结果可信度多少 要不要让用户确认 是否需要升级到更强模型 当前动作应该 Allow / Ask / Deny这些问题本质上都是Decision而不是Generation所以我觉得 Jev 这类思路真正值得关注的地方是当 AI 开始从“聊天”进入“执行”Decision Layer 可能会变成非常重要的一层基础设施。14. JevSec 最后不一定让 Qwen 做所有事情还有一种可能Qwen3-4B 最终根本不适合做主 Risk Classifier。如果 Sequence Context 做完之后AUROC 仍然接近 0.5那正确的做法可能不是继续堆 Prompt。而是重新分工Temporal Classifier ↓ Risk Score WAF / Rules ↓ Deterministic Evidence Jev ↓ Structured Decision Qwen3-4B ↓ Explanation / Review也就是说LLM 不一定非要做分类器。它可能更适合解释、Review、处理规则难表达的边缘案例。15. JevSec 当前已经有什么目前项目已经包含Local Qwen3-4B Behavior Window Static Rules Hybrid Decision Nginx / JSONL ingestion Shadow Mode Dashboard SQLite Docker Benchmark OWASP CRS comparison Failure Analysis Privacy Design Threat Model CIGitHubhttps://github.com/ccjmcc/jevsecJevSec 项目页https://www.easytool.me/jevsec/Jev / Decision Model 专题https://www.easytool.me/jev/16. 最后我现在越来越觉得Jev 最值得研究的问题不是它是不是一个比普通 LLM 更快、更便宜的新模型而是我们是不是一直在用生成式模型解决其实只需要结构化判断的问题如果一个任务真正需要的是yes / no A / B / C 0~1 risk allow / review / deny那么让模型生成一整段自然语言再让程序重新解析它可能本身就是绕路。JevSec 现在还远远不能证明这个方向已经成功。当前 Hybrid AUROC 只有0.454真实生产流量也还没有完成充分验证。但至少它让我开始认真思考一个问题当 AI 从“聊天”走向“执行”真正缺的也许不是更多会说话的模型而是更可靠的决策层。这也是我接下来准备继续做 JevSec 的方向。项目地址GitHubhttps://github.com/ccjmcc/jevsecJevSechttps://www.easytool.me/jevsec/Jev 专题https://www.easytool.me/jev/个人博客https://www.ccjmcc.xyz/标签建议JevDecision ModelQwen3本地大模型Web安全WAFAgentAI安全网络安全开源项目