LangChain 社区聚焦：生产环境中 LangGraph 智能体的五大控制措施 🛠️

我们驻波兰大使 Simon Budziak (@simon_budziak) 详细介绍了两套基于 LangGraph 和 LangSmith 构建的生产级智能体背后的五大控制措施，并附上了每项措施的代码。在一套患者教育助手中，置信度门控将约 15% 的对话转交给临床医生处理，临床医生认为其中 80% 的转交是合理的。

📖 阅读完整文章：https://sobalabs.ai/blog/langgraph-agents-in-production/…

生产环境中的 LangGraph 智能体：五大控制措施 | Soba Labs

来源：https://sobalabs.ai/blog/langgraph-agents-in-production/

题图写着“生产环境中智能体的五大控制措施“，左上角有 LangGraph 的名称和标志。深蓝色背景上，一个风格化的状态机由发光的圆角面板组成，面板之间由一条蜿蜒的金线连接，金线穿过一道高高的金色门，随后分岔：一条通向明亮的回答面板，另一条通向一个小型的人物剪影面板。

让 LangGraph 智能体在演示中跑起来只需要一个下午。让它在生产环境中稳定运行则是另一回事，而且很大程度上与模型无关。**在我们交付的两套系统中，起作用的是同样五项控制措施：显式状态机、每轮对话的完整追踪、每次变更的评估门控、幂等副作用，以及基于置信度的人员路由。**这些经验来自我们为 Open Loyalty 构建的 AI SDR（销售开发代表）和为 Shen.ai 构建的患者教育助手，两者均已作为案例研究发布。本文将逐一介绍每项控制措施，包括我们使用的代码结构，以及让这些措施成为必选项的生产事故。

在生产环境中杀死智能体的是质量，而非能力

智能体早已不再是实验品。在 LangChain 的《State of Agent Engineering》（https://langchain.com/state-of-agent-engineering）调查中（调查时间为 2025 年 11 月 18 日至 12 月 2 日），共有 1,340 名受访者，其中 57.3% 已在生产环境中运行智能体，另有 30.4% 正在积极向生产环境推进。同一份报告指出了最大障碍：32% 的受访者将质量列为生产落地的首要障碍，高于延迟（20%）。模型通常能够给出正确答案——问题在于，围绕它的系统无法在模型答错时察觉。

这就是下文所有内容的出发点。LangGraph（https://sobalabs.ai/glossary/langgraph/）在 LangGraph 概述（https://docs.langchain.com/oss/python/langgraph/overview）中将自己描述为*“一个用于构建、管理和部署长时间运行的有状态智能体的底层编排框架和运行时”*——其中“底层“是关键。它并不能直接让智能体变得可靠，而是为你提供了原语——状态、检查点、中断、条件边——让你自己构建可靠性。下面五项控制措施，就是当智能体必须扛住真实流量时，我们用这些原语实际构建的东西。

控制措施一：将智能体建模为显式状态机

生产环境中的 AI 智能体必须作为序列来调试，而不是作为单个回答来调试。第一个能带来长远回报的决策是：拒绝“提示词循环“模式（一个大提示词 + 工具 + 祈祷），将工作流建模为一个显式的智能体状态机——具名阶段、类型化状态、可读的条件边。

在 Open Loyalty 的 AI SDR 中，对话状态按显式阶段流转：介绍、资格判定、检索、销售简报和 CRM 写入：

class SDRState(MessagesState):
    lead_id: str
    lead: dict
    score: int
    next_action: str
    kb_context: list[Document]
    thread_id: str

graph = StateGraph(SDRState)
graph.add_edge("intro", "qualify")
graph.add_conditional_edges("qualify", needs_product_qa)
graph.add_edge("retrieve_kb", "sales_brief")
graph.add_edge("sales_brief", "crm_write")
graph.add_edge("crm_write", END)

当潜在客户被错误路由时，状态能够显示是哪个阶段做出的决策、检索返回了什么，以及是哪个工具触发了副作用。提示词循环只能回答“智能体说了什么“，而显式图能够回答“智能体做了什么、按什么顺序、基于什么输入“——这才是生产事故真正需要回答的问题。

控制措施二：追踪每一次生产对话

