AutoGen vs LangGraph：多智能体框架怎么选，旧项目怎么迁

AutoGen vs LangGraph，如今首先是一道迁移选择题。截至 2026 年 10 月 27 日，Microsoft 的 AutoGen README 已明确说明：项目已归档，不再维护。如果需要显式控制有状态工作流，选 LangGraph；如果更看重与 Microsoft 智能体技术栈的衔接，选 Microsoft Agent Framework。已有的 AutoGen 原型可以为迁移提供有用素材，却不适合继续作为新生产项目的基础。AutoGen 当前状态。

AutoGen vs LangGraph：现在该选哪一个？

新系统如果需要追踪任务进展、暂停等待审批，并在中断后按预期恢复，就选 LangGraph。 LangGraph 是 LangChain 开发的编排运行时，允许应用通过显式状态串联各个执行步骤。例如在客服工作流中，即使工作进程重启，回复草稿、审核结论和人工批准也必须能够明确区分，这正是它适合处理的场景。

如果 AutoGen 项目的迁移需要延续 Microsoft 生态，尤其是已有的 .NET 应用，就选 Microsoft Agent Framework。 这个后继框架将智能体抽象与工作流结合在一起。不过，即使留在同一技术体系内，也仍要调整编排和状态处理，不能只改一下包名。Microsoft 框架概述。

已有的 AutoGen 原型只宜在迁移期间作为用途受限的参考保留。 留下其中有价值的提示词、工具接口约定和示例；不要在上游维护承诺已经失效的情况下，继续给它增加职责。

这项选择取决于三个问题：底层框架由谁维护，应用状态存在哪里，暂停的任务如何恢复。本文判断依据是文档，并非速度或模型质量基准测试。文中引用的厂商页面与文档均于 2026 年 10 月 27 日核验。

表中实现细节分别来自 AutoGen 团队指南、AutoGen 状态指南、LangGraph Graph API 和 LangGraph 持久化文档。

AutoGen 已归档，不只是进入维护模式

AutoGen 是 Microsoft 用于构建协作式 AI 智能体的框架。它的 README 现已明确警告：“项目已归档，不再维护。” 同一则声明指出，Microsoft 不再提供缺陷修复、安全修复、新功能或支持，并建议现有用户迁移。对新用户的建议也很明确：“新用户应从 Microsoft Agent Framework 开始。” Microsoft 的 AutoGen README。

有些开发者记得的是另一种支持政策，这可以从 Microsoft 较早的声明中找到原因。2025 年 10 月 1 日的发布文章曾表示：“两个项目都将继续获得支持，但大部分投入现已转向 Microsoft Agent Framework。”这是发布当时对 AutoGen 和 Semantic Kernel 的表态；后者是 Microsoft 较早的智能体与 AI 应用框架。这段旧表态不能取代 AutoGen 当前的警告。Microsoft 发布介绍。

Microsoft 在 2026 年 6 月 3 日的 BUILD 更新中还写道：“MAF 已于 2026 年 4 月 2 日达到 1.0 GA。”GA 表示正式可用。因此，不应再把这个后继框架仅仅描述为最初发布时的预览版本。Microsoft BUILD 更新。

如果是新项目，在 AutoGen 和 LangGraph 之间应选 LangGraph。 还没进入对话 API 的比较，AutoGen 的支持状态就已经决定了这一点。Microsoft Agent Framework 则是当前可选的另一个迁移目标。

对话驱动与有状态图：应用到底围绕什么组织？

AutoGen AgentChat 以对话作为便捷的组织单元；LangGraph 则把应用状态和状态转换明确写出来。 两者都能协调智能体。真正值得比较的是：一旦执行出错，或需要人工介入，开发者必须事先明确哪些规则。

AutoGen：智能体轮流发言，读取消息

AutoGen AgentChat 是建立在事件驱动的 AutoGen Core 运行时之上的高层团队 API。使用 RoundRobinGroupChat 时，参与者按顺序发言，并将回复广播给整个团队。起草智能体可以提出答案，审核智能体随后质疑或检查。SelectorGroupChat 则由模型决定下一位发言者。AutoGen 团队模式。

