附录B 主流Agent框架速查手册

本附录综合自 Agentic Design Patterns 附录C、Hello-Agents 第七章，提供主流Agent框架的快速选型参考。

---

框架全景对比

框架	核心抽象	工作流类型	状态管理	适用场景	语言	GitHub Stars	社区活跃度
LangChain	Chain (LCEL)	线性DAG	单次运行无状态	简单RAG、摘要、提取	Python/JS	~100K	⭐⭐⭐⭐⭐
LangGraph	Graph of Nodes	循环图	显式持久状态	复杂有状态Agent	Python/JS	~10K	⭐⭐⭐⭐
LlamaIndex	Index + Query Engine	检索管道	索引状态	数据密集型RAG应用	Python	~38K	⭐⭐⭐⭐
CrewAI	Agent + Task + Crew	角色协作	任务级状态	多Agent角色扮演	Python	~25K	⭐⭐⭐⭐
AutoGen	ConversableAgent	对话图	对话状态	多Agent对话协作	Python	~38K	⭐⭐⭐⭐
Semantic Kernel	Plugin + Planner	管道/图	内核状态	企业级AI集成	C#/Python/Java	~22K	⭐⭐⭐
OpenAI Agents SDK	Agent + Handoff	交接链	Runner状态	多Agent交接工作流	Python	~15K	⭐⭐⭐⭐
Google ADK	Agent + Tool	事件循环	会话状态	Google生态集成	Python	~10K	⭐⭐⭐
Agno	Agent + Team	轻量Agent	内存/存储	高性能多模态Agent	Python	~18K	⭐⭐⭐⭐

注：GitHub Stars 为 2025 年初近似值，社区活跃度基于 Issue 响应速度、文档完善度和版本更新频率综合评估。

---

1. LangChain + LangGraph

定位

LangChain是LLM应用的基础框架，LCEL（LangChain Expression Language）提供管道式组合。LangGraph在其之上引入图结构和循环能力。

核心架构

LangChain: prompt | model | output_parser  （线性链）
LangGraph: StateGraph → add_node → add_edge（带循环的状态图）

何时选择

• 选LangChain：流程线性可预测（A→B→C），无需循环
• 选LangGraph：需要推理循环、工具重试、Plan-and-Execute、Human-in-the-Loop

何时不选

• 不选LangChain：需要复杂循环或条件分支——LCEL的线性模型会变得笨拙
• 不选LangGraph：简单的单次调用管道——Graph的状态管理开销是不必要的复杂度
• 通用反模式：不要将LangChain和LangGraph混合使用在同一个工作流中，选一个并坚持使用

关键代码模式

# LangGraph状态图示例
class State(TypedDict):
    messages: list
    next_step: str

graph = StateGraph(State)
graph.add_node("agent", agent_node)
graph.add_node("tools", tool_node)
graph.add_conditional_edges("agent", should_continue, {"continue": "tools", "end": END})

---

2. LlamaIndex

定位

数据框架，专注于将私有数据连接到LLM。核心优势在索引构建和查询引擎。

核心架构

Documents → Node Parser → Index → Query Engine → Response Synthesizer

何时选择

• 应用核心是数据检索与问答
• 需要多种索引类型（向量、关键词、知识图谱）
• RAG管道需要精细控制（分块策略、重排序、后处理）

何时不选

• 应用核心不是检索而是复杂的Agent交互——LlamaIndex的Agent功能相对薄弱
• 需要复杂的多Agent协作——请选择CrewAI或AutoGen
• 数据量极小且结构简单——直接使用LLM的上下文窗口比构建索引更高效

关键组件

组件	作用
VectorStoreIndex	基于向量相似度的标准检索索引
KnowledgeGraphIndex	基于知识图谱的结构化检索
SubQuestionQueryEngine	将复杂问题分解为子问题分别检索
ResponseSynthesizer	从检索结果综合生成最终响应

