#Agent 常见框架与区别

阅读提示 本笔记面向已经了解 LLM、Prompt、Function Calling 和 RAG 基础的开发者，目标不是罗列框架 API，而是讲清楚：各框架控制 Agent 循环的方式、状态如何保存、多 Agent 如何协作，以及选型时该依据什么判断。

内容依据各框架官方文档整理，最后核对日期：2026-07-28。

#目录

• 一、先建立统一坐标：Agent 框架到底管什么
• 二、常见框架逐个理解
• 三、核心区别速查
• 四、如何做技术选型
• 五、关键概念辨析
• 六、常见误区与生产风险
• 七、核心结论

一句话总纲 Agent 框架的本质，是替开发者管理 模型决策 → 工具执行 → 观察结果 → 更新状态 → 再次决策 的循环。框架之间真正的差异不在“都能调用工具”，而在于它们对流程控制、状态持久化、多 Agent 协作、数据/RAG、类型安全和云生态的侧重点不同。

读图时先看中间的 Agent Loop，再看四周的框架定位：LangGraph、Microsoft Agent Framework 偏显式编排；CrewAI 偏角色协作；LlamaIndex、Haystack 偏数据与 RAG；OpenAI Agents SDK 和 Pydantic AI 偏轻量代码体验。

#一、先建立统一坐标：Agent 框架到底管什么

#1. Agent 不等于一次 LLM 调用

普通 LLM 应用通常是：

用户输入 → 模型生成 → 返回结果

Agent 增加了一个可循环的执行闭环：

目标
  ↓
模型判断下一步
  ├─ 直接回答 → 结束
  ├─ 调用工具 → 获取 Observation → 更新状态 → 再判断
  ├─ 委派其他 Agent → 合并结果 → 再判断
  └─ 请求人工审批 → 暂停/恢复

最小伪代码如下：

state = {"messages": [user_message], "steps": 0}
 
while state["steps"] < MAX_STEPS:
    decision = model.decide(state)
 
    if decision.is_final:
        return decision.output
 
    observation = execute_tool(decision.tool_call)
    state["messages"].append(observation)
    state["steps"] += 1
 
raise RuntimeError("Agent 超过最大执行步数")

这个循环中，框架通常负责以下部分：

• 把 Python 函数、API、MCP Server 包装成 Tool；
• 保存消息、业务变量和中间结果；
• 决定节点、Agent 或工具的执行顺序；
• 处理重试、超时、暂停、恢复和人工审批；
• 记录 Trace，支持调试、评估和成本分析；
• 对输入、工具参数和最终输出做校验。

#2. Framework、Runtime、SDK 和平台不要混为一谈

精确表述 “Dify 和 LangGraph 都能做 Agent”这种说法过于笼统。更准确的区分是：Dify 更接近可视化应用平台，LangGraph 是代码优先的状态化编排运行时；二者抽象层级和控制粒度不同。

#二、常见框架逐个理解

#1. LangChain + LangGraph：生态层与编排层

LangChain 提供模型、Prompt、Tool、Retriever、Agent 等高层抽象和大量集成；LangGraph 则把 Agent 工作流表示为带状态的图，重点解决长时间运行、持久化、流式输出、Human-in-the-loop 和故障恢复。

两者不是竞争关系：

LangChain：模型、工具、Agent 预置能力
       ↓ 可组合使用
LangGraph：State + Node + Edge + Checkpoint
       ↓
LangSmith：Tracing、Evaluation、Deployment

优势

• 状态、节点和跳转路径显式，适合复杂业务流程；
• 支持 checkpoint、暂停恢复和人工干预；
• 模型与工具生态丰富，可不绑定单一模型厂商；
• 适合把“部分确定、部分由 LLM 决策”的流程组合起来。

代价

• LangGraph 抽象较底层，需要自行设计 State、节点边界和错误处理；
• 图变复杂后，状态字段、条件边和子图需要严格治理；
• 只做简单工具调用时可能显得过重。

适合：复杂客服流、审批流、研究型 Agent、长任务、需要断点恢复的生产系统。

#2. OpenAI Agents SDK：少量原语的轻量 Agent SDK

核心原语包括 Agent、Runner、Tool、Agent-as-tool / Handoff、Guardrail、Session 和 Tracing。SDK 自己管理工具调用循环，也支持多 Agent 委派。

优势

