如果你今天想让 AI 帮你做深度研究，大概率会用 ChatGPT Deep Research、Claude 或 Perplexity。
它们确实都很强。
但问题也很明显：它们都是闭源 SaaS，跑在别人的云上。你的查询、内部文档、连接的数据源，都会进入对方服务器。
对很多团队来说，这就是默认交换条件：
要么接受。 要么别用 AI 做严肃研究。
但其实还有第三种选择：
搭一套完全开源、可自托管的 Deep Research Stack。
核心是三个工具：
Onyx 负责检索。 CrewAI 负责编排。 Voxtral 负责语音。
这套系统可以从语音提问开始，到生成带引用的研究报告，再到语音朗读结果，完整跑通。
为什么自托管很重要？
主流 AI 研究工具基本都是闭源云服务，这会带来几个现实问题。
你的问题会发到它们服务器。 你连接的数据，会在它们基础设施里被索引。 日志、留存、审计规则，由它们决定。 价格和额度，也会按它们的节奏变化。
对普通用户来说，这可能还能接受。
但对受监管行业、处理敏感 IP 的团队，或者有数据驻留要求的公司来说，这不是小事。
AI 辅助研究之所以迟迟进不了很多严肃工作流，原因就在这里：
工具很好，但数据不敢放出去。
除非，你能把整套研究系统跑在自己的基础设施上。
现有研究工具为什么容易坏？
很多 AI 研究工具，本质上只做一轮：
搜索。 收集结果。 交给 LLM 写报告。
浅问题还行。
但一旦问题需要跨来源综合、识别矛盾、进行多跳推理，它就容易崩。
常见问题包括：
发现两个互相矛盾的来源，却只选一个继续写，矛盾没有暴露。 两个来源表达同一件事，却被当成两份独立证据。 关键连接事实没被检索到，因为关键词搜索不理解 “cloud migration” 和 “moving our PostgreSQL cluster to AWS” 是同一类问题。
这些不是边缘情况。
这就是现实研究任务的常态。
根本原因是：研究不是一个单一任务。
好的 Deep Research 需要什么？
不管用什么工具，真正可靠的深度研究至少需要五件事。
第一，阶段分离。
收集、分析、写作之间要有硬边界。每个阶段只接收上一阶段整理后的干净输出。
第二，检索要会推理。
关键词搜索太脆。单纯向量相似度在多跳问题上也容易断。你需要并行 query 变体、智能重组，以及 LLM 选择步骤，再进入综合。
第三，循环中要有反思。
静态计划遇到新发现时会失效。系统应该能根据发现调整方向，同时持续跟踪原始计划覆盖情况。
第四，统一搜索公开和内部资料。
研究层需要同时查开放网络和内部知识库，并且按文档权限控制访问。
第五，语音层。
能说出问题，比打字更自然。能听报告，也比盯着长文读更轻松。
Onyx：开源检索层
Onyx 是一个开源 AI 平台，围绕 RAG、Web 搜索、代码执行、Deep Research 和自定义 Agent 构建。
它可以完全自托管，所以数据不用离开你的基础设施。
而且能力并不弱。
Onyx 曾提交到 DeepResearch Bench，这是一个独立学术 benchmark，包含 22 个领域、100 个博士级研究任务，评估报告质量和引用准确性。
结果它排到第一，超过 OpenAI Deep Research、Gemini 2.5 Pro 和 Perplexity Deep Research。
Onyx 团队总结的提示哲学很直接：
“研究时，宁可彻底，也不要只是显得有帮助。”
这句话也直接体现在架构里。
分享一个正版GPT5.5 目前 0.2 倍率, https://api.aidazhi.com/，注册后把用户名发到私信里面，即可帮领 5 美元测试额度。
三个阶段，而不是一个循环
Onyx 的研究流程分成三个阶段。
第一阶段：澄清。
对短问题或模糊问题，最多提出 5 个针对性问题。问题足够详细时，会自动跳过。
第二阶段：规划。
把查询拆成最多 6 个探索方向。关键点是：planner 没有工具权限，所以它只做计划，不直接生成答案。
第三阶段：迭代执行。
Orchestrator 和 research agents 交替运行，最多 8 轮，每轮最多并行派出 3 个 agent。
这里有两个关键隔离：
Orchestrator 不直接搜索。 Research agents 看不到完整查询和完整计划。
这样能强制每个任务 brief 自洽，也能减少上下文污染。
自适应研究策略
Onyx 不会死守最初计划。
每次派发任务之间，它都会做一次强制 reflection，并输出结构化结果：
已经覆盖了什么。 还剩哪些空白。 出现了哪些新方向。 继续跑是否还能带来新信息。
这一步每次都会执行。
所以它更像研究员，而不是简单检索器。
六阶段检索管线
每个研究 agent 在综合前，都会先跑一套检索流程。
第一，query generation。
生成并行查询，包括语义改写、关键词变体和更宽泛搜索。多部分问题会自动拆分。
第二，search and recombination。
使用混合索引，也就是 vector + BM25。结果通过 Reciprocal Rank Fusion 合并，并把相邻 chunk 拼接起来。
第三，LLM selection。
LLM 会审查所有 chunk，只保留真正相关内容。跳过这一步，幻觉就容易进来。
第四，context expansion。
对每个选中的文档，LLM 会读取周边 chunk，决定需要扩展多少上下文。
第五，prompt building。
把选中的内容、引用和对话历史组装起来。
第六，answer synthesis。
生成带 inline citations 的 grounded answer，每条引用都能追溯到来源。
引用完整性
Onyx 的 agent 在写中间报告时，就会内联引用来源。
多个并行 agent 的引用会被合并、重新编号，变成统一引用集。
最终报告里的每个关键说法，都能追溯到具体来源文档。
这点很重要。
研究报告最怕的不是写得不漂亮，而是看起来有理，实际没证据。
内部资料也能接入
Onyx 支持 40 多种企业数据源，比如 Slack、Confluence、Jira、GitHub、Salesforce、Google Drive、SharePoint、Notion、Zendesk、HubSpot、Gong 等。
重点不是能不能连接。
而是索引在哪里发生。
Onyx 会在你的基础设施上持续预索引内容、metadata 和权限，并保持接近实时同步。
这带来的结果是：
一个查询可以同时覆盖开放网络和内部资料。 用户只能看到自己有权限访问的文档。 权限会自动从各数据源同步。 内部数据不会被送到第三方云上索引或存储。
CrewAI：编排层
Onyx 负责检索。
CrewAI 负责协调。
很多开发者一开始会写成一个 agent 加三个连续任务，共用一个越来越长的上下文窗口。
问题是：
Writer 可能在 Analyst 完成前就开始写。 搜索噪音会流进最终报告。 原始材料被反复解释，最后失真。
CrewAI 用三个东西解决这个问题：
Flows：把独立 Crews 串起来，每一层只接收上一层的干净输出。 Skills：通过SKILL.md在运行时给 agent 注入领域指令。 MCP Integration：通过mcps字段直接把 MCP server 接到 agent 上。
Onyx 接入也很简单：
from crewai import Agent researcher_agent = Agent( role="Senior Research Analyst", goal="Gather information on research query with source URLs", backstory="You are a disciplined analyst. Record every source URL.", mcps=[ f"{ONYX_MCP_URL}?token={ONYX_TOKEN}" ] )Researcher agent 会立刻获得三个工具：
搜索知识库。 搜索网页。 抓取任意 URL 的完整页面内容。
不需要手动接工具。schema 会缓存，连接按需建立，服务器不可用时也能优雅失败。
Voxtral：语音层
每个研究工作流都有一个摩擦点：
键盘。
AI 工具里的语音通常只是外挂：Whisper 做输入，普通 TTS 做输出，输入输出模型还不是一套。
Voxtral 不一样。
它是 Mistral 的原生音频模型家族，从一开始就为语音理解和生成设计，同一家族同时处理输入和输出。
它能带来两个变化：
第一，语音输入。
你直接说问题，转录结果进入研究管线。
第二，报告朗读。
完整 Markdown 报告可以被自然语音读出来。长报告很多时候听比读更舒服。
整体怎么跑？
完整流程是这样：
输入方式可以是打字、语音，或者上传 PDF。
Researcher Agent 通过 Onyx MCP 搜索网页和内部文档。
Analyst Agent 去重、标记矛盾、整理发现。
Report Writer Agent 生成结构化、带引用的 Markdown 报告。
最后点击 “Play Report”，用 Voxtral TTS 朗读报告。
为什么要三个 mini-crews？
最自然的设计，是一个 Crew 里放三个连续任务。
但不要这么做。
跨阶段共享上下文会损坏事实。Onyx 团队把这叫 “deep frying”。
事实被重新解释。 矛盾被抹平。 来源材料到 Writer 手里时，已经变味。
更好的方式是 Flow：三个独立 Crews，每个只接收上一阶段整理后的结果。
Researcher Agent：连接 Onyx，搜索网页、读取 URL、检索 PDF，每个发现都带 citation。
Analyst Agent：处理原始 findings，去重、合并同义信息、标记明确矛盾，并按主题分组。
Report Writer Agent：把结构化总结写成带引用的 Markdown 报告，并用 CrewAI Skill 保持格式一致。
目录可以这样：
deep-research-report/ ├── SKILL.md ├── scripts/ └── references/SKILL.md使用 YAML front matter 和 Markdown body：
--- name: deep-research-report description: > Guidelines for writing high-quality, publication-ready deep research reports. Covers structure, tone, evidence standards, and formatting rules. metadata: author: deep-research-agent version: "1.0" --- Instructions for the agent go here.当 skill 被激活时，这段 Markdown 会被注入到 agent prompt 里。
你最终得到什么？
这套方案的重点，不只是“开源工具终于追上大厂”。
真正的重点是：
你可以在自己可检查、可自托管、可修改的基础设施上跑 Deep Research。
Onyx 提供检索和引用完整性。 CrewAI 强制阶段隔离。 Voxtral 提供原生语音交互。
组合起来，你得到的是：
能力：研究质量有竞争力，甚至在 benchmark 上领先。 控制：查询和内部数据留在自己的基础设施里。 透明：代码开源，可阅读、可审计、可扩展。
最后：
精通 React 面试：从零到中高级(针对面试回答)
CSS终极指南
Vue 设计模式实战指南
20个前端开发者必备的响应式布局
深入React:从基础到最佳实践完整攻略
python 技巧精讲
React Hook 深入浅出
CSS技巧与案例详解
vue2与vue3技巧合集
