Agent框架选型指南

Agent框架选型指南

1. 先选型，再选框架

选型原则

  1. 先看语言和平台约束，再看业务场景。
  2. 复杂工作流优先控制力，简单场景优先上手速度。
  3. 需要生产化时，优先看可观测性、状态管理、部署能力。
  4. 如果只是做 PoC，不要一开始就上最重的框架。

2. 框架定位速览

框架 一句话定位 推荐指数 优势 局限 适合场景
LangGraph 状态驱动的底层编排框架 5/5 控制力强、状态清晰、适合复杂流程 学习曲线陡，设计成本高 生产级复杂 Agent、长流程、强状态管理
CrewAI 角色驱动的多 Agent 协作框架 4/5 上手快、协作直观、适合原型 底层控制力相对有限 内容生成、研究分析、快速 PoC
LlamaIndex RAG 和数据密集型 Agent 框架 5/5 文档/检索/知识库能力强 协作编排不如专门编排框架灵活 文档问答、企业知识库、数据检索
PydanticAI 轻量、类型安全的 Agent 框架 4/5 结构清晰、易测试、依赖少 编排能力偏轻 单 Agent、API 集成、工程化轻量项目
Agno 从原型到部署的一体化方案 4/5 组件完整、落地快、覆盖面广 生态体量不如头部框架 想快速做出可用系统并继续扩展
Microsoft Agent Framework 面向 .NET / Azure 的统一 Agent SDK 4/5 企业集成强、平台能力完整 平台绑定较强 Azure、.NET、企业内部系统
OpenAI Agents SDK 极简的 OpenAI 生态 Agent SDK 5/5 接入简单、门槛低 复杂编排能力有限 OpenAI 生态优先、轻量多 Agent
Google ADK 面向 Gemini / Google Cloud 的 Agent 套件 3.5/5 多语言、云集成强 生态依赖 Google Gemini、Google Cloud、企业部署
Dify 可视化低代码 Agent 平台 4/5 非技术团队友好、搭建快 灵活性受限 业务团队、快速试错、私有化部署
AgentScope 强调透明可控的多 Agent 框架 3.5/5 可见性好、国内生态适配较强 国际生态相对小 国内企业、研究场景、可控多 Agent

3. 框架快速理解

3.0 30 秒判断表

框架 一眼理解 最强项 最需要注意
LangGraph Agent 版工作流引擎 复杂状态、可恢复、可观测 设计成本高
CrewAI Agent 版团队协作工具 快速原型、多 Agent 协作 底层控制弱
LlamaIndex Agent 版知识系统 RAG、索引、检索 通用编排不是强项
PydanticAI Python 的类型安全 Agent 层 结构清晰、易测试 复杂编排要外接
Agno 原型到上线的一体化方案 组件齐全、落地快 生态还不如头部成熟
Microsoft Agent Framework .NET/Azure 的企业 Agent SDK 企业集成、平台能力 平台绑定强
OpenAI Agents SDK OpenAI 生态的极简入口 上手快、轻量 深度编排有限
Google ADK Gemini/Google Cloud 的官方选择 多语言、云集成 对 Google 生态依赖高
Dify 可视化低代码 Agent 平台 非技术团队、快试错 深度定制受限
AgentScope 透明可控的多 Agent 框架 可视性、国内适配 国际生态较小

3.1 LangGraph

可以把它理解成“Agent 版工作流引擎”。它不是替你想流程，而是让你把流程、分支、重试、回退都显式画出来。

  • 核心手感：前期最费脑，后期最稳
  • 最适合：审批流、长链路工具调用、状态会分叉或回滚的生产系统
  • 不太适合：只有一两个步骤的简单 Agent
  • 选型提醒：如果你最在意“可控”，它通常是第一候选

3.2 CrewAI

可以把它理解成“Agent 版团队协作工具”。你给每个 Agent 分工、定目标、设背景，它就更像一个能自己协作的小组。

  • 核心手感：表达自然，原型很快
  • 最适合：研究、内容生成、角色边界明确的协作任务
  • 不太适合：需要精细状态管理、复杂回路、强工程控制的系统
  • 选型提醒：适合先把协作想法跑通，再决定是否迁到更底层框架

3.3 LlamaIndex

可以把它理解成“Agent 版知识系统”。它更像数据和检索层的专家，而不是通用编排层的专家。

  • 核心手感：数据接入和检索链路很完整
  • 最适合：知识库问答、文档问答、企业内部搜索、RAG pipeline
  • 不太适合：需要复杂多 Agent 编排的场景
  • 选型提醒：如果系统核心是“答得准”，而不是“动作多”，优先看它

