故事是这样的。

我这两天梳理 LangChain 和 LangGraph 的资料，看到一半，脑子里突然冒出来一个以前被我低估的问题。

一个团队到底应该在什么时候停在 LangChain，什么时候必须下沉到 LangGraph？

这个问题听起来很工程。

但我觉得，它背后其实藏着过去三年 AI 应用开发里，一个挺有意思的变化。

我们一开始以为，做 AI 应用，就是把模型接上工具，把 prompt 写好，把向量库连起来，然后让它跑。

后来大家才发现，真正麻烦的地方，根本不在接起来。

麻烦的是它跑起来以后。

它什么时候该调工具，调错了怎么办，跑到一半断了怎么办，用户想回到上一步怎么办，某个工具调用要不要人类批准，出了问题怎么追踪，长任务怎么恢复。

这些问题一出来，很多早期 demo 里那种轻盈的感觉，瞬间就消失了。

像从乐高，突然变成了工地。

这就是我看 LangChain 和 LangGraph 这段演化时，最强烈的感受。LangChain 早期最迷人的地方，是它让很多人第一次相信，大模型应用是可以工程化的。

你想想 2022 年那会儿，大家刚开始认真折腾 LLM，最直接的需求是什么？

把 OpenAI 接到自己的文档里。

把模型接到数据库里。

把搜索 API 接进来。

把 prompt template、retriever、parser、memory 串起来。

那时候 LangChain 这个名字取得很准，Chain，链。它给开发者的心理暗示非常明确，LLM 调用可以像管道一样，一段接一段，一环套一环。

输入进来，套个 prompt，丢给模型，输出再交给 parser，必要时检索一下文档，再总结一下，给用户返回。

这套东西，对 RAG、问答机器人、文档分析、SQL 查询生成，真的很顺。

我甚至觉得，LangChain 早期真正卖的并非某个优雅 API，而是一种信心。

原来 LLM 应用可以被拆成组件。

原来模型、工具、向量库、外部 API，可以被放进同一套开发语境里。

原来这玩意不是只能在 ChatGPT 网页里手搓。

那段时间，LangChain 的生长速度非常恐怖。各种模型供应商、embedding、vector store、document loader、toolkits，全都往里面塞。

好处当然很明显。

你想试一个东西，很快。

你想接一个后端，大概率有人已经接过了。

你想做一个看起来很 AI Native 的 demo，LangChain 往往能帮你少写很多样板代码。

但问题也在这里埋下了。

一个框架什么都想装进去，慢慢就会开始膨胀。

chains、agents、retrievers、memory、callbacks、tools、community integrations，全都待在同一个大叙事里。刚开始你觉得热闹，后面就会觉得有点晕。

这里面有些是应用组件，有些是执行模型，有些是平台能力，有些只是第三方适配器。

混在一起之后，开发者很容易进入一种状态。

代码能跑。

但我不知道我到底在用哪一层。

这话说出来可能有点刺耳，但我觉得这就是 LangChain 早期被很多人又爱又骂的原因。

它太有用了。

也太满了。

然后 agent 热潮来了。

ReAct 这个思路其实很简单，Reasoning 加 Acting。模型先想一下，然后决定要不要行动，行动可以是查资料、调工具、访问外部环境。工具返回观察结果，模型再继续想，再决定下一步。

听着很自然对吧。

但一落到工程里，事情就开始变味了。

链式应用的路径通常比较清楚，先检索，再总结，再输出。agent 的路径经常不清楚。模型可能这一步调搜索，下一步调用数据库，再下一步发现信息不够，又回去问用户。

它开始循环。

循环一出现，软件工程的老问题就全回来了。

状态。

恢复。

追踪。

中断。

回放。

权限。

审批。

我看到这里的时候，脑子里突然想起以前写业务系统的感觉。很多系统刚开始都像一个小脚本，产品经理说，先跑通就行。

于是你写了一个函数。

后来要加重试。

再后来要加日志。

再后来要加审批。

再后来要支持失败后从中间继续。

再后来老板说，这个流程能不能可视化一下。

这时候你回头看最早那个函数，就会有一种很熟悉的窒息感。

AI agent 也一样。

如果只是一个简单助手，LangChain 的 create_agent 足够了。给它模型，给它工具，给它 system prompt，让它跑起来。

但如果这个 agent 开始承担真实业务，它就不再只是会聊天的模型了。它变成了一个会调用工具、会等待外部结果、会保存状态、会被人类打断的执行系统。

执行系统，就需要运行时。

LangGraph 就是在这个地方长出来的。

它的建模很克制，state、nodes、edges。

节点做事，边决定流向，状态贯穿整个过程。

听起来像废话，甚至有点老派。

但这个老派，恰恰是它最重要的地方。

