企业官网建设流程全解析

做调研是我日常工作中最躲不掉、也最消耗人的一件事。过去我习惯打开搜索页，开十几个标签页，一篇一篇翻，把要点复制进文档，再手工归纳结论。一场像样的技术调研写下来，一上午就没了。后来我开始用大语言模型辅助，但单轮问答的效果始终差一口气：你问它某个开源方案怎么样，它给你的往往是网上重复率最高的几个观点，甚至还有编造的数据来源。直到我接触到 DeerFlow 这类多智能体深度调研框架，才感觉这件事终于有人替我把“完整流程”接住了。

DeerFlow 不是一个普通聊天机器人，它是把“深度调研”拆成规划、搜索、阅读、验证、写作等多个环节、由多个智能体协作执行的框架，适合所有需要定期产出调研报告的人——不管是做技术选型、行业分析还是竞品跟踪。这篇内容面向想把它跑起来的人，我会从框架的模块分工讲起，讲清楚环境怎么搭、第一次运行会看到什么、参数怎么调、常见的坑怎么绕。文章里的方式我都实际跑过，不一定覆盖所有版本差异，但足以让你从 0 到 1 跑通，并把它用在自己的真实选题上。

1. 为什么单模型问答撑不起真正的深度调研

1.1 单轮问答的先天边界

先用一个比喻。单模型对话像一个记忆力很好但没有图书馆的人回答专业问题，他只能凭脑袋里背过的东西回答，没法说“等一下，我翻翻资料再回答你”。大模型训练语料再庞大，也有知识截止时间、数据偏见和错误记忆。面对“最近半年某领域进展如何”这类时效性问题，几乎毫无办法。

更麻烦的是，单模型无法主动判断“我掌握的信息够不够”。它给完答案就结束，不会因为多个资料相互矛盾就停下追加验证，不会发现全网信息存在分歧时重新搜索，更不会追溯原始来源。你追问一句，它可能换个说法继续编。深度调研恰恰依赖“查证—发现矛盾—再查证”的循环，单模型在这条路上迈出第一步就停住了。

从我在实际项目里的体感来说，让单模型直接写调研报告，最常见的三个毛病是：内容太笼统，几乎所有结论都是“A 有优点也有缺点”式的废话；来源不可查，关键数据不知道出自哪里；时效性差，训练数据切不到当下。中间也许有一段写得像模像样，但你一旦拿关键细节去核对，就会发现站不住脚。

1.2 深度调研的本质：一次信息工程项目

如果把深度调研这件事拆开看，会发现它跟写代码、做工程很像：先理解需求，再拆解任务，分头执行，最后集成验证。一份能用的调研报告，背后至少需要这些环节：

• 明确问题边界：主题具体要回答什么，哪些子问题必须覆盖，信息的时间范围怎么限定；
• 构造检索策略：为每个子问题设计查询词，决定优先去官方文档、行业分析还是社区帖子找线索；
• 广撒网抓取：执行搜索、阅读返回的页面、把有引用价值的段落摘出来；
• 可信度判断与去重：区分一手来源和二手转述，过滤大量重复内容；
• 交叉验证：关键结论至少有两个独立来源支撑，冲突信息单独标注；
• 综合输出：按目标读者的需求组织成有结构的报告，并在每个论点后面标注来源。

这些环节缺一不可。手动做费时费力，但流程非常清晰，完全可以用程序固化下来。多智能体框架做的事情，本质上就是把这套人工流程写成角色分工。

1.3 DeerFlow 在这个生态里的位置

DeerFlow 吸引我的地方在于：它没有把“自动调研”做成一个自由发挥的对话循环，而是做成了一条有明确分工的流水线。规划、检索、阅读、综合各自由独立智能体负责，智能体之间通过结构化数据传递中间结果。这种设计比“让同一个模型自由发挥”可控得多，也更容易排查某一步究竟出了什么问题。

另一个实用好处是模块化。模型层可以用 OpenAI 兼容接口对接商业模型，也可以换成开源权重模型；搜索后端同样预留了不同搜索服务商的接入空间。这意味着我可以把成本控制在可接受范围，还能针对自己的使用习惯做二次开发。对一个需要长期做调研的人来说，这种掌控感非常重要。

