哈哈哈，说起来，上个学期的一次组会，我导甩给煮啵一个任务——

把现在主流的Agent框架都跑一遍，写个对比报告。

煮啵当时心想，这不简单嘛，不就是跑几个demo。

然后。。。呜呜呜，煮啵花了一周，踩了一堆坑，写完报告之后对这个问题有了一些真实的判断。（咳咳，其实不是煮啵菜菜，让我狡辩一下，实际上是当时用的字节的trae！因为煮啵偷懒，所以说就让他给我跑，估计是提示词没写好，导致bug一堆，至于为什么不用Claude，呜呜呜，当时煮啵接私活，课题组的额度都不够用）

 

先说结论：没有”最好用”的Agent框架，只有”最适合你的场景”的框架。

这不是废话，是因为不同框架设计哲学完全不同，适合的场景差异很大——选错了框架，比没有框架还痛苦。

煮啵把主流框架都说一遍，最后给出选择建议。

---

煮啵先把Agent是什么说清楚

不然后面没法聊。

传统的大模型调用，是这样的：

用户输入 → 模型处理 → 输出结果

一次性的，线性的，没有记忆，没有工具，没有自主决策。

Agent是这样的：

用户给一个目标 ↓ 模型思考：要完成这个目标，需要做哪些步骤？ ↓ 模型决定调用某个工具（搜索、写代码、查数据库……） ↓ 拿到工具返回的结果，继续思考 ↓ 决定下一步做什么，或者判断目标已经完成 ↓ 输出最终结果

核心是：模型能自主决策，能调用工具，能多步执行，能根据中间结果调整计划。

Agent框架，就是帮你把这套流程搭起来的工具。

---

咳咳，然后，煮啵把主流框架逐个说一下叭

LangChain

最老牌，生态最大，文档最全，Stack Overflow上能找到答案最多。

它在做什么：

LangChain本质上是一个胶水层——把各种大模型API、各种工具（搜索引擎、数据库、计算器……）、各种数据源，用统一的接口包起来，让你能快速把它们拼在一起。

核心概念有几个：

Chain——把多个操作串联起来，A的输出是B的输入，B的输出是C的输入。

Agent——让模型自主决定调用哪个工具，调用几次，什么时候停。

Memory——给对话加上记忆，让模型知道前面说了什么。

Tool——各种外部工具的封装，搜索、代码执行、数据库查询……

煮啵的真实体验：

上手快，文档多，demo跑起来很顺。

但煮啵在真实项目里用LangChain，还是踩了不少坑——

比如说，抽象层太多，出了问题不好调试。你不知道中间哪个环节出了问题，因为被包了太多层。

并且它的版本更新太频繁，而且经常breaking change，上周写的代码这周就跑不了。

还有！灵活性受限，如果你的需求不在它设计的框架内，改起来很痛苦。（相信改过的懂的都懂）

它适合的场景：快速验证想法，做demo，需求比较标准化的RAG应用。

不适合的场景：需要精细控制每一步的生产级应用，需要高度定制化的Agent逻辑。

---

LangGraph

LangChain团队出的，算是LangChain的进化版，专门为复杂Agent设计的。

它在做什么：

煮啵的理解是，LangGraph把Agent的执行流程，建模成一个有向图（Graph）。

节点是操作（调用模型、调用工具、处理数据……），边是节点之间的转移关系，可以有条件分支，可以有循环。

like this:

# 一个简单的LangGraph例子 from langgraph.graph import StateGraph def agent_node(state): # 模型决定下一步 ... def tool_node(state): # 执行工具调用 ... graph = StateGraph(State) graph.add_node("agent", agent_node) graph.add_node("tool", tool_node) graph.add_edge("agent", "tool") graph.add_conditional_edges("tool", should_continue, {...})

煮啵的真实体验：

用起来，它确实比LangChain灵活很多，能表达更复杂的Agent逻辑。

并且，图的概念让执行流程变得清晰，调试比LangChain容易一嘟嘟。

还支持循环，煮啵感觉这个很重要——Agent经常需要”做一步，看结果，再决定下一步”，有了循环才能真正实现这个逻辑。

另外也支持Human-in-the-loop，在某个节点暂停，让人类审核，再继续。煮啵感觉这个在生产级应用里很有用，因为不是所有操作都适合完全自动化。

嗯，还有什么呢，嗯，它还支持持久化状态，中断之后能从断点继续。

然后说说缺点：

煮啵认为，它学习曲线比LangChain陡，概念更多，上手要花时间。

适合的场景：需要复杂控制流的Agent，需要条件分支、循环、人机协作的场景。

---

AutoGen（微软）

这个是微软出的，专注于多智能体（Multi-Agent）协作的东东。

它在做什么：

煮啵认为，AutoGen的核心思路就是：让多个Agent互相对话，协作完成任务。

