Appearance
Q116 · AI Agent 开发有哪些主流框架？各自有什么特点？
团队要做一个售后助手：客户说“订单 #7842 的商品破损，帮我申请售后”。应用得查订单归属、查售后规则、解释能否申请；若真要写入申请，必须取得有效确认，服务器重启后仍能知道是否已经提交。团队搜索框架时，会同时遇到 LangChain、LangGraph、LlamaIndex、CrewAI、AutoGen、Spring AI 等名字。它们看似都能“做 Agent”，封装的主要工作层却不同。
回答这题时可以把框架看作开发工具箱：有的先帮你搭好“模型提出工具调用 → 应用执行 → 模型继续回答”的循环；有的让你显式编排步骤、保存状态和等待审批；有的强调把文档处理成可检索知识；有的贴合 Java/Spring 应用。**框架不会自动给模型真实业务权限，也不会替商家承担订单所有权、退款确认或重复提交的校验。**下面按截至 2026 年 9 月 26 日可核对的官方文档介绍代表性选择；这不是按 Star、性能或市场份额排序的“前几名”。LangChain overview · LlamaIndex Framework · Spring AI Tool Calling
本文的商家、客户和订单 #7842 均为虚构示例。商品破损、申请条件和审批结果都由假设的业务系统决定；文中不擅自编造退款政策或金额。读者可以把同一任务放进不同框架比较，但示例没有跑过各框架的真实部署性能基准，不能据此声称谁更快或更安全。
术语：选框架时说的词
| 术语 | 初学者可以怎样理解 | 在 #7842 里是什么 |
|---|---|---|
| 模型 | 读输入、生成文字或结构化调用请求的大语言模型 | 判断下一步是否需要查订单和规则 |
| Agent | 模型、工具和应用控制逻辑组成的执行过程 | 多步处理售后请求的客服程序 |
| 框架 / SDK | 帮开发者组织模型调用、工具、状态或流程的代码库 | LangChain、Spring AI 等 |
| 工具调用 | 模型提出“用哪个工具和什么参数”；应用实际执行 | 请求查 #7842，由后端查订单库 |
| 工具循环 | 工具结果回给模型后，模型可继续回答或请求下一步 | 查单 → 看结果 → 再查规则 |
| 工作流 / 编排 | 应用明确规定步骤、分支和先后关系 | 查归属成功后才准查详情；确认后才可提交 |
| 状态 | 跨步骤保留的当前事实和进度 | #7842 已核验、等待用户确认、尚未提交 |
| 持久化 / 检查点 | 把状态存到运行进程之外，方便中断后继续 | 服务器重启仍知道申请是否已提交 |
| RAG | 检索增强生成：先找相关文档片段，再据此作答 | 找现行售后政策的相关条款 |
| 多 Agent | 多个有不同职责的 Agent 协作 | 资料核对者、订单核对者、回复起草者 |
| Middleware / Advisor | 在调用链中插入的可复用处理环节，各框架叫法不同 | 记录调用、限制工具、加入记忆或检索 |
| 人工介入 | 让真人在指定关口查看、批准或驳回 | 高风险申请在写入前等待客服主管 |
| POC | Proof of Concept，用小而真实的样本验证方案 | 用 20 张售后单测查单、审批和恢复 |
这里的“检查点”是程序保存的流程状态，不是“模型记住了就算保存”。“人工介入”也不等于模型写一句“请确认”就自动有了确认记录；应用需要有真实的界面、身份、审批事件和恢复逻辑。框架功能要与业务系统提供的数据库、权限、审计和运维能力一起看。
图中书架的四层是关注点清单，不是执行顺序或产品排名。同一框架可能覆盖几层，也可能要与别的组件组合。#7842 的“收到商品有破损，申请售后处理”是客户诉求；图上的锁提醒：接入框架之后，订单接口的权限仍须由商家后端控制。
先把这些名字放到正确的位置
LangChain 与 LangGraph 是相关但不同层级的项目。当前 LangChain 文档把 create_agent 作为可配置的高层 Agent 入口：给它模型、工具和指令，就得到常见的工具调用循环，还可通过 middleware 加入自定义行为。LangChain 的 Agent 构建在 LangGraph 之上。LangGraph 则是较低层的编排运行时，适合把节点、状态、分支、暂停和恢复写得更明确。两者不是“旧框架与新框架”或互斥替代品；LangGraph 也可不依赖 LangChain 的高层 Agent 使用。LangChain overview · LangGraph overview
LlamaIndex 以接入数据、建立索引、检索和用资料回答为重要入口，同时有 Agent 与工作流能力。当前官方文档既覆盖 RAG 流程，也介绍 FunctionAgent 这类使用函数工具的 Agent 和多 Agent 工作流。因此不能说“LlamaIndex 只能做 RAG”；更准确的说法是：当售后政策分散在文档、表格或知识库时，它的数据接入与检索组件值得重点评估。LlamaIndex：Building an LLM application · LlamaIndex：Building an agent
CrewAI 官方把 Crew 用于有角色和目标的 Agent 团队协作，把 Flow 用于更明确的事件驱动步骤和状态；Flow 可以在需要时调度 Crew。把三个角色写出来很容易，但三个 Agent 不会天然比一个 Agent 加三个专用工具更准确。售后场景若需要法务、质检、客服分别核查复杂证据，才值得测试分工带来的收益；简单的“查单再答”不必为了使用 Crew 而拆成多人对话。CrewAI Introduction · CrewAI Flows
AutoGen 与 Microsoft Agent Framework 需要特别看维护状态。AutoGen 曾以 Agent 间消息与多 Agent 协作为主要入口；但 Microsoft 的 AutoGen 仓库目前明确标注为 maintenance mode（维护模式），不再接收新特性，建议新项目从 Microsoft Agent Framework 开始，已有 AutoGen 项目可按迁移指南评估迁移。Microsoft Agent Framework 提供 Agent、工具、会话状态和显式工作流，官方文档列出 Python 与 .NET 入口。这里的“新项目建议”来自 Microsoft 项目维护者的现行说明，不代表所有既有 AutoGen 系统必须立即停用。AutoGen 官方仓库 · Microsoft Agent Framework overview · AutoGen 迁移指南
Spring AI 面向 Java/Spring 应用提供模型、工具调用、向量存储、RAG 和 Advisor 等抽象。当前 Spring AI 参考文档说明：在 ChatClient 路径中，ToolCallingAdvisor 负责工具调用循环；模型提出调用，应用侧的工具管理器执行。若直接使用较低层 ChatModel，不能假设同样的自动循环一定发生。对已有 Spring Boot 订单服务的团队，Spring AI 能让模型与业务代码留在熟悉的 Java 生态；但持久化审批、订单权限与幂等仍需要业务设计。Spring AI API · Spring AI Tool Calling
用相同维度比较，才不会背成广告词
| 框架或项目 | 官方文档中的主要入口 | 对 #7842 可能帮上哪一段 | 仍要由团队明确负责什么 |
|---|---|---|---|
| LangChain | 高层 create_agent、模型/工具抽象、middleware | 快速搭“查单—查规则—解释”的 Agent 循环 | 写入审批和业务权限仍要明确；复杂流程可下沉到 LangGraph |
| LangGraph | 显式状态与节点编排、持久化、人工介入 | 把查单、补证据、待批准、提交等步骤画成可恢复的路径 | 节点与状态定义、持久存储、外部写入幂等由开发者设计 |
| LlamaIndex | 文档接入、索引、检索、Agent/Workflow | 从多份售后政策和附件中找相关证据，再供模型解释 | 文档版本、权限过滤、证据适用性与业务动作校验 |
| CrewAI | Crew 协作与 Flow 控制 | 复杂售后调查时分给有不同职责的角色，并用 Flow 管整体步骤 | 多角色是否真有收益、角色间传递与最终责任归属 |
| Microsoft Agent Framework | Agent、会话、工具、显式工作流；Python/.NET | 在 Microsoft 技术栈中组织售后 Agent 和审批流程 | 实际身份、业务数据边界、所选模型/工具的支持与部署验证 |
| AutoGen | 历史上的多 Agent 消息与协作模式；现为维护模式 | 已有项目仍可继续运行和维护 | 新项目需考虑支持周期；老项目评估迁移成本 |
| Spring AI | Java/Spring 的 ChatClient、工具、Advisor、RAG | 把模型与现有 Java 订单服务和政策检索接起来 | 业务工作流的持久状态、确认、权限和重试设计 |
表里的“主要入口”表示适合从哪里开始评估，不是说某框架只会这一件事。LangGraph 也能接资料检索，LlamaIndex 也能编排 Agent，CrewAI 的 Flow 也有状态，Spring AI 也能构建工具循环。它们都不会因为框架名称里带 “AI” 就自动产生更好的模型、现行政策数据、可靠授权或真实售后能力。LangGraph overview · LlamaIndex Framework · CrewAI Introduction · Spring AI API
同一笔售后单怎样映射到不同技术选择
把 #7842 分成四个需要核对的业务动作。第一，读取订单：用登录会话校验订单归属，查商品、签收与售后状态。第二，读取规则：找到当前可用且适用的政策；资料缺失就说明不确定。第三，解释结论：模型根据订单和规则起草回复，不能宣布它尚未执行的申请已经提交。第四，若用户明确要求提交，则等待受控确认后写入：保存申请编号，超时后先查业务终态，防止重试产生重复单。
如果仅做前三步、团队主要用 Python，LangChain 的高层 Agent 足够作为快速原型起点；政策文档解析与引用占工作量大时，可以着重试 LlamaIndex 的检索组件。若第四步需要暂停数小时、服务重启后恢复、在分支之间保留可审计状态，LangGraph 或 Microsoft Agent Framework 的显式工作流值得评估。团队若本来就把订单和审批系统写在 Spring Boot 中，Spring AI 可承担模型/工具接入，原有 Java 服务继续承担确认和业务事务，不必为了“用一个 Agent 框架”强行搬走订单逻辑。多部门复杂调查才考虑 CrewAI 的 Crew 或其他多 Agent 结构；即使采用，最终写单仍应由受控流程执行。
这个映射是基于官方能力描述和本例需求作出的工程推断，不是厂商给出的统一评分。某个项目也可以组合两类库，例如用 Spring AI 调模型、由现有流程引擎处理审批，或者用 LangGraph 编排、用专门检索组件处理政策。关键是认清哪个组件持有状态、哪个组件真正调用业务接口，以及跨组件传递订单号和确认事件时怎样保持一致。
一个小 POC 比“谁最强”更有说服力
面试时若被问“你会选谁”，可用同一组样本测候选，而不是只跑一次“你好，世界”。以 #7842 为主线，至少准备五种情况：正常查单并给出处；客户订单不属于当前登录人；政策检索缺失或命中旧版；用户还没确认却被模型建议提交；写入请求超时后恢复并重试。事先规定正确行为：越权查询与未确认写入次数必须为零；没有可靠政策时要补查或转人工；恢复后最多保留一张有效申请单。
再记录每个框架方案要写多少业务胶水代码、能否看清模型和工具链路、暂停后怎样恢复、一次任务的 token/延迟、团队部署与维护是否熟悉。不要把“框架展示了 Human-in-the-loop 示例”误认为“生产审批已经可靠”：必须用真实的持久存储、审批身份、超时、撤销和幂等测试验证。也不要仅用 API 调用行数衡量复杂度；几行代码搭起的演示，可能把困难留给上线后的权限与恢复。
例如团队若有成熟 Java 服务和审批表，Spring AI 接入后能在五种样本中保持现有业务边界，就有充分理由不再引入新的 Python 编排服务。相反，如果售后流程需要频繁新增模型驱动分支、暂停恢复是主要难点，团队可把 LangGraph 或 Microsoft Agent Framework 纳入 POC。若实测发现一个 Agent 加查询工具就能稳定完成任务，多 Agent 协作的额外模型轮次和协调复杂度可能没有回报。最终选择是团队约束下的权衡，不是框架统一冠军。
容易混淆的边界
**框架不等于模型。**同一个框架可能接不同模型；模型支持的工具、结构化输出、长上下文等能力要按具体提供商与版本核对。换框架未必能修复模型本身的推理错误，换模型也不会自动补上订单所有权校验。
**框架不等于完整业务平台。**文档里的状态持久化、人工介入或可观测性是能力入口，仍需项目配置、存储后端、权限、日志脱敏、错误监控和线上运维。一个 POC 成功不等于退款流程已经合规或可靠。Spring AI 的 ChatClient 自动工具循环和直接 ChatModel 路径行为也不同，不能混称“Spring AI 的模型调用都会自动执行工具”。Spring AI Tool Calling
**多 Agent 不等于更高级的单 Agent。**角色越多，通信、上下文传递和冲突仲裁越多。若只是查订单、查规则、答复，明确的工具接口可能更直接；若要多部门独立调查，则多 Agent 才可能值得试。CrewAI 官方虽支持 Crew 与 Flow，也没有替你的业务定义最终批准者。CrewAI Introduction
**“主流”也会变。**过去的教程可能仍把 AutoGen 当成新项目默认入口，但其维护者现在明确给出了继任项目；Spring AI 等项目的接口也会升级。面试回答宜说“我依据当前官方文档和团队需求选择”，不要背某年的排名、Star 数或未经实测的性能数字。AutoGen 官方仓库 · Microsoft Agent Framework overview
面试时可以这样回答
AI Agent 框架可以按主要封装层来理解。LangChain 的
create_agent提供高层工具调用循环，LangGraph 更适合把状态、分支、暂停恢复显式编排；LlamaIndex 在数据接入、索引、检索及基于资料的 Agent 方面有完整组件；CrewAI 用 Crew 表达多角色协作、用 Flow 控制流程；Spring AI 贴合 Java/Spring 的模型、工具、Advisor 和 RAG 接入。AutoGen 是重要的多 Agent 框架，但当前官方仓库已标记维护模式，Microsoft 新项目建议看 Microsoft Agent Framework。选型时我会先拆业务：若只是查订单和政策后答复，先用高层 Agent；若有审批和重启后恢复，评估显式工作流；Java 团队可优先利用现有 Spring 服务。最后用同一批正常、越权、旧政策、未确认写入和超时恢复样本测结果。无论选哪个框架，订单权限、用户确认和外部写入幂等都由应用负责。
追问“LangChain 与 LangGraph 哪个更先进”，可以答：这不是新旧排名。当前 LangChain 的 Agent 建在 LangGraph 上；前者提供常见循环的高层入口，后者让你更细地控制流程状态。追问“为什么不直接上多 Agent”，可以答：先证明确实需要角色分工；否则协调开销可能增加，而订单查询与审批问题依然得自己解决。
资料依据
- LangChain overview 与 LangGraph overview — 高层 Agent、底层编排及两者关系。
- LlamaIndex Framework 与 Building an agent — 数据/RAG 组件与 Agent 工作流。
- CrewAI Introduction 与 Flows — Crew 协作与 Flow 控制。
- AutoGen 官方仓库、Microsoft Agent Framework overview 与 迁移指南 — 维护状态与继任项目。
- Spring AI API 与 Tool Calling — Java/Spring 生态、工具调用和 Advisor。