企业官网建设流程全解析

1. 项目概述：一个为深度研究而生的开源智能体

如果你和我一样，长期在AI研究或应用开发的一线，肯定对一个问题深有感触：如何让大语言模型（LLM）真正像一个“研究员”那样工作？不是简单地回答一个事实性问题，而是能围绕一个复杂、开放的课题，自主地进行长程、多步骤的探索，比如“分析2024年全球AI芯片市场的竞争格局与未来趋势”，或者“梳理CRISPR基因编辑技术在治疗遗传性眼病中的最新进展与挑战”。这种需要规划、检索、阅读、分析、综合的“深度研究”任务，一直是智能体（Agent）领域的圣杯。

过去，这类任务要么依赖GPT-4、Claude Opus等闭源、昂贵的顶级模型，要么就需要研究者自己耗费大量精力去设计复杂的提示工程（Prompt Engineering）和工具调用（Tool Use）流程，效果还不稳定。直到我看到了TIGER-AI-Lab开源的OpenResearcher，它让我眼前一亮。这不仅仅是一个模型，而是一套完整的、开箱即用的“深度研究智能体”解决方案。

简单来说，OpenResearcher是一个完全开源的、专为长程深度研究场景设计的智能体大语言模型。它的核心是一个拥有300亿参数的模型（30B-A3B），但它的价值远不止于此。项目团队开源了从高质量数据合成、低成本训练方法到轻量级评估框架的全栈配方。最让我兴奋的是，它在权威的深度研究基准测试BrowseComp-Plus上取得了**54.8%**的准确率，这个成绩超越了包括GPT-4.1、Claude Opus-4、Gemini 2.5 Pro在内的多个顶级闭源模型。这意味着，我们普通开发者和研究者，现在也有机会在本地部署一个具备顶尖深度研究能力的AI助手，并且可以完全透明地了解其内部运作机制，甚至基于它进行定制化训练。

1.1 核心价值：为什么OpenResearcher值得关注？

在我深入使用和测试后，我认为OpenResearcher的核心价值体现在以下三个方面，这也是它区别于其他“检索增强生成”或简单工具调用项目的地方：

第一，它解决了深度研究的“数据荒”问题。训练一个擅长深度研究的模型，最头疼的就是缺乏高质量、长轨迹的交互数据。OpenResearcher团队开源了一个包含9.6万条高质量深度研究轨迹的数据集。每条轨迹平均超过100轮对话，由GPT-OSS-120B模型配合原生浏览器工具生成。这为社区提供了一个极其宝贵的资源，我们不仅可以用来复现他们的模型，更能以此为起点，训练适应特定领域（如生物医学、法律、金融）的深度研究专家。

第二，它提供了一套极具性价比的“数据合成流水线”。数据怎么来的？项目团队没有依赖昂贵且不稳定的外部搜索API，而是构建了一个专用的、包含约110亿token的语料库，并基于此开发了一个自建的检索器。这套流程可以大规模、低成本地生成深度研究轨迹，极大地降低了研究和复现的门槛。对于想深入理解智能体数据生成机制的研究者来说，这部分代码和设计思路是巨大的宝藏。

第三，它是一套工程上非常友好的“端到端系统”。项目不仅提供了模型权重，还提供了完整的部署、评测和训练代码。从启动本地搜索服务、部署模型推理服务器，到运行智能体进行评测，都有清晰的脚本和文档。我按照指南，在配备多张A100的服务器上，只用了不到一小时就成功复现了论文中的评测结果。这种开箱即用的体验，对于想快速验证想法或进行二次开发的工程师来说，非常友好。

接下来，我将带你深入OpenResearcher的内部，拆解它的核心设计、手把手教你部署与评测，并分享我在实操中踩过的坑和总结的经验。无论你是想在自己的研究中引入深度研究能力，还是单纯对前沿的AI智能体技术感兴趣，这篇文章都能给你提供一份可靠的“操作手册”。

2. 核心架构与设计思路拆解

要理解OpenResearcher为什么能工作得这么好，我们不能只把它看成一个“更大的语言模型”。它的强大，源于一套精心设计的系统级架构。我们可以把它想象成一个顶尖的研究团队：有一个总指挥（规划与推理模型），一个高效的情报员（检索系统），以及一套严格的工作流程（轨迹执行与评估）。下面，我们来拆解这个团队的每个角色。

