外观
框架选型总览
「做 Agent 该用哪个框架」是这个领域被问得最多、也被答得最糟的问题。糟糕之处在于大多数答案直接给你一个名字，而不问你三个前提：你的任务到底是固定流程还是开放探索、你的团队是什么技术栈、你能承受多深的抽象。这一页不给「标准答案」，给的是一张光谱图、一张核实到 2026 年中的对比表、一场关于「要不要用框架」的诚实讨论，和一棵能直接照着走的决策树。各框架的深入用法在子页面展开，低代码平台放在产品案例栏目。
先说一个贯穿全页的判断：框架解决的是编排问题，不是智能问题。模型能力、prompt、工具和上下文决定了 Agent 聪不聪明（见 Agent Loop 与 Context Engineering），框架只决定这些调用以什么结构组织起来、状态怎么存、失败怎么恢复。选型时不要指望框架弥补模型能力的不足。
一、框架光谱：从裸 SDK 到低代码
2026 年的 Agent 开发工具可以排成一条连续光谱，从左到右抽象层级越来越高、控制力越来越低、上手速度越来越快：
控制力高 ◄──────────────────────────────────────────────► 上手快
抽象少 抽象多
┌──────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐
│ 裸 SDK │ │ 轻量 SDK │ │ 图/状态机 │ │ 角色编排 │ │ 低代码平台 │
│ │ │ │ │ 框架 │ │ 框架 │ │ │
│ OpenAI / │→ │ OpenAI │→ │ LangGraph │→ │ CrewAI │→ │ Dify │
│ Anthropic│ │ Agents SDK │ │ Google ADK │ │ Microsoft │ │ Coze │
│ 官方库 │ │ Claude │ │ MAF │ │ Agent │ │ n8n │
│ │ │ Agent SDK │ │ │ │ Framework │ │ │
└──────────┘ └────────────┘ └────────────┘ └────────────┘ └────────────┘
~100 行代码 少量原语： 显式建模状态、 用「角色+流程」 拖拽画布，
自己写 loop handoff/钩子 分支、断点续跑 隐喻组织多 Agent 不写代码这条光谱不是「进化序列」——右边的并不比左边的先进。它们服务的是不同的场景和人：
- 裸 SDK（无框架）：直接用 OpenAI / Anthropic 官方库写 while 循环 + tool calling。一个能跑的 Agent Loop 核心不到 100 行代码。适合学习、适合简单任务、也意外地适合很多生产场景——后文详述。
- 轻量 SDK：以 OpenAI Agents SDK（2025 年 3 月发布）和 Claude Agent SDK（2025 年从 Claude Code SDK 更名而来）为代表。给你少量经过生产验证的原语——handoff、guardrail、hook、session——但不接管你的控制流。本质是「厂商把自己内部跑 Agent 的循环打包成库」。
- 图/状态机框架：以 LangGraph（2025 年 10 月发布 1.0）为代表，Google ADK、Microsoft Agent Framework 也在这一档。把 Agent 执行建模成显式的状态图：节点是步骤，边是转移条件，状态在节点间流动并可持久化。换来的是 durable execution（断点续跑）、human-in-the-loop 中断、可审计的执行轨迹。
- 角色编排框架：CrewAI、（已停更的）AutoGen 是代表。用「给每个 Agent 一个角色，让它们协作」的隐喻组织多 Agent 系统。上手最快，但隐喻的代价是调试时你不知道对话会往哪走。
- 低代码平台：Dify、Coze（扣子）、n8n。拖拽画布代替写代码，面向业务人员或快速验证。它们在「框架」光谱的尽头，严格说不是框架而是平台。
一个容易看漏的事实
轻量 SDK 和图框架不是互斥的两级台阶。LangChain 官方在 LangGraph 之上又做了 DeepAgents（带 planning、子 Agent、文件系统记忆的开箱 harness），Anthropic 的 Claude Agent SDK 本身就是把 Claude Code 的运行时打包成库。2026 年的趋势是「厂商把验证过的 harness 直接给你」，而不是让你从图原语开始搭。
二、主流框架大对比
下表数据核实至 2026 年年中（主要来源见文末参考资料）。版本状态变化快，引用具体数字前请到官方仓库再确认一次。
| 维度 | 裸 SDK | OpenAI Agents SDK | Claude Agent SDK | LangGraph | CrewAI | Microsoft Agent Framework |
|---|---|---|---|---|---|---|
| 定位 | 自己写 loop | 轻量多 Agent 原语 | Claude Code 运行时库 | 图编排 + 状态管理 | 角色制多 Agent | AutoGen/SK 继任者 |
| 抽象层级 | 无 | 低 | 低-中 | 中-高 | 中 | 中-高 |
| 语言 | Python / TS 均可 | Python + TS（独立包 @openai/agents） | Python 3.10+ / TS | Python / JS-TS | Python | Python / .NET(C#) |
| 核心原语 | messages + tools | Agent、handoff、guardrail、session | hooks、in-process MCP、权限白名单、子 Agent | 节点/边/状态、interrupt、checkpointer | Crew（角色协作）+ Flow（事件驱动流程） | 图工作流、中间件、YAML 声明式定义 |
| 状态管理 | 自己存 | session 管理对话历史 | 会话与文件系统态 | checkpointer 持久化，durable execution | 内存/外部存储 + checkpoint | 会话状态 + 遥测 |
| 人机协作 | 自己写 | 需自行组合 | 权限白名单 + AskUser 钩子 | 一等公民：interrupt() 中断恢复 | Flows 中可插审批节点 | 支持审批与中断 |
| 模型绑定 | 绑定所调 API | 名义无关，经 LiteLLM 支持 100+ 模型 | 强绑定 Claude | 模型无关 | 模型无关 | 模型无关，Azure 深度集成 |
| 生态 | 无 | OpenAI 生态，内置 tracing | Anthropic 生态 + MCP | LangChain 集成目录最深 | 独立生态（不基于 LangChain） | Azure / Foundry |
| 版本状态（2026 中） | — | 仍为 0.x（2026 年 7 月约 0.18），迭代频繁 | 稳定迭代，随 Claude Code 演进 | 1.0（2025-10 GA，承诺 2.0 前不破坏 API） | 1.0 GA（2025-10） | 1.0 GA（2026-04） |
| 生产适用性 | 简单任务完全够用 | 快速上线可用，长期留意 API 变动 | Claude 系 Agent 的务实选择 | 复杂长任务的事实标准之一 | 原型到中小规模生产 | 微软系/.NET 团队默认选项 |
表格之外，几个需要单独说清楚的事实：
LangGraph 的位置。1.0 之后它把重心放在生产问题上：durable execution（失败后从断点精确恢复）、human-in-the-loop interrupt、短期加长期记忆。官方材料称 Uber、LinkedIn、Klarna、JP Morgan 等在生产环境使用（2025 年 10 月 1.0 发布公告）。配套的 LangGraph Platform 于 2025 年 5 月 GA。它是「复杂、有状态、长周期」工作流里被引用最多的默认选项——注意这个定语，不是「所有 Agent」的默认选项。
OpenAI Agents SDK 的 0.x 状态。它的原语设计（agent / handoff / guardrail / session）干净漂亮，但截至 2026 年 7 月仍是 0.x 版本，发布频繁，意味着 API 可能变动。名字里有 OpenAI，实际上通过 LiteLLM 等集成支持上百家模型。OpenAI 已宣布 2026 年中期起逐步淘汰 Assistants API、全面转向 Responses API，Agents SDK 是这条路线上的官方载体。
Claude Agent SDK 的独特性。它不是「又一个编排框架」，而是把驱动 Claude Code 的那套运行时（文件读写、Bash、子 Agent、权限控制、hooks、in-process MCP server）直接暴露成库。如果你要的 Agent 本质上需要「在文件系统和 shell 里边看边干」，这套 harness 已经被 Claude Code 的海量真实使用打磨过，自己重写一遍大概率不如它。
AutoGen 已死，有事烧纸——但不烧给错对象。AutoGen 自 2025 年底进入维护模式：README 明确「不再接收新功能，转为社区维护」，只有 bug 修复和安全补丁。微软把 AutoGen 与 Semantic Kernel 合并为 Microsoft Agent Framework，2026 年 4 月 GA，是 .NET 生态唯一的一线选择。存量 AutoGen 代码能继续跑，新项目不应再选它。本站 AutoGen 页面 保留它，是因为它的「对话即计算」思想和多 Agent 模式仍然值得学——作为历史与设计教材，不作为选型推荐。
第二梯队值得知道的名字：Google ADK（Gemini 生态，已到 2.x）、Pydantic AI（Python 类型安全流派，FastAPI 手感）、Mastra 与 Vercel AI SDK（TypeScript 阵营前两名）、AWS 的 Strands Agents、HuggingFace 的 smolagents（约千行核心的极简 CodeAgent）。选型 shortlisted 时按语言和云厂商归属对号入座即可。
常见的三组正面对决
实际选型很少是「全场海选」，通常是收敛到两个候选后的短名单对决。2026 年工程团队讨论最多的三组：
- LangGraph vs OpenAI Agents SDK：控制与简洁的权衡。OpenAI Agents SDK 的四个原语（agent / handoff / guardrail / session）半天能上手，适合把多 Agent 原型快速跑起来；LangGraph 要求你先想清楚状态图，但换来的是可审计、可回放、可中断的执行。原型期选前者、复杂生产选后者是常见路径——但要意识到两者代码不兼容，这个「之后再换」的迁移成本是真实的重写。
- LangGraph vs Pydantic AI：Python 团队内部的对决。Pydantic AI 用类型注解描述 Agent 的输入、工具签名和输出，依赖注入、结果校验、OpenTelemetry 埋点都由框架完成，代码量少一个量级，适合嵌在 Python 服务里的单 Agent 和小型系统；LangGraph 赢在显式编排：多角色、长周期、checkpoint、审批中断。判断标准一句话：你的复杂性在「单个 Agent 的输出质量」选 Pydantic AI，在「多个执行单元如何协作与恢复」选 LangGraph。
- Mastra vs Vercel AI SDK（TypeScript 阵营）：Mastra 是「全家桶」——Agent、图工作流、RAG、memory、evals 打成一个 TS 优先的包；Vercel AI SDK 是「在你已有的 Next.js/Node 栈上长出 Agent 能力」，AI SDK 7 提供 ToolLoopAgent、HarnessAgent、WorkflowAgent 三种抽象。整个产品都在 JS/TS 世界选前者更内聚，已有 AI SDK 存量代码选后者更顺滑。
三组对决的共同教训：先在语言和云厂商归属上砍一刀，再在这两个变量筛出的 2-3 个候选里做实测，而不是读十篇横评文章。
三、「要不要用框架」：一场诚实的讨论
Anthropic 的建议：先裸写，再考虑框架
Anthropic 在 2024 年 12 月发布的《Building Effective Agents》至今仍是这个领域被引用最多的工程建议，其核心观点两条：
- 他们与几十个跨行业团队合作后发现，最成功的实现用的都不是复杂框架，而是简单、可组合的模式。
- 严格区分 workflow（代码路径预先固定的编排）与 agent（模型自主决定路径的系统），并建议：先找最简单的方案，只有当固定步骤无法解决问题时才引入自主性。
这不是「框架一无是处」的论调，而是一个顺序问题：框架提供的 durable execution、多 Agent 委派、human-in-the-loop、tracing，每一样都是在「你确实遇到了那个问题」之后才值回票价。在那之前，它们只是你还没踩到地雷就先背上的辎重。
一个最小可用的裸写 Agent Loop 长这样（Anthropic SDK，Python）：
python
import anthropic
client = anthropic.Anthropic()
def run_agent(user_task: str, tools: list, max_turns: int = 20):
"""最小 Agent Loop：模型自主调用工具直到给出最终答复。"""
messages = [{"role": "user", "content": user_task}]
for _ in range(max_turns):
resp = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=4096,
tools=tools, # [{name, description, input_schema}, ...]
messages=messages,
)
messages.append({"role": "assistant", "content": resp.content})
# 没有工具调用 = 模型认为任务完成，退出循环
if resp.stop_reason != "tool_use":
return resp
# 执行模型请求的工具，把结果作为 tool_result 回喂
results = []
for block in resp.content:
if block.type == "tool_use":
output = execute_tool(block.name, block.input) # 你的工具分发
results.append({
"type": "tool_result",
"tool_use_id": block.id,
"content": str(output),
})
messages.append({"role": "user", "content": results})
raise RuntimeError("超过最大轮数，Agent 未收敛")这就是「裸 SDK」档位的全部核心。读一遍你就会发现：循环、工具分发、消息追加，没有任何黑魔法。不理解这段代码就直接上 LangGraph，是典型的地基没打先盖楼——这也是本站把 手写一个 Agent 列为实践第一站的原因。
框架的隐藏成本
框架的宣传页不会告诉你的四笔账：
- 学习成本前置。LangGraph 的节点/边/reducer/checkpointer 概念体系，学到位需要以周计。而你的第一个 Agent 大概率用不上其中一半。OpenAI Agents SDK 这类轻量库学习曲线平缓，但 0.x 阶段你要持续跟进 breaking change。
- 调试成本后置。框架越重，「模型为什么做了这个决定」到「框架在哪一层改了行为」之间的距离越远。在裸循环里加一行
print(messages)就能看到的 trace，在重型框架里可能要翻三层回调。可观测性工具能补回一部分（见 可观测性），但不如一开始就没丢。 - 版本耦合成本。Agent 框架是 2025-2026 年迭代最剧烈的软件品类之一。LangChain 生态早年「每个小版本都 breaking」的名声不是凭空来的；AutoGen 从爆红到停更只用了两年。选框架 = 选一支你未来一年要跟着升级的队伍。
- 人才与迁移成本。框架特有的写法（LangGraph 的 StateGraph、CrewAI 的 YAML 式角色定义）不是可迁移技能。团队换框架时，这部分经验直接清零。
抽象泄漏：Agent 框架的原罪
Joel Spolsky 的「抽象泄漏定律」在 Agent 框架上体现得淋漓尽致：框架试图把「一次 LLM 调用」抽象成节点、Agent、Crew，但 LLM 的非确定性会穿透一切抽象漏到你面前。模型在一个节点里输出了不合 schema 的 JSON、handoff 之后上下文丢失了一半、Crew 里两个角色陷入互相恭维的死循环——这些问题没有一个是框架概念能描述的，你最终还是要回到 prompt、消息列表和 tool result 的层面去修。
什么时候框架确实是过度设计
满足以下全部条件时，重型框架在大多数情况下是过度设计：单 Agent、工具数量少于 10 个、任务在几分钟内完成、失败重跑成本低、不需要中途人工介入。一个 while 循环加 retry 就完了。反例同样明确：任务要跑几小时、跨会话恢复、需要审批卡点、多 Agent 分工——这些正是 durable execution 和状态机的价值区，自己造反而更贵。
那框架到底买什么
买四样东西，按价值排序：
- 状态与恢复：checkpoint、durable execution、长任务断点续跑。自己造这套东西的痛苦远超想象，这是 LangGraph 这一档最硬的卖点。
- human-in-the-loop 基础设施：中断、审批、恢复执行。涉及钱、生产环境、对外发消息的 Agent 绕不开（见 Human-in-the-Loop）。
- 多 Agent 原语：handoff、子 Agent 隔离上下文、群聊协调。确实需要多 Agent 时（先看 多智能体架构 确认你不是在过度设计），原语比自写稳。
- tracing 与评估钩子：生产环境的必需品，但注意——Langfuse、LangSmith 这类独立可观测工具可以脱离编排框架单独接入，不构成选框架的锁定理由。
四、决策树
把「团队背景 × 任务复杂度 × 自主度需求」三个变量压成一棵树。从根节点顺着走，落在哪个叶子就先试哪条路：
开始：我要做一个 Agent
│
├─ Q1: 任务是固定流程（步骤可预先穷举）吗？
│ │
│ ├─ 是 ──► 别做 Agent，做 workflow
│ │ ├─ 会写代码？──► 裸 SDK + 普通函数编排（prompt chaining / routing）
│ │ └─ 不写代码？─► 低代码平台：Dify / Coze / n8n
│ │
│ └─ 否（路径必须由模型动态决定）──► Q2
│
├─ Q2: 这是第一个 Agent 原型 / 学习项目吗？
│ │
│ └─ 是 ──► 裸 SDK 手写 Agent Loop（~100 行）
│ 目的不是省钱，是建立对 loop 的直觉
│ └─ 遇到真实瓶颈后再回到本树 Q3
│
├─ Q3: 任务的运行特征？
│ │
│ ├─ 短任务、失败可重跑、单 Agent
│ │ ├─ 主用 OpenAI 系模型 ─► OpenAI Agents SDK
│ │ ├─ 主用 Claude 且需要文件/shell 操作 ─► Claude Agent SDK
│ │ └─ 想保持厂商中立 ─► 裸 SDK 或 Pydantic AI
│ │
│ ├─ 长任务 / 需断点续跑 / 需人工审批 / 复杂分支
│ │ ├─ Python/TS 团队 ─► LangGraph
│ │ ├─ .NET / Azure 团队 ─► Microsoft Agent Framework
│ │ └─ Gemini / GCP 团队 ─► Google ADK
│ │
│ └─ 明确的多角色协作（研究→写作→审核这类分工）
│ ├─ 快速验证想法 ─► CrewAI（Crews + Flows）
│ └─ 要进生产且流程复杂 ─► LangGraph 显式建模，
│ 角色只是 prompt 层面的设定
│
└─ Q4: TypeScript 全栈团队？
└─ 是 ──► Mastra 或 Vercel AI SDK 优先，LangGraph.js 兜底两条使用说明：
- 这棵树给出的是「第一个候选」，不是终身承诺。靠谱的做法（Langfuse 的建议）：用排名前二的候选各实现同一个最小任务，把两边的 trace 接进同一个可观测平台，比成本、延迟、失败模式，然后选那个「你更愿意在未来一年里调试它的 trace」的框架。
- 树里没出现「切换成本」分支，是因为降低切换成本的办法不在树里：把 prompt、工具定义、评估集与编排代码分离。这三样是你在任何框架间迁移时真正能带走的资产。
- 最后一条元建议：框架热度的半衰期以月计，但这棵树依据的变量——任务结构、自主度、恢复成本、团队栈——半衰期以年计。选型讨论时把话题拉回这四个变量，你就不会被每季度的新框架发布会牵着走。
五、各框架深入页导读
本页只做选型判断，每个框架的安装、核心 API、完整示例和坑位记录在各自专页：
- LangGraph 深入：StateGraph 心智模型、checkpointer 与 durable execution、interrupt 实现 human-in-the-loop、子图与多 Agent。
- OpenAI Agents SDK 深入：agent / handoff / guardrail / session 四大原语、tracing 接入、Responses API 时代的定位。
- Claude Agent SDK 深入：复用 Claude Code 运行时、hooks 拦截 Agent Loop、in-process MCP server、权限白名单。
- CrewAI 深入：Crew 角色协作模型、1.0 之后的 Flows 事件驱动流程、什么时候 CrewAI 够用、什么时候该换。
- AutoGen 深入：维护模式现状、向 Microsoft Agent Framework 的迁移路径、「对话即计算」的设计思想复盘。
还没读核心组件栏目的话，建议先补 工具与 MCP——框架的工具接入层几乎全部已经收敛到 MCP，这比选哪个框架更影响你的长期架构。
六、低代码平台：光谱的另一端
Dify、Coze（扣子）、n8n 严格说不是「框架」而是平台：你得到的不是代码库里的抽象，而是一整套带 UI、托管、权限和应用分发的环境。截至 2026 年年中的大致格局：
| 平台 | 定位 | 开源 | 适合谁 |
|---|---|---|---|
| Dify | LLM 应用开发平台（Workflow + RAG + Agent 一体） | 是，GitHub 约 14.2 万 star（2026-05） | 有研发能力、想自托管的团队 |
| Coze（扣子） | 无代码 Bot/Agent 构建工具，字节跳动出品 | 否（SaaS 为主） | 运营与业务人员，零代码起步 |
| n8n | 自动化集成平台长出 AI 能力，400+ 连接器 | 是（fair-code），GitHub 约 18.8 万 star | Agent 价值主要在打通外部系统的场景 |
三者的差异本质上是出发点的差异：Dify 从 LLM 应用出发加工作流，n8n 从自动化连接器出发加 AI 节点，Coze 从「让不会写代码的人搭 Bot」出发做生态分发。
常见的务实组合是 Dify + n8n 双栈：前者管 LLM 应用逻辑，后者管系统集成。但要清醒：低代码平台的天花板在于，当 Agent 行为需要精细调优（自定义 loop、细粒度控制上下文、非常规工具协议）时，你会撞墙，而且墙内没有代码可改。它们在产品案例栏目有专页：Coze 案例 与 Dify 案例。
给求职者的一句话
招聘市场上「会 LangGraph」出现在 JD 里的频率远高于其他框架，但面试里真正能拉开差距的问题是「你不用框架怎么实现，框架帮你解决了什么」。先裸写、再精通一个图框架、对其余保持「看过文档知道取舍」的了解度，是投入产出比最高的组合。岗位细节见 岗位版图 与 知识地图。
参考资料
- Building Effective Agents — Anthropic —— 2024 年 12 月发布，workflow vs agent 的经典区分与「从最简单方案做起」的建议源头。
- Open-Source AI Agent Frameworks: Which One Is Right for You? — Langfuse —— 2026 年 7 月更新的主流框架横评，本页对比表的主要事实来源之一。
- LangChain and LangGraph Agent Frameworks Reach v1.0 Milestones —— LangGraph 1.0 官方发布公告（2025 年 10 月），含 durable execution 与生产用户名单。
- CrewAI OSS 1.0 — We are going GA —— CrewAI 1.0 GA 公告（2025 年 10 月），Crews + Flows 架构的官方说明。
- Microsoft Agent Framework Overview — Microsoft Learn —— AutoGen 与 Semantic Kernel 合并后继任框架的官方文档。
- openai/openai-agents-python Releases — GitHub —— OpenAI Agents SDK 版本轨迹，核对其 0.x 状态与迭代节奏。
- The best AI agent frameworks in 2026 — LangChain —— LangChain 官方维护的框架清单，含各框架 star 数与定位快照（2026 年 6 月）。