企业官网建设流程全解析

从零搭建一个属于你的 OpenResearch：开源研究智能体实操全记录

先说结论：OpenResearch 不是那种只能跑 demo 的玩具项目，它是一整套把“人肉调研”变成“半自动研究流水线”的工程方案。我把它理解为一个面向研究场景的开源智能体框架，核心解决三件事：第一，把散落在网页、论文、文档里的信息自动抓回来；第二，用大模型对这批信息做归纳、对比和提炼；第三，把整个调研过程拆成可以复用的模块，让后续每一次研究都能站在前一次的“底座”上继续跑。

实际动手之后你会发现，真正花时间的不是调大模型接口，而是处理数据采集、清洗、分块、索引这些“不性感但决定成败”的脏活累活。这篇文章会从架构设计、技术选型、落地实现到问题排查，把我在真实项目里跑通 OpenResearch 的全过程记录下来。适合谁看？如果你正在做 AI Agent、知识库系统、自动调研工具，或者只是好奇“让 AI 帮我查资料写综述”到底怎么落地，这篇应该能帮你少踩几个坑。

1. 看懂 OpenResearch 这名字背后的含义

1.1 为什么叫“开放研究”，而不是“自动搜索”

一开始我看到 OpenResearch 这个名字，以为它只是一个聚合搜索工具，后来自己动手实现才发现，这个命名非常准确：开放（Open）强调的是数据源和流程的开放，研究（Research）强调的不只是“搜索”，而是从问题到结论的完整研究链路。

两者的差别在哪？普通搜索引擎给你的是十个蓝色链接，OpenResearch 给你的是经过筛选、归纳、标注来源的分析结果。它把“搜索→阅读→整理→输出”这条原本要花几小时甚至几天的人工链路，拆成了几个能被代码自动调用的环节。所以，它的核心单元不是“一次查询”，而是“一个研究任务”，这个词在后文会反复出现，因为它决定了整个系统的数据流设计。

1.2 项目到底能做什么，不能做什么

先说能做的。我目前跑通的 OpenResearch 版本支持这样几类任务：技术调研（比如“对比主流向量数据库的写入性能和召回率”）、论文综述（给它一个方向，它会抓取 arXiv 和期刊页面，按主题聚类后生成带引用的综述）、行业分析（抓取企业官网、新闻稿、财报摘要，输出竞争格局和趋势判断），以及个人知识库问答（把本地文档作为数据源，做限定范围的检索增强回答）。

不能做什么，这个我吃过亏，必须讲清楚。它不能代替研究者做最终判断，因为大模型输出的结论仍旧存在幻觉风险，尤其是数据源本身冲突时，它并不会自动知道谁更权威。它也不能做到完全自动化，至少在“定义研究问题”和“确认输出质量”这两个环节，都需要人介入。更准确地说，OpenResearch 解决的 80% 的体力活是资料检索整理，剩下 20% 的判断题必须由你来做。

2. 核心架构设计：一个研究型 Agent 的五大模块

真正动手前，我先给自己画了一张架构图，不是画给别人看的，是逼自己把思路理顺。一个完整的 OpenResearch 至少要有五个模块：需求解析、数据采集、内容处理、分析生成、质量校验。这五个模块可以分别在独立的服务里跑，也可以拆成五个 Python 包放进同一个仓库，具体看你的部署环境。

2.1 需求解析模块：把模糊想法变成可执行指令

这是整个流水线里最容易被低估的一环。大多数人对 Agent 的预期是“我说一句话它就去干活”，但实际落地时，模糊的指令意味着后面所有环节都会跟着模糊。比如“帮我查一下大模型微调的现状”，这句话交给大模型，它会给你一堆关于 LoRA、QLoRA、PEFT 的杂烩，信息密度很低。

我的做法是引入一个“研究需求单”，让模型先把用户的模糊描述转成结构化字段：研究主题、目标受众、时间范围、地理范围、数据源偏好、输出格式、字数约束。这一步看起来像在“折磨用户”，但它能显著提高后续采集和生成的准确性。需求解析环节我一般用一个较小的模型来跑，因为它是表单填写而非深度推理，用大参数模型纯属浪费。

