Dify接入Skill【开源】：从AI交互模式发展看工作流，智能体，MCP，Skill

引言

摘要：本节给出关键结论、核心步骤和可执行建议。

对于工程团队来说，AI 应用已经不只是“接个大模型 API”这么简单。真正进入生产后，问题会迅速变成：任务怎么拆、工具怎么接、执行怎么控、能力怎么复用、风险怎么隔离。

Dify 这类平台之所以值得关注，不是因为它能“更快搭个 Demo”，而是它把 Workflow、Agent、MCP、Plugin、Skill 这些能力逐步拼成了一套可落地的工程结构。尤其是近期出现的开源 Skill 方案，例如 Dify Marketplace 上的 Skill_Agent，让本地目录、脚本和说明文档可以被 Agent 按需读取和执行，这意味着 AI 能力开始从“Prompt 工程”走向“可管理的任务包工程”。

本文不讲泛泛概念，重点回答三个问题：

为什么说 Skill 是 Agent 之后的自然演进？

Dify 里 Workflow、Agent、MCP、Skill 到底怎么串起来？

工程上如何接入开源 Skill，并控制执行、安全和维护成本？

摘要

摘要：本文从 Dify 的工程能力出发，分析 AI 交互模式从 Workflow 到 Agent，再到 MCP 与 Skill 的演进逻辑，并给出开源 Skill 接入的落地方法。

核心结论有四点：

Workflow 适合强确定性流程编排，节点固定、路径可控。

Agent 引入“动态决策”和“工具选择”，适合复杂任务分解。Dify 官方文档已明确 Agent 节点可定义角色、目标、上下文，并接入工具 [6]。

MCP 正在成为外部工具接入的标准化协议层。Dify 已支持在 Agent、Workflow、Agent Node 中集成 MCP 工具 [2][4]。

Skill 则进一步把“能力”从单个工具升级成“带说明、带文件、可执行、可渐进披露”的任务包。Dify Marketplace 中的 Skill_Agent 已给出可行实现 [1]，而 OpenAI 对 Agents SDK 的新演进也已将 progressive disclosure via skills 列为 Agent primitives 之一 [5]。

如果你的系统还停留在“一个大 Prompt + 几个 API 工具”的阶段，那么 Skill 化很可能是下一个提升稳定性和复用性的方向。

从工作流到Agent：Dify里的能力演进主线

摘要：Dify 的能力演进可以理解为“固定流程”到“动态决策”的迁移，Workflow 负责编排，Agent 负责选择。

先看最基础的 Workflow。它的优势是确定性强：开始节点、LLM 节点、代码节点、HTTP 节点、知识检索节点，串起来就是一条显式业务链路。这种方式非常适合：

表单处理

审批流

RAG 问答标准流程

数据清洗与通知分发

但当任务变复杂，固定工作流会遇到两个问题：

分支爆炸：所有可能路径都要人工画出来；

工具选择僵化：流程先定死，模型只能在节点里“回答”，不能主动规划。

这时 Agent 就出现了。Dify 官方 Agent 节点文档指出，Agent 节点通过自然语言描述角色、目标、上下文，并且可以引用上游变量；同时其工具接入依赖清晰的描述、授权和参数设计，而这些会直接影响 Agent 的工具决策 [6]。这意味着：

Workflow 负责给 Agent 提供上下文和边界；

Agent 在边界内自主选择工具和步骤。

所以工程上更合理的理解不是“Workflow 被 Agent 替代”，而是：

Workflow 是外层控制面，Agent 是内层执行面。

这也是为什么 Dify 的 MCP 文档特别强调：Workflow 中的 Agent 节点也可以直接选择 MCP 工具，使用方式与独立 Agent 一致 [2]。这说明 Dify 的设计不是两套体系，而是逐渐统一的。

MCP为什么重要：它不是一个工具，而是一层工具协议

摘要：MCP 的价值不在于新增一个插件，而在于把工具接入从“平台私有适配”升级为“标准协议接入”。

MCP（Model Context Protocol）在 Dify 里不是概念展示，而是已经进入实际接入层。官方文档说明，连接 MCP servers 后，工具会出现在 Agent、Workflow、Agent Node 等场景中；在 Workflow 中，MCP tools 甚至可以成为可用节点 [4]。这非常关键，因为它带来三件事：

1. 工具接入标准化

以前每接一个外部系统，都要做一层平台专属封装。MCP 的目标是让“模型可调用工具”拥有统一协定。对工程团队来说，这降低了：

接入适配成本

平台迁移成本

多工具治理复杂度

2. Agent 能力边界扩大

如果 Agent 只能调用平台内置工具，它始终受限。MCP 让外部能力可以变成 Agent 的“原生工具集”。Dify 文档也说明在 Agents 中工具会按服务器分组展示 [4]，这意味着接入规模扩大后仍能保持管理结构。