2. DeerFlow 的接力赛：几个智能体角色把调研报告拆成流水线

2.1 规划智能体：把大主题拆成子问题

第一次跑 DeerFlow 时，我看到的第一个角色就是规划智能体。给它一个“某某主题调研报告”，它不会直接去搜，而是先输出一份子问题清单。比如输入“用 RAG 做企业知识库问答的落地难点”，规划智能体拆出的子问题大致包括：RAG 的基本流程与组件、企业场景对准确率和延迟的要求、常见数据切分策略、检索召回瓶颈、评测方法、代表性落地案例、成本构成等。

这份子问题清单的质量直接决定后续工作的上限。拆得太粗，后面检索就盲目，所有查询词都绕着主题打转；拆得太细，搜索次数成倍上涨，成本和时间都收不住。我后来调优的时候，大部分精力都花在调整这个角色的提示词上，因为它对于最终报告结构的影响比写作角色还要大。

2.2 检索智能体：把子问题变成搜索动作

规划完成之后，检索智能体开始接棒。它会拿到每个子问题，再把子问题改写成更适合搜索引擎的查询语句。例如，子问题是“RAG 在企业落地的准确率瓶颈”，它可能会生成“企业级 RAG 准确率低原因”“RAG 落地 private knowledge base 错误率”“RAG chunking 策略与检索精度关系”等多组查询词，然后调用搜索服务的网页检索接口，拿回标题列表、摘要和链接。

这一步是我早期经常忽略的重点：不要以为有了子问题就自动有答案。查询词的措辞、搜索时间范围、来源偏好，都会强烈影响结果质量。如果你指定的主题本身在公开网络上信息很稀疏，检索智能体还需要不断调整查询词试探，直到找到可用材料为止。所以这一阶段往往会多次调用搜索接口，也是整个流程中成本波动最大的部分。

2.3 阅读萃取智能体：从网页里捞出有效信息

搜索返回的并不是成稿答案，而是一堆网页结果。阅读萃取智能体负责把这些结果打开，读取正文，提取关键段落，抽取数据点，并过滤广告、导航、重复文本。它还会给信息打上来源标记，方便后续报告里面引用。

在实现上，这个角色通常会把长文本切片后交给模型做摘要，再用规则把摘要合并成结构化要点。如果同一事实来自多个网页，它会在合并时做去重；如果发现矛盾，它会保留冲突信息并记录不同来源。本质上，这一步就是把“人工开十几个标签页阅读”的行为自动化。我在观察日志时发现，萃取阶段容易丢信息，尤其是当网页内容比较长、模型上下文不够用的时候，所以后来我会刻意检查萃取结果，而不是直接信任中间输出。

2.4 综合写作智能体：把碎片拼成报告

最后接棒的是综合写作智能体。它读取前面所有环节产出的要点和来源标记，再按照报告结构进行组装。它会考虑逻辑线索、章节编排，也会把适合对比的信息放进表格，把关键结论放到显眼位置，并在每个论点后面挂上引用来源。

这一步最大的特点是可以追溯。因为前面所有信息点都带着来源 ID，最终报告里的任何一句话，理论上都能回溯到某次搜索结果或某个网页摘要。我自己在做团队内部分享时，经常把这条追溯链当作核心卖点，它意味着 AI 生成的报告不再是无源之水，人工复核成本大幅下降。

2.5 角色之间靠什么交流

这几个角色之间的通信在我看来是这套框架的骨架。每个角色的输入输出都是结构化数据，也就是 JSON，而不是自然语言聊天记录。这样设计有几个明显好处：角色之间耦合度低，哪个环节出了问题可以直接替换；中间结果可以落盘保存，方便调试和追溯；不同角色还能搭配不同模型，而不是整个流程绑死在一个模型上。

我在二次开发时最喜欢的就是这一点：不需要读懂全部源码，只要把某个环节的输入输出接口摸清楚，就能单独替换或增强它。比如想加入一个专门的“数据校验智能体”，只需要在综合写作前插入一个新节点，从萃取结果里读取要点，再返回一份校验标注，整体流程就能升级。

3. 上手机器就没停过：环境准备、模型接入与搜索源配置的完整记录

3.1 Python 环境与依赖安装