3.4 PydanticAI

可以把它理解成“把 Agent 写成类型明确的 Python 业务代码”。它把结构、校验、输出格式这些工程问题放得很前。

  • 核心手感：轻、干净、可测试
  • 最适合：API 辅助、单 Agent、工程化脚手架
  • 不太适合：大型多 Agent 编排
  • 选型提醒：很适合当 Agent 的基础层，而不是整套平台

3.5 Agno

可以把它理解成“从原型到上线的一体化方案”。它想解决的不是某一个点，而是尽量把 Agent 需要的东西拼齐。

  • 核心手感：从 demo 到可用系统的路比较短
  • 最适合：希望少拼装、尽快交付的团队
  • 不太适合：已经明确要自己掌握每个底层环节的团队
  • 选型提醒：如果你不想在太多组件之间自己搭胶水，它值得先看

3.6 Microsoft Agent Framework

可以把它理解成“Microsoft 全家桶里的官方 Agent 层”。它更像企业工程体系的一部分，而不是单独飘着的 SDK。

  • 核心手感：和 Azure、.NET、企业身份体系融合自然
  • 最适合：已有 Microsoft 技术栈的大中型企业
  • 不太适合：平台还没定，或者想要跨云、跨栈高自由度的团队
  • 选型提醒：不是最自由，但通常是企业内部最顺手的

3.7 OpenAI Agents SDK

可以把它理解成“最短路径做出一个 OpenAI 风格 Agent”。它把很多复杂性压得很低，适合先跑起来。

  • 核心手感：非常轻，几乎是直接把模型能力包装成 Agent
  • 最适合：OpenAI 生态优先、想快速上线的小团队
  • 不太适合：复杂调度、强状态、长流程
  • 选型提醒：如果你现在只想快，选它没有心理负担

3.8 Google ADK

可以把它理解成“Gemini 和 Google Cloud 的官方 Agent 套件”。它的优势主要来自 Google 生态内部的协同。

  • 核心手感：Google 体系里配合度高
  • 最适合：已经深度使用 GCP / Gemini 的团队
  • 不太适合：希望框架本身有最广泛社区沉淀的场景
  • 选型提醒：在 Google 体系里它很自然，离开这个体系优势会变弱

3.9 Dify

可以把它理解成“把 Agent 做成可配置产品”的平台。它更接近业务工具，而不是纯代码库。

  • 核心手感：拖拽、配置、发布，业务团队能直接参与
  • 最适合：低代码、业务试验、内部工具、快速 POC
  • 不太适合：复杂算法逻辑、深度定制、极致性能
  • 选型提醒：它最像平台，不像纯 SDK，这决定了它的边界

3.10 AgentScope

可以把它理解成“强调透明和可控的多 Agent 框架”。它更关注过程是否看得见、行为是否管得住。

  • 核心手感：流程清晰，行为透明
  • 最适合：国内企业、研究验证、需要清楚理解每一步的场景
  • 不太适合：只想直接吃到最成熟国际生态的团队
  • 选型提醒：适合追求可控性和国内适配的团队

4. 直接给结论

按场景选

  • 复杂生产流程：LangGraph
  • 多 Agent 协作和快速原型：CrewAI
  • 文档问答和 RAG：LlamaIndex
  • 类型安全、轻量开发：PydanticAI
  • 想一套打通原型到部署：Agno
  • 低代码给业务团队：Dify
  • .NET / Azure：Microsoft Agent Framework
  • OpenAI 优先：OpenAI Agents SDK
  • Gemini / Google Cloud：Google ADK
  • 国内企业和研究：AgentScope

按团队选

  • 只有工程师，且要长期维护：优先 LangGraph 或 PydanticAI
  • 业务同学也要参与：优先 Dify
  • 先验证想法，再决定架构：先 CrewAI，再迁移到更强的编排框架
  • 已被云平台锁定：直接选对应生态框架

5. 额外判断

MCP 已经把“工具接入”这件事标准化了，所以框架差距正在从“能不能接工具”转向“能不能把流程、状态、调试、部署做好”。A2A 更像未来互操作能力的加分项，不是大多数项目的第一决策点。

如果只记一句话：

复杂流程选 LangGraph，快速原型选 CrewAI，知识密集选 LlamaIndex，类型安全选 PydanticAI，低代码选 Dify，平台绑定场景直接选对应生态框架。