作者：技术老金

在启动一个全新的AI Agent项目时，技术选型的第一个岔路口，往往就是：我们应该选择一个像CrewAI这样“大而全”的集成框架，还是应该从底层构建自己的核心逻辑？

这是一个没有标准答案，但却生死攸关的决策。

在我们的内部项目vkflow-agent中，我们最初选择了前者，但在经历了一场惨烈的“依赖地狱”和架构冲突后，我们最终毅然决然地选择了后者。我们放弃了CrewAI。

这篇文章，不是一篇对CrewAI的“批判檄文”。恰恰相反，CrewAI是一个极其优秀的、现象级的应用框架。我们的放弃，只是一个特定团队，在特定目标下，做出的一个具体的、痛苦的、但我们认为是正确的架构决策。

我将完整地复盘这个决策过程，并为你提供一套我们总结出的、可复用的“AI框架选型决策清单”。

---

背景：我们的核心目标与最初的技术设想

首先，必须明确我们的核心目标：构建一个通用的、可灵活切换不同LLM、可自由扩展工具集的Agent框架。

关键词是“通用”和“灵活”。

基于这个目标，我们最初对CrewAI的设想是：将它作为我们框架的“任务编排层”。我们期望它能像一个“库”一样，被我们“调用”，来组织和调度我们自己开发的、遵循我们自己接口规范的Agent和Tool。

这个设想，听起来非常美好。但现实，给了我们沉重一击。

冲突的爆发：当“依赖”成为一种“绑架”

当我们尝试将crewai集成到我们自己的Poetry环境时，冲突爆发了。

Poetry的依赖解析器，用一长串无法解决的错误告诉我们：CrewAI为了实现它那“大而全”的功能，对它下游的所有子依赖（如embedchain, langchain-openai等），都做出了极其严格、甚至“霸道”的版本锁定。

它不仅要决定我们用什么，还要决定我们“必须用哪个版本”。

这与我们的核心目标，产生了三个不可调和的根本性矛盾：

1. LLM选型的自由： 我们希望自由地切换最新版本的langchain-openai和langchain-ollama，但CrewAI的依赖树，将我们锁定在了它所要求的、可能并非最新的版本上。
2. 工具集的扩展： 我们希望构建我们自己的BaseTool体系，但CrewAI有它自己的一套工具集成方式，我们的适配过程，充满了不确定性和“黑盒调试”的痛苦。
3. 项目的稳定性： CrewAI庞大而复杂的依赖关系，像一个“不定时炸弹”。今天我们可能侥幸解决了冲突，但明天，任何一个子依赖的更新，都可能让我们的整个项目，再次陷入崩溃。

我们意识到，CrewAI不是一个可以被我们轻易“调用”的“库”，它是一个试图定义我们整个项目技术栈的“框架”。

艰难的决策：“回归内核”

此时，我们面临一个灵魂拷问：

我们是要为了使用CrewAI的“多智能体编排”这一个功能，而放弃我们整个项目在技术选型、稳定性、和长期演进上的“主动权”吗？

作为项目的架构师，我的答案是：绝不。

一个健康的、有生命力的项目，其技术栈的控制权，必须掌握在自己手中。

因此，我们做出了决定：彻底放弃CrewAI，回归我们自己的、那个最简单的、只包含几个核心抽象和官方LLM库的内核。

我们放弃了“开箱即用”的便利，但换来了更宝贵的**“架构上的自由”**。

---

复盘：一套可复用的“AI框架选型决策清单”

这次失败的经历，最终凝结成了一套我们内部现在严格遵守的决策清单。在未来，当我们要引入任何一个核心的第三方AI组件时，我们都会用它来逐一审视：

1. 角色定位 (Role Assessment)

• [ ] 它是一个“库”（Library），还是一个“框架”（Framework）？前者是工具，后者是世界。我们必须想清楚，我们是要找一个“帮手”，还是要搬进一个“新家”。

2. 依赖透明性 (Dependency Transparency)

• [ ] 它的核心依赖有哪些？依赖关系是“重”还是“轻”？
• [ ] 它对下游依赖的版本要求，是“宽松”的，还是“严格”的？是否会与我们现有的核心技术栈（如LLM客户端版本）产生冲突？

3. 架构一致性 (Architectural Alignment)

• [ ] 它的核心设计哲学，与我们项目的长期架构目标，是否一致？
• [ ] 它是否足够“开放”？是否提供了清晰、稳定、官方支持的扩展方式（如自定义组件、插件机制）？

4. 掌控力评估 (Control & Forkability)

• [ ] 它的核心逻辑，对我们来说是“白盒”还是“黑盒”？我们是否能理解它的基本运行原理？
• [ ] 在最坏的情况下，当遇到一个框架本身无法解决的Bug时，我们是否有能力Fork其源码，进行我们自己的修复和维护？

只有当一个AI框架，能在这份清单上，得到一个足够肯定的答案时，我们才会谨慎地，将它引入我们的核心系统。

结语

我们放弃了CrewAI，但这并不影响我们对它的尊敬。它依然是快速构建特定AI应用的最佳选择之一。

我们的决策，只是一个特定团队，在“构建通用框架”这个特定目标下，做出的一个必然选择。我们选择了更艰难，但我们认为更正确的道路：将核心的、定义系统骨架的逻辑，牢牢掌握在自己手中。

希望我们的这次深度复盘，能为同样站在技术选型岔路口的你，提供一点有价值的参考。

更多阅读：
和AI结对编程第一天，我踩了3个大坑，差点项目失败！复盘4条生存法则