返回 DailyX Article2026年9月26日
Sydney Runkle 的 X 长文《Building Prod with Jev and LangGraph》封面

用 Jev 和 LangGraph 造生产级 AI 系统

Building Prod with Jev and LangGraph

SRSydney Runklesydneyrunkle
内容摘要:LangChain 工程师 Sydney Runkle 实操演示如何把 Jev 决策模型接进 LangGraph 编排:分支处用廉价的 system-one 判断,其余全部交给确定性代码。文章覆盖 Jev-as-a-judge 的百次评分几乎不动的一致性数据、PII 分类的视频演示、基于 interrupt 的人工介入流程,以及在成本与延迟上,路由为何优于什么都问前沿 LLM。“造产品,不当神”是从 demo 走向生产的一条可行路径。
核心要点(3条)

核心要点(3条)

  1. 1Jev 把“判断”做成了原语:带概率的类型化答案,远比调用 LLM 便宜。
  2. 2LangGraph 掌控控制流,模型只坐在需要语义判断的分支上。
  3. 3基于 interrupt 的人工介入,让高风险决策可审计而不牺牲自动化。
查看原文

FULL TEXT

完整正文

Building Prod with Jev and LangGraph

上周,TypeSafe AI 发布了 Jev,一种全新的模型。与传统 LLM 不同,Jev 不生成文本,而是做出你的代码可以直接执行的决策,服务于 TypeSafe 所称的 AI 驱动软件——“代码掌管工作流,AI 只负责狭窄而结构化的决策”。TypeSafe 将其哲学总结为“造产品,不当神”。

随着前沿 LLM 越来越强,我们开始把它们当成神来用:凡是输入模糊的任务都找它——写文案、抽取文档、搜索、排序、调研、分类等等。遗憾的是,神既昂贵又缓慢。每一次调用你都在为这种通用性买单,哪怕你需要的只是一个“是”或“否”。

这也解释了 Jev 的发布为何引发如此多的关注。在狭窄的决策任务上——比如许多 agent 赖以构建的 routing 和分类步骤——TypeSafe 的基准测试显示,Jev 比主流 LLM 最快快 200 倍,成本最低可降至 1/400。

对 LangChain 的我们来说,TypeSafe 的思路甚至有几分亲切。我们的使命是让 agent 有用且无处不在,我们的开源生态也随着模型格局的演变而不断演进,但在每一步,我们都会回到同样两个问题:如何让模型做出有用的决策,以及如何可靠地对这些决策采取行动?

**LangGraph 正是我们对这两个问题的回答。它的构建源于我们帮助数千家公司把 AI 投入生产所积累的经验,它让你在可靠、可观测的系统中,把模型驱动的决策与确定性代码结合起来。Jev 则为这些系统提供了一种更快、更便宜的决策方式。在本文中,我们将介绍如何用 Jev 和 LangGraph“造产品,不当神”。

用 Jev 做决策

Jev 从前沿 LLM 的能力捆绑中单独取出“判断力”这一项,把它变成了一种便宜到无需计量的原语。它就是 TypeSafe 所称的 system one model——或者用更常见的说法:“决策模型”。你给它状态和一组问题,它返回带概率的类型化答案。

TypeSafe 的文档列出了三种构建软件的方式。传统软件由显式逻辑构成,每个分支都由人手写、可审计,但也因此僵化。Agent 则摆向了另一个极端:一个模型在每一步包揽各种决策,控制流从代码移进了 prompt。AI 驱动的软件走的是中间路线:代码保留结构、负责精确计算,模型只出现在需要语义判断的分支上。

Jev 之所以够格成为生产系统的组件,靠的是下面几个特性:

  • 结构化:答案以带概率的类型化答案的形式返回,代码可以按可预测的方式根据结果进行分支
  • 可并行:可以同时针对同一状态提出许多问题
  • 快速:决策足够便宜,单次运行中可以做很多次
  • 自洽:system one 的设计目标就是在重复评估中返回稳定的答案。
“💡 Jev 的一致性,相对 LLM 的非确定性是一种可喜的改变。同一个问题多问几次 LLM,你可能得到不同的答案;而 Jev 的设计保证相同输入返回相同答案。在一项早期的 Jev-as-a-judge 实验中,100 次重复运行的评分几乎没有波动,远小于我们测试过的任何 LLM 评审。”

举个例子,下面这段视频能帮你直观感受 Jev 与 LLM 的工作方式有何不同。这里的任务是判断输入中是否包含各种类型的 PII:

真实的应用要做出大量决策,而每个决策又错综复杂地依赖于之前的选择。当决策变得如此便宜,挑战就变成了如何编排它们——这正是 LangGraph 的用武之地。

用 LangGraph 做编排

多年来,我们一直在帮助团队围绕 LLM 构建系统,几乎每个团队都会遇到同样两个问题:

  1. 上下文管理很难。模型要做出正确的决策,它的上下文窗口里需要“恰好是下一步所需的信息”。这些信息是模糊的,而且会随应用的运行而不断变化。
  2. 模型驱动的系统仍然要可靠。它们必须能在故障后恢复、支持人工介入,并让每一步都可观测。

现有的框架解决了其中一部分问题,但没有一个能在不限制构建方式的前提下把两者都解决。于是我们构建了 LangGraph。如今它的月下载量超过 6000 万次,许多正在用 AI 做事的《财富》50 强企业都在使用。

状态即上下文