运行 DeerFlow 首先需要一台装了 Python 3.10 及以上版本的机器。我建议不要直接装在系统 Python 里，而是创建独立虚拟环境，否则很容易遇到包版本互相打架的局面，尤其是异步 HTTP 库和 Pydantic 这类比较敏感的依赖。

基本步骤就是创建虚拟环境，激活它，然后到项目目录下安装依赖。如果是从官方仓库拉源码，还需要把仓库克隆到本地，再安装配置文件里列出的那些 Python 包。整个安装过程正常情况下几分钟能完成。如果你本机网络比较慢，可以换用镜像源加速，但要注意镜像源和依赖锁文件里的版本号是否匹配。

3.2 模型接入：LLM 配置里最容易被忽略的细节

DeerFlow 本身不绑定某个特定的大模型，而是接“OpenAI 兼容接口”，所以在配置文件里要填三样东西：接口地址、密钥、模型名称。接口地址可能是商业模型服务的地址，也可能是本地部署的模型服务地址；密钥要和这个地址匹配，模型名称一定要填写目标服务真正认的名字。

这里有个容易忽略的细节：整个调研链路里多个步骤会连续调用模型，并且每一步都要求返回结构化 JSON。如果你的模型不支持工具调用或严格的 JSON 输出模式，流程很容易中途断掉，要么返回一堆解释性文字，要么报解析错误。我遇到过一种情况：前面规划环节都正常，到了综合写作就反复报格式错误，最后发现是配置里把模型名字写成了旧版，而旧版模型对复杂 JSON Schema 的支持不稳定。所以跑正式任务之前，建议先用一个简单脚本测试模型服务是否支持强制 JSON 输出。

3.3 搜索源配置：没有搜索接口，框架就少了“手”

DeerFlow 本身不带搜索引擎，必须通过搜索服务商的 API 获取网页结果。配置项一般集中在 .env 或配置文件里，包括搜索服务的 key、搜索引擎标识、搜索地区、语言偏好等。不同搜索服务商返回的字段差异很大，有的给正文摘要，有的只给标题和链接，这会直接影响萃取环节能拿到多少材料。

在填入 key 之后，我建议先单独发一个最小的 HTTP 请求验证 key 是否有效，而不是直接启动整个调研任务。因为如果 key 无效，你在日志里看到的可能只是“搜索无结果”或“请求失败”，排查时容易和网络问题混淆。搜素 API 通常都有免费额度和计费规则，我实际跑一个中小型调研任务大概会消耗几十次到上百次搜索请求，批量跑之前最好先估算预算。

3.4 我踩过的三个环境坑

第一是依赖版本冲突。我之前在已有项目的环境里直接装 DeerFlow，结果某些异步请求库版本不一致，导致模型调用时连接被反复重置。解决办法就是换到全新虚拟环境里重装，再没出过同类问题。

第二是配置不生效。框架读取配置有优先级，有些配置项放在文件里，有些放在环境变量里，环境变量还会覆盖文件里的同名配置。当时我把模型密钥填进了配置文件，但环境变量里残留了一个旧值，导致一直报认证失败。排查时要先确认到底读的是哪份配置，最好的办法是在启动时打开调试日志看配置摘要。

第三是网络超时。搜索接口或模型服务的响应速度受当前网络质量影响很大，任务可能长时间卡在等待响应上。我的做法是把超时时间调大一些，同时打开日志观察任务到底卡在哪一步，再用小规模任务复现确认，而不是盲目重启。

4. 第一次试跑观察日志：从选题到成稿，每个环节到底输出了什么

4.1 选一个“不容易翻车”的首次选题

首次跑通，选题非常关键。太偏门的主题资料稀疏，检索智能体会反复空转；太宽泛的主题成本高，报告还会散。我推荐选一个“资料丰富、有一定争议面、不需要独占数据支撑”的话题，像“RAG 在企业知识库落地中的关键难点”就属于比较理想的首试题目，既有大量公开资料，也没有统一的标准答案，能充分展现检索和萃取的差别。

我当时调整了默认配置，只保留前两个轮次的搜索，模型也用成本比较低的那一档，先验证流程能走通，而不是一上来追求高质量报告。这样即使跑出问题，修复成本也低。等到流程稳定、中间输出都正常之后，再放开模型和搜索轮次去跑真正的完整任务。