3. 为更高层的 Agentic Layer 打基础

研究论文指出，复杂 MCP server 生态正在推动一种更声明式、模型无关的 agentic layer [8]。换句话说，MCP 正从“工具协议”往“智能体基础设施”演进。

如果把架构分层来看：

Workflow：负责流程编排

Agent：负责动态规划与决策

MCP：负责统一工具接入协议

Skill：负责封装可复用任务能力包

这四层叠起来，才是今天 AI 工程系统越来越像“软件系统”而非“Prompt 脚本”的原因。

Skill是什么：从工具调用走向可复用任务包

摘要：Skill 的本质不是另一个工具，而是把说明、资源、脚本和执行约束封装为可渐进披露的能力单元。

Dify Marketplace 上的 Skill_Agent  插件 给了一个很实用的定义：它把本地目录视作工具箱，模型按需读取 skill manual，在必要时再读取文件或运行脚本，最后输出文本或文件 [1]。这里最值得工程师关注的是“渐进披露”机制：

先读 Skill 的说明文档，而不是一次把所有内容塞给模型；

只有在需要时，才进一步读取文件或执行脚本；

这样能减少上下文污染，也能降低误调用概率。

这与  OpenAI               在 2026 年 Agents SDK 演进文章中的提法高度一致：其明确把 skills 的 progressive disclosure 列为 agent primitives 之一 [5]。说明 Skill 不再只是社区里的非主流玩法，而是逐渐成为 Agent 基础设施的一部分。

从研究角度，SkillFoundry 论文进一步把 skill 定义为包含以下信息的结构化能力单元 [7]：

任务范围

输入输出

执行步骤

环境假设

来源

测试

这个定义很重要。因为它意味着一个成熟 Skill 不应只是“一个脚本 + 一段提示词”，而应该是：

可理解、可调用、可验证、可治理的任务包。

这也是 Skill 相比 MCP Tool 更进一步的地方：

MCP Tool 更偏“单次函数调用”

Skill 更偏“带运行说明和执行资产的复合能力”

Dify接入开源Skill的工程路径

摘要：在 Dify 中接入开源 Skill，推荐采用“Workflow 控边界 + Agent 调度 + Skill_Agent 执行”的组合方式。

结合 Skill_Agent 插件说明 [1] 和 Dify 文档 [2][4][6]，一个实用落地路径如下。

1. 明确 Skill 的宿主位置

Skill_Agent 的核心机制是把本地目录当作 Skill 仓库 [1]。因此第一步不是写 Prompt，而是先设计目录结构，例如：

每个 skill 一个目录

目录中至少有 manual/说明文件

可附带模板、脚本、样例、静态资源

这其实已经很像一个小型“能力包仓库”了。

2. 用 Workflow 管理输入输出边界

不要让用户请求直接裸奔到 Skill。更稳妥的做法是：

Start 节点接收参数

LLM/Code 节点做任务分类或参数规范化

Agent 节点调用 Skill_Agent 或 MCP Agent

最后统一输出文本、文件或状态码

这样做的好处是：

前置做输入校验

后置做输出格式化

Skill 执行失败时更容易兜底

3. Agent 节点中配置工具策略

 Dify Agent 节点支持自然语言定义目标和上下文，同时工具描述会显著影响其决策 [6]。因此配置时要特别注意：

明确告诉 Agent 什么时候调用 Skill

提供清晰的 skill 适用场景

限制不必要的自由发挥

指定结果输出格式

例如，不要写“你可以灵活完成任务”，而应写“优先读取 skill manual，确认可执行后再读取文件或运行脚本”。

4. 必要时引入 MCP Agent Strategy

如果任务链条更长，需要动态规划、多轮推理、复杂任务分解，可以考虑 Marketplace 上的 mcp_agent 插件。其页面说明该插件支持 MCP tool invocation，并面向 Dify 增强复杂任务分解和动态规划能力，可集成进 workflow [3]。

因此，一种增强型结构可以是：

Workflow 负责业务编排

MCP Agent Strategy 负责规划

Skill_Agent 负责具体执行某类本地能力包

这会比“单 Agent 包打一切”更清晰。

5. 补齐运行时依赖

Skill_Agent 页面特别提示：Node.js 脚本类 Skill 需要在 Dify 容器内安装 Node.js runtime [1]。这类细节很工程化，也最容易在上线时踩坑。接入前建议形成依赖清单：

Python / Node.js / Shell 是否可用

所需系统包是否存在

文件系统挂载路径是否正确

容器权限是否允许执行脚本

Key Comparison Table

摘要：不同能力层并不是替代关系，而是面向不同工程问题的技术选择。

