人工智能大模型AI AgentRAG深度研究搜索引擎后端代码智能体【免费下载链接】deepsearchopenJiuwen DeepSearch是一款知识增强的深度搜索与研究框架有业界领先的片段级引用和溯源推理能力提供精准Agentic搜索与研究能力项目地址https://gitcode.com/openJiuwen/deepsearch点击查看免费下载导读本文深入解析 openJiuwen DeepSearch 搜索 AgentDeepSearchAgent中discovered_clues的REPORT报告式线索模式它以deepsearch_run_action_clues_report.md为规范骨架要求模型在每次状态补丁中为每个被更新的变量写入一条「History Candidate」双段式研究报告完整记录调研路径、候选发现过程与线索校验结论。读完本文你将掌握 REPORT 模式与 blacklist黑名单淘汰式、none禁用式三种discovered_clues_mode的语义差异与切换方式理解discovered_clues在状态空间搜索中的「记忆与推理证据链」作用并能结合源码与测试用例写出符合规范、可被解析器正确落库的线索条目。一、背景搜索 Agent 的状态空间搜索与线索字段的定位openJiuwen DeepSearch 的 Search Agent 采用状态空间搜索模型将复杂问题分解为多个变量Variable通过「初始化状态 → 发现动作 → 执行动作 → 产出答案」的循环逐步逼近答案。核心流程由三个子工作流构成见 README_search.mdinit_state解析问题构建初始搜索状态find_action从当前状态提出可执行的搜索动作Actionstate_creation执行动作、调用工具、扩展状态空间。其中state_creation的核心执行节点是RunActionNode其底层实现位于 run_action.py。每个状态State由若干Variable组成字段定义见 search_context.py字段可变性含义id不可变变量唯一标识type不可变变量类型如 City、Mathematicianquestion_clues不可变从问题本身推导出的线索初始化后不可修改discovered_clues可变研究过程中发现、可增量追加的线索candidate可变当前候选答案candidate_strength可变候选置信度0~1可选discovered_clues是 Agent 跨轮次推理的「增量记忆」它把一次 Action 中探索到的路径、排除的候选、验证过的线索写入状态供后续动作与并行分支继续消费。REPORT 模式正是这套记忆机制的规范化描述语言——它规定线索条目「怎么写、写什么、写到多细」。二、REPORT 模式核心规则规范原文继承deepsearch_run_action_clues_report.md定义了在 REPORT 模式下模型更新discovered_clues时必须遵守的规则共 5 条硬性约束整体替换而非追加discovered_clues会被你在状态补丁state patch中提供的内容整体替换REPLACED而不是追加。因此每次补丁都必须携带该变量的完整线索快照。一变量一条目在此模式下每更新一个变量discovered_clues必须恰好是只含一条字符串的列表list with exactly one string entry即[REPORT: ...]。条目双段式结构唯一的那条字符串必须包含两个带标签的段落History对该变量到目前为止调研过程的高信号high-signal叙事——尝试过哪些研究方向和动作、考虑过哪些候选或假设、为何被否决或仍未证实。Candidate若存在当前候选说明它是如何被发现的关键搜索词、工具或页面、已对照问题线索question clues做过哪些校验、这些线索是否被满足、是否查找过其他候选以评估唯一性并引用搜索/抓取结果中的相关原文若没有当前候选此段留空。允许压缩重写不必逐字保留全部历史细节随着掌握的信息增多可以重写与压缩过往信息只要报告仍反映当前的知识本质状态。统一格式REPORT: History: [探索路径与已否决候选的简明历史] Candidate: [当前候选状态、发现方式、对照问题线索的校验、唯一性评估] | Sources: [URL1, URL2, ...]三、三种 discovered_clues_mode 的语义对照REPORT 模式并非唯一选项。prompts 目录下共存放三个线索段落模板由配置项discovered_clues_mode选择其加载逻辑见 run_action.py 中的build_react_prompt_contextclues_key discovered_clues_mode if discovered_clues_mode in (blacklist, report, none) else blacklist context {CLUES_SECTION: get_prompt_section(fdeepsearch_run_action_clues_{clues_key})}模式模板文件线索条目语义典型适用reportdeepsearch_run_action_clues_report.md一条REPORT:式「研究履历 候选状态」条目需要让后续 Agent 理解调研过程、候选发现路径与校验结论的深链推理场景blacklistdeepsearch_run_action_clues_blacklist.md多条ELIMINATES:式淘汰条目明确「排除谁 证据」以候选淘汰为主、强调排除一致性的场景仓库默认值nonedeepsearch_run_action_clues_none.md禁用任何补丁中discovered_clues必须为[]不需要跨轮次线索记忆的轻量场景blacklist 模式的对照要点在blacklist模式下discovered_clues可以被写成多条淘汰条目格式为ELIMINATES: [candidate/group description] - [reasoning/evidence]. [If applicable: Include any assumptions about other variables that cause a contradiction or lead to this elimination] | Sources: [URL1, URL2, ...]且要求补丁中提供的线索必须保留此前所有仍然有效的信息线索应通过「排除具体候选」或「按属性排除一组候选」来收窄候选池候选被变更时与其相关的所有线索须同步更新。该模式提供的示例包括ELIMINATES: John Smith - published work in 1823, but University College London was not established until 1826. Assumption: Variable 2 (university) is University College London| Sources: url_of_the_sourceELIMINATES: Chicago - as there is no soccer team that is based in Chicago that competed in the FA Cup (requirement stated in question clues) | Sources: url_of_the_source1, ...对照可见两种模式的本质差异blacklist 记录「否证」谁被排除、为什么report 记录「正证与过程」怎么查的、查到了什么、候选是否唯一。二者同时约束着主提示词中的一条铁律——不能在 discovered_clues 中被淘汰的候选同时仍保留在 state 的 candidate 中。四、REPORT 条目格式与示例逐段解析规范原文继承4.1 格式模板REPORT: History: [concise history of explored paths and rejected candidates] Candidate: [current candidate status, how it was found, checks against question clues, and uniqueness assessment] | Sources: [URL1, URL2, ...]4.2 示例一数学家变量教师关系确认原文给出的完整示例REPORT: History: For the mathematician variable, we began with several 19th‑century figures linked to Ada Lovelace (Charles Babbage, Augustus De Morgan, and George Boole), checking biographies and correspondence for explicit evidence of a teaching role; Babbage and Boole were rejected because sources describe them as collaborators or contemporaries rather than her formal tutor, and their institutional roles did not match the degree program in the question. Candidate: Augustus De Morgan was surfaced by targeted searches for Ada Lovelace calculus tutor and De Morgan teaches Ada Lovelace; one biographical entry explicitly states that De Morgan later tutored Ada Lovelace in mathematics at her mothers request, and a university archive notes that Lovelace studied calculus under Augustus De Morgan at University College London in the 1840s. Taken together, these excerpts satisfy the tutor-relationship and timeline clues, and we have not found another mathematician who fits them simultaneously, suggesting De Morgan is a unique fit. | Sources: url...逐段拆解其信息负载History 段交代了初始候选集Babbage、De Morgan、Boole 三位与 Ada Lovelace 相关的 19 世纪数学家、验证手段传记与书信中的教学角色证据、两条淘汰原因Babbage 与 Boole 在文献中被描述为合作者/同代人而非正式导师其机构角色与问题中的学位项目不符。Candidate 段给出候选发现路径Ada Lovelace calculus tutor、De Morgan teaches Ada Lovelace两组定向搜索、两处原文引证传记条目、大学档案、线索校验结论满足师生关系与时间线两条线索、唯一性评估未发现其他同时满足的数学家。Sources 段附上支撑来源 URL 列表。4.3 示例二城市变量港口城市 山顶教堂识别REPORT: History: For the city variable, we first tested several European port cities with major early‑20th‑century expositions (Paris 1900, London 1908, Hamburg 1903), comparing archival photos and maps to the questions description of a colonial exposition overlooked by a hilltop basilica above the harbor; Paris and London were ruled out because their exposition sites are inland and lack the specified basilica, while Hamburgs waterfront skyline does not feature a comparable hilltop church. Candidate: Marseille emerged by searching for 1906 colonial exhibition port city basilica on hill; a heritage article describes the 1906 Colonial Exhibition held in Marseille, showcasing Frances overseas possessions, and a tourism page notes that the basilica of Notre-Dame de la Garde stands on a limestone outcrop overlooking the Vieux-Port. These quoted passages jointly match the exposition and skyline clues, and we have not identified any other port city with both a colonial exhibition in this period and a comparable hilltop basilica, so Marseille is currently the only strong candidate. | Sources: url...该示例展示了 REPORT 模式对多属性联合约束的处理History 段按「博览会年份 港口位置 山顶教堂」三重特征逐个淘汰候选巴黎、伦敦因场地在内陆且无教堂被排除汉堡因滨水天际线无同类教堂被排除Candidate 段以一条查询同时命中展览与地貌两个线索并通过「无其他城市同时具备两个特征」完成唯一性论证。五、REPORT 条目如何进入状态补丁REPORT 条目是state状态补丁中discovered_clues字段的值。主提示词 deepsearch_run_action.md 规定了三种互斥的输出模式TOOL CALL MODE调用web_search/web_fetch/retrieve工具收集证据工具定义见 run_action.pyFINAL ANSWER MODE证据足以满足全部问题线索时输出answer块含answer、new_state可选discovered_cluesSTATE PATCH MODE研究方向已被充分探索但尚无最终答案时输出state块仅包含发生变更的变量。REPORT 模式下一个典型的state补丁形如state { new_states: [ { state: [ { id: 1, candidate: Augustus De Morgan, candidate_strength: 0.8, discovered_clues: [ REPORT: History: ... Candidate: ... | Sources: url1, url2 ] } ] } ] } /state注意补丁的三项约束见 deepsearch_run_action.md只写发生变更的变量不要重复整个 stateid、question_clues不可变不可增删变量、不可改 question_clues每项discovered_clues在 REPORT 模式下必须是完整列表整体替换语义type与question_clues不得出现在补丁中。5.1 无进展时的空补丁约定当动作被充分探索但无任何新信息时必须返回空补丁state{new_states:[]}/state以向编排器发出「动作完成」信号而不是无限循环调用工具。这同样适用于 REPORT 模式——即使没有新候选History 段也可记录「已探索、无进展」的路径供后续分支避免重复。5.2 与 candidate_strength 的协同REPORT 模式的 Candidate 段天然与candidate_strength置信度语义配套。主提示词定义了强度分档proven 0.9strong 0.7–0.9tentative 0.4–0.7weak 0.4。当某变量与其最终答案关联、且candidate_strength 0.7时模型必须直接输出最终答案而非状态补丁。REPORT 条目中的「唯一性评估」正是模型给强度打分的证据基础完成充分交叉验证并确认唯一 → 高强度仅部分线索满足、其他关联变量缺候选 → 用 0.4–0.7 的暂定分先行记录待后续动作补齐。六、源码级实现REPORT 条目如何被解析与落库6.1 模板选择链路run_action执行时按use_candidate_strength选择主提示词模板deepsearch_run_action或deepsearch_run_action_no_cs并通过build_react_prompt_context注入{{CLUES_SECTION}}段落run_action.py。deepsearch_run_action_no_cs.md与主模板结构一致仅不输出candidate_strength字段候选强度通过use_candidate_strength: bool配置开关控制默认 True。6.2 补丁应用逻辑apply_patch模型输出的state内 JSON 由parse_run_action_result提取run_action.py随后进入apply_patchrun_action.py合并到基态。对discovered_clues的处理分支discovered_clues_mode config.get(discovered_clues_mode, report) ... if discovered_clues in pv and pv[discovered_clues] is not None: if discovered_clues_mode none: nv.discovered_clues [] else: new_clues pv[discovered_clues] if isinstance(new_clues, list): nv.discovered_clues new_clues elif isinstance(new_clues, str): nv.discovered_clues [new_clues] ...从源码可见三个关键实现事实none模式在引擎侧被硬编码为强制清空[]即使模型违规携带了内容也会被剥离report与blacklist在落库层面共享同一「整体替换」路径——discovered_clues总是被补丁值替换而非追加与规范第 1 条一致模型偶尔把单条字符串而非列表输出时解析器会宽容地包装为单元素列表[new_clues]。此外apply_patch强制要求每个被补丁的变量必须携带不可变id且id必须存在于基态否则抛出RUN_ACTION_PARSE_ERRORrun_action.py。6.3 状态合并与多分支并行parse_and_apply_llm_result支持new_states数组携带多个分支补丁_normalize_new_states还会自动把「扁平变量字典」包装为独立分支每个分支经apply_patch生成一个新的 State 并全部加入all_merged_states。这意味着 REPORT 模式下同一变量的多个互斥候选可写成多个补丁分支进入并行探索——每条 REPORT 条目的 History 段记录了各自分支的探索足迹后续采样与验证节点据此决定取舍。6.4 校验器兜底配置中的validator_agent可开启validate_new_states/validate_answer默认 False开启后新状态会先经过验证器再落库run_action.py。验证器实现见 validate_new_state.py它会按isolated / linked / set模式核对候选与线索CandidateVerifiedClues输出每条线索的 pass/fail/pending 状态进一步保证了 REPORT 条目中「已对照线索校验」结论的可信度。七、配置与切换discovered_clues_mode 实战参数discovered_clues_mode定义于 config.py属于SearchWorkflowConfig.state_creation_agent即StateCreationAgentConfigdiscovered_clues_mode: Literal[report, blacklist] Field(defaultblacklist, description发现线索模式)在 README_search.md 的配置参考表中字段类型默认值说明use_candidate_strengthboolTrue是否将 candidate_strength 喂入动作打分discovered_clues_modeLiteral[report, blacklist]blacklistreport呈现线索过程blacklist抑制重复max_llm_calls_per_runint100单次 state_creation 内的 LLM 调用上限context_limit_reached_strategyLiteral[fail, reduced_retrieval_request, delete_tool_responses, delete_tool_input_and_responses]reduced_retrieval_request上下文超限时的重试策略切换为 REPORT 模式只需将配置置为search_workflow: state_creation_agent: discovered_clues_mode: report use_candidate_strength: true注意两个适用前提discovered_clues_mode的 Literal 类型仅含report与blacklist两个合法值none是build_react_prompt_context内部识别、但不作为公开配置枚举的隐藏模式若传入非法值会被兜底为blacklist模式影响的是注入提示词的线索段落与解析分支不会改变discovered_clues字段本身的数据结构始终是字符串列表。八、与 blacklist 模式的选型建议结合两者在提示词与实现上的差异选型建议如下需要跨轮次传递「调研过程」时选report适合多跳、多变量关联、需要后续 Agent 理解「为什么排除了 A、为什么选中 B」的复杂推理题如 BrowseComp 式多线索交叉验证。REPORT 的 History 段让每个并行分支独立可追溯避免重复劳动以候选池收窄为主时选blacklist淘汰逻辑简单直接、条目可多条并列适合「排除法」型问题与对 token 消耗更敏感的场景对线索记忆无需求时使用none强制空列表最大化压缩上下文。无论哪种模式都需遵守主提示词中的共同铁律线索中被淘汰的候选不得继续出现在candidate中You cannot have a candidate that is eliminated in the discovered_clues and still be a candidate in the state以及「无进展必须返回空补丁、禁止动作悬挂」的终止纪律。九、测试与验证依据仓库测试覆盖了 run_action 的完整路径与线索模式配置test_run_action.py 的_params构造器显式以discovered_clues_mode: report驱动测试验证成功路径successTrue、mode 路由、token 累计、重试耗尽返回失败、以及上下文超限时reduced_retrieval_request策略将top_k减半10→5、top_k_multiply_factor减半8→4的降级逻辑conftest.py 的base_actionfixture 预置了含discovered_clues[eiffel tower]的状态样例供各类状态补丁合并测试复用main_graph_nodes.py 的RunActionNode文档注释明确了空state是给编排器的有意信号而非错误工具调用经规范化后进入pending_tool_calls队列上下文超限可按策略修剪消息重试。十、编写高质量 REPORT 条目的最佳实践History 段写「决策过程」而非流水账保留候选集合、验证手段、淘汰理由三条主干信息冗余细节可随轮次压缩Candidate 段必须包含可核验的三要素发现方式搜索词/工具、原文引证quote extracts、线索满足情况与唯一性评估引文要短而高信号每个被更新变量恰好一条条目且携带完整 Sources 列表——这是解析器与后续校验器共同依赖的格式契约候选被淘汰时同步重写 HistoryREPORT 是整体替换语义旧条目中的失效信息需在重写中移除避免「已淘汰候选仍出现在线索中」的一致性冲突善用空补丁无进展时返回state{new_states:[]}/state并在 History 中记录「已探索但无收获」的方向为并行分支提供负样本信息与置信度分档对齐唯一性论证充分才给 strong0.7–0.9以上仅部分线索满足时用 tentative0.4–0.7关联变量缺候选的暂定候选不要虚高置信度。REPORT 模式将「排除法」升级为「研究履历法」它让 openJiuwen DeepSearch 的每个搜索分支都能携带自己的调研史进入下一轮推理从机制上支撑了片段级可溯源、多假设并行验证的深度搜索能力。理解并正确使用discovered_clues_mode的三种模式是定制与调优 Search Agent 推理行为的关键一环。赞分享人工智能大模型AI AgentRAG深度研究搜索引擎后端代码智能体【免费下载链接】deepsearchopenJiuwen DeepSearch是一款知识增强的深度搜索与研究框架有业界领先的片段级引用和溯源推理能力提供精准Agentic搜索与研究能力项目地址https://gitcode.com/openJiuwen/deepsearch点击查看免费下载相关推荐openJiuwen-DeepSearch 产品技术解析基于 agent-core 的知识增强深度搜索与研究引擎openJiuwen DeepSearch 产品技术解析基于 agent core 的知识增强深度搜索与研究引擎 本文系统梳理 openJiuwen Deep人工智能大模型AI AgentRAG深度研究搜索引擎后端代码智能体openJiuwen DeepSearch SearchContext 与 Workflow 状态契约研究报告与深度搜索的状态骨架openJiuwen DeepSearch SearchContext 与 Workflow 状态契约研究报告与深度搜索的状态骨架 openJiuwen De人工智能大模型AI AgentRAG深度研究搜索引擎后端代码智能体openJiuwen DeepSearch 深度搜索与研究引擎:系统架构、三模式部署与源码级实践指南openJiuwen DeepSearch 深度搜索与研究引擎:系统架构、三模式部署与源码级实践指南 openJiuwen DeepSearch 是一款知识增强人工智能大模型AI AgentRAG深度研究搜索引擎后端代码智能体创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考