在我接触Dify这一年多里被问得最多的一个问题不是工作流怎么搭建也不是怎么接Ollama而是Plugin和Skill到底有什么区别很多人打开插件市场看到一堆标注“Skill”的插件包又翻到文档里满屏的“Plugin”字眼直接就看懵了。甚至不少已经跑通本地部署、做过企业级知识库项目的朋友也经常在这两个词上绕弯子。今天这篇我就把这事一次讲透Plugin是什么Skill是什么两者在Dify架构里的位置分别在哪什么时候该用哪个以及怎么在本地环境里把两者真正跑起来。不管你是刚装好Dify社区版的新手还是已经在折腾工作流、知识库、Agent的老手都值得把这篇看完。看完以后再遇到插件市场里那些带“Skill”字样的包你会非常清楚它到底是用来干嘛的该不该装。1. 先别急着装插件把两个概念的底层逻辑整明白1.1 PluginDify的“可插拔底座”Plugin对应的是Dify的平台扩展机制。Dify本身提供的核心能力已经很完整模型接入、知识库、工作流、Agent、RAG流水线这些都是开箱即用的。但真实项目从来不会只靠官方内置能力解决问题。你可能要对接内部OA系统可能要调某个第三方天气接口可能要用某个embedding模型的特殊能力甚至要把Dify接到自己团队的消息机器人上。这些官方没有现成提供的东西就需要Plugin来补位。Plugin本质上是一套封装好的、可复用、可分发、可独立升级的扩展单元。在Dify 1.x里插件以插件市场Marketplace的形式分发支持在线搜索安装、本地调试、离线包导入等几种方式。开发Plugin时官方有配套的插件开发框架核心是Plugin Daemon插件守护进程用来做进程隔离。开发者可以用Python编写扩展逻辑定义模型供应商、工具、扩展点等内容最后打包成.difypkg文件发布到市场。那为什么Dify非要搞一套Plugin而不是把所有外部集成直接写进核心代码里这个理由非常现实核心代码如果每加一个外部集成就发一个新版本版本迭代会直接爆炸。而且外部集成往往依赖特定的SDK版本、Python运行环境、权限配置硬融在一起会让整个平台变得很脆弱。Plugin机制的意义就在于把依赖关系隔离出去你用不到的功能完全不加载用到了就单独安装互不干扰。这也是Dify社区版能保持快速功能扩展、同时核心依然相对稳定运转的关键原因。1.2 Skill跑在Agent里的“专项技能包”Skill这个词近年因为Codex、Claude这类AI编程和智能体工具大火很多人对它已经有了模糊的概念。在Dify里Skill出现得比Plugin晚一些早期Dify里所谓的“技能”更多只是指Agent节点里配置的Prompt和工具调用。等插件生态慢慢成型以后官方开始把“Agent Skill”作为一个明确的分类来对待。你可以把Dify里的Skill理解成专门针对Agent场景封装好的一组能力描述和调用策略。Skill并不是独立于Plugin之外的另一个平行系统。恰恰相反大多数Skill是以Plugin包的形态存在的。当你安装了一个Skill类型的插件你实际上是给Agent装了一套“专项技能包”。这个技能包会告诉Agent在什么条件下使用这个技能、技能内部会调用哪些工具、推理步骤怎么组织、返回结果按什么格式处理。与直接在系统Prompt里写一句“你是一个擅长做报告的助手”不同Skill是结构化、可复用、可被Agent动态触发的。两者最直观的差别是Plugin解决的是“平台能接什么、能调什么”Skill解决的是“Agent在特定场景下怎么做得更好”。Plugin偏基础设施Skill偏行为策略。你完全可以在Dify里装一个提供搜索工具的Plugin但如果没有配套的SkillAgent往往只会把它当成一个普通函数来调用搜索质量全看模型临场发挥。而一旦有了一套写好的搜索SkillAgent就会按照Skill定义的完整流程执行先拆解关键词、再选择搜索策略、再提炼结果、最后组织回答。实测下来效果稳定得多也更容易调优。1.3 用一张表把差异讲清楚对比维度PluginSkill定位平台扩展能力Agent的专项行为策略面向用户开发者、平台管理员Agent应用的开发者、最终使用者分发形态插件包.difypkg、插件市场通常也通过插件市场分发核心内容模型供应商、工具、扩展点等Prompt策略、工具调用模板、任务流程、输出格式约束运行位置Plugin Daemon隔离进程Agent编排层典型例子接入Ollama、封装外部API、创建Webhook扩展让Agent会做代码审查、按固定模板生成报告这张对照表不用背需要判断的时候回来看一眼就行。核心记忆方式就一句话Plugin是“插上去就能用的模块”Skill是“装在Agent脑子里的标准操作流程”。2. 从架构和加载机制看差异为什么Skill离不开Plugin2.1 Plugin的运行机制插件守护进程与隔离加载Plugin在Dify里不是简单的配置文件它有一套完整的运行体系。当你在Dify管理后台安装一个Plugin后系统会把它交给Plugin Daemon来处理。Plugin Daemon是独立于API服务之外的进程负责加载插件的元数据、建立与插件进程的通信、执行权限校验、收集日志和监控指标。插件代码不会直接跑在Dify主进程里面而是运行在隔离环境中。这一步隔离带来的好处非常实在第一插件本身崩溃不会拖垮主服务最坏情况只是该插件的功能暂时不可用第二插件可以依赖自己的一套Python环境即使它需要的某个第三方库和Dify主进程的依赖版本冲突也不会有影响第三平台可以对插件做细粒度权限控制比如限制插件只能访问某些API域名或者只能读取指定配置。这种设计其实和浏览器扩展程序、IDE插件是一个思路把“第三方代码”关进笼子里而不是让它和核心系统住同一个房间。在Dify的插件体系里官方会按功能类型区分插件常见的比如模型供应商类、工具类、Agent策略类、扩展点类。其中Agent策略这一类就和Skill的关系非常密切。核心API服务与插件之间通过定义好的RPC接口通信所以你才会看到在工作流里添加一个工具节点时底层实际上是某个已经在Plugin Daemon里运行的插件在响应请求。这也是为什么Plugin出问题的时候很多排查动作要去看插件Daemon的日志而不是盯Dify主服务的日志。2.2 Skill的封装方式声明层、策略层、工具层Skill的封装我习惯把它拆成三层来看。第一层是“声明层”。它声明这个Skill叫什么名字、适合什么场景、哪些Agent可以加载、是否需要特定模型类型支持。Agent在启动时或者会话过程中会根据这些声明来决定自己当前“会什么”。声明写得好不好直接决定后续Agent能不能在正确时机找到这个技能。第二层是“策略层”。这一层包含一段与任务相关的指令类似Prompt但比普通Prompt要细得多。它不是简单写一句“你要做什么”而是细化到“遇到什么情况要切换备选方案”“结果不满足预期时怎么重试”“输出格式到底长什么样”。策略层是Skill里最值钱的部分因为它承载了人的经验。第三层是“工具层”。Skill会引用若干工具这些工具可能是Dify自带的也可能是通过Plugin安装进来的。真正干活的是工具层策略层负责编排。从这个角度看一个Skill如果依赖了某个外部工具那它基本上就必须以Plugin包的形式存在否则没法把工具依赖一起打包分发给别人。触发方式上Skill分主动和被动。主动触发是你直接在Agent配置里把某个Skill启用被动触发是Agent在对话过程中根据用户问题语义结合Skill的声明信息动态判断“当前问题落在哪个技能的适用范围”然后自行调用。Dify实际执行时通常还会做意图匹配匹配度够了才会激活技能。这里有个很关键的经验Skill描述写得好不好直接影响被动触发的准确率。很多人装了Skill发现Agent根本不主动用十有八九是描述和用户真实表达方式差距太大模型匹配不上。2.3 Plugin与Skill的真实绑定关系我举个例子这个例子我实际在本地环境跑过。我在本地Dify里接入Ollama用Llama系列模型跑对话和知识库问答。这个操作本身只需要一个Plugin——Ollama模型供应商插件。装完后在模型供应商页面里配置好Ollama地址、模型名和上下文长度工作流里就能直接选到这个模型。整个过程里完全没有Skill的事因为模型接入只是“把底座接上”。但当我希望Agent不要只把本地模型当聊天机器人用而是能按照我规定的格式做抽取、分类、总结时模型本身的能力就不够看了。我需要给Agent定义一套“信息抽取技能”告诉它第一步理解输入第二步识别实体第三步按特定JSON结构输出。这套东西可以做成Agent Skill也可以直接写在工作流里。如果我想让它在多个Agent里复用用Plugin体系来封装更合适建一个插件里面声明一个Agent Skill代码里还能加后处理逻辑比如校验输出字段是否完整不完整时报错重新生成。所以你能看到Plugin是Skill的载体Skill是Plugin在Agent层的“灵魂”。一个Plugin可以只提供模型也可以既提供模型又附带Skill更多情况下Skill会依赖多个Plugin提供的工具协同工作。理解了这层关系再去插件市场下载那些“某某Skill”包时你就能看懂为什么有些包会要求你先安装某个Tool插件了——Skill负责编排真正干活的是底层工具。3. 实际选型什么时候该用Plugin什么时候该用Skill3.1 典型场景拆解装底座还是装打法哪些场景铁定要用Plugin我给你列三类最典型的。第一类你有私有API要封装给工作流或Agent使用比如查询内部库存、读写CRM、调用公司统一的短信接口。这种情况下你写一个工具类Plugin注册成可调用工具Dify内部就能像调用内置工具一样调用它而且能统一做鉴权和参数校验。第二类你要接入新的模型服务尤其是本地私有模型。模型接入涉及API地址、模型名称、上下文长度、鉴权方式、请求响应格式转换等一大堆细节这些逻辑都放在model provider类型的Plugin里最合适。第三类你希望Dify在特定事件发生时向外部系统发通知比如Agent运行结束、知识库文档切分完成、工作流失败重试。这时你需要extension类型的Plugin挂到平台对应的事件扩展点上。用到Skill的场景也很清晰。首先是“输出规范复用”场景你希望Agent每次回答都包含结论、依据、置信度三个小节且这个规范要在多个Agent里统一复用那写成Skill比复制粘贴Prompt靠谱得多。其次是“复杂多步能力”场景比如代码审查先读取代码变更再按安全、性能、可读性逐项检查最后生成审查报告。这种能力用工作流硬写会很笨重封装成Skill Agent就能够在正确时机自动调用。最后是“降低使用门槛”场景你希望团队里的非技术成员也能给Agent添加技能而不是让他们去写Plugin代码。Skill的声明和策略很多通过配置就能完成门槛比插件开发低不少。再给个反例。如果只是想让Agent会算数学题你需要的是一个计算工具Plugin而不是Skill。只有当你要把“读题—建模—分步计算—验算—格式化输出”这整套流程固化成标准行为时Skill才真正发挥价值。工具和策略分开看选型就不会太纠结。3.2 工作流、Agent、知识库里的真实位置工作流和Agent是Dify里最容易和Plugin、Skill概念纠缠在一起的地方。我自己的理解是这样的工作流是显式的流程编排。你在画布上连线每一步都是确定性的。工作流节点调用的工具既可以来自内置能力也可以来自Plugin。工作流本身一般不叫Skill但你可以把一个成熟的工作流模板化发布成可复用的技能这在团队里是很常见的做法。Agent是隐式推理。模型在运行时自行决定调用什么工具、按什么顺序执行。Agent可以加载Plugin提供的工具也可以加载结构化的Skill。Skill在这里起到的作用是把模型的决策空间从“一堆工具列表”收敛为“相对标准的几套打法”大幅提升稳定性和可解释性。知识库是上下文供给方。Plugin可以增强知识库处理链路比如更细粒度的文档切分、多路召回、rerank调用。Skill则可以在知识库问答场景里规定“回答时如何引用文档”“检索结果不足时怎么办”“用户问题与知识库无关时怎么回应”。三者并不互斥实际项目里经常是叠加使用。做过企业知识库类项目的人应该深有体会数据清洗、切分、召回这些环节纯靠内置能力能跑但效果常常不稳定。加一个rerank工具Plugin再配一套“基于知识库的严谨作答”Skill回答质量和规范程度会立刻上一个台阶。这种组合用法才是Plugin加Skill在真实项目里最大的价值所在。3.3 选型速查表闭眼照做版你的需求首选方案理由接入新模型、本地模型Plugin模型供应商类模型接入属于基础设施行为封装外部API给平台调用Plugin工具类、扩展点类让任意节点和Agent都能引用让Agent按固定流程做事Skill流程化、可复用、可动态触发让Agent按固定格式输出Skill输出约束属于策略层沉淀复杂工作流经验模板化后做成Skill或Plugin内置供多个应用复用统一改造多个Agent的行为Plugin加Skill组合Skill统一策略Plugin统一工具来源这算是我心里默认的“第一原则”。当然实际项目里也见过有人把本该用Plugin封装的外部接口硬写成Skill也能跑但后面维护会非常痛苦。该用Plugin用Plugin该用Skill用Skill这是一条不需要妥协的边界。4. 实操在本地Dify里把Plugin和Skill都用起来4.1 环境准备本地部署并接入Ollama说实话只说思路具体步骤官方文档已经很全了我重点讲几个容易被坑到的地方。本地部署建议直接用Docker Compose。较新的社区版已经引入了更完善的多租户管理能力适合团队内部共用一套环境。克隆Dify仓库后比较稳妥的做法是执行docker compose up -d等所有容器起来以后进入后台完成初始化。这里有几个高频坑。第一是端口冲突Dify默认用80和443端口本地如果被占用需要在.env里改EXPOSE_NGINX_PORT。第二是版本差异如果你想玩最新的插件和Skill特性别用一个很老的tag切到最新发布版本会省很多事但要注意数据库迁移问题。第三是容器资源Dify全家桶起步大概要2GB内存再加上Ollama跑模型的占用开发机建议至少16GB内存才够顺畅。接Ollama是典型的Plugin操作。安装Ollama模型供应商插件后在模型供应商页面配置地址时千万注意Ollama和Dify都在同一台机器上也不要填localhost要填宿主机网络的网关地址。Linux下一般是172.17.0.1macOS填本机局域网IPWindows同理。这一点卡住了很多人因为Dify的容器网络里localhost指向的是容器本身根本访问不到宿主机上的Ollama。接上Ollama后还要把对话模型和Embedding模型分别配好知识库和对话才能都走本地模型。4.2 从插件市场安装Plugin并验证Dify后台左侧有“插件”入口点进去能看到插件市场。安装插件有两种常用方式在线市场搜索安装或者导入离线包。如果你部署的环境没有外网离线包方式更现实在能联网的机器上下载好.difypkg文件拷过去导入就行。我以安装一个工具类Plugin为例。在市场里搜到目标插件后点击安装系统会列出该插件依赖的其他Plugin可以一键安装。这里有个很多人会忽略的点插件安装成功不代表插件可用。安装完成后需要到“工具”或对应的模型供应商、扩展页面去启用并配置API凭证。配置完密钥或地址后一定要点“测试”按钮确认能连通不然等到工作流跑起来了才发现排查效率会很低。验证插件是否生效最快的方式是在工作流里新建一个工具节点选择刚安装的插件工具随便跑一个最小测试。如果返回正常结果说明底座通了。跑不通就先去看Plugin Daemon日志别急着怀疑Dify主服务。多数情况下问题出在插件的依赖下载失败、权限配置缺失、或者请求地址写错这几点上。4.3 在Agent里定义并启用一套Skill接下来是让Skill真正跑起来的部分。在Agent应用或Chatflow的Agent节点里你会看到一个“技能”配置区域里面可以列出当前Agent启用的技能列表。定义一个全新的Skill大致有这么几步在Agent节点上点击“添加技能”选择“新建技能”或者直接从插件市场导入现成的Skill包。填好技能名称和描述。这个描述字段直接决定Agent能不能在预期时机调用它尽量写“当用户要求……”“当用户提到……”这类触发场景明确的句子别只写“这是一个有用的技能”。编写策略正文。策略正文建议用清晰的编号步骤让模型能照做。比如第1步分析用户问题中的关键信息第2步从可用工具中选择匹配项第3步执行工具调用并暂存原始结果第4步按固定格式整理输出输出必须包含结论、依据、置信度三个字段。保存后把Agent发布到对话环境用几条贴近技能描述的测试语句触发它。到这一步Skill才算真正接入了。你可以做个对比测试同一个Agent不启用Skill时面对“帮我写一份周报”会自由发挥启用“周报生成”Skill后它会先收集本周工作项、再自动归类、再按模板输出。差别非常直观这也是验证Skill有没有生效的最简单方法。4.4 进阶自己写一个包含Skill的最小Plugin包如果你的需求比较定制化只靠市场插件是不够的就得自己动手写Plugin。目前官方推荐用Python一个最简插件包结构大概是这样的my-plugin/ ├── manifest.yaml ├── main.py ├── requirements.txt └── _assets/ └── icon.svgmanifest.yaml里声明插件的名称、版本、类别、作者同时声明这个插件包含哪些能力。如果你想让它同时提供工具和Agent Skill就在manifest里分别声明对应节点。main.py里写实际逻辑比如定义一个工具类和对应的处理函数Agent Skill更多是在manifest和策略描述里做文章代码里可以加一些后处理逻辑。官方提供plugin开发命令行工具可以本地调试。大致流程是先用初始化命令生成骨架再启动开发模式写完代码后用打包命令生成.difypkg文件最后在Dify后台直接导入。我踩过的一个坑是在manifest里声明的icon路径大小写写错导致插件能安装但无法正常展示。另一个坑是插件里用了requests库但requirements.txt里忘了写运行时报错找了大半天。所以建议写完以后先用本地Python环境把main.py单独跑一遍再丢进Dify环境里测定位问题会快很多。5. 常见问题与排查技巧实录5.1 高频问题速查表问题现象可能原因排查方向装了Plugin但工具列表里找不到插件没有配置凭证或未启用到插件详情页配置API Key并测试连通Skill安装了但Agent就是不调用技能描述和用户表达不匹配匹配阈值过高重写描述加入更多触发场景词汇降低触发条件本地Ollama连接失败地址填成localhost容器网络不通改为主机网关地址确认Ollama监听在0.0.0.0Plugin安装卡在“安装中”网络下载依赖失败插件版本不兼容查Plugin Daemon日志检查市场连通性或导入离线包知识库检索结果乱、回答不引用依据缺少rerank没有配套问答规范加rerank工具插件给Agent配置知识库作答Skill升级Dify后部分Plugin失效插件接口变动依赖版本不兼容检查插件版本是否兼容当前Dify版本更新或回退插件Agent工具列表太长导致选择困难Plugin装得太多工具没有收口用Skill把多个工具收敛成几套打法降低模型决策负担5.2 几条独家避坑经验先强调最常见的一个问题技能描述千万别偷懒。我见过太多人把Skill描述写成一两句官方话术结果Agent在测试时根本不触发。正确的做法是把用户最可能问的几种说法都写进去比如“用户要求生成报告”“写总结”“输出周报”“整理会议纪要”都属于“报告生成”技能的触发场景。Dify内部做意图匹配时这种描述命中率会高很多。第二Plugin装多了不等于能力变强。很多人看到一个插件就装一个最后Agent的工具列表拉下来一大串模型反而不知道该选谁。Plugin越多模型在工具选择上的负担越重。这时候Skill的价值就是“收口”把多个工具收敛到一个技能里让模型只需要判断“要不要用这个技能”而不是在几十个工具里一个个去算。第三文件名和目录名统一保持小写。在Windows和Linux都要跑的项目文件大小写不一致早晚会让你半夜爬起来改配置。Plugin打包文件、图标资源、代码文件名统一规范别高估自己以后的记性。第四升级前先做备份。Dify社区版升级相对频繁尤其是从旧版本跨越到大版本时数据库迁移可能会出问题。实测下来先给PostgreSQL和Redis的volume做一次快照再执行升级出问题还能退回原状。折腾本地部署的人这点基本属于必备修养。第五别忽略插件依赖关系。安装某个Skill包时如果提示需要同时安装某个Tool插件千万别跳过。Skill往往依赖底层工具缺少工具Skill的流程跑到一半就会卡死或者直接报工具未找到。插件市场上的依赖说明写得很清楚就是给人看的。我在实际操作里尝试过很多种组合最后得出一个自己的习惯凡是牵涉到外部系统、模型、数据源的先问自己“这个能力是不是要复用、要不要分发给别人”是就上Plugin凡是牵涉到Agent的回答风格、处理流程、输出规范的先问自己“这个行为是不是要固化下来、要不要跨应用复用”是就上Skill。把这两个问题问清楚绝大多数选型困难症就都解决了。Dify插件和技能体系还在快速演进很多边界以后可能还会调整但只要抓住“Plugin管连接Skill管行为”这条主线再出新概念也不会迷路。希望这篇文章能让你少走一点我踩过的弯路。