比如说，最基础的模式是两个Agent——一个AssistantAgent（负责生成方案），一个UserProxyAgent（负责执行代码、给反馈）。

from autogen import AssistantAgent, UserProxyAgent assistant = AssistantAgent( name="assistant", llm_config={"model": "gpt-4"} ) user_proxy = UserProxyAgent( name="user_proxy", code_execution_config={"work_dir": "coding"} ) user_proxy.initiate_chat( assistant, message="帮我写一个分析股票数据的Python脚本" )

两个Agent来回聊，直到任务完成。

那么，更复杂的模式呢？就是多个专业Agent（研究员Agent、写作Agent、审查Agent……）组成一个团队，分工协作。

煮啵的真实体验：

额，它在代码生成任务上表现很好——让Agent写代码，执行代码，看报错，修复，再执行，这个循环AutoGen做得很流畅。

另外，煮啵感觉它的多Agent协作的思路很有意思，适合那种真的需要多个角色分工的复杂任务。

咳咳，然后再扒扒缺点：

煮啵使用发现，它的对话式的交互有时候绕弯路，两个Agent来回聊了很多圈才解决一个本来可以一步搞定的问题。

另外，Token消耗比单Agent方案高很多，因为每次Agent都要读取完整的对话历史。不适合煮啵这样的穷鬼呜呜呜。

适合的场景：代码生成和调试、需要多角色分工的复杂任务、研究型的探索任务。

---

CrewAI

这个也是做多Agent的，不过煮啵认为，它的设计哲学和AutoGen不同。

它在做什么：

CrewAI把多Agent组织成一个”团队”（Crew），每个Agent有明确的角色（Role）、目标（Goal）、背景（Backstory），Agent之间按照定义好的流程协作。

from crewai import Agent, Task, Crew researcher = Agent( role="研究员", goal="找到关于某个话题最新最准确的信息", backstory="你是一个经验丰富的研究员，善于从海量信息中提炼关键内容", tools=[search_tool] ) writer = Agent( role="写作专家", goal="把研究结果写成高质量的文章", backstory="你是一个专业作家，擅长把复杂信息变成清晰易读的内容" ) research_task = Task( description="研究AI在医疗领域的最新进展", agent=researcher ) write_task = Task( description="根据研究结果写一篇2000字的文章", agent=writer ) crew = Crew( agents=[researcher, writer], tasks=[research_task, write_task] ) result = crew.kickoff()

煮啵的真实体验：

首先，它上手比AutoGen简单，角色定义清晰，适合那种任务流程相对固定的场景。

并且，Role/Goal/Backstory这套设计，让Agent的行为更可预测。

然后呢，缺点也是有滴：

首先，煮啵感觉，它的灵活性不如LangGraph，任务流程比较固定，动态调整难度大。

适合的场景：内容生成流水线（研究→写作→审查→发布）、报告生成、有固定工作流的自动化任务。

---

Dify

这个和上面几个不一样，它是一个有图形界面的平台，不是纯代码框架。（并且去年很火哈哈哈）

它在做什么：

Dify提供一个可视化的界面，让你用拖拽的方式搭建AI应用，包括RAG应用、Agent工作流……

对不想写太多代码的人很友好，也支持API调用，可以集成到自己的系统里。

真实体验：

部署自己的私有化实例，数据不出公司，这一点在企业场景里很有价值。（并且煮啵去实习的时候，很多公司都搭建了这个）

另外，上手快，搭一个基础的RAG应用可能只要半小时。

有完整的模型管理、知识库管理、用户管理界面。

额，至于缺点：

灵活性受限算一个，有一说一，煮啵感觉要是有复杂的Agent逻辑在可视化界面里表达起来很别扭。

适合的场景：企业内部知识库问答、不想写太多代码的团队、需要快速验证业务场景的产品。

---

OpenAI Assistants API

这个是直接用OpenAI提供的原生Agent能力，不需要额外的框架。

它在做什么：

OpenAI把Agent的核心能力（工具调用、代码执行、文件处理、记忆管理）封装成API，你直接调用，不需要自己管理状态和上下文。

内置了三个工具：Code Interpreter（执行Python代码）、File Search（检索上传的文件）、Function Calling（调用你自定义的函数）。

煮啵的真实体验：

如果你的Agent逻辑不复杂，这个是最省事的选择——OpenAI帮你管理线程、管理上下文、管理工具调用，你只需要定义工具和处理结果。

缺点：完全依赖OpenAI，不能用其他模型，成本相对高，数据主权问题在某些场景下是红线。

适合的场景：快速验证Agent想法、个人项目、对OpenAI有依赖的应用。

---

Semantic Kernel（微软）

企业级的AI应用框架，也是微软在Azure AI上重点推的东西。

它在做什么：

