AutoGen 到 Microsoft Agent Framework：从多 agent 对话到生产编排

一、先看一个多 Agent 原型上线时少了什么

假设研究员负责找资料，写作者负责成稿，负责人负责审核。做原型时，只要研究员能把结果交给写作者， 写作者再把草稿交给负责人，这个多 Agent 团队就已经能演示了。AutoGen 最有价值的地方，正是把这种 “谁给谁发消息、收到消息后做什么”表达得很清楚。

但上线以后，团队会遇到另一组问题：负责人还没审批，服务就重启了；用户第二天回来，流程不知道停在哪里； Web、Teams 和 API 各写了一套接入代码；人工补充意见后，任务只能从头再跑。此时缺的已经不是“再加一个 Agent”， 而是一套能记录进度、暂停、恢复并统一接入渠道的生产运行方式。

二、先认识贯穿全文的六个概念

先不看类名，把两代框架放在同一张地图上。后文所有源码都只是在实现下面六件事：

• AutoGen：重点表达多个 Agent 怎样通过消息协作，适合研究和搭建对话原型。
• 消息运行时：像团队的内部邮局，负责收消息、排队、找到收件人，并调用对应处理逻辑。
• 团队对话：把研究员、写作者、负责人组织起来，规定谁先说、谁接手、什么时候结束。
• MAF：Microsoft 后续面向生产 Agent 与多 Agent 工作流的新框架。
• 工作流与 checkpoint：把步骤、分支和暂停点显式记录下来；checkpoint 就是可恢复的“存档点”。
• Hosting：把同一套 Agent 或工作流接到不同入口，并统一管理会话、恢复和运行状态。

AutoGen README 开头已经给了很明确的边界：AutoGen is now in maintenance mode， 不再接收新功能；新用户应该从 Microsoft Agent Framework 开始，已有用户建议按迁移指南迁移。 同一段还把 MAF 定位成 AutoGen 的 enterprise-ready successor，强调 stable APIs、long-term support、 multi-agent orchestration、multi-provider model support，以及 A2A 和 MCP 互操作。 证据在 AutoGen README maintenance notice。

MAF 自己的 README 也不是把它写成“AutoGen 改名版”。它说 Microsoft Agent Framework 是用于 production-grade AI agents and multi-agent workflows 的开放、多语言框架，覆盖 Python 和 .NET； 适合需要生产运行、超出单 prompt 或无状态 chat loop 的编排、graph patterns、durability、restartability、 observability、governance、human-in-the-loop 和 provider flexibility 的团队。 证据在 MAF README overview。

三、同一份报告，用两套实现各跑一次

这里比较的是同一个逻辑任务的两次独立实现，不是一个运行先进入 AutoGen、做到一半再迁移到 MAF。 AutoGen 原型用于看清角色消息和团队规则；MAF 生产版重新实现同一业务目标，把审批、checkpoint 和发布回执放进显式 Workflow。

3.1 AutoGen 原型运行

1. 用户提交“调研三家竞品并给出建议”，这里选择一个明确的 AgentChat Team pattern，并调用 team.run(...)。
2. 研究员完成检索后发出结果，团队对话规则把结果转交给写作者。
3. 写作者生成草稿，负责人收到审核消息；团队达到终止条件，本次原型运行结束。
4. 如果应用需要稍后恢复，由应用在合适时机调用 save_state、持久化结果，并在新进程中先 load_state。

3.2 MAF 生产运行

1. 新的请求由 MAF Hosting 接收；本例的 host target 明确是 Workflow，不是在 Agent 与 Workflow 之间临时二选一。
2. Workflow 把“检索、写作、审核、发布”记成步骤，在人工审核前产生 request-info 并保存 checkpoint。
3. 负责人晚些时候补充意见，调用方用 responses 或 checkpoint id 恢复同一 Workflow。
4. 发布 executor 在批准后执行外部发布，保存回执；只有回执成功，报告才从 approved 进入 published。

服务重启后的恢复还有前提：Hosting 必须配置持久化 checkpoint storage（例如相应的 state_dir/checkpoint_location）和稳定 isolation key。默认只在内存里的状态会随进程退出丢失， 不能因为 API 里出现 checkpoint 字段就宣称天然跨进程恢复。

用同一个“研究员 + 写作者 + 负责人”的任务看，迁移线不是把类名换一遍，而是状态 owner 换了位置：

