Jev与Decision Model：重新定义Agent架构中的高频判断

一个Agent真正跑起来以后，会产生大量判断：该调用哪个Tool？加载哪个Skill？哪些上下文值得保留？这次操作有没有风险？执行结果需不需要人工检查？过去，这些问题很多都交给LLM处理。但Jev这类Decision Model出现以后，一个新的Agent架构开始值得关注：LLM继续负责复杂推理，但高频、明确的判断任务，可以单独拆出一层。这可能会直接影响未来Agent Harness的设计走向。

LLM承担过多高频判断的现状

很多人理解Agent，会把注意力放在模型多强、Tool有多少、Skill做得好不好。但真正把Agent跑到生产环境，会发现另一个问题：一次任务里面，LLM被调用得太频繁了。例如用户说帮我测试一下这个网站的登录功能，Agent可能要连续判断用户到底想干什么、应该加载哪个Skill、应该调用Playwright还是其他工具、哪些页面信息值得放进上下文、当前结果是否异常、是否继续执行、最终结果是否可信。这里真正需要复杂推理的，其实没有那么多。大量问题只是分类、路由、评分和判断，但今天很常见的做法是每碰到一个问题就调用一次LLM。于是延迟、成本和不确定性也跟着不断叠加。

Decision Model的架构设计思路

TypeSafe在2026年9月发布Jev时，把它定义成一种System One Model：输入程序状态，直接输出类型化决策、概率和置信度，而不是生成一段自由文本。例如应该调用哪个Tool，系统直接输出Playwright：91%、HTTP Client：6%、Search：2%、Other：1%。程序不需要再等模型生成一段JSON再解析、校验Schema、提取字段，而是直接根据判断结果继续执行。这意味着Agent Harness里可能出现一个新的分层：LLM负责想，Decision Model负责大量快速选。原来Agent Harness里面本身就存在大量判断型工作，这类工作交给专门的模型处理会更加高效。

多场景落地的判断任务拆分

从产业实践来看，有几类高频判断任务非常适合从LLM中拆分出来。第一是Tool Routing：当Agent开始挂几十个Tool、几十个MCP、几十个Skill时，路由本身变成一个独立问题。可以先经过判断层完成用户需求到Tool分类与评分的映射，候选Tool再交给Agent执行，LLM不需要每次从几十个工具里重新理解一遍。第二是Skill Routing：未来一个企业Agent很可能拥有几十甚至上百个Skill，如果一开始把所有Skill都塞进上下文，上下文会越来越重；如果全部让LLM动态选择，路由本身又会不断消耗推理资源。所以用户任务经过快速判断筛出2到3个Skill后，再交给LLM深度执行，这其实就是把能力发现和能力使用拆开。

判断分层对开发者的启示

除了Tool Routing和Skill Routing，还有三类重要场景值得关注。Context Filtering解决的是上下文太多的问题：RAG检索100条经过相关性判断留下10条进入LLM，这种任务不需要强模型写一大段分析，需要的是大量、快速、低成本的相关性判断。Guardrail判断的是执行前的风险等级：读取网页风险很低，删除文件风险不一样，修改数据库风险更高，执行之前需要判断允许自动执行、需要二次确认还是需要人工审批。Agent Trace Review则关注执行后的质量把控：系统直接决定自动关闭、人工检查优先还是创建Issue路由处理，而不是生成一篇长报告。这些判断任务交给Decision Model处理，可以让整个Agent系统更加高效可控。

Jev现在还是一个非常新的产品，讨论它会不会成为Agent标配还太早。但它提出的问题很值得关注：一个Agent里面真的所有智能任务都应该交给LLM吗？未来的答案很可能是：不是的。确定的问题交给规则，高频判断交给Decision Model，复杂问题交给LLM，执行交给Tool和Skill。Agent Harness接下来真正竞争的，可能不只是能接多少模型、多少MCP，而是能不能把不同类型的智能放到正确的位置上。