开源项目推荐｜LangGraph：用状态图构建可恢复的 Agent

Agent 不是一条直线

简单 Agent 可以按模型决定工具、执行、继续，真实任务却会分支、循环、等待审批和失败重试。若所有逻辑藏在一个循环里，状态难以观察，恢复也只能从头开始。LangGraph 将 Agent 描述为有状态图，因此成为代码级 Agent 编排的重要开源项目。

官方仓库：https://github.com/langchain-ai/langgraph

图结构带来的清晰度

节点负责模型、工具或业务动作，边决定下一步，状态在节点间传递。开发者可以显式表达条件分支、循环上限、并行与人工中断，并通过检查点恢复流程。对于研究助手、客服升级、代码 Agent 和审批链，这比隐式循环更容易测试。

LangGraph 适合希望保持代码控制、需要自定义状态和执行语义的团队。它与 Dify 的可视化应用平台不同，也不负责 n8n 那样的大量 SaaS 集成；其重点是 Agent 运行逻辑。

图也会变复杂

节点过细会让状态难以理解，节点过大又失去可观察性。开始前应定义状态字段、终态、最大步数、幂等策略和错误归属。工具写操作要能安全重试或明确禁止重试，不能只依赖框架恢复。

长流程还要控制上下文增长。检查点保存执行状态，不代表应把全部中间文本持续送给模型。真实历史、摘要和模型 Context 应分别管理；跨端对话可让 DASP 负责会话层持久化。

设计独立复核节点

对高风险 Agent，可以把生成和审阅分成两个节点。审阅节点只接收原始证据、计划和候选结果，依据固定清单判断是否继续、退回或交给人工。使用不同模型能减少同一错误模式，但审阅标准仍需用真实样本校准。

与 AnyAIS 的组合方式

LangGraph 负责应用内状态图，AnyAIS 提供统一模型、MCP 工具、API Key、计量和请求日志。不同节点可以使用不同逻辑模型，却共用治理入口；模型渠道变化不必改写图。需要面向用户的持久会话时，DASP sid 可作为外层会话边界。

适合谁

需要复杂 Agent 分支、人工介入、检查点和可测试状态，同时愿意用代码维护执行逻辑的团队，适合 LangGraph。从三到五个节点的清晰流程开始，先证明恢复和终态，再扩展工具数量，通常最稳。

持久化要围绕 thread 与 checkpoint 设计

LangGraph 的持久化层会在执行步骤保存状态快照，并以 thread 组织检查点。这为故障恢复、人工介入、记忆和调试提供基础，但 thread_id 只是运行定位符，不应代替业务身份。服务端仍要验证用户和租户是否有权读取、恢复或修改该执行。

interrupt 之前的副作用必须可重放

官方 interrupts 允许图在任意节点暂停，保存状态并等待外部输入。恢复时节点的一部分逻辑可能再次执行，因此付款、发信、写数据库和调用第三方 API 等副作用要放入可检查的独立步骤，并使用幂等键或执行记录。审批界面展示具体工具、参数、对象和影响范围，而不是只有一个模糊的继续按钮。

对高风险操作，可先由另一模型独立审阅计划与证据，标记参数冲突或过度推断；审阅结果仍交给确定性权限规则和人员决定。独立模型增加发现问题的机会，但不能获得执行权限。

与 DASP 区分两层状态

LangGraph 管理应用内部的节点、边和 checkpoint，DASP 管理面向产品客户端的持久会话、事件流与 sid。一个 DASP 会话可以触发 LangGraph 执行，但不必把内部图状态全部暴露给客户端。把二者通过受控关联标识连接，既能恢复用户体验，也保留 Agent 运行细节的安全边界。

官方资料

LangGraph 概览：https://docs.langchain.com/oss/python/langgraph/overview

LangGraph 持久化：https://docs.langchain.com/oss/python/langgraph/persistence

LangGraph Interrupts：https://docs.langchain.com/oss/python/langgraph/interrupts