AutoGen prototype
  User message
    -> SendMessageEnvelope(message, recipient, future)
    -> runtime queue
    -> MessageContext(is_rpc=True)
    -> RoutedAgent handler
    -> ResponseMessageEnvelope

  Team chat
    -> group topic / manager topic / participant topics
    -> embedded runtime publishes messages
    -> team save_state / load_state

MAF production route (a separate implementation)
  channel request
    -> AgentFrameworkHost
    -> ChannelContext.run_stream(...)
    -> Workflow.run(message=...) or Workflow.run(checkpoint_id/responses=...)
    -> status / request_info / checkpoint events
    -> channel response and durable recovery point

AutoGen 这边，核心形状是消息信封、topic 和 handler；MAF 这边，核心形状变成 hosted channel、session、 workflow checkpoint 和 HITL continuation。把这条差别记住，后面读每个类就不会把“多 agent 对话”和“生产编排” 混成同一件事。

四、再把迁移边界说清楚

AutoGen README 的 “Why AutoGen?” 仍然有价值，因为它把 AutoGen 的分层讲清楚： Core API 负责 message passing、event-driven agents、local and distributed runtime，并支持 .NET 和 Python； AgentChat API 是建立在 Core 上的更 opinionated API，支持 two-agent chat 和 group chats； Extensions API 则承接 LLM clients、AzureOpenAI、OpenAI、code execution 等能力。 这段在 AutoGen layered design。

但同一个 README 也提醒 AutoGen Studio 只是帮助快速 prototype 和 demo，不是 production-ready app； 生产应用需要开发者自己实现 authentication、security 等能力。 证据在 AutoGen Studio caution。 所以比较 AutoGen 和 MAF 时，不能把 Studio 的 no-code GUI 当成 MAF Hosting 的等价物。

五、AutoGen Core 的 owner 是消息运行时

AutoGen Core 可以先当成一个 agent 消息中心来理解。它至少要处理两种通信：一个 agent 点名找另一个 agent， 这就是 send_message；一个 agent 把消息发到某个 topic，让订阅者都收到，这就是 publish_message。 另外，runtime 还要知道 agent type 怎样创建，已经托管的 agent 状态怎样保存和恢复。 源码在 send_message 与 publish_message、 agent registration 和 runtime state。

SingleThreadedAgentRuntime 是这个协议的参考实现。它用一个 asyncio queue 处理 PublishMessageEnvelope、SendMessageEnvelope 和 ResponseMessageEnvelope， 同时维护 agent factories、instantiated agents、intervention handlers、subscription manager、serialization registry 和 tracing helper。类注释明确说它适合开发和 standalone applications，不适合 high-throughput 或 high-concurrency 场景。 源码在 runtime 说明 和 runtime fields。

send 和 publish 的处理差异也很干净。send_message 会生成 future、入队 direct envelope，并等待 response； publish_message 只把消息投递到 topic，不期待响应。处理时，direct 消息构造 MessageContext(is_rpc=True) 并把 agent response 包成 ResponseMessageEnvelope；publish 消息从 subscription manager 找所有订阅者， 构造 MessageContext(is_rpc=False)，并并发调用订阅 agent。 证据在 send / publish 入队、 direct processing 和 publish processing。

六、RoutedAgent 把 handler 变成类型路由

AutoGen Core 不是只靠字符串路由。@message_handler 装饰器会读取函数的 type hints， 记录 target message types 和 return types，并在 wrapper 里做输入与返回类型检查。 @event 是专门处理 publish event 的版本，它要求返回 None，并通过 ctx.is_rpc 防止 RPC 消息走进 event handler。 源码在 @message_handler contract 和 @event contract。

这就是 AutoGen 的“agent framework”味道：agent 不是一轮 LLM call 的别名，而是一个能被 runtime 按消息类型、topic、 RPC/event 语义调度的 actor-like object。它能解释为什么 AutoGen 很适合讲 multi-agent conversation 和研究型协作模式， 也解释为什么生产服务层的 authentication、channel、durability 并不是 AutoGen Core 自己的中心。

七、AgentChat 把 runtime 包成团队对话

AgentChat 的 ChatAgent 协议把低层消息运行时收束成更像产品开发者使用的接口： agent 有 name、description、produced_message_types， 通过 on_messages 或 on_messages_stream 处理 chat messages，并支持 reset、pause、resume、save_state、load_state 和 close。 源码在 ChatAgent。

