Agent 框架怎么选？我踩坑半年的答案

从 LangChain 到 CrewAI 到 AutoGen，踩坑跑完一轮后聊聊 Agent 框架到底该怎么选，Star 数只是个参考，场景才是王道。

半年前开始搭多 Agent 知识库系统的时候，我信心满满地选了 Star 数最高的框架。

结果呢？跑了三周，重写两次。

这不是框架不好，是我选错了。今天把这半年的选型踩坑经历摊开聊聊，希望能帮你少走点弯路。

先说个扎心的事实：GitHub Star 数是最不靠谱的选型指标。

LangChain 135k Star，CrewAI 50k，AutoGen 57k。差距看着挺大，对不对？但你如果因为 Star 数选了 LangChain，然后发现项目只需要两个 Agent 互相传个消息，那这 135k Star 对你来说一文不值。

选框架之前，先搞清楚一个问题：你的 Agent 到底需要多复杂？

我把它分成四个层级。

第一层：单 Agent + 简单工具调用。

你要做的就是让 LLM 能查数据库、调 API、写文件。不需要记忆，不需要多轮对话，工具也就三五个。

这个场景下，OpenAI Agents SDK 是最舒服的选择。25k Star，体量小、文档清楚，10 行代码跑通第一个 Agent。学习曲线几乎为零，特别适合刚入门的同学。如果你们公司用的就是 OpenAI 的模型，那更没理由换别的。

代码量大概长这样：

from agents import Agent, Runner

agent = Agent(
    name="Assistant",
    instructions="You help users query data.",
    tools=[query_database, send_email]
)
result = Runner.run_sync(agent, "查一下昨天的订单量")

就五行，没了。

第二层：多步骤工作流 + 状态管理。

你的 Agent 需要跑一个流程——先查数据，根据结果决定下一步，可能还要循环几次。这时候线性 Chain 就不够用了，你需要一个有状态图。

LangGraph 是这里的最佳实践。30k Star，把工作流建模成有向图，支持条件分支、循环、持久化状态。

我的知识库项目最开始的查询流程就是拿 LangGraph 搭的：

from langgraph.graph import StateGraph, END

class AgentState(TypedDict):
    messages: list
    step: int

def search_node(state):
    # 查向量库
    return {"step": state["step"] + 1}

def decide_next(state):
    if state["step"] < 3:
        return "search"
    return END

graph = StateGraph(AgentState)
graph.add_node("search", search_node)
graph.add_conditional_edges("search", decide_next)

关键就在这里——add_conditional_edges 让你的 Agent 不再是死脑筋，能根据每轮结果调整方向。这是 LangGraph 的核心价值。

第三层：多 Agent 协作 + 角色分工。

你有多个 Agent，每个干不同的事，需要协作完成一个复杂任务。比如一个写代码、一个审代码、一个跑测试。

CrewAI 和 AutoGen 都适合这个场景，但思路完全不同。

CrewAI 走的是角色扮演路线。每个 Agent 有 Role、Goal、Backstory，多个 Agent 组一个 Crew。这个设计更像人类团队——你给每个人分配角色，他们自己协作。

from crewai import Agent, Task, Crew

researcher = Agent(
    role="Research Analyst",
    goal="Find relevant papers on RAG optimization",
    backstory="You're a senior research analyst..."
)

writer = Agent(
    role="Tech Writer",
    goal="Write a clean summary of findings",
    backstory="You transform research into readable content..."
)

task = Task(
    description="Research and summarize latest RAG techniques",
    agent=researcher
)

crew = Crew(agents=[researcher, writer], tasks=[task])

CrewAI 的优势是上手快、概念好理解。你给老板汇报的时候说"我们给 AI Agent 分配了角色"，他一听就懂。

但 CrewAI 也有坑。角色分工一旦复杂起来，Agent 之间容易互相干扰。我试过五个 Agent 组一个队，结果两个 Agent 抢同一个工具用，直接报错。

AutoGen 走的是事件驱动架构。它不跟你聊角色，它跟你聊事件和消息。每个 Agent 监听消息，处理完再发新消息出去。

AutoGen 的架构分四层：Studio（无代码原型）→ AgentChat（Python SDK）→ Core（分布式执行）→ Extensions。对生产环境更友好，支持 gRPC 跨进程部署和 Docker 隔离。

但代价是学习曲线陡很多。我花了一周才搞明白它的 event-driven 模型，CrewAI 的话一天就能上手。

所以这两者的选择其实很清楚：

• 场景固定、想快速验证 → CrewAI
• 要上生产、有 DevOps 能力 → AutoGen

第四层：全栈 TypeScript 应用。

你的技术栈是 Next.js，团队全员 TS，不想在 Python 和 JS 之间切来切去。

Mastra 是 2025 年冒出来的新秀，23k Star，原生 TypeScript，和 Next.js 无缝集成。你要的是前后端统一，那它是最优选。

不过生态还在长，社区资源不如 LangChain 丰富，遇到问题可能得自己啃源码。

---

说回我自己的项目。

我的多 Agent 知识库系统一开始踩了个大坑——我想一步到位，选了最重的框架。

结果发现，知识库的查询流程其实很简单：用户提问 → 向量检索 → LLM 生成答案。一个状态图 + 一个 Agent 就能搞定。硬上完整的多 Agent 编排框架，反而引入了多余的复杂度。

最后我的架构是：LangGraph 管工作流，底层自己封装工具调用层，需要协作的任务才用 AutoGen 的子模块。

这个组合的好处是，每个组件只负责自己擅长的事。LangGraph 帮我管流程状态，我自己写的工具层灵活可控，AutoGen 只有在真正需要多 Agent 协作时才上场。

你可能会问：为什么不直接用 LangChain 全家桶？也想过。但 LangChain 的抽象层太厚了，出了问题很难追。我更喜欢能看到底层的东西。

---

总结一下我的建议：

• 刚入门 → OpenAI Agents SDK，快速跑通再换
• 单 Agent + 流程控制 → LangGraph
• 多 Agent 协作、快速验证 → CrewAI
• 多 Agent 上生产 → AutoGen
• 全栈 TS → Mastra

选框架这事儿，跟挑工具一样——别管别人说哪把锤子最好，先看看你手里是什么钉子。

当你把 Star 数从决策因素里拿掉，回归到"我的场景需要什么"，答案通常就很清楚了。