安全与治理：开源Skill不能只看能跑

摘要：Skill 一旦包含说明文件、脚本和可执行资产，就不再只是提示词问题，而是标准的软件供应链问题。

这是很多团队最容易忽视的部分。论文《Agent  Skills               in the Wild》指出，agent skills 往往是包含指令和可执行代码的模块化包，会带来供应链、代码执行和权限边界等风险 [10]。这与 Skill_Agent 的模型完全吻合，因为它本身就支持读取文件、必要时运行脚本 [1]。

因此，Dify 接入开源 Skill 时，至少要做下面几件事：

1. Skill 分级信任

不要把所有 Skill 一股脑挂到生产环境。建议按来源分级：

自研 Skill：高信任

团队内共享 Skill：中高信任

社区开源 Skill：中低信任

未审计 Skill：禁止执行脚本

2. 执行环境隔离

如果 Skill 涉及脚本执行，应尽量隔离运行时：

独立容器

只读挂载输入资源

限制网络访问

限制系统命令

限制文件写入目录

OpenAI 新 Agents SDK 文章也强调了安全沙箱执行的重要性 [5]，这说明行业方向是明确的：Agent 的代码能力必须和沙箱绑定。

3. 保留审计链路

建议记录以下信息：

哪个请求触发了哪个 Skill

读取了哪些文件

执行了什么脚本

输出了哪些文件

失败原因是什么

Dify 官方关于 MCP 的文档还建议记录应用依赖的 MCP servers [4]。同理，Skill 也应做依赖登记，否则后续升级和审计很难做。

4. 为 Skill 加测试说明

SkillFoundry 论文把“测试”视为 Skill 的组成部分之一 [7]。工程实践里可以简化为：

最少 1 个正例

最少 1 个反例

明确输入输出样式

明确环境前置条件

这样做能显著降低 Agent 误用 Skill 的概率。

实战代码示例

摘要：下面给出一个贴近 Dify 落地的目录组织示例，以及一个 Agent 提示配置示例，便于直接开始工程实现。

示例1：Skill 目录结构设计

# 目的：定义一个可被 Skill_Agent 使用的本地 skill 仓库结构 # 关键点：每个 skill 独立目录，manual 负责说明，scripts 负责执行资产 skills/ ├── sql_report/ │   ├── manual.md          # skill 说明：用途、输入、输出、执行限制 │   ├── templates/ │   │   └── report.sql.j2  # SQL 模板文件 │   ├── examples/ │   │   └── demo_input.json │   └── scripts/ │       └── run_report.py  # 生成报表的脚本 ├── doc_summarizer/ │   ├── manual.md │   ├── prompts/ │   │   └── summary.md │   └── scripts/ │       └── export_txt.js  # 注意：如为 Node.js，需容器中安装 runtime └── README.md              # 仓库级说明，便于维护和审计

建议 manual.md 至少写清这些字段：

适用任务

输入参数

输出格式

所需依赖

允许读取哪些文件

是否允许执行脚本

错误处理方式

示例2：Dify Agent 节点中的提示词模板