因为 LangGraph 做的事情，是把 agent 那个看起来很魔法的循环，放回一个工程师能理解的结构里。

模型输出 AIMessage，里面可能带着 tool_calls。

工具执行完，返回 ToolMessage，里面带着对应的 tool_call_id。

模型读完整个消息历史，再决定下一步。

这时候 AIMessage 和 ToolMessage 就不是一些无聊的类名了。

它们是协议。

它们告诉系统，这个动作是谁发起的，这个结果回应的是哪一次动作，这一步应该怎么被记录，怎么被恢复，怎么被追踪。

很多人第一次看 LangGraph，可能会觉得，怎么做个 agent 还要画图，太重了吧。

我非常理解这种感觉。

你只是想让模型调用几个工具，为什么要学 state，学 node，学 edge，学 conditional edge？

你只是想做一个小助手，为什么突然被迫进入编排运行时的世界？

所以这里有一个很重要的判断。

别一上来就写 LangGraph。

真的别。

如果你只是要做一个能查资料、能调几个 API、能返回答案的 agent，就先用 LangChain create_agent。它就是入口。

只有当你开始遇到那些很烦、很真实、很生产的问题，再下沉到 LangGraph。

比如任务会跑很久。

比如工具调用之间有依赖。

比如中间某一步要人工审批。

比如失败后要从 checkpoint 恢复。

比如你需要 time travel，回到某个状态测试不同 prompt。

比如你不想再把所有东西塞进一个 while loop 和几个全局变量里。

到了这个时候，LangGraph 才开始变香。

说到这里，其实就能理解 LangChain 1.0 这次变化了。

表面看，是 API 迁移，是导入路径变化，是旧功能进了 langchain-classic，是 create_agent 成了标准入口。

但往深一点看，这是一次边界重画。

LangChain 主包开始变窄。

它不再试图把所有 LLM 应用模式都塞进自己怀里。

它把自己收缩成一个更聚焦的 agent framework 和组件集成层。

复杂执行交给 LangGraph。

观测、评估、部署交给 LangSmith。

历史功能交给 langchain-classic。

这其实是一个开源项目成熟之后，很典型的动作。

早期为了增长，什么都接，什么都包，什么都欢迎。

中期开始还债，把边界切清楚，把入口做简单，把底层做稳定，把商业产品放到平台层。

这件事在技术上叫架构分层。

在产品上叫认知减负。

在开发者体感上，大概就叫，终于别让我一次性理解全部东西了。

我觉得 LangChain 1.0 最有意思的地方，也在这里。

它承认自己不能什么都做。

这反而是一种成熟。

以前的 LangChain 像一个工具箱，什么都有，钳子、锤子、胶带、电钻、螺丝刀、说明书、购物小票，全在里面。你打开的时候很兴奋，但真要找东西，会翻半天。

现在它更像一个入口。

你先用最简单的方式把 agent 搭起来。

如果只是小任务，就停在这里。

如果复杂了，再往下走。

下面那层，就是 LangGraph。

这个分层对于 AI 应用开发很重要，因为 agent 框架最怕的不是能力少。

最怕的是每个用户都被迫理解全部层级。

一个刚入门的人，只想写一个工具调用助手，你让他理解 checkpoint、interrupt、time travel，他会直接跑掉。

一个做企业流程的人，需要审批、恢复、追踪，你只给他一个轻量 agent harness，他会在项目后期被状态管理折磨到怀疑人生。

所以好的框架分层，应该允许用户停在合适的位置。

能跑，就停在 LangChain。

要可控，就下沉 LangGraph。

要评估和观测，就接 LangSmith。

这才是一个比较健康的路径。

顺着这个再看横向竞争，就更清楚了。

AutoGen 的气质很明显，它更像多智能体协作实验室。多个 agent 对话、分工、协商，特别适合研究型任务和多角色系统。

CrewAI 更产品化。Agent 是角色，Crew 是团队，Task 是任务，Process 是流程。对很多业务自动化团队来说，这套词汇更好懂，也更像他们平时理解组织协作的方式。

LlamaIndex Workflows 很 Pythonic。它用 event-driven steps 来描述 workflow，和 LlamaIndex 的数据、索引、RAG 生态衔接很自然。

Haystack 的基本盘仍然是 RAG pipeline。检索增强、文档问答、生产级 RAG，这是它长期积累的优势。

LangChain 和 LangGraph 的组合，走的是另一条路。

LangChain 把开发者留在组件和入口层。

LangGraph 把复杂执行放进状态图运行时。

LangSmith 再把 tracing、evaluation、deployment 补上。

这条路的野心其实挺大。

它想让你从一个最小 agent，一路走到企业级 agent runtime。

当然，这条路也有风险。

