Jev 不是万能的：这 5 类任务依然应该交给 LLM

摘要：

Jev 擅长分类、路由、评分和风险判断，但这并不意味着 Agent 里的大模型可以被大量替换。

真正的工程难点，不是判断 Jev 和 LLM 谁更强，而是划清两者的任务边界。

一旦任务涉及开放式生成、复杂推理、动态规划、代码修改或者需要完整解释，LLM 依然不可替代。

把快速判断交给 Jev，把复杂思考留给 LLM，可能才是更合理的 Agent 架构。

一、Agent 架构正在遇到一个新的问题

Jev 出现以后，一个很容易产生的想法是：

既然很多 Agent 任务本质上只是分类、路由和判断，那是不是可以少调用一些 LLM？

这个思路本身没问题。

比如：

应该调用哪个 Tool？

应该加载哪个 Skill？

这次操作风险高不高？

当前结果要不要进入 Context？

Agent 是否应该继续执行？

这些任务通常：

• 输出范围明确
• 判断频率高
• 不需要长文本
• 不需要复杂推理

确实很适合 Decision Model。

但问题也随之出现：

如果什么任务都开始往 Jev 上迁移，又会走向另一个极端。

因为 Jev 的优势，本身就建立在一个前提上：

问题边界相对清晰，而且输出空间能够提前定义。

一旦这个前提不存在，LLM 依然更合适。

二、第一类：开放式内容生成

这是最明显的一条边界。

比如：

根据需求写一份测试方案。

分析这些日志并生成一份故障报告。

根据 PRD 编写完整测试用例。

帮我写一段自动化测试代码。

这些任务的答案没办法提前限定成：

A
B
C

或者：

高风险
中风险
低风险

它需要模型完成：

理解需求
↓
组织信息
↓
生成结构
↓
补充细节
↓
形成完整内容

这里真正需要的是：

生成能力。

这也是 LLM 的核心优势。

三、第二类：复杂多步推理

假设线上支付接口突然出现异常。

输入信息包括：

最近代码 Diff

接口失败日志

调用链

数据库慢查询

历史故障

监控指标

现在要求 Agent：

找出最可能的根因。

这已经不是简单的分类问题了。

它可能需要：

提出假设
↓
寻找证据
↓
验证假设
↓
发现矛盾
↓
重新分析
↓
补充信息
↓
最终定位原因

关键在于：

模型一开始甚至不知道完整的推理路径是什么。

这种问题不是：

A、B、C 选哪个？

而是：

问题到底应该怎么拆？

这仍然是 LLM 更擅长的领域。

Decision Model 可以参与其中的某些节点。

例如：

这个异常值得继续调查吗？
→ Jev

下一步更应该查看日志还是数据库？
→ Jev

真正分析调用链和代码：
→ LLM

两者可以配合，但不能简单互换。

四、第三类：代码生成和代码修改

对测试开发来说，这条尤其重要。

Jev 可以很好地判断：

这个 Diff 风险高吗？

应该执行哪些测试？

这是接口问题还是数据问题？

应该加载哪个测试 Skill？

但如果任务变成：

修复这个接口超时问题。

事情就完全不一样了。

Agent 需要：

理解代码
↓
定位问题
↓
修改实现
↓
生成 Patch
↓
执行测试
↓
根据结果继续修改

这里不仅需要判断。

更需要：

代码生成 + 上下文理解 + 多步推理。

所以未来 Coding Agent 更合理的架构不是：

Jev 替代 LLM

而是：

Jev
负责路由和判断

+

LLM
负责真正写代码

五、第四类：连问题边界都不清楚的任务

Decision Model 很擅长回答：

这是 A、B 还是 C？

但现实中很多任务根本没有这么清晰。

比如用户只说：

系统最近感觉有点慢，你帮我看看。

这时候 Agent 首先要做的不是分类。

而是：

用户说的“慢”是什么？
↓
页面加载？
↓
接口响应？
↓
数据库？
↓
网络？
↓
某个具体业务？

Agent 可能需要不断：

澄清、探索、提出问题、重新定义问题。

甚至一开始：

候选答案空间都不存在。

这就是 Jev 很重要的一条边界。

可以简单理解成：

Decision Model 擅长在已有边界里做选择。

而：

LLM 更擅长先把问题边界找出来。

六、第五类：需要解释“为什么”的高风险决策

假设 Agent Guardrail 给出了：

高风险：96%

对于程序来说，这个结果可能已经足够。

系统可以：

阻断 Tool Call

但如果这是一次人工审批：

审核人员还会继续问：

为什么高风险？

涉及了什么数据？

哪一步存在问题？

如果放行会有什么后果？

这时候一个：

96%

显然不够。

系统还需要根据：

Tool 参数
执行上下文
用户权限
目标资源
历史行为
业务规则

形成一段完整解释。

所以在很多高风险场景里，可以这样分工：

Jev
↓
做判断

LLM
↓
解释判断

这种组合反而比只使用其中一个更合理。

七、Jev + LLM，可能才是更实用的架构

Agent 工程真正需要解决的，不是：

Jev 和 LLM 到底谁更强？

而是：

什么问题应该交给谁？

这里其实有一个很清晰的分工：

规则

解决：

确定性问题。

Jev

解决：

边界明确的快速判断。

LLM

解决：

复杂推理和开放式生成。

Tool / Skill

负责：

真正执行任务。

这比单纯追求：

“尽可能少调用 LLM”

更合理。

八、怎么判断一个任务该交给谁？

实际做架构设计时，可以先问两个问题。

第一个问题：输出空间能不能提前定义？

比如：

继续 / 重试 / 停止

高 / 中 / 低

Skill A / Skill B / Skill C

保留 / 删除

这种任务非常适合 Decision Model。

因为我们已经知道：

答案可能是什么。

第二个问题：模型需要创造新的内容吗？

例如：

生成代码

制定测试方案

分析复杂故障

解释问题原因

规划多步任务

这些任务的答案无法提前枚举。

通常应该继续交给 LLM。

所以可以先记住一个非常简单的判断方法：

答案空间已知，更适合 Decision Model。

答案空间未知，更适合 LLM。

这不是绝对规则，但对于 Agent 架构设计非常实用。

九、真正危险的是“模型用错地方”

Jev 这类模型真正带来的价值，并不是：

以后少用大模型。

而是让 AI 系统多了一种新的能力选择。

以前我们的架构很容易变成：

遇到智能问题
↓
调用 LLM

以后可以进一步拆成：

确定性问题
→ 规则

高频判断
→ Jev / Decision Model

复杂分析
→ LLM

真实动作
→ Tool / Skill

高风险问题
→ 人工

这样做的核心目标不是：

谁替代谁。

而是让不同类型的问题，使用不同成本、不同能力的组件。

写在最后

Agent 越来越复杂以后，一个成熟的系统不应该只有一个“大脑”。

因为：

分类和写代码不是一类问题。

Tool Routing 和根因分析不是一类问题。

风险判断和制定方案也不是一类问题。

如果所有事情都交给 LLM：

成本高，延迟高，也未必稳定。

但如果为了追求速度，又把大量复杂任务交给 Decision Model：

系统同样会失去真正的推理能力。

所以真正值得关注的，不是：

Jev 能替代多少 LLM。

而是：

能不能把 Jev 和 LLM 放在各自最适合的位置。

这可能才是 Agent 从 Demo 走向生产环境以后，越来越重要的一项架构能力。