LangGraph：把 Agent 从“会回答”推进到“可控执行”的工程架构

1. 为什么企业 Agent 不能只靠一次 LLM 调用

在 PoC 阶段，很多 AI 应用看起来只需要一个 Prompt：用户输入问题，模型生成答案。但进入真实业务系统后，这种“输入一次、输出一次”的方式很快会遇到边界：

  • LLM 本身无法稳定访问实时数据、内部数据库、业务系统 API。
  • 单次推理缺少长期任务规划能力，难以独立完成“查询、判断、执行、复核、回写”的完整流程。
  • 完全自主的 Agent 又会带来不可预测性，例如死循环、错误工具调用、越权操作、幻觉决策。
  • 传统链式流程可靠但僵硬，一旦出现分支、重试、人工审批、异常回滚，链会迅速膨胀。

所以企业落地真正需要的不是“更聪明的聊天框”，而是一个能把 AI 能力放进工程控制面里的运行时。LangGraph 的价值就在这里：它用图结构承载 Agent 流程，把 LLM、工具、规则、状态、人工干预组织成可观察、可恢复、可约束的执行系统。

2. 从 Chain 到 Graph：核心变化是什么

传统 Chain 更像一条固定流水线：

Start -> Step 1 -> Step 2 -> Step 3 -> End

它的优势是确定性高，缺点是灵活性弱。业务越复杂，分支越多，异常路径越多，链式代码越容易变成大量 if/else 和补丁逻辑。

LangGraph 将流程建模为图：

Start
-> Agent Node
-> Tool Node
-> Agent Node
-> Human Review Node
-> End

图结构允许流程根据状态动态选择下一步。一个节点执行完成后，不必只能进入固定的下一个节点，而是可以由边，尤其是条件边，决定是否调用工具、是否重试、是否进入人工审批、是否终止。

这使 Agent 系统从“线性脚本”变成“受控状态机”。它不是让模型随意行动，而是把模型的自主性限制在设计好的图结构中。

3. LangGraph 的三个基础构件

视频中反复强调：上手 LangGraph 要先吃透三个词，State、Node、Edge。官方文档也将它们定义为 Graph API 的核心。

State：共享的业务现场

State 是图执行过程中的共享数据结构，可以理解为一次任务的“黑板”或“上下文快照”。每个节点不需要传递一长串参数，而是读取当前状态，并返回对状态的增量更新。

企业系统中，State 通常不应只放聊天消息，还应包含：

  • messages：用户消息、模型回复、工具结果。
  • user_id / tenant_id：身份和租户上下文。
  • task_id：业务任务编号。
  • intent：模型或规则识别出的业务意图。
  • tool_results：工具调用返回的结构化结果。
  • approval_status：人工审批状态。
  • risk_level：风控等级。
  • retry_count：重试次数。
  • final_answer：最终对用户返回的结果。

这个设计的关键是：状态要有 Schema。不要让节点随意写任意字段，否则后期排查和升级会非常痛苦。

Node：执行动作的最小单元

Node 是真正做事的地方。它可以是：

  • 一次 LLM 调用。
  • 一个工具调用。
  • 一个业务 API 调用。
  • 一个规则校验。
  • 一个检索步骤。
  • 一个人工审批等待点。
  • 一个结果格式化器。

好的节点应该职责单一。比如不要把“识别意图、查数据库、生成回复、写审计日志”全塞进一个节点。这样虽然初期快，但后续无法复用、无法单独测试，也无法精确定位失败点。

Edge：流程控制与决策

Edge 决定下一个节点。固定边适合稳定流程，条件边适合根据状态分支。

例如：

Agent Node
-> if need_tool: Tool Node
-> if need_human: Human Review Node
-> if ready: Final Answer Node

在企业系统里，条件边最好由“模型判断 + 规则兜底”共同决定。模型可以识别复杂语义，规则可以守住安全边界。

4. 一个适合公司落地的 LangGraph Agent 架构

下面是推荐的基础架构：

User Request
-> Input Validation
-> Intent Router
-> Agent Reasoning
-> Tool Selection
-> Tool Execution
-> Result Normalization
-> Risk Check
-> Human Review, optional
-> Final Response
-> Audit Log / Metrics

对应到 LangGraph：

START
-> validate_input
-> classify_intent
-> agent_reason
-> route_action
-> call_tool
-> ask_human
-> final_answer
-> normalize_result
-> risk_check
-> END

这个结构把 Agent 的“思考”和企业系统的“控制”分开：

  • LLM 负责理解、规划、解释。
  • 工具节点负责访问外部能力。
  • 风控节点负责策略判断。
  • 人工节点负责高风险动作确认。
  • 状态和检查点负责恢复与审计。

5. 工具调用：不要把工具结果直接丢给用户

视频中特别提到一个常见错误：工具节点执行完后，不应直接把原始结果返回给用户。工具返回的往往是 JSON、数据库行、API 响应或错误码。用户真正需要的是经过上下文解释后的结论。

推荐流程是：

Agent decides tool is needed
-> Tool executes
-> Tool result written into State
-> Agent reads State again
-> Agent produces human-readable response

这条回路非常重要。它让 LLM 不只是“选择工具”，还负责把工具结果转化成业务语言。

工程建议：

  • 工具返回值必须结构化，避免返回不可解析的大段文本。
  • 工具节点要记录 tool_name、args、duration_ms、status、error。
  • 对写操作工具增加幂等键，例如 operation_id。
  • 对高风险工具增加人工审批边。
  • 对外部系统失败增加重试和降级路径。