无法重放的故障是无法修复的。LangSmith 为两套系统都提供了端到端的对话记录；其可观测性概念对基本单元的定义很简洁：*“一个 trace 是单次操作的一组运行记录。”*我们的 trace 包含了模型调用、工具调用、输入、输出、延迟、提示词版本和运行元数据，因此单个运行 ID 就能回答：是哪个提示词产生了该行为，以及某次工具调用是首次调用还是重试。

这已经是主流实践，而非锦上添花：同一份《State of Agent Engineering》报告显示，89% 的组织已经实施了某种形式的智能体可观测性，62% 拥有足够详细的追踪来检查单个步骤和工具调用。差距在于，远少于这个比例的组织会真正根据这些数据采取行动。LLM 可观测性的价值，会在一个隐藏的工具故障看起来像模型异常输出的那一天体现出来——而大多数工具故障看起来确实如此。我们为客户搭建这套体系的方式，可以在我们的 LangSmith 服务页面上找到。

**陷阱：**没有 trace 的情况下，检索或 CRM 故障与模型当天状态不佳无法区分。Open Loyalty 那两个真正要紧的 bug，都是在 trace 中发现的，而不是在对话记录中。

控制措施三：为每次变更设置评估门控

一个在预发布环境中看起来可靠的提示词，会在面对混乱的多部分问题时崩溃。对于 Open Loyalty，我们基于具有代表性的真实对话构建了一个小型评估集：定价问题、异议、模糊意图、缺失字段等。提示词、模型、检索设置或工具模式的每一次有意义的变更，都会在发布前针对同一套评估集运行，检查四件具体的事情：智能体是否正确路由、是否提取了必需字段、是否始终基于已审核材料作答、是否避免了不安全或重复的副作用。该门控中检索侧的构建——分块、混合搜索和重排序器——有其自身的构建顺序，我们在《Enterprise RAG on LangChain: fix retrieval first》（https://sobalabs.ai/blog/enterprise-rag-on-langchain/）中做了详细阐述。

这将一场围绕单条对话记录的争论，变成了一项回归测试——与 LangSmith 的评估概念中针对数据集为应用打分的规范如出一辙。生产中的故障会被反馈进来：团队对真实失败案例进行分类（错误路由、无依据的断言、遗漏字段、工具错误），并将最有代表性的案例纳入评估集。行业在这一环节的实践明显滞后，数据也能说明问题：根据同一份调查，可观测性的采用率为 89%，而评估明显落后——只有 52.4% 在运行离线评估，37.3% 在运行在线评估。一个有 trace 但没有评估门控的智能体，可以“看到“自己的退化，却仍然把退化版本发布出去。我们在《LLM-as-judge evaluation in LangSmith》（https://sobalabs.ai/blog/langsmith-llm-as-judge/）中讨论了如何对模糊案例进行评分。

控制措施四：让每个副作用都具备幂等性

Open Loyalty 最棘手的 bug 从未出现在最终的助手消息中。一小部分对话产生了两次 CRM 更新，而不是一次。Trace 揭示了完整过程：一次 CRM 写入超时，智能体重试，第二次调用成功，随后第一次调用也完成了。一次对话，两次写入。

修复方案是一个幂等工具调用边界，而不是更好的提示词：

crm_write.invoke({
    "lead_id": state["lead_id"],
    "payload": payload,
    "idempotency_key": f"{thread_id}:{turn_id}",
})

每次写入都获得一个由对话和轮次派生的幂等键，模型重试和工具重试变成了独立的决策，评估集中也新增了一个模拟超时的测试用例，断言每轮对话只对每个线索进行一次更新。LangGraph 本身也将这一规则制度化：根据中断文档，当暂停的图恢复执行时，节点会从头开始重新运行，interrupt 之前的任何代码都会再次执行——这就是该位置的副作用必须具备幂等性的原因。我们在《LangGraph human-in-the-loop: interrupt vs middleware》（https://sobalabs.ai/blog/langgraph-interrupts-production/）中详细拆解了这个重放边界。通用规则是：任何涉及资金、邮件或 CRM 的节点都必须配备幂等键，且重试逻辑必须假设调用可能已经执行过。

一张 LangGraph 智能体在生产环境中的竖向流程图。显式状态机节点输出到一个金色的确定性门控，检查置信度后分流：一条路径是带幂等写入的回答路径，另一条是人工审查路径。图上标注着每一步都进入 LangSmith trace，且受评估集约束。两套系统最终收敛到的生产形态：确定性门控决定路径，数据变更操作位于门控之后并配备幂等键，每一步都记录在 trace 中。