Semantic Kernel的设计目标是企业级可靠性——支持多种模型（OpenAI、Azure OpenAI、Hugging Face……），有严格的插件体系，支持企业级的安全和合规需求。

核心概念：

Kernel——整个框架的核心，管理模型、插件、记忆。

Plugin——功能模块，可以是原生代码，也可以是语义函数（用自然语言描述的功能）。

Planner——让模型根据用户目标，自动规划调用哪些插件、以什么顺序调用。

煮啵的真实体验：

.NET生态支持很好，Java和Python次之。如果你们公司的技术栈是.NET，Semantic Kernel是自然的选择。（咳咳，可能是这样，煮啵已经忘记了哈哈哈，当时的感觉是这样嘟）

企业级功能完善，日志、监控、安全、合规，都有对应的解决方案。

缺点：对Python开发者来说，比LangChain重，概念更多，上手成本更高。

适合的场景：企业级应用，微软技术栈团队，对安全合规要求高的场景。

---

Phidata

相对小众，但煮啵觉得值得单独提一下。

它在做什么：

Phidata的设计哲学是简洁——用最少的代码，搭出一个能跑的Agent。

from phi.agent import Agent from phi.tools.duckduckgo import DuckDuckGo agent = Agent( tools=[DuckDuckGo()], show_tool_calls=True, markdown=True ) agent.print_response("搜索一下最近AI领域的重要进展", stream=True)

就这几行，一个有搜索能力的Agent就跑起来了。

煮啵的真实体验：

代码量极少，上手极快，适合快速原型。

内置了很多常用工具（搜索、数据库、文件处理……），不需要自己封装。（这点要夸夸哈哈哈）

缺点：社区小，文档相对少，出了问题不容易找到答案，生产级使用的案例不多。

适合的场景：快速原型验证、个人项目、需要快速搭出一个demo。

---

一个让煮啵印象很深的现象

跑完这些框架，煮啵发现一件事：

大多数Agent框架的demo，跑起来都很漂亮。

但一旦换成真实的、复杂的、有边界情况的任务，差距就出来了。

比如：让Agent做一个需要多步推理的任务，中间某一步工具调用失败了，Agent怎么处理？

有些框架直接报错崩掉。

有些框架让Agent继续往下走，但忽略了那一步的错误，最终给出一个错误的结果，还是正经格式的，你看不出来哪里不对。

有些框架让Agent识别到错误，尝试用不同的方法重试，最终给出了正确结果——但这需要你在设计工作流的时候，把错误处理的逻辑显式地加进去。

这件事说明一个很重要的判断：

Agent框架的真实能力，不在demo里，在边界情况的处理上。

选框架之前，最好把你真实场景里最复杂、最容易出错的那个case，先拿去跑一遍。跑通了，再考虑要不要用。

另外，哈哈哈哈，希望技术可以再多进步进步！

 

---

然后煮啵整理了一张对比表，方便读者姥爷们收藏

框架	上手难度	灵活性	多Agent	生产可用性	适合场景
LangChain	低	中	支持	中	快速原型、标准RAG
LangGraph	中	高	支持	高	复杂控制流、生产级Agent
AutoGen	中	中	核心特性	中	代码生成、多角色协作
CrewAI	低	中	核心特性	中	固定流程的内容生产
Dify	极低	低	支持	中高	企业知识库、非技术团队
OpenAI Assistants	低	低	不支持	中	快速验证、个人项目
Semantic Kernel	高	高	支持	高	企业级、微软技术栈
Phidata	极低	中	支持	低	快速原型、个人项目

---

至于读者姥爷们怎么选，煮啵来说点干货

场景一：你在做RAG应用，需要给用户提供基于文档的问答。

首选Dify，如果你不想写太多代码的话——部署私有化实例，上传文档，配好模型，半天能跑起来。

如果你需要精细控制检索逻辑、重排序、混合检索——用LangChain或者LangGraph自己搭，灵活性更高。

场景二：你需要一个能自主完成复杂任务的Agent，中间有很多步骤，有条件分支，有循环。

用LangGraph。

它的图结构能清晰地表达复杂的控制流，调试方便，生产级可靠性在这几个框架里算高的。

学习曲线有点陡，但值得。

场景三：你需要让多个Agent协作，每个Agent有自己的职责。

如果任务流程相对固定——用CrewAI，上手快，角色定义清晰。

如果任务流程需要动态调整，Agent之间的交互比较复杂——用AutoGen或者LangGraph。

场景四：你需要让Agent生成代码，执行代码，根据执行结果修复，反复迭代。

用AutoGen，这是它最强的场景，两个Agent（一个生成，一个执行验证）来回配合，代码调试任务做得很流畅。

场景五：你是企业级用户，有严格的安全合规要求，技术栈是微软系的。

