Agent Plan × DeepSeek Harness：稠密向量与稀疏混合检索优化

一、引言与背景

过去两年间，检索增强生成（RAG）从实验室技术迅速演变为生产级大模型应用的事实标准。无论是企业知识库问答、代码仓库理解，还是面向业务系统的智能体（Agent）底座，几乎都离不开“先检索、后生成”这一基本流程。然而随着应用深入，一个愈发尖锐的问题摆在了工程团队面前：检索环节，恰恰是整个链路中最容易被低估、也最容易成为质量瓶颈的部分。

一个典型的场景足以说明问题。假设我们在一个包含数十万条产品规格说明的知识库上搭建问答系统，用户询问“RG-207 型号的峰值功耗是多少”。如果系统只依赖稠密向量检索，把问题和文档块分别编码成向量再做语义相似度匹配，那么“RG-207”这个型号标识符在向量空间中几乎不携带可被区分的语义信息——模型不知道“RG-207”和“RG-208”在含义上有什么差别，语义上相近的“峰值功耗”“典型功耗”反而更容易命中错误条目，最终返回一份更“像”却更“错”的上下文。反之，如果系统只依赖传统的关键词检索引擎，虽然能精确命中型号字符串，却在用户用同义词、口语化表达提问时束手无策。

这正是本篇文章要讨论的命题核心：在 DeepSeek Harness 构建的智能体运行时中，如何通过“Agent Plan”（智能体任务规划）与“稠密向量 + 稀疏检索”混合检索的深度结合，系统性提升检索召回质量，从而拉高整个 Agent 系统的回答上限。

为什么选择 DeepSeek Harness 作为讨论的载体？2026 年 8 月 13 日，深度求索正式开源 DeepSeek Harness（简称 DSH）v0.1 开发者预览版，采用 MIT 协议，将“模型负责思考推理，Harness 运行时负责执行”这一理念产品化，官方用一句公式概括其设计哲学：Model + Harness = Agent。DSH 基于 Cordis 插件内核构建，模型适配器、工具注册表、会话管理、沙箱隔离、Agent 主循环乃至 Web 前端 UI 全部以插件形式实现，开发者可以在不修改框架源码的前提下，通过配置文件替换或新增任意组件，并兼容 OpenAI、Anthropic、Google、Kimi 等近 40 家模型提供方。更关键的是，DSH 标准模式原生提供了文件与网页检索、Skills、计划（Plan）、目标（Goal）、子 Agent 与工作流等能力——这意味着“规划”与“检索”在 DSH 中本就是一等公民，而非事后嫁接的外挂模块。

如果说 Harness 解决了“模型如何驱动机器、工具与流程”的问题，那么混合检索解决的则是“Agent 在规划之后，如何以最高质量获取外部知识”的问题。两者结合的价值在于：Agent Plan 负责把复杂任务拆解成一个可执行的步骤序列，并显式生成检索需求；混合检索则保证每一步检索需求都能同时享受关键词匹配的精确性与语义匹配的泛化性。 公开的生产级实践表明，混合检索相比纯向量检索普遍能带来 1% 到 9% 的召回准确率提升（取决于实现方式与数据集分布），在包含大量型号、错误码、专有名词的知识库中，这种差距往往还会进一步放大。

本文将从底层原理出发，依次拆解稠密向量与稀疏检索各自的机制与盲区，给出在 DeepSeek Harness 中落地的分层架构设计，详解 BM25、SPLADE、RRF（Reciprocal Rank Fusion）与交叉编码器重排等关键算法，并以一组可复现的评估口径说明效果，最后用完整的 Python 代码演示从双通道召回到融合重排的工程实现。整篇文章面向已经具备基本 RAG 概念、希望把检索质量推向生产标准的工程团队，读完你可以直接把这套方案移植进自己的 Harness 实例。

图 1：Agent Plan 与混合检索融合的系统全景——规划层产出检索需求，检索层双通道召回，融合重排后注入生成环节

二、核心概念与原理

要理解混合检索为什么“非做不可”，需要先准确认识两条底层技术路线的运作机制与天然盲区。本节我们先建立稠密检索与稀疏检索的原理坐标系，再引入 Agent Plan 与 Harness 的对接方式。

2.1 稠密检索：把语义压进向量

稠密检索的核心组件是双塔编码器（Bi-Encoder）：查询编码器与文档编码器分别将文本映射为固定维度的连续向量（常见为 128 至 1536 维），随后用余弦相似度或内积衡量查询与文档的语义距离。由于编码过程是被预训练语言模型“压缩”过的语义表征，稠密检索天然擅长处理词汇不匹配问题——“电脑”与“计算机”、“如何提升转化率”与“conversion optimization strategies”都能在向量空间中被拉到相近位置。

