返回首页

Stanford OVAL STORM 项目分析报告

发布时间：2026-06-19 · 分析对象：stanford-oval/storm · 项目定位：LLM 驱动的知识整理、深度检索与长文报告生成系统

核心判断：STORM 最值得复用的不是代码本身，而是它的研究流程：先做多视角问题发现，再做检索增强对话和资料归纳，最后生成大纲与带引用的长文。对 OpenClaw 来说，最佳路线是先把它固化成报告生成方法论，再考虑实验性接入 knowledge-storm。

1. 核心结论

STORM 是 Stanford OVAL 实验室开源的知识整理系统，全称是 Synthesis of Topic Outlines through Retrieval and Multi-perspective Question Asking。它的目标不是做一个普通搜索增强问答机器人，而是把“写一篇有引用的维基式长文”拆成可执行的研究流程：先围绕主题提出多视角问题，通过搜索收集资料，再生成大纲，最后写成带引用的长文。

这个仓库现在已经不只是论文 demo。它包含 Python 包 knowledge-storm、STORM pipeline、Co-STORM 协作式 pipeline、多个搜索后端、LiteLLM 模型适配、VectorRM 私有文档检索，以及一个轻量 Streamlit 前端。

2. 项目基本信息

公开仓库信息截至 2026-06-19：

版本号不一致是一个小瑕疵，因为仓库的发布 workflow 明确会检查 setup.py 和 knowledge_storm/__init__.py 的版本一致性。它不影响我们理解项目，但说明当前 main 分支的发布工程纪律不是完全干净。

3. 它到底做什么

STORM 解决的是“复杂主题研究和长文生成”的问题。普通 RAG 通常是用户问一个问题，系统检索若干资料后回答；STORM 的思路更像人类写综述或百科文章：

  1. 先理解主题可能有哪些观察角度。
  2. 让不同视角的“维基作者”提出问题。
  3. 让“专家”基于搜索结果回答这些问题。
  4. 把问答和资料整理成信息表。
  5. 生成文章大纲。
  6. 按大纲写出带引用的长文。
  7. 最后做 polish，加入摘要、去重或改善表达。

所以它更接近 Deep Research / research agent / 自动综述写作系统，而不是传统 chat bot。

4. STORM 工作流拆解

4.1 Knowledge Curation

这一步负责收集资料。核心设计是模拟对话：WikiWriter 扮演有特定研究视角的维基作者，负责问问题；TopicExpert 把问题拆成搜索 query，用搜索后端取回资料，再基于资料回答；ConvSimulator 让 writer 和 expert 多轮互动。

这一步的关键不是“搜一下”，而是自动生成好问题。它把研究质量押在“问题是否覆盖不同视角”上，这是 STORM 最有价值的思想。

4.2 Outline Generation

系统会先生成一个直接大纲，再基于收集到的信息生成 STORM 大纲。输出包括 direct_gen_outline.txt 和 storm_gen_outline.txt。这个设计保留了“仅凭模型知识的大纲”和“检索增强后的大纲”，方便比较两者差异。

4.3 Article Generation

系统根据大纲逐节写文章，并从信息表中检索相关引用。输出包括 storm_gen_article.txt 和 url_to_info.json。每一节不是纯生成，而是用前面搜集到的来源作为依据。

4.4 Article Polishing

最后一步负责改写成更完整的最终稿，支持添加摘要和去重。输出为 storm_gen_article_polished.txt。从报告生产角度看，这一步相当于编辑台。

5. Co-STORM：协作版 STORM

Co-STORM 是后续扩展，论文发表于 EMNLP 2024。它从“系统自动写一篇文章”升级到“人和多个 LLM expert 一起探索主题”。

Co-STORM 的核心角色包括多个 expert agent、Moderator、Human user，以及动态 mind map。普通报告生成通常是“一次性输出”，Co-STORM 更像“边研究边开圆桌会”。如果接入 OpenClaw，可以变成：多个子 agent 分别从技术、商业、投资、安全、生态角度查资料，中途让用户插话调整重点，最后再收敛成公开报告。

6. 技术架构

knowledge_storm/
  storm_wiki/              # STORM 主流程
  collaborative_storm/     # Co-STORM 协作流程
  lm.py                    # LLM 封装，LiteLLM、OpenAI、Claude 等
  rm.py                    # retrieval model，搜索和向量检索
  interface.py             # 抽象接口和数据结构
  dataclass.py             # conversation、knowledge base 等结构
