AI Agent 框架选型：LangChain vs LangGraph vs 自研决策指南

先回答核心问题：该不该用框架？

如果你的场景只有两三个工具、一条线性调用链——比如用户提问 → 检索知识库 → 生成回答——那根本不需要任何 Agent 框架。直接调用 LLM API，加上几行工具调度逻辑就够了。框架带来的抽象层在这个量级上只会增加调试负担。

但当你的任务需要多步推理、动态工具选择、持久化状态、人工审核节点或多个 Agent 协作时，框架的价值才真正显现。这就是框架的甜蜜区：既不是简单到手写就行，也不是复杂到必须完全自研。

2025 年主流选择集中在三类路径上：LangChain 代表高抽象、全托管的开发体验；LangGraph 代表低层级、显式状态图的精细控制；以及完全自研，把每一块拼图自己组装。

下面从四个决策维度逐一拆解。

---

维度一：开发效率（DX 与学习曲线）

LangChain 的核心优势是开箱即用。 它提供超过 1000 个预置集成，ReAct 风格的工具调用循环只需几行代码就能跑通，8 种内置记忆类覆盖了从滑动窗口到向量检索的常见场景。对于需要快速验证想法的团队，这种"电池全含"的设计能把原型到 MVP 的周期压缩到最短。

但高抽象是一把双刃剑。LangChain 的链式调用在调试时经常让人摸不清数据流向——抽象层太多，出错时难以定位是哪一层吞掉了信息或改变了格式。一个真实案例是 Octomind 团队在使用 LangChain 构建测试 Agent 时，遇到了调试困难，最终评估认为抽象深度反而拖慢了迭代速度。此外，LangChain 在 v1.0 之前经历了多次 API 变更，稳定性一直是社区反馈的痛点。直到 2025 年 10 月发布 v1.0 后，引入语义化版本控制和中间件层，才显著改善了升级体验。

LangGraph 从一开始就选择了另一条路。 它不是在 LangChain 之上加一层，而是一个更底层的运行时。你需要显式定义 StateGraph 对象，用 TypedDict 声明状态结构，每个节点、每条边都是你亲手写出来的。代码量更多，但每一步的执行路径都一目了然。在 Nextbuild 的 90 天基准测试中，PydanticAI（同样是类型驱动的框架）获得了 8/10 的开发者体验评分，而 LangChain 只拿到 5/10。LangGraph 的开发体验介于两者之间：学习曲线更陡，但一旦理解了状态图模型，调试和修改的效率反而更高。

自研方案的 DX 取决于团队能力。 如果你的团队对 LLM 调用模式、prompt 工程和异步编程都很熟悉，自研可以做到极致精简。OpenAI Agents SDK 用 4 行代码就能创建一个可工作的 Agent，MIT 协议，按用量计费。但"简单"的前提是你自己负责所有周边能力：重试逻辑、错误处理、监控埋点、权限控制。这些在框架里是免费的，在自研里全是工作量。

决策建议： 如果团队小于 5 人、项目处于探索阶段、需要快速出 Demo，LangChain 是合理的起点。如果团队有扎实的工程基础、项目需要精细控制执行流程，直接上 LangGraph 能避免后期重构。如果场景极度标准化且对延迟敏感，自研可能是长期最优解。

---

维度二：状态管理（记忆与 Checkpoint）

Agent 和普通 LLM 调用的核心区别在于：Agent 是一个循环。它接收提示，决定行动，执行工具，观察结果，再决定下一步。这个循环要可靠地工作，状态管理是基础设施。

LangChain 的记忆机制覆盖面广但粒度粗。 8 种记忆类包括对话历史、实体记忆、知识图谱记忆等，开箱即用。但这些记忆模块主要服务于"对话上下文"这个场景——你需要在多轮对话中记住用户说过什么。对于 Agent 执行过程中的中间状态（比如某个工具调用失败后需要回退到上一步），LangChain 的原生支持就比较有限。

LangGraph 在状态管理上做到了工程级的可靠性。 每一次节点转换都会自动做 checkpoint，这意味着 Agent 在任何一步崩溃，都能从最近的 checkpoint 恢复，而不是从头重跑。这对长耗时任务（比如需要调用外部 API 批量处理数据的场景）至关重要——一个运行了 20 分钟的 Agent 在第 18 分钟挂了，有 checkpoint 意味着只需从断点继续，没 checkpoint 意味着从头来。

更进一步，LangGraph 提供了 interrupt_before 和 interrupt_after 机制，让你在任意节点前后插入人工审核。这在合规场景下几乎是刚需：比如 Agent 在执行资金操作前，先暂停等人工确认。持久化方面，PostgresSaver 和 RedisSaver 让状态可以跨进程、跨机器存活。LangGraph Studio 还支持"时间旅行调试"——你可以回到 Agent 执行过程中的任意历史状态，检查当时的决策是否合理。

自研方案在状态管理上的常见陷阱是低估复杂度。 很多团队一开始觉得"我用 Redis 存一下中间状态就行"，但很快就会发现需要处理并发冲突、状态序列化、清理过期数据、支持多租户隔离等一系列问题。如果你的 Agent 需要可靠的中断恢复，自研一个 checkpoint 系统的工作量不亚于直接用 LangGraph。

