一、Dify的RAG架构：从"分块+向量"到多层语义检索
多模态嵌入层：感知通道的扩展
Summary Index：语义摘要层的引入
Excel内嵌图片：结构化文档的媒体感知
二、工作流引擎：GraphEngine落地与执行模型的根本改变
工作流执行模型：从线到图
异步执行模式：长任务轮询
执行引擎的性能优化
三、安全体系：开源平台的SSRF治理路线
四、difyctl CLI与平台工程化
五、架构层面的细微信号
Dify
Dify近三个月技术演进分析——从应用工具到AI基础设施
探索Dify如何通过RAG架构升级，从应用工具进化为AI基础设施，重新定义企业级知识管理。 核心内容： 1. 多模态嵌入层如何扩展感知通道，实现图文跨模态检索 2. Summary Index如何通过双层索引结构解决语义完整性问题 3. 对Excel等结构化文档的媒体感知支持如何满足企业级需求
Dify近三个月技术演进分析——从应用工具到AI基础设施
一、Dify的RAG架构：从"分块+向量"到多层语义检索Dify的RAG在三个月内完成了三层叠加。从架构层面看，每一次升级都不是简单的"加个功能"，而是在检索管道的特定环节插入了新的处理层。 传统RAG只处理文本，图片要么被丢弃，要么单独存成一个附件字段，检索时跟文本完全割裂。 Dify v1.11.0的改动是：在文档预处理阶段，用独立的图片提取器（支持Markdown内嵌图片、PDF扫描截图等格式）把图片分离出来，不走文本分块管道，而是直接走多模态embedding模型编码。文本块和图片向量分别入库，检索时做跨模态融合排序。 这里的工程细节值得注意：图片提取不是无差别的全量转码。Dify设置了单张≤2MB的阈值，超过的跳过——图片质量直接影响embedding效果，过大的图即便勉强塞进去也是噪声。同时在入库时保留了图片与原文片段的位置对应关系，不是简单把所有图片堆到一个池子里。这样在后续检索时，返回结果能精确定位到"哪张图对应哪个段落"。 从检索架构的角度看，这就是在向量库内部做了模态路由——文本走text-embedding通道，图片走multimodal-embedding通道，两条通道平行写入，检索时做加权融合。相比"把图片转成文字描述再检索"的方案，这种架构的好处是保留了视觉信息本身，不会因为"转述"丢失细节。 v1.12.0的Summary Index是三层架构中最有意思的改动。它解决的问题是：向量检索擅长词义匹配，但不擅长"理解文章在说什么"。 分块+向量的模式有一个根本性矛盾：块分大了，检索精度下降；块分小了，语义完整性丢失。长段落检索更是老大难——一段500字的文本，向量可能只有几KB的embedding，压缩比决定了语义信息的丢失程度。 Dify的解法是在向量索引之上再加一层摘要索引。对每个文档块，先生成AI摘要，摘要走独立的embedding。检索时先命中文摘向量（第一层粗筛），再命中原文向量（第二层精排），最后把摘要+原文全文喂给LLM。 从检索管线角度看，这就是从单层索引变成了两层索引结构。代价是写入时增加一次LLM调用（摘要生成），但召回质量的提升是可测量的。场景是概括性问答时，摘要层能快速定位相关段落，原文层保证答案的精确性。 v1.15.0的Excel内嵌图片提取，本质上是在多模态感知通道里增加了对结构化文档的支持。Excel不同于PDF/Markdown——它的数据结构是网格化的，图片可能嵌入在单元格内、也可能浮动在工作表上。Dify需要解析xlsx的底层XML结构才能正确提取这些内嵌媒体。 对于企业RAG来说这很关键。大量运营数据、报表、KPI看板都存在于Excel文件里，而Excel中的图表截图往往承载了最重要的决策信息。Dify填补了一个实际的空白。 多模态embedding层 + 摘要语义层 + 结构化文档解析层 — 三层叠加构成多层语义检索架构 从架构层面总结这条进化线：文本分块层 → 多模态embedding层 → 摘要语义层 → 结构化文档解析层。三个版本，每层解决一个不同的问题。不是简单的堆功能，是在检索管线里一层一层填实。
二、工作流引擎：GraphEngine落地与执行模型的根本改变HITL（Human-in-the-Loop）在v1.13.0上线，但我认为更值得关注的是背后GraphEngine的引入。 早期的Dify工作流本质上是一个DAG（有向无环图），执行引擎按拓扑序逐节点推进。这在"串行调用+简单并行"的场景下够用。但当HITL出现，执行模型需要处理"暂停→等待人工→恢复"这个状态转换时，简单的拓扑序遍历就不够了。 GraphEngine的核心改进在于：工作流的状态管理从"节点级"下沉到了"边级"。每一个连接（边）都可以携带状态信息（已执行/等待/跳过/失败）。HITL节点暂停时，上游边标记为completed，下游边标记为blocked，等待输入节点唤醒后才恢复。这个模型天然支持部分执行、条件分支、循环回退等复杂拓扑。 从v1.14.x的修复记录可以看到一些小线索——早期HITL resume后会丢失tracing，原因是session context的序列化/反序列化没处理好。这个话题绕不开一个技术点：工作流引擎怎么做中断恢复。Dify的做法是持久化trace ID + 完整的节点上下文快照，resume时从最近的checkpoint加载，而不是从头重跑。 v1.15.0的慢模型支持，本质上是在同步执行模型里插入了异步等待的语义。通义万相、Flux这类文生图/视频模型API的响应时间是秒级到分钟级，不可能让HTTP连接一直挂着等。 Dify的实现是：调用慢模型时，先异步发起请求，拿到task ID后立即返回，然后在后台轮询进度。工作流继续往下走——不是整个workflow卡住等图片生成完毕，而是"生成图片"和"后续步骤"并行执行。MaxWaitTime参数提供了超时兜底。 这在实际效果上意味着Dify的工作流引擎从"编排API调用链"升级到了"编排混合时延任务"。后者的编程模型要复杂得多——需要处理超时、重试、部分结果回收等状态。能做到这点的低代码工作流引擎并不多。 从线性的DAG执行到GraphEngine边级状态管理，再到异步慢模型轮询——工作流引擎执行模型的三次迭代 除了架构上的变化，v1.14.x开始的性能优化也是工程层面的兑现。核心改动是数据库写入操作从同步改为异步非阻塞。在复杂工作流中，数据库I/O经常是瓶颈——并行分支的日志写入会互相等待。异步写入让总执行时间从"各分支之和"逼近"最长分支执行时间"。
三、安全体系：开源平台的SSRF治理路线Dify这三个月的安全迭代有一个清晰的叙事脉络：被SSRF逼着完成了企业级加固。 SSRF（服务端请求伪造）在Dify语境下的攻击面很具体——API Tool允许用户配置自定义API端点，工作流节点可以发起HTTP请求，如果这些请求没有经过代理就直连内网，攻击者可以用Dify服务器做跳板扫描内网资源。 Dify的修复路线是按层推进的： 第一层：默认值消除。固定SECRET_KEY意味着攻击者可以伪造session token。去掉默认值，强制部署时生成唯一secret。 第二层：端点保护。内嵌的metrics端点、health检查端点以前不需要鉴权，变成internal+auth双约束。 第三层：租户隔离。工具凭证加scope约束——A租户的凭证不能被B租户的工作流使用。这在多租户SaaS场景下是基本要求，但对开源项目来说，做到这一步意味着至少在生产环境被验证过了。 第四层：SSRF代理加固。修复多个通过raw httpx.get()绕过SSRF_PROXY的漏洞。本质上是一致性校验问题——同一个请求路径，有的endpoint走代理，有的不走。修复方案是统一路由到中间层做请求转发。 SSRF占比约40%，凭证/租户隔离约25%，默认值/鉴权约20%，依赖CVE约15%——安全迭代按层推进 v1.15.0继续加了路径穿越修复。这条线可以预见还会持续——只要Dify支持用户自定义API调用，SSRF就是持续的战役。关键是不回避。
四、difyctl CLI与平台工程化v1.15.0的difyctl CLI值得单独讨论，但它不只是"多了一个命令行工具"。 CLI的引入意味着Dify的操作接口从单一的Web UI扩展到了API+CLI双通道。CLI天然适合：CI/CD集成、运维自动化、批量操作。从工程角度看，CLI的存在迫使后端API具有完备性和一致性——Web UI可以掩盖API设计的粗糙（自动补全、默认值、错误提示），但CLI暴露的是API的原始形态。 difyctl的实现搭载了checksum校验、跨平台支持（macOS/Linux/Windows）。这些细节说明它不是"顺手写的小工具"，而是作为正式产品组成部分开发的。 同版本的CoT推理流式面板在架构上也有意思。推理过程流式输出→实时WebSocket推送到前端展示→同时持久化到数据库→CLI也可以查询。这里做了数据流的复用——同一份推理链数据，同时消费于Web UI和CLI。 Phoenix自定义trace session ID则是可观测性的端到端打通。Dify作为编排平台，本身的trace和业务系统的trace往往是割裂的。自定义session ID让你可以把业务请求ID传入Dify的trace上下文，在Phoenix中实现跨系统的链路追踪。对于生产环境的根因定位，这是关键能力。 从CLI到CoT持久化到Phoenix集成，这三个变动指向的是同一个方向：Dify在从"开发者工具"转向"平台级基础设施"。平台和工具的区别是什么？工具解决单一问题，平台提供生态系统、运维能力和开放接口。 CLI + CoT推理流式 + Phoenix可观测性——从工具到平台的三个工程化方向
五、架构层面的细微信号除了上面几个大方向，还有一些技术细节值得关注： GraphEngine替换遗留引擎。不是简单升级，是底层重建。从遗留代码的修复模式（修一个bug、再修一个相关的bug）推断，旧的执行引擎在处理复杂拓扑时边界条件较多。 依赖安全升级保持月频节奏。Bleach、PyJWT、starlette三个CVE补丁分别对应XSS防护、JWT签名验证和ASGI框架安全。覆盖了Web安全的三个主要维度。对于一个快速迭代的开源项目，保持这个频率的依赖安全投入不容易。 代码现代化：Protocol/ABC → match-case。Python 3.10引入的match-case在Dify的代码库中开始替代旧式的类型分发模式。这不仅是代码风格问题——match-case在分支逻辑复杂的场景下比if/elif链更少出错，TypeChecker对match-case的覆盖也更完善。
这三个月的节奏说明一件事：Dify在快速加功能的同时，没有放下架构改造和安全加固。对一个靠社区驱动、每六周一个大版本的开源项目来说，能平衡好交付速度和工程质量，已经是很多人做不到的事。方向本身已经说明了问题。
一、Dify的RAG架构：从"分块+向量"到多层语义检索
二、工作流引擎：GraphEngine落地与执行模型的根本改变
三、安全体系：开源平台的SSRF治理路线
四、difyctl CLI与平台工程化
五、架构层面的细微信号
立即咨询 JOTO
JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。 联系 JOTO 获取 AI 落地咨询
想把这些做法用到你的业务里?
留下你的场景和痛点,我们帮你判断从哪一步开始。
联系我们