examples/
  storm_examples/          # GPT、Claude、Gemini、Groq、Mistral、DeepSeek、Ollama 示例
  costorm_examples/        # Co-STORM 示例
frontend/demo_light/       # Streamlit 轻量 UI

依赖层面，dspy_ai==2.4.9 是核心编排依赖，litellm 用来适配多模型供应商，trafilatura 用于网页正文抽取，qdrant-client 等用于自有语料向量检索。

7. 模型与搜索后端

STORM 允许不同阶段使用不同模型：便宜快速模型可以用于拆 query 和模拟对话，更强模型用于生成大纲、写正文和 polish。

检索后端在 knowledge_storm/rm.py 中包括 YouRM、BingSearch、VectorRM、SerperRM、BraveRM、DuckDuckGoSearchRM、TavilySearchRM、GoogleSearch、AzureAISearch 和 SearXNG。

VectorRM 很重要。它允许不用互联网搜索，而是用自己的 CSV 语料和 Qdrant 向量库作为资料来源。这意味着 STORM 可以从“公开互联网研究工具”扩展成“企业内部知识库报告生成工具”。

8. 输出与可审计性

topic_name/
  conversation_log.json
  raw_search_results.json
  direct_gen_outline.txt
  storm_gen_outline.txt
  url_to_info.json
  storm_gen_article.txt
  storm_gen_article_polished.txt
  run_config.json
  llm_call_history.jsonl

这是一个很好的设计。它让报告不是“凭空生成”，而是保留问过什么问题、搜过什么 query、搜到了哪些资料、大纲如何形成、哪些来源进入最终文章，以及 LLM 调用配置。

9. 和 Deep Research、NotebookLM、Agent Reach 的区别

STORM vs Deep Research：Deep Research 更偏产品化，一般只给用户最终报告和引用；STORM 更偏研究框架，暴露 question asking、conversation log、outline、article generation 等中间层。

STORM vs NotebookLM：NotebookLM 更强在用户给定材料后的理解、问答和摘要；STORM 更强在主题尚不明确时主动提出问题、上网搜索、扩展视角、生成结构化长文。

STORM vs Agent Reach：Agent Reach 更像工具路由层，负责“去哪里拿资料”；STORM 更像研究写作层，负责“拿到资料后怎么研究和写报告”。两者可以互补。

10. 对 OpenClaw / Codex 的复用价值

11. 不建议直接照搬的地方

12. 本地验证

我成功 clone 最新 main，阅读 README、examples、核心 engine、retriever、LM 封装和 Streamlit demo，并使用以下命令做语法编译检查，通过：

python3 -m compileall -q knowledge_storm examples/storm_examples examples/costorm_examples frontend/demo_light

没有实际运行 STORM pipeline，因为需要外部 LLM API key 和搜索 API key，直接跑会产生费用和外部请求。

13. 建议路线

  1. 第一阶段：复用方法，不引入依赖。把 STORM 方法写成 OpenClaw 报告模板：主题识别、生成分析视角、生成问题、搜索权威来源、合并来源、生成大纲、写报告、发布 GitHub Pages。
  2. 第二阶段：做一个 storm-style-report skill，触发条件是详细报告、项目分析、产业分析、公司分析。
  3. 第三阶段：实验性接入 knowledge-storm，隔离环境测试中文主题、引用质量、幻觉率、成本和运行时长。
  4. 第四阶段：和 Agent Reach 组合，让 Agent Reach 负责资料源，STORM-style pipeline 负责研究写作。

14. 总结

STORM 是一个很值得研究的项目。它的核心贡献不是“自动写文章”，而是把复杂研究拆成：多视角提问、检索增强对话、资料整理、大纲生成、引用长文写作。这个结构非常适合迁移到我们的报告系统。

但它不是开箱即用的中文 Deep Research 替代品。它偏研究框架，默认英文语境，依赖外部模型和搜索 API，生产化还需要来源质量、成本控制、中文资料、隐私和任务恢复等工程补强。

建议：不要直接把 STORM 当工具装进主工作流；先把它的方法论固化成 OpenClaw 的报告生成标准流程。这样收益最大，风险最小。

参考来源