LangChain / LangGraph 引入决策：什么时候才需

LangChain / LangGraph 引入决策：什么时候才需要

最近在做长记忆RAG知识库系统时面临是否需要引入LangChain / LangGraph的问题，作为新手步步深入后再后面的项目中必然是要面对的抉择。本文刚好是对于当前系统代码中遇到的总结，希望能帮助大家是否为了假需要而引入还是为了真需要而拒绝引入的思考。

一句话结论：针对当前这份长记忆 RAG 项目任务书，v1.0 不需要引入 LangChain，也不需要 LangGraph。

---

0. 核心判断

那条链路——分块、三路召回、RRF 融合、重排、分层注入、记忆四步写入、Tools 查单据——"下一步干什么"全部由代码写死，模型只负责生成 / 抽取 / 判定，不负责决定流程。这种「确定性流水线 + 少量 LLM 调用」，恰好是框架收益最低、抽象成本最高的场景。

已经选定的 LangSmith 是框架无关的：用 wrap_openai() 包住原生 SDK，再用 @traceable 装饰自己的函数即可完成追踪与评估，完全不必为了观测引入 LangChain。

---

1. 先分清三者定位

	解决什么问题	位置
LangChain	集成与快速搭 agent：create_agent + middleware，多模型 / 多工具 / 多向量库的适配层	高层框架
LangGraph	编排运行时：节点、条件边、共享状态、检查点、人工中断、时间旅行	低层运行时
LangSmith	观测与评估，不参与执行	旁路，与框架无关

需要更新的旧认知：

• 两者于 2025 年 10 月同时发布 1.0，此后 LangChain 的 agent 本身就跑在 LangGraph 之上。二者不是二选一，而是同一栈的上下层。
• 可以只用 LangGraph、不引入 LangChain：节点就是普通 Python 函数，内部可调用任意模型 SDK。
• 官方承诺 2.0 前无破坏性变更；旧 chains / helpers 已迁至 langchain-classic 包。
• 2026 年又多了一层 Deep Agents：开箱即用的长任务 harness，内置文件系统、子代理、记忆、按需加载的 skills。

---

LangChain（组件库：解决"适配"问题）

#	触发条件	典型信号	预估收益
LC-1	POC / 快速验证期	需求未定型，几天内出 demo 优先于工程质量	原型周期缩短 50%+
LC-2	文档数据源快速膨胀（本项目最可能的触发点）	知识库需接入 Confluence / SharePoint / 钉钉文档 / 网页等 10+ 异构源	省去 2~4 周手写 loader 与鉴权适配
LC-3	模型/供应商频繁更换	多模型并存、切换频繁（本项目 OpenAI 兼容接口已解决大半）	适配层零维护
LC-4	缺乏专人跟进第三方 API 变更	无人力维护 pypdf / DashScope SDK 等兼容性	依赖风险转移给库方
LC-5	深度使用 LangSmith 评估生态	数据集管理与自动评估链路需复用现成实现	评估基建省约 1 周

本项目现状核对：5 种本地格式自研解析（D-03）、模型走 OpenAI 兼容接口、检索/记忆全自研——LC-1~5 均未触发，故一期不引入。

LangGraph（编排器：解决"动态控制流"问题）

核心判断法则：流程在编码时能否画成一张固定的直线图？能 → 不引入；需要由 LLM 在运行时决定下一步 → 才考虑。

#	触发条件	判断标准	本项目对应情景
LG-1	多步自主任务（ReAct 式）	工具调用 ≥ 2 轮且步骤不可预知	"查这单为什么没发货，有问题直接建售后工单"→ 订单→物流→建单的连续调用与循环判断
LG-2	人工介入节点（HITL）	流程需中断等待审批，批准后从断点继续	工具从"查"升级为"写"（建退款单/改库存）时为硬需求
LG-3	状态持久化与断点恢复	长任务中断后从中间态重放而非重头来	多步任务第 3 步服务重启，恢复后不重复前 2 步
LG-4	多 Agent 协作/路由	规划者-执行者、领域间 handoff	出现"知识库 agent / 业务查询 agent / 客服 agent"分工时
LG-5	复杂对话状态机	显式阶段（澄清→检索→确认→执行）且含回边	固定管道 + 8 轮摘要机制不满足时

反向信号（出现下列情况仍不引入，避免过度设计）：

• 仅增加查询类工具数量（3~5 个），每轮仍单次调用、失败即降级 → while 循环手写足够（D-09 方案）；
• 工具调用失败只需重试/熔断降级，无需"重规划" → 现有 5.3.2 熔断方案覆盖；
• 记忆/检索逻辑再复杂也属确定性数据流水线，不是 agent 决策 → 不纳入图编排。

2. 引入阶梯：什么时候往上走一级

阶梯里真正值得付钱的只有最上面一级。LangGraph 卖的不是"能画流程图"——自己写 200 行 if/else 也能画——而是让一次执行可以暂停、跨天恢复、从任意检查点重放。

---

3. LangGraph 真正不可替代的能力

能力	自己实现要写什么	LangGraph 提供
状态	Typed state 序列化、reducer 合并规则	State + Reducer
持久化	每步写库、幂等、崩溃重放	Checkpointer
暂停	暂停 / 恢复 API、状态版本管理	interrupt()
回跳	条件边、循环终止条件	条件边、图拓扑
排查	任意步骤快照与回放	Time travel