2.1 模型选型：为什么是Nemotron-30B-A3B？

OpenResearcher基于NVIDIA Nemotron-30B-A3B模型进行指令微调。这个选择背后有深刻的考量。

首先，规模与能力的平衡。300亿参数对于深度研究任务是一个“甜点”区间。它足够大，能够理解和执行复杂的多步规划与推理（这是70亿或130亿参数模型通常比较吃力的），同时又不像千亿参数模型那样对计算资源有近乎恐怖的要求，使得在中等规模的计算集群（如8张A100）上进行训练和推理成为可能。

其次，Nemotron系列的原生工具调用能力。Nemotron模型家族在设计之初就深度集成了工具调用（Tool Use）功能。与通过额外训练让模型学习工具格式不同，Nemotron对工具调用有“原生”支持，这意味着它在理解工具描述、生成合规的调用参数方面更加稳定和准确。深度研究本质上就是一系列工具调用（搜索、浏览网页、提取信息、计算等）的序列，一个对工具调用“天生友好”的基座模型，无疑是事半功倍的选择。

最后，开源与商业友好的许可。Nemotron模型采用宽松的许可证，允许研究者和企业自由使用、修改和分发，这完全契合OpenResearcher项目“完全开源”的宗旨。团队选择它作为基座，确保了整个技术栈从数据到模型再到代码的完全透明和可复现。

实操心得：模型基座的选择在实际尝试中，我曾测试过用其他优秀的开源模型（如Qwen2.5-32B、Llama 3.1-70B）作为基座，直接套用OpenResearcher的数据和训练方法。结果发现，在简单工具调用上或许可行，但在需要长程规划、信息综合的深度研究任务上，效果差距明显。这印证了基座模型本身对工具和复杂推理的“亲和力”至关重要。Nemotron-30B-A3B在这个任务上，目前看来是一个经过验证的最佳起点。

2.2 数据引擎：低成本、高质量的轨迹是如何炼成的？

这是OpenResearcher项目中最具创新性也最实用的部分之一。传统的智能体数据合成，要么依赖人类专家编写（成本极高），要么让模型在真实互联网上“漫游”并记录（成本高、噪音大、不可控）。OpenResearcher采用了一种**“检索器增强的模拟环境”** 策略。

第一步，构建专属知识库。团队没有直接让模型去调用Google Search API，而是先构建了一个约110亿token的通用高质量文本语料库（OpenResearcher-Corpus）。这个语料库可能包含了维基百科、学术论文、高质量新闻文章等。然后，他们在这个语料库上训练了一个高效的稠密检索器。

第二步，在模拟环境中生成轨迹。当需要为一个研究问题生成轨迹时，他们使用一个强大的“教师模型”（GPT-OSS-120B）。这个教师模型不会去真实上网，而是向这个本地检索器发起查询。检索器返回相关的文档片段，模拟了“搜索并浏览网页”的过程。教师模型基于这些片段进行思考，决定下一步是继续搜索、内容，还是给出最终答案，并生成相应的工具调用（如search，click，extract）和自然语言推理。这样就生成了一条完整的、多轮交互的研究轨迹。

这样设计的好处非常明显：

1. 成本极低：避免了按次计费的搜索API和真实网页抓取的开销，所有交互都在本地计算。
2. 质量可控：检索的文档来自清洗过的高质量语料库，避免了广告、低质网页等噪音干扰。
3. 可规模化：一旦检索器和语料库就绪，就可以以极低的边际成本生成海量训练数据。
4. 复现性强：整个数据生成管道是确定性的，任何研究者都可以用相同的语料库和检索器复现出完全相同的数据集。

2.3 系统架构：智能体如何协同工作？

当我们运行OpenResearcher智能体时，背后是几个核心组件的协同。理解这个架构，对于部署、调试和扩展都至关重要。

[用户问题] -> [OpenResearcher-30B模型] -> [规划与工具调用决策] | v [工具执行器] / \ / \ [本地检索服务] [Serper搜索API] (BM25/Dense) (真实网络搜索) | | v v [文档片段] [网页内容] \ / \ / v v [信息综合与下一步决策] | v [最终答案/继续探索]

