用 Jev 和 LangGraph 构建生产系统

Building Prod with Jev and LangGraph

作者：Sydney Runkle 与 Hunter Lovell（LangChain）

TypeSafe 把他们的哲学总结成一句话：构建「prod, not god」。

上周 TypeSafe AI 发布了 Jev，一种新型模型。和传统 LLM 不同，Jev 不生成文本。它做出你的代码可以直接据以行动的决策——这就是 TypeSafe 所说的「AI 驱动的软件」：代码拥有工作流，AI 处理窄的、结构化的决策。

一、问题的由来

随着前沿 LLM 变得更强，我们开始把它们当成神来用，任何输入模糊的任务都伸手去够它们：散文生成、文档抽取、搜索、排序、研究、分类等等。

不幸的是，神很贵，而且很慢。你为那份通用性在每一次调用上付费——即使你只想要一个「是」或「否」。

这就是 Jev 的发布引起这么多关注的原因。在窄的决策任务上——比如很多 agent 赖以构建的路由和分类步骤——TypeSafe 的基准显示 Jev 比领先的 LLM 快最多 200 倍、便宜 400 倍。

二、返回同一个答案，是 Jev 最被低估的性质

Jev 把一项能力从前沿 LLM 的捆绑包里拆了出来——判断——并把它变成一个便宜到不用计量的原语。

它是 TypeSafe 所说的 system one 模型，更常见的叫法是决策模型。你给它状态和一组问题，它返回带概率的类型化答案。

作者列了四条让它够格成为生产系统组件的性质：

· 结构化：答案是带概率的类型化答案，所以代码可以可预测地据其分支

· 并行：你可以一次对同一份状态问很多问题

· 快：决策足够便宜，可以在一次运行里做很多次

· 自洽：system one 被设计成在重复评估中返回稳定的答案

最后一条值得单独说，因为他们给了一个实验数字：

Jev 的一致性相对于 LLM 的非确定性，是一个令人欢迎的变化。 同样的问题问一个 LLM 多次，你会得到不同的答案。Jev 被设计成对同样的输入返回同样的答案。在一次早期的「Jev 当裁判」实验里，它的分数在 100 次重复运行中几乎没有变动，远小于我们测试过的任何 LLM 裁判。

TypeSafe 给出的三种构建软件的方式

传统软件：由显式逻辑构成，每个分支都是手写的、可审计的，但因此很僵硬。

Agent：摆向另一极——一个模型在每一步都处理所有决策，控制流从代码里跑到了提示词里。

AI 驱动的软件：走中间路线。代码保留结构、处理精确计算，模型只坐在那些需要语义判断的分支上。

三、LangGraph 负责编排

一旦决策这么便宜，挑战就变成了如何编排它们——这就是 LangGraph 的用途。

作者说他们帮团队构建基于 LLM 的系统多年，几乎每一个都会撞上同样两个问题：

① 管理上下文很难。 要做出正确的决策，模型的上下文窗口需要「恰好是下一步所需的信息」。那份信息是模糊的，而且随着应用运行而变化。

② 模型驱动的系统仍然需要可靠。 它们必须能在失败中存活、支持人工介入、并让每一步都可观测。

State 即上下文

一个 LangGraph 应用由三部分构成：

· 节点是工作单元：普通代码、一次模型调用、一次工具调用，或者一整个子图

· State 是节点读取和更新的信息

· 边决定接下来跑哪个节点，要么沿固定路径，要么根据当前状态动态决定

任何图也可以是大图里的一个节点，所以小而经过测试的部件能组合成更大的系统。

随着图运行，每一步的结果都累积进 state。那个 state 成为后续每一步的上下文，同时它也决定接下来跑哪些节点。

作者点出了这套设计的核心：

与其把领域知识塞进提示词，你把它编码进图的拓扑里：做哪些决策、以什么顺序、以及每个决策能看到什么状态。

判断来自模型，但流程留在你可以检视和测试的代码里。

可靠的运行时

作者引用 TypeSafe 的主张：你只在某个组件可靠之后才让它无人值守地运行，只在你能够检视、测试和约束它之后才在它之上构建。 LangGraph 在运行时层面处理这件事：