---

4. 四个真正该引入的信号

信号	说明	该上什么
下一步由模型决定	工具调用几次、什么顺序、失败是否换路，代码写不出来也写不全	create_agent + middleware
流程有环 / 条件回跳 / 并行汇合	不是一张固定 DAG，而是"判定不合格 → 回到上一步重做"	LangGraph 的图与条件边
执行要跨重启、跨天恢复，或中途人工审批	需要暂停、等人确认、从检查点续跑、回放排查客诉	LangGraph 的 checkpointer + interrupt()
生态适配成了主要维护成本	频繁换模型商、接十几个向量库 / 工具，适配代码比业务代码多	LangChain integrations

反信号：出现任一情况就别引入

• 流程能画成固定 3~8 步顺序图；
• 核心资产是自研算法（RRF 权重、分层注入预算、冲突判定、衰减公式）——被框架封装后反而难针对性调参；
• 团队要一眼看懂调用栈、精确定位 P95 延迟在哪一步；
• 私有化单机部署、依赖越少越好。

---

5. 引入的隐性成本

成本	说明
抽象泄漏	出问题时在读框架的调用栈，不是自己的 200 行代码；LangSmith 的 trace 会变漂亮，但排查不一定变快
版本迁移	1.0 前的旧写法已迁至 langchain-classic；网上大量教程是旧 API；追踪环境变量从 LANGCHAIN_TRACING_V2 改为 LANGSMITH_TRACING，写错不报错、只是静默不上报
不改善核心指标	Recall@5、忠实度、记忆污染率由检索策略、分块和 Prompt 决定，框架不碰这些
团队学习	状态、节点、边、reducer、thread 等概念需要统一心智模型

对本项目的具体冲突（重点）

任务书 是「MariaDB 11.8 单库双模」。而 LangGraph 官方 checkpointer 只支持 Postgres / SQLite / Redis，没有 MariaDB 实现。一旦引入，要么用 SQLite 文件（检查点脱离主库，破坏"单库"一致性），要么再加一个 Postgres（多一套运维与备份）。

这个代价足以否决 v1.0 引入 LangGraph。

---

6. 项目升级需要考虑的问题

保持 L1 自研编排 + LangSmith 旁挂，直到出现以下任一情形再局部升级：

触发	情形	动作
A	Tool 从"正则命中单号 → 查表"升级为"模型自主决定调哪个工具、调几轮、失败自动换路"	只把这段换成 create_agent 或一个小型 graph
B	记忆写入从固定 4 步变成"抽取 → 判定 → 可能反过来追问用户 → 再判定"的循环，或矛盾合并前需人工确认且隔天继续	引入 LangGraph
C	出现多 Agent handoff（检索 Agent / 记忆 Agent / 校验 Agent）	引入 LangGraph

即便触发，建议只用 LangGraph，不引入全套 LangChain：节点里继续调项目自己的 OpenAI 兼容封装，模型层不动；InMemorySaver 仅限开发，生产必须换持久化 checkpointer。

最小改造路径示意（复用已有函数，不动其他模块）：

from langgraph.graph import StateGraph, START, END
from langgraph.types import interrupt

builder = StateGraph(MemoryWriteState)
builder.add_node("extract", extract_candidates)   # 已有函数，直接复用
builder.add_node("judge",   judge_conflict)
builder.add_node("confirm", lambda s: interrupt({"draft": s["candidates"]}))
builder.add_edge(START, "extract")
builder.add_conditional_edges("judge", route_by_verdict)  # 补充 / 矛盾 / 无关
graph = builder.compile(checkpointer=...)                # 生产须持久化

顺带提醒：如果团队发现自己在"手搓长任务 harness"（上下文卸载到文件、子代理隔离、按需加载技能），2026 年官方第三层 Deep Agents 已把这些做成开箱即用，值得先看一眼再决定自研。

---

7. 版本事实与参考

• LangChain 与 LangGraph 均于 2025 年 10 月发布 1.0，官方承诺 2.0 前无破坏性变更。
• LangChain 的 agent 自 1.0 起运行于 LangGraph 运行时之上；Deep Agents 是构建在其上的第三层 harness。
• LangSmith 明确支持框架无关接入：wrap_openai()、@traceable、OpenTelemetry 三种方式，不依赖 LangChain。
• 官方选型建议（原文）：标准 tool 循环用 LangChain；需要混合确定性步骤与 agentic 步骤、或完整控制每一步时用 LangGraph。文档同时提醒"不要一上来就画图"。

参考链接：

• https://langchain.com/
• https://www.langchain.com/blog/deep-agents-vs-langchain-vs-langgraph
• https://www.langchain.com/blog/common-questions-about-agent-evals
• https://www.workbuddy.cn/docs/workbuddy/Overview

---

8. 一句话

LangChain 是"少写适配代码"，LangGraph 是"买一套状态持久化与人工介入的运行时"。 前者在多模型多工具时才值，后者在流程会暂停、会回跳、要跨天恢复时才值。其余情况，自己的 200 行编排更好维护——本项目目前正是这种情况。

---

本文档由对话回复整理，两张图为内嵌 SVG（已使用唯一 marker id 与显式字体栈），可直接复制到 HTML 中复用。