LangGraph 的图模型，对初学者确实有心智负担。你做一个很小的任务，强行上图，会觉得像杀鸡用火箭。

而且竞品都在从不同方向降低复杂度。CrewAI 用业务角色降低理解门槛，LlamaIndex Workflows 用事件和普通 Python 降低代码门槛，AutoGen 用对话式 multi-agent 降低概念门槛。

所以 LangGraph 未来最大的挑战，可能不是功能够不够。

它的挑战是，能不能让开发者在真正需要它的时候，觉得这套复杂性是值得的。

这句话很关键。

复杂性本身不可怕。

不合时宜的复杂性，才可怕。

你让我为了一个 demo 去理解状态图，我会烦。

你让我为了一个要跑半年、要审计、要恢复、要人工审批的企业 agent 去理解状态图，我会感谢你。

因为那时候我知道，我迟早要面对这些问题。

LangGraph 只是把这些问题提前摊在桌面上。

这让我想起 1880 年代电力刚进入工厂的时候。

很多工厂主一开始只是把蒸汽机换成电动机，机器布局、生产流程、管理方式都没变。结果效率提升并没有想象中那么夸张。

真正吃到电力红利的人，是后来意识到，电力不只是一个更方便的动力源，它会改变整个工厂的组织方式。

AI agent 现在也有点像这个阶段。

如果你只是把模型塞进原来的软件流程里，它当然有用。

但当模型开始自己决定下一步，开始调用工具，开始参与流程控制，开始在长任务里保存状态，整个软件系统的组织方式就会变。

这时候你需要的，就不只是一个模型调用库了。

你需要新的运行时。

这也是为什么我觉得，LangGraph 的出现不是偶然的。

它是 agent 从 demo 走向生产时，被现实逼出来的东西。

一开始大家都喜欢魔法。

模型自己思考，自己行动，自己调用工具，哇，好酷。

但真正做系统的人，到头来都会回到几个很朴素的问题。

出了错，能不能查。

断了，能不能恢复。

危险操作，能不能拦。

状态变化，能不能看。

版本迭代，能不能回放。

这些问题一点都不性感。

但它们决定一个 agent 能不能从玩具变成系统。

大时代啊，朋友们。

所以如果你问我，今天到底应该怎么学 LangChain 和 LangGraph，我会给一个很笨，但我觉得很稳的顺序。

先理解 messages、tools、tool calling、structured output。

然后理解 ReAct loop，模型发出 AIMessage.tool_calls，工具执行，返回 ToolMessage，模型继续读消息历史。

再用 LangChain create_agent 搭一个最小 agent。

先别急着上复杂架构。

等你真的遇到状态、分支、恢复、人工介入，再去学 LangGraph 的 state、node、edge、conditional edge。

再往后看 persistence、interrupt、time travel、LangSmith tracing。

这条路不酷。

但很省命。

因为它符合一个很朴素的软件工程原则，先让东西跑起来，再让它变得可控。

LangChain 对应前半句。

LangGraph 对应后半句。

我梳理完之后，最大的感受其实不是某个框架赢了。

而是 AI 应用开发终于开始从兴奋期，进入还债期。

早期大家忙着证明，大模型能接工具，能查资料，能写代码，能自动完成任务。

现在大家开始认真面对，自动完成任务之后，系统怎么治理。

怎么记录。

怎么恢复。

怎么让人类在关键时刻插手。

怎么把不稳定的模型行为，放进一个可管理的工程结构里。

这件事听起来没有那么热闹。

但它很重要。

因为所有真正改变世界的技术，到头来都会从魔法变成基础设施。

互联网如此。

云计算如此。

电力也如此。

AI agent 大概率也会如此。

一开始我们惊讶于它会说话。

后来我们惊讶于它会调用工具。

再后来，我们会越来越少惊讶。

我们会开始问更无聊的问题。

它稳吗？

它能恢复吗？

它能审计吗？

它能长期维护吗？

它能成为系统的一部分吗？

到那个时候，LangChain 变窄，LangGraph 变重，就不是一件奇怪的事了。

那说明这个行业，终于开始认真了。

说实话，我很喜欢这个变化。

因为它没有继续沉迷于把所有东西都叫 agent。

它开始把入口、运行时、观测平台、历史功能拆开。

拆开之后，很多东西反而更清楚。

LangChain 是你上车的地方。

LangGraph 是你开进复杂路况之后，真正需要的底盘。

LangSmith 是你看仪表盘、查事故记录、做长期维护的地方。

这么看，LangChain 和 LangGraph 并没有抢位置。

它们是在回答同一个问题的不同阶段。

我怎样更快搭一个 agent。

这个 agent 复杂起来以后，怎样不失控。

前一个问题，属于兴奋。

后一个问题，属于认真。

而 AI 应用开发，正在从兴奋，走向认真。