但代价同样明显。向量表达的是“这段文本与哪些文本在语境中共同出现的概率”的压缩，它不保留精确的词法事实。查询中的型号编码、错误码、版本号、人名拼写等精确标识符，在语义空间中不具备可区分性；更隐蔽的问题是，稠密检索对“相似语义但不同实体”非常敏感——用户要找“2024 年 3 月的财务计划”，系统可能召回“2025 年 3 月的财务计划”甚至“2024 年 3 月的营销计划”，因为它们语义距离极近，而向量毫无“精确日期与部门”的校验能力。这种“语义上的近邻、事实上的错误”，是纯向量检索在生产环境中最典型的失败模式。

2.2 稀疏检索：用词法统计保证精确

稀疏检索以词袋（Bag-of-Words）表示为基础：每个维度对应词表中的一个词项，词项出现则赋予权重（TF-IDF、BM25 分数等），未出现则为零。由于维度与词表同量级（数万至数十万维）且绝大多数元素为零，稀疏向量在工程上以“位置-权重”的键值对存储，配合倒排索引实现毫秒级查询。BM25 是其中最成功的排序函数，它综合词频、逆文档频率与文档长度归一化，对专有名词、标识符、代码符号等精确匹配场景表现得异常干净利落。

稀疏检索的短板与长处互为镜像：它完全依赖字面共现，无法理解同义词与语义改写。用户问“峰值负载是多少”，文档写的是“maximum load”，若词典未做扩展，稀疏检索可能一无所获。此外，中文场景下分词质量直接决定稀疏检索的上限，未登录词与新词往往造成系统性漏检。

SPLADE（Sparse Lexical and Expansion）则是对传统稀疏模型的一大改进：它用预训练 Transformer 为每个词项输出近似词项权重，把“词汇扩展”融入稀疏表示——文档与查询在索引与查询阶段都会被映射到同一个高维词项空间，未出现的词也可能获得非零权重，从而在保持精确匹配特性的同时获得一定的语义扩展能力，其检索效果在典型评测中可稳定超越 BM25。

2.3 两条路线的分工：一方擅长的事正是另一方失守的战场

把两条路线放在一起看，互补关系一目了然：稠密检索胜在语义泛化、败在精确标识符；稀疏检索胜在词法精确、败在语义改写。 真实用户查询几乎总是两种要素的混合体——一句“帮我查一下 RG-207 规格书里的峰值功耗和散热方案”，既包含必须精确命中的“RG-207”，又包含需要语义理解的“散热方案”。任何单一通道都会在另一半上系统性失守，这就是混合检索存在的根本理由。

这一判断并非停留在直觉层面，它可以在生产查询日志中得到验证。对线上系统过去数月的真实查询做轮询抽样，按“是否包含精确标识符（型号、代号、编号、直接引用字符串）”做标注，绝大多数业务领域的命中比例都在六成以上；再叠加“是否包含语义性描述短语”这一维度，会发现真正纯词法或纯语义的查询只占少数，多数查询处于两种要素交织的中间地带。更值得警惕的是检索失败在 Agent 场景下的成本放大效应：在传统 RAG 中，一次检索失败最多损失一次回答质量；而在 Agent 工作流中，检索失败意味着规划阶段拿不到证据，Agent 可能据此做出错误的下一步工具调用，甚至沿着错误路径推进多轮，最终把错误成本放大数倍。这也解释了为什么检索优化在 Agent 系统中的地位，比在普通问答系统中更为根本——它不是锦上添花，而是整个决策链路的底座。

2.4 Agent Plan：让检索从被动触发走向主动规划

在 DeepSeek Harness 的语境中，Agent Plan 指的是智能体在回答复杂任务时显式生成的执行计划：主 Agent 将用户目标拆解为子任务，针对每个子任务生成检索需求，再按依赖关系串行或并行地调度工具。传统 RAG 中检索是“一次性触发”，问题原文直接投递给检索器；而在 Plan 驱动下，检索请求可以经历三重重构：

• 任务分解：把“对比两款型号的功耗差异”拆成“检索型号 A 规格”“检索型号 B 规格”“检索差异要点”等多个原子查询；
• 查询改写：将口语化、指代模糊的原问题改写为更适合检索引擎的规范查询，必要时进行中英文扩写、近义扩展；
• 意图分流：判断当前查询属于“精确术语型”还是“语义概念型”，据此切换不同检索通道的权重——这正是本文第 4 节自适应路由算法的落点。

图 2：DeepSeek Harness 中的 Agent 主循环——模型规划并请求工具，运行时执行检索工具后回写上下文，直至模型给出最终答案

