1. 项目概述一个为深度研究而生的智能搜索代理框架如果你曾经尝试过让AI帮你做一次深度的网络调研比如“对比2024年主流大语言模型在代码生成任务上的表现”你可能会发现一个尴尬的局面要么它基于过时的知识库给你一些陈旧的信息要么它给出的回答虽然流畅但缺乏具体的数据来源和细节支撑你无法判断其可信度。这正是当前AI应用的一个痛点——如何让AI不仅“知道”还能“求证”和“整合”。今天要聊的II-Researcher就是为了解决这个问题而生的一个开源框架。它不是一个简单的聊天机器人而是一个智能的、可深度搜索的代理Agent框架核心目标是让AI能够像人类研究员一样主动规划搜索策略、爬取并理解网页内容、进行多步推理最终生成一份带有详细引用来源的综合性报告。简单来说II-Researcher是一个**“AI驱动的自动化研究助理”。你给它一个复杂的问题它会自动拆解成多个搜索子任务调用Tavily或SerpAPI等搜索引擎去获取信息然后用Firecrawl等工具精准抓取网页正文再通过大语言模型LLM进行内容提炼、交叉验证和逻辑推理最后把所有信息整合成结构清晰的答案。整个过程是异步并行的效率很高。它特别适合需要事实核查、市场调研、竞品分析、学术文献综述**等场景。无论是开发者想快速了解某个技术栈的生态还是分析师需要一份行业动态简报都可以通过这个框架自动化完成信息收集和初步分析的重度工作。2. 核心架构与设计哲学为什么是“智能搜索代理”2.1 从“检索增强生成”到“代理增强研究”传统的RAG检索增强生成方案其工作流通常是线性的用户提问 - 向量库检索相似片段 - LLM基于片段生成答案。这个模式对于已知、静态的知识库非常有效但对于瞬息万变的互联网信息尤其是需要主动探索、发现未知关联的“研究型”问题就显得力不从心了。RAG的检索是被动的它依赖于预先构建好的索引。II-Researcher代表的是一种更高级的范式我称之为“代理增强研究”。它的核心设计哲学是赋予LLM“行动力”和“反思力”。在这个框架中LLM不再仅仅是文本生成器而是一个决策中心。它可以根据当前的研究目标和已获得的信息动态决定下一步做什么是应该换一个关键词重新搜索还是需要深入爬取某个特定URL的内容或者是已有的信息存在矛盾需要进行反思和验证这种基于目标的、循环往复的“规划-执行-观察-反思”闭环正是智能体Agent的典型特征。2.2 框架的核心组件与工作流拆解要理解II-Researcher我们可以把它拆解成几个核心的“器官”大脑决策与规划层由配置的LLM如GPT-4o, DeepSeek-R1担任。它负责理解复杂问题并将其分解成一系列可执行的搜索查询Search Query。例如对于“对比LLM的代码生成能力”这个问题它可能会规划出“GPT-4代码生成基准测试”、“Claude 3.5 Sonnet编程表现”、“开源模型如CodeLlama评测”等多个并行的搜索子任务。在Pipeline或Reasoning模式下这个大脑还会进行多步推理判断信息的充分性和可靠性。手脚行动与执行层这是与外界交互的部分主要包括两类工具搜索提供者Search Provider如Tavily和SerpAPI。Tavily是为AI优化过的搜索API返回的结果已经是经过清洁和摘要处理的适合快速获取概览。SerpAPI则提供更原始、更丰富的谷歌搜索结果包括视频、新闻等卡片信息灵活性更高。框架允许你根据需求配置。内容抓取提供者Scraper Provider如Firecrawl、Browser可能是Playwright/Selenium、BeautifulSoup4BS4。当搜索返回一个URL列表后框架需要获取这些网页的详细内容。Firecrawl是一个专门为AI设计的爬虫服务能很好地处理现代JavaScript渲染的页面并提取核心内容避免广告和导航栏的干扰。BS4则是一个经典的HTML解析库轻量但功能相对基础。消化系统信息处理与压缩层互联网信息是海量且冗余的。直接把所有爬取的原始文本动辄数万字扔给LLM会迅速耗尽上下文窗口且成本高昂。因此II-Researcher内置了内容压缩Context Compression功能。它可以使用一个较小的、高效的LLM如配置中的gemini-lite或嵌入模型如text-embedding-3-large来对抓取的内容进行摘要、去重和关键信息提取只保留与研究方向最相关的高价值信息大幅降低传递给主推理模型的数据量。协作网络编排与通信层整个系统通过BAMLBoundary AI的模型语言来定义和约束LLM的输入输出结构确保数据流的规范性。同时框架支持MCPModel Context Protocol这是一个由Anthropic提出的协议允许像II-Researcher这样的工具服务器轻松集成到Claude Desktop等客户端中让你能在熟悉的聊天界面里直接调用这个强大的研究能力。实操心得组件选型的背后逻辑为什么同时提供Tavily和SerpAPI这其实是成本和质量的权衡。Tavily结果更“干净”适合快速生成初步报告但其搜索深度和结果多样性可能不如原生谷歌通过SerpAPI获取。对于严肃的研究我通常先用Tavily做广度探索锁定关键信息来源后再针对特定网站用SerpAPI获取更全面的搜索结果并结合Firecrawl进行深度抓取。Firecrawl虽然是商业服务但其在反爬处理和内容提取上的准确性远比我们自己写一个Playwright脚本要省心得多对于生产级应用这个投入是值得的。3. 从零开始部署与深度配置指南纸上谈兵终觉浅我们直接上手把一个完整的II-Researcher环境跑起来。这里我会选择功能最全面的Docker Compose部署方案因为它能一次性搞定前端、后端和LLM代理服务最适合体验和开发。3.1 基础环境与密钥准备首先你需要准备好几个关键的API密钥这是整个系统的“燃料”LLM服务密钥框架本身不绑定特定厂商通过LiteLLM代理。你需要至少一个OPENAI_API_KEY: 用于调用GPT-4o等OpenAI模型或作为LiteLLM的通用密钥。DEEPSEEK_API_KEY: 如果你想使用DeepSeek-R1这个强大的推理模型。ANTHROPIC_API_KEY: 如需使用Claude系列模型。建议初期可以只配置OPENAI_API_KEY并用OpenRouter作为统一网关。OpenRouter聚合了多家模型一个密钥就能调用GPT、Claude、Gemini等非常方便。搜索与爬虫服务密钥TAVILY_API_KEY: 从Tavily官网注册获取。它有免费额度足够个人测试。SERPAPI_API_KEY: 从SerpAPI官网注册获取。同样有免费额度。FIRECRAWL_API_KEY: 从Firecrawl官网注册获取。这是必须的如果你计划使用它作为爬虫提供商强烈推荐。可选OpenRouter密钥如果你想像官方示例那样通过OpenRouter来统一调用多模型就需要去OpenRouter官网注册并获取API密钥。拿到这些密钥后我们不要直接硬编码在命令里。最佳实践是创建一个.env文件来管理。在项目根目录下执行# 复制环境变量示例文件 cp .env.example .env # 使用你喜欢的编辑器如nano, vim, VS Code编辑.env文件 nano .env在你的.env文件中你需要填充如下关键配置以下为示例请替换为你的真实密钥# 核心API密钥 - 必须配置 OPENAI_API_KEYsk-your-openai-key-here TAVILY_API_KEYtvly-your-tavily-key-here SERPAPI_API_KEYyour-serpapi-key-here FIRECRAWL_API_KEYfc-your-firecrawl-key-here # 如果你想用DeepSeek-R1取消注释并填写 # DEEPSEEK_API_KEYyour-deepseek-key-here # 如果你想用OpenRouter取消注释并填写 # OPENROUTER_API_KEYyour-openrouter-key-here # API端点配置 - 指向我们将要启动的LiteLLM代理 OPENAI_BASE_URLhttp://litellm:4000 # Docker Compose中服务名是litellm # 内容压缩配置 - 优化性能与成本的关键 COMPRESS_EMBEDDING_MODELtext-embedding-3-large COMPRESS_SIMILARITY_THRESHOLD0.3 # 相似度阈值高于此值的文本块将被合并去重 COMPRESS_MAX_OUTPUT_WORDS4096 # 压缩后最大输出字数适配主流模型上下文 COMPRESS_MAX_INPUT_WORDS32000 # 单次压缩的最大输入字数防止内存溢出 # 搜索与抓取策略配置 SEARCH_PROVIDERserpapi # 可选: serpapi 或 tavily SCRAPER_PROVIDERfirecrawl # 可选: firecrawl, bs, browser, tavily_extract # 超时与性能设置 - 根据网络情况调整 SEARCH_PROCESS_TIMEOUT300 # 整个搜索进程超时秒 SEARCH_QUERY_TIMEOUT20 # 单次搜索查询超时秒 SCRAPE_URL_TIMEOUT30 # 单URL抓取超时秒 STEP_SLEEP100 # 步骤间延迟毫秒避免请求过快被封3.2 配置LiteLLM构建统一的模型网关II-Researcher通过LiteLLM来调用各种大模型。LiteLLM就像一个智能路由器将标准的OpenAI API格式的请求转发到正确的模型提供商OpenAI、Anthropic、DeepSeek等或本地模型。在Docker部署中我们需要为LiteLLM准备一个配置文件。在项目根目录创建一个名为litellm_config.yaml的文件model_list: # 嵌入模型 - 用于内容压缩中的语义去重 - model_name: text-embedding-3-large litellm_params: model: text-embedding-3-large api_key: ${OPENAI_API_KEY} # 从环境变量读取 # 主推理模型 - 用于策略规划和报告撰写 - model_name: gpt-4o litellm_params: model: gpt-4o api_key: ${OPENAI_API_KEY} # 深度推理模型 - 用于多步推理Reasoning模式 - model_name: r1 litellm_params: model: deepseek-reasoner api_base: https://api.deepseek.com/beta api_key: ${DEEPSEEK_API_KEY} # 确保环境变量中有此值 # 快速模型 - 用于内容压缩等对速度要求高的任务 - model_name: gemini-lite litellm_params: model: gemini/gemini-2.0-flash-exp api_base: https://openrouter.ai/api/v1 api_key: ${OPENROUTER_API_KEY} # 如果使用OpenRouter litellm_settings: drop_params: true # 忽略请求中模型不支持的参数 set_verbose: true # 调试时开启查看详细日志关键配置解析model_name这是在II-Researcher配置中如STRATEGIC_LLMgpt-4o引用的名称。litellm_params定义实际调用的模型。api_base和api_key指定了调用路径和凭证。多模型路由你可以在这里定义多个相同model_name但不同后端权重的条目实现负载均衡和故障转移但对于个人使用一个就够了。3.3 一键启动使用Docker Compose运行完整栈配置完成后启动服务就变得极其简单。确保你的Docker和Docker Compose已就绪在项目根目录执行docker compose up --build -d这个命令会执行以下操作构建镜像根据项目内的Dockerfile构建包含II-Researcher代码和依赖的容器镜像。启动服务根据docker-compose.yml定义启动三个服务litellm运行在4000端口提供模型代理。api运行在8000端口提供FastAPI后端处理研究请求。frontend运行在3000端口提供Next.js的Web交互界面。-d参数让服务在后台运行。启动完成后你可以通过以下命令查看日志确认一切正常# 查看所有服务的实时日志 docker compose logs -f # 或者只看后端API的日志这里能观察到搜索和推理的详细过程 docker compose logs -f api如果看到各服务启动成功的日志没有报错就可以打开浏览器访问http://localhost:3000了。避坑指南首次启动常见问题端口冲突如果3000、4000、8000端口已被占用需要在docker-compose.yml中修改ports映射例如将3000:3000改为3001:3000然后通过http://localhost:3001访问。API密钥未生效确保.env文件在项目根目录且变量名与docker-compose.yml中env_file指定的路径一致。Docker Compose不会自动读取Shell中的环境变量。LiteLLM连接失败检查litellm容器的日志确认模型配置的api_key和api_base是否正确。一个快速测试方法是进入api容器内部用curl命令测试LiteLLM端点docker compose exec api curl http://litellm:4000/health。网络超时首次拉取镜像或模型响应慢可能导致超时。可以适当调大.env文件中的SEARCH_PROCESS_TIMEOUT和SCRAPE_URL_TIMEOUT值。4. 实战演练使用不同模式进行深度研究环境跑通了我们来实际感受一下II-Researcher的威力。它主要提供三种使用方式Web界面、命令行接口CLI和通过MCP集成到Claude。我们重点看前两种并对比其背后的Pipeline模式和Reasoning模式。4.1 Web界面快速体验访问http://localhost:3000你会看到一个简洁的界面。输入一个研究性问题例如“What are the latest advancements in quantum error correction as of 2024, and which companies or research labs are leading this field?”截至2024年量子纠错的最新进展是什么哪些公司或研究实验室处于领先地位。点击搜索后前端会将问题发送到后端API (localhost:8000)。后端的工作流程可以简化为以下步骤接收与解析API接收问题初始化研究代理。规划搜索STRATEGIC_LLM如gpt-4o分析问题生成3-5个核心搜索查询例如[“2024 quantum error correction breakthroughs”, “top companies quantum error correction 2024”, “surface code recent progress”, “quantum computing labs error correction”]。并行搜索与抓取框架并发地使用配置的SEARCH_PROVIDER执行这些查询获取URL列表然后使用SCRAPER_PROVIDER并发抓取这些页面的内容。内容压缩与合成所有抓取的文本经过压缩模块处理去除无关内容保留核心信息并合并成一份紧凑的研究材料。生成报告SMART_LLM可以是同一个模型基于这份材料撰写结构化的最终答案并自动附上引用来源。在Web界面上你可以实时看到“生成搜索查询”、“抓取网页内容”、“生成报告”等状态更新。最终你会得到一份段落清晰、带有引用标记如[1],[2]的报告点击引用可以跳转到源网址。这个过程通常需要1-3分钟取决于问题的复杂度和网络速度。4.2 命令行CLI与模式深度配置对于开发者或者需要将研究能力集成到自动化脚本中的场景CLI是更强大的工具。我们进入API服务的容器内部来操作# 进入正在运行的api容器 docker compose exec api bash # 现在你就在容器的命令行里了基础CLI使用# 使用流式输出--stream实时查看过程 python ii_researcher/cli.py --question Explain the Rust programming languages ownership model and its advantages for concurrent programming. --stream模式选择与高级配置 II-Researcher的精髓在于其可配置的推理模式。除了默认流程你还可以通过环境变量启用更强大的模式。启用LLM内容压缩默认使用嵌入模型进行语义去重压缩。如果你希望用更智能的LLM来做摘要和提炼可以启用此选项这通常能产生质量更高的压缩文本但速度稍慢、成本略高。# 在启动容器前在.env文件中添加 USE_LLM_COMPRESSORTRUE FAST_LLMgemini-lite # 指定一个快速且便宜的模型来执行压缩任务Pipeline模式这是默认的强化模式。它使用两个或更多LLM分工协作。# 在.env中配置 STRATEGIC_LLMgpt-4o # 负责高层策略规划决定搜索什么、何时停止、如何验证。 SMART_LLMgpt-4o # 负责具体执行撰写搜索查询、分析内容、生成最终报告。 # 你可以让STRATEGIC_LLM使用更强的模型如o1-preview让SMART_LLM使用性价比高的模型以达到效果和成本的平衡。Reasoning模式这是II-Researcher的“深度研究”模式尤其适合需要复杂逻辑推理、数学计算或分步验证的问题。它利用DeepSeek-R1这类专门针对推理优化的模型。# 在.env中配置 R_MODELr1 # 指定使用在litellm_config中定义的‘r1’模型 R_TEMPERATURE0.2 # 较低的温度使推理更确定、更专注 R_REPORT_MODELgpt-4o # 推理模型可能不擅长组织最终报告用另一个模型来润色输出 R_PRESENCE_PENALTY0 # 通常推理任务不需要此惩罚要使用Reasoning模式你需要在CLI命令中指定如果框架已根据环境变量自动切换则无需此步python ii_researcher/cli.py --question Prove that the square root of 2 is irrational. --reasoning --stream在这个模式下模型会展示出更接近“思考链”的过程你会看到它如何一步步地推导、引用数学定理最终构建严密的证明。4.3 一个完整的复杂研究案例拆解让我们设计一个更复杂的问题看看II-Researcher如何应对“评估在边缘设备如手机、物联网传感器上部署微型大语言模型如Phi-3, Gemma-2B的可行性主要挑战是什么以及目前有哪些优化的推理框架如MLC-LLM, llama.cpp”这是一个典型的、包含多个子维度的调研问题。一个优秀的AI研究员应该能拆解出“边缘设备硬件约束”、“微型LLM特性”、“推理框架对比”等子主题。为每个子主题设计精准的搜索词。从搜索结果中识别出权威来源如论文、官方博客、基准测试报告。提取关键数据如模型大小、内存占用、推理速度。进行对比分析总结挑战如能耗、精度损失和解决方案。当你通过CLI以--stream模式运行这个问题时观察输出日志你会看到框架是如何动态完成这些步骤的。它可能首先搜索“tiny LLMs for edge devices 2024”然后根据抓取到的文章中提到“MLC-LLM”和“llama.cpp”再发起针对这两个框架的专项搜索。整个过程是自适应、迭代的。最终生成的报告理想情况下应该包含以下几个部分引言概述边缘AI与微型LLM的趋势。可行性分析列举Phi-3、Gemma-2B等模型参数量、内存需求对比典型边缘设备如手机SoC的算力。核心挑战分点说明内存限制、计算延迟、能耗问题、模型精度与规模的权衡。推理框架评估用表格或列表对比MLC-LLM、llama.cpp、TFLite Micro等框架的特点、支持硬件和性能数据。结论与展望。参考文献列出所有信息源的链接。5. 性能调优、问题排查与进阶技巧任何强大的工具都需要精细的调校才能发挥最大效力。在实际使用II-Researcher的过程中你肯定会遇到各种情况。下面是我踩过坑后总结出的经验。5.1 关键性能参数调优指南下表总结了核心环境变量对性能和质量的影响以及调优建议环境变量默认值/示例作用调优建议SEARCH_PROVIDERserpapi选择搜索引擎。tavily返回更简洁serpapi结果更原始丰富。研究广度用tavily快速扫描研究深度或需要最新/多样结果用serpapi。SCRAPER_PROVIDERfirecrawl选择网页抓取器。firecrawl最强但需付费bs免费但功能弱。生产环境强烈推荐firecrawl。测试或简单页面可用bs。COMPRESS_SIMILARITY_THRESHOLD0.3嵌入模型压缩时的相似度阈值。值越高去重越严格信息丢失风险越大。一般保持0.3-0.5。如果发现报告遗漏关键细节可降至0.2如果报告冗余重复可升至0.5。COMPRESS_MAX_OUTPUT_WORDS4096压缩后最大字数。决定了传递给报告生成模型的信息量上限。根据你使用的报告模型SMART_LLM的上下文窗口调整。对于128K模型可设为30000以保留更多细节。SEARCH_QUERY_TIMEOUT20单次搜索查询超时时间秒。网络不佳或使用serpapi时可适当增加到30-40。SCRAPE_URL_TIMEOUT30单URL抓取超时时间秒。对于大型或复杂的网站如新闻门户可能需要增加到60。STEP_SLEEP100步骤间延迟毫秒。避免向搜索引擎或爬虫服务发送请求过快。免费API通常有速率限制保持100-200是安全的。自有服务器可降低。5.2 常见问题与排查实录即使配置正确在实际运行中也可能遇到问题。下面是一个快速排查清单问题现象可能原因排查步骤与解决方案启动失败提示端口占用3000/4000/8000端口被其他程序使用。docker compose ps查看服务状态。修改docker-compose.yml中的端口映射如8001:8000。搜索过程卡在“Generating search queries...”战略LLM (STRATEGIC_LLM) 服务不可用或响应慢。1. 检查litellm容器日志docker compose logs litellm。2. 确认litellm_config.yaml中对应模型的api_key和api_base正确。3. 测试LiteLLM连通性在api容器内执行curl http://litellm:4000/health。报告内容空洞引用来源少1. 搜索查询设计不佳。2. 内容压缩过于激进。3. 抓取失败。1. 查看日志确认生成的搜索查询是否具体、相关。2. 调低COMPRESS_SIMILARITY_THRESHOLD如0.2增加COMPRESS_MAX_OUTPUT_WORDS。3. 查看日志中是否有“Failed to scrape”错误尝试更换SCRAPER_PROVIDER或增加超时。报告生成时间过长5分钟1. 搜索或抓取超时。2. 抓取了过多或过大的网页。3. LLM响应慢。1. 适当增加超时设置但也要设置SEARCH_PROCESS_TIMEOUT总超时防止无限等待。2. 框架可能会限制并发请求和总抓取量检查相关配置如果有。3. 考虑换用响应更快的LLM如GPT-4o-mini作为SMART_LLM。报告出现“幻觉”编造信息1. 搜索到的源信息质量差。2. LLM在信息不足时过度推理。1. 这是当前AI研究的核心难题。可以尝试启用Reasoning模式让模型更谨慎地推理。2. 在Prompt层面强化“基于引用”、“不确定则说明”的指令需要修改源码。3. 人工审核关键事实的引用来源。Web前端报错无法连接API前端配置的API地址错误或后端服务未启动。1. 确认前端.env文件中NEXT_PUBLIC_API_URL是否为http://localhost:8000或你映射的端口。2. 确认api服务正在运行docker compose ps。3. 直接访问http://localhost:8000/docs看Swagger UI是否能打开。5.3 进阶技巧自定义与扩展II-Researcher作为一个开源框架提供了良好的扩展性。集成自定义工具框架的核心是让LLM调用工具。你可以参考现有搜索/抓取工具的实现在代码中添加新的工具。例如添加一个从特定数据库如arXiv, PubMed抓取论文摘要的工具让研究代理能直接获取学术信息。修改Prompt模板报告的质量和风格很大程度上受Prompt影响。你可以在源码中找到生成搜索查询、总结内容、撰写报告的Prompt模板根据你的需求进行优化。比如你可以要求报告必须采用“背景-方法-结果-讨论”的学术结构。混合使用Pipeline与Reasoning你可以修改核心逻辑让代理先使用Reasoning模型进行复杂的规划和分析然后使用Pipeline模式的高效模型进行大规模的内容抓取和摘要最后再用一个高质量的模型进行报告合成从而在成本、速度和效果间取得最佳平衡。作为MCP服务器集成到工作流这是我最喜欢的用法。将II-Researcher配置为MCP服务器后我可以在Claude Desktop中直接调用它。当我在和Claude讨论一个技术话题时如果感到信息不足只需输入一个特殊命令如/researchClaude就会将问题委托给II-Researcher并将研究结果无缝地融入对话上下文。这极大地提升了信息获取的深度和效率。经过几个月的实际使用II-Researcher已经成为了我处理复杂信息调研的得力助手。它并不能完全替代人类的批判性思维和深度分析——最终的报告仍然需要你判断信息的权重和真伪——但它极大地压缩了从“提出问题”到“获得初步材料”的时间。从手动打开十几个浏览器标签、反复筛选信息到如今只需等待几分钟获得一份带引用的初稿这种效率的提升是革命性的。对于任何需要频繁进行网络深度研究的人来说花点时间部署和调优这个框架绝对是一笔高回报的投资。