一个 LangGraph 应用由三部分组成。节点(Node)是工作单元:可以是普通代码、一次模型调用、一次工具调用,或整个子图。状态(State)是节点读取和更新的信息。边(Edge)决定下一个运行哪个节点,要么沿固定路径,要么根据当前状态动态决定。

任何图本身也可以是更大图中的一个节点,因此经过测试的小组件可以组合成更大的系统。TypeSafe 的宣言对智能下了同样的赌注:小而清晰的原语,正是让复杂系统保持可信的关键。

图运行时,每一步的结果都会累积到状态中。这些状态随后成为后续每一步的上下文,同时也决定了接下来运行哪些节点。

你不再把领域知识塞进 prompt,而是把它编码进图的拓扑结构:要做哪些决策、按什么顺序做、每一步能看到什么状态。用 TypeSafe 的话说,软件因此能够“基于意图和常识进行分支”。判断力来自模型,但流程仍保留在你可以检查和测试的代码中。

可靠的运行时

正如 TypeSafe 宣言所论述的:只有当组件足够可靠,你才敢让它无人值守地运行;只有当你能检查、测试并约束它,你才会在它之上构建。LangGraph 在运行时层面做到了这一点:

  • 持久化执行(durable execution):模型驱动的步骤是非确定性的,同样的输入可能让模型走向不同的调用,使整个运行走上不同的路径。失败后从零重跑不只是慢——重跑未必会重复同一条路径。检查点机制会在每一步持久化状态,因此失败的运行可以带着已做出的决策从中断处继续
  • 人工介入(human in the loop):当某个步骤在系统采取行动前需要审核时,interrupt(中断)机制让你可以暂停、批准,然后从上次中断的地方继续
  • 可观测性:模型驱动的步骤不会每次都做同样的事,所以你需要 LangSmith 中的 trace 来看清做出了什么决策、为什么

这些保障并非 LLM 专属。Jev 接收的仍是非结构化的文本上下文,返回的仍是一个判断,因此它同样需要这些保证,而图会自动把它们赋予每个节点。

示例:证据开示中的文档审阅

在诉讼中,公司必须逐页审阅之后,才能向对方提交(交出)文件,而单个案件的材料可能多达数十万页。这些审阅大部分是同一种有边界的判断被一遍又一遍地重复,这正是 Jev 的天然适用场景。

对每一页,Jev 在一次请求中回答三个问题,每个答案都映射到图中的一条 route:

  1. 这一页是否与调取请求相关?若不相关,就搁置一旁。
  2. 它是否包含个人信息?若是,就由 LLM 对其中的 PII 做脱敏处理。
  3. 它是否可能涉及法律特权?若是,就进入 attorney_review,让图暂停下来,等待人工介入。

剩下没有问题的页面就可以交付了。下面是这个流程的快速演示(实际运行中,各页是并行处理的):

所有分类都由 Jev 处理,只有当某一页需要更多处理时,图才会升级:交给 LLM 做脱敏,或交给律师做特权判定。

我们用同一张图分别测试了由 Jev 负责分类和由 Sonnet 充当评审两种方案,在多轮试验中,Jev 在分类这一步快了 5–6 倍。两次运行都在 LangSmith 中留有 trace,你可以打开任意一页,查看它走了哪条 route,以及背后的概率。LangSmith 还为 Jev 这类决策模型提供了专门视图,展示每个决策的输入和经过校准的输出:

智能的大拆解

过去三年,大多数 agent 都把所有事情交给同一个前沿 LLM 来处理。Jaya Gupta 把接下来会发生的事称为“智能的大拆解”(the Great Unbundling of Intelligence):这些能力将被拆开,每一项都交给能胜任它的最便宜的模型。Jev 拆出的正是判断力——它返回结构化的决策,而不是生成的文本。而一旦各部分被拆开,就需要有东西把它们重新缝合起来:为每一步做 routing,并决定何时升级。这就是运行时的职责。

浏览器自动化展示了这在实践中是什么样子。浏览器 agent 读取页面并决定下一步做什么:点按钮、填字段、滚动。这听起来很开放,但在任一时刻,页面上可交互的元素是有限的,所以下一个动作其实就是从一份列表中做选择。

Browserbase 围绕这一思路重构了 Stagehand 的 act()。Stagehand 标记页面上的可交互元素,Jev 选出动作类型和最佳候选元素,凡低于 0.7 置信度阈值的情况则回退到 LLM。在早期测试中,act() 的中位延迟从 1.97 秒降到 0.46 秒,快了约 4.3 倍。

对大多数用例来说,Jev 并不能完全取代 LLM。它处理自己有把握的有边界选择,把其余一切都交给 LLM。这正是 Gupta 所描述的转变:从“默认前沿、之后再优化”转向“默认廉价、例外才前沿”。我们预计会看到更多这种模式:凡动作空间受限之处,都由决策模型快速、廉价地做出判断,LLM 则留作开放式推理之用,以及处理小模型拿不准的情形。

开发者们已经在朝这个方向走。本周有位开发者告诉我们:“我基本上正在把我们现有的每一个 agent 都改造成由 Jev 驱动的工作流。”

上手指南

  • 想了解 LangGraph 运行时的工作原理,请阅读《3 years of graph engineering with LangGraph》
  • 想了解 Jev 如何融入 agent harness——包括 model routing 和 auto mode 分类器——请阅读《Building a harness with Jev》
  • 用 LangSmith 监控和评估你的 agent

致谢

本文由 Sydney Runkle 和 Hunter Lovell 撰写。

感谢 Kevin Frank、Harrison Chase、Eugene Yurtsev 和 Nathan Drezner 的审阅与建议。