---

3. CrewAI

定位

基于角色扮演的多Agent协作框架，强调分工明确的团队协作。

核心抽象

Agent（角色+目标+背景） + Task（任务描述+预期输出） + Crew（编排策略）

何时选择

• 任务可自然分解为不同角色（研究员、写作者、审校者）
• 需要顺序或层级的多Agent协作
• 偏好声明式角色定义而非编码式流程

何时不选

• 需要自由形式的Agent对话和协商——CrewAI的顺序/层级模式较为刚性
• 需要细粒度的执行控制（如条件分支、循环终止条件）——LangGraph更合适
• 任务间有复杂的动态依赖关系——CrewAI的静态任务编排难以处理

关键代码模式

researcher = Agent(role="研究员", goal="收集全面信息", backstory="...")
writer = Agent(role="作家", goal="撰写高质量文章", backstory="...")
crew = Crew(agents=[researcher, writer], tasks=[research_task, write_task], process=Process.sequential)

---

4. AutoGen

定位

微软的多Agent对话框架，以消息驱动的Agent间对话为核心。

核心架构

ConversableAgent ←对话→ ConversableAgent
     ↑                        ↑
AssistantAgent          UserProxyAgent

何时选择

• 多Agent对话式协作（讨论、辩论、协商）
• 需要灵活的群聊拓扑
• 需要代码执行环境集成

何时不选

• 需要确定性的工作流编排——AutoGen的对话式协作结果不完全可预测
• 对执行延迟敏感——多Agent对话会引入多轮LLM调用的延迟
• 不需要代码执行能力——AutoGen的代码沙箱是特色但非所有场景都需要

关键特性

特性	说明
GroupChat	多Agent群聊，支持动态发言选择
Code Execution	内置代码沙箱执行能力
Nested Chat	嵌套对话，实现复杂工作流
Teachability	Agent学习和记忆用户偏好

---

5. Semantic Kernel

定位

微软的企业级AI编排框架，强调与现有企业系统的集成。

核心架构

Kernel → Plugin（函数集合）→ Planner（自动编排）→ Memory（记忆管理）

何时选择

• 企业环境，需要与Microsoft生态集成
• 需要多语言支持（C#/Python/Java）
• 偏好Plugin式的能力扩展模型

何时不选

• 团队没有 C# 或 .NET 经验——Python/Java SDK 相对 C# 成熟度较低
• 不在 Microsoft 生态中——Semantic Kernel的集成优势将无法发挥
• 需要快速原型——Semantic Kernel的企业级设计带来较高的初始配置成本

---

6. OpenAI Agents SDK

定位

OpenAI官方的Agent构建SDK，核心概念是Agent间的Handoff（交接）。

核心架构

Agent（指令+工具+交接）→ Runner（执行循环）→ Handoff（Agent间转交）

何时选择

• 深度使用OpenAI模型生态
• 需要Agent间流畅交接（如客服分级、专家路由）
• 需要内置的Guardrails支持

何时不选

• 需要使用非OpenAI模型——SDK与OpenAI API深度绑定
• 需要复杂的图结构工作流——Handoff模型适合线性交接，不适合复杂拓扑
• 对供应商锁定敏感——迁移到其他模型提供商需要重写核心逻辑

关键特性

• Handoff：声明式Agent间任务转交
• Tracing：内置执行追踪和可观测性
• Guardrails：输入/输出验证护栏

---

7. Dify / Coze / FastGPT

定位

低代码/无代码Agent构建平台，通过可视化界面编排工作流。

平台	定位	核心优势	适用场景
Dify	开源LLMOps平台	可视化编排、RAG集成、自托管	需要完全控制的企业部署
Coze	字节跳动Agent平台	丰富插件生态、一键发布	快速原型验证、社交平台集成
FastGPT	开源知识库问答	知识库管理、工作流编排	知识密集型客服应用

何时选择低代码平台