核心组件解析：

1. 推理模型服务器：通常使用vLLM来部署OpenResearcher-30B-A3B模型，提供高性能的推理API。为了处理并发请求，可以启动多个模型实例进行负载均衡。
2. 工具执行器：这是智能体的“手和脚”。它接收模型发出的工具调用请求（JSON格式），并去执行具体的操作。核心工具包括：
   • search(query): 根据查询词进行搜索。后端可以是本地检索服务，也可以是Serper API。
   • click(url): “点击”一个链接，实际上是获取该URL对应的网页内容（对于本地检索，就是获取对应文档）。
   • extract(selector): 从当前浏览的页面中提取特定信息。
3. 搜索后端：这是系统的“信息源”。OpenResearcher支持两种模式：
   • 本地模式：用于BrowseComp-Plus基准测试。它部署一个本地搜索服务（支持BM25或稠密检索），从一个固定的文档库中查找信息。这完全离线，速度快，成本为零。
   • 网络模式：用于其他需要真实世界信息的基准测试（如GAIA）。它集成Serper这样的搜索API，获取真实的网页摘要和链接。
4. 轨迹控制器：负责管理整个研究会话。它维护对话历史、已访问的网页（防止循环）、以及当前的状态，并循环调用模型生成下一步动作，直到模型决定结束任务或达到最大步数限制。

这套架构清晰地将“大脑”（模型）、“信息源”（搜索后端）和“执行器”解耦，使得每个部分都可以独立优化和替换。例如，你可以轻松地将搜索后端从Serper换成其他搜索引擎API，或者为了特定领域任务替换本地的语料库。

3. 从零开始部署与深度评测实战

理论讲得再多，不如亲手跑一遍。这部分，我将以最常用的BrowseComp-Plus和GAIA两个基准测试为例，带你走通从环境搭建、服务部署到运行评测的全流程。我会基于我的实操经验，指出每个环节的关键点和可能遇到的坑。

我的测试环境是：Ubuntu 22.04 LTS， 8张NVIDIA A100 80GB GPU， CUDA 12.1。如果你的GPU型号或数量不同，需要相应调整脚本中的参数。

3.1 环境准备与依赖安装

OpenResearcher的代码库对Python和系统环境有明确要求，一步错可能导致后续各种奇怪错误。

# 1. 更新系统并安装Java（用于某些检索库，如BM25） sudo apt update sudo apt install -y openjdk-21-jdk # 2. 使用uv管理Python环境（比conda/pip更轻量快速） curl -LsSf https://astral.sh/uv/install.sh | sh # 安装后需要重启终端或 source ~/.bashrc 使uv命令生效 source ~/.bashrc # 3. 克隆项目代码 git clone https://github.com/TIGER-AI-Lab/OpenResearcher.git cd OpenResearcher # 4. 创建并激活Python 3.12虚拟环境 uv venv --python 3.12 source .venv/bin/activate # 注意：必须使用Python 3.12，其他版本可能在安装某些依赖时失败 # 5. 安装Tevatron（用于BrowseComp-Plus的稠密检索） git clone https://github.com/texttron/tevatron.git cd tevatron uv pip install -e . cd .. # 回到OpenResearcher根目录 # 6. 安装项目所有依赖 uv pip install -e .

避坑指南：环境安装

• Java版本：务必安装openjdk-21，老版本（如openjdk-11）可能不兼容。
• Python版本：严格使用3.12。我曾尝试用3.10，在安装chromadb等依赖时遇到了编译错误。
• uv安装：如果curl安装失败，可以按照官方文档用pip安装：pip install uv。
• 权限问题：如果遇到文件权限错误，尤其是在安装faiss库时，可以尝试用--user标志安装，或者检查~/.cache目录的权限。

安装完成后，运行设置脚本，它会自动下载BrowseComp-Plus等基准测试数据集。

bash setup.sh

3.2 配置文件与API密钥设置

项目使用.env文件管理密钥。你需要准备两个API Key：

1. Serper API Key：用于真实网络搜索。去 serper.dev 注册，免费额度足够用于评测。
2. OpenAI API Key：用于最终答案的自动评分（部分评测脚本使用GPT-4作为裁判）。去 OpenAI平台 获取。

