Agent 框架市场在过去两年极度碎片化，新框架几乎每周出现。本篇不追求列全，而是建立一套分类思维框架，帮助你在面对任何新框架时都能快速定位其价值。
框架（Framework）vs 产品（Product）是一个容易混淆的基本区分：框架是你用来构建东西的工具（LangChain、CrewAI），产品是你直接使用的应用（OpenClaw、nanobot、Claude Code）。本篇聚焦框架侧；OpenClaw、nanobot 等个人 Agent 产品在第七篇产品格局中讨论。
一、选框架前先回答三个问题
在看任何框架之前，先想清楚这三个问题：
问题 1：任务复杂度如何？
- 单步工具调用（查一个 API）→ 任何轻量方案都够用
- 多步推理循环（ReAct）→ 需要 Agent Loop 支持
- 多 Agent 协作 → 需要专门的协作框架
问题 2：可控性要求多高？
- 固定流程、合规要求高 → 倾向于 Workflow 化框架
- 灵活决策、适应性强 → 倾向于 Agent 化框架
- 既要可控又要灵活 → 状态机框架（LangGraph 类）
问题 3：团队背景是什么？
- 非技术人员、快速验证 → 低代码平台
- Python 工程师、原型开发 → 轻量框架
- 大型工程团队、生产部署 → 全栈重框架或企业级方案
二、六层框架分类图谱
1 | ┌──────────────────────────────────────────────────────────────────┐ |
三、各层核心特征
3.1 第一层：低代码/无代码平台
目标用户：产品经理、运营人员、非技术背景的 AI 探索者。
核心价值：拖拽式构建，无需写代码，快速上线。
| 平台 | 特点 | 适合场景 |
|---|---|---|
| Coze | 字节跳动出品，集成飞书/微信/Discord，插件生态丰富 | 快速搭建对话 Agent，接入各类平台 |
| Dify | 开源，私有化部署友好，工作流 + Agent 双模式 | 企业私有知识库问答，工作流自动化 |
| n8n | 自动化工作流为主，AI 节点是近两年新增 | 将 AI 嵌入已有的自动化流程 |
| Flowise | LangChain 的可视化版，开源 | 快速验证 LangChain 方案 |
局限：可定制性有限，复杂逻辑难以表达，生产环境的性能和可靠性依赖平台。
3.2 第二层：轻量框架
目标用户：Python 工程师、研究者、个人开发者。
核心价值：依赖少、核心可读、易于定制和学习，适合原型验证或深入理解 Agent 机制。
OpenAI Swarm
OpenAI 官方出品的极简多 Agent 框架，设计目标是教学和原型验证而非生产部署。核心概念只有两个：Agent（有名字、指令和工具的 LLM）和 Handoff（Agent 之间的控制权移交）。代码量极小，是理解多 Agent 协调机制的最佳入门材料。
smolagents（HuggingFace 出品）
最小化依赖的 Agent 框架，核心创新是 CodeAgent：Agent 用 Python 代码而非 JSON 表达 Action，天然支持工具组合和复杂逻辑，可读性更高，也更容易调试。适合对工具调用方式有定制需求的场景。
Pydantic AI
以类型安全为核心设计理念，用 Pydantic 的 Schema 约束 Agent 的输入输出和工具调用参数。适合注重代码质量和工程规范的团队，与现有 Python 类型注解体系无缝衔接。
Instructor
严格来说不是完整的 Agent 框架，而是专注于 Structured Output 的库。用 Pydantic 模型定义期望输出格式，自动处理重试直到 LLM 输出符合 Schema。可以搭配任何框架使用，是生产环境保证输出可解析的常用方案。
3.3 第三层：全栈重框架
目标用户：需要生产级功能的 Python 工程团队。
核心价值：覆盖 Agent 开发的完整链路，文档齐全，生态丰富。
LangChain（LLM 应用开发的早期奠基者）
几乎定义了 Agent 开发的基础抽象：Chain、Tool、Memory、Retriever、Prompt Template。生态最丰富，几乎所有 LLM 都有 LangChain 集成。
但随着功能膨胀，API 频繁变化、学习曲线陡峭的批评也不断出现。LangChain 后来推出 LangGraph 作为对复杂状态管理的答案。
LlamaIndex
与 LangChain 定位略有不同——LlamaIndex 以数据连接和 RAG 见长，强调”让 LLM 与私有数据对话”。其数据连接器（Data Connectors）和查询引擎（Query Engine）是业界参考标准。
Haystack
以生产环境 Pipeline 见长，强调可测试性和组件化。在文档搜索、问答系统等偏 RAG 的场景有大量生产案例。
3.4 第四层：多 Agent 专向框架
目标用户：需要多 Agent 协作的复杂系统工程师。
核心价值：提供角色定义、通信协议、协作模式的抽象。
| 框架 | 核心模式 | 特点 |
|---|---|---|
| CrewAI | 角色+任务分配 | 简单易用，定义角色和任务即可，是目前落地最多的多 Agent 框架 |
| AutoGen | 对话式多 Agent | 微软出品，Agent 之间通过对话协作，灵活但难以预测 |
| MetaGPT | 软件公司 SOP | 模拟研发团队（PM/架构师/程序员），适合代码生成类任务 |
| CAMEL | 角色扮演对话 | 学术背景，适合研究 Agent 间自主协作的行为 |
3.5 第五层：状态机/工作流框架
LangGraph（LangChain 团队出品）
将 Agent 执行过程建模为状态图（State Graph）：节点是处理函数，边是状态转换条件。
核心优势：
- 支持循环、分支、条件跳转
- 人工介入节点（Human-in-the-loop）是一等公民
- 状态持久化，支持长时间运行的任务
- 比纯 LLM 驱动的 Agent 更可预测、可调试
当需要”可控的复杂流程”时，LangGraph 是目前最成熟的选择。Anthropic 的 Orchestrator-Subagents 模式用 LangGraph 实现效果最好。
3.6 第六层：企业/云原生层
目标用户：需要与企业现有基础设施深度集成的大型团队。
Semantic Kernel（微软出品）
支持 C# 和 Python 双语言，与 Azure、Office 365、Microsoft Graph 深度集成，适合微软技术栈的企业。
Amazon Bedrock Agents
AWS 的托管 Agent 服务，与 AWS 生态（S3、Lambda、RDS）深度集成，适合已经重度使用 AWS 的团队。
Azure AI Foundry
微软的企业 AI 平台，提供模型管理、Agent 编排、评估、监控的完整工具链。
四、选型决策逻辑
不需要写代码？ → 低代码层（Coze/Dify/n8n）
需要写代码，但任务简单或个人项目？ → 轻量层
→ 学习/理解多 Agent 机制：OpenAI Swarm
→ 代码即 Action 的灵活工具调用：smolagents
→ 类型安全优先的工程风格：Pydantic AI
→ 只需约束输出格式：Instructor
需要完整的生产级功能？ → 全栈重框架
→ 以 RAG 为核心：LlamaIndex
→ 通用 LLM 应用开发：LangChain
核心需求是多 Agent 协作？ → 多 Agent 专向层
→ 快速落地：CrewAI
→ 代码生成团队模拟：MetaGPT
需要复杂可控的流程控制？ → LangGraph
深度集成企业现有 IT 基础设施？ → 企业层（Semantic Kernel/Bedrock）
五、一个真正的选型建议
对于大多数项目，推荐的路径是：
- 先用低代码平台验证 idea（Dify/Coze），成本最低
- 验证可行后，用轻量框架重写核心（smolagents/Pydantic AI），控制复杂度
- 规模化时引入重框架或状态机框架（LangGraph），处理生产级挑战
每个阶段都有明确的升级信号：低代码平台碰到定制性瓶颈时升级；轻量框架碰到状态管理瓶颈时升级。
避免的常见错误：一开始就引入最重的框架（LangChain + 所有插件），在不了解工具的情况下被框架的复杂性淹没，最终花大量时间调框架而不是解决业务问题。
六、总结
框架不是目的，解决问题才是。掌握六层分类图谱后，面对任何新框架，先问三个问题：它在哪一层？它解决了那一层什么核心问题？我的项目需要那一层吗？
| 层次 | 代表框架 | 核心价值 |
|---|---|---|
| 低代码 | Coze/Dify/n8n | 无代码快速上线 |
| 轻量 | OpenAI Swarm/smolagents/Pydantic AI | 小而可读，原型/研究友好 |
| 全栈 | LangChain/LlamaIndex | 生产级功能全覆盖 |
| 多 Agent | CrewAI/AutoGen/MetaGPT | 角色协作编排 |
| 状态机 | LangGraph | 可控复杂流程 |
| 企业 | Semantic Kernel/Bedrock | 企业基础设施集成 |
下一篇：Agent 如何记住东西——四种记忆类型、RAG 的工作原理、Agentic RAG 与 GraphRAG，以及长上下文 vs RAG 的判断框架。