当前位置：首页 > news >正文

LangGraph 工作流：简历项目怎么讲清楚

news 2026/6/29 3:06:05

聊《LangGraph 工作流：简历项目怎么讲清楚》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

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

最近面试了几个做 Agent 应用的后端同学，发现大家有个共同的痛点：简历上写着“基于 LangChain/LangGraph 构建了智能客服”，但被问到“如何保证流程可控”、“怎么处理异常分支”或者“状态怎么管理”时，往往支支吾吾，最后只能聊两句 LLM 的 Prompt 调优。

这其实是因为大多数人的项目还停留在“脚本阶段”——也就是把 LLM 当成一个黑盒函数，输入问题，输出答案。但在企业级应用里，Agent 不是聊天机器人，它是一个需要严格状态管理、错误重试和人工介入的系统。

今天我不讲那些虚头巴脑的理论，直接结合我最近重构的一个金融合规审核 Agent项目，聊聊怎么把 LangGraph 从“玩具代码”变成“可展示的工程资产”。这也是我在面试中用来证明“我能搞定复杂业务逻辑”的核心案例。

为什么你需要图工作流？

在传统脚本里，我们习惯用if-else或者简单的链式调用（Sequential Chain）来处理任务。比如：
1. 用户提问 -> 2. LLM 生成回答 -> 3. 结束。

这在简单场景没问题，但一旦涉及多步推理、工具调用、或者需要人工审批，这种线性结构就崩了。你会遇到以下问题：

状态丢失：第二步依赖第一步的结果，如果中间断了，很难恢复。
循环死锁：LLM 可能反复调用同一个工具，导致无限循环。
难以调试：出了 Bug，你很难知道是在哪个节点出的错，因为整个流程是一坨代码。

LangGraph 的核心价值在于它引入了图（Graph）的概念。你把每个处理单元看作一个节点（Node），它们之间的流转关系看作边（Edge）。更重要的是，它有一个全局的State（状态）对象，所有节点共享并修改这个状态。

在简历里，你可以这样描述：“设计并实现了基于 LangGraph 的状态机工作流，解决了传统链式调用无法处理多轮对话回溯和异常重试的问题。” 这句话比“用了 LangChain”有力得多。

State 与 Node：定义你的业务契约

很多初学者在写 LangGraph 时，喜欢直接用字典当状态，或者干脆不用状态机，直接把数据在函数间传参。这是大忌。

在我的合规审核项目中，我定义了一个 TypedDict 作为 State。这不仅是为了类型检查，更是为了向面试官展示你有“契约精神”。

from typing import TypedDict, Annotated import operator from langgraph.graph.message import add_messages class ReviewState(TypedDict): # 用户原始问题 question: str # LLM 生成的初步分析 llm_analysis: str # 工具调用记录（列表累加） tool_calls: Annotated[list, operator.add] # 是否需要人工介入的标志位 need_human_review: bool # 最终审核结论 final_verdict: str # 消息历史，用于多轮对话上下文 messages: Annotated[list, add_messages]

注意看Annotated[list, operator.add]和add_messages。这是 LangGraph 提供的自定义 reducer（归约器）。如果你只是简单的赋值，后面的节点会覆盖前面的结果；而使用 reducer，你可以实现“追加”语义，这对于日志记录和消息累积至关重要。

在面试中，如果有人问你“为什么 State 设计这么复杂？”，你可以回答：“因为在金融场景下，我们需要审计追踪。每一个工具调用的参数和结果都必须保留在 State 中，以便后续溯源，而不是仅仅保留最终结果。”

Edge 与条件分支：让 Agent “思考”后再行动

有了 State 和 Node，接下来就是连接它们的 Edge。最简单的 Edge 是条件边（Conditional Edge），它根据当前 State 决定下一个节点是谁。

在我的项目里，核心逻辑是一个“路由节点”：

def should_review(state: ReviewState) -> str: # 这里可以嵌入一个简单的 LLM 判断，或者规则引擎 # 如果置信度低，或者涉及敏感操作，标记为需要人工 if state['need_human_review']: return "human_approval_node" return "auto_approve_node" workflow = StateGraph(ReviewState) # 添加节点 workflow.add_node("analyze", analyze_step) workflow.add_node("human_approval_node", human_approval_step) workflow.add_node("auto_approve_node", auto_approve_step) # 设置入口和条件边 workflow.set_entry_point("analyze") workflow.add_conditional_edges( "analyze", should_review, { "human_approval_node": "human_approval_node", "auto_approve_node": "auto_approve_node" } )

这里的亮点在于“动态决策”。普通的 Agent 是线性的，而基于 Graph 的 Agent 可以根据中间结果改变路径。在简历上，强调你使用了条件边（Conditional Edges）来实现动态路由，能体现你对业务灵活性的理解。

人工审批节点：工程化的关键差异点

这是区分“Demo 代码”和“生产级应用”的分水岭。

纯自动化的 Agent 在遇到不确定情况时，要么报错，要么瞎编。而在真实业务中，比如银行转账、合同签署，我们必须引入Human-in-the-loop（人在回路）机制。

在 LangGraph 中，这通常意味着一个特殊的节点，它会暂停执行，等待外部信号唤醒。

def human_approval_step(state: ReviewState): print(f"等待人工审批... 待决事项: {state['question']}") # 在实际工程中，这里会保存 State 到数据库，生成一个 Task ID # 然后等待 API 接收到 'approve' 或 'reject' 信号 # 模拟人工决策 decision = input("请输入审批结果 (approve/reject): ") if decision == "approve": state['final_verdict'] = "Approved by Human" else: state['final_verdict'] = "Rejected by Human" return state

工程化建议：
1.持久化：在节点执行前，务必将 State 序列化存入 Redis 或 DB。因为进程可能重启，或者用户关闭浏览器后重新打开。
2.幂等性：确保人工干预后的流程回写是幂等的，防止重复提交。
3.超时处理：如果人工超过 24 小时未审批，应该触发超时节点，转为人工客服介入或自动降级处理。

在面试中，提到“设计了支持断点续传的人工审批节点，并实现了 State 的持久化存储”，这直接展示了你对分布式系统和数据一致性的考量。