LangChain 和 LangGraph，到底怎么分工

1. 一个做零件，一个做流水线

如果你刚接触 Agent 开发，LangChain 和 LangGraph 这两个名字很容易混。

可以这么理解：

• LangChain 是工具箱。它把模型调用、Prompt 模板、资料检索、外部工具封装成稳定组件。
• LangGraph 是施工流程图。它决定这些零件按什么顺序组装、出错后回到哪一步、在哪里停下来等人确认。

一个 Agent 项目通常会遇到两类问题：

1. 原子能力问题：怎么调用不同模型、怎么复用 Prompt 模板、怎么从知识库检索资料、怎么把外部系统封装成工具。
2. 工作流问题：什么时候先检索，什么时候再生成；事实不足时是否回到检索；产物风险较高时是否进入人工确认；审核不通过时回到哪一步。

LangChain 解决第一类，LangGraph 解决第二类。

一句话：LangChain 负责「一个节点怎么完成任务」，LangGraph 负责「多个节点怎么按状态继续往下走」。

2. LangChain：把节点里的动作做稳

一个 Agent 节点通常会调用模型、拼装 Prompt、检索资料、使用外部工具，再把结果整理成结构化输出。LangChain 就适合放在这一层。

2.1 模型调用

Agent 系统通常会同时使用多种模型：

• 目标解析或轻量判断用成本低、响应快的模型。
• 深度生成用长上下文、生成能力强的模型。
• 事实核查用更重视引用和结构化输出的模型。
• 变体生成用适合短文本的模型。

如果每个节点都直接写供应商 SDK，模型参数、超时、重试、结构化输出和 tracing 很快会散在各处。LangChain 的模型抽象让调用保持相近形态，节点只关心「输入什么、产出什么」。

例如，planningAgent 不需要知道底层是 OpenAI、Anthropic 还是其他。它只需要接收任务目标、对象画像和资料摘要，然后返回一份结构。

2.2 Prompt 模板

Agent 的 Prompt 很容易膨胀。目标、对象、产物类型、资料来源、禁用表达、结构要求、引用规范都会塞进去。如果直接散落在节点函数里，后续很难比较不同版本的生成效果。

LangChain 的 Prompt 模板可以把稳定结构和运行时变量分开：

const planningPrompt = ChatPromptTemplate.fromMessages([
  [
    'system',
    '你是任务规划 Agent。请基于资料摘要生成可执行结构，并标记每一部分还缺哪些证据。',
  ],
  ['human', '目标：{goal}\n目标对象：{audience}\n资料摘要：{researchBrief}'],
]);

这个模板不决定工作流要不要进入事实核查，也不决定审核失败后回到哪里。它只负责让「生成结构」这个动作更稳定、更容易复用。

2.3 Retriever

Agent 常见的资料来源包括项目文档、会议纪要、竞品分析、内部规范、历史产物和外部网页。Agent 需要按主题、对象和阶段取回不同证据。

LangChain 的 Retriever 可以把「怎么检索」封装成稳定接口。上层节点只传入查询意图，例如：

• 检索与主题相关的历史项目资料。
• 检索产品能力的官方描述。
• 检索已批准可公开使用的案例。
• 检索项目规范中关于格式和表达的要求。

Retriever 返回的结果再进入执行节点、核查节点或编辑节点。向量库、关键词检索、重排策略和来源过滤可以在 Retriever 内部演进，不需要每次都改动工作流节点。

2.4 Tool

Agent 里的 Tool 往往连接真实系统：

• 搜索内部知识库。
• 抓取指定 URL。
• 查询历史产物或草稿。
• 写入新的产物版本。
• 创建人工审核任务。
• 读取项目词表和禁用词表。

LangChain 可以把这些能力封装成工具，并明确输入输出 schema。节点拿到结构化结果，后续节点可以减少对自由文本的解析。

需要注意的是，Tool 只解决「怎么执行动作」。是否允许写入外部系统，是否需要人类确认，工具失败后是否重试，这些属于流程控制，应该放在 LangGraph 里处理。

3. LangGraph：把 Agent 流程组织成状态图

当 Agent 系统从「一次生成」变成「多 Agent 协作」，流程会出现分支、回退、暂停和恢复。LangGraph 的价值主要在这一层。

3.1 State：任务状态在节点之间流转

LangGraph 的 State 可以承载一个任务在整个流程里的当前快照。除了 messages，它也可以保存目标、资料、结构、产物、审核意见和下一步动作。

interface AgentTaskState {
  goal: string;
  audience: string;
  sources: Array<{ title: string; url?: string; summary: string }>;
  plan?: string;
  product?: string;
  factCheckNotes: string[];
  styleReviewNotes: string[];
  approvalStatus: 'pending' | 'approved' | 'rejected';
  nextStep?: string;
}

这个状态让每个节点只处理自己负责的部分。researchAgent 更新 sources，planningAgent 更新 plan，executionAgent 更新 product，factCheckAgent 更新 factCheckNotes。流程不再依赖一条越来越长的对话历史来保存所有中间结果。

3.2 条件路由：根据状态决定下一步

Agent 流程里的常见风险，是把所有步骤写成固定顺序。固定顺序适合演示，难以支撑生产系统。

更接近实际的路由规则：

• 如果资料不足，回到 researchAgent。
• 如果结构缺少证据标注，进入 planningRevisionAgent。
• 如果事实核查发现未引用来源，回到 executionAgent。
• 如果包含法律、医疗、金融等敏感主题，进入 humanReview。
• 如果人工审核通过，进入 systemWriter。

