做多智能体，很多人第一反应是 LangGraph 或 CrewAI。但微软 AutoGen 在 v0.4 重写后走了一条不同的路：事件驱动、异步消息、actor 式的智能体节点。理解它的抽象，对你设计复杂协作流程很有帮助。
AutoGen v0.4 的抽象和 CrewAI 差在哪？
CrewAI 偏「角色分工」：定义几个角色，给个流程顺序。AutoGen v0.4 偏「消息总线」：每个智能体是一个异步 actor，通过结构化消息通信，谁下一步发言由事件和规则决定。它更适合「多个自主进程互相发消息」，而不是「一条流水线顺序执行」。
第一个多智能体怎么搭起来？
起一个团队：一个组织者负责拆任务，两个执行者并行干活，一个审核者汇总。关键不是把它们串成直线，而是定义好「什么消息触发哪个智能体」。组织者发出任务已拆分事件后，两个执行者各自监听并开工，完成后发回结果就绪，审核者等齐了再汇总。你会发现这套写法天然适合并行，而不是被迫在单线程里排队。
什么场景才该选 AutoGen？
如果你的协作是「一个主管派活、几个工人并行、最后汇总」这种天然异步结构，AutoGen v0.4 的事件模型写起来很顺。如果是严格的有向无环流水线、节点间状态明确传递，别的编排框架可能更直观。
自动兜底有什么隐患？
事件驱动意味着调试变难：报错不再是「第几步崩了」，而是「哪个事件没被谁接住」。第一天就要把消息流打日志，否则出了问题你只能在事件队列里盲人摸象。
中间状态该存在哪才安全？
事件驱动跑起来后，中间状态很容易散落在各个 actor 内存里，进程一重启就全丢。重要的任务进度要落到外部存储，让每个 actor 重启后能从持久化状态恢复。这件事在演示阶段看不出必要，一旦你让它跑过夜任务，就会庆幸早做了——否则半夜任务崩了，第二天只能从头再来。
这套事件范式帮你想清什么？
多智能体框架没有银弹，只有范式匹配。把 AutoGen v0.4 当成异步消息式协作的样本跑一遍，你对「智能体之间到底怎么协作」的理解会上一个台阶——哪怕最后你仍用别的框架。
去论坛讨论
这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：AutoGen多智能体