Deep Researcher on Dify: a cascaded search and outline workflow you import as a DSL file
Deep Research workflow on Dify: cascaded multi-source search → outline → cited long-form report. Credited in Awesome-Dify-Workflow.
At a glance
- What is it?
- This repository is a Dify workflow definition, not a standalone application. It chains topic parsing, multi-source retrieval and paragraph generation into a cited long-form report, and its own README documents the two places where it breaks: LLM node timeouts and Google API rate limits.
- Who is it for?
- Adopt this if you already run Dify and want a working reference for multi-stage retrieval plus cited report generation that you can inspect node by node, rather than a hosted product. Do not adopt it if you need a supported library with a versioning policy, or if you cannot accept LGPL3.0 terms on a derived workflow.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 28 days ago.
- What is it written in?
- GitHub does not report a main language for this repository.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
A Dify workflow definition, not a research product
The repository is a DSL export. The README states the workflow was originally published in this repository on 2025-02-13 and was later included in Awesome-Dify-Workflow as the entry DSL/Deep Researcher On Dify .yml, with the upstream file described as byte-identical to this repository's version. That is the shape of the artefact: a YAML graph you import into a Dify instance, not a package you install with a package manager. The primary language and licence fields in the repository metadata are unset in the material provided, but the README carries its own Licences section naming LGPL3.0.
The problem it addresses is concrete. A single prompt against a single model produces an answer with no retrieval trail and no structure. This workflow instead forces the question through a sequence of stages so that retrieval happens before writing, and the writing stage receives an outline rather than a raw question. The audience is Dify users who want a worked example of that pattern, plus anyone evaluating whether Dify's node graph can express a research pipeline at all.
The graph: topic parsing, question generation, then cascaded retrieval
The README's mermaid diagram is the clearest statement of the data flow. A user question enters a topic parsing node. That node splits into two paths. One path generates questions, which are returned to the user for an answer, and that answer feeds into secondary topic extraction. The other path performs topic analysis, which also feeds secondary topic extraction. From there the flow enters what the README calls the hybrid iterative retrieval engine, then multi-model collaborative generation, then a structured report.
Two mechanisms are worth naming precisely. First, the retrieval stage is described as hybrid: a local knowledge base plus Wikipedia, Google and Bing APIs. That is a fan-out over sources, not a reranker, and the README does not describe how results from different sources are merged or scored. Second, the README describes a 2>1 model cascade, with conditional branches and conversation turn markers used to pace processing. The cascade claim is about model roles, a heavier model for one stage and a lighter one for another, and the pacing claim is about throttling the flow rather than about retrieval quality.
The topic parsing stage is attributed to Gemini 2.0 Flash, and the README says it supports analysis across four dimensions. Paragraph-level generation is attributed to models including deepseek-r1-distill, with Markdown as the output format. Treat the model names as defaults in the DSL, not as requirements: the README states the workflow in principle supports any model.
Importing the DSL and the settings that actually matter
The material does not include the import steps verbatim, so the exact menu path is not something I can quote. What the README does establish is the artefact and the configuration surface around it. The upstream copy lives at DSL/Deep Researcher On Dify .yml, and the README states that file is byte-identical to this repository's version, so either copy is the same graph.
Configuration happens after import, in the Dify editor. Three things need attention. The model bindings on the topic parsing and generation nodes, since the README names Gemini 2.0 Flash and deepseek-r1-distill as the defaults and says the underlying models are meant to be replaceable. The data source bindings, since the retrieval stage expects a local knowledge base plus the Wikipedia, Google and Bing channels. And the timeout setting, because the README's own troubleshooting note points at the Dify configuration file as the place to raise the timeout value when LLM nodes throw a timeout error.
If you are on Google's free API tier, the README suggests inserting a local model node to throttle requests per minute, noting Google's default limit of 15 RPM and that bursts produce errors. That is a workaround inside the graph, not a setting.
Two failure modes the README admits to
The notes section is unusually candid, and both items are operational rather than cosmetic. The first is the timeout error on LLM nodes. The README attributes it to request pressure when running local models, and offers two fixes: switch to an online API service, or raise the timeout in the Dify configuration file. The second is rate limiting. Google's free tier is described as 15 RPM by default, and the README warns that too many requests in a short window will error out, recommending a local model node as a throttle.
Read together, these two notes describe the same underlying tension, and the README's own To Do list names it: balancing RPM against processing time. A cascade with multiple retrieval channels and multiple generation calls per report multiplies the number of model invocations, which is exactly the workload shape that trips per-minute quotas. The workflow does not appear to ship with a built-in backoff or queue; the suggested mitigation is a node you add yourself.
The To Do list also flags a correctness bug rather than a performance one: occasional multiple subtitles appearing in the answer. That is a structural output defect, and it is listed as unfixed. A third item, adaptive questioning based on user question complexity, is described as requiring a large-scale refactor, which tells you the current question-generation stage does not branch on difficulty.
Where a plain retrieval chain is the better choice
The obvious alternative is a standard RAG chain: embed the query, retrieve top-k chunks from one index, pass them to one model, return the answer. That approach has one retrieval hop and one generation call. This workflow has a topic parsing stage, a question-generation stage that may round-trip to the user, a secondary topic extraction stage, a multi-channel retrieval stage and a multi-model generation stage.
The difference in approach is not quality per se, it is where the structure comes from. A RAG chain produces an answer whose shape is decided by the model at generation time. This workflow decides the shape first, via the outline implied by topic parsing and secondary topic extraction, and then fills it in paragraph by paragraph. That is why the README can claim a structured, cited, long-form report as the output. It is also why the invocation count is higher and the quota pressure is real.
If your question is a lookup, the RAG chain is cheaper and has fewer nodes to misconfigure. If your question requires assembling material from several sources into a document with sections, the outline-first structure is doing work that a single retrieval call cannot. The trade is latency and quota for structure.
Maintenance, licence and what the byte-identical claim buys you
The repository's last push is 2026-08-18 and the only release listed is an initial publish dated 2025-02-16. There is no versioning scheme in the material, no changelog, and no stated compatibility range for Dify versions. The README's To Do list is open work, including a large-scale refactor, which means the current graph is explicitly not the author's intended final form. Upgrading is therefore not a matter of bumping a dependency; it means re-importing a DSL and re-binding models and data sources, or diffing the graph yourself.
The licence question is the sharper one. The README's Licences section names LGPL3.0. LGPL is a copyleft licence written with libraries in mind, and a Dify workflow DSL is not a library in the usual sense: it is a graph definition that binds to models and external services at runtime. How LGPL3.0 applies to a modified DSL, or to a workflow you embed in a product, is not something the README addresses and not something I can resolve here. If you plan to redistribute a modified version, or to ship it inside a commercial offering, get your own reading of the licence rather than assuming the header settles it. The byte-identical relationship with the Awesome-Dify-Workflow copy is a provenance fact, not a licence grant.
Who should import this, and what to check first
Import it if you run Dify, you want a reference implementation of outline-first research rather than a black-box service, and you are comfortable editing node bindings. The value is in the graph being inspectable: you can see where retrieval fans out, where the user round-trip sits, and where the generation cascade begins. The README's own To Do list gives you a realistic view of maturity, and the two documented failure modes give you a realistic view of operations.
Do not import it if you need a supported component with a versioning policy, or if the LGPL3.0 question is unresolved for your distribution model, or if your search providers cannot sustain the request volume the cascade implies. The 15 RPM Google free-tier figure in the README is the number to check against your own quota before you wire anything to a live endpoint.
Before you rely on it, confirm the DSL imports on your Dify version without node errors, confirm each retrieval channel returns results from your network, and confirm how your deployment sets the LLM node timeout the README points at in the Dify configuration file. If the graph imports and the channels respond, the remaining work is the throttle node and the subtitles bug, both of which the author has already listed.
Editorial conclusion
Adopt this if you already run Dify and want a working reference for multi-stage retrieval plus cited report generation that you can inspect node by node, rather than a hosted product. Do not adopt it if you need a supported library with a versioning policy, or if you cannot accept LGPL3.0 terms on a derived workflow. Verify three things before committing: whether the DSL still imports cleanly on your Dify version, whether your search providers (Wikipedia, Google, Bing) are reachable and within quota, and how your deployment handles the LLM node timeout the README flags as a known failure mode.
Community notes