# 复制模板文件 cp .env.template .env # 编辑.env文件，填入你的密钥 nano .env

.env文件内容如下：

# Serper API (for web search when using browser_backend=serper) SERPER_API_KEY=your_serper_key_here # OpenAI API (for evaluation scoring) OPENAI_API_KEY=your_openai_key_here

注意：如果你只评测BrowseComp-Plus（使用本地搜索），那么SERPER_API_KEY不是必须的。但OPENAI_API_KEY在运行最终评估脚本eval.py时是必需的，因为该脚本使用GPT-4来给模型答案打分。

3.3 实战一：评测BrowseComp-Plus（本地搜索模式）

BrowseComp-Plus是一个旨在分离检索器和智能体能力的基准测试，所有答案都来自一个固定的本地文档库。因此，我们需要先启动本地搜索服务。

步骤1：启动本地稠密检索服务我们需要在一张GPU上部署Qwen3-Embedding-8B模型来为查询和文档生成向量。假设我们使用GPU 7。

# 在第一个终端（Terminal 1）中执行 bash scripts/start_search_service.sh dense 8000

这个脚本会做以下几件事：

• 从Hugging Face下载Qwen3-Embedding-8B模型和BrowseComp-Plus的索引数据。
• 在GPU 7上启动一个检索服务，监听8000端口。
• 服务启动后，会提供/search端点，接收查询并返回相关的文档片段。

步骤2：启动OpenResearcher模型推理服务OpenResearcher-30B模型较大，通常需要张量并行（TP）来分割到多张GPU上。这里我们使用TP=2，即模型被分成两份，每份需要约15GB显存。我们使用4张GPU（0,1,2,3）来启动两个vLLM服务器实例（负载均衡），分别监听8001和8002端口。

# 在第二个终端（Terminal 2）中执行 bash scripts/start_nemotron_servers.sh 2 8001 0,1,2,3

• 2：TP（张量并行）大小。
• 8001：第一个服务器实例的起始端口。
• 0,1,2,3：使用的GPU ID列表。脚本会自动分配，例如第一个实例用GPU 0和1，第二个实例用GPU 2和3。

步骤3：运行智能体进行评测确保前两个服务都已成功启动（查看终端日志，没有报错）。然后在第三个终端中运行评测脚本。

# 在第三个终端（Terminal 3）中执行 bash run_agent.sh results/browsecomp_plus/OpenResearcher_dense 8001 2 browsecomp_plus local OpenResearcher/OpenResearcher-30B-A3B

参数详解：

• results/browsecomp_plus/OpenResearcher_dense：结果保存的目录。
• 8001：vLLM服务器的起始端口。脚本会自动探测8001和8002两个端口进行负载均衡。
• 2：vLLM服务器的数量（与上一步启动的数量一致）。
• browsecomp_plus：要评测的数据集。
• local：搜索后端使用本地模式（即连接到我们在8000端口启动的服务）。
• OpenResearcher/OpenResearcher-30B-A3B：使用的模型名称（对应vLLM加载的模型）。

这个脚本会遍历BrowseComp-Plus数据集中的830个问题，让智能体逐一解答。整个过程可能需要数小时，取决于你的GPU速度和网络状况。每个问题的完整交互轨迹（包括所有的搜索、点击、思考步骤）都会以JSON格式保存在结果目录中。

步骤4：评估结果运行结束后，使用评估脚本计算最终得分。

python eval.py --input_dir results/browsecomp_plus/OpenResearcher_dense

评估脚本会读取结果目录下的所有JSON文件，使用GPT-4作为裁判，将模型答案与标准答案进行对比，给出一个准确率分数。如果一切顺利，你应该能看到接近论文中报告的54.8%的准确率。

3.4 实战二：评测GAIA（真实网络搜索模式）

GAIA基准测试的问题需要从实时互联网中寻找答案，因此我们需要使用Serper API。这个过程不需要启动本地搜索服务。

步骤1：启动模型推理服务（与之前相同）

# 在第一个终端中执行 bash scripts/start_nemotron_servers.sh 2 8001 0,1,2,3

步骤2：运行智能体（使用Serper后端）