group chat 的基类更能说明 AgentChat 是如何建立在 Core 之上的。BaseGroupChat 注释说， participants 通过发布消息共享上下文；这个 base class 负责把 AgentChat API 的 agents 映射到 Core API 的 agent runtime， 并处理 run、pause、resume 和 reset。它还为每个 team 生成唯一 topic type：group topic、manager topic、participant topics、 output topic，并用 embedded SingleThreadedAgentRuntime 托管。 证据在 BaseGroupChat 说明、 topic 与 embedded runtime 和 runtime registration and subscriptions。

所以 AutoGen 的高级体验并不是脱离 Core 的单独 DSL，而是用 topic、subscription 和 routed agents 搭出 round robin、selector、swarm、Magentic-One 这类 team patterns。README 里的 multi-agent orchestration 示例还展示了 AgentTool：把专家 agent 包成工具，再交给 general assistant 调用。 证据在 AutoGen AgentTool 示例。

7.1 AutoGen 的恢复 owner 仍在应用

pause/resume 改变当前 Team 的运行状态，save_state/load_state 则提供状态导出和导入能力； 但“何时保存、保存到哪里、进程重启后先装载哪份状态”仍由应用决定。这个边界与后面的 MAF Hosting 不同： Hosting 可以为 Workflow 配置 checkpoint owner，但只有配置了持久存储和隔离键时，重启恢复才成立。 两边都出现 state API，不代表 durability owner 相同。

八、MAF 的 Agent 是 client、tool、session 的组合面

MAF Python README 给出的最小路径是 Agent(client=OpenAIChatClient(), instructions=...)， 然后直接 agent.run(...)；也可以不建 agent，直接使用 chat client 的 get_response。 这说明 MAF 把 client 和 agent 分开：chat client 是模型服务适配层，agent 是带工具、上下文、session、middleware 和 telemetry 的运行单元。 证据在 Python quickstart and direct chat client。

源码里 SupportsChatGetResponse 协议只要求 get_response， 支持 streaming 和 non-streaming，接收 messages、options、compaction_strategy、tokenizer、function_invocation_kwargs 和 client_kwargs。 Agent.run 则先准备 run context，再调用 client 的 get_response，最后把 ChatResponse 或 streaming updates 解析为 AgentResponse。 证据在 SupportsChatGetResponse、 Agent.run 与 client call 和 response parsing。

BaseAgent 负责 id、name、description、context providers、middleware、session 创建和 session 获取； RawAgent 则接收 client、instructions、tools、default_options、context_providers、middleware、compaction_strategy 和 tokenizer。 它还把 tools normalize 后拆出 MCP tools，并把 agent-level options 合并为 chat options。 证据在 BaseAgent session and context 和 RawAgent setup。

更关键的是，MAF 明确把 agent delegation 做成 first-class tool。BaseAgent.as_tool 会把 agent 包成 FunctionTool，可设置 approval mode、stream callback、是否传播 parent session。这样多 agent 协作不一定要先进入 group chat， 也可以通过普通工具调用协议完成。 源码在 BaseAgent.as_tool。

九、MAF Workflow 是图执行引擎，不是 chat transcript

MAF 的 Workflow 不应该读成“把聊天历史组织一下”。它更像一个可恢复作业图：executor 收到消息后运行， 可以把消息发给下游 executor，可以产出 workflow-level output，也可以发自定义事件。 文档里说它是 graph-based execution engine，用 edge groups 连接 executors，并使用类似 Pregel 的 superstep 模型执行到 idle。 证据在 Workflow overview。

它的 run API 也比普通 chat loop 更接近可恢复作业系统：run 支持初始 message、streaming、responses、 checkpoint_id、checkpoint_storage、include_status_events，以及传给 subagents 的 function/client kwargs。 参数校验规定 message 不能和 responses 或 checkpoint_id 同时传，至少要有 message、responses 或 checkpoint_id 之一。 证据在 Workflow.run 和 run parameter rules。

工作流状态也不是隐藏实现细节。run stream 会显式产出 started、status、request_info、failed 等控制事件； 如果 executor 请求外部输入，workflow 会进入 IDLE_WITH_PENDING_REQUESTS，调用方可以之后用 run(responses=...) 或 checkpoint restore 加 responses 继续。checkpointing 捕获 executor states、 in-transit messages 和 shared state，支持跨进程恢复。 证据在 request info and checkpointing、 workflow status events 和 core run continuation。

十、Orchestrations 是预制图，而不是另一个 runtime

