1. 先把 DeepResearch 工作流拆开看Dify 节点编排到底在做什么Dify 里的 DeepResearch 工作流本质上是一个“用 LLM 决定搜什么、用搜索工具拿资料、再让 LLM 汇总成报告”的循环结构。它不是什么黑魔法拆开之后你会发现核心就三件事控制迭代次数、动态生成搜索主题、把中间结果汇总成最终报告。适合谁适合想复刻深度研究流程、又不想从零写调度代码的开发者。你只要理解节点之间的数据流就能自己改出一个更符合业务场景的版本。我先把工作流从推荐页复制到自己的工作区然后导出 DSL。DSL 是一个 YAML 文件里面记录了所有节点、连线、变量和提示词。拿到 DSL 之后你可以直接读也可以丢给任意一个支持长文本的模型帮你梳理节点关系。我当时的提示词是“这是一个 Dify 工作流的配置文件请先详细描述各个节点然后描述整个流程最后用 mermaid 画出流程图。”注意这里只是让模型帮你理解不是让模型替你跑工作流。拆解下来节点大致分四层。第一层是输入与控制Start 节点接收用户输入Code 节点根据 depth 生成一个数组用来控制迭代次数。第二层是迭代主体Iteration 节点遍历数组里面包含 LLM 节点分析当前主题、Tavily Search 节点执行搜索、JSON Parse 节点提取 nextSearchTopic 和 shouldContinue、Assign Variables 节点更新搜索主题列表和控制变量、If-Else 节点判断是否继续。第三层是结果汇总Template Transform 节点格式化中间搜索结果Variable Aggregator 节点汇总所有中间结果。第四层是最终输出Final LLM 节点分析汇总结果生成报告Answer 节点输出。这里最关键的是 LLM 节点的提示词设计。system prompt 大意是你正在调查以下主题你发现了什么还有哪些问题未解决接下来需要调查哪些具体方面不要输出与已搜索主题完全相同的内容如果需要进一步搜索设置 nextSearchTopic如果信息足够把 shouldContinue 设为 false以 JSON 格式输出。user prompt 里注入 Topic、Findings、Searched Topics。这个设计决定了整个工作流是“动态搜索”而不是“固定轮次搜索”。如果你只是想把工作流跑起来需要准备两样东西一个 Tavily 的 key以及两个 LLM 节点的模型配置。Tavily 每月有免费搜索额度简单玩一下够用。模型配置这里就是后面要说的重点——两个 LLM 节点如果分别配不同厂商的 key管理起来很麻烦用统一 Key 会省事很多。还有一个容易漏掉的细节Intermediate Output Format 节点里要加一行检索结果输出类似{{ index 1 }}/{{ depth }}th search executed. {{ text }}否则中间结果的可读性会很差。做完这些再发布工作流预览时只需要填 depth 和研究题目就能启动 DeepResearch。实测下来这个内置工作流跑出来的结果只能算中规中矩。迭代节点可能只迭代 3 次就被 LLM 判停每次 Tavily 检索 5 篇文章3 次共 15 篇而且基本都是英文文章。最终报告的质量个人感觉并不比一些成熟的对话产品更好。原因也很直接这个工作流太简单了。LLM 主题分析和终止搜索节点的设置、信源组成、报告生成节点的提示词都还有大量优化空间。但它最大的价值是帮你揭开了 DeepResearch 的面纱——你可以在它基础上继续改而不是从零猜。2. TaoToken 统一 Key 前置为什么两个 LLM 节点要共用一个入口Dify 工作流里只要出现多个 LLM 节点就会遇到一个很现实的问题每个节点都要选模型供应商、填 API Key、填 Base URL。如果两个节点用不同厂商你就要维护两套 key如果同一个厂商但不同模型切换时又要改配置。更麻烦的是当你想对比不同模型对 DeepResearch 最终报告质量的影响时每换一次模型就要重新填一遍 key工作流日志里还容易看混。TaoToken 在这里的角色是提供一个统一的模型调用入口。你可以在 TaoToken 里拿到一个 API Key然后把 Dify 里所有 LLM 节点的模型供应商都指向同一个 Base URL用同一个 Key只改 Model ID 来切换模型。这样做的直接好处是工作流里两个 LLM 节点可以共用一套凭证验证多模型切换时只需要改模型名不用动 Key 和地址。具体来说TaoToken 的 API 地址是https://taotoken.net/api官网是https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content。你需要在 TaoToken 的控制台里创建一个 API Key然后回到 Dify 的模型供应商配置里选择 OpenAI-API-compatible 这类兼容入口把 Base URL 填成 TaoToken 的 API 地址把 Key 填进去再填你要用的 Model ID。这里要强调一点TaoToken 不是让你绕过什么限制它就是一个正常的模型调用聚合入口方便你在一个地方管理 Key 和切换模型。你完全可以在 Dify 里直接配各家官方 Key只是节点多了之后维护成本高。用统一 Key 的核心动机是“少改配置、方便对比”。如果你还没有 Key可以先去 TaoToken 控制台创建。创建之后建议先不要急着填进 Dify而是用一条 curl 命令验证 Key 是否可用。验证通过再进 Dify 配置能省掉很多“到底是 Key 错了还是 Dify 配错了”的排查时间。另外Dify 里配置模型供应商时Base URL 的写法要注意有些版本要求填到/v1有些版本只填到域名。TaoToken 的 API 地址是https://taotoken.net/api如果 Dify 提示 404可以尝试在末尾加上/v1也就是https://taotoken.net/api/v1。这个细节后面排错部分会再展开。对于长期做编码或 Agent 类工作流的开发者如果你不只是想跑 DeepResearch还想把同一套 Key 用在更多模型调用场景里可以了解一下 Coding Plan。它适合需要长期、稳定调用模型的场景入口在 TaoToken 的 coding-plan 页面。但就本篇的 DeepResearch 工作流而言你只需要一个普通 API Key 就够了。3. 可复制配置Dify 模型供应商 DSL 片段 环境变量这一节给你可以直接复制粘贴的配置。先说你需要在 Dify 里改什么再说 DSL 里哪些字段要跟着改。第一步在 Dify 的“设置 - 模型供应商”里添加一个 OpenAI-API-compatible 供应商。配置项如下{ provider: openai_api_compatible, base_url: https://taotoken.net/api/v1, api_key: sk-你的TaoTokenKey, model_id: 你的模型ID, model_type: llm }注意Dify 不同版本对 Base URL 的校验不一样。如果保存时提示连接失败先把https://taotoken.net/api/v1改成https://taotoken.net/api再试。两个都试一遍哪个能通过就用哪个。Key 填你在 TaoToken 控制台创建的那一串。第二步打开 DeepResearch 工作流的 DSL 文件找到两个 LLM 节点。DSL 里 LLM 节点的模型配置通常长这样model: provider: openai_api_compatible name: 你的模型ID mode: chat completion_params: temperature: 0.3你需要把provider改成你刚添加的兼容供应商名称把name改成你要用的 Model ID。两个 LLM 节点可以填同一个模型也可以填不同模型——这正是后面做多模型对比的关键。如果你想让“主题分析节点”用推理型模型、“最终报告节点”用长文本型模型就在这里分别改name。第三步如果你是用 Docker 部署 Dify建议把 Key 放到环境变量里而不是硬编码在 DSL 中。在docker/.env里加一行TAOTOKEN_API_KEYsk-你的TaoTokenKey然后在docker-compose.yaml里给 api 和 worker 服务加上环境变量引用services: api: environment: - TAOTOKEN_API_KEY${TAOTOKEN_API_KEY} worker: environment: - TAOTOKEN_API_KEY${TAOTOKEN_API_KEY}改完之后执行cd docker docker compose down docker compose up -d这样做的目的是DSL 可以分享给别人Key 不会跟着泄露。如果你只是本地测试直接填在 Dify 界面里也可以但正式用建议走环境变量。第四步检查 Intermediate Output Format 节点。这个节点负责把每次检索结果格式化方便后面汇总。内容参考{{ index 1 }}/{{ depth }}th search executed. {{ text }}如果你想让报告里保留来源链接可以改成[{{ index 1 }}] {{ text }}第五步确认 Iteration 节点的输入数组来自 Code 节点。Code 节点的逻辑是根据 depth 生成一个长度为 depth 的数组。如果你把 depth 设成 5迭代最多跑 5 次但 LLM 可能提前把 shouldContinue 设为 false实际迭代次数会少于 5。这个设计是合理的避免无意义搜索。配置完成后先不要急着发布。点预览填一个 depth 比如 3再填一个研究题目比如“2025 年边缘计算在工业质检中的落地案例”看工作流能不能跑通。跑通之后再发布到探索页。4. 验证请求与成功结果从 curl 到工作流日志在把 Key 填进 Dify 之前先用 curl 验证一次能排除掉大部分低级错误。命令如下curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的TaoTokenKey \ -H Content-Type: application/json \ -d { model: 你的模型ID, messages: [ {role: user, content: 用一句话说明什么是深度研究工作流} ], temperature: 0.3 }如果返回里能看到choices字段和正常内容说明 Key、Base URL、Model ID 三者至少是通的。如果返回 401说明 Key 有问题如果返回 404说明 Base URL 路径不对如果返回 model not found说明 Model ID 写错了。这三种错误后面排错部分会细说。curl 通过之后回到 Dify 工作流预览。填 depth3研究题目填一个你熟悉的话题启动。然后打开工作流日志逐个节点看执行情况。重点看三个地方Iteration 节点实际迭代了几次、Tavily Search 每次返回了几篇文章、Final LLM 节点的输入 token 数是多少。一个正常的成功结果应该长这样Iteration 节点显示迭代 3 次每次 Tavily 返回 5 条结果中间结果被 Template Transform 格式化后进入 Variable AggregatorFinal LLM 拿到汇总后的 findings输出一份带小标题的报告。报告里应该能看到对多个来源的引用而不是只有一段泛泛而谈。如果你在日志里看到 Iteration 只跑了 1 次就停了不要慌这通常是 LLM 在第一次迭代后就把 shouldContinue 设成了 false。你可以检查 LLM 节点的提示词看是不是“信息足够”的判断过于宽松。可以把 system prompt 里的终止条件写得更严格一点比如要求至少覆盖三个不同子问题才允许停止。验证多模型切换时你只需要改 LLM 节点的 Model ID然后重新跑同一个研究题目。对比两次报告的结构、引用数量和结论深度。这一步用统一 Key 的优势就体现出来了你不用改 Base URL也不用换 Key只改一个模型名就能在同一工作流里做 A/B 对比。如果你验证模型时想更直观地对比输出可以打开 TaoToken 的模型对话页面把同一段提示词分别发给不同模型看原始输出差异。模型对话入口在 TaoToken 的模型对话页面。但注意工作流里的表现和单轮对话不完全一样最终还是要以工作流日志为准。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth这一节按真实报错来。你在 Dify 里接 TaoToken 统一 Key最可能遇到下面几类错误。第一类401 Unauthorized。报错原文通常是{error:{message:Invalid API key,type:invalid_request_error}}。原因一般是 Key 复制时带了空格或者 Key 已经被删除。解决方法是重新在 TaoToken 控制台创建一个 Key复制时注意不要带首尾空格。如果你把 Key 放在.env里检查有没有引号包裹导致 Key 被当成字符串带上了引号。第二类local proxy failed。这个报错在 Dify 的模型供应商测试连接时比较常见原文类似local proxy failed: connection refused。原因通常是 Dify 容器访问不到你填的 Base URL或者 Base URL 路径写错。先确认https://taotoken.net/api/v1和https://taotoken.net/api哪个能通。如果你是在 Docker 里跑 Dify还要确认容器有外网访问能力。这个报错和“代理”无关就是网络连通性和路径问题。第三类reading choices 相关报错。原文可能是error reading choices: unexpected end of JSON input或者cannot read property choices of undefined。这通常说明返回体不是标准 OpenAI 格式或者返回了空内容。先检查 Model ID 是否写对再检查请求参数里有没有 Dify 自动加上的、TaoToken 不支持的字段。可以先用第 4 节的 curl 命令确认接口本身返回正常再回 Dify 看请求体差异。第四类OAuth 相关报错。如果你在 Dify 里选错了供应商类型比如选成了需要 OAuth 授权的官方供应商而不是 OpenAI-API-compatible就会看到 OAuth 授权失败或回调地址错误的提示。解决方法是删掉错误的供应商配置重新添加 OpenAI-API-compatible 类型只填 Base URL、Key、Model ID 三件套。这里把三件套再强调一次Base URL 填https://taotoken.net/api/v1或/apiKey 填 TaoToken 控制台创建的 KeyModel ID 填你要用的模型名。这三个任何一个错都会导致上面的报错。如果你用的是 CC Switch、Cline MCP 或 Codex 的 auth.json配置逻辑是一样的Base URL、Key、Model ID 三件套必须完整且一致。比如 Codex 的auth.json里base_url和api_key要对应同一个入口Model ID 单独在配置里指定。还有一个容易忽略的错工作流日志里 Final LLM 节点报context length exceeded。这是因为 Variable Aggregator 汇总了太多中间结果超出了模型上下文。解决办法是减小 depth或者在 Template Transform 节点里对每条结果做截断比如只保留前 500 字。6. 从 Agent 节点到 ManusDify 工作流还能怎么升级Dify 在 v1.0.0 之后新增了 Agent 节点这个节点的执行流程分三个阶段初始化、迭代循环、回答。初始化阶段设置参数、工具和上下文迭代循环阶段准备包含当前上下文的提示调用 LLM解析响应决定是调用工具还是得到最终答案如果需要调用工具就执行工具并用输出更新上下文循环直到任务完成或达到最大迭代次数最后返回最终答案。这个流程和 OpenManus 这类多智能体框架的“规划—执行—反馈”结构非常像。但要说最新版 Dify 能不能直接搭出一个完整的 Manus我的判断是暂时还不能。缺的不是 Agent 节点而是记忆模块、browser-use 这类辅助模块以及更细粒度的任务调度。不过核心的 Agent 节点已经出来了你完全可以照着 OpenManus 的流程图用工作流拼出一个简易版一个 Agent 节点负责理解需求一个 Agent 节点负责调用搜索工具一个 Agent 节点负责汇总中间用 If-Else 和 Variable Aggregator 做反馈控制。如果你想继续完善内置 DeepResearch 工作流可以从三个方向入手。第一扩充信源把 Tavily 换成或加上 Firecrawl、本地文献库、其他搜索接口让检索结果更多样。第二优化提示词主题分析节点要求 LLM 输出更具体的子问题终止条件要求覆盖至少 N 个不同角度。第三报告生成节点单独配一个长文本模型和主题分析节点用的模型分开通过 TaoToken 统一 Key 切换 Model ID 即可。对于想长期做 Agent 类工作流的开发者统一 Key 的价值会随着节点数量增加而放大。你不需要在每个节点里重复填 Key只需要在供应商配置里维护一份。如果你后续要接入更多模型调用场景可以看看 TaoToken 的 Coding Plan它适合需要长期稳定调用模型的编码和 Agent 场景。而如果你只是想先验证模型输出模型对话页面更轻量。接入文档在 TaoToken 的 doc 页面API Key 管理在 console 的 api-keys 页面。最后给一个实用建议每次改完 DSL先导出备份再发布。Dify 的工作流版本管理不算强改坏了回滚比较麻烦。你可以用cp命令给 DSL 文件加时间戳备份和升级 Dify 时备份 docker-compose 是同一个习惯。这样你就能放心大胆地试各种 Agent 化改造而不怕把能跑的工作流改崩。