# 011、Agent 开发框架对比：LangChain、AutoGPT、CrewAI、Semantic Kernel

从一次诡异的“Agent 死循环”说起

上个月帮团队排查一个生产问题：一个基于 LangChain 的客服 Agent，在用户问“帮我查一下订单”之后，居然连续调用了 17 次工具，最后把 OpenAI 的 API 额度跑光了。日志里看到它反复执行“查询订单→解析结果→发现信息不全→再次查询→再次解析”的循环，中间没有任何跳出逻辑。我盯着 trace 看了半小时，发现不是 prompt 写错了，而是框架本身的 ReAct 循环机制没有对“重复调用同一工具”做任何限制——这就是框架设计哲学带来的坑。

后来我用同样的需求在 CrewAI 上重写了一遍，同样的 LLM、同样的工具，循环问题消失了。因为 CrewAI 默认对每个 Agent 的任务执行次数做了硬限制，并且强制要求任务之间有明确的“输入输出契约”。这件事让我意识到：选框架不是在选“谁更强大”，而是在选“谁帮你管住了哪些边界”。

LangChain：瑞士军刀，但刀片容易划伤自己

LangChain 是目前生态最完整的 Agent 框架，没有之一。它的核心抽象是 Chain 和 Tool，Agent 本质上是一个“带循环的 Chain”。你写一个 Agent 的过程，就是在组装各种 Chain：LLMChain、RetrievalQAChain、ConversationChain……然后通过 AgentExecutor 驱动 ReAct 循环。

优点很突出：社区资源多到爆炸，任何你想得到的工具（Slack、数据库、API、本地文件）都有现成的集成。文档虽然写得像 API 手册，但至少能查到。对于快速原型验证，LangChain 是最快的——你甚至不需要理解 Agent 原理，照着示例改改 prompt 就能跑。

但坑也深：它的 AgentExecutor 默认是“无限循环”的。你给 Agent 一个工具，它就会一直调用，直到 LLM 自己决定停止。如果 LLM 抽风（比如温度设高了、prompt 里没写清楚停止条件），就会像开头那个案例一样死循环。我后来加了 max_iterations=5 和 early_stopping_method="generate" 才勉强控制住。另一个坑是 Tool 的输入输出格式：LangChain 的 Tool 要求输入输出都是字符串，如果你的工具返回 JSON，Agent 解析时经常丢字段。我习惯在每个 Tool 的 _run 方法里手动 json.dumps，然后在 prompt 里强调“输出必须是合法 JSON”——这其实是在给框架的缺陷打补丁。

适合场景：你需要快速集成大量外部工具，且团队有足够能力处理边界情况。不适合生产环境直接裸用，除非你愿意花时间写大量的 wrapper 和校验逻辑。

AutoGPT：理想很丰满，现实很骨感

AutoGPT 刚出来的时候，我激动了一晚上——终于有框架能“自动分解任务、自我反思、长期记忆”了。它的设计理念是“让 Agent 自己规划、执行、评估、迭代”，听起来像 AGI 的雏形。

实际用下来：它的核心是 任务队列 和 上下文窗口。Agent 会先生成一个任务列表，然后逐个执行，执行结果写回上下文，再根据上下文生成新任务。这个循环理论上可以无限持续，直到目标达成。

但问题在于：它太“自主”了。我试过一个简单任务：“帮我整理本周的代码 review 记录”。AutoGPT 先花了 3 分钟生成了 12 个子任务，包括“搜索 Git 仓库→过滤本周提交→提取 review 评论→总结格式→生成报告→检查报告完整性→如果报告不完整则重新生成……”——结果在“检查报告完整性”这一步，它认为报告“不够详细”，于是又生成了 5 个新任务去补充细节，最后跑了 20 分钟，生成了一个 8000 字的文档，而我只想要一个 200 字的摘要。

另一个致命问题：它的长期记忆用的是向量数据库（默认 Pinecone），但记忆的写入和检索逻辑非常粗糙。Agent 会把每一步的思考过程都存进去，导致检索时返回大量无关内容。我试过在 prompt 里加“只检索最近 3 条记忆”，但 AutoGPT 的 prompt 模板是硬编码的，改起来很麻烦。

适合场景：探索性任务，比如“帮我研究一下这个新技术，写一份报告”。不适合需要精确控制执行路径的场景。另外，它的 token 消耗是 LangChain 的 3-5 倍，钱包不够厚的话慎用。

CrewAI：给 Agent 上了“项目管理”的枷锁

CrewAI 是我最近半年用得最多的框架。它的核心思想是 多 Agent 协作，但和 LangChain 那种“一个 Agent 调多个工具”不同，CrewAI 让你定义多个 Agent，每个 Agent 有独立的角色、目标和工具，然后通过 Task 把它们串起来。