如果你已经清楚对话应该怎样展开，这种表达方式很直观。但当对话记录还要承担业务执行记录的职责时，问题就复杂了。一句“已批准”，可能是说草稿事实准确、客户已经同意，也可能是指人工授权。应用必须先分清这些含义，才能采取外部操作。

AutoGen 的难点，在于从有用的对话走向可恢复的业务流程，中间仍有一段距离；项目归档又进一步加重了这个问题。增加提示词，并不能定义哪份已保存的产物才是权威版本，也不能说明哪些操作已经发生。

但说 AutoGen 不能表达图结构，同样不准确。它的实验性 GraphFlow 支持顺序执行、分支、并行任务和循环。更值得注意的是另一项限制：执行图并不决定智能体能看到哪些消息。消息默认广播，消息过滤是独立机制。表示“接下来由审核者执行”的一条边，并不构成数据访问边界。GraphFlow 文档。

要理解已有的对话式原型，AutoGen AgentChat 更直观。 它的团队抽象能简洁地解释原型如何运行。这是迁移前读懂代码的理由，而不是用它启动新部署的理由。

LangGraph：由应用掌握结构化的工作记录

LangGraph 是面向有状态工作流的底层运行时。节点负责执行任务，边决定下一步，状态则是贯穿应用的结构化工作记录。节点既可以包含模型调用，也可以只是普通函数。LangGraph 概述。

在客服回复场景中，状态可以保存工单标识、已批准的参考文本、当前草稿、审核发现的问题以及人工决策。审核节点更新审核结果；条件边根据结果，将未通过的草稿送回修改，或让合格草稿进入审批环节。字段和规则都属于应用自身的设计。

**Reducer（状态归并规则）**决定如何将一次更新与某个已有状态字段合并。例如，当前草稿可以直接替换，审核意见则持续累积。如果这里选错了规则，就可能出现答案已经修改，旧审核结论却仍附在上面的情况。状态更新与 reducer。

LangGraph 的门槛，是它要求你把设计工作做明确。 状态结构、路由规则和失败时的行为都由应用负责。图中同样可以包含模型驱动的决策和循环；画出图，并不意味着生成文本就具有可重复性或一定正确。

要掌控工作流的业务状态，LangGraph 更合适。 它的价值在于提供可直接检查的记录，让你不必再从智能体对话中推断任务进行到了哪一步。

LangGraph 与 LangChain：先选对技术层次

LangChain 是提供模型、工具和智能体循环的高层框架，LangGraph 则在其底层提供编排能力。使用 LangGraph，并不要求同时采用 LangChain 的组件。技术栈如何配合。

迁移 AutoGen 项目时，先判断应用是否需要自定义工作流。一个调用工具后就返回答案的小助手，未必需要这层额外结构。LangChain 与 LangGraph 对比详细讨论了这一选择。

同一个双智能体任务，两种框架如何实现？

用起草者和审核者比较协作方式，但把发送权限放在两个智能体之外。 假设要根据固定的客户工单和经过批准的知识片段撰写客服回复：起草智能体提出答案，审核智能体逐项检查其中的说法是否有参考片段支持，然后要求修改或接受草稿。是否发送，由人工单独授权。

这是一份示意设计，并未执行基准测试。两种实现使用相同的输入、提示词和审核标准，两个智能体都拿不到发送工具。这样就能把比较集中在一个问题上：框架如何表示任务，以及任务应当停在哪里？

这些设计依据的是文档中的 AutoGen 反思式团队模式、两次运行之间的反馈、LangGraph 路由和中断机制。

AutoGen 需要配置什么？

为起草者和审核者设置各自的指令，再将它们放入 RoundRobinGroupChat。官方教程使用 TextMentionTermination，在智能体回复中出现某个词时停止运行。在这个应用里，这种停止只能表示自动审核结束，绝不能视为发送授权。应用需要检查结果，并保留审核者实际评估过的那份草稿。