4.2 规划环节：看子问题列表有没有“调研感”

第一次启动后，我先把日志级别调到最细，打印每个环节的中间结果。规划智能体输出的子问题列表令我比较惊喜，它拆出了十几个子问题，覆盖数据切分、召回优化、评估体系、落地成本等维度，确实有一点点“有经验的调研助理”的感觉。

但仔细看也有问题：个别子问题明显太偏，比如单独拆出一个“向量数据库选型对比”，和主题相关，但优先级没那么高，会在后续检索阶段消耗不必要的搜索次数。这让我意识到，规划质量受模型推理能力影响极大，也受提示词影响极大。后面我会在提示词里明确要求：只保留与主题强相关的子问题，并按优先级排序。

4.3 检索与阅读环节：跟踪查询词与信息萃取过程

规划完成之后，日志里开始出现一条条搜索记录。我看到每个子问题都配了多组查询词，有的子问题甚至搜索了三四次，因为第一轮结果不够。这种“尝到甜头继续搜”的行为是人工调研的典型动作，说明框架不是简单地执行一次关键词查找。

萃取环节的表现也很有意思。它会把每篇网页压缩成若干条要点，每条要点都带上来源页面的编号。我翻了一下中间 JSON，发现它对短网页处理得很好，摘要干净、不啰嗦；但遇到超长技术文档时，会有明显的截断，部分数据点丢失。后来我调大了单次读取的最大长度，情况有明显改善。所以如果你发现报告里总缺某个方面，先回头查萃取结果是不是漏了。

4.4 综合环节：报告初稿的真实状态

最终报告是 Markdown 格式，有概述、分论点、对比表格、引用列表，骨架完整。但坦率地说，第一次跑出来的质量只是“能看”，距离“能用”还有一段距离。最明显的三个不足：部分结论只用了一个来源支撑，交叉验证不够；重复内容没有被完全合并，前后两节出现相似观点；个别表述比较空泛，因为萃取出来的要点本身就不够具体。

这个结果完全正常。首次跑通的目标是暴露问题，而不是一次到位。接下来要做的就是按着这些缺陷，反推是规划拆得不够细、还是检索范围不够宽、还是写作模型理解力不足，再逐项调整。

5. 调参不只是调模型：这几个参数才是决定调研深度的关键

5.1 模型选型与分工

DeerFlow 的不同环节其实可以搭配不同模型，这是性价比最高的调优手段。规划智能体和综合写作智能体承担了最多推理负担，需要用推理能力强的模型，比如配置里换成一个参数量更大、逻辑更稳的模型；阅读萃取智能体做的事情相对机械，可以用响应更快的轻量模型，成本能降不少。

我实测下来，把萃取环节换成轻量模型，输出质量差别不大，但成本降低明显；反过来，如果把综合写作也换成轻量模型，报告的结构和逻辑立刻变散。所以我的建议是：预算有限时，优先保证规划和综合两个环节的模型质量，萃取的模型可以适当妥协。

5.2 搜索深度与广度参数

这是直接决定报告“厚不厚”的一组参数。最大搜索轮次控制每个子问题最多能迭代搜索多少次，单轮结果数控制每次搜索返回的网页数量。轮次太少，检索智能体裁不出足够的材料，报告就会单薄；轮次太多，时间成本和费用成倍上涨，而且容易重复。

我一般从默认参数开始，先跑一个中型主题看效果。如果报告里每个章节后面只有一两条引用，说明搜索深度不够；如果日志里大量搜索没有新增信息，说明搜索轮次已经冗余，可以往回缩。另一个有用的配置是时间范围过滤，把搜索限定到近一年或近半年，特别适合做行业动态跟踪。

5.3 并发与重试参数

并发参数控制的是多个子问题是否同时执行。并发数太小，整个调研任务跑得像蜗牛；并发数太大，搜索服务和模型服务都可能触发限流，任务整体反而变慢。我走得比较稳妥，起步并发数不超过 5，确认没有限流问题再往上加。

重试参数也很关键。模型服务偶尔返回超时或限流错误，框架一般会自动重试，但重试次数和退避策略都可以配置。如果重试次数过多，遇到服务持续抖动时会把任务拖很久。我的习惯是开 3 次重试、每次退避间隔 5 到 10 秒，既能容忍临时抖动，又不会把任务耗死。

