企业架构、智能体设计 LangChain官方接入Jev：用Jev模型搭建智能体Harness #AI智能体Agent #Jev分类模型 2026-09-18 5K banq 传统的 Agent 工作流是一个持续的循环（Loop）：LLM 决策→调用工具 (Tool)→评估执行结果→继续下一步
LangChain官方宣布接入Jev模型，通过使用Jev来搭建智能体Harness，显著提升AI智能体的决策速度和效率。这一创新不仅解决了传统Agent工作流中存在的微小决策、评估和判断需要频繁调用大语言模型的问题，还通过RLCD训练法将分类任务的推理速度提升了200倍，成本降低至原来的四百分之一。Jev模型的设计重点在于其非生成文本的特性，专门用于评估状态并返回确定类型的答案和概率分布，极大地提高了处理速度和降低了成本。此外，Jev的训练方式基于Reinforcement Learning for Calibrated Decisions（RLCD），强调输出的概率值的准确性，而非仅仅是回答的逼真度。这种特性对于智能体系统来说至关重要，因为它确保了模型输出的概率值的真实性和可靠性，从而在自动化决策中提供了更高的信任度。
--91likeyou---
普通大模型的强化学习（比如RLHF）追求的是“回答得像人”，让人类打分员觉得舒服。RLCD追求的完全是另一件事：让模型输出的概率值本身是准的。什么叫概率准？就是Jev说这条工单有90%概率是紧急的，那你把100条它标了90%的工单拿出来看，真的紧急的应该差不多就是90条左右，不能是50条也不能是99条。
这个特性对智能体系统来说太重要了。你要用Jev来做工具调用的风险拦截，如果Jev说这个bash命令有85%概率是危险的，你就得能相信这个85%不是随口报的，而是一个真实的、可以拿来做决策阈值的数字。
对比一下现在的大模型，你让GPT-4o输出一个置信度，它给你的那个数字基本上是编的，跟真实概率对不上号。这也是为什么大家平时不敢用大模型输出的置信度来做自动化决策，只能拿来看个热闹！
一段代码，看清Jev怎么接进LangChain
LangChain已经出了官方的集成包，叫langchain-typesafe。装完之后，调用方式简单到你会怀疑人生。
python
from langchain_typesafe import Noul, TypeSafeClassifier
classifier = TypeSafeClassifier()
response = classifier.invoke(
state=(
"The deploy failed twice and customers are seeing 500s. "
"Can someone look now?"
),
questions={
"urgent": Noul(
instructions="Does this need attention right now?"
),
},
)
urgency = response.nouls["urgent"].noul
这段代码干的事情是：把一句英文的用户求助（“部署失败了两次，客户看到500错误，现在有人能看一下吗？”）传给Jev，问它一个问题“这个需要立刻处理吗？”，然后从返回结果里取出那个概率值。
传进去的state可以是文本，可以是结构化数据，也可以是LangChain的消息对象。这意味着你可以在智能体循环的任何一个节点插入Jev，把它当成一个毫秒级的判断插件。这个接口设计的克制程度，才是Jev真正跟其他“决策类模型”拉开距离的地方！
Jev的第一个杀手级应用，是模型路由
Jev最直接的应用场景，是给大模型系统做前置的“分流员”。LangChain官方给了一个叫ModelRouterMiddleware的中间件示例，代码长这样：
python
from langchain.agents import create_agent
from langchain_typesafe.experimental.middleware import (
ModelChoice,
ModelRouterMiddleware,
)
router = ModelRouterMiddleware(
choices={
"fast": ModelChoice(
model="openai:luna",
criteria="Direct lookups, extraction, and localized changes.",
),
"powerful": ModelChoice(
model="openai:sol",
criteria="Architecture and high-stakes decisions.",
),
},
instructions="Choose the least costly model that can complete the task.",
)
agent = create_agent("openai:gpt-5.6-luna", middleware=[router])
这段代码的意思是，你定义两档模型：便宜快速的luna处理简单查询和局部改动；昂贵强大的sol处理架构级别的高风险决策。然后给一个总指令：能用便宜的就用便宜的。Jev在用户消息进来的一瞬间做出判断，决定这轮到底走哪条路。
你可能会问，让大模型自己判断该用哪个模型不行吗？行是行，但那样每次判断本身就要花掉大模型的钱，跟你想省的钱正好抵消。Jev做这个判断的成本几乎可以忽略不计，而且判断结果自带概率值和置信度，可以保留在智能体的状态里，后续可以复盘或者调阈值。
真正让人上头的用法，叫自动模式守卫
第二个应用更关键，直接关系到智能体的安全。做过智能体产品的都知道，智能体本质上是不可信的：它可能被用户的话术骗到，也可能被恶意注入的指令诱导，去执行你不希望它执行的动作。
现在市面上的编码类智能体，比如Claude Code、OpenAI Codex、Cursor，都有一层危险动作拦截器，在执行rm -rf、git push --force这类命令之前，会先做一层分类判断：这个操作到底安不安全？但这层拦截器一直都是这些产品闭源的一部分，普通开发者要自己搭一套非常麻烦。
LangChain基于Jev做了个AutoModeMiddleware，把这套能力开源化：
python
from langchain.agents import create_agent
from langchain_typesafe.experimental.middleware import (
AutoModeMiddleware,
)
guardrail = AutoModeMiddleware(tools=["bash"])
agent = create_agent("openai:gpt-5.6-luna", middleware=[guardrail])
这几行代码干的事是：给智能体的bash工具加一道守卫。每次智能体想调用bash的时候，Jev先毫秒级评估一下这个调用有没有风险，如果风险超过阈值，直接阻止。这个能力过去只有闭源产品能提供，现在Jev让每个开发者都能装配。
三家早期用户的账单，暴露了真实价值
Jev发布之后，最早跳出来晒战果的是三家小团队，他们的用法各不相同，但共同点是账单都被打骨折了。
第一家是Browserbase的Kyle Jeong，他用Jev给浏览器操作智能体做决策层。浏览器智能体的老大难问题是每一步点击都要判断“下一步该点哪”，用大模型判断慢又贵。Kyle换成Jev之后，单次浏览器操作的成本降到了几分之一美分的水平。
第二家是Jarrod Watts，他搭了一个实时交易智能体。交易场景对延迟极其敏感，大模型秒级的响应根本没法用，Jev毫秒级的判断刚好卡进了实时交易的时间窗口。第三家Ryan Vogel做的是大规模邮件分诊，每天几万封邮件要分类打标签，用大模型跑一天的账单能让创业公司破产，用Jev之后成本压到了可以接受的范围。
这三个场景有个共同的隐藏特征：都是那种“判断多、生成少”的高频决策场景。这才是Jev真正吃到的市场空白。
Jev不是要杀死大模型，而是要做大模型的副驾
聊到这里必须泼一盆冷水。Jev不能取代大模型，一个字都写不出来的东西怎么可能取代GPT或Claude？
真正的架构是分层协作。大模型继续负责它擅长的事：开放式推理、代码生成、长文写作、复杂对话。Jev负责它擅长的事：毫秒级的结构化判断、路由决策、风险拦截、工具调用前的守门。两者的关系更像是主驾和副驾，不是替代关系。
这个架构变化的信号很明显：智能体系统正在从“一个巨型大模型扛所有活”演进到“分层组合，各司其职”。就像当年计算机架构从单核变多核，再从多核变异构计算（CPU+GPU+NPU），每一次分工细化都带来了几个数量级的效率提升。Jev可能就是智能体领域的“NPU时刻”，专门处理那些高频、低复杂度但对速度和成本极度敏感的任务。
但事情没那么简单，还有个悬而未决的问题：Jev的训练数据和评估基准目前都是TypeSafe AI自己公布的，官方声称的20到200倍加速、40到400倍成本压缩，在真实生产环境的多样化任务上到底能不能稳定复现，第三方独立评测还没跑出来。三家早期用户的账单只是个开始，整个开发者社区能不能验证出同样的数字，Diogo Almeida憋了两年的这个东西到底是不是真金，接下来的三个月才是关键窗口。
🔥 热词：#LangChain官方接入Jev · #用Jev模型搭建智能体Harness · #企业架构、智能体设计 · #AI智能体Agent · #Jev分类模型 · #2026 · #09 · #18