2.2 数据采集模块：决定研究质量的上限

这一模块的任务是把需求单翻译成具体的抓取任务。例如用户要“近两年的向量数据库对比”，系统就生成一组关键词组合，分发给搜索组件，拿到候选 URL 后进入正文抽取。

这一模块并不依赖大模型，它靠的是搜索 API 加抓取解析库，最多加一层规则引擎做站点适配。很多人在这个环节盲目追求“智能”，我的建议是越规则化越可靠。采集模块关注三个指标：覆盖率（该查的源查了没有）、时效性（数据是不是最新的）、稳定性（反爬、编码、超时是不是处理好了）。采集质量直接决定后续分析质量，简单说就是 Garbage in, garbage out。

2.3 内容处理模块：把非结构化数据变成系统能理解的形态

抓下来的 HTML 必须清洗成干净的正文，然后根据长度切分成段落或语义块，再送给 embedding 模型做向量化。这个模块的工作量占整个项目的 40% 左右，但很多人把它当成“边角料”处理，这是错的。清洗和分块策略直接影响检索召回质量，而召回质量又直接影响最终输出质量。

具体来说，我先用 Trafilatura 抽取正文，再做一层自定义清洗：去重、识别列表、合并段落、剔除广告和导航文本。分块策略上测试过固定窗口、按段落分块、语义切分三种方式，最后固定窗口加 10% 重叠效果最稳定。向量化用 bge-m3 这类中文友好的模型，每个块控制在 512 token 左右。

2.4 分析与生成模块：Agent 的“大脑”所在

这是模型真正出场的地方。拿到向量检索后的相关文本块，系统需要把它和用户的研究需求一起组装成上下文，由大模型完成归纳、对比、推理和生成。

我在实际操作中把这一模块继续细分：先让模型生成“研究大纲”，也就是把用户需求映射成若干子问题；然后针对每个子问题做一轮检索、阅读和归纳；最后把这些归纳结果拼接成完整报告，再做引用标注。这样做比“一次检索、一次生成完整报告”要稳得多，原因很简单：大模型的注意力有限，一次塞 30 个文本块让它写综述，它往往到后面就忘了前面的内容，结论偏颇是常态。

2.5 质量校验模块：AI 生成内容的最后一道防线

这个模块很多开源实现里根本没有，但我在跑完第一版后果断加上了。校验模块做两件事：第一，核查每个关键结论是否能在检索到的原文里找到对应依据，找不到的标记为“待验证”；第二，检查输出结构的完整性，比如必须包含的数据点有没有遗漏，引用编号是不是和参考文献对应得上。

校验模块可以用规则做一部分，比如引用编号的对应关系；也可以用模型做一部分，比如“你判断一下报告中第 3 节的主语和结论是否与提供的原文一致”。我实际的做法是两层结合：规则优先，模型兜底，因为模型校验本身也会出错，不能完全依赖它。

3. 技术选型拆解：每一步都解释一下为什么这么选

这章的每个选型都有替代方案，我会说明我最终的选择、替换时的考量，以及踩过的坑。

3.1 正文抓取：为什么是 Trafilatura 而不是通用爬虫

最初我尝试过 Requests + BeautifulSoup 手写解析，也试过 Scrapy 做整站抓取，后来都没能成为最终方案。原因很简单：OpenResearch 面对的是大量陌生站点，而研究类数据源（论文页面、新闻资讯、官方文档）的 HTML 结构千奇百怪，手写解析器的维护成本太高；Scrapy 则更像是为固定站点的爬虫任务设计的，做通用正文抽取时又重又不灵活。

Trafilatura 的定位恰好是“从任意 HTML 中提取主文本”，它内置了针对正文区块和样板内容的启发式算法，对新站点的泛化能力远比手写规则要好。实测下来，它在一个有 200 个测试 URL 的样本集上的正文抽取成功率在 80% 左右，手写规则只能做到 60% 上下。阅读类站点如果能额外拿到 RSS 源，采集质量会更高，因为 RSS 的摘要相对干净。

