3、主流Agent框架选型：LangGraph、AutoGen、CrewAI、Semantic Kernel、Dify.AI的对比与选型策略

聊到Agent落地，选框架是绕不开的坎。

我见过不少团队，一上来就追着最火的框架跑。结果呢？做到一半发现根本hold不住。要么是图编排太复杂，要么是多Agent协作根本跑不通。嗯，今天我就把这五个主流框架掰开揉碎了讲清楚。

3.1 为什么需要Agent框架？

说白了，大模型本身只是个“大脑”。你要让它干活，得给它装上手和脚。这就是Agent框架干的事——编排、记忆、工具调用、多Agent协作。

我自己在项目中踩过最大的坑，就是自己手写Agent编排逻辑。一开始觉得挺简单，不就是调API嘛。结果状态管理、错误重试、上下文传递……越写越像在造轮子。后来我学乖了，直接用现成框架。

3.2 五大框架横向对比

先给个全景图，方便你快速建立认知。

框架	核心定位	编程语言	适合场景	学习曲线
LangGraph	有向图编排	Python	复杂流程、状态机	中高
AutoGen	多Agent对话	Python	多角色协作、辩论	中
CrewAI	角色分工协作	Python	任务分配、流水线	低
Semantic Kernel	企业级集成	C#/Python	.NET生态、Azure	中
Dify.AI	低代码平台	可视化	快速原型、非技术人员	低

3.3 逐个拆解：我的实战感受

3.3.1 LangGraph —— 复杂流程的王者

LangGraph是我目前在复杂业务场景中最常用的框架。它的核心思想是用“有向图”来描述Agent的行为。

你想想看，一个真实的业务流程，比如“客服工单处理”，它绝对不是线性的。可能先分类，然后判断是否需要人工介入，再决定是自动回复还是升级处理。这里面有分支、有循环、有并行。LangGraph就是为这种场景设计的。

from langgraph.graph import StateGraph, END

# 定义状态
class AgentState(TypedDict):
    input: str
    processed: bool
    output: str

# 定义节点
def process_input(state: AgentState):
    # 处理逻辑
    return {"processed": True}

def generate_output(state: AgentState):
    # 生成输出
    return {"output": f"结果: {state['input']}"}

# 构建图
graph = StateGraph(AgentState)
graph.add_node("process", process_input)
graph.add_node("generate", generate_output)
graph.add_edge("process", "generate")
graph.set_entry_point("process")
graph.set_finish_point("generate")

app = graph.compile()

不过要注意，LangGraph的学习曲线确实不低。如果你只是做个简单的问答机器人，用它就有点大材小用了。

3.3.2 AutoGen —— 多Agent对话的利器

AutoGen是微软出品，主打“多Agent对话”。它的设计哲学很有意思——让Agent像人一样聊天、辩论、协作。

我记得有一次做“合同审核”项目，需要三个角色：法务Agent、财务Agent、业务Agent。它们需要针对同一份合同，从各自角度提出修改意见，最后达成共识。用AutoGen的ConversableAgent，我只需要定义好每个Agent的角色和工具，它们自己就会“聊”起来。

from autogen import AssistantAgent, UserProxyAgent

# 定义法务Agent
legal_agent = AssistantAgent(
    name="Legal",
    system_message="你是法务专家，负责审核合同条款的合规性。",
    llm_config={"config_list": [{"model": "gpt-4", "api_key": "..."}]}
)

# 定义用户代理
user_proxy = UserProxyAgent(
    name="User",
    human_input_mode="NEVER",
    max_consecutive_auto_reply=10
)

# 启动对话
user_proxy.initiate_chat(
    legal_agent,
    message="请审核这份NDA协议的第3条保密条款。"
)

3.3.3 CrewAI —— 最易上手的角色分工框架

如果你团队里有非技术人员，或者你想快速验证一个想法，CrewAI是首选。它的设计非常直观：定义Agent（角色）、定义Task（任务）、然后让Crew（团队）去执行。

说白了，CrewAI就是把“项目管理”的思路搬到了Agent世界里。每个Agent有明确的职责，每个Task有明确的输入输出。我有个客户，他们的运营团队用CrewAI三天就搭出了一个“竞品分析自动化”流程。

from crewai import Agent, Task, Crew

# 定义分析师Agent
analyst = Agent(
    role="市场分析师",
    goal="分析竞品动态",
    backstory="你是一名资深的市场分析师，擅长从公开信息中提取洞察。",
    verbose=True
)

# 定义任务
task = Task(
    description="分析最近一个月内，竞品A的产品更新和用户反馈。",
    agent=analyst
)

# 组建团队并执行
crew = Crew(
    agents=[analyst],
    tasks=[task]
)
result = crew.kickoff()

3.3.4 Semantic Kernel —— 企业级集成的首选

Semantic Kernel（简称SK）也是微软出品，但它和AutoGen的定位完全不同。SK更像是一个“企业级AI编排中间件”。它深度集成Azure生态，支持C#和Python。

如果你所在的企业用的是.NET技术栈，或者需要和Azure OpenAI Service、Azure Cognitive Search等深度集成，SK是唯一的选择。我在一个制造业客户的项目中，用SK把他们的ERP系统和LLM打通了，实现了“自然语言查库存”的功能。

using Microsoft.SemanticKernel;

var kernel = Kernel.CreateBuilder()
    .AddAzureOpenAIChatCompletion(
        deploymentName: "gpt-4",
        endpoint: "https://xxx.openai.azure.com/",
        apiKey: "xxx"
    )
    .Build();

// 注册原生函数
kernel.ImportSkill(new InventorySkill(), "Inventory");

// 执行自然语言查询
var result = await kernel.InvokeAsync(
    "Inventory.GetStock",
    new() { ["productName"] = "螺丝钉" }
);

3.3.5 Dify.AI —— 低代码的快速通道

Dify.AI是这五个框架里唯一一个“可视化平台”。你不需要写代码，拖拖拽拽就能搭出一个Agent应用。

我经常用它来做两件事：一是给客户做POC（概念验证），二是让业务人员自己搭建简单的自动化流程。比如“自动生成周报”、“客户邮件分类回复”这类场景，业务人员自己就能搞定。

但Dify的缺点也很明显——它是个“黑盒”。一旦你的需求超出了它预设的模板，你就得回到代码层面。而且它的多Agent协作能力比较弱，目前主要还是单Agent + 工具调用的模式。

3.4 选型策略：我的决策框架

讲了这么多，到底怎么选？我总结了一个“三问决策法”：

1. 你的流程有多复杂？
   • 线性流程 → CrewAI 或 Dify
   • 有分支/循环/状态机 → LangGraph
2. 你需要几个Agent协作？
   • 单Agent + 工具 → Dify 或 Semantic Kernel
   • 多Agent对话/辩论 → AutoGen
   • 多Agent分工协作 → CrewAI
3. 你的技术栈和团队能力？
   • .NET/Azure生态 → Semantic Kernel
   • 非技术人员主导 → Dify
   • Python技术团队 → LangGraph 或 AutoGen

3.5 知识体系全景图

下面这张图，是我自己梳理的Agent框架选型决策树。你可以把它当作一个快速参考。

嗯，框架选型这块，我踩过的坑不少。但只要你掌握了这套决策逻辑，至少能避开80%的坑。记住，没有银弹，只有最合适的。

---