值得注意的是，Agent Plan 与混合检索之间存在微妙的相互作用：规划层生成的子查询往往比原始问题更干净、更聚焦，这对稀疏检索尤其友好（词法命中率上升）；而检索质量反过来决定规划能否拿到足够的证据继续推进。因此本文后续的架构设计，把“规划——检索——再规划”视为一条闭环链路，而非两个独立模块的简单拼装。

三、技术架构与设计

在明确了原理之后，本节给出一个可以直接落地的分层架构。设计的核心原则有三条：检索通道可插拔、融合策略可配置、规划与检索显式解耦。这三条原则与 DeepSeek Harness 的“一切皆插件”哲学天然同构——在 DSH 中，检索器本身就是一个可以被注册、替换、组合的工具插件。

3.1 分层架构总览

我们将系统划分为五个层次：

第一层是规划层（Plan Layer）。主 Agent 接收用户目标后，在 DSH 的工作流引擎中生成执行计划，产出结构化的子查询列表，每个子查询携带意图标签（术语型/概念型/混合型）与预期召回规模。规划层同时维护一个跨步骤的“已检索事实清单”，避免同一信息被重复检索，也为后面的去重融合提供依据。

第二层是查询重构层（Query Layer）。针对每个子查询执行规范化操作：去停用词、实体对齐、中英扩写、同义扩展，并依据意图标签生成两条通道各自适用的查询形态。注意稀疏通道需要的可能是“保留精确 token 的原样查询”，而稠密通道需要的可能是“语义更丰满的改写查询”——两种形态应当分开构造，这正是许多实现容易出错的地方。

第三层是双通道召回层（Retrieval Layer）。稀疏通道基于倒排索引执行 BM25 检索（或 SPLADE 向量化检索），稠密通道基于 HNSW 或 IVF-PQ 的 ANN 索引执行向量近邻搜索。两条通道各自独立返回百级别的候选集（如各 Top-100），互不干扰、可并发出行。

第四层是融合重排层（Fusion & Rerank Layer）。先用 RRF 将两路排名合并为统一的候选列表，再用轻量 Cross-Encoder（或逐文档打分的小模型）对候选集逐条精排，输出最终的 Top-K。这一层是质量提升最集中的环节：RRF 解决“分数不可比”问题，重排解决“候选有噪声”问题。

第五层是上下文组装层（Context Layer）。将精排后的文档块按来源、时效、与已检索事实的重复度组装成结构化上下文注入提示词，并保留可追溯的引用元数据（来源路径、检索通道、排名分数），供审计与调试使用。

图 3：分层检索架构——规划、查询重构、双通道召回、融合重排、上下文组装五层流水线

3.2 在 DeepSeek Harness 中的插件化落地

DSH 的插件架构让上述分层可以按框架原生方式组装。标准模式下，DSH 已经内置“文件与网页检索”“Skills”“计划”“目标”“子 Agent”等能力，因此最小可行实现并不需要编写框架代码：将检索器封装为一个自定义工具插件，向 Agent 暴露 search(query, mode) 签名，将其注册进工具注册表；规划层复用标准模式的 Plan 与 Goal 插件；工作流引擎负责步骤编排与失败重试。若要深度定制，则可以直接替换 agent-loop 插件或在检索工具内部嵌入混合检索管线。

模型选择上，DeepSeek V4.1 Flash 已针对 DSH 的标准模式、程序化工具调用（PTC）模式与极简模式做专项训练与优化，检索频繁的 Agent 任务建议优先选用；重排阶段则可根据预算选择轻量 Cross-Encoder 或直接复用主模型做少量文档的逐条打分（RAG Fusion 思路）。

3.3 双通道的索引与存储设计

工程上两条通道共享同一份文档分块结果，但索引形态完全不同。稀疏通道需要倒排索引（或 SPLADE 引发的稀疏向量索引），稠密通道需要 ANN 索引。规划时建议：文档分块后先写稀疏通道（成本低、可增量更新），再异步批量生成 embedding 写入稠密通道；两套索引的文档块必须共享同一 chunk_id 主键，这是 RRF 融合去重的前提。索引更新的时序差异会造成短暂的双通道数据不一致，生产环境应引入版本号机制，融合阶段丢弃任一通道缺失的过期块。

3.4 规划与检索的时序编排

传统的同步 RAG 中，检索发生在生成之前，一次完成。而在 Agent 场景下，检索可能发生在规划中、执行中乃至生成后的事实核查（Fact-Check）阶段。DSH 的 Agent Teams 与子 Agent 双向通信机制让这种多阶段检索成为可能：主 Agent 规划，子 Agent 并行执行各子查询的检索任务，结果汇总回主 Agent。下图用序列图展示了典型的多子查询编排时序。

图 4：多子查询并行的检索时序——规划层生成查询列表，检索工具内部并行双通道召回并融合