还要给应用设定有边界的修改策略。如果审核者不断发现缺乏依据的说法，就应把案例连同问题清单交回人工处理，而不是让未解决的对话无限循环，只为等到一个表示成功的标记。

额外的工程工作都在对话之外：记录正在处理哪张工单、保存审核结论、在安全的停止点持久化团队状态，并将之后收到的人工输入关联到正确的草稿。状态教程提供的是序列化基础能力，并不是应用完整的恢复策略。

LangGraph 需要配置什么？

定义应用字段，例如 ticket_id、source_text、draft、review、approved 和 send_receipt。将起草节点连接到审核节点。审核失败时，如果修改策略仍允许重试，就返回修改；否则停止并交由人工处理。审核通过后，再进入人工审批步骤。

一条实用的实现规则是：只要草稿发生变化，就让之前的批准失效。否则，人工批准的可能是一份文本，应用最终发送的却是另一份。这是必须始终成立的业务约束，需要应用自行保证，并非框架自带的功能。

发送操作应在批准后，由一个独立的普通函数执行。该函数将外部系统的回执与工单、获批草稿关联保存。智能体的审核结果与人工授权，始终是不同的字段。

一旦任务需要延后审批和恢复执行，LangGraph 就更适合这个场景。 AutoGen 能清楚描述双方如何交流，而图结构更直接地表达业务记录及其控制关卡。如果任务只需产出一份尚未发送的草稿，而且很容易从头重跑，迁移时要解决的工作流要求就会少一些。

检查点与人工中断：恢复执行究竟意味着什么？

保存对话状态很有用，但它与恢复工作流并不是同一种保证。 AutoGen 在智能体和团队上都支持 save_state() 与 load_state()。应用可以将这些状态持久化到文件或数据库。直接说 AutoGen“没有记忆”，并不符合现有 API 的能力。AutoGen 状态管理。

LangGraph 使用 **checkpointer（检查点组件）**保存某个线程的图状态。线程标识的是一项持续进行的工作。与之独立的 **store（存储组件）**则保存需要跨线程使用的应用数据。要继续处理当前工单，用前者；如果需要共享的持久信息，再使用后者。持久化概念。

存储方案的选择至关重要。InMemorySaver 和 MemorySaver 将检查点保存在内存中，进程一旦重启，这些检查点就会消失。一个使用内存存储来演示中断的原型，并不能证明它具备重启恢复能力。要满足这个要求，必须使用持久存储。持久化问题排查。

面对延后的人工审核，LangGraph 的 interrupt() 可以暂停执行，等待外部输入。恢复时使用 Command(resume=...)，并沿用暂停运行时的同一个 thread_id。这个标识负责将新到达的决策与已保存的工作关联起来。LangGraph 中断行为。

AutoGen 的 UserProxyAgent 可以在运行过程中请求人工反馈，但文档提醒，此时等待中的团队会被阻塞在一个无法保存或恢复的状态。如果人工可能稍后才回来处理，文档给出的替代方式是结束运行、保存状态，然后在后续运行中携带反馈继续执行。AutoGen 人工反馈。

在客服示例中，应使用由应用管理的请求标识和已保存的发送回执，为发送操作提供保护。将发送放在审批之后，并确保其能够正确处理重复请求。设置一道审批关卡，本身并不会让独立的邮件服务获得事务保证。

需要持久保存、允许延后处理的审批流程时，LangGraph 更合适，前提是配置持久存储，并认真设计重复执行时的行为。无论检查点还是聊天记录，都不能证明某个外部操作恰好只发生了一次。

AutoGen 迁移：选 LangGraph 还是 Microsoft Agent Framework？

先根据需要自行掌控的部分选择目标框架，再对照现有应用评估重写工作。 离开 AutoGen，并不自动意味着应当选择 LangGraph。

已有 AutoGen 原型，什么情况下适合迁到 LangGraph？

如果原型的主要问题是状态不清晰，就应考虑 LangGraph：无法判断哪份产物是当前版本、失败任务应该从哪里继续，或者人工批准的是否是当前版本。在迁移提示词之前，先把这些不确定性转换成明确的字段和状态转换。

