最近半年只要你刷开发者社区基本都能看到类似说法LangChain 死了。LangGraph 太重了。真正做 Agent 的团队都在把它们移除。然后评论区马上会冒出一堆替代方案Pydantic AI。CrewAI。Claude Agent SDK。OpenAI Agents SDK。或者更直接一点别用框架直接调 API。听起来很热闹。但问题是LangChain 和 LangGraph 真的死了吗答案没那么简单。更准确地说它们不是“死了”。而是当初它们解决的问题已经变复杂了两倍。所以今天真正的问题不是LangChain 还能不能用而是2026 年你到底该用什么发现一个低成本 AI 平台GPT-5.6 倍率0.05 Claude Code 4.8 都能用倍率 0.25还支持 image-2 生图。适合 Codex / Claude Code 用户。LangChain 当初为什么会出现时间回到 2023 年。那时候 ChatGPT 刚刚爆火。每个开发者突然都想做一个“带 AI 的应用”。但真正坐下来写的时候你很快会发现调用 LLM API 很简单。发一个 HTTP 请求。拿一个回答回来。完事。但真实 AI 应用根本不是一次请求就能解决的。一个稍微有用的 AI 应用往往需要做这些事先根据用户问题从公司内部文档里找相关资料再回答。这就是 RAG。记住用户三轮之前说过什么。这就是 memory。判断要不要搜索网页、查数据库还是直接回答。这就是 tool use。如果第一次回答不好再换一种方式重试。这就是 loop。今天接 OpenAI明天可能要切 Anthropic但不想重写所有代码。这就是 provider abstraction。听起来都很合理。但在 2023 年初这些东西基本都不在模型 API 里。OpenAI 给你的就是一个chat.completionsendpoint。你要 RAG、memory、tools、retry、parser、vector DB、prompt template就得自己一遍遍写。所有人都在写同样的样板代码。连接向量数据库。切文档。格式化 prompt。解析输出。处理重试。LangChain 就是为了这个问题出现的。LangChain 是怎么火起来的2022 年底Harrison Chase 还在 Robust Intelligence 做 ML 工程师。这家公司主要做生产环境里的机器学习模型测试和验证。换句话说他见过很多 ML 系统在真实世界里怎么坏掉。这件事后来反而成了很好的准备。2022 年 10 月在公司一次 hackathon 里他做了一个 bot可以查询 Notion 和 Slack 里的内部数据。那正好是 ChatGPT 发布前一个月。他其实提前撞上了整个行业接下来都会需要的模式把 LLM 接到自己的数据和工具上。2022 年 10 月 24 日他第一次发推介绍这个项目。他把它叫做 LangChain。也就是 Language Model Chains。随后开源MIT 协议。有意思的是ChatGPT 大约一个月后发布。然后所有想做 AI 应用的开发者突然发现 GitHub 上已经有一个项目正好在解决他们眼前的问题。LangChain 到底是什么一句话说LangChain 是一个 Python后来也支持 JavaScript 的库给开发者提供了一堆搭 AI 应用的乐高积木。核心思想就在名字里把涉及 LLM 的步骤串成一条 chain。一个典型 chain 可能是这样用户输入 → 从向量数据库拉相关文档 → 把文档塞进 prompt template → 发给 LLM → 解析输出 → 返回给用户LangChain 给每一步都提供了类和函数。然后再提供一种方式把它们粘起来。它还提供了各种适配器。比如你想用 Pinecone 当向量数据库有 wrapper。下周想换 Weaviate接口差不多底层 wrapper 换掉就行。LLM provider 也是类似。OpenAI、Anthropic、Cohere、本地模型都可以套进去。文档加载器也一样。PDF、Notion、Google Drive、网页抓取都有对应模块。在 2023 年这个抽象非常有用。因为那时候大家最需要的就是快速把这些零散能力拼起来。后来事情变了LangChain 确实很火。但到了 2024 年中Harrison Chase 和团队遇到了一个靠“多加 integration”解决不了的问题。LangChain 的成功把它带进了它最初并不擅长的场景。它最初的心智模型是 chain。也就是一条从输入到输出的直线。这非常适合 2023 年那波“和 PDF 聊天”的应用。但很快团队开始做更复杂的东西Agent 可以连续思考好几分钟。反复调用工具。把任务交给另一个 Agent。中途暂停等人类批准。批准后再从原位置继续。这已经不是一条直线了。而是一张流程图。这时候问题开始出现。Octomind 是一家 YC 公司曾经把整个产品搭在 LangChain 上。2024 年他们发了一篇复盘解释为什么最后把 LangChain 移除了。核心问题是他们需要根据 Agent 已经发现的信息动态改变它可以使用的工具。但 LangChain 没办法让他们在运行中检查或修改 Agent 状态。最后他们只能把产品能力降级以适配框架。这件事在开发者社区影响很大。因为很多认真做 Agent 的团队都在撞同一堵墙。LangChain 的线性模型不够用了。于是LangGraph 出现了。LangGraph从 Chain 变成 GraphLangGraph 在 2024 年初发布2025 年 10 月正式公开可用。名字的变化其实就是思想的变化。LangChain 是 chain。一条直线。LangGraph 是 graph。一张由节点和箭头组成的图。图可以循环。可以分支。可以暂停。可以根据条件决定下一步。它的心智模型是这样的在 LangChain 里你描述的是一个菜谱先做 A。再做 B。然后做 C。最后返回结果。在 LangGraph 里你描述的是一张地图节点负责执行工作。边负责决定下一步去哪里。箭头可以往回指。如果 B 的结果不好可以回到 A。箭头可以分叉。A 可以根据用户问题把任务交给 B、C 或 D。节点也可以暂停。比如等人类点击 approve再继续执行。想象一个医疗 App 的客服 Agent。用户发来一个很模糊的投诉。在 LangChain 世界里你可能会写一个线性流程分类问题 → 查询用户 → 获取近期记录 → 生成回复 → 发送如果第一步分类错了后面流程可能已经继续跑下去了。但在 LangGraph 世界里你会把它建成一张图。第一步triage 节点判断问题类型并路由到三个专家节点之一。第二步专家节点拉取数据、起草回复然后路由到 approval 节点。第三步approval 节点暂停整个 Agent等待人类审核。如果人类拒绝图会带着拒绝原因回到专家节点重新生成。如果中途任何地方失败你可以两天后重新打开这个 Agent看到每一步做了什么并从某个 checkpoint 恢复。这就是 LangGraph 的强项。LangGraph 今天适合什么它适合这些场景多 Agent 系统。比如研究 Agent 把发现交给写作 Agent写作 Agent 再交给 critic Agentcritic 再打回去修改。长时间运行的 Agent。任务不是几秒而是几分钟、几小时。比如 Claude Code、Devin 式 coding agent、deep research 类产品都使用了 LangGraph 风格架构。有些直接用 LangGraph有些自己实现了类似思想。需要 human-in-the-loop 的流程。医疗、金融、法律这类领域里很多动作不能让 AI 直接执行必须有人类审批。复杂客服流程。Agent 需要升级、重试、分支简单 chain 表达不了。研究分析型 Agent。需要先计划再执行再评估结果再决定继续还是换策略。所以说 LangGraph 没用肯定不对。但说它适合所有人也不对。那为什么大家说它“死了”因为现在生态变了。Anthropic 发布了 Claude Agent SDK。OpenAI 发布了 Agents SDK。AWS 开源了 Strands。越来越多 provider 把原本框架层才有的能力直接做进了官方 SDK。比如状态管理。工具调用。子 Agent。handoff。guardrails。MCP。computer use。上下文管理。也就是说2023 年你必须依赖第三方框架做的很多事情2026 年已经可以从模型提供商那里直接拿到。这让 LangChain 的存在感变弱了。但还有一个更关键的变化大家都在争论 LangChain 会不会被替代时LangChain 公司自己已经把重心移到了另一个东西上。2025 年 10 月他们以 12.5 亿美元估值融资 1.25 亿美元。真正推动这轮融资的产品不是 LangChain。也不是 LangGraph。而是 LangSmith。也就是他们的可观测性平台。更重要的是LangSmith 可以和他们不拥有的框架一起工作。这说明 LangChain 公司也看清楚了框架之争不会只有一个赢家。但所有 Agent 系统都需要观测、调试、评估和追踪。这才是更大的生意。2026 年到底该用什么如果今天重新开始一个 LLM 项目我会优先考虑下面这 7 个方向。不是说其他框架不能用。而是这些更值得认真评估。第一类Provider-native SDK这是现在大多数团队的新默认起点。模型提供商已经把很多一方工具做进官方 SDK。很多场景下你可以直接跳过框架层。1. Claude Agent SDK这是 Anthropic 官方用于构建 Claude Agent 的 SDK。它从 Claude Code 中抽取出来而 Claude Code 正是 Anthropic 自己的 coding agent 产品。它原生支持tool use。MCP。computer use。extended thinking。context management。如果你已经决定主要使用 Claude这会是摩擦最小的路径。为什么用它它非常适合长周期 Agent。尤其是那种需要读文件、跑代码、操作电脑、跨多轮管理上下文的 Agent。MCP 是原生集成。接工具真的可以很简单。如果你已经押注 Claude这就是最直接的生产 Agent 路线。为什么不用它它锁定 Anthropic。如果你需要多个模型并行或者未来随时切 provider你就得为其他模型重新实现 harness。另外对简单 chatbot 或单轮应用来说它太重。这种场景直接调 Messages API 就够了。怎么开始pip install claude-agent-sdkAnthropic 文档里有 quickstart几十行代码就能跑一个带 tool use 的 Agent。Claude Cookbooks 里也有常见 Agent 模式的参考实现。2. OpenAI Agents SDK这是 OpenAI 的生产级 Agent 框架从早期实验项目 Swarm 演进而来2025 年 3 月发布。它特别关注多 Agent 协作。一个 Agent 可以 handoff 给另一个 Agent。session 自动追踪。guardrails 可以验证输入输出。为什么用它如果你主要用 OpenAI 模型这是目前多 Agent ergonomics 最舒服的选择之一。handoff 是一等公民。你可以声明一个 triage agent让它把用户路由给 billing agent 或 tech-support agentSDK 负责处理协议。内置 tracing 也很适合开发调试。至少早期不用马上接一套额外 observability 工具。为什么不用它它也锁 OpenAI。而且它的 handoff 模型比较有主见。如果你的架构需要的是 graph而不是树状 Agent handoff它未必完全匹配。内置 tracing 适合开发阶段但大多数生产团队最后还是会叠一层专门的可观测性平台。怎么开始pip install openai-agentsOpenAI 文档里有一个多 Agent 客服 bot 教程大约 30 分钟可以跑起来。这个例子很适合作为第一项目因为它直接覆盖 handoff 模式。3. AWS Strands AgentsStrands 是 AWS 开源的 Agent 框架。它和 Amazon Bedrock、AgentCore 集成得很深。但它并不是只能用 AWS 模型。它支持 Bedrock、Anthropic、OpenAI、Ollama以及任何 OpenAI-compatible 接口。为什么用它如果你的基础设施已经在 AWSStrands 很值得看。AgentCore 可以处理部署、扩缩容、监控这些运行层问题。否则你要自己把这些全接起来。而且它的模型层是相对开放的不会因为 AWS 品牌就只能绑定 Bedrock。为什么不用它如果你不在 AWS集成价值会少很多。那你就只是在选一个框架本身。这时其他方案可能 momentum 更强。另外它的文档还在完善中相比 Claude Agent SDK 或 OpenAI Agents SDK成熟度略弱一些。怎么开始pip install strands-agentsAWS 的 Strands 文档有用 Bedrock 做 inference 的教程但你可以在配置里换成其他模型。第二类编排框架当一个简单 Agent loop 不够时你就需要这类框架。它们适合显式状态、分支逻辑、人类审批、多 Agent 协调等场景。Provider SDK 适合简单场景。编排框架适合真正变复杂的场景。4. LangGraphLangGraph 是 LangChain 团队推出的图式编排框架。它把 Agent 建模成节点和边的网络。节点负责工作。边负责转移。状态可以 checkpoint、检查和恢复。它的月下载量已经非常高说明生产使用并不少。为什么用它如果你需要 stateful、branching、human-in-the-loopLangGraph 依然是非常强的答案。比如你的 Agent 需要执行不可逆操作前暂停审批。根据发现的信息条件路由。把状态持久化到磁盘几小时后继续。从任意 checkpoint 恢复。这些都是 LangGraph 的一等能力。它适合复杂工作流。尤其是那些不能只靠一个 while loop 解决的 Agent。为什么不用它如果你的应用只是一个简单 loop它可能过重。学习曲线也是真的。你要用节点、边、状态 schema 来思考。这比直接调 SDK 高一个复杂度。另外如果你不小心引入太多 LangChain 包也可能带来你不想要的依赖。怎么开始pip install langgraphLangGraph 文档里的客服 Agent 教程值得看。它包含 handoff 和 approval steps比玩具例子更能体现框架价值。5. Pydantic AIPydantic AI 来自 Pydantic 团队。它是一个类型化、轻量的 Agent 框架。Pydantic 本身就是很多 Python 开发者已经在用的类型验证库。所以这个路线很自然。为什么用它因为它代表一种思路我宁愿要类型也不要魔法。你用 Python 类型对象描述 Agent 的输入输出。用 typed function 定义工具。框架负责和 LLM 交互。没有 chain。没有 graph。没有一堆你必须先理解的抽象。就是类型化代码只是它会调用 LLM。如果你曾经被 LangChain 的 output parser 折磨过Pydantic AI 可能就是你当时想要的东西。为什么不用它它没有一等多 Agent 图模型。如果你需要显式状态机、human-in-the-loop、复杂分支你就要自己在它上面搭。另外它目前主要是 Python 路线。TypeScript-first 团队不一定适合。怎么开始pip install pydantic-ai官方文档里的 first-agent 示例十分钟就能跑完能很快感受到 typed approach 的风格。6. CrewAICrewAI 是一个基于角色的多 Agent 框架。你定义一组 Agent。比如 researcher、writer、critic。然后 CrewAI 负责协调它们。到 2025 年它已经发展到 1.14并支持 A2A protocol。为什么用它它可能是最快把多 Agent 想法做成 demo 的方式。role abstraction 很符合人类对团队的直觉。你可以很快把一个想法拆成“研究员、写作者、审稿人”这样的协作流程。它适合内容生产。研究任务。报告生成。那些天然适合“专家团队”心智模型的问题。为什么不用它让它快速上手的角色抽象也会限制你对执行细节的控制。很多生产团队后期可能会撞到类似 LangChain 的问题框架自己的意见和你真正需要 Agent 做的事情不完全一致。这时可能会迁到 LangGraph 或 raw SDK。怎么开始pip install crewaiCrewAI 文档里有 research-and-writing crew starter。这正是它最擅长的场景。第三类研究优先方案如果你的工作介于研究和生产之间这类值得知道。7. CAMEL-AI 和 OWLCAMEL-AI 最初是 KAUST 在 2023 年的学术研究项目。它研究的问题是如果让 LLM Agent 按明确角色互相对话会发生什么这种交互能不能被大规模研究后来它逐渐变成一个生产可用的框架并支持百万级 Agent simulation。OWL 是建立在 CAMEL-AI 上的实用层。它在 2025 年的开源 general agent 评测 GAIA 上表现很强并被 NeurIPS 2025 接收。为什么用它如果你的问题更像“Agent 社会”而不是“几个 Agent 排成流程”CAMEL-AI / OWL 会更适合。比如大规模合成数据生成。Agent simulation。多 Agent 研究任务。跨环境自动化。它的 synthetic data pipeline 也很实用。包括 Chain-of-Thought、Self-Instruct、Source2Synth以及 verifier。这更接近真实研究工作流而不是简单产品框架。为什么不用它对普通产品工程来说它太重了。如果你要在三周内上线一个客服 Agent不该选它。它首先是研究工具。只是它也具备生产能力。不是反过来。怎么开始pip install camel-aiCAMEL-AI 文档里有 role-playing 示例展示两个 Agent 如何协作完成任务。OWL 也有单独 quickstart偏生产化能力。那 AG2、Semantic Kernel、smolagents、Haystack、LlamaIndex 呢它们不是不能用。只是这篇没有把它们放进主清单。原因是它们更偏特定生态或特定场景。比如Haystack 更适合欧洲合规和 RAG-heavy 场景。LlamaIndex 很适合以 RAG 为核心的应用。Semantic Kernel 对 .NET 团队更自然。smolagents、AG2 也都有自己的用户群。如果你的上下文刚好匹配这些 niche它们当然值得看。但如果从一个新 LLM 项目通用选型出发前面 7 个更值得优先评估。到底怎么选可以简单按这个逻辑如果你已经确定只用 Claude优先看 Claude Agent SDK。如果你确定只用 OpenAI并且需要多 Agent handoff看 OpenAI Agents SDK。如果你在 AWS 上部署和运维看 Strands Agents。如果你需要复杂分支、状态、审批和恢复看 LangGraph。如果你想要轻量、类型安全、少魔法看 Pydantic AI。如果你想快速做多 Agent 原型看 CrewAI。如果你做研究、仿真、合成数据和大规模 Agent 实验看 CAMEL-AI / OWL。最后LangChain 没有简单地“死”。它只是从那个所有人都需要的万能入口变成了一个不再适合所有问题的旧默认。LangGraph 也没死。它依然是复杂 Agent 编排里非常强的工具。但 2026 年的现实是Provider-native SDK 变强了。Agent 编排场景变复杂了。可观测性变成刚需了。团队开始更在意控制权、类型、状态、部署和调试。所以今天做 LLM 应用不要再问哪个框架最火应该问我的 Agent 到底有多复杂我是否需要多模型是否需要长期状态是否需要人类审批是否要部署在 AWS是否要强类型是否只是快速验证 demo框架不是信仰。框架是代价。能用原生 SDK 解决就别上重框架。需要复杂状态和分支时也别硬用简单 loop。真正成熟的 2026 AI 工程选型不是追新名词。而是知道每个工具适合什么又会在哪一步开始拖你后腿。