① 持久化执行：模型驱动的步骤是非确定性的，所以同样的输入可能让模型做出不同的调用、把运行带到不同的路径上。失败后从头重跑不只是慢，而是可能不会重走同一条路径。 Checkpointing 在每一步持久化 state，所以失败的运行会带着它已经做出的决策继续。

② 人工在环：当某一步需要人在系统行动前复核时，interrupt 让你暂停、批准、然后从离开的地方继续。

③ 可观测性：模型驱动的步骤不是每次都做同样的事，所以你需要 LangSmith 里的 trace 来看清做了什么决策、以及为什么。

作者强调：这些都不是 LLM 特有的。Jev 仍然接受非结构化的文本上下文并返回一个判断，所以它需要同样的保证——而图自动把保证给了每一个节点。

四、完整例子：诉讼中的文档审查

在诉讼里，一家公司必须在把文件交给对方之前审查每一页，而单个案件可能达到几十万页。 其中大部分审查就是对同一类有界判断的反复调用，这让它成为 Jev 的天然适配场景。

对每一页，Jev 在一次请求里回答三个问题，每个答案映射到图里的一条路由：

· 这一页和请求相关吗？ 不相关就放到一边

· 它包含个人信息吗？ 包含就让 LLM 去脱敏

· 它可能受特权保护吗？ 可能就送到 attorney_review，这会暂停图等待人工在环

剩下的一切就可以交付了。（实践中，页是并行处理的。）

Jev 处理所有分类，图只在某页需要更多处理时升级——升级到 LLM 做脱敏，或升级到律师做特权判断。

关键的对比数字

我们用同一个图跑了两次，一次用 Jev 做分类、一次用 Sonnet 当裁判，跨多次试验，Jev 在分类这一步快 5–6 倍。

两次运行都在 LangSmith 里被 trace 了，所以你可以打开任何一页，看它走了哪条路由、以及背后的概率。LangSmith 还为 Jev 这类决策模型做了专门的视图，显示每个决策的输入和校准过的输出。

五、「智能的大解绑」

作者引用 Jaya Gupta 的说法——接下来会发生的是「智能的大解绑」：

在过去三年里，大多数 agent 把所有东西都路由到一个前沿 LLM。接下来，那些能力会被拆开，每一项去到能处理它的最便宜的模型那里。

Jev 把判断拆了出来，返回结构化决策而不是生成的文本。而一旦这些部件被分开，就必须有东西把它们重新缝合起来——给每一步做路由、决定什么时候升级。那就是运行时的活。

浏览器自动化是这套东西的具体形态

一个浏览器 agent 读一个页面并决定接下来做什么：点一个按钮、填一个字段、滚动。这听起来是开放式的，但在任何一个时刻，一个页面只提供有限的一组可交互元素——所以下一步动作其实是从一个列表里做选择。

Browserbase 基于这个想法重建了 Stagehand 的 act()：

Stagehand 在页面上标出可交互元素，Jev 选出动作类型和最佳候选元素，任何低于 0.7 置信度阈值的情况回退给 LLM。在早期测试里，act() 的中位延迟从 1.97 秒降到 0.46 秒，约快 4.3 倍。

那句总结

Jev 在大多数用例里并不完全取代 LLM。它处理它有把握的有界选择，把其他一切交给 LLM。

作者把 Jaya Gupta 描述的这个转变讲得很清楚：

从「默认用前沿，之后再优化」转向「默认用便宜的，例外时才上前沿」。

他们预期会看到更多这个模式：决策模型在动作空间受限的地方做快速、便宜的调用，而 LLM 保留给开放式的推理和小模型不确定的情况。

一个开发者的反馈：

「我基本上正在把我们现在有的每一个 agent 都转成由 Jev 驱动的工作流。」

链接

原文：https://www.langchain.com/blog/building-prod-with-jev-and-langgraph

前作（用 Jev 构建 harness）：https://blog.langchain.com/building-a-harness-with-jev/

TypeSafe 的宣言（prod, not god）：https://typesafe.ai/blog/introducing-system-one-models-and-jev

#Jev #LangGraph #Agent工程