5.4 提示词定制：让报告更贴近自己的使用场景

改代码不如改提示词见效快。规划智能体的提示词可以增加行业背景，要求拆解时强制加入“成本与风险”“数据安全”这类维度；综合写作智能体的提示词可以指定报告语气，比如写成面向管理层的决策简报，或者面向工程师的技术评估文档。

我调整提示词时有个习惯：一次只改一个角色，记录前后两次输出的差异。同时改五处，出了问题根本不知道是谁的错。另外，改完提示词一定要先跑一个小型任务验证，不要直接上几十个搜索轮次的大任务，否则一次调坏就是十几分钟和一笔费用。

6. 跑不起来、搜不出来、写得不像人话：三类常见故障的排查思路

6.1 启动阶段就报错：按日志逐层定位

启动阶段最常见的报错是模块缺失、密钥认证失败和端口占用。模块缺失通常说明依赖没有装全，回到虚拟环境里重装一遍；认证失败要检查模型服务和搜索服务两组密钥是否都配置正确，尤其注意环境变量是否覆盖了文件配置；端口占用一般是本地模型服务已经被别的进程占用，换一个端口就好。

我的排查顺序很固定：先看最顶层的报错信息，再到日志中间找第一次出现异常的位置，最后回查配置项。很多问题其实在日志里写得很明白，只是被大段堆栈盖住了，需要静下心顺着时间线倒推。

6.2 搜索阶段零结果：先别急着怀疑框架

搜索阶段出现“零结果”或“结果太少”，原因大概率不在框架本身，而在搜索源。最常见的有四类：API key 失效或配额耗尽，搜索接口返回错误但被当成了空结果；查询词太冷门或措辞太学术，搜索引擎没索引到合适内容；时间范围过滤设置得太窄；某些搜索服务对特定语言或地区的网页覆盖不足。

排查技巧是把单个子问题拿出来，直接用同样的查询词去搜索服务商的控制台验证一遍。如果在控制台也搜不到，那就是查询词的问题，调整提示词让检索智能体尝试更口语化、更细致的变体；如果控制台能搜到但框架里没有，就去看 API 的返回字段是不是被解析层漏掉了。

6.3 报告质量差：按链路环节定位瓶颈

报告质量差没有统一解法，必须先定位瓶颈出在哪个环节。子问题拆得不好，报告结构一定散，回头改规划提示词；萃取环节丢数据，报告一定薄，往回检查中间 JSON 里的要点覆盖；综合写作模型太弱，报告一定空，该换强模型或调写作提示词。

我把这种排查叫“环节回溯法”：每级中间产物都保留下来，质量出问题时从下游开始往回查。先看最终报告，找到最弱的那一节，往上找这一节对应的综合输入，再看萃取结果，再看原始搜索记录。基本上三轮之内就能定位是哪一步丢了信息或没有正确理解。

6.4 我长期形成的四个排查习惯

一是先看日志再看代码。多智能体系统的运行状态全部隐藏在日志里，直接读源码容易看错调用关系。

二是用小规模任务复现。任何修改都先用最小配置跑通，再扩大到完整任务，成本可控。

三是检查配置优先级。确认框架到底读取哪份配置，尤其是同时存在 .env、配置文件和环境变量时。

四是定期更新依赖。这类框架迭代很快，很多隐蔽 bug 在更新日志里已经标注修掉，升级依赖比临时改代码省事得多。

跑通 DeerFlow 之后，我最大的感受是：它并不会让调研质量自动超过一个有经验的人，但它把最耗时的重复劳动稳稳接住了。我现在最常用的场景是每周让它生成一份指定方向的技术动态简报，再花十几分钟人工核对引用来源和关键结论，整体效率和过去手动搜一上午相比提升明显。

最后分享两个小经验。一是跑完任务一定把中间 JSON 留一份，后续复核时，任何一条结论都能回溯到最初的搜索结果，这对保证调研可信度非常关键。二是如果想长期使用，可以把调研任务做成定时任务定期执行，再把输出导进自己的笔记体系，相当于养了一个不睡觉的研究助理。希望这份记录能帮你少走弯路，尽早把 DeerFlow 变成自己顺手的信息工具。