LangGraph 工作流：从基础调用到稳定运行

关注

原创最新推荐文章于 2026-09-24 17:39:12 发布 365 阅读 AI 写同款· GEO 优化 ›

LangChain与LangGraph技术解析：从框架到智能体工作流编排大语言模型应用开发框架是构建AI应用的核心基础设施，它通过模块化设计连接模型、数据和工具，简化开发流程。其底层原理在于将复杂的AI能力封装为可复用的组件，通过链式调用实现任务自动化。这一技术显著降低了AI应用开发门槛，使开发者能够快速构建检索增强生成、智能对话等场景的应用。当应用逻辑涉及多步骤决策、循环执行和状态管理时，基于图的工作流编排技术成为关键解决方案。LangGraph作为LangChain生态系统中的核心库，专门用于构建有状态的复杂智能体工作流，支持条件分支和循环控制，适用于自动化决策、业务流程编阅读详情

聊《LangGraph 工作流：从基础调用到稳定运行》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

本文概述文章目标、核心观点和实践价值。

前阵子线上出了一个让人头疼的问题：我们的客服 Agent 在处理退款请求时，偶尔会把“部分退款”执行成“全额退款”，而且没有触发任何预警。排查日志发现，Agent 内部状态流转是线性的，一旦 LLM 判定需要退款，它就直接调用了 refund_tool，中间没有任何校验环节。

这就是典型的“脚本式 Agent”陷阱——代码写起来快，跑起来像脱缰野马。为了解决这个问题，我们重构了底层逻辑，引入了 LangGraph。今天不聊那些花哨的概念，就聊聊怎么把这个图结构真正变成生产环境里可控、可观测、可回滚的系统。

为什么需要图工作流

文章插图 1

很多开发者刚接触 LangChain 时，喜欢用 Chain 串联模块。Chain 适合简单的顺序执行，比如“检索文档 -> 组装 Prompt -> 调用 LLM”。但在复杂的业务场景下，Chain 显得力不从心：

1. 循环依赖：如果 LLM 生成的答案需要自我反思（Self-Correction），Chain 很难表达这种迭代过程。
2. 条件分支复杂：根据用户意图不同，后续调用不同的工具集，用 Chain 写一堆 if-else 会让逻辑变得难以维护。
3. 状态丢失：Chain 往往是无状态的，每一步的输出直接作为下一步的输入，难以保存整个对话的历史上下文快照。

LangGraph 的核心价值在于它将 Agent 的工作流建模为有向图（Directed Graph）。节点（Node）代表执行单元，边（Edge）代表控制流。这种抽象让我们能像画流程图一样设计 Agent，更重要的是，它支持持久化状态和人工干预。

State 与 Node：定义系统的“记忆”

文章插图 2

在 LangGraph 中，State 是整个系统的灵魂。不同于普通函数传参，State 是一个共享的字典，所有 Node 都可以读写它。

我们在项目中定义了一个 AgentState，它不仅包含用户输入和当前回复，还记录了工具调用的历史、置信度分数以及是否触发了人工审核标志。

from typing import TypedDict, Annotated
import operator

class AgentState(TypedDict):
    messages: Annotated[list, add_messages] # 消息列表，自动合并
    tool_calls: list # 待执行的工具调用
    is_human_review_needed: bool # 是否需要人工介入
    confidence_score: float # LLM 输出的置信度
    final_decision: str # 最终决策结果

def llm_node(state: AgentState) -> AgentState:
    # 模拟 LLM 推理
    response = call_llm(state['messages'])

    # 简单策略：如果涉及金钱操作且置信度低，标记需要人工审核
    needs_review = False
    if "refund" in response.content.lower() and response.confidence < 0.8:
        needs_review = True

    return {
        "messages": [response],
        "is_human_review_needed": needs_review,
        "confidence_score": response.confidence,
        "tool_calls": response.tool_calls
    }

这里有一个关键的工程取舍：State 的序列化与持久化。在生产环境中，State 必须能被序列化（如 JSON），以便存入 Redis 或数据库。这样当服务重启或迁移时，Agent 可以从断点恢复，而不是从头开始。这也是实现“可回滚”的基础。

优快云资料领取方式

Edge 与条件分支：掌控流量走向

有了 State，接下来就是定义 Edge。LangGraph 提供了两种边：

1. Conditional Edges：根据当前 State 决定下一步去哪个 Node。
2. Normal Edges：确定性地跳转到下一个 Node。

在我们的退款场景中，我们使用条件边来路由流程：

def route_after_llm(state: AgentState) -> str:
    if state['is_human_review_needed']:
        return "human_review_node"
    elif state['tool_calls']:
        return "tool_execution_node"
    else:
        return "final_response_node"

workflow.add_conditional_edges(
    "llm_node",
    route_after_llm,
    {
        "human_review_node": "human_review_node",
        "tool_execution_node": "tool_execution_node",
        "final_response_node": "end"
    }
)

这种写法比硬编码 if-else 清晰得多。如果将来我们要增加一个新的审核维度（比如风控拦截），只需要修改 route_after_llm 的判断逻辑，而不需要改动其他 Node 的内部实现。这就是关注点分离带来的工程优势。

人工审批节点：给 AI 装上“刹车”

回到最初的问题：如何防止错误的全额退款？答案就是引入人机协同（Human-in-the-loop）机制。

在 LangGraph 中，我们可以暂停图的执行，等待外部信号（如人类确认）后才继续。这对于高风险操作至关重要。

def human_review_node(state: AgentState) -> AgentState:
    # 这里通常会阻塞，直到收到人工确认
    # 实际生产中，通过 API 将请求推送到审批后台
    approval = get_human_approval()

    if not approval.approved:
        # 拒绝则生成拒绝理由，并结束或重新引导
        return {
            "messages": [AIMessage(content=f"Request denied: {approval.reason}")],
            "final_decision": "denied"
        }

    # 批准则继续执行工具
    return {
        "is_human_review_needed": False,
        "approved_by_human": True
    }

这个节点不仅仅是个开关，它还是监控的关键入口。我们记录了每次人工干预的时间、原因和操作者。这些数据事后可以反哺模型，优化置信度阈值，减少未来的误判。