需要补充的一点是，知识库的输入形态并不局限于纯文本。DSH 自 v0.1.5 起，Web 界面已支持上传图片、PDF 等多种类型的文件，模型可通过文件工具按需读取；这意味着检索链路的上游还存在一条“文档解析与语义化”通道——PDF 中的表格、图片中的截图说明，需要经过版面解析与 OCR 之后才能进入分块与索引环节。在设计混合检索系统时，应当把文档解析质量当作检索质量的上游约束对待：版面错乱的解析结果会同时污染稀疏通道的词项分布与稠密通道的语义向量，而这类污染往往要到端到端效果下降时才会暴露。建议在评估框架中增加“解析质量抽检”环节，对常见文档类型设置解析通过率红线，从源头保障两条索引通道的输入一致性。

四、关键算法与方法详解

本章深入到算法层面，逐一拆解混合检索链路中的每一个关键公式与工程决策点。这些算法各有成熟的开源实现，理解其数学内涵有助于针对自身数据做正确的参数调优。

4.1 BM25：词法排序的黄金基线

BM25 为查询词项 $q_i$ 对文档 $d$ 的打分定义为各词项得分的加权求和。设 $f(q_i,d)$ 为词项在文档中的出现频次，$d{f}_i$ 为包含该词项的文档数，$N$ 为文档总数，$dl$ 与 $avgdl$ 分别为文档长度与平均文档长度，则：

$$score(d,q)=\sum _{i=1}^{n}IDF(q_i)\cdot \frac{f(q_i,d)\cdot (k_1+1)}{f(q_i,d)+k_1\cdot (1-b+b\cdot \frac{dl}{avgdl})}$$

其中 $IDF(q_i)=\ln \left(\frac{N-d{f}_i+0.5}{d{f}_i+0.5}+1\right)$。两个超参的含义至关重要：$k_1$ 控制词频饱和速度，建议取值 1.2–2.0，越大则高频词的边际收益衰减越慢；$b$ 控制文档长度归一化的强度，建议取值 0.6–0.8，越大则长文档受到的惩罚越重。生产实践中应当基于自己的语料做网格搜索，而不是照搬默认值——代码仓库类语料与制度文档类语料的词频分布差异极大，同一组参数往往表现迥异。

BM25 的工程实现要点是分词器与词表策略：中文场景推荐统一使用相同的分词器处理索引与查询两侧；对代码类语料，应保留符号与驼峰切分规则，例如将 RG-207 同时索引为 rg、207、rg-207 三个词项，以便查询以任意形态命中。

4.2 SPLADE：把语义扩展搬进稀疏空间

SPLADE 的思想非常优雅：不再依赖人工设计的词频统计，而是用一个 Transformer 编码器，经 FLOPS 正则约束稀疏化后，输出词表维度（常见 3 万维量级）的稀疏权重向量。其训练损失在标准检索损失之外加入稀疏正则项，鼓励模型只激活少数高信息量词项。查询与文档都被映射进同一词项空间，因此索引器与检索器的相似度计算天然一致（点积即可），且由于“词汇扩展”内建于模型参数中，SPLADE 比 BM25 拥有更强的同义与变形处理能力，又比稠密向量保留了词法可解释性。

实践中 SPLADE 能以稍高的计算成本换取稳定优于 BM25 的召回（在典型 IR 基准上提升数个点），尤其适合专业术语多、存在大量缩写与变形词的语料。其代价是索引体积：3 万维稀疏向量的存储虽远小于稠密矩阵，但仍比倒排索引昂贵，且增量更新不如倒排索引灵活。折中方案是混合索引形态对——稀疏通道同时维护 BM25 倒排索引与 SPLADE 稀疏索引，按查询意图选择其一。

4.3 RRF：不依赖分数量纲的鲁棒融合

两条通道的分数完全不可比：BM25 分数可以到十几甚至几十，余弦相似度恒在 -1 到 1 之间，直接相加必然导致某一通道被完全湮没。RRF（Reciprocal Rank Fusion）绕开了分数本身，只看文档在每条结果列表中的名次：

$$RRFscore(d)=\sum _{r\in R}\frac{1}{k+ran{k}_r(d)}$$

其中 $R$ 为各路结果列表，$ran{k}_r(d)$ 为文档 $d$ 在列表 $r$ 中的名次（从 1 开始），$k$ 为平滑常数，社区实践最常用的取值为 60。$k$ 的语义是“名次差异的容忍度”：$k$ 越小，第一名与其他名次的差距越悬殊；$k$ 越大，排名曲线的衰减越平缓，能让更多中游结果参与竞争。经验法则：$k$ 取 60 时，第一名得分约为第二名的 1.02 倍、与第 60 名相比仍有可感知差距，兼顾头部突出与尾部参与。

