做AI应用的朋友应该都有同感单聊机器人谁都会搭但要让一个智能体真正承担“研究”这种活难度完全不在一个量级。研究意味着它要自己找线索、筛信息、抓原文、读内容、再组织成结论链条长且每一步都容易断。我最近基于 Dify 把 FireCrawl 和百度搜索整合进了一个工作流算是把这条链完整跑通了做出来的东西可以当“全能研究助手”用。这篇就把整套思路、配置细节、踩坑记录都摊开来讲适合正在折腾 Dify 工作流、想给智能体加“联网研究”能力的朋友参考。1. 从需求到方案为什么这三样东西要搭在一起1.1 研究助手到底缺什么先想清楚一个问题普通聊天机器人缺的是什么缺的是“新鲜信息”和“可验证的出处”。大模型的知识截止日期是训练时决定的你问它“那款开源模型这周发布了什么新版本”它大概率只会编一个不存在的答案。所以要让智能体具备研究能力第一件事就是给它接上搜索。但只接搜索还不够。搜索结果页给的是链接和摘要摘要那几十个字根本带不动深度问题的回答。你真正需要的是点进链接、把正文抓出来、喂给模型读。这一步在技术圈叫“网页抓取与内容提取”听着简单实际坑很多有的页面是动态渲染的普通请求拿不到正文有的页面反爬严重有的页面内容混着导航、广告、弹窗抓回来一堆垃圾。所以研究助手的完整链路应该是这样四段搜索发现线索、筛选有效链接、抓取页面正文、归纳组织输出。缺任何一环这个助手都会变成“一本正经地胡说八道”。1.2 三个工具的分工逻辑这套方案里三个工具各管一段链路。Dify 是编排中枢。它在整个流程里扮演“厨房”的角色搜索、抓取、分析都是食材和工序Dify 负责把流程串成一条可复用的自动化流水线同时提供可视化调试界面让我能看每一步的输入输出。百度搜索解决的是“去哪里找”的问题。虽然 Dify 官方工具里已经带了 Bing、DuckDuckGo 这类搜索能力但做中文场景的研究百度的覆盖度和时效性更适合国内用户习惯。我不需要跟 LLM 说“帮我搜英文资料”直接中文一问搜索结果就是中文世界最相关的那些页面。FireCrawl 解决的是“拿到链接之后怎么读”的问题。它是一个专门做网页抓取的服务能把任意 URL 转成干净的 Markdown支持动态渲染页面还能整站爬取。相比自写 requests 加 BeautifulSoup 的方案FireCrawl 免去了处理验证码、渲染引擎、页面解析这套脏活累活在我这个工作流里是最省心的一环。1.3 为什么不推荐其他方案可能会有人问直接用 Dify 自带的工具不就行了我用下来感觉有几个具体短板一是 Dify 内置搜索工具基本是国外搜索引擎或 SerpAPI 这类聚合服务中文搜索结果质量和国内访问稳定性都一般二是内置工具返回的结果数据没经过定制化清洗链路里少了“提炼有效链接”这一步后面的抓取质量就全靠运气。也有人会提议自己写 Scrapy 爬虫做抓取服务然后接进 Dify 的 API 工具。这条路不是不行但维护成本高对方网站一改结构就要跟着改代码动态页面还得维护无头浏览器环境。FireCrawl 直接把这件事封装成了“传一个 URL返回干净 Markdown”省掉的运维时间足够把精力放在更核心的提示词和流程设计上。2. 动手前的准备工作环境、密钥和前置配置2.1 Dify 环境与版本说明这套工作流我是在最近升级过的 Dify 社区版上跑的。社区版迭代速度相当快新版本对工作流可视化、知识点管理体验优化了不少。如果你还没有环境官方推荐的做法是用 Docker 部署一条 docker compose 命令就能起服务。国内拉镜像偶尔会失败解决方案很朴素给 Docker 配置镜像加速器然后重新拉取。启动完记得先去“系统设置”里配置模型供应商。这个很关键工作流里所有 LLM 节点都要依赖模型服务。我的选择是配了一个支持函数调用的模型作为“主模型”因为后面要干搜索词生成、内容提取、总结归纳这些不同类型的任务一个稳定的主模型能减少很多切换成本。模型配好后可以顺手建一个测试应用随便跑个对话确认链路通畅了再往下搭。要提一嘴多租户Dify 社区版现在支持创建多个工作空间了。我帮团队搭这套工作流的时候给每个成员分配了独立空间权限隔离很干净数据也不会互相串。如果你是个人玩单空间完全够用但团队协作场景强烈建议用多租户能力方便后期管理和审计。2.2 FireCrawl 的两种接入方式FireCrawl 想用好第一步是拿到 API Key。你去官网注册后后台会给你一个密钥同时送一些免费额度。免费额度拿来做测试、搭 prototype 足够了真跑大量抓取任务再考虑付费套餐。接入 Dify 有两条路。第一条是用 Dify 的“自定义工具”功能把 FireCrawl 的 OpenAPI schema 填进去。Dify 会自动解析接口定义生成一个可视化工具节点这样在 workflow 里就可以像拖拽官方工具一样拖一个“抓取”节点出来。这是我最推荐的方式配置一次全局复用。第二条路是直接用“HTTP 请求”节点手动调 FireCrawl 的 API。好处是灵活坏处是每次都要写 URL、Header、Body工作流里多条分支时会显得很啰嗦。我的建议是两条路搭配着用搜索抓取这种高频操作用自定义工具节点偶尔调试的时候用 HTTP 请求节点直接看原始返回排查问题更快。2.3 百度搜索的接入思路Dify 没有现成的“百度搜索”工具所以这里得动点脑筋。我的方案是让 FireCrawl 去抓百度搜索结果页再把抓回来的页面内容交给 LLM 提取出真实的文章链接。也就是说FireCrawl 在流程里承担了双重职责既是搜索结果页抓取器也是具体文章页抓取器。百度搜索结果页的 URL 格式很简单https://www.baidu.com/s?wd搜索词。加密参数wd后面接 query再补一个rn20就能一页拿 20 条结果。FireCrawl 抓这个页面不需要额外处理它交付的 Markdown 里通常包含了每条结果的标题、摘要和链接后续让 LLM 按规则解析就行。这里有个魔鬼细节百度结果里的跳转链接往往是加密重定向 URL直接抓那个链接大概率拿到一堆 JS 脚本而不是原文。所以我在 LLM 解析节点里专门加了一条指令——提取结果时跳过所有以/link?开头的重定向链接尽量保留真实站点的 URL。如果不加这条到了 FireCrawl 抓取正文那一步错误率会非常高。2.4 知识库要不要一起接进来如果你做的研究助手需要结合自己团队的资料库我建议在搭好搜索流程之后把 Dify 知识库也融进来。我个人的习惯是把经常用的内部文档、此前抓取过的优质文章全部灌进知识库然后让工作流判定一个问题“是搜新东西”还是“应该先翻资料库”。这个判定逻辑放在意图解析节点里一句话提示词就能搞定。知识库有一个必须注意的坑检索效果差往往不是 Embedding 模型的问题而是分段策略和召回参数没调好。我遇到过明明文档里有的内容检索就是召回不出来的情况最后发现是 TopK 设置太小、段落切得太碎。工作流里接知识库的时候记得先做几个测试 query确认召回命中率再往生产上推。3. 核心工作流实现从搜索词到研究报告3.1 整体流程拆解这个工作流我用的是 Dify 的聊天流模式因为研究问题通常需要多轮追问聊天流能保留上下文。完整链路如下开始节点接收用户输入意图解析节点判断这个问题走“本地知识库”还是“联网检索”搜索词生成节点把口语化问题改写成适合百度的搜索词代码节点对搜索词做 URL 编码拼出百度搜索结果页地址HTTP 请求节点或 FireCrawl 工具抓取搜索结果页LLM 解析节点从搜索结果中提取候选链接清单和摘要链接筛选节点按相关性排序选择最优的 2 到 3 个链接FireCrawl 工具节点依次抓取这些文章的正文LLM 综合分析节点结合所有正文内容和原始问题生成研究报告结构化输出节点以 Markdown 格式返回最终答案这条链路每一步的输入输出都环环相扣Dify 可视化面板里可以清楚看到每个节点的数据流转调试时非常直观。3.2 关键节点配置实录先看意图解析节点。我只用了模型节点没有用分类器因为简单场景下提示词就够。提示词大概是这样的判断用户问题是否需要最新信息、外部数据或特定事实若是则调用联网检索否则使用本地知识库。然后是搜索词生成节点。默认用户输入的问题是口语化的“帮我查一下最近国产大模型 API 哪家便宜”这个不能直接当搜索词用搜索词应该是“国产大模型 API 价格对比”。所以我在模型节点里给它一个模板从问题中提取核心名词和限定词压缩成 2 到 5 个关键词组合不要加修饰语。真正有意思的是代码节点。Dify 的代码节点支持 Python我用它来做 URL 编码省得每次都让 LLM 去编码容易出错。代码很简单import urllib.parse def main(keyword: str) - dict: encoded_keyword urllib.parse.quote(keyword) url fhttps://www.baidu.com/s?wd{encoded_keyword}rn20 return {url: url, keyword: keyword}这里编码一定要在代码节点里做。如果直接拼 URL中文搜索词不会被浏览器或 HTTP 客户端自动编码FireCrawl 拿到的 URL 是非法请求根本抓不到结果。这个小点是我调试时踩过最笨的坑写出来提醒大家。搜索结果抓取我用的是 HTTP 请求节点直接 GET 上面拼好的 URL不需要额外 Header。返回的内容如果是 JSON 格式里面会有 markdown 字段后续解析节点就从这里取数据。接下来是链接解析节点。这里我让 LLM 从抓回来的 Markdown 中按规则提取真实站点链接。提示词里给了非常明确的格式要求[ { title: 文章标题, url: 文章真实URL, summary: 摘要内容, source: 站点名称 } ]同时告诉它要去掉百度自己的产品入口和广告区只保留自然搜索结果。这一步做出来的候选清单质量直接决定了后面抓正文的效果。最后是 FireCrawl 抓取正文节点。我配置了onlyMainContent这个参数很关键——它告诉 FireCrawl 只返回页面主体内容把导航、页脚、弹窗这些无关信息全扔掉。实测下来打开的页面哪怕挂了一堆推荐位广告返回的 Markdown 依然很干净LLM 读起来舒服多了。3.3 提示词研究助手的灵魂这套工作流里提示词占的比重比想象中大。我写了几个版本才调到满意的状态核心感受是“每个节点只让 LLM 干一件事”。意图解析节点不要让它输出长篇大论只输出一个字段。搜索词生成节点输出纯字符串不给解释。链接筛选节点输出 JSON 数组且要求必须给每个链接打相关性分数。综合分析节点输出一份结构化报告。这样设计的理由是模型在单一、明确的任务上更稳定输出格式越简单越不容易发生解析错误。综合分析节点是整个工作流的收口我给它设计的输出模板是这样的研究结论用 200 字以内概括核心结论关键发现列出 3 到 5 个对结论有直接支撑的事实点每个要点后标注来源争议与差异如果来源之间观点不一致明确指出来补充信息基于搜索内容列出值得进一步阅读的扩展方向参考资料以带链接列表的形式附上引用来源这个输出结构是我反复试用后确定的。研究助手最怕的就是只给一个干瘪结论没有出处、没有前因后果。上面这套结构基本能让用户拿着答案去回溯原文判断信息的可信度。3.4 参数调优一次完整的实测记录参数方面我把 Search 节点的抓取深度设成只抓第一页也就是 20 条搜索结果。因为经过验证第一页已经能覆盖大多数研究问题的有效线索抓更多页反而引入更多噪音也消耗更多 FireCrawl 额度。FireCrawl 抓正文时设置只返回 Markdown 文本不要截图不要 PDF 转换速度会快非常多。LLM 节点的温度参数我也做了区分搜索词生成用低温度确保关键词稳定性内容提取用更低温度防止模型在抽取链接时“创造性发挥”综合分析用中等温度让文章有一定归纳自由度。具体值是 0.3、0.1、0.5大家可以根据自己用的模型微调。实测案例我把问题定为“帮我调研一下最近国内开源大模型的许可证变化”整个工作流跑下来耗时二十几秒抓取了 3 篇相关文章正文最终报告里正确列出了许可证类型差异、社区争议点、以及各家的官方公告出处。相比我之前用“让 LLM 直接凭记忆回答”这份报告的可信度高了一个层次。4. 常见问题与排查技巧实录4.1 高频报错与解决办法搭建过程中我整理了一张问题表基本把能踩的坑都踩了一遍现象可能原因解决办法百度搜索结果为空搜索词未 URL 编码加代码节点转码FireCrawl 抓取超时目标站点响应慢调大 timeout 参数减少并发返回内容全是导航和广告没开 onlyMainContent请求参数加上 onlyMainContenttrueLLM 提取链接出现截断返回内容超过上下文先截断前 5000 字符再送 LLM知识库检索不召回分段策略/TopK 设置不合理调 TopK检查分段重叠抓取正文包含大量无用 JS 片段目标页面是动态渲染检查 FireCrawl 返回格式必要时启用 wait_for多租户空间看不到自定义工具工具没有跨空间共享在工具管理里设为公开或复制到目标空间前三个问题出现频率最高基本占了调试时间的七成。特别是超时问题有些站点本身响应就慢FireCrawl 默认超时时间不能满足业务场景我统一在配置里加到了 60 秒抓取成功率明显提升。4.2 从“能跑”到“好用”几个细节打磨链路跑通之后我花了整整一个下午做细节打磨。第一个细节是链接去重。百度搜索结果里经常会出现同一个站的多个页面或者转载内容高度相似的情况。我在筛选节点里让 LLM 对比标题和摘要把相似度高的结果合并只保留最完整的那个避免重复内容反复抓取浪费额度。第二个细节是来源可信度标注。我把source字段的赋值做了约束让 LLM 尽量识别出站点类型官方站点、新闻媒体、个人博客、论坛问答然后在综合分析节点里按可信度给来源排序。官方公告排第一个人博客和论坛内容只能作为补充参考不会喧宾夺主。第三个细节和安全相关脚本类内容、验证码页面、非法内容站点在 FireCrawl 抓取之前就该被拦掉。我在链接筛选节点里加了一条过滤规则指定站点类型直接剔除既能节约额度也避免模型读入垃圾信息影响判断。4.3 多轮对话场景的特别处理聊天流的好处是能多轮追问但这也带来了新问题第二轮提问时上一轮的搜索结果会留在上下文里容易造成混乱。我做了个比较笨但有效的处理每个新问题进来时都让意图解析节点先修正上下文把“上一轮已经回答过”的信息压缩成一句话埋进新提示词而不是让模型读完整历史。实测下来效果不错连续问三个相关问题时模型能区分哪些信息是新搜索来的哪些是之前已经确认过的不会答非所问。Dify 的对话历史变量在这里起了很大作用建议认真研究一下它的作用域和生命周期。5. 这套工作流还能怎么玩扩展与进阶5.1 定时监控与自动入库研究助手模式搭好之后最自然的扩展是“定时监控”。Dify 的定时触发能力可以实现这种场景每天早上自动搜一遍你关注的竞品动态或行业关键词抓取文章汇总出一份简报推送给你。配合知识库流水线还可以把每天抓取的优质内容自动写入知识库形成个人专属资料池越用越聪明。我已经开始这样玩了本质上就是把一次性的“研究”变成习惯性的“监视”。时间久了积累下来的知识库再配合问答系统就是一套私有版的行业情报中心。5.2 与其他工具的联动Dify 的开放接口让这套工作流能很方便地嵌进其他系统。比如把工作流发布为 API 后接到企业微信机器人里同事在工作群里直接 机器人发问题就能收到研究报告。群机器人的问题往往五花八门正好是这套链路最擅长的场景。搜索范围也不局限于百度。FireCrawl 本身支持抓任意网页和搜索源你可以并行加一个技术社区搜索、博客搜索多个源的结果在综合分析节点里做交叉验证结论会更扎实。注意控制并发数量别让 FireCrawl 同时请求太多页面容易被限流。5.3 关于版本更新的提示Dify 更新频率快如果你用的是旧版本建议升级后先跑一遍现有工作流确认节点行为没有变化再继续生产使用。我遇到过升级后自定义工具的鉴权 Header 格式变了导致 HTTP 请求 401排查了半小时才发现是版本兼容问题。多看更新日志升级前先备份数据库和 docker-compose 配置稳字当头。最后分享一点个人心得这套工作流跑通之后我最大的体会是研究助手真正难的不是模型能力而是流程设计。模型再聪明上游搜索乱七八糟、抓取断断续续输出一样一塌糊涂。Dify 的价值就在于把流程可视化让每一步都能人工干预和调试。我建议刚上手的朋友别急着追新功能先把自己最常用的一个研究场景完整跑通哪怕一开始丑一点、慢一点等链路通了再逐步优化也不迟。搜索引擎和抓取服务还会有更多新选择但只要流程骨架搭对了后面换工具、加来源都是顺手的事。 基于Dify+FireCrawl+百度搜索搭建全能研究助手工作流
做AI应用的朋友应该都有同感单聊机器人谁都会搭但要让一个智能体真正承担“研究”这种活难度完全不在一个量级。研究意味着它要自己找线索、筛信息、抓原文、读内容、再组织成结论链条长且每一步都容易断。我最近基于 Dify 把 FireCrawl 和百度搜索整合进了一个工作流算是把这条链完整跑通了做出来的东西可以当“全能研究助手”用。这篇就把整套思路、配置细节、踩坑记录都摊开来讲适合正在折腾 Dify 工作流、想给智能体加“联网研究”能力的朋友参考。1. 从需求到方案为什么这三样东西要搭在一起1.1 研究助手到底缺什么先想清楚一个问题普通聊天机器人缺的是什么缺的是“新鲜信息”和“可验证的出处”。大模型的知识截止日期是训练时决定的你问它“那款开源模型这周发布了什么新版本”它大概率只会编一个不存在的答案。所以要让智能体具备研究能力第一件事就是给它接上搜索。但只接搜索还不够。搜索结果页给的是链接和摘要摘要那几十个字根本带不动深度问题的回答。你真正需要的是点进链接、把正文抓出来、喂给模型读。这一步在技术圈叫“网页抓取与内容提取”听着简单实际坑很多有的页面是动态渲染的普通请求拿不到正文有的页面反爬严重有的页面内容混着导航、广告、弹窗抓回来一堆垃圾。所以研究助手的完整链路应该是这样四段搜索发现线索、筛选有效链接、抓取页面正文、归纳组织输出。缺任何一环这个助手都会变成“一本正经地胡说八道”。1.2 三个工具的分工逻辑这套方案里三个工具各管一段链路。Dify 是编排中枢。它在整个流程里扮演“厨房”的角色搜索、抓取、分析都是食材和工序Dify 负责把流程串成一条可复用的自动化流水线同时提供可视化调试界面让我能看每一步的输入输出。百度搜索解决的是“去哪里找”的问题。虽然 Dify 官方工具里已经带了 Bing、DuckDuckGo 这类搜索能力但做中文场景的研究百度的覆盖度和时效性更适合国内用户习惯。我不需要跟 LLM 说“帮我搜英文资料”直接中文一问搜索结果就是中文世界最相关的那些页面。FireCrawl 解决的是“拿到链接之后怎么读”的问题。它是一个专门做网页抓取的服务能把任意 URL 转成干净的 Markdown支持动态渲染页面还能整站爬取。相比自写 requests 加 BeautifulSoup 的方案FireCrawl 免去了处理验证码、渲染引擎、页面解析这套脏活累活在我这个工作流里是最省心的一环。1.3 为什么不推荐其他方案可能会有人问直接用 Dify 自带的工具不就行了我用下来感觉有几个具体短板一是 Dify 内置搜索工具基本是国外搜索引擎或 SerpAPI 这类聚合服务中文搜索结果质量和国内访问稳定性都一般二是内置工具返回的结果数据没经过定制化清洗链路里少了“提炼有效链接”这一步后面的抓取质量就全靠运气。也有人会提议自己写 Scrapy 爬虫做抓取服务然后接进 Dify 的 API 工具。这条路不是不行但维护成本高对方网站一改结构就要跟着改代码动态页面还得维护无头浏览器环境。FireCrawl 直接把这件事封装成了“传一个 URL返回干净 Markdown”省掉的运维时间足够把精力放在更核心的提示词和流程设计上。2. 动手前的准备工作环境、密钥和前置配置2.1 Dify 环境与版本说明这套工作流我是在最近升级过的 Dify 社区版上跑的。社区版迭代速度相当快新版本对工作流可视化、知识点管理体验优化了不少。如果你还没有环境官方推荐的做法是用 Docker 部署一条 docker compose 命令就能起服务。国内拉镜像偶尔会失败解决方案很朴素给 Docker 配置镜像加速器然后重新拉取。启动完记得先去“系统设置”里配置模型供应商。这个很关键工作流里所有 LLM 节点都要依赖模型服务。我的选择是配了一个支持函数调用的模型作为“主模型”因为后面要干搜索词生成、内容提取、总结归纳这些不同类型的任务一个稳定的主模型能减少很多切换成本。模型配好后可以顺手建一个测试应用随便跑个对话确认链路通畅了再往下搭。要提一嘴多租户Dify 社区版现在支持创建多个工作空间了。我帮团队搭这套工作流的时候给每个成员分配了独立空间权限隔离很干净数据也不会互相串。如果你是个人玩单空间完全够用但团队协作场景强烈建议用多租户能力方便后期管理和审计。2.2 FireCrawl 的两种接入方式FireCrawl 想用好第一步是拿到 API Key。你去官网注册后后台会给你一个密钥同时送一些免费额度。免费额度拿来做测试、搭 prototype 足够了真跑大量抓取任务再考虑付费套餐。接入 Dify 有两条路。第一条是用 Dify 的“自定义工具”功能把 FireCrawl 的 OpenAPI schema 填进去。Dify 会自动解析接口定义生成一个可视化工具节点这样在 workflow 里就可以像拖拽官方工具一样拖一个“抓取”节点出来。这是我最推荐的方式配置一次全局复用。第二条路是直接用“HTTP 请求”节点手动调 FireCrawl 的 API。好处是灵活坏处是每次都要写 URL、Header、Body工作流里多条分支时会显得很啰嗦。我的建议是两条路搭配着用搜索抓取这种高频操作用自定义工具节点偶尔调试的时候用 HTTP 请求节点直接看原始返回排查问题更快。2.3 百度搜索的接入思路Dify 没有现成的“百度搜索”工具所以这里得动点脑筋。我的方案是让 FireCrawl 去抓百度搜索结果页再把抓回来的页面内容交给 LLM 提取出真实的文章链接。也就是说FireCrawl 在流程里承担了双重职责既是搜索结果页抓取器也是具体文章页抓取器。百度搜索结果页的 URL 格式很简单https://www.baidu.com/s?wd搜索词。加密参数wd后面接 query再补一个rn20就能一页拿 20 条结果。FireCrawl 抓这个页面不需要额外处理它交付的 Markdown 里通常包含了每条结果的标题、摘要和链接后续让 LLM 按规则解析就行。这里有个魔鬼细节百度结果里的跳转链接往往是加密重定向 URL直接抓那个链接大概率拿到一堆 JS 脚本而不是原文。所以我在 LLM 解析节点里专门加了一条指令——提取结果时跳过所有以/link?开头的重定向链接尽量保留真实站点的 URL。如果不加这条到了 FireCrawl 抓取正文那一步错误率会非常高。2.4 知识库要不要一起接进来如果你做的研究助手需要结合自己团队的资料库我建议在搭好搜索流程之后把 Dify 知识库也融进来。我个人的习惯是把经常用的内部文档、此前抓取过的优质文章全部灌进知识库然后让工作流判定一个问题“是搜新东西”还是“应该先翻资料库”。这个判定逻辑放在意图解析节点里一句话提示词就能搞定。知识库有一个必须注意的坑检索效果差往往不是 Embedding 模型的问题而是分段策略和召回参数没调好。我遇到过明明文档里有的内容检索就是召回不出来的情况最后发现是 TopK 设置太小、段落切得太碎。工作流里接知识库的时候记得先做几个测试 query确认召回命中率再往生产上推。3. 核心工作流实现从搜索词到研究报告3.1 整体流程拆解这个工作流我用的是 Dify 的聊天流模式因为研究问题通常需要多轮追问聊天流能保留上下文。完整链路如下开始节点接收用户输入意图解析节点判断这个问题走“本地知识库”还是“联网检索”搜索词生成节点把口语化问题改写成适合百度的搜索词代码节点对搜索词做 URL 编码拼出百度搜索结果页地址HTTP 请求节点或 FireCrawl 工具抓取搜索结果页LLM 解析节点从搜索结果中提取候选链接清单和摘要链接筛选节点按相关性排序选择最优的 2 到 3 个链接FireCrawl 工具节点依次抓取这些文章的正文LLM 综合分析节点结合所有正文内容和原始问题生成研究报告结构化输出节点以 Markdown 格式返回最终答案这条链路每一步的输入输出都环环相扣Dify 可视化面板里可以清楚看到每个节点的数据流转调试时非常直观。3.2 关键节点配置实录先看意图解析节点。我只用了模型节点没有用分类器因为简单场景下提示词就够。提示词大概是这样的判断用户问题是否需要最新信息、外部数据或特定事实若是则调用联网检索否则使用本地知识库。然后是搜索词生成节点。默认用户输入的问题是口语化的“帮我查一下最近国产大模型 API 哪家便宜”这个不能直接当搜索词用搜索词应该是“国产大模型 API 价格对比”。所以我在模型节点里给它一个模板从问题中提取核心名词和限定词压缩成 2 到 5 个关键词组合不要加修饰语。真正有意思的是代码节点。Dify 的代码节点支持 Python我用它来做 URL 编码省得每次都让 LLM 去编码容易出错。代码很简单import urllib.parse def main(keyword: str) - dict: encoded_keyword urllib.parse.quote(keyword) url fhttps://www.baidu.com/s?wd{encoded_keyword}rn20 return {url: url, keyword: keyword}这里编码一定要在代码节点里做。如果直接拼 URL中文搜索词不会被浏览器或 HTTP 客户端自动编码FireCrawl 拿到的 URL 是非法请求根本抓不到结果。这个小点是我调试时踩过最笨的坑写出来提醒大家。搜索结果抓取我用的是 HTTP 请求节点直接 GET 上面拼好的 URL不需要额外 Header。返回的内容如果是 JSON 格式里面会有 markdown 字段后续解析节点就从这里取数据。接下来是链接解析节点。这里我让 LLM 从抓回来的 Markdown 中按规则提取真实站点链接。提示词里给了非常明确的格式要求[ { title: 文章标题, url: 文章真实URL, summary: 摘要内容, source: 站点名称 } ]同时告诉它要去掉百度自己的产品入口和广告区只保留自然搜索结果。这一步做出来的候选清单质量直接决定了后面抓正文的效果。最后是 FireCrawl 抓取正文节点。我配置了onlyMainContent这个参数很关键——它告诉 FireCrawl 只返回页面主体内容把导航、页脚、弹窗这些无关信息全扔掉。实测下来打开的页面哪怕挂了一堆推荐位广告返回的 Markdown 依然很干净LLM 读起来舒服多了。3.3 提示词研究助手的灵魂这套工作流里提示词占的比重比想象中大。我写了几个版本才调到满意的状态核心感受是“每个节点只让 LLM 干一件事”。意图解析节点不要让它输出长篇大论只输出一个字段。搜索词生成节点输出纯字符串不给解释。链接筛选节点输出 JSON 数组且要求必须给每个链接打相关性分数。综合分析节点输出一份结构化报告。这样设计的理由是模型在单一、明确的任务上更稳定输出格式越简单越不容易发生解析错误。综合分析节点是整个工作流的收口我给它设计的输出模板是这样的研究结论用 200 字以内概括核心结论关键发现列出 3 到 5 个对结论有直接支撑的事实点每个要点后标注来源争议与差异如果来源之间观点不一致明确指出来补充信息基于搜索内容列出值得进一步阅读的扩展方向参考资料以带链接列表的形式附上引用来源这个输出结构是我反复试用后确定的。研究助手最怕的就是只给一个干瘪结论没有出处、没有前因后果。上面这套结构基本能让用户拿着答案去回溯原文判断信息的可信度。3.4 参数调优一次完整的实测记录参数方面我把 Search 节点的抓取深度设成只抓第一页也就是 20 条搜索结果。因为经过验证第一页已经能覆盖大多数研究问题的有效线索抓更多页反而引入更多噪音也消耗更多 FireCrawl 额度。FireCrawl 抓正文时设置只返回 Markdown 文本不要截图不要 PDF 转换速度会快非常多。LLM 节点的温度参数我也做了区分搜索词生成用低温度确保关键词稳定性内容提取用更低温度防止模型在抽取链接时“创造性发挥”综合分析用中等温度让文章有一定归纳自由度。具体值是 0.3、0.1、0.5大家可以根据自己用的模型微调。实测案例我把问题定为“帮我调研一下最近国内开源大模型的许可证变化”整个工作流跑下来耗时二十几秒抓取了 3 篇相关文章正文最终报告里正确列出了许可证类型差异、社区争议点、以及各家的官方公告出处。相比我之前用“让 LLM 直接凭记忆回答”这份报告的可信度高了一个层次。4. 常见问题与排查技巧实录4.1 高频报错与解决办法搭建过程中我整理了一张问题表基本把能踩的坑都踩了一遍现象可能原因解决办法百度搜索结果为空搜索词未 URL 编码加代码节点转码FireCrawl 抓取超时目标站点响应慢调大 timeout 参数减少并发返回内容全是导航和广告没开 onlyMainContent请求参数加上 onlyMainContenttrueLLM 提取链接出现截断返回内容超过上下文先截断前 5000 字符再送 LLM知识库检索不召回分段策略/TopK 设置不合理调 TopK检查分段重叠抓取正文包含大量无用 JS 片段目标页面是动态渲染检查 FireCrawl 返回格式必要时启用 wait_for多租户空间看不到自定义工具工具没有跨空间共享在工具管理里设为公开或复制到目标空间前三个问题出现频率最高基本占了调试时间的七成。特别是超时问题有些站点本身响应就慢FireCrawl 默认超时时间不能满足业务场景我统一在配置里加到了 60 秒抓取成功率明显提升。4.2 从“能跑”到“好用”几个细节打磨链路跑通之后我花了整整一个下午做细节打磨。第一个细节是链接去重。百度搜索结果里经常会出现同一个站的多个页面或者转载内容高度相似的情况。我在筛选节点里让 LLM 对比标题和摘要把相似度高的结果合并只保留最完整的那个避免重复内容反复抓取浪费额度。第二个细节是来源可信度标注。我把source字段的赋值做了约束让 LLM 尽量识别出站点类型官方站点、新闻媒体、个人博客、论坛问答然后在综合分析节点里按可信度给来源排序。官方公告排第一个人博客和论坛内容只能作为补充参考不会喧宾夺主。第三个细节和安全相关脚本类内容、验证码页面、非法内容站点在 FireCrawl 抓取之前就该被拦掉。我在链接筛选节点里加了一条过滤规则指定站点类型直接剔除既能节约额度也避免模型读入垃圾信息影响判断。4.3 多轮对话场景的特别处理聊天流的好处是能多轮追问但这也带来了新问题第二轮提问时上一轮的搜索结果会留在上下文里容易造成混乱。我做了个比较笨但有效的处理每个新问题进来时都让意图解析节点先修正上下文把“上一轮已经回答过”的信息压缩成一句话埋进新提示词而不是让模型读完整历史。实测下来效果不错连续问三个相关问题时模型能区分哪些信息是新搜索来的哪些是之前已经确认过的不会答非所问。Dify 的对话历史变量在这里起了很大作用建议认真研究一下它的作用域和生命周期。5. 这套工作流还能怎么玩扩展与进阶5.1 定时监控与自动入库研究助手模式搭好之后最自然的扩展是“定时监控”。Dify 的定时触发能力可以实现这种场景每天早上自动搜一遍你关注的竞品动态或行业关键词抓取文章汇总出一份简报推送给你。配合知识库流水线还可以把每天抓取的优质内容自动写入知识库形成个人专属资料池越用越聪明。我已经开始这样玩了本质上就是把一次性的“研究”变成习惯性的“监视”。时间久了积累下来的知识库再配合问答系统就是一套私有版的行业情报中心。5.2 与其他工具的联动Dify 的开放接口让这套工作流能很方便地嵌进其他系统。比如把工作流发布为 API 后接到企业微信机器人里同事在工作群里直接 机器人发问题就能收到研究报告。群机器人的问题往往五花八门正好是这套链路最擅长的场景。搜索范围也不局限于百度。FireCrawl 本身支持抓任意网页和搜索源你可以并行加一个技术社区搜索、博客搜索多个源的结果在综合分析节点里做交叉验证结论会更扎实。注意控制并发数量别让 FireCrawl 同时请求太多页面容易被限流。5.3 关于版本更新的提示Dify 更新频率快如果你用的是旧版本建议升级后先跑一遍现有工作流确认节点行为没有变化再继续生产使用。我遇到过升级后自定义工具的鉴权 Header 格式变了导致 HTTP 请求 401排查了半小时才发现是版本兼容问题。多看更新日志升级前先备份数据库和 docker-compose 配置稳字当头。最后分享一点个人心得这套工作流跑通之后我最大的体会是研究助手真正难的不是模型能力而是流程设计。模型再聪明上游搜索乱七八糟、抓取断断续续输出一样一塌糊涂。Dify 的价值就在于把流程可视化让每一步都能人工干预和调试。我建议刚上手的朋友别急着追新功能先把自己最常用的一个研究场景完整跑通哪怕一开始丑一点、慢一点等链路通了再逐步优化也不迟。搜索引擎和抓取服务还会有更多新选择但只要流程骨架搭对了后面换工具、加来源都是顺手的事。