上篇聊了 Function Calling 的进阶玩法——并行工具调用、流式输出、多层 Agent 架构。写完那篇之后，有个问题一直在我脑子里转：如果我有好几个 Agent，分别负责不同的任务，它们之间怎么配合？谁来调度？

这个问题我踩过坑。最早做多 Agent 的时候，我天真地写了一大堆 if-else 来手动调度——”如果天气 Agent 查完温度，就把结果传给行程 Agent”——结果代码写成了一个意大利面条，改一处逻辑碰三处依赖。后来我才意识到，多 Agent 协作不是 UI 上画几个框那么简单的，需要专门的编排框架。

目前市面上最热的三个编排框架：LangGraph、AutoGen、CrewAI。这三周我挨个试了一遍，今天聊聊我的真实感受和选型建议。

三大框架概览

先上结论，再细说。

讲一个我发现的小细节：选框架之前先想清楚你要解决什么问题。如果只是”两个 Agent 互相传话跑个流程”，这三个都能干。但如果涉及状态持久化、人工介入、长周期任务——区别就来了。

LangGraph：图编排的”工业标准”

LangGraph 给我的第一印象是：这东西设计得像一个状态机框架，而不是一个”Agent 框架”。它的核心概念就两个：Node（节点）和Edge（边）。节点就是你的一步操作，边决定哪一步之后走哪条路。

我拿它搭过一个”自动更新博客”的小工具，伪代码如下：

from langgraph.graph import StateGraph, END

class BlogState(dict):
    topic: str
    draft: str = ""
    review: str = ""
    published: bool = False

graph = StateGraph(BlogState)

def write_draft(state):
    state["draft"] = "..."
    return state

def review_article(state):
    state["review"] = "..."
    return state

graph.add_node("write", write_draft)
graph.add_node("review", review_article)
graph.set_entry_point("write")
graph.add_edge("write", "review")
graph.add_conditional_edges(
    "review",
    lambda s: "publish" if "通过" in s["review"] else "rewrite"
)
graph.add_node("publish", publish_post)
graph.add_node("rewrite", rewrite_draft)
graph.add_edge("publish", END)
graph.add_edge("rewrite", "write")

app = graph.compile()
result = app.invoke({"topic": "LangGraph 入门"})

LangGraph 最强的点是有状态管理——它内置了持久化机制（checkpoint），任务跑了三小时后服务器重启，回来能接着跑。这在长周期 Agent 场景下太重要了。但它也有代价：概念多、心智负担重，写一个小功能要理解 StateGraph、Node、Edge、ConditionalEdge 一堆东西。

适合场景：需要状态持久化、人工介入（human-in-the-loop）、复杂分支逻辑的 Agent 系统。

AutoGen：对话式多 Agent 的老大哥

AutoGen 我试得最早，因为它 Star 最多、社区最活跃。它的逻辑很好理解——你不是给 Agent 写”工作流”，而是让 Agent 之间互相对话。一个 AssistantAgent 负责回答，一个 UserProxyAgent 负责执行代码或调用 API，两者来回对话，任务就完成了。

不过，我写这篇文章的时候查了一下，AutoGen 官方仓库已经进入维护模式了。Microsoft 把重心转到了新的 Microsoft Agent Framework（MAF）。AutoGen 不会有新功能，只修 bug，社区维护。

这是个挺大的变化。如果你现在才开始做多 Agent，我建议直接看 MAF，别从 AutoGen 起步了。但如果你已经在用 AutoGen，迁移到 MAF 也不难，官方有迁移指南。

CrewAI：角色扮演式编排，上手最快

CrewAI 是三个里我上手最快的。它的设计哲学很直接：把 Agent 当成”员工”，给每个员工分配角色（Role）、目标（Goal）、背景故事（Backstory），然后定义任务清单（Task），最后组一个 Crew 来跑。

from crewai import Agent, Task, Crew

researcher = Agent(
    role="技术调研员",
    goal="收集最新的 LLM 技术动态",
    backstory="你是一名资深 AI 研究员，擅长跟踪前沿论文",
)

writer = Agent(
    role="技术写手",
    goal="把调研结果写成通俗易懂的文章",
    backstory="你擅长把复杂的技术概念翻译成大白话",
)

research_task = Task(
    description="调研 2026 年 Q2 大模型最新进展",
    agent=researcher,
    expected_output="结构化调研报告"
)

write_task = Task(
    description="基于调研报告撰写一篇 1500 字的文章",
    agent=writer,
    expected_output="完整文章"
)

crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, write_task],
    process="sequential"
)

result = crew.kickoff()

CrewAI 做得好的一点是：你不需要理解图论、状态机这些底层概念，写代码的思路跟真实团队协作高度一致。对于一个前端出身的人（比如我）来说，这种”直觉友好”的设计太重要了。

但它也有硬伤：复杂场景控制力不足。如果工作流里有嵌套条件分支、循环、人工审核节点，CrewAI 的”顺序执行 + 简单依赖”模型就不太够用了——这时候还得回到 LangGraph。

怎么选？我的经验法则

试了三周之后，我给自己定了一个选型标准：

• 简单流水线（A 做完给 B，B 做完给 C）→ CrewAI，代码最少，心最不累
• 有状态、需要人工介入、条件分支多 → LangGraph，虽然重但稳
• 微软生态、已有 Azure 投入 → MAF（AutoGen 的继任者）
• 只是想快速验证 ML 原型 → 用 CrewAI 先跑通，复杂了再切 LangGraph

另外有个坑我要提一下：别一上来就上多 Agent。我之前犯过这个错——听人说多 Agent 是趋势，二话不说拿 LangGraph 搭了三个 Agent，结果问题本身用单 Agent + Function Calling 30 行代码就解决了。多 Agent 带来的是复杂性，只有当一个 Agent 搞不定（比如需要不同知识背景的协作、或者任务天然可以拆分并行）的时候才值得引入。

总结

三个框架各有擅场：LangGraph 胜在状态管理和复杂流程控制，CrewAI 胜在开发效率和直觉友好度，AutoGen 则正在被它的接班人 MAF 取代。选哪个取决于你的场景——先想清楚问题是什么，再选工具，别反过来。

下期预告：Agent 记忆系统实战——短期记忆、长期记忆与知识图谱。Agent 怎么记住上下文、跨会话回忆信息、用知识图谱做长期记忆——踩坑经验到时候一并分享。

参考资料

• LangGraph 官方文档
• LangGraph GitHub 仓库
• AutoGen GitHub 仓库（维护模式）
• Microsoft Agent Framework（MAF）
• CrewAI 官方文档
• CrewAI GitHub 仓库
• AutoGen → MAF 迁移指南

转载请注明：Falost的小窝 » Agent 通信与编排框架选型：LangGraph vs AutoGen vs CrewAI 方案对比与实践