用Semantic Kernel，这就是它设计的目标场景。

场景六：你想快速验证一个Agent想法，不想花时间配框架。

用OpenAI Assistants API或者Phidata，最省事。

验证完想法，再决定要不要用更完整的框架重新实现。

---

然后说一个很多教程没有告诉你的东西（咳咳，可能）

煮啵跑完这些框架，最大的感受不是”哪个框架最好”，而是：

大多数Agent失败，不是框架的问题，是Prompt的问题。

框架只是骨架，真正决定Agent能不能好好工作的，是你怎么告诉模型它该做什么、不该做什么、遇到什么情况该怎么处理。

煮啵在实验室做Agent相关的实验，发现同一个框架，Prompt写得好和写得差，效果差距能有几倍。（相信懂的都懂哈哈哈）

然后这里煮啵就再写几个真实观察到的Prompt问题叭：

工具描述写得太模糊。

你给Agent提供了一个搜索工具，描述写的是”搜索信息”——Agent不知道什么时候该用它，什么时候不该用，导致要么不用，要么乱用。

写成”当需要获取2023年之后的实时信息、或者需要查询特定事实时，使用此工具”——Agent的行为就会稳定很多。

没有告诉Agent遇到错误怎么处理。

Agent调用工具失败了，如果你没有在Prompt里说清楚该怎么做，它可能直接放弃，给你一个”我无法完成这个任务”，或者更糟糕，编一个答案出来。

显式地告诉它：”如果工具调用失败，尝试不同的参数重试一次，如果还是失败，告诉用户失败的原因并说明你能提供什么替代方案。”

没有给Agent明确的停止条件。

有些Agent会陷入无限循环——一直调用工具，一直觉得任务没完成，token烧完才停。

在Prompt里明确告诉它：”当你已经有足够的信息回答用户的问题时，直接给出答案，不要继续调用工具。”

输出格式没有约束。

让Agent输出结构化数据，如果不加格式约束，它的输出格式每次都不一样，后续处理很痛苦。

用JSON Schema明确约束输出格式，或者在Prompt里给出格式示例。

 

---

一个更底层的判断

煮啵在实验室等实验结果的时候，想过一个问题：

Agent框架这个东西，本质上在解决什么问题？

煮啵认为：它在解决”如何让模型可靠地完成需要多步骤、多工具、多决策的复杂任务”这个问题。

但这个问题，今天所有的框架都没有完全解决。

当前所有Agent框架，在真实的、高复杂度的任务上，成功率都不够高——模型会犯错，工具会失败，多步骤任务的累积误差会让最终结果偏离目标。

这不是框架设计的问题，是当前大模型本身的局限——模型的推理能力、工具使用能力、长程规划能力，还没有到”完全可靠”的程度。

这意味着什么？

现在做Agent，不能完全信任Agent自主运行，需要在关键节点加入人工检查。

不要设计一个”扔进去一个目标，等着拿结果”的全自动Agent，而是设计一个”在关键决策节点告诉人类，让人类确认之后继续”的半自动Agent。

LangGraph的Human-in-the-loop就是为这个设计的。

这个判断，在你设计Agent系统的时候很重要——不要被demo的顺畅骗到，真实场景里Agent需要人来兜底。

---

还有一件事要说

这个领域迭代速度极快。

煮啵写这篇的时候是2026年初，说不定你看到这篇的时候，某个框架已经出了大版本更新，某个新的框架已经异军突起，某个今天还在用的框架已经被社区抛弃了。

而且解答这类问题的大模型，训练数据可能有截止日期，它给你的信息不一定是最新的。

这类技术选型问题，最准确的信息来源：

各框架的GitHub star增长趋势——star在涨，说明社区在活跃。

各框架的issue响应速度——maintainer多久回复，说明这个项目有没有人认真维护。

HuggingFace、Reddit的r/LocalLLaMA、Discord里的真实用户讨论——比任何测评文章都真实，因为都是踩过坑的人在说话。

直接拿你的真实场景去跑——任何测评都替代不了这个，因为你的场景是独特的。

 

---

最后，让煮啵用一句话收尾叭：

如果煮啵现在要做一个新的Agent项目，会这样选——

需要快速验证想法：Phidata或者OpenAI Assistants API。

需要复杂控制流、要上生产：LangGraph。

需要多Agent协作、任务流程固定：CrewAI。

需要多Agent协作、需要写代码执行：AutoGen。

企业级、微软技术栈：Semantic Kernel。

不想写代码、做知识库问答：Dify。

但在选框架之前，先把你的Agent的Prompt写好——因为框架选对了Prompt写烂，不如框架选烂了Prompt写好。

框架是骨架，Prompt是灵魂。

咳咳，好了煮啵该去恰饭了，有想法或者指正评论区见，全体起立，下课家人们！