用 Jev 和 LangGraph 构建生产级 Agent：LangChain 官方教程翻译
用 Jev 和 LangGraph 构建生产级 Agent：LangChain 官方教程翻译
"做产品，不是造神"——这是这篇教程的核心命题。
昨天刚翻译了 LangChain 的 Jev-as-a-Judge 评测文章，今天这篇是它的续作：《Building Production Agents with Jev and LangGraph》（用 Jev 和 LangGraph 构建生产级 Agent），9 月 25 日发布，作者 Sydney Runkle 和 Hunter Lovell。
上一篇讲"Jev 能不能当评估器"，这篇讲"Jev 怎么在生产系统里用"。核心思想来自 TypeSafe 的宣言："prod, not god"（做产品，不是造神）——别把前沿 LLM 当万能神，把它的"判断力"拆出来，交给便宜 400 倍的专用模型。文中有一个真实示例：文档审查流程用 Jev 做分类，比 Claude Sonnet 快 5-6 倍；浏览器自动化里 Jev 替代部分 LLM 判断，延迟从 1.97 秒降到 0.46 秒。
老规矩，忠实翻译全文，文末附我的解读。
本文提纲
- 核心思想：prod, not god
- Jev 作为生产系统组件的四个属性
- LangGraph 编排：解决两个老问题
- 状态即上下文：Nodes / State / Edges
- 可靠运行时：持久执行、人在环、可观测
- 真实示例：诉讼文档审查
- 智能的大拆分（The Great Unbundling of Intelligence）
- 翻译后的几点解读
核心思想：prod, not god
上周，TypeSafe AI 发布了 Jev——一种新类型的模型。和传统 LLM 不同，Jev 不生成文本。它做出你的代码可以直接执行的决策，服务于 TypeSafe 所说的 AI 驱动的软件（AI-powered software）——"代码拥有工作流，AI 处理窄的、结构化的决策"。TypeSafe 把它的哲学总结为**"做产品，不是造神"（prod, not god）**。
随着前沿 LLM 越来越强，我们开始把它们当神用——任何有模糊输入的任务都找它：散文生成、文档抽取、搜索、排序、研究、分类……
这就是 Jev 发布引起这么大关注的原因。在窄决策任务上——比如很多 Agent 构建所依赖的路由和分类步骤——TypeSafe 的基准显示 Jev 比领先 LLM 快 200 倍、便宜 400 倍。
TypeSafe 的方法让我们 LangChain 感到有些"怀旧"。我们的使命是让 Agent 有用且无处不在，我们的开源生态随着模型格局一起演进，但在每一步，我们都在回答同一个问题：如何构建既可靠又可组合的模型驱动系统？ LangGraph 就是我们对这两个问题的答案。
我们用它帮助数千家公司把 AI 投入生产，它让你把模型驱动的决策和确定性代码结合起来，构建可靠且可观测的系统。Jev 给这些系统提供了一种更快、更便宜的决策方式。
Jev 作为生产系统组件的四个属性
Jev 从"前沿 LLM 大礼包"里拿出了一个能力——判断（judgment）——把它变成了一个便宜到不值得计量的原语。它就是你给它状态和一组问题，它返回带概率的类型化答案。
几个属性让 Jev 有资格成为生产系统的组件：
| 属性 | 说明 |
|---|---|
| 结构化（Structured） | 答案以类型化答案 + 概率返回，代码可以可预测地根据结果分支 |
| 并行（Parallel） | 可以针对同一个状态同时问多个问题 |
| 快（Fast） | 决策便宜到可以在单次运行中做很多个 |
| 自一致（Self consistent） | System One 设计为在重复评估中返回稳定答案 |
💡 Jev 的一致性是对 LLM 非确定性的一个受欢迎的改变。同一个问题问 LLM 多次，可能得到不同答案；Jev 设计为对同一输入返回同一个答案。在早期的 Jev-as-a-judge 实验中，它的分数在 100 次重复运行中几乎不动，远低于我们测试过的任何 LLM judge。
真实应用会做大量决策，每个决策都微妙地依赖于之前的决策。一旦决策便宜到这个程度，挑战就变成了编排（orchestration）——这正是 LangGraph 的用武之地。
LangGraph 编排：解决两个老问题
我们帮团队构建 LLM 系统好几年了，几乎每个团队都会遇到同样的两个问题：
- 管理上下文很难。 模型要做对决策，它的上下文窗口需要"下一步正好需要的信息"。这个信息是模糊的，而且随着应用运行不断变化。
- 模型驱动的系统仍然需要可靠。 它们必须扛住失败、支持人工介入、让每一步都可观测。
现有框架解决了部分问题，但没有一个能在不限制构建方式的前提下同时解决两者。所以我们构建了 LangGraph。它现在每月下载量超过 6000 万次，被许多 Fortune 50 公司用于 AI 构建。
状态即上下文：Nodes / State / Edges
一个 LangGraph 应用由三块组成：
- 节点（Nodes）：工作单元——普通代码、模型调用、工具调用，或整个子图。
- 状态（State）：节点读取和更新的信息。
- 边（Edges）：决定下一个运行哪个节点，沿固定路径或根据当前状态动态决定。
任何图也可以成为更大图里的一个节点，所以小的、经过测试的组件可以组合成更大的系统。TypeSafe 的宣言也押注同样的智能观：小的、可读的原语，是复杂系统保持可信的原因。
图运行时，每一步的结果累积到状态里。这个状态成为之后每一步的上下文，也决定接下来运行哪些节点。
关键的设计理念：与其把领域知识塞进 prompt，不如把它编码进图的拓扑（topology）——哪些决策被做出、以什么顺序、每个决策看到什么状态。这就是软件如何"根据意图和常识分支"。判断来自模型，但流程由代码决定。
可靠运行时：持久执行、人在环、可观测
正如 TypeSafe 宣言所说：只有当一个组件可靠了，你才让它无人值守地运行；只有当你能检查、测试、约束它时，你才在它之上构建。 LangGraph 在运行时里处理这些：
- 持久执行（Durable execution）：模型驱动的步骤是非确定性的——同一个输入可能让模型做出不同调用、让运行走不同路径。失败后从头重启比慢更糟，所以 LangGraph 持久化每一步的状态。
- 人在环（Human in the loop）：当一步需要审查才能继续时，中断（interrupts）让你暂停、批准、然后从停下的地方继续。
- 可观测性（Observability）：模型驱动的步骤不是每次都做同样的事，所以你需要 LangSmith 里的 trace 来看清做了什么决策、为什么。
这些都不是 LLM 特有的。Jev 仍然接收非结构化文本上下文、返回判断，所以它需要同样的保证——而图自动把这些保证给到每个节点。
真实示例：诉讼文档审查
在诉讼（discovery）中，公司必须在交出（producing）文件前审查每一页，一个案子可能多达几十万页。大部分审查是重复的——而这是 Jev 的完美场景。
对每一页，Jev 在一个请求里回答三个问题，每个答案映射到图里的一条路由：
- 这页对请求是否相关（responsive）？ 如果不是，放到一边。
- 它是否包含个人信息？ 如果是，LLM 负责脱敏 PII。
- 它是否可能受特权保护（privileged）？ 如果是，进入
attorney_review，暂停图等待人在环介入。
剩下的都准备好交出。Jev 处理所有分类，图只在页面需要更多时才升级：交给 LLM 做脱敏，或交给律师做特权判断。
结果：用 Jev 处理分类和用 Sonnet 当 judge 跑同一个图，Jev 在分类步骤上快 5-6 倍。两次运行都 trace 在 LangSmith 里，可以打开任何一页看它走了哪条路由、背后的概率是什么。
智能的大拆分（The Great Unbundling of Intelligence）
过去三年，大多数 Agent 把一切都路由给一个前沿 LLM。Jaya Gupta 把接下来要发生的事称为**"智能的大拆分"**：那些能力被拆开，每个交给能处理它的最便宜模型。Jev 抽出的是判断——返回结构化答案，而不是生成文本。
浏览器自动化展示了这在实践中长什么样。浏览器 Agent 读页面、决定下一步做什么：点按钮、填字段、滚动。听起来很开放，但在任何给定时刻，选择是有限的。Browserbase 重建了 Stagehand 的 act()：
- Stagehand 标记页面上的交互元素
- Jev 选择动作类型和最佳候选元素
- 任何置信度低于 0.7 的，回退给 LLM
结果：act() 延迟从 1.97 秒降到 0.46 秒，约快 4.3 倍。
Jev 在大多数用例中不会完全取代 LLM。它处理它有信心的有界选择，把其他一切交给 LLM。这就是 Gupta 描述的转变——从"默认前沿模型"到"默认最便宜的足够好的模型"。
开发者已经在这么做了。正如一位开发者本周告诉我们："我基本上正在把我们现在的每一个 Agent 都转成 Jev 驱动的工作流。"
翻译后的几点解读
这是"决策模型 + 编排框架"的标准组合拳。 这篇教程的战略意义很清楚：TypeSafe 提供便宜的决策原语（Jev），LangChain 提供编排层（LangGraph），两者拼成一套"用代码控制流程、用模型做判断"的生产架构。Jev 解决"决策便宜"，LangGraph 解决"决策多了怎么编排"——正好互补。
"把领域知识编码进图的拓扑，而不是塞进 prompt"是全文最值钱的一句话。 这和我们一直讲的 harness 工程同源：判断交给模型，但流程、约束、决策顺序由代码决定。Jev 的"结构化+并行+快+自一致"四个属性，本质都是为了让代码能可靠地围绕它构建逻辑。
Browserbase 的 0.7 置信度回退是教科书级模式。 不是"Jev 或 LLM"二选一，而是"Jev 处理有把握的，LLM 兜底没把握的"。这个置信度阈值架构会在越来越多系统里出现——它是成本和质量之间的旋钮。
数字要看清前提。 快 5-6 倍是"分类步骤"、快 4.3 倍是"act() 的特定实现"——都是窄任务上的收益，不是端到端 Agent 的全面提速。但趋势明确：判断类子任务正在从"LLM 全家桶"里被拆出来，交给专门的决策模型。
如果你想动手：先看 3 years of graph engineering with LangGraph 了解 LangGraph 运行时，再看 Building a harness with Jev 了解 Jev 怎么融入 Agent harness（模型路由、auto mode 分类器），最后用 LangSmith 监控和评估你的 Agent。
参考链接
- 原文：Building Production Agents with Jev and LangGraph（LangChain 博客） - Sydney Runkle & Hunter Lovell，2026-09-25
- Building a Harness with Jev（LangChain） - Jev 融入 Agent harness 的配套教程
- 3 years of graph engineering with LangGraph - LangGraph 运行时深度解读
- TypeSafe AI：Introducing System One Models and Jev - Jev 官方发布博客
- 我的 Jev-as-a-Judge 翻译 - LangChain 前一篇 Jev 评测实验翻译
- 我的 System One 拆解 - JEV、kev、laya 架构对比
你会把哪些判断类子任务从 LLM 里拆出来交给 Jev？评论区聊聊，觉得有用点个赞让更多人看到。
作者: itech001 来源: 公众号：AI人工智能时代(the-ai-era) 网站: https://www.theaiera.top/ 关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top
本文首发于 AI人工智能时代，转载请注明出处。