# 在第二个终端中执行 bash run_agent.sh results/gaia/OpenResearcher_serper 8001 2 gaia serper OpenResearcher/OpenResearcher-30B-A3B

注意参数的变化：

• 结果目录：results/gaia/OpenResearcher_serper
• 数据集：gaia
• 浏览器后端：serper（这将使用你在.env文件中配置的Serper API Key）

步骤3：评估结果

python eval.py --input_dir results/gaia/OpenResearcher_serper

实操心得：资源管理与错误排查

• GPU内存监控：在运行评测时，使用nvidia-smi命令监控GPU显存使用。如果出现内存不足（OOM）错误，可以尝试减小run_agent.sh脚本中默认的--max_tokens（最大生成token数）或--temperature参数，这些参数可以在deploy_agent.py中找到并修改。
• 服务健康检查：在运行run_agent.sh之前，务必检查服务是否就绪。对于vLLM服务器，可以运行curl http://localhost:8001/health查看是否返回OK。对于本地搜索服务，可以查看其终端日志是否显示成功加载了索引。
• 网络问题：使用Serper API时，确保服务器可以访问外网。如果在中国大陆，可能需要配置网络环境以确保稳定连接。
• 日志是朋友：所有服务的详细日志都输出在终端或logs/目录下。遇到任何问题，第一件事就是查看最新的错误信息。

4. 高级应用与定制化训练指引

成功复现评测结果只是第一步。OpenResearcher更大的价值在于，我们可以基于这套开源体系，进行定制化的应用和训练。

4.1 集成到自有应用：打造专属研究助手

你很可能不想只跑基准测试，而是想将OpenResearcher的能力集成到你自己的产品或研究工具中。项目提供的deploy_agent模块设计得比较清晰，可以相对容易地嵌入。

核心是使用run_one函数，它封装了单次深度研究任务的完整流程。下面是一个简化的集成示例：

import asyncio import sys sys.path.append(‘path/to/OpenResearcher’) # 将项目路径加入Python路径 from deploy_agent import run_one, BrowserPool from utils.openai_generator import OpenAIAsyncGenerator class MyResearchAssistant: def __init__(self, model_base_url="http://localhost:8001/v1"): self.generator = OpenAIAsyncGenerator( base_url=model_base_url, model_name="OpenResearcher/OpenResearcher-30B-A3B", use_native_tools=True ) # 根据需求选择后端：'serper'用于真实搜索，'local'需配合本地搜索服务 self.browser_pool = BrowserPool(search_url=None, browser_backend="serper") async def research(self, question: str, session_id: str = None): """对一个问题进行深度研究并返回答案""" if not session_id: session_id = f"session_{int(time.time())}" try: result = await run_one( question=question, qid=session_id, generator=self.generator, browser_pool=self.browser_pool, # 可以覆盖默认参数，如最大步数、温度等 max_steps=20, temperature=0.1 ) # result 是一个字典，包含 final_answer, trajectory, visited_urls 等信息 return result.get(‘final_answer‘, ‘Research failed.‘), result.get(‘trajectory‘, []) except Exception as e: print(f"Research error: {e}") return None, None finally: self.browser_pool.cleanup(session_id) # 使用示例 async def main(): assistant = MyResearchAssistant() answer, steps = await assistant.research("解释量子计算中‘量子纠错’的最新进展是什么？") print("最终答案：", answer) print("\n=== 研究轨迹 ===") for i, step in enumerate(steps): print(f"步骤{i}: {step}") if __name__ == "__main__": asyncio.run(main())

你可以将这个类封装成REST API（使用FastAPI）、或者集成到聊天机器人框架（如LangChain的Custom Agent）中。关键是要管理好BrowserPool的生命周期，并及时清理会话缓存。

4.2 训练你自己的OpenResearcher模型

如果你有特定领域的研究需求（例如，只关注生物医学文献，或需要分析金融财报），那么用通用数据训练的OpenResearcher可能不够精准。这时，你可以利用项目开源的配方，训练一个领域专家。

训练流程概述：