• 快速原型：验证Agent概念，无需编写代码
• 非开发者：业务人员直接构建AI工作流
• 标准场景：客服、知识问答等成熟场景

何时转向Pro-code

• 需要自定义控制流或复杂条件逻辑
• 对延迟和性能有严格要求
• 需要与内部系统深度集成

---

8. Google ADK

定位

Google 的 Agent 开发套件，深度集成 Google Cloud 和 Gemini 模型生态。

核心架构

Agent（指令+工具）→ Session（会话状态）→ Runner（事件循环）→ Tool（函数/MCP/Agent-as-Tool）

何时选择

• 深度使用 Google Cloud 和 Gemini 模型
• 需要 Agent-as-Tool 模式（将子Agent作为工具调用）
• 需要 Vertex AI 集成用于生产部署

何时不选

• 不在 Google 生态中——ADK 的集成优势将无法发挥
• 需要丰富的社区生态和第三方集成——ADK 的生态相对年轻
• 需要非 Gemini 模型的深度支持

关键特性

特性	说明
Agent-as-Tool	将子Agent封装为工具，实现嵌套Agent架构
Session State	内置会话状态管理，支持多轮交互
Callback Hooks	before/after tool callback，实现工具调用拦截和验证
Multi-model	支持Gemini全系列模型，通过LiteLLM扩展到其他模型

---

9. Agno

定位

轻量级高性能Agent框架，专注于多模态能力和极简API设计。

核心架构

Agent（指令+工具+知识+记忆）→ Team（多Agent协作）→ Workflow（DAG/有状态图）

何时选择

• 需要 极简API 和快速上手——Agno的Agent定义通常只需几行代码
• 需要原生 多模态支持（图像、音频、视频输入输出）
• 需要 高性能——Agno声称Agent创建时间约为平均框架的1/10000
• 需要灵活的 存储后端（PostgreSQL、SQLite等）

何时不选

• 需要成熟的企业级功能（审计、合规、RBAC）——Agno 的企业功能尚在发展中
• 需要丰富的第三方集成生态——相比 LangChain 的集成数量仍有差距
• 团队已熟悉其他框架且迁移成本高

关键特性

特性	说明
Agent/Team/Workflow	三级抽象满足从单Agent到复杂工作流的所有场景
内置多模态	原生支持图像、音频、视频的输入处理和输出生成
知识库集成	内置向量存储和知识检索，无需额外RAG框架
轻量级记忆	会话记忆和持久化存储的统一接口
模型无关	支持OpenAI、Anthropic、Google、AWS等主流模型提供商

---

选型决策树

你的Agent需要什么？
│
├─ 简单的LLM管道（RAG/摘要/提取）
│  └→ LangChain 或 LlamaIndex
│
├─ 复杂的有状态循环工作流
│  └→ LangGraph
│
├─ 多Agent角色协作
│  ├─ 偏好声明式角色定义 → CrewAI
│  └─ 偏好对话式协作 → AutoGen
│
├─ 企业级集成（Microsoft生态）
│  └→ Semantic Kernel
│
├─ Google 生态集成
│  └→ Google ADK
│
├─ OpenAI模型 + Agent交接
│  └→ OpenAI Agents SDK
│
├─ 快速原型 / 非开发者
│  └→ Dify / Coze / FastGPT
│
└─ 高性能多模态Agent
   └→ Agno

---

框架演进趋势

1. 从链到图：LangChain→LangGraph的演进代表了从线性DAG到有状态循环图的架构升级
2. 协议标准化：MCP和A2A协议正在成为框架间互操作的标准接口
3. 低代码与Pro-code融合：Dify等平台逐渐支持代码节点，而LangGraph等框架也在增加可视化能力
4. 内置安全：新一代框架（如OpenAI Agents SDK）将Guardrails作为一等公民内置
5. 多模态原生：Agno等新框架从设计之初就支持多模态输入输出