真正有价值的变化，是让这些要求能够被直接检查。如果只是把旧对话记录搬进图里，关键决策依然埋在消息中，那只是换了一个依赖，业务运行并没有得到多少改善。

如果原型中的不同智能体角色，并没有带来独立的工具、上下文或审核职责，可以在迁移时将其简化。多智能体系统指南解释了哪些情况下单智能体反而是更好的设计。

Microsoft Agent Framework：延续现有生态

Microsoft Agent Framework 是 Microsoft 为 AutoGen 和 Semantic Kernel 提供的直接后继框架。它提供智能体，以及连接智能体与普通函数的工作流。如果应用和运维团队已经依赖 Microsoft 的智能体技术栈或 .NET，它就更值得作为首选候选方案。这是基于集成条件的判断，并不意味着 LangGraph 无法处理同样的业务流程。Agent Framework 概述。

当前指南将 AssistantAgent 映射为 Agent，解释如何通过 AgentSession 延续对话，并用工作流模式取代团队协作机制。这些工作流提供带类型的数据流、人工输入请求和检查点能力。工具调用的迭代行为也有差异，因此迁移时需要回放现有的工具调用序列。AutoGen 迁移指南。

一个明确的迁移缺口：自定义分布式运行时。 指南目前将 Agent Framework 的组合执行描述为单进程模式，而分布式执行仍在规划中。如果 AutoGen 原型使用了分布式 Core 运行时，不能假定完成智能体层面的移植，就能保留原来的部署拓扑。需要针对计划采用的实际运行时和托管方式，单独验证这项要求。这是迁移指南指出的限制，不能据此概括所有 Microsoft 托管服务。

要延续 Microsoft 后继技术路线，Microsoft Agent Framework 更合适。 它的难点在于兼容性：熟悉的智能体概念，并不保证消息路由、会话行为和执行拓扑完全一致。如果离开 AutoGen 的目的，是围绕显式应用状态重新设计系统，则 LangGraph 更有优势。

迁移成本在哪里，哪些项目不必急着重写？

迁移的成本主要在于重建行为、转换状态，以及验证实际运行是否可靠。 提示词和工具实现或许可以复用，但它们的调度方式、上下文和持久化规则仍需逐项检查。评估工作量时，应围绕一个完整的业务操作展开，而不是数一数需要改多少条导入语句。

可以从客服回复这条流程开始。它有可观察的输入、草稿产物、审核结论、人工审批关卡和最终回执。相比一次搬走整组智能体、再寄希望于最终答案看起来差不多，这样的完整流程更适合作为迁移的最小单元。

1. 1

   记录现有行为

   保存有代表性的输入、已批准的参考资料、提示词、工具结构定义、输出和失败案例。记录模型与依赖版本。样例中应包括审核者拒绝通过的情况，以及需要人工澄清的情况。这些将成为新实现的验收样例。

2. 2

   独立导出应用记录

   使用由应用自行管理的格式，保留工单标识、草稿、审核意见、人工决策和外部操作回执。保留对话记录作为上下文，但不要把框架序列化出来的状态数据块，当成可直接迁移的业务记录。对于后续处理仍然需要的数据，写出明确的映射规则。

3. 3

   重建最小的完整工作流

   在 LangGraph 中定义状态结构和路由。在 Microsoft Agent Framework 中，按当前指南映射智能体、会话和工作流执行器。保持任务输入与评估标准不变，才能分辨行为差异究竟来自编排调整，还是模型或提示词变化。

4. 4

   验证各个失败边界

   让任务停在等待审批的状态，然后停止工作进程。重启后恢复任务、拒绝一份草稿、重复提交恢复请求，并模拟外部操作失败。检查已保存的应用记录与最终回执。仅凭最终生成的一段文字看起来合理，无法证明工作流已经正确恢复。

5. 5

   明确进行中的任务如何收尾

   决定未完成的任务是在旧实现中结束，还是经过明确的状态转换后继续处理。保留标识，以及批准决定与对应草稿之间的关联。不要悄悄把旧检查点交给不兼容的新工作流。

