故事是这样的。我这两天梳理 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 的 demoLangChain 往往能帮你少写很多样板代码。但问题也在这里埋下了。一个框架什么都想装进去慢慢就会开始膨胀。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就先用 LangChaincreate_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模型继续读消息历史。再用 LangChaincreate_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 应用开发正在从兴奋走向认真。