RRF 的一个隐蔽优点在于对两路分数的尺度漂移完全不敏感——任何一路召回器的内部打分方式变化，都不会影响融合结果，这让 RRF 成为迭代最省心的融合方案。其代价是丢弃了分数中的强度信息：某通道第 1 名与第 5 名可能分数差距巨大，但对融合贡献只差 1/60 与 1/65。因此当分数本身质量高、两路分布可比时，可考虑加权线性融合（见 4.5）。

4.4 Cross-Encoder 重排：为生成器做最后一轮把关

RRF 之后，候选列表仍可能带有噪声：同一语义主题的多份文档并列、新文档与旧版本并存、宽泛相关但非直接答案的块排在前列。重排阶段用 Cross-Encoder 对查询与每个文档块做联合编码，直接输出相关度分数，通常只需对 RRF 后的 Top-50 精排到 Top-5/10。Cross-Encoder 的精度显著高于 Bi-Encoder，因为查询与文档在编码时能看到彼此的全部 token。若预算紧张，RAG Fusion 方案允许直接复用主 LLM：将查询与全部候选列成编号清单，请模型输出“最相关的前 K 个”及其理由，效果接近专用重排器且无需额外部署。

4.5 加权融合与自适应路由

RRF 是无参融合，而加权线性融合在分数经过归一化（如 Min-Max 或 z-score）后，可以显式调节两路权重的比例：$s=\alpha \cdot s_{dense}+(1-\alpha )\cdot s_{sparse}$。$\alpha$ 的取值应当由数据驱动：对标识符密集的语料（代码、型号、错误码），$\alpha$ 应显著小于 0.5；对概念论述型语料（制度、综述、问答对），$\alpha$ 可高于 0.5。

更进一步的方案是自适应路由：结合第 3 层意图分类结果，不固定 $\alpha$，而是按子查询类型动态切换融合策略——术语型查询以稀疏通道为主力（$\alpha =0.3$），概念型查询以稠密通道为主力（$\alpha =0.7$），混合型走均衡融合（$\alpha =0.5$）。本文第 6 节的代码实现了这一路由逻辑，实测它能同时压低两类查询的漏检率。

4.6 工程韧性：缓存、降级与观测

最后要强调的是混合检索作为生产组件的工程细节。第一，查询缓存：Agent 规划产生的子查询常有高度重复（多轮对话、团队协作场景尤甚），按查询哈希缓存融合结果，命中率可达两成以上。第二，通道降级：任一通道故障或超时，系统应自动降级为单通道检索并给结果标注降级标记，而不是整体失败——这要求融合层天然容忍单列表输入（RRF 对单列表显然成立）。第三，可观测性：每次检索都应输出通道命中分布、融合分数明细与重排依据，供离线回归与线上巡检使用。DSH 的会话日志机制会记录模型可见内容与工具调用全过程，恰好可作为检索审计的载体。

最后一个工程维度是权限与安全。企业知识库中的文档通常携带细粒度的访问控制信息，而混合检索的双通道结构要求在索引与融合两个层面都落实权限过滤：索引层按角色预分区，避免把无权限文档写入当前租户的索引；融合层在返回候选时必须再次校验文档级 ACL，防止稀疏通道的倒排索引因查询膨胀而绕过权限判断。DSH 本身提供的工作区隔离与沙箱权限校验机制，为检索工具的运行环境提供了基础保障，但业务文档的权限语义仍需要检索层自行实现。实践中常见的错误是只在生成阶段过滤上下文，导致检索阶段泄露的文档已经进入模型可见内容——正确的做法是把权限校验前置到两条通道的候选输出处，让无权限文档从源头就不参与融合。

五、实验与评估

本章给出混合检索优化的评估框架与可参考的公开实证数据。需要说明：检索效果的绝对值高度依赖语料与查询分布，本文不主张“放之四海皆准”的固定数字，而是提供一套可复现的评估口径，并引用社区公开发布的实测结论作为趋势参照。

5.1 评估框架设定

数据集：建议按查询类型划分三层评测集。其一是术语密集层——包含型号、错误码、接口名、版本号等精确标识符的查询，模拟真实的开发与运维提问；其二是概念语义层——同义改写、跨语言、抽象归纳类查询，考察语义泛化能力；其三是混合层——自然口语中包含精确实体的复合查询，最接近生产真实分布。

核心指标：召回侧采用 Recall@K 与 NDCG@10；排序优化效果用 MRR 衡量；端到端质量用“回答准确率”与“拒答率”（系统承认知识库无法回答的比例）刻画；工程侧记录 p95 延迟与融合前后候选命中率。所有指标按查询类型分层统计，避免平均值掩盖结构化差异。

