别再默认上 LangGraph

2026 年做 Agent，框架越堆越厚不是本事，把大模型当成普通组件、用经典工程手段管起来才是。

框架选型这事，很多人第一步就错了

2024-2025 年 Agent 框架爆发，LangChain、LangGraph、CrewAI、AutoGen、LlamaIndex、OpenAI Agents SDK、Pydantic AI……个个都在喊"快速构建 AI Agent"。结果是很多团队不管需求多简单，默认上了最复杂的方案。一个三步骤的客服机器人，也要搭 Graph、State、Node、Edge、Checkpoint。

框架本身没问题，是用错了地方。

LangGraph 确实强，但不是万能钥匙

2026 年 LangGraph 依然是生产级 Agent 的标杆。有向图结构决定了执行路径是显式定义的，不是让模型"猜"；checkpointing 让长任务崩溃后能精确恢复；LangSmith 的 tracing 也是业界最细的，每一步的输入输出、token 消耗、延迟都一目了然。

Q1 生产基准的数据很说明问题：4-agent 协作场景，LangGraph 消耗约 26k token，CrewAI 约 52k，AutoGen 约 42k；复杂分支任务（10+ 步骤），LangGraph 约 35k，CrewAI 约 78k，AutoGen 约 58k。错误率上 LangGraph 只有 4.7%，CrewAI 8.3%，AutoGen 12.1%。自动恢复成功率 LangGraph 89%，CrewAI 67%，AutoGen 45%。

代价是上手成本。 一个团队从零学会 LangGraph 并达到有效产出，需要 10-14 个工程师日。CrewAI 只要 2-3 天。简单场景里这笔账不划算。

CrewAI 的 Demo 爽，上生产就露馅

CrewAI 的"角色驱动"模型很直观——给 Agent 定角色、写背景故事、设目标，它们就像团队成员一样协作。Demo 确实爽，50 行代码跑起一个多 Agent 研究流水线。

但生产环境要的东西，CrewAI 给得很勉强。

生产系统需要确定字段、权限边界、失败重试、审计日志、SLA、可复现性。CrewAI 的纯自然语言协作模型，到了企业环境容易变成三件事：token 成本失控（Agent 之间"对话"消耗大量上下文，很多是"好的我来做""谢谢我来检查"之类的废话）、延迟不可预测（每个 Agent 响应时间叠加，端到端很难保证）、调试 nightmare（任务失败了，很难定位是哪个 Agent 哪一步出的问题）。

一个医疗排班的案例：CrewAI 把放射科 3-4 小时的日常排班匹配压缩了 78%，但上线第二周就出边界 case——某个医生资质证书过期，CrewAI 的"分配 Agent"没有暂停等人工确认，直接分了一个无资质的人。这个 case 在 LangGraph 里一个条件分支就能解决，在 CrewAI 里要写大量自定义 wrapper。

快速验证想法可以用 CrewAI，直接上生产要谨慎。

AutoGen 的历史任务完成了

AutoGen 在推动多 Agent 对话范式上有历史意义，"群聊"模式让 Agent 互相质疑、迭代、refine，研究型任务上确实有效。

2026 年的现实是：AutoGen 已进入维护模式，Microsoft 把资源转向 Microsoft Agent Framework；0.4 重写版本（AG2）的破坏性变更让老用户头疼；多 Agent 对话的 token 开销是 LangGraph 的 4-5 倍（一个 4-Agent 任务 AutoGen 消耗 56,700 token，LangGraph 只要 13,500）。

AutoGen 的价值是"启发"，不是"沿用"。 它证明了多 Agent 协作能解决问题，后续框架在工程化上做得更好。

新势力的正确用法

2026 年涌现了一批更轻、更聚焦的工具，它们不是"全能框架"，是"解决具体问题"：

Pydantic AI 的核心假设：Agent 的输入输出应该类型安全。用 Pydantic model 定义结构化输出，运行时做验证。适合需要严格结构化输出的场景（表单、数据提取、分类），不适合开放式对话。和 Temporal 结合后能解决长任务持久化——执行到一半 API 超时或系统崩溃，Temporal 自动恢复，精确回到断点。