• 抽象少，上手快，Python 代码直观；
• Handoff、Guardrail、Session、Tracing 是一等能力；
• 与 OpenAI Responses API、Hosted Tools 和 OpenAI 可观测体系衔接自然；
• 既能用 Manager 调用“Agent-as-tool”，也能把会话控制权 Handoff 给专家 Agent。

代价

• 使用 OpenAI 模型和平台能力时体验最好，跨厂商场景需要额外适配和验证；
• 对非常复杂、强确定性的状态图编排，显式控制力不如 LangGraph；
• Handoff 会改变当前负责对话的 Agent，需要额外治理上下文和 Guardrail 边界。

适合：OpenAI 技术栈、客服分流、语音 Agent、快速构建带工具和安全校验的 Agent。

#3. CrewAI：角色化多 Agent 协作

CrewAI 用“团队”来描述系统：Agent 有角色、目标和工具，Task 描述任务，Crew 组织协作；Flow 则提供事件驱动、条件分支、状态和持久化，用于更可控的业务流程。

优势

• 角色、任务、团队的心智模型直观；
• 适合研究、写作、审核等“专家分工”场景；
• Crew 与 Flow 可以组合，在自主协作和确定性流程之间取平衡；
• 多 Agent 原型开发速度快。

代价

• 角色越多不代表效果越好，容易增加 Token、延迟和错误传播；
• 自主协作过程若缺少明确终止条件，调试和复现较困难；
• 对底层状态流转的精细控制通常不如显式状态图。

适合：内容生产、研究分析、专家评审、多角色协作 PoC。

#4. LlamaIndex：以数据和 RAG 为中心的 Agent

LlamaIndex 的传统强项是数据接入、索引、检索和 Query Engine；现在通过 FunctionAgent、ReActAgent、AgentWorkflow 和事件驱动 Workflow 把这些数据能力接入 Agent。

优势

• 数据连接器、索引、Retriever、Query Engine 与 Agent 结合紧密；
• 适合把多个数据源或查询引擎包装为工具；
• 对 Agentic RAG、文档研究和知识库问答很自然；
• 支持单 Agent、多 Agent、结构化输出和 Workflow。

代价

• 如果项目重点是复杂业务编排而不是数据检索，其优势不明显；
• 同时使用 LangChain/LangGraph 时容易出现抽象重叠；
• 旧的 Query Pipeline 已进入冻结/弃用阶段，新代码应优先看 Workflows。

适合：文档问答、Agentic RAG、多知识库路由、数据密集型 Agent。RAG 细节可参考 RAG架构设计 与 RAG优化方案。

#5. Pydantic AI：类型安全的 Python Agent 开发

Pydantic AI 强调“像 FastAPI 一样”的开发体验：通过类型注解、依赖注入和 Pydantic Model 定义依赖、工具参数和结构化输出，并提供多模型、MCP、Graph、Durable Execution、Evals 和 OpenTelemetry/Logfire 集成。

优势

• 输入、依赖、工具参数、输出都有清晰类型；
• 结构化输出验证和重试机制自然；
• 依赖注入有利于单元测试、Mock 和业务代码解耦；
• 模型厂商相对中立，适合现代 Python 工程。

代价

• 团队需要理解泛型、类型注解、Pydantic 校验和依赖注入；
• 生态规模和历史积累不如 LangChain；
• 复杂多 Agent 业务仍需要自己选择合适的编排模式或 Graph。

适合：FastAPI/Pydantic 技术栈、强结构化输出、金融/业务校验、重视测试和类型安全的项目。

#6. Microsoft Agent Framework：AutoGen 与 Semantic Kernel 的后继

截至 2026-07，微软官方将 Microsoft Agent Framework 定位为 AutoGen 与 Semantic Kernel 的直接后继：它结合 AutoGen 的 Agent 抽象与 Semantic Kernel 的类型安全、Middleware、Telemetry 和企业集成，并增加显式的图工作流、Checkpoint 与 Human-in-the-loop。

优势

• 同时提供单 Agent、Agent Harness 和类型化 Workflow；
• 支持 Python 与 .NET，适合 Azure 和微软企业生态；
• Session、Middleware、Telemetry、MCP、Checkpoint 等生产能力完整；
• 适合从 AutoGen 或 Semantic Kernel 迁移。

代价

• 新框架仍在快速发展，部分语言或能力可能处于 Preview；
• 旧项目、旧教程仍大量使用 AutoGen/Semantic Kernel，学习时要辨认版本；
• 如果团队不使用 Azure/.NET，部分企业集成优势可能用不上。