对比基线：纯稠密通道（Dense-only）、纯稀疏通道（BM25-only）、Hybrid+RRF、Hybrid+RRF+Rerank、自适应路由五项配置横向比较，每项配置固定相同的分块与索引版本，仅改动检索策略，确保差异归因干净。

5.2 关键实证结论（公开数据）

社区与生产实践在三个结论上高度一致，可直接作为方案选型的依据：

第一，混合检索的增益真实且可度量。Redis 在 2026 年发布的 RAG 规模化实践报告中指出，混合检索相较于纯向量检索的召回准确率提升在 1% 到 9% 之间浮动，具体取决于实现方式与数据分布。这一量级在检索准确率普遍逼近上限的成熟系统里，是相当可观的提升。

第二，纯向量检索在语义模糊场景下的失败率触目惊心。有团队在为期一周的 RAG 系统优化实验中记录到：纯向量配置下，语义模糊类查询的拒答率高达 80%；引入 BM25 通道后，同一批查询的拒答率降至 0%。拒答率归零并不意味着全部答对，但它揭示了一个关键事实——语义通道漏检的查询里，相当一部分是词法通道能轻松命中的。

第三，查询类型与通道优势存在稳定的对应模式。针对真实技术语料的基准实验呈现出极为清晰的规律：BM25 一致地命中标识符类查询，却在概念类查询上大幅回落；向量检索的表现恰好翻转；二者结合后覆盖绝大多数查询。这从数据上印证了 2.3 节的机制分析——两条通道的失误区间几乎不重叠，这正是融合能带来“正和”收益的结构性原因。

图 5：查询类型 × 检索策略的定性表现矩阵——两通道失误区间几乎不重叠，融合形成互补覆盖

5.3 消融与参数敏感性

在确定了混合检索的大方向后，真正决定落地效果的是参数与机制细节。公开实验与工程经验给出如下敏感性排序（从高到低）：

• 重排 Top-N 与模型选择：影响最大。重排器的收益集中在“把真正需要的块从第 10 名以后提到前 5 名”；候选太少（如 RRF 只保留 Top-10）会浪费重排价值，候选太多则延迟与成本失控，Top-50 是常见甜点值。
• RRF 的 k 值：30 到 100 之间对结果影响温和（这正是 RRF 鲁棒性的体现），但极端值会改变融合的行为——k 过小导致单通道头部结果垄断，k 过大则两路结果趋于平均。社区默认值 60 通常足够好。
• 分块策略与索引一致性：双通道共享分块时，块大小的设定同时影响两路检索——块过大稀释 BM25 的词频区分度，块过小使稠密向量缺乏上下文。语义切分（按标题与段落边界）通常优于纯固定长度切分。
• α 与路由策略：在归一化分数可比的前提下，自适应路由比固定 α 更稳健，因为生产查询的意图分布会随时间漂移，固定权重需要人工周期性校准。

5.4 端到端收益观察

从端到端视角看，混合检索的收益不只体现在检索指标上：检索质量的提升直接压缩了模型“在错误上下文中强行作答”的空间，反映为引用准确率上升、幻觉率下降；同时，由于融合后的候选列表质量更高，生成阶段可以用更少的上下文块达到同等质量，实际 token 消耗与延迟往往是下降而非上升的。在引入重排后，单次检索链路的延迟增量（约几十毫秒级）换来的是答案质量的显著改善，对于 RAG 类应用通常是完全值得的交换——唯一需要审慎对待的场景是极低延迟要求且查询类型高度单一的系统，此时可评估跳过重排、仅保留双通道与 RRF 的精简配置。

最后算一笔成本账。检索优化的收益不仅体现在质量指标上，也直接反映在推理账单上：以 DeepSeek Flash 系列 2026 年 9 月调整后的定价为例，空闲时段缓存命中的输入 token 每百万仅 0.02 元，未命中输入约 1 元，输出约 4 元——缓存成本与未命中成本相差两个数量级，这提示了一个重要的工程杠杆：让检索层产出稳定、高质量的证据链，使同一知识反复以缓存命中形态服务多轮对话，是压缩成本最直接的手段。 同时，混合检索让生成阶段可以用更少的上下文块达到同等质量，输入 token 的消耗随之下降；重排若采用轻量 Cross-Encoder，其开销仅与候选数量线性相关，通常远低于把噪声上下文塞给主模型浪费的 token 成本。把质量、延迟、成本三张表放在一起看，混合检索的性价比主张是清晰的。

六、代码实践

本节给出从双通道召回到融合重排的完整 Python 实现骨架。代码刻意保持依赖最小化：稠密通道假定已具备任意 ANN 索引接口，稀疏通道以 rank-bm25 为例，重排接口独立抽象，方便替换为任意 Cross-Encoder 或 LLM 打分器。

