2024-11-21-crewai & Dify试用
为了实现一个智能客服系统，对crewai和Dify进行了试用。
背景
业务背景：实现一个私有化部署、有私域知识、多模态支持、多渠道接入的智能客服系统。这里以Crew AI和Dify作为两大类开源可商用的技术路线代表进行比较。
Crew AI是标准的、支持多智能体协同的工具。类似的还有微软的autogen、Open AI的swarm、LangChain的LangGraph等。以crewai作为代表，是因为它更成熟、功能更全面、案例更多。
Dify更多的是一个LLMOps框架、大模型应用开发平台。类似的开源框架有fastgpt，商业产品有字节的coze。
简述
本文输出的结论仅为初学者未调优、本地体验所得，存在主观看法，未必正确，仅供参考。
Dify/fastgpt已有的功能更适合实现一个智能客服，可以快速地实现一个MVP版本（尽管交付给用户的界面是重写。Dify自带的界面用来做设计态或者内部运维界面也是实用的），而需要改进的点也可以较方便地替换成自己的组件和实现。在易用性、响应速度、稳定性等方面相比Crew AI也更有优势。Crew AI能快速跑起来示例，但响应时间相对更慢，而且多轮重复运行后出现了预计外的错误（提示词指定了使用中文回答，前几轮循环正常，后面就变成英文答案和LLM异常了。27b的GEMMA和72b的QWEN都会出现，GPU是足够的）。
LLMOps类的框架，在ops这块确实更易用更全面。这里的ops含义从DevOps中的运维扩展到运营，体现在可视化的调试、监控、日志、发布、token计费等方面，更容易对整个项目方案有更多的信息收集和掌控。反过来crewai的调试、监测等是需要通过命令行和编程去实现，更灵活，但那是在一定时间和工作量之后。
PS：在体验Crew AI过程中查阅官方和网络上的示例，几乎都不是智能客服这种（尤其是电话客服）实时性、互动性要求高的应用，更多是订票、写博文、预定会议等。这个也是更快转向Dify的一个原因，Dify有聊天助手的应用类型，而且有多个客服相关的应用模版。
agent支持度
agent的定义和分类很多，这里使用相对最普遍的定义：agent=llm+memory+tool+plan。
Crew AI对这些概念不仅是支持的，而且有对应的逻辑实体和api来对应，整个agent的实现风格就是指定LLM，配置memory选项，指定agent使用的工具集，声明agent扮演什么角色完成哪些任务，声明整个crew团体的组织结构和代理委派的模式。而这些声明式的代码编写完成，应用代码就几乎完成了。
在memory这块不仅支持短期记忆和长期记忆，还支持实体内存，可以捕获运行期遇到的实体概念，从而促进更深入的理解和关系映射。
Crew AI建立在Langchain 之上，可以访问他们的所有工具,同时自身也提供了一套工具集。用户还可以定义和集成针对其特定需求量身定制的工具。
多智能体协同：Crew AI 支持灵活的任务管理、自主的代理间委派。
而Dify这边，尽管有单独的agent的应用类型，agent可指定知识库和工具，但多个智能体之间的协同机制是没有的需要自行实现。如果是创建工作流类型的应用，可以 引入多个处理LLM/知识检索/工具节点进行协作，而非多agent的协作。此外，Dify只有聊天记录的内置记忆和编排变量的机制。至于工具内置、扩展和生态方面，Dify也有相关的能力。工具并不是最核心的差异。
LLM接入
区别不大，主流LLM服务和本地LLM都能支持。如果某些本地LLM部署框架不支持，也可以通过one api这种，代理本地LLM模型服务伪装成openai接口即可。而openai接口各框架都支持，甚至是默认选项。
RAG支持度
Crew AI并没有强调RAG，只是提供了一系列的RAG Tool。而这些单独的rag并不能在实践中独立、容易完成私域知识检索的能力。而Dify有单独的知识库管理，有单独的知识检索类型的节点，支持配置嵌入模型和多种检索模式等，能够快速而完整地将私域知识纳管和用于应用中。而Crew AI需要达到该目标，按官方的倾向应该是集成LangIndex使用。
本地开发学习曲线
本地安装部署这块都比较顺利和简单，运行简单的示例都不难，相对而言，Crew AI会差一点，因为命令行示例并没有第一次成功（python代码首次是成功的），更何况Dify是提供了精美页面和示例应用模板的。
接下来是希望找到更合适我们的示例模版，跑起来，然后再修改，而非从头开始。在这 点上，Dify提供了国内外大量的应用模板，而且如前文所述有复数客服相关模板。而且基于模板创建应用后，是可以快速跑起来的，包括每一步的输入输出和性能，不用专门学习都能在界面上找到。小的修改也是可以基于页面的工作流、代码节点、http调用节点和丰富的工具市场来完成。这种小步快跑、即时反馈的风格，更适合初学者。而Crew AI的代码灵活度更高，全代码受控，更适合熟练者有代码控制和完成业务应用。在Dify能支持的灵活度范围内，基于界面、工作流和丰富模板的方式更易上手和更易验证业务目标。
开放与集成
对于Crew AI，整个应用代码都是自己写的，开放与集成自然是可以任意和完全控制的，但同样需要自行实现的成本。所以本节主要描述Dify在这块的表现。
开放api。Dify搭建出的应用是非常容易发布成直接可用的站点，或者嵌入到自己的业务系统，也提供了http api和sdk来再开发。PS：提供的http的对话接口是支持流式和中断的。
代码执行。工作流节点类型中有代码执行节点。支持python和nodejs代码。
用户输入/人机交互。在Dify中使用用户输入或者反求用户补充信息，基于对话和变量都是容易配置的。
内置的语音输入和语音播报，同样是可以换成自有实现版本。Dify和fastgpt这种平台更多是胶水和脚手架，本身并没有包括和限定哪种模型。哪怕官方没有说明支持本地的哪种模型，也可以通过代理成官方支持模型的api来实现接入和替换。
性能
在8卡4090的服务器上通过docker部署Dify和Ollama，通过Ollama部署qwen2.5:72b和gemma2:27b和mxbai-embed-large，8卡显存占用13G左右。
应用使用的LLM是qwen72b时，LLM开始出字在3-4s，生成token在60token/s左右。 同样的应用，LLM换成gemma27b时，LLM开始出字在1s，生成token在300token/s左右。两者都回答质量差不多，更多取决于知识检索的准确率，但gemma生成的回答更简略些。
多模态支持
Dify默认支持语音输入和语音播报。
在对话过程中支持用户上传文件，配备文档提取器将文档解析为文本供 LLM 理解。
对于音频文件，可以使用 gpt-4o-audio-preview 等支持多模态输入的模型直接处理音频，无需额外的提取器。
对于视频和其他文件类型，暂无对应的提取器，需要应用开发者接入外部工具进行处理。
持续改进
首先两者都有单步重放、单步调试的能力，来确认新配置/新模型/新数据的改进效果。而Dify的持续改进优势更多在数据上，在知识库的管理上，可以人工标注、召回测试等。而Crew AI的持续改进优势更多在agent能力上，提供了基于命令行和编程方式的训练agent的机制。
其他
基于agent去实现客服理论上是适合的，但受限于LLM和agent目前的能力，在落地时还是有不少问题的，不仅只是rag准确度的问题。可以参考知乎上的这篇回答。