最近花了不少时间翻 Dify 的 GitHub、官方博客和路线图，越看越觉得这个项目的方向比表面看起来要野心大得多。
今天不聊某个版本更新，而是拉远视角，聊聊 Dify 到底在往哪走，以及它对做 Agent 框架的人意味着什么。
先看清楚：Dify 的四个阶段
回头看 Dify 从 2023 年到现在的发展，路线其实非常清晰：
注意最后这个箭头——从"Agent 平台"到"Agent 操作系统"，这不是我瞎猜的，是 Dify 一系列动作指向的方向。
2026 年已经落地的关键拼图
在聊"下一步"之前，得先把 2026 年已经做掉的事情过一遍，因为每一步都在为后面的大棋铺路。
1. Trigger（v1.10.0）：工作流不再被动等待
2025 年底发布的 Trigger 功能，让 Workflow 可以定时执行、响应外部事件（GitHub push、Gmail 收件等）自动触发。
这意味着工作流从"等人点按钮"变成了"自己跑起来"。
2. 多模态知识库（v1.11.0）：图文统一检索
知识库不再只能处理文本了——截图、图表、嵌入图片的 Markdown，都能进入统一语义空间做检索。检索准确率提升了 35% 以上。
3. Summary Index（v1.12.0）：AI 摘要增强检索
给每个文档块生成 AI 摘要，检索时不再只靠原始 embedding，而是利用语义更丰富的摘要来匹配查询。
4. difyctl CLI（v1.15.0）：从浏览器走向终端
官方 CLI 工具，让你在终端、CI/CD 流水线里直接跑 Dify 应用和工作流。
这个信号很明确：Dify 不想只活在你的浏览器标签页里，它要成为你基础设施的一部分。
5. New Agent（v1.16.0 - v1.17.0）：Agent 成为一等公民
这是 2026 年最重要的一步。Agent 不再只是工作流里的一个节点，而是拥有独立身份、配置和生命周期的资源：
-
Build Mode：通过对话构建 Agent -
Skills：可复用、可版本化的能力包 -
E2B 云沙箱：隔离执行环境 -
Home Snapshots：可复现的运行时状态 -
声明式输出：结构化结果传给下游
下一步：Dify 正在铺垫的 6 个方向
好了，铺垫够了。基于 GitHub 上的 Issue 讨论、官方博客、社区提案和行业标准走向，我判断 Dify 接下来会在以下方向发力：
方向一：Multi-Agent 协作
这是最大的一个。
Dify 目前已经有"邀请 Agent 进入 Workflow"的能力，但这只是单 Agent 在工作流里执行任务。下一步是 Agent 之间的发现、通信和协作。
信号很明确：
-
A2A（Agent-to-Agent）协议已经进入 1.0 稳定版，加入了 Linux Foundation 的 Agentic AI Foundation -
Dify 的 GitHub Issues 里出现了"Agent discovery"和"Agent communication"的功能讨论 -
官方博客明确提到"connecting Dify with more agent stacks"
我的判断：Dify 会原生支持 A2A 协议，让 Dify 上的 Agent 能发现并调用外部 Agent，也能被外部 Agent 发现和调用。这会把 Dify 从一个"内部 Agent 平台"变成一个"Agent 网络节点"。
方向二：Skills 生态市场化
Skills 是 2026 年引入的核心抽象——把业务方法论封装成可复用、可版本化的能力包。
现在 Skills 已经可以在工作区级别被多个 Agent 共享。下一步是什么？
Marketplace。
Dify 已经有了插件市场（928 个插件）、创作者中心和模板市场。Skills 上市场的逻辑非常自然——不只是卖工具，而是卖"工作方法"。
想象一下：一个资深采购员把"三家比价"的判断逻辑封装成 Skill，发布到 Marketplace，其他团队的 Agent 直接调用。这比卖一个 API 接口有价值得多。
方向三：RAG 链路持续优化
GitHub 社区最近有一个提案（#43664），指出多知识库检索时的加权评分和引用组装存在不必要的性能开销。用 Grafana Tempo 追踪发现，某个评分分支的后处理从 170ms 可以优化到 2.91ms。
这说明 RAG 的性能优化还在持续进行。结合 Summary Index 和多模态知识库，Dify 的 RAG 链路会越来越成熟。
我关注的点：Agentic RAG——让 Agent 在检索过程中自主判断是否需要补充查询、切换数据源、评估证据质量。Dify 官方博客已经有专门文章介绍这个概念，说明这个方向已经在推进。
方向四：企业级治理深化
Dify 的融资（3000 万美元 Pre-A 轮）明确说了——钱会投在企业采用上。
已经在做的：
-
SAML 2.0 / OIDC SSO -
多工作区管控 -
凭证隔离 -
审计日志 -
白标 UI
下一步会做什么：
-
更细粒度的 Agent 权限管控（谁能调用哪个 Agent、哪些 Skill） -
Agent 行为的合规审计（不只是日志，而是可追溯的决策链） -
跨工作区的 Agent 共享和治理
Asqav 的加入很有意思——它让 Dify 上每个 Agent 动作都生成可验证、防篡改的凭证。这不是普通的审计功能，这是给 Agent 行为做"公证"。
方向五：Trigger 和事件驱动自动化
Trigger 已经上线了，但还比较基础。从社区讨论来看，下一步会包括：
-
更复杂的事件源（不只是 GitHub/Gmail，还有自定义 Webhook 和内部服务） -
更灵活的调度策略（不只是定时，还有条件触发、级联触发） -
时区问题的修复（当前存在本地时间显示但 UTC 执行的 Bug）
我的判断：Trigger 会让 Dify 从"按需调用的工具"变成"7×24 运行的基础设施"。结合 Agent 的自主决策能力，这意味着很多业务流程可以实现真正的"设好就跑"。
方向六：开发者体验的持续升级
difyctl 只是开始。从 GitHub Issues 来看，社区在推动：
-
更好的 DSL/低代码支持 -
本地开发调试工具套件 -
性能分析和优化建议 -
Datadog 等可观测性平台的集成
Dify 正在从"给业务人员用的可视化工具"同时向"给开发者用的工程化平台"演进。这两条线不矛盾，但需要同时做好。
一句话总结 Dify 的演进逻辑
拆开来看：
-
Prompt 工具（2023）：帮你写 Prompt -
工作流平台（2024）：帮你编排流程 -
Agent 平台（2025-2026 上半年）：帮你构建和运行 Agent -
Agent 操作系统（2026 下半年 - ？）：帮你管理多个 Agent 的发现、协作、治理和生命周期
如果这个判断成立，Dify 最终想做的不是一个更好的"AI 应用开发平台"，而是 AI 时代的操作系统——Agent 是进程，Workflow 是调度器，Skills 是库函数，Marketplace 是应用商店，Trigger 是中断机制。
对做 Agent 框架的人意味着什么
看完 Dify 的路线图，我觉得有三个值得借鉴的思路：
1. Agent 和 Workflow 的分工必须清晰
Dify 用了一整篇文章来回答"Agent 这么强了，Workflow 还有意义吗"。答案是：Agent 决定怎么做，Workflow 决定什么时候做。
这个分工不是技术细节，是架构哲学。做 Agent 框架如果不处理好这个问题，迟早会撞墙。
2. Skills 是比 Tool 更重要的抽象
Tool 是能力，Skill 是方法论。一个 Tool 只能调用 API，一个 Skill 封装了"怎么用这个 API 做好这件事"。
如果你的 Agent 框架只有 Tool 没有 Skill，那每个 Agent 都得从头学怎么干活。有了 Skill，经验可以复用。
3. A2A 协议不是可选项，是必选项
A2A 已经进入 1.0，被 Linux Foundation 接管，150+ 生产组织在使用。Dify 大概率会接入。
如果你的 Agent 框架不支持 A2A（或类似的跨 Agent 通信标准），未来在互操作性上会吃亏。MCP 解决了 Agent-to-Tool 的问题，A2A 解决的是 Agent-to-Agent 的问题。两个协议，一个垂直一个水平，缺一不可。
写在最后
Dify 从一个开源的 LLM 应用构建器起步，花了三年时间走到了 Agent 操作系统的门口。15.8 万 GitHub Star、3000 万美元融资、928 个插件——这些数字说明市场认可了它的方向。
但真正让我觉得有意思的，不是这些数字，而是它背后的演进逻辑：
不是做一个更聪明的 Agent，而是做一个让 Agent 真正跑起来的系统。
Agent 的智力来自模型，但 Agent 的可靠性来自系统。调度、权限、审计、复用、协作、生命周期管理——这些"无聊"的工程问题，才是 Agent 从 Demo 走向生产的关键。
Dify 正在解决这些无聊但关键的问题。这比发布一个更酷的功能值得关注。
Dify社区群：嗨聊吧
欢迎扫码加入嗨聊吧！