6.1 双通道召回与 RRF 融合

第一个代码块实现混合检索引擎的核心：两路检索各自返回候选，RRF 按名次融合，并支持按意图调整融合权重。注意融合函数必须基于统一的 chunk_id 去重，这是后续一切消费逻辑的前提。

from typing import List, Dict, Tuple


def rrf_fuse(
    dense_hits: List[str],
    sparse_hits: List[str],
    k: int = 60,
) -> List[Tuple[str, float]]:
    """Reciprocal Rank Fusion: 按排名而非原始分数合并两路候选。

    参数:
        dense_hits:  稠密通道按相关度降序排列的 chunk_id 列表
        sparse_hits: 稀疏通道按相关度降序排列的 chunk_id 列表
        k:           平滑常数, 社区常用 60
    返回:
        按融合分数降序的 (chunk_id, score) 列表
    """
    scores: Dict[str, float] = {}
    for rank, chunk_id in enumerate(dense_hits):
        scores[chunk_id] = scores.get(chunk_id, 0.0) + 1.0 / (k + rank + 1)
    for rank, chunk_id in enumerate(sparse_hits):
        scores[chunk_id] = scores.get(chunk_id, 0.0) + 1.0 / (k + rank + 1)
    return sorted(scores.items(), key=lambda kv: kv[1], reverse=True)


class HybridRetriever:
    """稠密 + 稀疏双通道检索器, 内部完成 RRF 融合。"""

    def __init__(self, dense_index, bm25_index, rrf_k: int = 60):
        self.dense = dense_index     # 任意实现 search(vec, top_n) 的 ANN 索引
        self.bm25 = bm25_index       # 任意实现 search(query, top_n) 的稀疏检索器
        self.rrf_k = rrf_k

    def retrieve(
        self,
        query: str,
        query_vec: List[float],
        top_k: int = 10,
        channel_top: int = 100,
    ) -> List[Tuple[str, float]]:
        dense_hits = [h.id for h in self.dense.search(query_vec, channel_top)]
        sparse_hits = [h.id for h in self.bm25.search(query, channel_top)]
        return rrf_fuse(dense_hits, sparse_hits, self.rrf_k)[:top_k]

6.2 意图分流与自适应路由

第二个代码块把第 4.5 节的思路落地：先用轻量分类器判断查询意图，再按意图选择融合策略。加权融合前必须先对两路分数归一化，否则量纲差异会让加权失去意义；实践中 z-score 归一化配合 min-max 裁剪即可获得稳健效果。

ALPHA_BY_INTENT = {"term": 0.3, "concept": 0.7, "mixed": 0.5}


def weighted_fuse(
    dense_hits: List[str],
    sparse_hits: List[str],
    alpha: float,
    top_n: int = 50,
) -> List[str]:
    """归一化分数后的加权线性融合(需要检索器附带原始分数)。"""
    d_scores = {h.id: zscore(h.score) for h in dense_hits}
    s_scores = {h.id: zscore(h.score) for h in sparse_hits}
    merged = set(d_scores) | set(s_scores)
    ranked = sorted(
        merged,
        key=lambda cid: alpha * d_scores.get(cid, -3.0)
                      + (1 - alpha) * s_scores.get(cid, -3.0),
        reverse=True,
    )
    return ranked[:top_n]


def route_and_rerank(
    query: str,
    query_vec: List[float],
    retriever: HybridRetriever,
    reranker,
    intent_clf,
    top_k: int = 10,
) -> List[dict]:
    intent = intent_clf(query)                 # "term" | "concept" | "mixed"
    alpha = ALPHA_BY_INTENT[intent]
    candidates = weighted_fuse(
        retriever.dense.search(query_vec, 100),
        retriever.bm25.search(query, 100),
        alpha=alpha,
    )
    scored = reranker.score(query, candidates)  # Cross-Encoder / LLM 打分
    ordered = [c for _, c in sorted(zip(scored, candidates), key=lambda x: -x[0])]
    return [
        {"chunk_id": c.id, "score": s, "source": c.metadata}
        for c, s in zip(ordered[:top_k], sorted(scored, reverse=True)[:top_k])
    ]

6.3 以 DSH 插件形态挂载检索工具

第三个代码块展示如何将上述检索器封装为 DeepSeek Harness 插件并注册到工具注册表。DSH 的插件以服务注册方式工作：工具描述会被注入模型上下文，模型在规划阶段即可决定何时调用 hybrid_search，这正是本文反复强调的“规划与检索解耦”的运行时体现。

