JEV 又有新玩法：当 AI Agent 开始拥有一个“决策层”

上一篇介绍 JEV 的时候，我提到过一个比较有意思的概念：JEV 不太像传统的大语言模型，它更像一个专门负责"做决定"的 AI。最近继续关注 JEV，我发现真正值得研究的地方，可能并不是 JEV 本身，而是它和 Agent 结合之后会发生什么。

现在的 Agent 有一个很明显的特点：什么事情都喜欢问 LLM。用户提出问题，要问 LLM；应该调用哪个工具，要问 LLM；搜索结果是否有用，要问 LLM；这个操作有没有风险，还是要问 LLM。于是一个复杂一点的 Agent，很容易变成这样：

复制代码

用户
 ↓
LLM
 ↓
选择工具
 ↓
Tool
 ↓
LLM
 ↓
判断结果
 ↓
继续执行

Agent 越复杂，里面的 LLM 调用就越多。这时候一个问题就出现了：这些决策真的都需要一个大语言模型来完成吗？

LLM 擅长"想"，但不一定什么都应该让它做

LLM 最厉害的地方是理解复杂问题、推理、生成代码和自然语言。比如让它分析一个 GitHub 项目，让它回答"这个项目是干什么的？用了哪些技术？有没有潜在问题？应该怎么改进？"，这种复杂任务当然应该交给 LLM。

但如果只是让 AI 在几个选项中做选择，例如"这个请求应该交给 Search Agent、Code Agent 还是 Database Agent"，我们真正需要的可能并不是一段完整的自然语言回答，而是一个明确的决策结果。

css 复制代码

输入：用户请求

JEV：
Code Agent
概率：0.91

这就是 JEV 这种 Decision Model 有意思的地方。它不是想替代 LLM，而是把 AI 应用中的一部分工作单独拿出来，让 LLM 负责复杂推理，让 JEV 负责决策。

JEV + Agent，会发生什么？

假设我们正在开发一个 AI Agent 平台，里面有 Search Agent、Code Agent、Database Agent 和 Writing Agent。用户输入："帮我分析一下这个 GitHub 项目。"

传统方式很可能是先把问题交给一个 LLM，让 LLM 自己判断应该调用哪个 Agent。如果引入 JEV，就可以增加一个 Decision Layer：

css 复制代码

用户请求
   ↓
JEV
   ↓
选择 Agent
   ↓
Search / Code / Database / Writing

JEV 不需要把整个任务完成，它只需要回答一个问题：现在应该选择谁？

这其实非常符合软件工程的思想。我们不会让数据库负责写前端，也不会让 Redis 负责处理业务逻辑。不同的问题应该交给不同的组件。那么 AI 应用为什么一定要让一个 LLM 什么都做？

JEV + RAG，也很有意思

另一个我比较关注的方向是 RAG。我们现在做 RAG，通常会使用向量搜索、BM25 或 Hybrid Search 找到候选文档，然后把这些文档交给 LLM。

问题是，搜索结果相似，不代表真正有用。

比如用户问："MySQL 为什么会发生死锁？"搜索可能找到 MySQL 锁机制、MySQL MVCC、MySQL 事务、MySQL 性能优化等很多内容。这些内容都和问题有关系，但相关程度并不一样。

于是可以把 JEV 放到搜索和 LLM 中间：

css 复制代码

Query
 ↓
Vector Search + BM25
 ↓
候选文档
 ↓
JEV
 ↓
相关性判断 / Score
 ↓
Top K
 ↓
LLM

这里三者的分工就很清晰了：搜索负责"找"，JEV 负责"选"，LLM 负责"理解和生成"。

这也是我觉得 JEV 很值得关注的地方。它并不是简单增加一个模型，而是在重新拆分 AI 应用里的职责。

JEV + Tool Calling

Agent 还有一个很现实的问题：工具不是都可以直接调用。

例如一个 Agent 有：

scss 复制代码

search()
database()
send_email()
delete_file()

搜索当然可以直接调用，但 delete_file() 和 send_email() 就不一样了。传统 Agent 可能是 LLM 决定调用工具，然后直接执行。如果加入 Decision Model，可以变成：

sql 复制代码

Agent
 ↓
Tool Call
 ↓
JEV
 ↓
判断
 ↓
允许 / 拒绝 / 人工确认

例如低风险操作自动执行，中风险操作进行二次检查，高风险操作交给人工确认。

这时候 JEV 就不只是 Router 了，它甚至可以充当 Agent 的一个 Decision Guard。当然，这并不意味着 JEV 判断永远正确。AI 做出的概率判断依然可能出错，所以真正的生产环境里，还需要结合传统规则、权限系统和人工确认。

JEV + AI Coding，会不会更有意思？

最近 AI Coding Agent 发展非常快，Codex、Claude Code 这类工具已经可以自己修改代码、执行命令、运行测试。但 Agent 能做的事情越来越多以后，一个问题也会越来越明显：什么事情可以自动做，什么事情必须停下来？

比如一个 Coding Agent 修改了代码，可以让 Decision Model 判断这次修改的风险，然后根据结果进入不同流程：

复制代码

低风险 → 自动测试 → 自动提交

中风险 → AI Review → 再测试

高风险 → 人工 Review

这时候 LLM 负责写代码，JEV 负责判断风险，传统 CI/CD 负责真正执行。

三者之间的关系就变成了：LLM 负责"写什么"，JEV 负责"要不要"，Code 负责"执行它"。

JEV 真正想改变的可能不是"大模型"

如果把 GPT、Claude 和 JEV 放在一起比较，很容易产生一个误解：JEV 是不是想成为 GPT 的替代品？

我觉得这不是最值得关注的问题。

更有意思的问题应该是：未来的 AI 应用，是不是需要一个独立的 Decision Layer？

过去我们习惯把 AI 理解成 Generate，后来变成 Generate + Tool，再后来出现 Agent，把 Reason 和 Act 加进来。而 JEV 试图补充的，是其中的 Decide。

css 复制代码

             AI Application
                    │
          ┌─────────┼─────────┐
          ↓         ↓         ↓
         LLM       JEV       Code
          │         │         │
        推理生成    决策判断    确定执行
          │         │         │
          └─────────┼─────────┘
                    ↓
                  Agent

这样来看，JEV 就不再只是一个"新模型"，而更像是 AI 应用架构里面新增的一种基础能力。

当然，现在下结论还太早

JEV 目前仍然非常早期。它到底能不能在真实生产环境里大规模使用，还需要继续观察。模型准确率怎么样，概率是否真的校准，和普通 LLM 做分类、Function Calling 相比有什么优势，成本和延迟怎么样，这些都需要真实项目验证。

所以现在我不会把 JEV 说成什么"下一代 GPT"。但我会继续关注它，因为它提出了一个很有意思的问题：

AI 应用是不是不应该只有一个"大脑"，而应该把生成、决策、执行拆成不同的能力？

如果答案是肯定的，那么 JEV 这种 Decision Model，就可能成为 Agent 基础设施中的一个新组件。

而这，可能比"又出现了一个 AI 模型"更值得开发者关注。