AutoGen 还要不要学？

要理解，但要带着迁移视角学习。AutoGen 的 AgentChat、Team、GroupChat、事件驱动 Runtime 仍是多 Agent 领域的核心概念；新项目选型时，应同时评估微软推荐的 Agent Framework。

#7. Haystack：Pipeline 与 RAG 工程化

Haystack 以 Component、Pipeline、Document Store 为基础，Pipeline 是可以包含分支、循环和并行路径的有向多重图；Agent 内部组合 Chat Generator、Tool 和 ToolInvoker。

优势

• RAG、搜索、文档处理和生成管线组件化程度高；
• Pipeline 适合明确的数据流、分支、循环和可复用组件；
• 模型与存储集成较多，适合搜索/RAG 工程；
• 可以在管线中嵌入 Agent，也可以构建 Agentic RAG。

代价

• 以多 Agent 社会化协作为主的场景，不如 CrewAI 直观；
• 纯 Agent 项目可能感到 Pipeline 抽象偏数据处理；
• 复杂状态化长任务需要特别核对持久化、恢复和部署方案。

适合：企业搜索、文档处理、生产级 RAG、需要清晰数据管线的 Agent。

#三、核心区别速查

表格中的“强/中/偏弱”是相对定位，不代表框架绝对能力；很多缺失能力都能通过自定义代码或外部服务补齐。

#最容易混淆的三组

#LangChain vs LangGraph

• LangChain 解决“我有哪些模型、工具、Retriever 和通用 Agent 抽象”；
• LangGraph 解决“这些步骤如何带着状态可靠运行、分支、暂停和恢复”；
• 简单 Agent 可只用 LangChain；复杂工作流常用 LangGraph，也可以完全不用 LangChain 组件。

#CrewAI vs LangGraph

• CrewAI 从“有哪些角色，如何协作”出发，适合快速表达组织分工；
• LangGraph 从“状态如何经过节点和边变化”出发，适合精确表达执行过程；
• 前者默认更强调自主协作，后者默认更强调显式控制。

#LlamaIndex vs Haystack

• 两者都擅长 RAG；
• LlamaIndex 更强调 Index、Retriever、Query Engine 与 Agent/Workflow 的结合；
• Haystack 更强调可复用 Component 和显式 Pipeline；
• 最终选择常取决于现有数据连接器、检索栈、团队经验和部署方式，而不是单看功能清单。

#四、如何做技术选型

#1. 决策顺序

任务能否用普通函数/工作流完成？
  ├─ 能 → 优先确定性代码，不必强上 Agent
  └─ 不能，需要动态决策或工具选择
       ↓
是否要求长任务、暂停恢复、人工审批？
  ├─ 是 → LangGraph / Microsoft Agent Framework / Durable Execution
  └─ 否
       ↓
核心竞争力是什么？
  ├─ RAG 与数据 → LlamaIndex / Haystack
  ├─ 角色化多 Agent → CrewAI
  ├─ OpenAI 原生能力 → OpenAI Agents SDK
  ├─ Python 类型安全 → Pydantic AI
  └─ 复杂通用编排 → LangGraph

#2. 一次完整的选型论证

站得住脚的选型论证通常包含五层：

1. 业务约束：流程是否确定、是否长运行、是否需要人工审批、并发和延迟目标是什么；
2. 关键能力：状态持久化、工具生态、RAG、多 Agent、结构化输出、可观测性；
3. 候选对比：至少横向比较两个框架，而不是直接锁定一个；
4. 决策理由：为什么它更匹配团队技术栈和生产约束；
5. 代价评估：复杂度、厂商绑定、迁移成本、Token 和调试成本。

示例场景：

项目存在多个确定的业务节点，但路由和工具选择需要模型判断，同时要求人工审核后恢复执行。因此我选择 LangGraph：用 StateGraph 显式描述节点和条件边，用 checkpoint 保存状态，用 interrupt 实现审批。相比 CrewAI，它牺牲了一些角色化建模的便捷性，但状态流转和故障恢复更可控，更符合生产需求。

#五、关键概念辨析

#1. Agent 框架与普通工作流框架的区别

普通工作流通常由代码预先决定每一步；Agent 允许模型根据当前目标和 Observation 动态选择工具或下一节点。生产系统往往是混合模式：确定性骨架由代码控制，不确定性决策交给模型。

#2. Agent 并非越多越好