一个值得警惕的反面案例： 某些框架的 delegation 循环存在已知的可靠性问题。在没有内置 token 预算限制器的情况下，Agent 之间相互委托任务可能陷入死循环，有实测记录显示单次运行费用达到 414 美元。无论选哪种方案，你都需要在状态管理层面设置明确的退出条件和资源上限。

---

维度三：生产可观测性（Tracing、Logging、Guardrails）

原型能跑和生产能用之间，隔着一整套可观测性基础设施。

LangChain 生态在这方面投入最多。 LangSmith 提供了从 prompt 输入到最终输出的全链路追踪，每一次 LLM 调用、每一次工具执行都被记录下来。结合 LangGraph Platform，你可以把 Agent 部署为托管服务，内置日志收集和错误告警。对于需要审计合规的企业，这种开箱即用的可观测性是很大的加分项。

但要注意 LangGraph Platform 的部署模型——它是云托管服务。如果你的场景有严格的数据本地化要求（比如金融、医疗行业），需要确认数据是否经过你的 VPC，以及是否有自托管选项。

LangGraph 本身的可观测性更依赖你自己的埋点。 框架提供了 checkpoint 和状态快照，但日志、指标、告警这些生产级能力需要你自己接入 Prometheus、Grafana 或其他监控栈。好处是你完全控制数据流向，坏处是前期搭建成本更高。

自研方案在可观测性上从零开始。 你需要自己设计 trace ID 传播方案、结构化日志格式、指标采集点。如果团队之前没有做可观测性的经验，这部分工作量很容易被低估。一个实用的建议是：即使选择自研 Agent 逻辑，也尽量复用已有的 APM 基础设施（比如 OpenTelemetry），而不是重新造轮子。

关于 Guardrails（安全护栏）： 这是生产部署中容易被忽视的一环。Agent 拥有执行能力，如果不加限制，一个幻觉输出可能触发真实世界的操作。你需要在三个层面设防：输入过滤（防止 prompt 注入）、输出校验（确保 Agent 行为在预期范围内）、执行审计（记录所有副作用操作）。LangChain 的 LCEL（LangChain Expression Language）中间件层可以插入自定义检查逻辑；LangGraph 可以在节点级别做 guard；自研方案则需要在架构设计阶段就把护栏作为核心组件。

---

维度四：厂商锁定风险（开源 vs 闭源、模型依赖）

框架选型是一个持续 3-5 年的技术投资决策。锁定风险需要在选型阶段就评估清楚。

LangChain 的锁定风险处于中等水平。 它是 MIT 协议开源的，核心代码你可以 fork 和修改。但它的抽象层设计意味着大量业务逻辑会绑定在 LangChain 的 API 上——当你想切换到其他方案时，重写成本不低。2024 年的频繁 API 变更已经让不少团队吃过亏。v1.0 之后的语义化版本控制承诺了更稳定的升级路径，但承诺和现实之间的距离需要时间验证。

LangGraph 的锁定风险相对较低。 它的 StateGraph 模型是显式的、可序列化的——你的状态定义和执行图是标准 Python 代码，不依赖任何黑盒运行时。即使将来不用 LangGraph 了，你的状态结构和图定义可以相对容易地迁移到其他方案。代价是前期需要投入更多工程量。

模型依赖是另一个维度。 如果你的 Agent 深度依赖某个特定模型的能力（比如某个模型的 function calling 格式、某个模型的超长上下文窗口），那框架选型之外还要考虑模型切换成本。一个务实的做法是：在 Agent 的工具层和编排层之间保持清晰的边界，让模型切换只影响 LLM 调用这一个点，而不扩散到整个系统。

自研方案在锁定风险上天然最低。 你自己写的代码，你完全掌控。但这也意味着你需要自己跟进 LLM 生态的变化——API 格式调整、新能力发布、安全漏洞修复。每年花在"跟上变化"上的工程时间，就是自研的隐性成本。

---

落地决策框架

不要从"我偏好哪个框架"出发，而要从约束条件倒推：

第一步，列出硬约束。 合规要求（数据是否可以出境？是否需要审计日志？）、部署环境（K8s？Serverless？需要特别注意的是 LangGraph 与 Serverless 不兼容）、团队能力（有多少人熟悉 Python 异步编程？有没有 LLM 应用开发经验？）。

第二步，评估你的 Agent 复杂度。 2-3 个工具、线性流程——不需要框架。多步推理、动态工具选择、需要 checkpoint——考虑 LangGraph。快速原型、团队经验有限——从 LangChain 开始。

第三步，规划演进路径。 今天选的方案不一定是三年后的方案。选择一个在你当前约束下最省力的方案，但确保核心业务逻辑和框架抽象之间有清晰的解耦层。这样当需求变化或框架不再适合时，迁移成本可控。

框架只是工具。选对了，它帮你省时间；选错了，它帮你造债。花在理解自身需求上的时间，永远比花在比较框架特性列表上更值得。