Instructor 比 Pydantic AI 更轻，不是 Agent 框架，是"让 LLM 返回结构化数据"的库。封装了各 provider 的 structured output 能力，统一成 Pydantic model 接口。月下载量 300 万+，生产验证最充分。已经在用 OpenAI/Anthropic SDK、只需要结构化输出的团队，这是最小侵入的方案。

Temporal 不是 Agent 框架，是工作流引擎。但解决的是 Agent 生产最痛的问题：长任务（几小时、几天）的可靠执行；失败后精确恢复，不重跑已完成步骤；人工审批节点可以"睡"几天，不占用资源。合理架构：Temporal 管外层编排和状态持久化，Pydantic AI 或原生 SDK 管 LLM 调用，两者通过 Activity 边界分开。

回归软件工程

用户的核心观点我很认同：AI 的尽头不是越来越复杂的黑盒框架，是回归经典软件工程。

具体怎么做？状态管理用数据库（PostgreSQL、SQLite），不用框架内建的 State；长任务执行用队列（Redis、RabbitMQ）加 Temporal，不用框架的"async"；结构化输出用 Pydantic model 加 Instructor，不用框架的 output parser；可观测性用 OpenTelemetry 加 trace/eval/log，不是"框架自带的 monitoring"；失败恢复靠幂等设计加重试策略，不是框架的 retry wrapper；权限边界用 RBAC 加 API 网关，不是框架的"agent role"。

大模型应该是被调用的组件，不是系统的主宰。 系统应该有明确的数据流、状态机、错误处理策略——这些是软件工程的基本功，不是 Agent 框架该教的。

一个实用的选型决策树

• 简单工具调用 / 结构化抽取 / 单轮客服 → 原生 SDK（OpenAI/Anthropic）+ Instructor/Pydantic AI 管输出。不需要框架。
• 多步骤工作流，有明确分支和条件 → LangGraph 的 Graph 层做编排，节点内用 Pydantic AI 或原生 SDK。或者 Temporal + 原生 SDK，如果任务很长。
• 需要多 Agent 协作，但流程明确 → LangGraph 的 Multi-Agent 模式，不要用 CrewAI 的"自然语言协作"。每个 Agent 是图中的一个节点，边定义协作规则。
• 快速原型验证，不打算直接上生产 → CrewAI，50 行代码出 Demo。验证完用 LangGraph 重写生产版。
• 研究型任务，需要 Agent 互相质疑迭代 → AutoGen/AG2 或 OpenAI 的 Swarm（教育参考）。注意成本控制。

生产级 Agent 长什么样

一个成熟的生产级 Agent 系统，应该具备：Schema 先行（所有 LLM 输出都有 Pydantic model 定义，运行时验证）、可观测性内建（每个 LLM 调用、工具调用、状态变更都有 trace，是系统设计的一部分，不是框架"附赠"的）、失败可恢复（任何步骤失败后知道从哪里重试，不是从头来）、成本可控（token 消耗可预测，不是跑完才知道花了多少）、人工可介入（关键节点可以暂停等人，不是"全自主"或"全手动"的二选一）、版本可复现（同样输入一个月后跑，结果应该一致，或者不一致是有记录的）。

这些特征和用不用 LangGraph 没关系。用原生 SDK + 数据库 + 队列 + Temporal 一样能做到。用 LangGraph 但忽略了 schema 和 trace，一样做不到。

最后

2024-2025 年，Agent 框架教会了开发者"AI Agent 能做什么"。2026 年需要回答的是"AI Agent 怎么在生产环境可靠地跑"。答案不在框架的 GitHub Stars 里，在软件工程的基本功里：类型系统、数据库设计、错误处理、可观测性、成本管理。

框架是工具，不是信仰。选对工具，然后让工程原则接管。

参考

• LangGraph 文档：langchain-ai.github.io/langgraph
• CrewAI 文档：docs.crewai.com
• Pydantic AI 文档：ai.pydantic.dev
• Instructor 文档：python.useinstructor.com
• Temporal 文档：temporal.io
• OpenAI Agents SDK：platform.openai.com/docs/agents
• Claude Agent SDK / Managed Agents：docs.anthropic.com

#AI #Agent #LangGraph #CrewAI #AutoGen #PydanticAI #Instructor #Temporal #生产级Agent #软件工程