上周我在做一个内部知识库问答机器人，一开始图省事，直接把一整包文档丢给大模型，让它“阅读理解”。结果就是：回答经常跑偏，明明问的是《报销制度》里的差旅标准，它非要扯到加班餐补；而且每次提问都把所有上下文灌进去，那叫一个费钱。后来同事甩给我一个GitHub链接，说“你试试这个”。我点开一看，是 dify——一个靠工作流编排来构建智能体应用的开源平台，星标超过十五万。
为什么我会盯上它
我当时的场景很具体：公司有几十份制度文档，分散在飞书、网盘和本地Markdown里。我需要一个机器人，能回答“年假怎么休”“出差报销上限多少”这类问题。如果用传统RAG方案，我得自己写向量化、检索、重排、提示词拼接，再封装成API，运维一套数据库和索引服务。而dify把这一套都可视化地做成了“画流程图”，我只要把文档喂进去，拖几个节点，就能跑起来一个问答应用。
这正是我想要的：不重复造轮子，把精力花在业务逻辑上。
我是怎么用的
环境是Docker Compose，项目仓库里直接有编排文件。我照着官方文档，在服务器上执行了下面这条命令：
git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d起来之后，浏览器打开 http://localhost/install，设置管理员账号，就进了工作台。整个过程大概五分钟，没有任何魔法，就是常规的容器部署。
接下来我创建了一个“聊天助手”应用，模型选的是平台里配置好的DeepSeek——因为公司预算有限，国产模型便宜。知识库部分，我把几十个Markdown文件上传进去，dify自动做了分段和向量化，我还顺手把分段大小调成了400字符，重叠50字符，这样既不会把语义切碎，也不会让检索结果太冗余。
最关键的一步是编排工作流。dify默认的“聊天流”其实就是一个线性流程：用户输入 → 知识库检索 → 模型生成 → 输出。我想要的并不是“先检索再一股脑交给模型”，而是先判断问题类型，再决定走哪个知识库。
用户提问 → 问题分类（LLM节点）→ 按分类选择知识库 → 检索 → 拼接上下文 → 最终回答在dify里，我拖了四个节点：一个“开始”节点，两个“知识检索”节点（分别对应行政制度和财务制度），一个“LLM”节点用来写最终回答，还有一个“分支判断”节点。点击连接线，设置条件：如果分类结果是“财务”，就走财务知识库；否则走行政知识库。全程没有写一行代码，纯鼠标操作。
好用在哪？我列了三个点
1. 工作流可视化，比写代码调试快十倍
以前我用LangChain写类似的逻辑，光调试工具调用就花了一天。dify把每个节点抽象成可以拖拽的积木，每个节点都能单独测试。比如我可以先跑一下“问题分类”节点，输入“出差能坐高铁一等座吗”，看它返回的JSON是否包含“财务”这个标签。不合适就调整提示词，再跑一次。这种即时反馈的调试体验，是我最喜欢的地方。
2. 内置RAG管道，检索效果开箱即用
dify的知识库支持多种分段策略，还内置了向量检索、全文检索和混合检索。我对比过自己用FAISS搭的方案，dify的召回质量略好，尤其是长文档的标题和关键句提取，能减少很多无关片段。最贴心的是，它会显示每个检索结果的得分，我可以直接看到“这段文档匹配度0.87，为什么匹配？”从而反推文档里的术语和问法不匹配的问题。
3. 发布即API，省掉后端管道
编排完成后，dify直接生成了REST API和WebApp演示页面。我把API密钥给前端同事，后端对接就结束了。它还支持嵌入到网页里的iframe，我甚至为内部演示做了一个简单的聊天窗口，发给老板看效果，前后不到一小时。
【我遇到的坑】
当然，如果全是优点，我也不会写这篇文章了。下面这些坑，都是流汗换来的。
坑一：知识库分段太粗，导致回答张冠李戴。 我第一次上传文档，用了默认的500字符分段。结果有一份文档里，前半段写“行政部负责办公用品采购”，后半段写“财务部负责报销审批”，中间隔得很近。用户问“申请办公用品找谁”，检索系统把两段都召回，大模型就混在一起回答“找财务部”。后来我把分段大小调小到300，重叠区间加大到80，这种问题才基本消失。
坑二：工作流里的变量冲突，调试了半天才发现。 我在“知识检索”节点后面接了一个“LLM”节点，想在提示词里引用检索结果的变量名。但dify里的变量引用格式是 {{#nodeID#}}，而不是我习惯的 $context。一开始没注意，直接写成了 {{knowledge}}，结果输出的回答全是乱的。后来点开节点详情，看到右侧“可用的变量”列表，才搞清楚引用方式。
坑三：模型幻觉问题，比想象中严重。 即便加了RAG，当用户问的问题碰巧不在知识库里时，模型还是会一本正经地编造答案。比如问“公司有没有宠物假”，知识库根本没有相关文档，但模型回答“有，每年三天”。我后来在提示词里强制加了“如果知识库中没有相关信息，请直接回答不清楚”，并开启了dify的“引用归属”功能，让回答附带文档来源，才勉强遏制住。
坑四：并发性能，别裸奔上生产。 我本地测试时一切流畅，但部署到公网后，十几个同事同时用，Docker容器CPU直接飙到100%。后来看了日志发现是向量检索没有走索引，每次都是全量扫描。dify官方建议生产环境至少用单独部署的Weaviate或Qdrant，而不是内嵌的默认存储。我后来给服务器加了内存，才好转。
和竞品比，它赢在哪，输在哪？
我顺手也试过另一个类似的开源平台 FastGPT，以及自己用 LangChain + Chroma 搭的简易RAG。对比下来，dify的优势非常明显：
- 上手成本最低。FastGPT需要自己配置数据库和模型供应商，LangChain更是要从零写代码。
- 工作流能力最强。dify支持条件分支、循环、工具调用、HTTP请求等复杂节点，FastGraph那边的可视化还停留在简单问答阶段。
- 生态完善。插件市场、模型接入、监控日志、API管理，基本都齐了。
但缺点也真实存在：dify的重逻辑场景反而繁琐。如果我只是想快速搭一个简单的FAQ机器人，dify的工作流配置反而比直接用LangChain的RetrievalQA更绕。前期要学习它的节点概念，中期要调小参，后期还要维护它自己的数据库结构。而LangChain虽然代码多，但灵活度极高，什么逻辑都能写。另一个问题是，dify的版本更新很快，社区版和专业版功能差异也越来越大，一些好的插件只支持云版。
什么场景适合用dify？
我总结得非常直白：
- 适合：中小团队做内部知识库、客服机器人、文档问答、自动化报告生成；非深度学习背景的全栈工程师想快速交付一个AI应用；产品经理做原型验证。
- 不适合：超大规模高并发场景（你要自己搞定数据库和K8s）；自定义程度极高的对话逻辑（比如多轮状态机、复杂多Agent协作）；纯学术研究（它太封装了，不利于理解底层原理）。
我用dify做了个demo之后，最大的感受是：AI应用开发的瓶颈，已经从“会不会调模型”变成了“能不能把复杂业务逻辑捋清楚”。dify把模型调用的部分标准化了，但流程设计、知识库质量、提示词工程，这些依然得靠自己。
最后的结论
如果你跟我一样，手头有一个具体业务问题，想用大模型解决，但不想上来就啃一堆AI框架的文档，那我强烈建议你花一个晚上试试dify。它能不能变成生产级方案另说，但至少它能让你在半小时内看到一条完整的AI应用流水线是什么样子，远比读十篇《我的大模型实践》有用。
我自己的下一步计划，是把dify接入到公司企业微信机器人里，让员工直接在聊天窗口里问行政问题。前端的权限校验和审计日志我都想好了，dify的API足够干净，对接不会太难。等跑一段时间，我再来写一篇“生产环境踩坑续集”。
话不多说，今晚就拉代码跑起来吧。