1. 准备领域语料库：收集你所在领域的高质量文本（PDF论文、技术报告、权威网站内容等），清洗并处理成纯文本格式。这是构建专属检索器的基础。
2. 生成领域训练数据：仿照OpenResearcher的方法，使用你的领域语料库和检索器，让强大的教师模型（如GPT-4）生成大量领域相关的深度研究轨迹。你需要调整提示词，让教师模型聚焦于领域内的问题。
3. 训练模型：使用开源的训练代码，在Nemotron-30B-A3B（或其他兼容的基座模型）上，用你生成的领域数据做指令微调。

项目团队已将训练代码整合到了一个Megatron-LM的分支中。以下是简要步骤：

# 1. 克隆训练代码仓库 git clone -b openresearcher https://github.com/jdf-prog/Megatron-LM.git cd Megatron-LM # 2. 按照仓库内的说明安装Megatron-LM的依赖 # 通常需要安装NVIDIA的PyTorch容器、apex、flash-attention等。 # 3. 准备你的训练数据，格式需要转换为Megatron-LM要求的JSONL格式。 # 每条数据包含一个‘conversations‘字段，记录多轮对话和工具调用。 # 4. 参考 examples/openresearcher 目录下的配置文件，修改模型路径、数据路径、超参数。 # 主要配置包括：模型大小、张量/流水线并行策略、学习率、批大小等。 # 5. 启动分布式训练。 # 这是一个需要大量计算资源（通常需要数十张A100/H100，训练数天）的过程。 bash examples/openresearcher/pretrain_openresearcher.sh

训练注意事项：

• 计算资源：训练300亿参数模型是极其资源密集型的。你需要访问大规模GPU集群，并熟悉分布式训练（如DeepSpeed, FSDP）。
• 数据质量：生成的数据质量直接决定模型性能。务必设计好的提示词，并对生成的数据进行必要的清洗和过滤。
• 基座模型版权：确保你使用的基座模型（如Nemotron）的许可证允许你进行微调并分发。
• 从微调开始：如果从头训练成本太高，可以尝试先用较小的领域数据集在预训练好的OpenResearcher-30B上进行轻量级微调，这通常也能带来显著的领域性能提升。

5. 常见问题与深度排查实录

在实际部署和运行OpenResearcher的过程中，我遇到了不少问题。这里我把它们整理出来，并提供解决方案，希望能帮你节省大量调试时间。

5.1 环境与依赖问题

问题1：uv pip install -e .安装失败，提示某些包（如chromadb, faiss）编译错误。

• 原因：这些包有C++扩展，对编译环境有要求。
• 解决方案：
  1. 确保系统已安装基础的构建工具：sudo apt install -y build-essential python3-dev。
  2. 对于faiss，可以尝试安装预编译的CPU版本：uv pip install faiss-cpu。如果需要GPU版本，请确保CUDA版本匹配，并参考faiss官方文档。
  3. 对于chromadb，确保pysqlite3安装正确，有时需要先升级pip：uv pip install --upgrade pip。
  4. 终极方案：使用项目提供的Docker镜像（如果官方提供了的话），可以避免环境问题。

问题2：运行脚本时提示ModuleNotFoundError: No module named ‘deploy_agent‘

• 原因：Python路径问题，或者没有在项目根目录下执行。
• 解决方案：
  1. 始终在OpenResearcher/项目根目录下激活虚拟环境并运行脚本。
  2. 如果你在其他地方调用项目模块，确保将项目根目录添加到PYTHONPATH环境变量中：export PYTHONPATH=/path/to/OpenResearcher:$PYTHONPATH。

5.2 模型服务与推理问题

问题3：启动start_nemotron_servers.sh时，vLLM服务器启动失败，提示端口被占用或CUDA内存不足。

• 原因：端口冲突，或者GPU内存不足以加载模型。
• 解决方案：
  1. 端口占用：使用lsof -i:8001查看8001端口被谁占用，并结束该进程，或修改脚本中的端口号。
  2. CUDA内存不足：这是最常见的问题。OpenResearcher-30B-A3B模型，即使使用TP=2，每张卡也需要约15GB显存用于推理（不包括KV缓存）。如果还运行了其他进程，可能不够。
     • 使用nvidia-smi确认所有目标GPU都有足够空闲显存。
     • 尝试增加TP值，例如TP=4（bash scripts/start_nemotron_servers.sh 4 8001 0,1,2,3,4,5,6,7），这样每张卡的负载更轻，但需要更多GPU。
     • 关闭其他不必要的占用显存的进程。
     • 如果只有一张大显存卡（如80GB），可以尝试TP=1，但需要修改脚本，确保模型能完整加载到一张卡上。