3.2 检索增强（RAG）落地的几个关键参数

RAG 看似简单，实际参数敏感。主要关注三个参数：分块大小、Top-K 数值、是否做重排。

分块大小我最终定在 300 字到 500 字之间（中文），重叠 50 字。章节分段有时能达到 2000 字以上，直接做向量化会造成两个问题：一是向量表征被冗余内容稀释，检索时召回不精准；二是超长块塞进上下文会挤占大模型的注意力预算。

Top-K 我一般取 6 到 8。太少则信息不足，太多则噪音增多。最关键的是要加一层重排：bge-reranker 对召回结果做一次精排，把和问题真正相关的块提到前面。加了重排之后，最终报告里“无中生有”的段落数明显下降，这一点在技术调研类任务上尤其明显。

3.3 模型层：本地模型与 API 模型如何取舍

我的建议非常直接：如果你没有 24GB 以上显存的显卡，不要执着于本地部署生成模型。OpenResearch 的生成链路里，上下文经常要填到 8000 token 甚至更多，本地小模型的输出质量和速度都很吃力。我的实际分工是：需要深度推理和长文本生成的环节用大参数 API 模型，需求解析和标题生成这类轻任务用本地小模型，既省钱又不会太慢。

另外要提一下 embedding 模型。我先后测试过 text-embedding-ada-002、bge-m3 和 m3e，最终日常项目固定用 bge-m3，因为它在中文技术文档上的召回效果不弱于商业化接口，而且可以本地跑，数据不出内网。

3.4 工程细节：并发、缓存与限流

这块文档里很少提，但实际跑起来全是坑。我固定用 SQLite 加一个简单的缓存表来存储抓取结果，URL 做唯一键，重复抓取直接命中缓存。这样做有两个好处：抓取速度快了，而且对目标站点的压力小了，不容易触发反爬。

并发控制我压在 3 到 5 个并发请求，QPS 限制在 2 左右。这是一个平衡值，太快会被封 IP，太慢又影响效率。遇到 403 或 429 响应后，我会退避重试，最多重试两次，退避时间指数增长。这个策略在新闻类和博客类站点上基本没出过事，但要注意，每个站点都有各自的 robots 规则，抓取前应确认自己的操作是否符合对方网站的公开允许范围。

4. OpenResearch 的落地实现：跑通一条研究流水线

从设计到实践，我写过不止一版代码，这里给你一条最简但可复用的落地路径。不需要一开始就实现全部五个模块，先把流水线跑通，再逐步加校验和优化。

4.1 一条完整流水线的运行流程

我用一个“mini_research.py”的脚本把全流程串起来。运行逻辑是：输入研究需求 → 需求解析模块生成检索词 → 调用搜索组件拿到 URL 列表 → 批量抓取正文 → 清洗分块 → 向量化入库 → 检索召回 → 大模型归纳生成 → 输出 Markdown 报告。

python mini_research.py --topic "2024年开源向量数据库对比" --out report.md

注意看，这里的入口参数只有两个，一个是 topic，一个是输出路径。看起来简单，但内部流程已经跑了一整个研究循环。这个脚本的完整运行时间因数据源数量和响应速度而异，通常 5 到 15 分钟不等。

跑完之后，report.md 底部会附上参考文献列表，每条都对应检索到的原始 URL。这一步特别重要，因为研究报告和普通问答最大的不同就是必须可溯源。

4.2 提示词工程：把“研究需求”翻译给 Agent

提示词这块我踩过不少坑，总结出一个稳定的模板结构，分为五个部分：角色、任务、约束条件、输出格式、参考来源。约束条件里我会显式注明“不要编造数据，没有来源支持的观点请标注为推测”，这是压制幻觉最有效的一句话。

给 Agent 的提示词示例（简化版）：