{# 目的：约束 Agent 正确调用 Skill_Agent，而不是盲目自由发挥 #} 你是企业内部任务执行 Agent，目标是根据用户请求选择是否调用 Skill。 【任务上下文】 用户请求：{{#sys.query#}} 上游分类结果：{{classification}} 标准化参数：{{normalized_args}} 【执行规则】 1. 优先判断是否存在匹配的 skill。 2. 如存在，先读取 skill manual，理解用途、输入输出和限制。 3. 只有在 manual 明确支持时，才进一步读取文件或执行脚本。 4. 若 skill 不匹配，则返回“无合适 skill”，不要编造执行结果。 5. 输出必须包含：   - 是否使用了 skill   - 使用了哪个 skill   - 最终结果摘要   - 是否生成文件 【安全要求】 - 不执行 manual 未说明的脚本 - 不访问与当前任务无关的文件 - 参数缺失时先指出缺失项，不要猜测

这个模板的核心不是“让模型更聪明”，而是把可执行边界写死。根据 Dify Agent 文档，工具描述与上下文会直接影响 Agent 决策 [6]，所以这里的约束信息是必须写进去的。

示例3：容器运行时检查脚本

# 目的：在 Dify 容器内检查 Skill 所需运行时 # 关键点：上线前先验环境，避免执行阶段才发现缺依赖 echo "[check] python version:" python3 --version || echo "python3 not found" echo "[check] node version:" node --version || echo "node not found" echo "[check] skill path:" ls -lah /app/skills || echo "/app/skills not mounted" echo "[check] test execute permission:" find /app/skills -type f \( -name "*.sh" -o -name "*.py" -o -name "*.js" \) -maxdepth 3

对于 Skill_Agent 来说，Node.js 运行时缺失是一个典型问题，Marketplace 页面已经明确提示这一点 [1]。所以在 CI/CD 或容器启动阶段做环境探测很有必要。

代码块注释规范

摘要：代码示例要服务于工程落地，注释重点应放在“目的、前提、关键步骤、风险点”。

我在写技术博客和内部文档时，通常要求代码块注释遵循以下规则：

开头先说明目的

用 1 行注释说明这段代码是做什么的。

例如：# 目的：检查 Dify 容器是否具备 Skill 运行时

关键步骤必须有简短注释

不是每行都注释，而是对“读者看不出意图”的地方标注。

特别是：路径约定、环境变量、权限限制、输入输出格式。

说明前置条件

比如“需要先挂载 /app/skills”“需要 Node.js runtime”。

这类信息经常比代码本身更重要。

标出风险或限制

如果代码涉及脚本执行、文件读写、外部调用，要写清边界。

例如：# 注意：仅在 manual 明确允许时执行脚本

注释要短，不要重复代码字面意思

注释不是翻译代码，而是解释为什么这么做。

比如不要写 ls -lah # 列出文件，应写 # 检查 skill 仓库是否已挂载

常见问题与排错

摘要：Skill 接入问题大多不是模型本身，而是目录、权限、运行时和工具描述不清。

1. Agent 不调用 Skill，只自己回答

先检查 Agent 提示词是否明确要求“优先读取 skill manual”。根据 Dify Agent 文档，工具描述会影响决策质量 [6]。

2. Skill 能识别，但脚本执行失败

优先检查运行时依赖。Skill_Agent 已明确提示 Node.js 脚本需要在 Dify 容器内安装 Node.js runtime [1]。

3. Workflow 中看不到 MCP 工具

检查 MCP server 是否已正确连接。Dify 文档说明连接后工具会出现在 Agent、Workflow、Agent Node 中 [2][4]。

4. Agent 频繁误用不相关 Skill

说明 skill manual 不够清晰，或 skill 的适用边界写得太宽。建议增加“适用/不适用场景”和反例。

5. 开源 Skill 引发安全担忧

默认先禁用脚本执行，仅允许读取 manual 和静态文件；完成审计后再开放执行能力。参考技能生态的安全研究结论 [10]。

6. 多个能力混在一起难维护

不要做“万能 Skill”。按任务域拆分，例如报表生成、文档摘要、代码修复分别独立目录和 manual。

结论

摘要：从工程视角看，Workflow、Agent、MCP、Skill 不是替代关系，而是一条逐级抽象、逐级增强的能力链。

如果用一句话总结本文：

Workflow 解决可控编排，Agent 解决动态决策，MCP 解决标准化工具接入，Skill 解决能力资产化与复用。

Dify 的价值就在于，这几层能力已经不是分散存在，而是在平台里逐渐打通了：

Agent 节点可以接工具 [6]

Workflow 中可使用 MCP 工具与 Agent [2][4]

Marketplace 已有 Skill_Agent 和 mcp_agent 这类开源插件 [1][3]

对于工程团队，我建议按下面顺序推进：

先用 Workflow 固定主链路

在复杂节点上引入 Agent

通过 MCP 统一外部工具接入

把高频任务沉淀为 Skill 仓库

为 Skill 补齐测试、审计、沙箱与分级治理

别急着一开始就搞“全自动智能体系统”。真正能跑稳的系统，往往是从明确边界、逐步放权开始的。

参考资料

Skill_Agent - Dify Marketplace
https://marketplace.dify.ai/plugin/lfenghx/skill_agent

集成 MCP 工具 - Dify Docs
https://docs.dify.ai/versions/3-3-x/zh/user-guide/tools/mcp

mcp_agent - Dify Marketplace
https://marketplace.dify.ai/plugin/ssf/mcp_agent

Using MCP Tools - Dify Docs
https://docs.dify.ai/en/learn-more/extended-reading/dify-docs-mcp

The next evolution of the Agents SDK
https://openai.com/index/the-next-evolution-of-the-agents-sdk/

Agent - Dify Docs
https://docs.dify.ai/en/use-dify/nodes/agent

SKILLFOUNDRY: Building Self-Evolving Agent Skill Libraries from Heterogeneous Scientific Resources
https://arxiv.org/abs/2604.03964

Towards a Declarative Agentic Layer for Intelligent Agents in MCP-Based Server Ecosystems
https://arxiv.org/abs/2601.17435

Plugin Trigger - Dify Docs
https://docs.dify.ai/en/guides/workflow/node/plugin-trigger

Agent Skills in the Wild: An Empirical Study of Security Vulnerabilities at Scale
https://arxiv.org/abs/2601.10338