梦兽编程™AI 套装 
每隔几个月，「LangChain 已死」就会换一种说法在开发者圈子里流行一次：LangChain 太臃肿、LangGraph 太重、正经团队都在往外拆。而另一组数据是：2025 年 10 月，LangChain 公司宣布拿到 1.25 亿美元融资，估值 12.5 亿美元——这轮估值背后真正赚钱的产品，不是 LangChain，也不是 LangGraph，是 LangSmith。
两件事都是真的。这本身就说明「X 框架已死」这种争论问错了问题。
这篇文章把整件事从头讲一遍：LangChain 当年解决了什么真问题，链条（chain）模型为什么撑不住 Agent，LangSmith 的崛起说明了什么，以及 2026 年这个时间点上，新起一个 LLM 项目我会怎么选。文中框架事实参考了一篇 2026 年 6 月的 Medium 热文和各家官方文档，判断和踩坑结论是我们自己的。
2023 年的 LangChain，解决的是真问题
先把时间拨回 2023 年初。ChatGPT 刚炸场，每个开发者都想做一个「带 AI 的应用」，但真坐下来写，你会发现裸调模型 API 只能解决一半问题。
OpenAI 给你一个 chat.completions 端点：发一个 HTTP 请求，拿一个回复。可一个真正能用的 AI 应用要做的远不止这些：
- 回答之前先查公司内部文档——这就是 RAG；
- 记住用户三轮之前说过的话——这是记忆；
- 自己决定是搜网页、查数据库还是直接答——这是工具调用；
- 第一版答案不行，换个思路再来一遍——这是循环；
- 今天接 OpenAI，明天想换 Anthropic 但不想重写——这是 provider 抽象。
2023 年初，这些东西模型 API 里一样都没有。每一样都得自己从零写，而且所有人写的都是同一套样板代码：连向量库、切文档、拼 prompt、解析输出、处理重试。
LangChain 就是冲着这个问题去的。创始人 Harrison Chase 当时是 Robust Intelligence 的 ML 工程师，2022 年 10 月在公司 hackathon 上做了一个能查 Notion 和 Slack 内部数据的机器人，当月就把项目开源，MIT 协议，取名 LangChain——Language Model Chains。一个月后 ChatGPT 发布，整个行业的开发者突然发现 GitHub 上正好躺着一个现成的答案。
它做的事一句话就能说清：把上面那些重复劳动做成预制积木。一条典型的 chain 就是：接收输入 → 从向量库检索 → 填进 prompt 模板 → 发给模型 → 解析输出 → 返回给用户。每一步都有现成的类；向量库（Pinecone、Weaviate）、模型厂商（OpenAI、Anthropic、本地模型）、文档加载器（PDF、Notion、网页）全有适配器。
现在回头看，LangChain 常被打上「过度设计」的标签。我的看法不太一样：它是 2023 年最务实的答案。你可以批评它后来膨胀了，但说它解决的问题是假的，这不公平——那些问题每一个都是真的，而且到今天依然存在。
链条模型为什么撑不住 Agent
LangChain 的默认心智模型是一条直线：A → B → C → 返回。这个形状完美匹配 2023 年那波「跟你的 PDF 聊天」的应用。但 2024 年开始，团队要造的东西变了：能让模型思考几分钟、反复调工具、和其他 Agent 交接、中途暂停等人类点头、然后从断点继续的 Agent。
直线装不下这些东西。
一个典型的翻车案例是 Octomind——一家把整个产品建在 LangChain 上的 YC 公司，2024 年发了一篇 postmortem 讲他们为什么把它拆掉了。核心问题一句话：他们需要根据 Agent 已经发现的东西动态改变它能用的工具，而 LangChain 在运行中既看不到也改不了 Agent 的状态。他们最后的选择是降低产品复杂度去迁就框架。这篇 postmortem 当时在开发者社区传得很广，因为所有认真做 Agent 的人都撞过同一堵墙。
我们自己写多 Agent 运行器（runner）时撞的也是这堵墙。一个长任务跑起来之后，「它现在进行到哪一步、手里握着什么状态、哪一步失败了」必须能被外部检视，甚至能被人工修改后继续——这不是锦上添花，是生产环境的底线要求。
Chase 团队的答案是换一个形状。在 LangChain 里你把应用写成菜谱：先 A，再 B，再 C；在 LangGraph 里你把应用写成地图。节点干活，边决定下一个去哪个节点；箭头可以往回指——输出不行就回到上一个节点重来；可以分叉——按用户意图路由到不同分支；可以暂停——整个人停下来，等人工点下「批准」再继续。配合 checkpoint，Agent 跑了两天之后，你可以把它的完整状态翻出来，从任意一个检查点续跑。
LangGraph 在 2024 年初推出，如今月下载量已是数千万级（原文数据为 4700 万+）。方向上我认为是对的：把状态从框架的黑盒里拿出来，变成显式、可检查、可持久化的东西。
「已死」叙事的另一面：LangSmith 才是产品
那「已死」的说法从哪来？如果你在开发者 Twitter 上逛，过去半年每隔几周就能看到一轮：LangChain 死了、LangGraph 太肿、大家都改用 Pydantic AI、CrewAI、Claude Agent SDK、裸 API 了。
而与此同时，LangChain 公司拿了 1.25 亿美元（公开报道，2025 年 10 月）。驱动这轮估值的不是 LangChain，也不是 LangGraph，是 LangSmith——一个可观测性平台，而且它不绑定自家框架，你用别的框架也能接。
这两组事实放在一起，我的解读是：框架本身从来都不是最值钱的那层。真正值钱的是运行数据——一次 Agent 运行里每一步做了什么、调了什么工具、花了多少 token、在哪一步失败，能不能被记录、回放和审计。LangSmith 恰好站在这一层，所以它既配得上融资，也不在乎你用什么框架。
我们自己的生产系统跑过多模型调度，对这点体会很直接：Agent 出问题的时候，第一优先级永远不是「换个框架」，而是「把当时的状态原样拿出来看」。做不到这点的系统，换什么框架都没用。
所以「LangChain 已死」是个伪命题。真正值得问的问题是：你的状态归谁管？能不能被检视？这才是选型的分水岭。
2026 年的框架格局：三大类七个选项
下面是我会认真考虑的七个选项，按三大类分。先说量它们的尺子，不是功能列表，而是三样东西：
- 状态是否显式、可检视、可恢复；
- provider 能不能换，换的成本多大；
- 抽象本身够不够薄——框架不应该比你的业务逻辑还重。
第一类：厂商原生 SDK
模型厂商已经把一等公民的工具做进自家 SDK，很多场景下可以直接跳过框架层。
Claude Agent SDK。Anthropic 的官方 Agent SDK，从 Claude Code 里提炼出来，原生支持工具调用、MCP、computer use 和长上下文管理。模型锁定 Claude 的前提下，这是摩擦最小的路径——接 MCP 工具真的是几行代码。代价是绑定 Anthropic；而且如果应用只是简单聊天，直接调 Messages API 就够了，用它属于杀鸡用牛刀。上手：pip install claude-agent-sdk，官方 quickstart 五十行内能跑起一个带工具的 Agent。
OpenAI Agents SDK。2025 年 3 月发布，从实验项目 Swarm 演化而来。handoff——一个 Agent 把任务交给另一个 Agent——是一等公民，配 guardrails 和内置 tracing。OpenAI 生态下做多 Agent 分工最顺手的选项。缺点同样明显：绑定 OpenAI；交接是树状的，你想要图状路由时会别扭；内置 tracing 撑开发可以，生产大概率还是要接专业可观测层。上手：pip install openai-agents，官方文档有个约三十分钟的多 Agent 客服机器人教程。
AWS Strands Agents。AWS 的开源 Agent 框架，跟 Bedrock 推理、AgentCore 托管部署打通。别看是 AWS 家的，它模型无关：Bedrock、Anthropic、OpenAI、Ollama 都支持。基础设施本来就在 AWS 上的团队，AgentCore 把部署、扩缩、监控这些运维层省掉，这是很实在的价值。但不在 AWS 上，它的集成故事就掉价大半，文档厚度也不如前两家。上手：pip install strands-agents。
第二类：编排框架
单个 Agent 循环不够用时——需要显式状态、条件分支、人工审批门、多 Agent 协调——才轮到这一层。
LangGraph。LangChain 团队的图编排框架：节点干活、边走流程、状态可 checkpoint 可恢复。在「有状态 + 分支 + human-in-the-loop」这个象限里，它仍是场上最干净的答案，Claude Code、Devin 这类产品的部分架构用的就是同一思路。代价是学习曲线真实存在——得习惯用节点、边、状态 schema 思考，比直接调 SDK 高一个台阶；而且 import 不小心会拖进一堆 LangChain 依赖。上手：pip install langgraph，官方教程直接带你做一个带交接和审批的客服 Agent，比玩具例子更能体会它的长处。
Pydantic AI。Pydantic 团队做的类型化 Agent 框架，2024 年底发布。哲学是「我要类型，不要魔法」：输入输出是类型化 Python 对象，工具是类型化函数，没有 chain、没有 graph、没有需要专门学习的抽象。调试过 LangChain output parser 的人，懂我在说什么。短板：没有一等公民的多 Agent 图模型，要状态机或人工审批分支得自己搭；而且只有 Python，TypeScript 团队无缘。上手：pip install pydantic-ai，十分钟能过完第一个 Agent 例子。
CrewAI。基于角色的多 Agent 框架：定义一个研究员、一个写手、一个审稿人组成 crew，框架负责协调，v1.14 起支持 A2A 协议。它是把多 Agent 点子跑起来最快的方式——从想法到能演示的 demo，一个下午够了。内容工作流、调研任务这类「专家团队」心智模型对得上的场景很顺。代价是：让原型快的那个角色抽象，也正是规模化时控制力的天花板，不少团队最后在规模化阶段迁去 LangGraph 或裸 SDK。上手：pip install crewai。
第三类：研究优先
CAMEL-AI（含 OWL）。2023 年起源于 KAIST 的学术项目，研究的问题是「LLM Agent 在定义好的角色下互相交谈会发生什么」，如今进化成能撑起百万级 Agent 仿真的生产级框架。OWL 是上面的实践层，2025 年在 GAIA 基准的开源通用 Agent 里拿到第一（原文口径）。如果你的问题长得像「Agent 社会」——大规模合成数据、Agent 仿真、多 Agent 研究负载——它是七个选项里最强的。反过来，如果目标是一个三周内要上线的产品功能，别选它：它是研究优先、恰好能生产，不是反过来。上手：pip install camel-ai。
你没在这个清单里看到 AG2、Semantic Kernel、smolagents、Haystack、LlamaIndex，不是它们不行——Haystack 在欧洲合规场景、LlamaIndex 在重 RAG 应用、Semantic Kernel 在 .NET 体系里各自有一席之地——而是它们的适用面要么偏窄，要么还没有上面这七个的生产动量。如果你的场景恰好落在某个窄领域里，选那个窄领域的专家没毛病。
我的选型建议
把话说简单点。下面这张表是我会给自己团队用的，你对号入座：
| 你的场景 | 我的选择 |
|---|---|
| 单轮问答、简单聊天 | 别上框架，直接调模型 API |
| 锁定 Claude 的长程任务（编码、操作电脑） | Claude Agent SDK |
| OpenAI 生态的多 Agent 分工 | OpenAI Agents SDK |
| 基础设施在 AWS | Strands Agents |
| 有状态、要分支、要人工审批、要断点续跑 | LangGraph |
| 喜欢类型化、以单 Agent 为主 | Pydantic AI |
| 快速验证多 Agent 点子 | CrewAI（预留迁移后路） |
| 研究、仿真、合成数据 | CAMEL-AI / OWL |
最后泼一盆冷水：表里没有任何一行是「永远正确」的。框架选型真正的分水岭，还是前面那把尺子——状态归谁管、能不能换 provider、抽象够不够薄。用这三把尺子量，答案通常自己会长出来。
在中国落地这些方案
上面七个选项里，有两个对中国团队有现实的接入门槛：Claude Agent SDK 和 OpenAI Agents SDK 默认你能稳定访问对应厂商的 API，这对国内网络环境不是默认成立的。实际落地可以考虑三条路：
- OpenAI-compatible 端点接国产模型。LangGraph 和 Pydantic AI 都支持自定义 base_url，把端点指向 DeepSeek、通义千问或智谱 GLM-5 等已支持工具调用的国产模型，请求体结构基本一致，改动量很小。
- 本地推理。用 Ollama 部署开源模型（如 Qwen 系列），编排层保持不变，完全不依赖外网。
- 转发网关。公司已有 API 转发或网关服务的，把 SDK 的端点指向网关即可，上游换哪家对业务代码透明。
我们的实际体会是：provider 层越不确定——账号、网络、价格、断供——越应该选对 provider 依赖最薄的那一层。这也是为什么我们自己的调度服务能在多家上游之间切换：状态在自己手里，换 provider 就只是改配置。
常见问题
LangChain 真的死了吗？
没有。「已死」更多是开发者社区的叙事。2025 年 10 月 LangChain 公司还拿到了 1.25 亿美元融资（估值 12.5 亿），驱动估值的产品是 LangSmith 可观测平台，而不是框架本身。框架仍在维护，月下载量数千万级。
新项目应该直接用 LangChain 吗？
大概率不应该。简单场景直接调模型 API；有状态、分支、人工审批需求的上 LangGraph；喜欢类型化的选 Pydantic AI。LangChain 原始的 chain 抽象，适合的是 2023 年那种「检索 → 拼 prompt → 调模型」的直线流程。
LangGraph 和 LangChain 是什么关系？
同一个团队的两个产品。LangChain 把应用建模为直线链条（A→B→C），LangGraph 把应用建模为图：节点干活、边决定路由、状态可 checkpoint 和恢复，支持循环、分支和暂停等人审批。做 Agent 应该直接看 LangGraph。
2026 年做 AI Agent，不用框架行不行？
行，很多团队就是这么干的。模型厂商的官方 SDK 已经把工具调用、MCP、tracing 做成一等公民。框架真正还值钱的场景是：显式状态、条件分支、人工审批门、多 Agent 协调。单 Agent 循环能搞定的，裸 SDK 通常更省事。
中国团队应该怎么选？
优先选 provider 依赖薄的编排层（LangGraph、Pydantic AI），用 OpenAI-compatible 端点接 DeepSeek、通义千问、智谱 GLM-5，或走 Ollama 本地推理、转发网关。Claude Agent SDK 和 OpenAI Agents SDK 在国内直连受限，落地成本高。
参考资料
- Ankita Tripathi, “LangChain and LangGraph are DEAD? So what to USE!!”, Medium, 2026-06（作者主页 ；原文存档，文中框架事实与 4700 万月下载等数据引自该文）
- LangGraph 官方文档
- Claude Agent SDK 文档
- OpenAI Agents SDK
- AWS Strands Agents
- Pydantic AI
- CrewAI
- CAMEL-AI
对 AI Agent 和 AI 编程的底层开发感兴趣？关注「全栈之巅-梦兽编程」公众号，每周更新 AI 技术深度文章与编程实战干货。
也欢迎了解 梦兽编程 AI 编程助手服务 ，帮你把 AI 编程工具真正用到日常开发里。
顺带一提：我们自己日常开发在用的 AIOS（Local-First Agent 工作流层），正好补在这篇文章反复强调的「状态归谁管」这一层——给 Codex、Claude Code、OpenCode 这些 AI 编程助手加上跨会话项目记忆、/team 多 Agent 协作，以及 aios verify 验证与隐私保护。框架负责跑任务，AIOS 负责记住状态、把关质量：cli.rexai.top