你是一名资深行业研究员。 请围绕主题「{topic}」完成一份调研报告。 要求： 1. 基于提供的参考来源，不要使用来源之外的信息。 2. 输出结构：背景、现状对比、关键结论、风险提示。 3. 每个结论后面必须标注来源编号，例如 [1][2]。 4. 如果参考来源中找不到依据，请写出“当前资料无法支持该结论”。 参考来源如下： {retrieved_chunks}

可以注意到我把“无法支持”作为合法输出，而不是逼模型硬给答案。运行结果里，加了这句之后，报告中“可能”“大概”这类模棱两可的表述减少了，取而代之的是更明确的信息缺口提示，本质上提高了可信度。

4.3 数据存储设计：一张表就够了，但字段别省

我用 SQLite 存数据，只有一个 sources 表，字段如下：

这个表简单，但够用。content_hash 字段建议保留，我最早省略了它，后来发现重复抓取时每次都重新清洗分块，既慢又费 tokens。加了哈希之后，重复 URL 或重复内容直接跳过，存储成本和接口成本都降下来了。

usage_count 这个字段也很有用。报告生成后，我会反向统计每个来源被引用了多少次，以此识别“核心信源”和“边缘信源”。如果某个 URL 被引用次数很高，说明这个来源对最终结论影响很大，需要重点复核。

5. 实操中的高频问题与排查手册

最后这部分，我把实际使用 OpenResearch 时踩过的坑整理成了一份速查表。这些问题很有共性，你在自己搭建时十有八九会遇到。

5.1 高频问题速查表

这张表里最值得反复看的是第二行：报告有常识错误。很多人在模型层找原因，换更大的模型，但问题其实出在检索层。如果把一个错误网页排在前面，大模型再强也会被带偏。先查召回，再查提示词，最后才换模型，这是调优顺序。

5.2 排查思路与调试技巧

当你发现输出质量差时，不要直接改提示词。我建议做一个“数据体检”：把一串研究问题的原始输入、检索到的文本块、最终输出三者放到一起看。如果检索到的文本块本身不相关，那问题在采集或召回，改提示词没有意义；如果文本块相关但输出不相关，那才轮到优化提示词或换模型。

调试时我最常用的一招是“模板分离”。把需求解析、抓取、清洗、召回、生成分别写成独立函数，然后用一个 debug 模式单独打印每个环节的输出摘要。比如抓取环节是否拿到正文、清洗后字数是否合理、向量化用了多少块、召回命中了哪些文档。这一套下来，问题几乎一分钟就能定位到具体模块。

还有一个容易被忽略的问题：缓存的脏数据。有些页面第一次抓取时正常，后来站点改版或内容更新了，你的缓存库里还是旧版本，导致结论过时。我的做法是给缓存加一个 TTL（生存时间），一般设 7 天，过期后重新抓取。

5.3 还能怎么扩展：从个人工具到团队平台

现在这个 OpenResearch 已经能稳定跑通单机研究流程。如果后续要让它服务团队，我建议按这个顺序扩展：第一，把结果存储从 SQLite 迁到 PostgreSQL，支持多人并发检索；第二，给任务加一个队列，用 Celery 或类似方案管理异步任务；第三，做一个简单的前端界面，让研究员录入需求、查看报告、反馈标注。

另外，我最近在尝试给它加一层“知识沉淀”机制：每次研究完成后，自动抽取报告里的关键结论和历史结论合并，生成一份“领域快照”，下次同类研究可以基于快照做对比分析。这个方法还处于早期，但我觉得方向是对的，相当于让 OpenResearch 具备了一定的记忆能力。

我在实际把 OpenResearch 搭起来并跑完第一份真实报告之后最深的体会是：这类工具真正迭代的不是模型，而是“数据链路”的可靠性。每次花时间优化抓取、清洗、去重、缓存，短期看不出效果，但长期跑下来，整个系统的稳定性和输出质量会明显上两个台阶。最后再分享一个小技巧：给关键的检索结果打印一行调试日志，记录下“检索词→命中文档→最终引用”的路径，你会惊讶地发现很多质量问题，其实在检索阶段就能提前发现并补救。