观点
万字演讲：Dify 插件如何助力 AI Agent 应用开发？
大家好，我是 Allen，来自 Dify 的技术文档工程师，主要负责 Dify 整体帮助文档和企业版整体文档建设，为各位开发者提供知识服务。
很荣幸今天有机会站在讲台上来和大家分享 Dify 的一些技术实践案例。我呢其实算是业务人员，也是许多新功能的第一体验用户，会更加关注于某项新功能能够给我们的用户带来何种价值，以及用户体验。因此我今天的分享将主要集中于实际的应用，希望我这个视角能够给大家带来不一样的收获。
我本次演讲的题目是 Dify 插件生态实践：Agent 应用开发的新范式，将分为五个部分。
第一部分先是给还不知道 Dify 的朋友简单介绍一下，接下来是我们对于不断变化的 Agent 开发做了哪些自适应改造，以及如果说开发者想要搭建功能更加复杂的 Agent 应用，Dify 能够给开发者提供什么价值。
同时我也会和大家分享我们的一些用户案例，如何使用 Dify 插件来搭建出具备自动能力的类 Agent 应用案例，以及应用开发完之后最重要的，如何完成投产和上市，最后是一些总结和思考。
好那我们开始今天的分享。
感谢各位支持，Dify 在过去的两年已在 GitHub 上斩获 10W 颗 star，也是在最近跻身全球开源项目排名前五十。也在此感谢各位曾经为 Dify 项目点过星星的用户。
很显然，Dify 之所以能取得今天的成绩，离不开 AI 趋势和大家的支持。
可以说，你只需要有创意有想法，在数分钟内你就可以在 Dify 上创建一个应用。并且还可以随时添加第三方服务来扩展这个应用的功能，打造更好的用户体验。
所以我们其实也很乐观的看到，使用 Dify 的用户，甚至说是深度使用 Dify 的用户，许多人并不是严格意义上的开发者。他们更多的是像我一样的业务人员，比如说财务岗、运营岗，市场销售这些岗位。
在 Dify 诞生以前，一个业务人员在收集到了用户的需求之后，他能做的事情估计就是层层上报，反馈给产品经理，再由开发人员来实现这个功能。
而有了 Dify 之后，对于一些简单的问题，他可能只需要简单的动一动手，把逻辑想清楚了就可以把一个能够解决用户基础问题的应用给做出来。 Dify 自己又是支持 API 的，开发搞定安全和并发之后，说不定只需要写一个按钮就可以上线了。
**业务人员，不应该在这场 AI 技术变革中“失语”。**我们相信，凭借他们的深刻市场洞察和感知能力，再加上由 AI 带来的技术平权，只要跨越了技术这道看起来高深的鸿沟，其实是可以创造出许多意想不到，但却十分有用的 AI Agent 应用。我们都说艺术来源于生活，我在这里也想说，好用的 Agent 应用更是来自对于日常痛点场景的洞察。
而 Dify 要做的事情，就是不断的降低这里面的技术门槛。
其实自从今年以来，大家也许都有同样的体会，那就是大模型自身变得越来越聪明了，并且市面上不断地出现新的协议，来帮助大模型这个智慧大脑来使用工具。
你看年初 DeepSeek 横空出世，ChatGPT 又顺势推出了 DeepResearch，没过多久 Manus 也来了。，再过一个月 MCP 又忽然变得很火，谷歌又推出了 A2A。连去年很火的 RAG 呀都显得没那么火了。
这就是一个百家争鸣的时代，一会一个热点，应接不暇。要知道，也就只是两年前，你只要学会使用怎么调 GPT 的 API，简单套个壳，你就可以把自身包装为一个 AI 产品，开始对外讲故事。
而现在已经不是通过套一个 LLM API 就可以宣传自己是 AI 产品的这个时代了。相反，你需要做很多传统软件工程上需要做的事情。
比如说我们都很期待的 Agent 应用，本质上其实就是给大模型不断地添加多模态支持的能力，它要会联网搜索，会看图，甚至还希望它会说话。以及要使用 OCR 提取各种文档、图标内的信息。同时还需要解决 RAG 知识库准确度的问题。
开发者所做的这一切努力其实都是为了让应用往真正的 AI Agent 方向靠，谁不希望有一个全能的 AI 助理呢？对着手机说一声，它可以自动帮我订机票，帮我指定行程，叫个车，直接告诉我车在什么时候在什么地方出现。哪怕代替我操作浏览器，搞定日常办公软件的使用，都是很理想。
而要想实现这些美好的愿景，我们需要在现有的大模型能力上不断加东西。在AI 技术不断进化的今天。每一次革新都在重塑开发方式。
对开发者来说，技术变了、场景变了，唯独时间和资源始终紧张。使用插件这套体系，开发者可以把 AI 应用的开发过程，变得像乐高拼积木一样简单。
下面来看几个实际的例子，以及它能够解决的问题。这些例子都是通过插件来实现的，后面我会为大家介绍 Dify 插件的实现原理，同时讲解如何开发一个 Dify 插件，以及最后如何通过各个服务搭建出更加自动的 AI Agent 应用。
第一个例子还得是最近被 Manus 带火的浏览器使用（browser-use）用例，智能浏览器助手。
这个例子最早是由我们的日本用户贡献出来的。它的作用就是帮助你定位网页上的关键信息。比如说，我想要知道一个网站的联系表单需要填写什么内容，那么这个工作流会帮你找到该网站内的联系表单。而且会提取该联系表单所在的页面URL和联系项目，并全部带回来。 信息带回来之后，你也可以让 AI 进行处理，你都可以自定义后续的流程。如果说同时能够运行一千次，一万次，然后对提取完的数据分门别类，这里面的价值就起来了。
目前这个插件已经公开可用了，你在 Dify 的插件市场里搜索 Browser 就可以找到。
第二个例子是使用 Dify 复刻 Deep research 。可以说，你只要知道最新技术的主流程图，使用 Dify 里的节点，就可以获得所见即所得的 LLM 应用开发体验。
第三个例子是在 Dify 内使用 SSH 插件，输入指令，比如说在某个服务器里部署一个网页。那么这个插件就可以帮助我们自动登录服务器，然后部署网页。我将在后面用这个插件作为示例，为大家详细说明 Dify 插件是如何开发的。
第四个例子就更简单一些，直接在 Dify 里生成视频。顺带一提这个插件就是我本人做的，主要用到的技术其实问就是把 API 转为 Plugin。
我们所做的这一套全新的插件系统，其实也承载了我们对于下一代 AI 应用开发的设想。我们希望 Dify 不仅仅只是 LLM 应用的开发底层基建，更是要成为各位开发者调用 AI 能力的首选操作系统。
而这个思路，其实很早就有了。其实我们在很早的时候就认识到，想要让你的 AI 应用不仅仅只是一个简单的 Chatbot，聊天机器人的话，那一定是要对接好各种外部服务的。因此也预留了工具调用的入口。但是随着项目演进，这套非常基础的、大量依赖 API 通讯的工具产品设计体系，其实已经不适合现在日新月异的 AI Agent 发展节奏了。
所以我们也复盘总结了过去的工具体系设计，把问题总结归纳，大概总结出了以下问题：
在这个插件中，比较好的处理方式是直接请求 Dify 内的应用，让它来理网络请求，从而实现自动 Bot 的功能。插件里的应该具备的功能也就呼之欲出了：反向调用
为全球的开发者提供全面、功能强大的 AI 应用扩展能力。让 AI Agent 的开发之旅变得更加简单。你的 AI 应用能够更好地”看”、“听”、“说”、“画”、“计算”、“推理”，执行真实世界的操作。
可以说，只要工具足够多，那么通过不同工具的组合，你的 AI 应用也会变得越来越强大。我也看到许多云厂商现在都支持了实时和 AI 进行视频沟通、语音克隆、还有各式各样的基础能力，那么其实都可以变为一个插件。开发者通过这个流程，能够为自己的 AI 应用扩充无限的能力。这里面的想象空间十分巨大。
在新的插件生态设计下，第三方服务都会成为独立的插件包，可以独立安装、卸载和运行，大大增强你们的使用灵活性。开发的插件不单单可以用于解决本身的问题，更有可能在整个生态里发挥作用。只要满足 Dify 这套新标准，开发新范式，任何插件都有可能上线我们的官方插件市场，有机会被全球的开源社区所看到。这也是 Dify 开源的其中一个价值。
插件生态发布之后，大家可以看到我们现在的插件市场上已经出现了 120 多个好用的服务，开发者可以像在逛 App Store 一样，自由地“下载”所需插件。加强自己的 AI 应用能力。
插件能够提供的能力远不止是简单的 API 封装这么简单。把整套结构解耦出来之后，对于业内新出现的协议，比如说 MCP，谷歌的 A2A，都可以很方便的进行兼容和集成。我在这里可以预告一下，Dify 的 MCP 功能即将推出，你可以将 MCP 接入到 Dify 里的工具内，同时也可以把在 Dify 内已搭建好的 AI 应用发布为 MCP 服务器。
受 Manus AI 启发的两个关键想法包括：
服务器交互： 将 Manus 的“计算机使用”功能转化为服务器管理。
代理驱动的任务规划： 利用 AI Agent 有效地管理和执行任务。
我们现在来仔细拆解下 SSH 插件。这个插件直接可用让 LLM 访问服务器，并且执行操作。怎么做到的呢？
很简单，人类程序员登录服务器需要做什么操作，那么这个插件也需要具备对应的操作动作。比如说登录远程主机、还要找到对应端口、输入密码、然后执行命令等等这些操作。只要把这些操作配置好，那么一个插件也可以算是完工了。
现在我们直接来讲解一下具体的代码实现，来看一下类似这样的插件是如何搭建出来的。建议各位开发者在正式开发插件前，先安装插件开发的命令行工具，我们也准备了完善的初始化文档。
好的我们继续来解析这个插件代码。它大概长这个样子，我一步一步来讲。
开发代码的第一件事是什么？当然是新建一个文件夹，把这个项目名称和描述都写好。那么在 Dify 插件里，就需要先把 manifest.yaml 这个文件里的基础信息填好，多语言也做好。
接下来就需要去定义这个工具供应商的名字，相当于你需要定义这个工具的名称和描述细节，也就是图中看到的这个部分，有点像是这个插件的前端设计。
接下来就是这个插件的具体功能了，比如说这个插件需要具备各个动作。那么对应的功能就在 tools 文件下，一个 Action 对应一个 python 文件。
大家可以看到现在只有一个动作，接下来要做的事就是不断地往这里面塞各式各样的参数来让这个插件起作用。比如我想要让这个插件登录服务器，那么它肯定得有基础的 IP 登录和密码这些信息吧，对于这些数据的处理就可以通过 python 代码里的各个函数来进行实现。
好了当我们写好这些插件功能的时候，如何验证这些功能是否按照预期运行呢？我们需要进行远程调试。这也是插件这套体系所带来的新功能，这比之前的那套模式体验好太多了。现在你不需要在本地部署整套 Dify 平台源代码，你只需要在 .env 文件里填写远程调试信息。
如果你想要在 SaaS 环境上调，那么你直接写 SaaS 的调试地址，社区版同理，就写你的社区版服务地址。
调试没问题之后呢，你可以使用命令行工具把这个插件打包为一个 .pkg 文件。这个文件有点像是我们安卓手机里常用的 .apk 安装包。没错，作为个开源产品，我们就是希望插件在安装和开发的过程中是去中心化的，在确保安全的情况下，用户可以自由地进行分享。
像我了解到，其实很多产品和基础设施的厂商，都有很多很好用的 AI Agent 功能或服务，而且 API 文档都很完善，只是缺一个比较好的使用入口，一个清爽的用户使用界面。
那么完全可以把 API 服务转换为 Dify 插件，然后直接加入到我们的生态里，让全球的用户都可以来直接体验产品，打造不一样的 Agent 服务。我也相信我们国内的技术实力，通过不同的组合其实是可以非常快速的搭建出我们心目中那种全知全能的 AI Agent 应用。
并且当模型发生更新的时候，你也可以快速进行版本升级。
那么在插件生态体系下，LLM API 网关这件事成为可能。怎么做到的？插件具备反向调用功能，这也是插件生态下的一个亮点功能。它允许插件调用内部的 Dify 服务，包括模型，应用，工具。
就像地图应用调用系统的 GPS 定位能力，还有微信调用手机的通讯录目录一样 Dify 的 plugin 也可以调用 Dify 本体的能力。
任何人都可以创建这样一个插件，用户只需要进行简单的参数修改，通过这个插件来请求 Dify 内的服务，那么拿来反向调用已托管在 Dify 里的大模型。
大体的思路就是新建一个 Endpoint 类型的插件，来反向调用 Dify 内部的模型。这个 Endpoint 插件支持 API 调用，并且也是支持 OpenAI 格式的。
所需要做的就是新建这样一个插件，然后开启它的反向调用能力。
配置完成后这个插件将自动提供 API 端口，并且这个 API 是兼容 OpenAI 格式的。也就是说你可以在这个插件里选择 Google 的大模型，请求这个插件的 API 本质上是在请求谷歌大模型
通过这个方法，无论你是用的自研模型还是外部模型，只要集成到了 Dify，无论是否兼容 OpenAI 规范，它都可以被“封装”为兼容 OpenAI 的类型，然后被轻松调用。
那么其实通过数据库查询插件，完全可以通过自然语法获取想要的数据。演示效果如下：
这种应用对于内部的效率提升可以说非常大了。甚至业务人员自己就知道需要查询什么样的数据，AI 就可以帮忙查到。
IT 人员做好插件的风险管理就可以了，插件本身只具备只读权限。如果实在不放心，也可以自行开发一个数据库插件来满足业务人员的需求。
不得不想起我自己之前还学过一些 SQL，每次想调数据的时候还得在各个数据库里找键值对，还要盘各个数据库的设计逻辑。不盘对就写不了 SQL 命令，知道这里面的流程有多复杂。现在有了 AI ，自己亲身体验过之后确实感觉丝滑了不少。我希望 Dify 也能解放各个开发者的创意，搭建出更多类似好用的 AI 应用，不断的去往真正的 Agent 去靠。
要想把内容处理好其实也非常考验技术，同时也很考验经验。Dify 在这方面确实不占优势。不过好在我们也发现市面上涌现了很多专业做向量数据库的厂商和服务，那么现在出现了一个能双赢的方案。专业的厂商干专业的事，Dify 只需要做好兼容性就好。因此我们在去年国庆那会就上线并支持了外部知识库的方案。
只需要通过 API 就可以接入了。不过那会插件还没上，依然需要依赖开发者重新开发 API 来实现这个目的。那这样看难度其实也挺大。因为经常会出现这种情况，大家都选择了某个厂商提供的向量数据库服务，但是开发者 A 和 B 相互都不认识，但他们都在干同一件事。这就很浪费时间了。
现在有了插件之后，完全就可以把常用的外部知识库开发为插件，这样开发者不需要反复的开发。因为它本身也不存在一个雕花的需求，只要满足和向量数据库的通讯标准，数据能传输，通了也就通了，代码能跑就行。
就比如说我现在想要调取托管在 Llamacloud 里的数据，那我只需要安装一个插件就可以了。把 Llamacloud 的 API 配置进这个插件里，然后这个插件自动会给一个 API 的请求地址。
然后你只需要把这些 API 接口的数据填写到外部知识库 API 里就可以了。
配置完成后 Dify 就具备调取外部知识库的能力了。
可能有观众反应过来了，那就是这个插件居然还自带 API 端口？
这种类型的插件其实和 Cloudflare 的 Workers 有点类似，自带双向通讯功能。一方面可以接收来自用户所发出的 Query 请求，一方面又可以把数据发送给 Llamacloud，然后把数据再返回给 Dify。可玩性大大提升。
我们内部有时候也在开玩笑，说 Dify 再这么干下去可能真要把 Serverless 的活也给干了。
如果大家对于这个插件类型比较感兴趣，也欢迎阅读我们的文档。如果对文档有什么修改意见呀，那你可以直接找我。
Dify 里是否有可能帮助开发者，搭建出具备上述模能力的 LLM 应用？一个比较好的办法便是我们为模型和工具能力开放提供标准接口，借助社区的力量来一起拥抱全新的策略。我们因此提出 Agent 策略类型插件，让开发者可以自己在 Dify 内实现自己的 agent strategy 并装载到工作流的 Agent 节点当中，像 PPT 中的这个演示就是让 LLM 具备自动使用外部工具的能力，来满足 Function Calling 的要求。
出于时间考虑，我就不仔细分析这种类型插件的代码了，非常多细节。还是那句话，感兴趣的朋友直接看我们的开发文档。
并且还会附加另外一个功能，那就是 Dify 应用将支持以 MCP 服务器的形式进行发布。怎么理解？就是你可以在 MCP 客户端，比如说 Cursor 或 Claude 里，直接通过 MCP 这个协议来使用 Dify 内已搭建好的工作流应用。
另一个比较重要的运营功能就是数据监控。Dify 在开源的第一天，就已经支持了完善的数据监控系统，比如说用户的访问日志记录和反馈标注。
在应用的数据性能监测方面也尽可能的提供了多个监控数据面板，提出了包括会话数呀、Token 输出速度、费用消耗等监控指标。如果不能满足开发者需求，也支持配置第三方的数据监控服务。
企业版
对于有更高并发和多租户的需求，Dify 也提供企业版解决方案。我这里就不详细介绍了，有需要的话可以扫描二维码联系我。
Dify 介绍
如果把 AI 的智能能力比喻成一种和水电网络一样，新的生产资源，我们发现所有开发者在 ChatGPT 刚刚爆火那会都面临的相同类似的问题，不知道如何很好的利用这种资源。早期阶段，很多人就是在反复造轮子，比如说要怎么把 API 融入到自己的产品里，知识库怎么处理，哪怕大家互不认识，但却不影响在做同一件事情。 于是 Dify 也就在此背景下诞生了，作为一款开源的生成式 AI 应用开发，我们向开发者提供了在 AI 开发过程中许多通用的能力与服务组件，包括 AI 工作流编排、RAG 知识检索、Agent 应用构建、多模型管理和应用的可观测工具等。 我们把开发者大概率会遇到的问题和需求，全部做成了一套完整的解决方案，同时开源。
感谢各位支持，Dify 在过去的两年已在 GitHub 上斩获 10W 颗 star，也是在最近跻身全球开源项目排名前五十。也在此感谢各位曾经为 Dify 项目点过星星的用户。
很显然，Dify 之所以能取得今天的成绩，离不开 AI 趋势和大家的支持。
可以说，你只需要有创意有想法，在数分钟内你就可以在 Dify 上创建一个应用。并且还可以随时添加第三方服务来扩展这个应用的功能，打造更好的用户体验。
所以我们其实也很乐观的看到，使用 Dify 的用户，甚至说是深度使用 Dify 的用户，许多人并不是严格意义上的开发者。他们更多的是像我一样的业务人员，比如说财务岗、运营岗，市场销售这些岗位。
在 Dify 诞生以前，一个业务人员在收集到了用户的需求之后，他能做的事情估计就是层层上报，反馈给产品经理，再由开发人员来实现这个功能。
而有了 Dify 之后，对于一些简单的问题，他可能只需要简单的动一动手，把逻辑想清楚了就可以把一个能够解决用户基础问题的应用给做出来。 Dify 自己又是支持 API 的，开发搞定安全和并发之后，说不定只需要写一个按钮就可以上线了。
**业务人员，不应该在这场 AI 技术变革中“失语”。**我们相信，凭借他们的深刻市场洞察和感知能力，再加上由 AI 带来的技术平权，只要跨越了技术这道看起来高深的鸿沟，其实是可以创造出许多意想不到，但却十分有用的 AI Agent 应用。我们都说艺术来源于生活，我在这里也想说，好用的 Agent 应用更是来自对于日常痛点场景的洞察。
而 Dify 要做的事情，就是不断的降低这里面的技术门槛。
其实自从今年以来，大家也许都有同样的体会，那就是大模型自身变得越来越聪明了，并且市面上不断地出现新的协议，来帮助大模型这个智慧大脑来使用工具。
你看年初 DeepSeek 横空出世，ChatGPT 又顺势推出了 DeepResearch，没过多久 Manus 也来了。，再过一个月 MCP 又忽然变得很火，谷歌又推出了 A2A。连去年很火的 RAG 呀都显得没那么火了。
这就是一个百家争鸣的时代，一会一个热点，应接不暇。要知道，也就只是两年前，你只要学会使用怎么调 GPT 的 API，简单套个壳，你就可以把自身包装为一个 AI 产品，开始对外讲故事。
而现在已经不是通过套一个 LLM API 就可以宣传自己是 AI 产品的这个时代了。相反，你需要做很多传统软件工程上需要做的事情。
比如说我们都很期待的 Agent 应用，本质上其实就是给大模型不断地添加多模态支持的能力，它要会联网搜索，会看图，甚至还希望它会说话。以及要使用 OCR 提取各种文档、图标内的信息。同时还需要解决 RAG 知识库准确度的问题。
开发者所做的这一切努力其实都是为了让应用往真正的 AI Agent 方向靠，谁不希望有一个全能的 AI 助理呢？对着手机说一声，它可以自动帮我订机票，帮我指定行程，叫个车，直接告诉我车在什么时候在什么地方出现。哪怕代替我操作浏览器，搞定日常办公软件的使用，都是很理想。
而要想实现这些美好的愿景，我们需要在现有的大模型能力上不断加东西。在AI 技术不断进化的今天。每一次革新都在重塑开发方式。
对开发者来说，技术变了、场景变了，唯独时间和资源始终紧张。使用插件这套体系，开发者可以把 AI 应用的开发过程，变得像乐高拼积木一样简单。
下面来看几个实际的例子，以及它能够解决的问题。这些例子都是通过插件来实现的，后面我会为大家介绍 Dify 插件的实现原理，同时讲解如何开发一个 Dify 插件，以及最后如何通过各个服务搭建出更加自动的 AI Agent 应用。
第一个例子还得是最近被 Manus 带火的浏览器使用（browser-use）用例，智能浏览器助手。
这个例子最早是由我们的日本用户贡献出来的。它的作用就是帮助你定位网页上的关键信息。比如说，我想要知道一个网站的联系表单需要填写什么内容，那么这个工作流会帮你找到该网站内的联系表单。而且会提取该联系表单所在的页面URL和联系项目，并全部带回来。 信息带回来之后，你也可以让 AI 进行处理，你都可以自定义后续的流程。如果说同时能够运行一千次，一万次，然后对提取完的数据分门别类，这里面的价值就起来了。
第三个例子是在 Dify 内使用 SSH 插件，输入指令，比如说在某个服务器里部署一个网页。那么这个插件就可以帮助我们自动登录服务器，然后部署网页。我将在后面用这个插件作为示例，为大家详细说明 Dify 插件是如何开发的。
第四个例子就更简单一些，直接在 Dify 里生成视频。顺带一提这个插件就是我本人做的，主要用到的技术其实问就是把 API 转为 Plugin。
Dify 如何重构工具体系以迎接 Agent 时代
旧有工具体系所碰到的问题
我们经常收到的反馈就是，Dify 什么时候支持某某功能呀。某某大的模型厂商刚出新的模型，社区里马上就会有人来问我们什么时候支持。改到后面，很多时候只是模型参数换一下。但是你这边就要重新打包发版，为了一碟醋包一整个饺子。那么怎样才能改变这种局面？
旧有工具体系 VS 新版插件技术架构
我们的优势是开源，有一个还不错的开源社区。而 Dify 又是一个中间件平台，一个共享的创意工坊，其实有很多好用的能力都是通过第三方的服务来支持的。但是在过去，要想给 Dify 整体贡献外部能力，哪怕只是添加一个简单的 API 工具或者更改模型参数，你都需要先在本地部署整套源代码，然后找到对应的功能模块，参考一堆规范，小心翼翼的进行修改。
所以我们也复盘总结了过去的工具体系设计，把问题总结归纳，大概总结出了以下问题：
- **代码强耦合：**在 Dify 中添加新模型和工具的过程非常繁琐，且会带来过多的工程依赖，导致工具和模型的版本管理问题。
- **用户需求无法闭环：**某些需求，例如接入即时通讯服务，必须在 Dify 之外再封装一层服务，来接受 Webhook 请求，再发送至 Dify 平台内。
- **定制化模块固定性：**例如，Dify 的 PDF 解析器效果不理想，且 RAG 等定制化模块无法灵活调整。
- 多 Workspace 设计：Dify 是多工作空间的设计，每个工作空间所安装的工具并不相通，这意味着不能仅仅通过将工具的 Python 代码挂载至项目源码内 tools/models 目录的方式来实现功能，如果这样做还会面临依赖冲突的问题。
- 插件环境一致性：我们希望同一个插件在不同的环境中表现一致。虽然 Docker 可以解决这个问题，但为每个插件分配一个 Docker 容器将大大增加部署复杂度。
- 高并发的云服务负载：如果每 10 个用户就有一个自定义插件，Dify 将面临数万个插件的运行时负载，这对云服务成本造成很大压力。
- 插件开发调试：作为开发者，每次修改代码都要重新打包并安装插件，同时日志也要跑到 Dify 后台，这会极大影响了开发体验。
- 插件长期运行：例如，用户需要长期运行一个 HTTP 服务器来监听 IM 平台的 Webhook 事件，Dify 插件是否应该支持？
第一个问题：远程调试
我们决定先优先解决的是开发者普遍会遇到的痛点，那就是远程调试：每次修改代码后，不需要安装过程，直接在 Dify 中生效。 我们采用了调试器和运行时分离的方式：调试器等待运行时主动连接。一旦连接建立，本地插件就可以与 Dify 建立长连接，Dify 会将其视为已安装插件，标记为调试模式。用户请求通过长连接转发给本地插件，插件的返回结果也通过长连接发送给 Dify，从而实现了流畅的调试体验。 然而，这种设计面临一个问题：长连接是带状态的，而 Dify 目前的服务是无状态的。在 Kubernetes 集群中，负载均衡会将请求路由到不同的 Dify Pod 上。举个例子，Plugin 1 连接到 Dify 1，Plugin 2 连接到 Dify 2。当用户请求调用 Plugin 1 时，请求可能会被负载均衡路由到 B 工作空间，导致用户无法访问插件 A。因此，我们需要在后续实现流量转发机制来解决这一问题。
第二个问题：插件应支持 Endpoint 能力
我们调研了许多现有的即时通讯（IM）工具和办公协作软件，并综合当前需求，明确了要解决的关键问题：如何让 Dify 接收来自这些平台的 Webhook 请求，并让插件能够处理这些 HTTP 请求。例如，使用 Dify 的 App 来处理用户消息。 为了解决这个问题，我们设计了生成随机 URL 的机制，通过这种方式，我们成功避免了在每个插件中长期运行一个服务器的问题。 Dify 平台承担了 HTTP 请求转发的责任，插件则只是简单处理网络转发的请求。 解决了如何接收消息的问题后，接下来的就是处理消息。设想我正在开发一个 Slack Bot，想让 Dify 的某个 Chatflow 来回复用户消息，流程可以是这样的：
在这个插件中，比较好的处理方式是直接请求 Dify 内的应用，让它来理网络请求，从而实现自动 Bot 的功能。插件里的应该具备的功能也就呼之欲出了：反向调用
第三个问题：插件应具备反向调用能力
**反向调用是新插件机制中的重要概念，允许插件调用 Dify 内部的服务。**例如，插件可以调用已经鉴权的模型、工具，或 Dify 的 App。在以下几个场景中，反向调用发挥了重要作用：- 外部知识库的实现：例如常见的一个外部知识库服务 —— LlamaIndex，它实现了多种 Agentic RAG 策略，通过 LLM 对检索到的列表进行总结。在 Dify 中，它作为一个工具使用，用户只需配置模型参数和输入列表，工具即可安装卸载。这样相当于 Dify 里变相也可以使用 Agentic RAG 方案。顺带一提，我们即将推出 RAG 2.0，大幅强化知识库的能力。
- 模型作为工具：以前，OCR、ASR 和 TTS 模型只能作为独立模型使用，无法灵活调用。现在，它们可以作为工具使用，例如将 Gemini 作为 OCR 工具，简化了操作流程。
- OpenAI 兼容 API：插件通过支持 Endpoint 功能，提供了兼容 OpenAI API 的接口格式。相当于每个插件都支持 API 的调用请求，调用这个插件，就可以调用不同的大模型，例如 Claude 或 Gemini。
- Agent 插件化：插件自动接收参数执行操作并返回结果，并根据需求自定义 Agent 策略。
插件技术架构实现细节
SaaS 服务
**考虑到大规模用户的需求，SaaS 版本的设计采用类似 Serverless 的架构，能够根据使用量自动弹性伸缩，从而确保高并发、高资源利用率和高可用性。**最终，我们选择了 AWS Lambda 作为解决方案，AWS 作为 Dify 的合作伙伴，现已支持现有 SaaS 业务。远程调试
对于调试模式，Dify 支持通过 TCP 网络长连接调试插件，并解决了有状态问题。我们采用类似 etcd 的设计，通过 Redis HashMap 管理插件的连接状态，确保插件的请求能够正确转发到相应的 Pod。为了管理 IP，我们设置了如下两项机制：- 集群需要维护一个 IP 池，Pod 会将其 IP 加入池中。在生产环境中，一台机器可能有多个 IP，并且位于多个子网，因此，Pod 之间采用投票机制进行可达性测试，标记可用 IP。
- 集群需要有一个 Master 节点，定期检查 Pod 的存活情况，清理掉已退出的节点状态，确保集群的稳定性。
为全球的开发者提供全面、功能强大的 AI 应用扩展能力。让 AI Agent 的开发之旅变得更加简单。你的 AI 应用能够更好地”看”、“听”、“说”、“画”、“计算”、“推理”，执行真实世界的操作。
可以说，只要工具足够多，那么通过不同工具的组合，你的 AI 应用也会变得越来越强大。我也看到许多云厂商现在都支持了实时和 AI 进行视频沟通、语音克隆、还有各式各样的基础能力，那么其实都可以变为一个插件。开发者通过这个流程，能够为自己的 AI 应用扩充无限的能力。这里面的想象空间十分巨大。
在新的插件生态设计下，第三方服务都会成为独立的插件包，可以独立安装、卸载和运行，大大增强你们的使用灵活性。开发的插件不单单可以用于解决本身的问题，更有可能在整个生态里发挥作用。只要满足 Dify 这套新标准，开发新范式，任何插件都有可能上线我们的官方插件市场，有机会被全球的开源社区所看到。这也是 Dify 开源的其中一个价值。
插件生态发布之后，大家可以看到我们现在的插件市场上已经出现了 120 多个好用的服务，开发者可以像在逛 App Store 一样，自由地“下载”所需插件。加强自己的 AI 应用能力。
插件能够提供的能力远不止是简单的 API 封装这么简单。把整套结构解耦出来之后，对于业内新出现的协议，比如说 MCP，谷歌的 A2A，都可以很方便的进行兼容和集成。我在这里可以预告一下，Dify 的 MCP 功能即将推出，你可以将 MCP 接入到 Dify 里的工具内，同时也可以把在 Dify 内已搭建好的 AI 应用发布为 MCP 服务器。
如何基于 Dify 插件落地 AI Agent 应用？
其实在 AI Agent 这个概念火起来之前，另一个比较火的自动化技术就是 RPA，人们都是希望任务可以被计算机自动化搞定。那么现在 AI Agent 概念新在什么地方呢？ AI Agent 追求的是“智能决策 + 自主执行”的能力，它尝试模拟人类在复杂任务中进行判断、调整乃至对话协商的能力。这种系统往往具备任务拆解、多轮规划、跨系统操作的能力，目标是做到“给定一个目标，让 Agent 自主完成”。当前 AI Agent 开发面临的主要问题
- 稳定性和可控性差
- 认知与人类不对齐
- 上下文管理困难
- 可验证性和审计难 AI Agent 的行为则是非确定性的，难以测试、复现或解释其失败原因。
- 跨系统操作能力有限
使用 Dify 插件开发 AI Agent 应用的优势
1. 大幅降低 Agent 开发成本
标准接口 + Schema 驱动：Dify 插件通过 OpenAI Plugin / Function Call 兼容协议，开发者只需定义标准 JSON Schema 的接口描述，模型便能理解如何调用这个插件。 无需全流程手工编排：在传统 Agent 框架中，开发者可能需要手动实现意图识别、API 调用顺序规划，而 Dify 插件机制天然支持“模型选择调用时机”，减少了大量控制逻辑的编写。 一处开发，多处复用：开发一个插件即可服务多个应用、多个 Agent，提升复用效率。✅ 总结：开发者在 Dify 上只需专注于定义好工具，将推理和调用逻辑交给模型，大大减少了工程复杂度。
2. 在复杂 Agent 场景中支持“模块化演进”
- 可以先从单个插件 + 简单 Prompt 开始 Agent 任务，逐步增加插件能力，不必一次性完成复杂全流程开发。
- 插件可作为“任务拆解”中的功能组件，使复杂 Agent 更具维护性、扩展性。
- 每个插件可以单独调试、单独测试，降低 Agent 应用出错风险。
Dify 插件开发与案例实践
SSH 操作插件
还记得之前我在前文介绍的 SSH 插件吗？我将会为大家先拆解一下这插件的实现原理。我也建议大家如果想要开发插件的话，先从工具类型的插件入手。 接下来我将带大家手把手开发一个 Dify 插件。插件功能的实现代码语言主要还是 Python，并且已经预置了一个插件开发 SDK，提供命令行工具，所有的开发文档也已经完善。欢迎扫码了解。 工具类型的插件的结构设计其实非常简单，你只需要先定义一个工具的提供商，然后在其中定义这个插件所能够执行的动作。比如说在 SSH 插件里就是定义连接服务，登录服务器这些动作。那么我就在这个提供商里定义各个工具的作用。具体的功能实现就以 Python 函数的形式来解决。
SSH 插件代码解析
在正式解析 SSH 插件代码之前，或者说动手开始写代码之前，需要厘清这件事情的全貌。这个插件的初衷是为了在 Dify 复刻 Manus 的工作流，因此我们可以先回顾 Manus 这个工具的设计路径。
受 Manus AI 启发的两个关键想法包括：
服务器交互： 将 Manus 的“计算机使用”功能转化为服务器管理。
代理驱动的任务规划： 利用 AI Agent 有效地管理和执行任务。
我们现在来仔细拆解下 SSH 插件。这个插件直接可用让 LLM 访问服务器，并且执行操作。怎么做到的呢？
很简单，人类程序员登录服务器需要做什么操作，那么这个插件也需要具备对应的操作动作。比如说登录远程主机、还要找到对应端口、输入密码、然后执行命令等等这些操作。只要把这些操作配置好，那么一个插件也可以算是完工了。
现在我们直接来讲解一下具体的代码实现，来看一下类似这样的插件是如何搭建出来的。建议各位开发者在正式开发插件前，先安装插件开发的命令行工具，我们也准备了完善的初始化文档。
好的我们继续来解析这个插件代码。它大概长这个样子，我一步一步来讲。
开发代码的第一件事是什么？当然是新建一个文件夹，把这个项目名称和描述都写好。那么在 Dify 插件里，就需要先把 manifest.yaml 这个文件里的基础信息填好，多语言也做好。
接下来就需要去定义这个工具供应商的名字，相当于你需要定义这个工具的名称和描述细节，也就是图中看到的这个部分，有点像是这个插件的前端设计。
接下来就是这个插件的具体功能了，比如说这个插件需要具备各个动作。那么对应的功能就在 tools 文件下，一个 Action 对应一个 python 文件。
大家可以看到现在只有一个动作，接下来要做的事就是不断地往这里面塞各式各样的参数来让这个插件起作用。比如我想要让这个插件登录服务器，那么它肯定得有基础的 IP 登录和密码这些信息吧，对于这些数据的处理就可以通过 python 代码里的各个函数来进行实现。
好了当我们写好这些插件功能的时候，如何验证这些功能是否按照预期运行呢？我们需要进行远程调试。这也是插件这套体系所带来的新功能，这比之前的那套模式体验好太多了。现在你不需要在本地部署整套 Dify 平台源代码，你只需要在 .env 文件里填写远程调试信息。
如果你想要在 SaaS 环境上调，那么你直接写 SaaS 的调试地址，社区版同理，就写你的社区版服务地址。
调试没问题之后呢，你可以使用命令行工具把这个插件打包为一个 .pkg 文件。这个文件有点像是我们安卓手机里常用的 .apk 安装包。没错，作为个开源产品，我们就是希望插件在安装和开发的过程中是去中心化的，在确保安全的情况下，用户可以自由地进行分享。
像我了解到，其实很多产品和基础设施的厂商，都有很多很好用的 AI Agent 功能或服务，而且 API 文档都很完善，只是缺一个比较好的使用入口，一个清爽的用户使用界面。
那么完全可以把 API 服务转换为 Dify 插件，然后直接加入到我们的生态里，让全球的用户都可以来直接体验产品，打造不一样的 Agent 服务。我也相信我们国内的技术实力，通过不同的组合其实是可以非常快速的搭建出我们心目中那种全知全能的 AI Agent 应用。
如何确保安装 Dify 插件可信与安全？
开发完插件之后一个很重要的问题就是需要确保插件可信与安全。 插件机制的安全性主要依赖于密码学中的签名，而不是类似 Sandbox 的强制性安全限制。Sandbox 的限制非常严格，导致很多依赖包无法安装和使用，因为这些包可能会涉及未经许可的系统操作，严重影响插件使用体验。相较之下，插件是已经编写完成的代码包。 在安装插件之前，人工审核能够为插件包打上“安全”标签，极大地降低风险。我们采用了基于公钥密码学的签名策略：如果插件通过审核，我们将使用私钥对插件进行签名，标记为“已认证”，如果未通过审查，用户将看到“不安全”的提示。所有未签名的插件无法安装，除非用户手动更改设置。
Dify 插件案例分享
Dify 提供五种插件类型，分别是模型、工具、Agent 策略、Extensions 扩展类型、以及 Bundle 插件包。这里我就不给大家去念各个插件的概念了，大家会后有兴趣的话可以打开我们的文档看看。 接下来我将围绕几个案例来和大家分享一些插件的使用技巧。1. 如何把 Dify 变成 LLM API 网关？
其实之前一直都有人问，Dify 能不能把大模型的 API 托管这件事给做了。你看我反正都要把很多大模型的 Key 保存到 Dify 里，Dify 又可以帮我调各个模型，事实上这已经是一个 LLM API 网关正在做的事了。 可以说 Dify 平台可以兼容大部分的 LLM API，无论是闭源的还是自研的。在模型层面的体验看起来虽然简单，但是这其实是关键的第一步。因为 LLM 本身还是在一个百家争鸣的阶段，像 Claude 和 GPT 用的就是两个请求方法。虽然 DeepSeek 也兼容 OpenAI 方法，但是其实还有很多自研的模型又是遵循另外一套标准。 我知道有很多用户是在两年前就开始用的 Dify，随着大模型逐步迭代，多了很多新增的大模型。于是很多用户已经习惯了在 Dify 里便捷的切换各个大模型。 而插件系统升级之后，之前模型供应商这个地方的功能全部改为了模型插件。这个插件类型可以说是更新频率最高，使用率最广的插件类型了。在插件市场里你可以找到绝大部分主流模型。
并且当模型发生更新的时候，你也可以快速进行版本升级。
那么在插件生态体系下，LLM API 网关这件事成为可能。怎么做到的？插件具备反向调用功能，这也是插件生态下的一个亮点功能。它允许插件调用内部的 Dify 服务，包括模型，应用，工具。
就像地图应用调用系统的 GPS 定位能力，还有微信调用手机的通讯录目录一样 Dify 的 plugin 也可以调用 Dify 本体的能力。
任何人都可以创建这样一个插件，用户只需要进行简单的参数修改，通过这个插件来请求 Dify 内的服务，那么拿来反向调用已托管在 Dify 里的大模型。
大体的思路就是新建一个 Endpoint 类型的插件，来反向调用 Dify 内部的模型。这个 Endpoint 插件支持 API 调用，并且也是支持 OpenAI 格式的。
所需要做的就是新建这样一个插件，然后开启它的反向调用能力。
配置完成后这个插件将自动提供 API 端口，并且这个 API 是兼容 OpenAI 格式的。也就是说你可以在这个插件里选择 Google 的大模型，请求这个插件的 API 本质上是在请求谷歌大模型
通过这个方法，无论你是用的自研模型还是外部模型，只要集成到了 Dify，无论是否兼容 OpenAI 规范，它都可以被“封装”为兼容 OpenAI 的类型，然后被轻松调用。
2. 数据库插件
接下来我想给大家分享如何使用 Dify 插件来搭建数据库分析和查询的 AI Agent 应用。当然这其实也主要是面向业务人员，很多时候业务人员想要调一些用户行为数据的时候是需要层层 IT 审批的。数据安全是一方面，主要问题不是所有的业务人员都掌握 SQL 语法，所以到头来很多公司会专门设一个数据分析的岗位。 所以说这项工作的链路大概是长这样的，前后对比区分效果非常大。
那么其实通过数据库查询插件，完全可以通过自然语法获取想要的数据。演示效果如下：
这种应用对于内部的效率提升可以说非常大了。甚至业务人员自己就知道需要查询什么样的数据，AI 就可以帮忙查到。
IT 人员做好插件的风险管理就可以了，插件本身只具备只读权限。如果实在不放心，也可以自行开发一个数据库插件来满足业务人员的需求。
不得不想起我自己之前还学过一些 SQL，每次想调数据的时候还得在各个数据库里找键值对，还要盘各个数据库的设计逻辑。不盘对就写不了 SQL 命令，知道这里面的流程有多复杂。现在有了 AI ，自己亲身体验过之后确实感觉丝滑了不少。我希望 Dify 也能解放各个开发者的创意，搭建出更多类似好用的 AI 应用，不断的去往真正的 Agent 去靠。
3. 第三方 RAG 插件
接下来的例子是有关于 RAG 方向的。LLM 本身是有内容的局限性的，而使用 RAG 方案可以很好的给它补上关键知识。Dify 在很早期的时候就支持了知识库，也算是当时比较易用的 RAG 解决方案。当然随着技术的演变，很多技术公司都选择了自建知识库，或者是使用市面上更加专业的知识库服务。 其实在做文本向量化的时候是非常考验技术处理的，比如说对于各个格式文档文件的处理，比如说图表内容、甚至说还有视频数据的处理。
要想把内容处理好其实也非常考验技术，同时也很考验经验。Dify 在这方面确实不占优势。不过好在我们也发现市面上涌现了很多专业做向量数据库的厂商和服务，那么现在出现了一个能双赢的方案。专业的厂商干专业的事，Dify 只需要做好兼容性就好。因此我们在去年国庆那会就上线并支持了外部知识库的方案。
只需要通过 API 就可以接入了。不过那会插件还没上，依然需要依赖开发者重新开发 API 来实现这个目的。那这样看难度其实也挺大。因为经常会出现这种情况，大家都选择了某个厂商提供的向量数据库服务，但是开发者 A 和 B 相互都不认识，但他们都在干同一件事。这就很浪费时间了。
现在有了插件之后，完全就可以把常用的外部知识库开发为插件，这样开发者不需要反复的开发。因为它本身也不存在一个雕花的需求，只要满足和向量数据库的通讯标准，数据能传输，通了也就通了，代码能跑就行。
就比如说我现在想要调取托管在 Llamacloud 里的数据，那我只需要安装一个插件就可以了。把 Llamacloud 的 API 配置进这个插件里，然后这个插件自动会给一个 API 的请求地址。
然后你只需要把这些 API 接口的数据填写到外部知识库 API 里就可以了。
配置完成后 Dify 就具备调取外部知识库的能力了。
可能有观众反应过来了，那就是这个插件居然还自带 API 端口？
这种类型的插件其实和 Cloudflare 的 Workers 有点类似，自带双向通讯功能。一方面可以接收来自用户所发出的 Query 请求，一方面又可以把数据发送给 Llamacloud，然后把数据再返回给 Dify。可玩性大大提升。
我们内部有时候也在开玩笑，说 Dify 再这么干下去可能真要把 Serverless 的活也给干了。
如果大家对于这个插件类型比较感兴趣，也欢迎阅读我们的文档。如果对文档有什么修改意见呀，那你可以直接找我。
4. 如何使用 Dify 插件实现复杂的 Agent 策略？
这时候有朋友会问了，你刚刚介绍的这些插件，感觉其实也就是增强版的工具，本质上还是需要人工介入去手动来调。有没有更加自动化更加 Agent 的方案？ 曾经有一个用户向我们提问 我们是否可以支持更多的 Agent 模式，比如说 ReAct、FunctionCalling 呀 而且现在大家可能听过像 CoT/ToT/GoT/BoT/ 思维链/思维树/思维图/思维袋 等等这些新颖的策略。毫无疑问，这些新的模式能够大大增强 LLM 的性能。
Dify 里是否有可能帮助开发者，搭建出具备上述模能力的 LLM 应用？一个比较好的办法便是我们为模型和工具能力开放提供标准接口，借助社区的力量来一起拥抱全新的策略。我们因此提出 Agent 策略类型插件，让开发者可以自己在 Dify 内实现自己的 agent strategy 并装载到工作流的 Agent 节点当中，像 PPT 中的这个演示就是让 LLM 具备自动使用外部工具的能力，来满足 Function Calling 的要求。
出于时间考虑，我就不仔细分析这种类型插件的代码了，非常多细节。还是那句话，感兴趣的朋友直接看我们的开发文档。
5. 预告：即将上线 MCP 工具
今天可以和大家预告个功能，那就是 Dify 即将支持通过 HTTP 协议集成 MCP 服务，使得开发者可以轻松地将各种外部 MCP 服务引入至现有 Dify 应用中。
并且还会附加另外一个功能，那就是 Dify 应用将支持以 MCP 服务器的形式进行发布。怎么理解？就是你可以在 MCP 客户端，比如说 Cursor 或 Claude 里，直接通过 MCP 这个协议来使用 Dify 内已搭建好的工作流应用。
推动 AI Agent 应用从原型到上市
假设你已经完成了 AI Agent 的开发，那么很自然的就会想到数据监控和投产。开发者最关心的莫过于辛辛苦苦搭建的 AI 应用，支不支持 API 功能？ Dify 在开源的时候就结合了 LLMOps 和后端即服务（BaaS）理念，所有的主要功能均支持 API。我们的五个类型的应用类型全部支持 API，并且还贴心的内置了自动生成嵌入代码的功能，甚至连知识库也支持 API。
另一个比较重要的运营功能就是数据监控。Dify 在开源的第一天，就已经支持了完善的数据监控系统，比如说用户的访问日志记录和反馈标注。
在应用的数据性能监测方面也尽可能的提供了多个监控数据面板，提出了包括会话数呀、Token 输出速度、费用消耗等监控指标。如果不能满足开发者需求，也支持配置第三方的数据监控服务。
企业版
对于有更高并发和多租户的需求，Dify 也提供企业版解决方案。我这里就不详细介绍了，有需要的话可以扫描二维码联系我。
总结
最后还是很感谢大家的时间，也感谢主办方提供的一个分享的机会。希望我今天对于 Dify 的介绍、以及新上线的这一套插件开发体系，AI Agent 的案例开发思路和分享可以真正的帮助大家在这个变幻莫测的 AI 时代快速上线应用，抢占时代先机。 AI时代变化很快，但机会也很多。 Dify 希望成为大家的武器库，让每个有想法的人都能快速把创意变成现实。 今天的分享就到这里，欢迎大家来体验Dify，一起创造更多可能！