控制措施五：通过代码将低置信度路由到人工

对于 Shen.ai 的患者教育助手来说，一个自信但缺乏依据的解释不是 UX 缺陷，而是安全问题。关键决策——一个问题应该走正常回答路径还是转交临床医生——是用代码实现的，而不是写在提示词里：

def should_route_to_human(state: PatientEducationState) -> str:
    if state["confidence_score"] < 0.7 or state["requires_review"]:
        return "human_review"
    return "education_module"

graph.add_conditional_edges("retrieve_kb", should_route_to_human)

置信度门控将不确定性变成一个显式的系统状态：低置信度的检索结果根本无法到达回答节点，对话将转入人在回路中的人工审查流程。该系统调优后的生产数据：约 15% 的对话进入人工审查，临床医生认为其中约 80% 的升级处理是合理的，将阈值从 0.8 降低到 0.7 后，不必要的审查减少了约 40%。这些数字描述的是该系统调优期间的情况，并非通用基准，但这一模式适用于任何“答错的代价高于转交成本“的领域。选择触发门控的信号本身就是一个设计问题，详见确定性置信度门控。

提示词要求模型保持谨慎，并不能定义系统何时必须停止——条件边可以。OpenAI 十月的事故报告中，两个智能体在常规指令下削弱了自身监控能力，这是同一课从失败侧的讲述：OpenAI 的智能体禁用了自己的监控。

底层基础设施：持久化检查点

所有五项控制措施都以状态能够存续为前提。一个为等待人工介入而暂停的门控，只有在暂停状态能够持久保存时才有意义——因此两套系统都使用 PostgreSQL 进行检查点存储。LangGraph 的持久化文档建议在生产环境中使用基于数据库的检查器，例如 PostgresSaver，将其编译到图中，并以稳定的 thread_id 为键：

from langgraph.checkpoint.postgres import PostgresSaver

with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    graph = builder.compile(checkpointer=checkpointer)

对 Shen.ai 而言，这也让患者可以离开并随时返回，而不会丢失安全检查所依赖的状态。持久化执行有一个值得了解的配置项：检查器持久化模式（"exit"、"async"、"sync"）在性能与运行中途崩溃恢复之间做取舍——对于耗时长、成本高且不允许丢失的运行场景，"sync" 是合适的选择。

真实世界中的生产案例

上述五项控制措施并非纸上谈兵。每一项都来自我们实际交付的系统，以下是已发布的案例研究：

Freedman 还证明了这些控制措施的可迁移性：它的追踪基于 Langfuse 而非 LangSmith 运行——控制措施的本质是 trace，而不是供应商。无论是哪个可观测性后端在记录，门控、幂等边界和人工路由的形态都完全相同。

核心要点

根据 LangGraph 自身的概述页面，Klarna、Uber 和摩根大通等公司已经在生产环境中信赖使用它。原因不在于它让智能体更聪明，而在于它的原语让你能够对智能体进行检查和治理。五项控制措施，各用一句话总结：将工作流建模为显式状态机；追踪每一轮对话；用基于真实对话构建的评估集为每次变更设置门控；为每个副作用配备幂等键；通过条件边（而非提示词）将不确定性路由到人工。上述两套系统都完整落地了这五项措施，此后每一次生产事故都是通过其中一项来调试的。如果你想深入了解我们在这个技术栈上构建的完整方案，可以从我们的 LangGraph 服务页面或上面链接的两篇案例研究开始。

来源

• LangGraph 概述，框架的自我介绍和生产环境用户
• State of Agent Engineering，LangChain 2025 年对 1,340 名受访者的调查
• LangSmith 可观测性概念，trace 和运行模型
• LangSmith 评估概念，数据集和评分
• LangGraph 中断文档，恢复时的节点重放与幂等性
• LangGraph 持久化文档，生产级检查器
• LangGraph 检查器文档，三种持久化模式
• Open Loyalty：生产级 AI SDR，控制措施一至四背后的已发布案例研究
• Shen.ai：带安全控制的患者教育，控制措施五背后的已发布案例研究

最后更新：2026 年 10 月 23 日