MAF README 把 sequential、concurrent、handoff、group collaboration 写进 key features，并强调 workflows 支持 checkpointing、 streaming、human-in-the-loop 和 time-travel。Python README 也把 advanced orchestration patterns 列成 Sequential、 Concurrent、Group Chat、Handoff 和 Magentic。 证据在 MAF key features 和 Python orchestration overview。

源码上，SequentialBuilder 会把 participants 解析成 executors：agent-like participant 变成 AgentExecutor，开启 request info 时变成 AgentApprovalExecutor；然后用 WorkflowBuilder 从 input conversation 到每个 participant 依次加 edge。也就是说 sequential orchestration 本质上是一个 workflow graph 模板。 证据在 SequentialBuilder setup、 participant resolution 和 workflow build。

human-in-the-loop 也落在 workflow 机制上。AgentRequestInfoExecutor 收到 agent response 后调用 ctx.request_info(...)；如果用户给了补充消息，就回到 agent executor 继续；如果没有补充消息，就 approve 原响应。 AgentApprovalExecutor 实际上包装了一个内部 workflow，里面有 agent executor 和 request info executor 的循环。 源码在 AgentRequestInfoExecutor 和 AgentApprovalExecutor。

对报告任务来说，这里只完成了“草稿是否获准”的判断，还没有发布。一个单独的 publisher executor 应消费 approved draft：补充意见会把草稿退回写作者，拒绝会终止发布，批准才允许调用外部发布接口。 外部系统返回 publication_id 后，Workflow 才把状态写成 published。草稿被产出、 负责人验证、发布系统采用，不能被一个 approve 动作压成同一状态。

group chat 同样没有回到 AutoGen 的 topic runtime，而是用 orchestrator 和 workflow graph 表达。 GroupChatOrchestrator 用 selection function 挑选下一位 participant，广播上下文，收集 response，保存 conversation， 检查 termination 或 round limit 后继续下一轮。AgentBasedGroupChatOrchestrator 则让一个 agent 产出结构化选择结果。 证据在 group chat module overview、 selection-function orchestrator 和 group chat loop。

十一、Hosting 把 channel、session、checkpoint 接到服务层

生产系统最后还要有入口：HTTP、WebSocket、Teams、Slack，或者其他 channel。MAF 的 hosting 包把这个故事再往外推一层。 AgentFrameworkHost 是 Starlette wrapper：接收一个 hostable target，也就是 agent 或 Workflow， 再接收一组 channels；每个 channel 贡献 routes，host 通过 ChannelContext 暴露 run 和 run_stream。 证据在 host module overview 和 ChannelContext。

host 构造函数还能看出它对 workflow 的运行责任：target 可以是 agent 或 workflow；channels 挂到 channel path； workflow target 可以配置 checkpoint_location 或 state_dir，从而跨请求持久化 workflow checkpoints； host 还维护 session aliases，并防止 workflow 自己的 checkpoint storage 与 host-managed checkpoint 双重配置。 源码在 AgentFrameworkHost.__init__ 和 checkpoint ownership。

这里的“可以配置”是关键限定。Hosting dispatch 会按 target 类型选择 Agent 或 Workflow；本文的生产报告选择 Workflow。 若 state_dir=None 且没有外部 checkpoint storage，host 管理的相关状态仍停留在内存，进程退出后不能恢复。 所以 production-ready 的结论必须带着存储、isolation key、重启测试和外部发布幂等性一起验收。

这就是从 AutoGen 到 MAF 的核心转向：AutoGen 的中心是多 agent message runtime，MAF 的中心是可部署的 agent/workflow surface。前者让你研究和表达 agent 对话模式，后者把同类能力接到 provider flexibility、HITL、 checkpoint、channel hosting 和 observability 上。

十二、和前几篇放在一起看

下一篇会看 CrewAI。它的关键词不会是 runtime bus，而是角色、任务、crew、process、 flow、knowledge 和 memory：它更像把团队协作流程直接建模成 agent application。

参考源码与文档

• AutoGen README
• AutoGen AgentRuntime
• AutoGen SingleThreadedAgentRuntime
• AutoGen routed agent handlers
• AutoGen AgentChat ChatAgent
• AutoGen AgentChat BaseGroupChat
• Microsoft Agent Framework README
• MAF Agent
• MAF Workflow
• MAF sequential orchestration
• MAF group chat orchestration
• MAF hosting