人工智能大模型AI AgentRAG深度研究搜索引擎后端代码智能体【免费下载链接】deepsearchopenJiuwen DeepSearch是一款知识增强的深度搜索与研究框架有业界领先的片段级引用和溯源推理能力提供精准Agentic搜索与研究能力项目地址https://gitcode.com/openJiuwen/deepsearch点击查看免费下载openJiuwen DeepSearch 的深度搜索与研究能力集中在 openjiuwen_deepsearch/ 这一 Python 包中本文以该包的官方目录结构文档为骨架逐层拆解algorithm、framework、config、llm、utils五大模块的稳定职责边界并结合源码文件定位关键入口工作流组装、节点、状态契约、工具注册与配置模型。读完本文你将能快速看懂一次深度研究报告任务的完整代码路径意图识别 → 大纲 → 收集 → 写作 → 溯源 → 流式输出并掌握新增搜索 provider、新节点、新算法模块时的落点与同步约定。概览顶层模块职责原文档用一张概览树刻画了包内六个顶层目录的稳定分工openjiuwen_deepsearch/ ├── algorithm/ # 研究、检索、写作和溯源算法 ├── common/ # 异常、状态码和公共定义 ├── config/ # Pydantic 配置与运行时 API 工具模型 ├── framework/openjiuwen/ # 工作流编排、节点、工具和 LLM 适配 ├── llm/ # 统一 LLM 调用封装 └── utils/ # 安全、日志、限流、校验和常量工具algorithm/是领域算法的集中地负责「做什么」意图识别、大纲规划、信息收集、报告撰写、图表生成、溯源推理与用户反馈后处理均以纯 Python 算法模块形式存在framework/openjiuwen/是运行时编排层负责「怎么跑」把算法节点组装进可流式执行的工作流并提供工具注册与 LLM 适配能力config/用 Pydantic 模型统一管理对外可配置项llm/封装统一的大模型调用入口utils/提供安全、日志、限流、校验与常量等横切能力common/提供CustomValueException等异常体系见 common/exception.py与错误码定义见 common/status_code.py。说明本文描述的是稳定模块边界与关键入口不逐条列举缓存与易变的内部实现文件与官方目录结构文档口径一致。algorithm/领域算法层algorithm/下按「报告类型 × 生命周期阶段」组织子目录algorithm/ ├── brief_report/ # Brief 报告、素材合并与 HTML 输出 ├── chart_generation/ # 图表生成和沙箱资源 ├── prompts/ # 提示词模板 ├── query_understanding/ # 意图、素材、大纲、计划与澄清 ├── report/ # 子报告/总报告、证据和可视化 ├── report_export/、report_style/、report_template/ ├── research_collector/ # 收集、证据融合和网页正文增强 ├── search_agent/、search_index/、search_nodes/、search_tools/ ├── source_trace/、source_tracer_infer/ └── user_feedback_processor/ # 报告后局部编辑与补充检索各目录的源码级定位如下brief_report/精简版Brief报告全链路包括素材合并、大纲outline.py、信息收集collector.py、证据复核review.py、Markdown/HTML 报告输出markdown.py、html_reporter.py与图表html_charts.py等chart_generation/报告图表生成包含 chart_generator.py 与基于 VLM 的迭代生成器 vlm_chart_generator.py以及用于执行图表代码的sandbox/沙箱资源prompts/全部提示词模板目录brief_*、collector_*、outliner_*、infer_*、sub_section_*、synonym_rewrite_*等数十个主题report/专业版报告的撰写与证据管线核心实现为 report.py并包含 doc_prefilter.py、evidence.py、visualization.py、sub_section_outline.py 等report_export/、report_style/、report_template/分别承担报告导出、样式与模板的解析生成如 template_generator.py 被工作流入口用于generate_templateresearch_collector/信息收集阶段的证据融合与网页正文增强核心文件包括 collector_function.py、scholarly_fusion.py、webpage_enrichment.py 与 target_paper.py目标论文标识归一化search_agent/、search_index/、search_nodes/、search_tools/Search/ReAct 模式的搜索智能体、检索索引与搜索节点工具例如 search_agent/action_pool.py、search_nodes/下的find_action.py、initialize_state.py、run_action.py、tool_node.py构成 DeepSearch 图的执行原子source_trace/、source_tracer_infer/片段级引用校验与溯源推理如 source_trace/checker.py、source_tracer_infer/infer.py对应项目「片段级引用和溯源推理」的核心能力user_feedback_processor/报告生成后基于用户反馈的局部编辑与补充检索user_feedback_processor.py。query_understanding意图、素材、大纲与计划原文档特别点出query_understanding/的关键入口为intent_recognition.py、material_processing.py、outline_mode_router.py、interpreter.py、outliner.py和planner.py这些文件在仓库中均已确认存在见 query_understanding/intent_recognition.py报告意图识别classify_and_recognize_intent/recognize_report_intent将用户 query 解析为结构化的ResearchIntent并通过resolve_report_type_policy归一化出确定性的报告类型策略它还内置了pmid、DOI、arXiv ID、URL 等正则识别见该文件_PMID_IN_QUERY_RE等normalize_research_query会控制研究 query 最大长度material_processing.py用户素材UserMaterial的校验、去重、摘要与相关性分析产物写入search_context.material_analysis供后续节点复用outline_mode_router.py大纲执行方式路由route_outline_execution_method调用 LLM 返回parallel或dependency_driving空 query、调用失败或输出不可解析时安全回退到parallel见 outline_mode_router.pyinterpreter.pyquery 解释/澄清query_interpreter被IntentRecognitionNode直接消费outliner.py 与 planner.py分别产出大纲Outline与章节级计划Plan章节绑定的用户素材约束material_bindings与use_material_ids在此阶段确认供收集和写作阶段消费。framework/openjiuwen/运行时编排层framework/openjiuwen/是整个运行时的核心原文档给出的结构如下framework/openjiuwen/ ├── agent/ │ ├── workflow.py # 流式 Agent 入口与工作流组装 │ ├── main_graph_nodes.py # 主图节点 │ ├── brief_nodes.py # Brief 专用节点 │ ├── metadata_injectors.py # 请求 metadata 注入器 │ ├── search_context.py # 工作流状态模型 │ ├── collector_graph/ # 收集子图、证据账本、网页增强 │ └── reasoning_writing_graph/# 章节推理/写作子图 ├── core/workflow_agent/ # WorkflowAgent 与控制器适配 ├── llm/ # 工作流 LLM 工厂与适配器 └── tools/ ├── fetch_api/ # 网页抓取 provider含 jina ├── runtime_api/ # 运行时 HTTP 工具构建与调用 └── search_api/ # 联网、本地和学术搜索 provideragent/节点与工作流组装workflow.py 是流式 Agent 入口定义了BaseAgent抽象基类run/generate_template抽象接口及其四个具体实现DeepresearchAgentworkflow.py专业版并行工作流_build_research_workflow注册主图节点并通过init_router组装条件边DeepresearchDependencyAgentL1087 起依赖驱动工作流使用DependencyOutlineNode、DependencyOutlineInteractionNode与DependencyEditorTeamNode按「推理写作」依赖分层流水线执行DeepresearchIntentHybridAgentL1196 起hybrid 模式复用普通大纲节点同时注册普通与依赖驱动两套写作团队由意图识别结果选择分支DeepSearchAgentL1319 起Search/ReAct 模式的搜索智能体入口维护ActionPool、日志目录与DeepSearchRunContext运行上下文。此外_add_brief_branchworkflow.py向任意研究主图注册相同且独立的 Brief 支路BriefOutline → BriefInfoCollector → BriefEvidenceReviewer → BriefSubReporter → BriefReporter → BriefSourceTracer → BriefHtmlReporter。main_graph_nodes.py主图节点实现涵盖IntentRecognitionNode、GenerateQuestionsNode、OutlineNode、OutlineInteractionNode、EditorTeamNode、ReporterNode、VLMChartGeneratorNode、SourceTracerNode、SourceTracerInferNode、UserFeedbackProcessorNode、FeedbackHandlerNode、SearchStartNode/SearchEndNode、ToolNode、EndNode等brief_nodes.pyBrief 专用节点BriefOutlineNode、BriefInfoCollectorNode、BriefEvidenceReviewNode、BriefSubReporterNode、BriefReporterNode、BriefHtmlReporterNodemetadata_injectors.py请求 metadata 注入器注册表MetadataInjector采用matches轻量指纹检测→validate严格结构校验→inject构造状态更新三段式协议apply_injectors在StartNode编排所有激活注入器状态更新采用 first-wins 合并目前注册的brief_outline_injectorL256支持「Brief 升级专业版」回传brief_outline/research_intent/language三键 metadata直接路由到大纲节点并要求强制走并行图force_execution_methodPARALLELsearch_context.py工作流状态契约定义Message、Step、Plan、Section、Outline、Report、SubReport、FinalResult、ResearchIntent、ReportTypePolicy、TemporalScope、TargetPaper、SearchContextL649等 Pydantic 模型是节点间传递状态的唯一事实源collector_graph/收集子图包含 graph_builder.py子图组装、info_collector.py、evidence_ledger.py证据账本供目标论文去重与可检索性判断、webpage_enrichment.py 与 collector_execution_service.pyreasoning_writing_graph/章节推理/写作子图包含section_context.py、dependency_reasoning_team_nodes.py、dependency_writing_team_nodes.py、editor_team_nodes.py。节点的通用基类在 base_node.pyBaseNode继承WorkflowComponent统一提供_pre_handle取 Session 字段→_do_invoke核心算法输入输出与平台解耦→_post_handle回写 Session三段钩子invoke负责注入计时、日志与异常处理等横切逻辑init_routerL68则按next_node字段动态生成分支路由。core/workflow_agent/ 与 llm/core/workflow_agent/WorkflowAgent与WorkflowControllerConfig、workflow_controller.py是工作流 Agent 的控制器适配层DeepresearchAgent通过WorkflowAgent(cardcard, configconfig)与add_workflows装载 workflow providerllm/工作流 LLM 工厂与适配器。llm_adapter.py 定义了五类模型槽位LlmConfigCategorygeneral通用、plan_understanding推理/规划、info_collecting信息收集、writing_checking写作校验、vlm_chart_generating多模态图表并通过NODE_LLM_MAPPING将节点映射到模型槽位llm_model_factory.py 按openai/siliconflowprovider 构造模型实例并支持通过环境变量LLM_SSL_VERIFY控制 SSL 校验。tools/搜索、抓取与运行时工具tools/下三个子目录构成了工具的完整生态fetch_api/网页抓取 provider含 jinajina/api_wrapper.py与 base.py、registry.pyruntime_api/运行时 HTTP 工具构建与调用由build_runtime_api_tools将 runtime_api_models.py 中声明的RuntimeApiToolConfig列表转换为可执行工具search_api/联网、本地和学术搜索 provider原文档明确列举agc_ainetworking、harness_web_search、jina、petal、serper、tavily、xunfei和scholarly_search/PubMed、arXiv、Semantic Scholar、全文获取外部及本地适配位于external_tool/、local_search_api/、native_local_search_api/。从 search_api/init.py 的__all__可见已导出的 wrapperAgcAiNetworkingSearchAPIWrapper、XunfeiSearchAPIWrapper、PetalSearchAPIWrapper、GoogleSearchAPIWrapperserper、TavilySearchAPIWrapper、PubMedSearchAPIWrapper、ArxivSearchAPIWrapper、SemanticScholarSearchAPIWrapper、HarnessWebSearchAPIWrapper、BochaSearchAPIWrapper、JinaSearchAPIWrapper、PerplexitySearchAPIWrapper、LocalDatasetAPIWrapper、NativeLocalSearchAPIWrapper以及load_external_search_tools。在 web_search.py 中可看到搜索引擎注册表search_engine_mapping新增外部引擎可经由CustomWebSearchConfig的custom_web_search_file/custom_web_search_func动态注册见 workflow.py 的register_web_search_tool/_register_local_search_tool。另外tools/mcp/可选依赖pyproject[mcp]提供 MCP 客户端与工具捆绑tools/init.py 中在未安装mcp包时将其置为None而非阻断导入。配置与工具config/config.py是全部对外配置的权威定义原文档明确指出它定义AgentConfig、ServiceConfig和 provider 配置。从源码看config/config.pyAgentConfigL360单次 Agent 运行配置包含execute_modecommercial/general、execution_methodparallel/dependency_driving/hybrid默认 parallel、report_typebrief/professional、user_materials_enabled、coverage_rule_block_enable、exclusion_constraint_enable、workflow_human_in_the_loop、outliner_max_section_num范围[1, 15]、outline_interaction_max_rounds、source_tracer_*系列溯源开关、五槽位llm_config、info_collector_search_methodweb/local/all、web_search_engine_config、scholarly_search_enabled、local_search_engine_config、custom_web_search_config、custom_local_search_config、search_moderesearch/search/react、enable_question_router、search_workflow_per_question_params、search_workflow_milvus_config、mcp_servers、web_search_max_qps、api_tools_config、user_feedback_processor_*、stats_info_llm、vlm_chart_generator_*等ServiceConfigL482服务级默认参数如workflow_execution_timeout7200 秒、workflow_feedback_modeweb/cmd、search_workflow、outliner_max_generate_outline_retry_num、info_collector_max_search_query_count、source_tracer_citation_verify_max_concurrency_num、visualization_enable、llm_thinking_enabled等ConfigL568总配置类组合agent_config与service_configprovider 配置WebSearchEngineConfigL29search_engine_name支持 tavily/google/xunfei/petal/custom/bocha/jina/perplexity/serper/agc_ainetworking、WebFetchProviderConfigL51、ScholarlySearchConfigL105含 PubMed/arXiv/Semantic Scholar 子配置fetch_full_text与max_full_text_results_per_query、LocalSearchEngineConfigL138search_mode支持 doc/keyword/mix、MilvusConfigL216与PerQuestionParamsL179max_workers、time_limit、answer_mode_top_k、provide_best_guess等。runtime_api_models.py定义运行时 HTTP 工具模型RuntimeApiToolConfig声明tool_id、path、http_methodget/post/put/delete/patch/head/options、request_params含send_methodnone/header/query/body以及is_runtime运行时参数标记、response_params与静态headersApiToolsConfig再按query_understanding_tools/collector_tools分组。utils/包含common_utils/、constants_utils/、debug_utils/、log_utils/、rate_limiter_utils/、validation_utils/目录均已确认存在于 utils/common_utils/LLM 工具llm_utils.py含ainvoke_llm_with_stats、安全security_utils.py含zero_secret密钥清零、流式stream_utils.py定义StreamEvent/MessageType等constants_utils/节点 ID 与 LLM 调用点名node_constants.py 中NodeId覆盖主图、子图、搜索图、收集子图全部节点、搜索引擎常量search_engine_constants.pyTEMPORAL_SCOPE_SEARCH_ENGINES目前仅 tavily 原生支持按发表日期过滤、学术 provider 常量scholarly_constants.py与 session 级 ContextVarsession_contextvars.pylog_utils/LogManager敏感日志开关、log_interface接口日志、log_metrics耗时指标等rate_limiter_utils/qps_limiter对应web_search_max_qps流控validation_utils/field_validation与param_validationDeepresearchAgent.run入口的validate_run_agent_params/validate_agent_required_field即来自此debug_utils/与run_telemetry.py节点调试日志与长任务 HTTP 遥测RunTelemetryConfigrun_telemetry_session见 run_telemetry.py。主调用链与开发入口原文档给出了权威的一次研究报告调用链workflow.py → main_graph_nodes.py / brief_nodes.py → query_understanding → collector_graph research_collector → reasoning_writing_graph report → source_trace / source_tracer_infer → 流式输出或 HITL 等待事件结合源码可将该链路进一步落实为可追踪的节点序列对应 workflow.py 的_build_research_workflowStartNodeSTART→ 条件路由到IntentRecognitionNode或OutlineNodeIntentRecognitionNodeINTENT_RECOGNITION→ 可路由到GenerateQuestionsNode澄清提问、FeedbackHandlerNode接收用户反馈、OutlineNode/BriefOutlineNode或直接EndNodeGenerateQuestionsNode→FeedbackHandlerNodeOutlineNode→OutlineInteractionNodeHITL 大纲交互可多轮回 Outline或EditorTeamNode并行图/DependencyEditorTeamNode依赖驱动图写作团队产出子报告后进入ReporterNodeREPORTER→ 可选VLMChartGeneratorNode图表迭代生成→SourceTracerNode→SourceTracerInferNode→UserFeedbackProcessorNode可自循环处理多轮反馈→EndNode运行结果通过Runner.run_agent_streaming以流式事件返回_consume_stream_chunks将CustomSchema块转换为 JSON 消息并转发含__interaction__类型的 HITL 等待事件见 workflow.py。节点间的条件边由init_router生成实际执行的分支由节点输出字段next_node决定见 base_node.py。二次开发时原文档给出的四个落点约定是工作流节点新增或修改节点集中在 framework/openjiuwen/agent/节点 ID 需同步注册到 node_constants.py 的NodeId并在_build_research_workflow/_build_research_dependency_workflow/_build_research_hybrid_workflow中挂边报告算法和提示词位于 algorithm/report/ 与 algorithm/prompts/新提示词模板按既有命名规范中/英双语成对落盘搜索/抓取 provider新增引擎实现在 framework/openjiuwen/tools/search_api/ 或fetch_api/并同步注册到 web_search.py 的search_engine_mapping与 config/config.py 的 provider 配置模型WebSearchEngineConfig.search_engine_name的 Literal 取值等AgentConfig中已提供custom_web_search_file/custom_web_search_func的免改码外部注册通道状态契约framework/openjiuwen/agent/search_context.py 是节点间共享状态的唯一事实源修改状态字段时必须同步 API 参考文档见 docs/zh/3.开发指南/ 下的 API 文档目录并留意ResearchIntent中temporal_scope→source_date_scope/content_date_scope这类旧字段路由兼容见 search_context.py 的 before-validator。与测试体系的对应关系仓库在 deepsearch/tests/ 下为各模块提供了成体系的测试可作为理解模块边界的第二手证据framework/下的test_workflow_agent.py、test_create_agent.py、test_sub_workflow.py覆盖工作流组装与 Agent 构建search_agent/下的test_find_action_space.py、test_initialize_state.py、test_run_action.py、test_termination.py覆盖 DeepSearch 图执行原子report/下的test_general_report.py、test_sub_report.py、test_citation_sanitize.py对应algorithm/report/source_tracer/与source_tracer_infer/的测试对应溯源与推理模块user_feedback_processor/的测试则覆盖报告后局部编辑链路。开发者修改某目录代码后可定位到同名测试文件做回归验证。结语openjiuwen_deepsearch包通过「领域算法algorithm/ 运行时编排framework/openjiuwen/ 配置契约config/ 横切工具utils/」的清晰分层把意图识别、大纲规划、信息收集、报告写作、图表生成与片段级溯源推理组织成可流式执行、可 HITL 交互的工作流。掌握本文梳理的模块边界、关键入口与同步约定后无论是新增搜索 provider、扩展工作流节点还是深入调优某个报告算法都能快速定位到对应的源码文件与测试用例。赞分享人工智能大模型AI AgentRAG深度研究搜索引擎后端代码智能体【免费下载链接】deepsearchopenJiuwen DeepSearch是一款知识增强的深度搜索与研究框架有业界领先的片段级引用和溯源推理能力提供精准Agentic搜索与研究能力项目地址https://gitcode.com/openJiuwen/deepsearch点击查看免费下载相关推荐openJiuwen DeepSearch 源码导读openjiuwen_deepsearch 目录结构、模块边界与主执行链openJiuwen DeepSearch 源码导读openjiuwen_deepsearch 目录结构、模块边界与主执行链 本文以 deepsearch 开人工智能大模型AI AgentRAG深度研究搜索引擎后端代码智能体Handsontable 源码结构完全指南核心包 handsontable/ 目录地图、模块体系与扩展开发导航Handsontable 源码结构完全指南核心包 handsontable/ 目录地图、模块体系与扩展开发导航 本篇技术指南以 Handsontable 开源前端UI组件tsParticles 仓库代码结构完全指南从 monorepo 布局到源码导航与二次开发入口tsParticles 仓库代码结构完全指南从 monorepo 布局到源码导航与二次开发入口 本文以仓库内 .planning/codebase/STRUC前端上一篇AWS CLI apigatewayv2 get-domain-name 命令详解查询 API Gateway 自定义域名配置下一篇Telegraf Printer 处理器插件详解将指标实时打印到标准输出的调试利器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考