最让我舒服的设计：每个 Task 必须指定 Agent 和 expected_output。这意味着你必须在写代码时就明确“这个任务完成后，输出应该是什么格式”。比如一个“查询订单”的 Task，expected_output 是 {"order_id": str, "status": str, "items": list}。如果 Agent 的输出不符合这个格式，CrewAI 会强制重试（默认最多 3 次）。这个机制直接解决了 LangChain 里“Agent 输出格式不稳定”的问题。

另一个亮点：CrewAI 内置了 任务依赖管理。你可以定义 Task B 必须在 Task A 完成后才能执行，并且 Task B 可以引用 Task A 的输出。这听起来简单，但在 LangChain 里你需要自己写状态机或者用 SequentialChain 来实现，而 CrewAI 把这个做成了第一等公民。

但也不是没有坑：CrewAI 的 Agent 之间通信是通过“共享上下文”实现的，这个上下文默认是全部 Agent 可见的。如果你的 Agent 数量超过 3 个，上下文会迅速膨胀，LLM 的注意力会被稀释。我试过 5 个 Agent 协作，结果 Agent C 经常引用 Agent A 的中间结果，而不是 Agent B 的最终结果——因为上下文里所有历史记录都混在一起。解决方案是手动清理每个 Task 的 context 参数，只传入必要的输出。

适合场景：有明确流程的多步骤任务，比如“用户下单→验证库存→生成订单→发送通知”。每个步骤可以交给不同的 Agent，且步骤之间有严格的输入输出依赖。CrewAI 的“项目管理”风格非常适合这种场景。

Semantic Kernel：微软的“企业级”答案

Semantic Kernel（简称 SK）是微软推出的框架，定位是“将 AI 集成到企业应用中”。它的核心抽象是 Plugin 和 Planner。Plugin 类似于 LangChain 的 Tool，但更强调“类型安全”——每个 Plugin 的输入输出都有明确的 C# 或 Python 类型注解。

让我眼前一亮的设计：SK 的 Planner 不是靠 LLM 自己规划，而是通过一个“函数调用图”来静态分析。你定义好所有 Plugin 的签名，Planner 会在运行时根据用户输入，自动匹配最合适的 Plugin 调用链。这意味着 Agent 的执行路径是可预测的、可调试的，不会出现 LLM 随机选择工具的情况。

实际体验：我用 SK 写了一个“内部知识库问答”Agent。它有三个 Plugin：SearchKnowledgeBase（输入：query，输出：list of documents）、SummarizeDocument（输入：document，输出：summary）、TranslateToChinese（输入：text，输出：translated text）。Planner 自动识别出“用户问的是中文，但知识库是英文的”，于是生成了 SearchKnowledgeBase → SummarizeDocument → TranslateToChinese 的调用链。整个过程没有 LLM 参与规划，完全基于函数签名匹配，速度快且稳定。

但缺点也很明显：SK 的生态远不如 LangChain 丰富。你想集成 Slack、Discord、数据库？要么自己写 Plugin，要么等社区贡献。另外，SK 的 Planner 对复杂任务的支持有限——如果任务需要条件分支或循环，Planner 会直接报错，告诉你“无法生成计划”。我试过一个任务：“如果搜索结果少于 3 条，就扩大搜索范围再试一次”，Planner 直接拒绝执行，因为它不支持循环。

适合场景：企业级应用，尤其是对稳定性和可预测性要求高的场景。如果你团队有 .NET 背景，SK 的 C# SDK 体验极佳。但如果你需要灵活的任务分解和动态规划，SK 可能不是最佳选择。

我的选择建议（纯个人经验）

• 快速原型、验证想法：用 LangChain。但记得在第一天就加上 max_iterations 和输出格式校验，否则后面会哭。
• 多步骤、有明确流程的任务：用 CrewAI。它的 Task 依赖管理和输出校验能省掉你 80% 的调试时间。但注意控制 Agent 数量，别超过 4 个。
• 探索性、开放式任务：AutoGPT 可以试试，但别指望它一次就跑对。我通常用它来“头脑风暴”，生成一些初步思路，然后人工筛选。
• 企业级、需要稳定上线：Semantic Kernel。虽然生态小，但它的 Planner 机制让 Agent 行为可预测，这对生产环境至关重要。而且微软的更新频率很稳，不用担心框架突然不维护。

最后说一句：没有完美的框架，只有适合你场景的框架。我见过有人用 LangChain 写出了比 CrewAI 更稳定的多 Agent 系统，也见过有人用 Semantic Kernel 做原型做到崩溃。框架只是工具，真正决定 Agent 质量的，是你对 LLM 行为的理解和对边界条件的把控。别迷信框架，多写代码、多踩坑，比什么都强。