6. Persistence 与 Checkpoint：让 Agent 能恢复

企业 Agent 不能假设每次任务都在一个请求内完成。用户可能隔天回来问进度，工具调用可能超时，人工审批可能几个小时后才完成，服务也可能重启。

因此，持久化不是锦上添花，而是生产必需能力。

LangGraph 的检查点机制可以把图执行状态保存下来，使任务能够从中断处继续。对于研发团队，这意味着：

  • 长任务可以跨请求运行。
  • 人工审批可以暂停和恢复。
  • 失败后可以从最近节点重放，而不是从头开始。
  • 审计可以追踪每一步状态变化。

推荐做法：

  • 开发环境可以使用内存型 checkpointer。
  • 测试和生产环境应使用数据库型 checkpointer。
  • 状态字段要区分“可持久化业务数据”和“临时运行时数据”。
  • 涉及用户隐私、密钥、支付、订单的字段要做脱敏或加密。

7. Human-in-the-loop：让 AI 学会“请示汇报”

在企业落地中，人机协同不是削弱自动化，而是提高可上线性。视频中把它形容为让 AI 像员工一样“请示汇报”，这个说法很适合工程团队理解。

需要人工介入的典型场景：

  • 删除、转账、退款、发券等不可逆操作。
  • 置信度低但影响大的判断。
  • 命中合规或安全策略。
  • 模型计划与业务规则冲突。
  • 工具参数需要人工修正。

图结构非常适合表达这类流程：

risk_check
-> low_risk: execute_tool
-> high_risk: human_review
human_review
-> approved: execute_tool
-> edited: execute_tool_with_new_args
-> rejected: final_reject_response

这样做的好处是 AI 不再是黑盒执行器，而是可被拦截、可被修改、可被追责的协作单元。

8. 自我修正与反思：用图表达质量闭环

视频最后给出的一个重要方向是“自我修正”。例如让一个节点生成方案，另一个节点评审方案，如果评审失败，就沿着边回到生成节点重写。

generate_plan
-> review_plan
-> if pass: execute_plan
-> if fail: generate_plan

这个模式适用于：

  • 代码生成和代码评审。
  • SQL 生成和 SQL 安全检查。
  • 文档生成和事实一致性检查。
  • 客服回复和合规审核。
  • RAG 回答和引用完整性检查。

但要注意，循环必须有上限。生产环境中应设置：

  • 最大递归次数。
  • 最大工具调用次数。
  • 最大 token 成本。
  • 最大执行时长。
  • 失败后的降级响应。

9. 公司研发团队的落地路线

建议不要一开始就做“万能 Agent”。更可控的路线是：

第一阶段：把现有 Prompt 应用图化

选择一个已经跑通的 AI 功能，将它拆成：

  • 输入校验节点。
  • LLM 节点。
  • 输出格式化节点。
  • 错误处理节点。

目标是建立图执行、状态记录、日志追踪的基础能力。

第二阶段：接入只读工具

优先接入风险较低的工具：

  • 查知识库。
  • 查订单状态。
  • 查客户画像。
  • 查库存。
  • 查工单。

只读工具能快速验证工具调用闭环，同时避免写操作风险。

第三阶段：引入持久化和短期记忆

为每个会话或任务引入 thread_id，使用 checkpointer 存储状态。让 Agent 能够记住一次任务中的上下文，而不是每次都从零开始。

第四阶段：接入写操作与人工审批

写操作必须先进入审批和风控：

  • 参数展示给人看。
  • 人可以批准、拒绝或修改参数。
  • 所有决策写入审计日志。

第五阶段：平台化

沉淀通用能力：

  • 工具注册中心。
  • 状态 Schema 规范。
  • Agent 模板。
  • 审批组件。
  • 运行指标。
  • LangSmith 或等价观测平台。
  • 测试集与回归评估。

10. 技术选型建议

LangGraph 适合以下场景：

  • 多步骤任务。
  • 需要工具调用。
  • 需要状态持久化。
  • 需要人工审批。
  • 需要可恢复、可观测、可测试。
  • 需要把确定性流程和模型推理混合起来。

如果只是简单问答、FAQ、一次性总结，直接使用模型接口或 LangChain agent 可能更轻。如果已经明确需要复杂编排，LangGraph 更适合作为底层运行时。

11. 工程风险清单

研发团队上线前至少要检查：

  • 图是否存在无限循环风险。
  • 每个工具是否有权限边界。
  • 写操作是否幂等。
  • 状态是否包含敏感信息。
  • checkpointer 是否可用并可迁移。
  • 节点失败是否有补偿路径。
  • 人工审批是否能恢复执行。
  • 是否有完整 trace。
  • 是否有成本、延迟和调用次数监控。
  • 是否有回归测试集。

12. 总结

LangGraph 的核心不是“让 Agent 更自由”，而是“让 Agent 在可控结构中自由”。它用图结构把 LLM 的推理能力、工具的执行能力、状态的连续性、人工的监督能力组合起来。

对公司研发团队而言，LangGraph 最值得采用的地方不是某个 API，而是一种架构思想：把 AI 应用从 Prompt 工程推进到状态机工程、流程工程和运行时工程。

posted @ 2026-07-30 17:03  青柠_fisher  阅读(1)  评论(0)    收藏  举报