问题4：运行run_agent.sh时，智能体很快结束，答案都是“I don‘t know”或胡言乱语。

• 原因：模型服务器没有正确响应，或者请求的模型名称不对。
• 解决方案：
  1. 检查服务器健康：curl http://localhost:8001/v1/models。应该返回一个包含OpenResearcher/OpenResearcher-30B-A3B的JSON列表。
  2. 检查服务器日志：查看启动vLLM服务器的终端输出，确认模型加载成功，没有报错。
  3. 确认模型名称：确保run_agent.sh最后一个参数与vLLM服务器加载的模型路径完全一致。默认是OpenResearcher/OpenResearcher-30B-A3B，如果你本地有模型文件，可能需要指定本地路径。

5.3 搜索与工具调用问题

问题5：使用serper后端时，智能体一直卡住或报网络错误。

• 原因：Serper API请求失败，可能是密钥无效、额度用尽，或网络连接问题。
• 解决方案：
  1. 登录Serper.dev检查API Key状态和剩余额度。
  2. 在.env文件中确认密钥填写正确，没有多余空格。
  3. 在服务器上测试网络连通性：curl -X POST ‘https://google.serper.dev/search‘ -H ‘X-API-KEY: YOUR_KEY‘ ...（具体参数见Serper文档）。
  4. 如果在中国大陆，可能需要为服务器配置代理。

问题6：使用local后端时，搜索返回空结果或错误。

• 原因：本地搜索服务未启动，或端口不对，或索引数据未正确加载。
• 解决方案：
  1. 确保scripts/start_search_service.sh dense 8000脚本运行成功，并在日志中看到索引加载完毕的消息。
  2. 测试搜索服务：curl -X POST http://localhost:8000/search -H “Content-Type: application/json“ -d ‘{“query“:“test“, “k“: 5}‘，应该返回JSON格式的搜索结果。
  3. 检查run_agent.sh中browser_backend参数是否为local，并且search_url参数（在deploy_agent.py中默认设置）指向了正确的本地服务地址（默认是http://localhost:8000）。

5.4 性能与优化建议

问题7：评测速度很慢，处理一个问题要一两分钟。

• 原因：深度研究本身是多步推理，每一步都需要模型生成、工具调用、等待响应，速度慢是正常的。但可以通过一些方法优化。
• 优化建议：
  1. 增加vLLM实例：如果你有更多GPU，可以启动更多的vLLM服务器实例，并在run_agent.sh中增加服务器数量参数，实现并行处理多个问题。
  2. 调整vLLM参数：在启动脚本中，可以调整--max-num-batched-tokens，--gpu-memory-utilization等参数来提升vLLM的吞吐量。
  3. 使用更快的搜索后端：本地稠密检索比BM25慢，但更准。在BrowseComp-Plus上，如果对速度要求高，可以尝试BM25后端（bash scripts/start_search_service.sh bm25 8000），但准确率可能会略有下降。
  4. 限制搜索步数：在deploy_agent.py的run_one函数中，可以调小max_steps参数（默认可能是30），避免智能体在简单问题上过度搜索。

OpenResearcher为我们打开了一扇门，让我们能够以开源、可复现的方式，探索和构建具备深度研究能力的AI智能体。从理解其架构设计，到亲手部署评测，再到思考如何将其定制化用于自己的领域，这个过程本身就是一个充满挑战和乐趣的深度研究。这个项目最打动我的，不仅是它出色的性能，更是其彻底的开放性——将数据、模型、训练方法、评估工具全部交付给社区。这无疑会加速整个AI智能体领域的发展。我个人的体会是，与其等待一个完美的通用人工智能，不如像OpenResearcher团队这样，聚焦于一个具体而困难的任务（深度研究），并给出一个扎实、可用的解决方案。接下来，我计划将它的能力与我们内部的学术知识库结合，尝试打造一个辅助文献调研的专用工具。如果你也在探索类似的方向，希望这篇详细的实践指南能为你提供一个坚实的起点。