采用 LangGraph 后，同样需要面对它自身的迁移约束。Graph API 文档警告，不要重命名或删除被中断线程仍然需要的节点。今后部署新版本时，也应将工作流定义与已保存状态之间的关系视为兼容性边界。图迁移约束。

对于一个独立的研究原型，如果有用产出已经提取出来，且即将停用，就不必急着全面重写。总结经验，只迁移仍要继续使用的场景。对于仍在运行的 AutoGen 应用，有计划、可控的过渡优于未经验证的替换；但项目归档意味着应该安排迁移，而不是继续扩大对旧依赖的使用。

如果还要考虑更多候选方案，可以阅读 AI Agent 框架对比。如果最后还在考虑 CrewAI，则可查看 LangGraph 与 CrewAI 对比。

**下一步：**选一项反复执行的任务，写清楚哪些记录必须在重启后保留下来，以及谁有权批准最终操作。选择最能清楚表达这些要求的框架，先验证这一条完整流程，再迁移其余部分。

常见问题

AutoGen 和 LangChain 的主要区别是什么？

AutoGen AgentChat 围绕团队和消息组织多个智能体协作。LangChain 提供模型、工具和智能体抽象，LangGraph 则是它底层的编排运行时。如果目标是自定义有状态工作流，LangGraph 才是更直接的对比对象。AutoGen 已归档的状态，也改变了新项目的选择依据。

2026 年还值得学习 LangChain 吗？

如果它的模型与工具抽象适合你的应用，就值得学。如果需要明确指定工作流的状态和状态转换，可以直接学习 LangGraph。迁移 AutoGen 原型，并不要求采用整套技术栈的每一层。

CrewAI 比 LangGraph 更好吗？

没有适用于所有场景的赢家。如果应用的关键要求是显式状态、恢复边界和自定义审批逻辑，应优先评估 LangGraph。做决定前，让 CrewAI 接受同一项完整任务的检验；仅凭对框架的偏好，无法判断任务完成质量。

本文中的 AutoGen 指什么？

本文所说的 AutoGen，是 Microsoft 位于 microsoft/autogen 仓库的多智能体应用框架。讨论的实现主要是 AgentChat 团队 API，并在相关部分区分其底层 Core 运行时和实验性 GraphFlow。

AutoGen 已经弃用了吗？

Microsoft 当前的 README 使用了比“弃用”更明确的状态描述：项目已归档，不再维护。它建议新用户使用 Microsoft Agent Framework，并鼓励现有用户迁移。应以当前措辞为准，不要假定项目仍处于持续维护阶段。

AutoGen 和 Microsoft Agent Framework 是同一个框架吗？

不是。Microsoft Agent Framework 是后继框架，其迁移指南涵盖智能体、会话、工具和工作流 API 的变化。迁移过去需要验证应用行为，不能把它理解为给已安装的 AutoGen 包换个名字。

哪个 AI 智能体框架最好？

对本文讨论的需求而言，如果显式应用状态和工作流控制最关键，选 LangGraph；如果 Microsoft 的后继技术路线和已有生态最关键，选 Microsoft Agent Framework。框架本身无法替你判断，底层任务究竟是否需要多个智能体。

AutoGen 和 Semantic Kernel 的主要区别是什么？

Microsoft 的发布介绍将 AutoGen 的贡献概括为实验性的多智能体编排，将 Semantic Kernel 的贡献概括为企业应用 SDK 基础。Microsoft Agent Framework 将这两条路线结合起来。现在着手迁移 AutoGen，应评估当前的后继框架，而不是把这段历史分工作为仅有的选择依据。

多智能体框架应该怎么选？

最合适的框架，应当让所需行为表达清楚、易于维护。对于本文的客服工作流，推荐 LangGraph，因为审核、人工授权和发送必须是彼此独立的状态。如果更看重与后继技术路线的衔接，则可选择 Microsoft Agent Framework。

迁移前，可使用 AI 业务工作流审查清单，明确任务、审批边界及其运行负责人。