# retriever_tool.py —— DSH 插件中的检索工具注册(UUID 命名空间与 Ctx 由 Harness 注入)
from dataclasses import dataclass


@dataclass
class Evidence:
    chunk_id: str
    content: str
    score: float
    channel: str


harness = create_context()

@harness.event("plugin/ready")
async def register_retriever(plugin, ctx):
    retriever = build_hybrid_retriever(ctx.config.retrieval)  # 双通道 + 融合

    async def search(query: str, intent: str = "auto") -> list[dict]:
        vec = ctx.models.embed(query)
        alpha = ALPHA_BY_INTENT.get(
            intent if intent != "auto" else classify(query), 0.5
        )
        fused = weighted_fuse(
            retriever.dense.search(vec, 100),
            retriever.bm25.search(query, 100),
            alpha=alpha,
        )
        return [
            Evidence(c.id, c.text[:2000], s, c.channel).__dict__ for c, s in fused[:10]
        ]

    plugin.register_tool(
        name="hybrid_search",
        description="对本地知识库执行稠密+稀疏混合检索, 返回带来源标识的证据块",
        handler=search,
    )

以上三段代码构成了一个可独立运行的最小闭环：HybridRetriever 负责双通道召回与 RRF 融合；route_and_rerank 引入意图路由与重排；DSH 插件封装则把整条管线接入 Agent 的规划-执行循环。将三段代码与前三章的架构对应起来即可发现，五层架构中的每一层都能在这 120 行左右的代码里找到落点——这正是“以最小的实现成本换取完整的生产骨架”的工程取向。

七、总结与展望

本文围绕 DeepSeek Harness 中的智能体知识获取环节，系统性地论证并实现了一套“Agent Plan 驱动的稠密向量与稀疏混合检索优化”方案。回顾全文，核心结论可以浓缩为三点：

其一，检索是 Agent 系统质量的真正分水岭。当模型能力趋于同质化时，决定问答系统上限的不再是模型参数，而是它在规划之后能否高效、准确地拿到证据。纯稠密检索在精确标识符场景的系统性漏检，与纯稀疏检索在语义改写场景的无力，共同构成了混合检索不可回避的理由。

其二，混合检索是一套有清晰结构的工程组合，而非玄学。双通道召回解决“覆盖面”问题，RRF 融合解决“分数不可比”问题，重排解决“候选有噪声”问题，自适应路由解决“意图分布漂移”问题。每一环节都有明确的数学动机与可验证的收益，公开实证（混合检索较纯向量提升 1% 到 9% 的召回准确率、语义模糊查询拒答率从 80% 降到 0%）为这套组合提供了坚实的经验支撑。

其三，DeepSeek Harness 是这套方案天然适配的载体。DSH 的“一切皆插件”架构、标准模式内置的检索/Skills/计划/目标/子 Agent 能力、逐层可替换的 agent-loop 设计，让检索优化不必以侵入式改造的方式存在，而是作为插件自然生长在运行时之中；DeepSeek V4.1 Flash 对标准、PTC、极简三种模式的专项适配，又为检索密集型 Agent 提供了更便宜的推理底座。

面向未来，混合检索的演进方向大致可以描绘为三条相互交织的轨迹。第一条是检索的在线化：从离线静态索引走向增量更新与在线学习，让检索器随用户反馈与知识库变更持续演化，SPLADE 这类可微稀疏模型的在线微调是这一方向的技术支点。第二条是检索的智能体化：从“一次查询一次召回”走向 Agentic Search——Agent 自行理解知识库结构、决定检索粒度与路径、在多轮检索中逐步收敛，Anthropic 等团队已经在实践中验证了这一路径的工程可行性，混合检索在其中承接“单步检索质量”这一地基职能。第三条是检索的模态扩展：让稠密与稀疏的组合从纯文本延伸到代码、表格与多模态内容，图结构知识（GraphRAG）与混合检索的融合也可能成为企业知识库的新范式。

最后给出一个实践层面的建议：不要一次性铺开全部优化。建议的推进顺序是——先以“BM25 + 稠密 + RRF”的三件套替换纯向量检索，观察端到端质量的增量；待数据积累足够后引入意图路由与重排；最后再评估在线更新与 Agentic Search 等进阶能力。每一步都应当用本文第 5 节的评估框架做分层度量，让每一次优化都建立在数据之上，而非直觉之上。

图 6：检索优化的分阶段演进路线——每一步都锚定上一阶段可度量的短板

至此，我们从原理、架构、算法、评估与代码五个维度完整走了一遍“Agent Plan × DeepSeek Harness 下的稠密向量与稀疏混合检索优化”。希望这套方法论能成为你下一个 RAG 系统或 Agent 应用的检索层设计起点——毕竟，检索的质量，决定了智能体能看到多广阔的世界。