多 Agent 会增加模型调用次数、上下文传递、冲突仲裁和失败点。只有当任务可以按能力、权限、上下文或并行性明确拆分时，多 Agent 才可能收益大于成本。否则，一个 Agent 加多个工具通常更简单、更稳定。

#3. State、Memory 与 Checkpoint 的区别

• State：本次运行正在使用的结构化数据，如消息、订单号、执行结果；
• Memory：跨轮次或跨会话保留的信息，如用户偏好和历史摘要；
• Checkpoint：某个执行时刻的状态快照，用于故障恢复、回放或人工审批后继续。

#4. Handoff 与 Agent-as-tool 的区别

• Handoff：把后续会话控制权交给另一个 Agent，适合客服分流；
• Agent-as-tool：主 Agent 仍掌握控制权，只把子任务交给专家 Agent，适合 Manager 模式；
• 核心区别是：谁拥有下一轮决策权，谁负责最终回答。

#5. 如何防止 Agent 死循环

• 限制最大步数、最大 Token、总时长和单工具超时；
• 为工具调用设计清晰的成功/失败结果；
• 对重复调用做去重或幂等控制；
• 用状态记录已尝试方案；
• 超过阈值后降级、请求人工或返回可解释错误；
• 通过 Trace 和离线 Evals 检查终止条件。

#6. 生产环境选型最该看的指标

优先看可控性而不是 Demo 代码长度：

• 任务成功率和评估体系；
• 状态持久化与故障恢复；
• 工具权限、审批、幂等和审计；
• Trace、日志、指标和成本；
• 延迟、并发、限流与重试；
• 模型/云厂商可替换性；
• 框架升级和团队维护成本。

#六、常见误区与生产风险

⚠️ 把多 Agent 当成默认架构 错误操作： 每个步骤都创建一个 Agent。

实际结果： 调用链变长、成本和延迟升高，错误在 Agent 之间传播，输出难复现。

原因： 把普通函数、工具和 Agent 的职责混淆；很多步骤根本不需要模型决策。

正确做法： 确定性转换用函数，外部能力用 Tool，只有需要独立目标、上下文或决策权时才拆成 Agent。

⚠️ 只有 Memory，没有业务状态 错误操作： 把订单号、审批结果、已执行步骤全部塞进聊天历史。

实际结果： 上下文被截断或摘要后，Agent 忘记关键状态，甚至重复执行有副作用的工具。

原因： 对话 Memory 不等于可靠的业务状态存储。

正确做法： 关键业务字段结构化存入 State/数据库；Checkpoint 用于恢复；Memory 只保存适合跨会话复用的信息。

⚠️ 有 Trace 就等于可观测 错误操作： 只接入调用链页面，不定义成功标准。

实际结果： 能看到每一步，却无法判断回答是否正确、检索是否有效、成本是否异常。

原因： Trace 解决“发生了什么”，Eval 和 Metric 才回答“效果是否达标”。

正确做法： 同时建立任务成功率、工具调用正确率、RAG 忠实度、延迟、Token 成本和人工介入率等指标。

有副作用的工具必须做工程保护 发邮件、付款、删数据等操作不能只靠 Prompt 限制。应在后端落实鉴权、参数校验、幂等键、最小权限、人工审批、审计日志和补偿机制。

#七、核心结论

八条核心结论

1. Agent 框架管理的是“模型决策—工具执行—状态更新”的循环。
2. LangChain 偏组件生态，LangGraph 偏长运行、状态化的显式编排。
3. OpenAI Agents SDK 用少量原语提供 Tool、Handoff、Guardrail、Session 和 Tracing。
4. CrewAI 擅长角色化多 Agent；LangGraph 擅长显式状态流。
5. LlamaIndex 与 Haystack 都适合 RAG，前者偏数据/查询引擎，后者偏组件化 Pipeline。
6. Pydantic AI 的关键差异是类型安全、依赖注入和结构化输出。
7. Microsoft Agent Framework 是 AutoGen 与 Semantic Kernel 的新一代后继。
8. 生产选型首先看状态、恢复、权限、评估和可观测性，不看 Demo 谁最短。

#官方资料

• LangGraph Overview
• OpenAI Agents SDK
• CrewAI Documentation
• LlamaIndex：Multi-Agent Report Generation
• Pydantic AI Overview
• Microsoft Agent Framework Overview
• AutoGen 迁移到 Microsoft Agent Framework
• Haystack Documentation