LangGraph 的条件边可以把这些规则放在图结构里。路由函数读取当前 State，返回下一步节点。节点本身只负责产出状态更新，不需要同时承担所有流程判断。

3.3 持久化：长流程需要可恢复

一个任务可能不会一次完成。检索可能要等待，人工审核可能隔天才处理，外部系统写入也可能失败后重试。把状态只放在内存里，流程中断后就很难恢复。

LangGraph 的持久化能力至少解决三件事：

1. 恢复：服务重启后，可以从上一次保存的任务状态继续。
2. 审计：可以回看每个节点对任务状态做过什么修改。
3. 人工介入：人工审批后，流程可以带着审批结果继续运行。

这类能力难以仅靠 Prompt 承接。Prompt 可以要求模型「像审核员一样谨慎」，但工程上的暂停、恢复和审批记录需要明确的状态与存储机制。

3.4 人工确认点：把不可自动化的判断留出来

Agent 系统里，并非每个步骤都适合自动放行。下面几类节点通常需要人工确认：

• 使用了不确定来源，且产物准备对外发布。
• 涉及法律、财务、医疗、隐私或品牌风险。
• Agent 建议删除大量原有内容。
• 工具准备写入外部系统或发布渠道。

LangGraph 可以在这些位置中断执行，等待人工给出 approve、edit、reject 或补充说明。确认完成后，图再从对应 checkpoint 继续运行。

这让工作流更接近真实生产流程：AI 可以推进检索、整理和初版产物，但高风险动作需要留下可追溯的确认点。

3.5 多 Agent 编排：让分工围绕同一个状态协作

Agent	主要职责	写入状态
Research Agent	收集资料、归纳来源、标注证据缺口	sources
Planning Agent	生成结构、拆分节点、标记证据需求	plan
Execution Agent	根据结构和资料生成产物	product
Fact Check Agent	检查事实、引用和不确定表述	factCheckNotes
Style Editor Agent	按项目规范修订表达	styleReviewNotes、product
Delivery Agent	写入外部系统或提交发布请求	approvalStatus

LangGraph 没有要求所有 Agent 都合并成一个大 Prompt。更合适的做法是：每个 Agent 负责一个清晰的节点，节点内部用 LangChain 的模型、Prompt、Retriever 和 Tool；节点之间通过 State 和条件边协作。

4. 一个完整的 Agent 流程示例

下面是一条较完整的流程，用来看 LangChain 和 LangGraph 怎么协作。

1. 输入目标

   用户提交目标、对象和产物类型。LangGraph 初始化 AgentTaskState，把目标、对象和空资料列表写入状态。

2. 资料检索

   LangGraph 进入 researchAgent 节点。节点内部用 LangChain Retriever 检索项目资料、历史产物和公开资料，再把摘要写入 sources。

3. 结构生成

   LangGraph 进入 planningAgent。节点内部用 LangChain Prompt 模板和模型调用，根据 goal、audience、sources 生成结构，并标出每一部分需要的证据。

4. 条件判断

   路由函数检查 plan 和 sources。如果资料不足，回到 researchAgent；如果结构可用，进入 executionAgent。

5. 产物生成

   executionAgent 用 LangChain 模型调用和 Prompt 模板生成产物。它只更新 product，不直接写外部系统。

6. 事实核查与风格修订

   factCheckAgent 检查产物里的事实和引用，styleEditorAgent 检查表达是否符合项目规范。两个节点可以顺序执行，也可以在某些场景下并行后合并状态。

7. 人工确认

   如果产物包含高风险主题，或核查节点留下未解决问题，LangGraph 暂停在 humanReview。人工给出批准、修改意见或拒绝后，流程从 checkpoint 继续。

8. 写入外部系统

   审核通过后，LangGraph 进入 deliveryAgent。节点内部调用 LangChain Tool，把产物写入外部系统或提交发布请求。

这条流程里，LangChain 让每个节点的动作可复用、可替换；LangGraph 让整条流程具备分支、暂停、恢复和审计能力。

5. 一句话判断：这个问题该放哪边

实际设计时，可以用下面这张表判断：

问题	更适合放在
怎样调用某个模型并解析结构化输出	LangChain
怎样维护可复用 Prompt 模板	LangChain
怎样从向量库、文档库或网页检索资料	LangChain
怎样把外部系统、搜索、审核系统封装成工具	LangChain
当前任务状态包含哪些字段	LangGraph
资料不足时回到哪个节点	LangGraph
人工审核通过后从哪里继续	LangGraph
多个 Agent 怎样共享同一个任务状态	LangGraph
服务中断后怎样恢复流程	LangGraph

如果一个问题只关心单次动作的输入输出，通常先放到 LangChain。如果一个问题关心状态、分支、恢复、人工确认或多 Agent 交接，通常应该放到 LangGraph。

6. 总结

LangChain 和 LangGraph 可以按工程责任分层使用。

LangChain 负责把模型、Prompt、Retriever 和 Tool 做成稳定的原子能力。它让每个 Agent 节点内部的动作更容易复用和替换。

LangGraph 负责把这些节点组织成可运行的状态图。它让 Agent 流程可以根据状态分支，可以在人工确认点暂停，可以持久化和恢复，也可以让多个 Agent 围绕同一个任务状态协作。

这个边界在组合使用时需要保留：节点里的动作交给 LangChain，节点之间的状态流转交给 LangGraph。

一句话总结：LangChain 管一个节点怎么做好，LangGraph 管多个节点怎么按状态继续走。