MiroThinker-v1.5：从检索规划到自评反思，打造最强搜索智能体

前几天在社区聊Agent应用时，有位朋友问我：搜索场景为什么非要单独做一个智能体，直接让大模型联网不就行了？我拿这次放出的MiroThinker-v1.5实测数据给他算了笔账：同样一堆来源片段，普通联网问答能把一半信息整合对，带上检索规划、结果反思和引用校验之后，整段答案的完整度与准确率直接上了一个台阶。这个版本也是我们在内部评测榜上第三次刷新名次，所以标题说“最强搜索智能体”不算夸张，更多是这一个多月迭代下来的水到渠成。

这篇内容适合正在做Agent、检索增强生成或者对话式搜索产品的开发者，也适合那些纠结“大模型联网为什么经常答非所问”的入门朋友。我会把MiroThinker-v1.5从问题拆解、架构设计、模块实现到评测调优的完整链路摊开讲，大部分方案都是基于常见实践的补充，你可以直接照搬，也可以按自己的场景改。

1. 为什么要做搜索智能体：传统检索与大模型之间的三座山

1.1 关键词匹配与真实意图之间的鸿沟

传统搜索的核心逻辑是关键词匹配，系统把用户输入拆成词，再去倒排索引里找包含这些词的网页。这套机制在信息检索时代够用，但放到今天的内容环境里，问题很明显：用户很少用网页原文里的词表达需求。

举个例子，“孩子发烧到38.5度需要马上捂汗吗”，网页标题大概率是“儿童发热的居家护理要点”或者“退烧过程中的常见误区”，“捂汗”这个词在正规医学内容里可能压根不会出现。传统搜索返回十条链接，用户得自己逐一打开、自己判断哪条权威、自己把碎片化信息拼成答案。这种“自己动手拼接”的模式，在有明确关键词的场景下还能凑合，一旦问题是多跳推理或者需要对照多个来源，效率就断崖式下跌。

我见过太多用户在一个搜索框里反复换说法，本质原因不是他们不会搜，而是他们的语言习惯和信息页面的语言习惯之间存在偏移。搜索智能体要做的第一件事，就是先在语义层把用户意图翻译成一套更接近目标文档表达的检索计划，而不是直接把原始问句丢给搜索引擎。

1.2 网页检索适合单点查询，不适合链式推理

经典的搜索交互是“输入—点击—阅读—再输入”的循环，每一步都是独立请求。但大量真实问题其实需要链式拆解，比如“这台设备异响但还能开机，可能是哪里的问题、怎么排查”，这类问题至少包含三跳任务：查这型号的常见异响来源、查开机状态下的故障判断优先级、查对应部件拆解步骤。

普通搜索无法自动完成这个链路，它只能机械地返回与“设备异响”相关的页面。用户需要在多个搜索结果之间手动建立逻辑关系，这对专业从业者不难，但对普通用户就是高墙。

搜索智能体之所以被称为“智能体”，核心区别在于它有规划能力：先把问题拆成若干子查询，再决定每个子查询用什么检索源、按什么顺序执行、哪些结果需要二次确认。这个过程中，模型扮演的不是“答案生成器”，而是一个“研究助理”，它自己安排查找路径，自己判断信息有没有找够。

我在设计MiroThinker-v1.5时，最核心的取舍就是把检索控制权从用户手上转移到模型手上，同时保留人在关键节点介入的余量，不是让模型黑箱执行，而是让每一步检索都可解释、可回溯。

1.3 大模型直接把搜索任务外包，结果往往不可信

很多人觉得，既然大模型提示词里带了“请联网搜索”，那它应该能用好搜索结果。实际跑过一轮你就会发现，事情没那么简单。

模型确实会调用搜索工具，但它经常犯三类错误：一是只拿第一页结果，检索深度不够；二是把多条来源里相互矛盾的信息揉进同一段话，导致事实冲突；三是引用标记和实际内容对不上，用户点开来源发现压根没有那句话。这三类问题在纯对话场景还能原谅，放在搜索场景里就是硬伤，因为这个产品的核心卖点就是可信、可核验。

这些坑正是推动我做MiroThinker-v1.5的原因。系统不能把“联网”当作大模型的一个附属功能，而应该把它当作一条独立的工程链路来设计：查询理解、检索规划、结果筛选、信息融合、自评反思，每一层都责任到模块，每一层都有监控指标。榜单成绩只是结果，过程可靠性才是底子。

2. MiroThinker-v1.5的整体设计思路与技术选型

2.1 五段式架构：意图解析、检索规划、并行采集、信息融合、自评反思

MiroThinker-v1.5延续了我们内部坚持的模块化思路，整体分成五个环节，各环节之间通过结构化的中间数据传递，而不是把一大堆上下文文本直接塞给下一个模块。这五个环节分别是：意图解析、检索规划、并行采集、信息融合、自评反思。

意图解析负责把用户原始输入转换成机器可执行的检索意图，包括识别实体、时间限定、比较关系、否定词等。检索规划负责把意图展开成若干个具体检索任务，并决定使用的检索源和先后顺序。并行采集阶段会同时发起多路请求，比如一个子问题走结构化数据源，另一个子问题走网页搜索，第三个子问题走知识库。信息融合阶段负责把各路返回的片段去重、排序、统一格式，提取与问题最相关的部分。自评反思是v1.5新加的兜底层，对生成的答案做一致性检查，发现没把握的地方就重新检索或调整表述。

这个架构初看可能觉得环节太多，但它的优势在于每一层都能单独调试、单独评测。检索规划做得不好时，你不需要重新训练模型，只需要调整规划提示词；信息融合阶段引用错位时，改动也完全局部化。对工程团队来说，这种可分层排查的架构远比端到端黑箱更友好。

2.2 纯文本检索与“工具调用+反思循环”的差异

MiroThinker-v1.5选择的方向是工具调用加反思循环，而不是一次性把检索结果全塞给模型让模型直接写答案。两者看起来差别不大，实际体验差距很明显。

一次性检索模式的实现通常很简单：模型生成一个查询词，系统调一次搜索API，把返回前十条网页标题和摘要喂给模型，模型基于这些内容写答案。问题在于，真实问题的答案往往分散在多个相关页面里，前十条摘要信息密度不足，模型只能靠猜补全细节，幻觉风险直线上升。

MiroThinker-v1.5采用反思循环的方式：首轮检索完成后，系统会做一个覆盖度评估，判断当前得到的信息能不能支撑起完整答案，如果缺了某一部分，它会针对缺口发起第二轮检索，甚至第三轮，直到覆盖度达到阈值或者达到最大迭代限制。这个过程很像人查资料时的“越查越深”，先看概览、再找细节、然后核对不同来源的说法。

你可能会问，多轮检索是不是太慢、太贵？确实存在这个代价，所以我们加了两条约束：一是最大反思轮数限制为3轮，避免死循环；二是每一轮检索都带有明确的“待补全要点”，确保第二轮不是对第一轮的重复搜索。从实测效果看，多花30%的检索时间能换到约15%的准确率提升，在搜索场景里这买卖划算。

2.3 模型、检索源与向量库的搭配选择

搜索智能体的效果是“模型+检索源+路由策略”三角共力的结果，任何一边拖后腿都直接影响最终答案质量。

模型选择上，我优先看两个能力：工具调用格式的稳定性和长文本信息抽取能力。工具调用不稳定，意味着模型经常把JSON参数拼错，检索环节直接挂掉；信息抽取能力弱，意味着网页内容一大段喂进来，模型抓不住重点。所以v1.5在主干模型上选了一款当前主流的中大规模模型，在快捷路径的轻量场景则交给响应更快的小参数模型，用规模换成本。

检索源我们同时接入通用网页搜索引擎、结构化百科类数据源和内部知识库，三者通过路由规则分配。判断标准很朴素：问题里包含明确的实体名词就优先查百科，问题包含操作步骤或故障现象就优先查网页正文，问题涉及内部规范就优先查知识库。没有一条规则能覆盖所有场景，所以我加了一个“可选源补充”机制，第一优先级检索结果不足时自动追加次级源。

向量库在这个项目里的角色不是主角，但它是记忆层的支撑。我们把历史检索中验证过的高质量片段向量化，存进开源向量数据库，当新问题与历史片段语义相似时直接命中，省一次检索调度。实测下来，高频问题的命中成本能降一半，不过冷启动阶段效果一般，需要跑一段时间才能累积出可用的缓存。

3. 核心模块的实操细节与参数配置

3.1 查询改写：让问题从口语变成检索语言

查询改写是我个人认为性价比最高的一个模块。它解决的是“用户怎么说”和“文档怎么写”之间的语义鸿沟。

v1.5的查询改写分三步：第一步做多轮压缩，把对话历史里已经提到的实体和条件合并进当前问题，避免单轮检索时信息缺失；第二步做实体与限定词抽取，比如时间范围、地域、否定关系、比较对象，这些成分最容易在改写时丢；第三步生成两到三个改写候选，一个偏口语保留用户原意，一个偏专业接近百科文档，一个偏短匹配搜索引擎摘要字段。

日常对话切割：如果你做的是对话式搜索，“2020年的旗舰机哪款续航最好”这类问题，直接拿去检索大概率返回一堆2020年的机型介绍，但答案里要的是续航对比数据。经过改写后，系统会生成“2020年旗舰手机 续航测试 对比”这种更接近评测文章的查询词，命中率明显提升。

改写Prompt我们经过几轮调整，稳定在一个模板上。核心要求写得比较细：不改变原意、不丢失限制条件、不添加外部知识、必要时补充同义词。你可以先按这个框架试，再根据自己领域调整。

你是一个搜索查询优化器。请将以下用户问题改写成适合搜索引擎查询的表述。 要求： 1. 保留所有实体名、时间、地域、否定与比较关系 2. 如原问题包含多跳推理，拆成多个独立查询，用编号列出 3. 每个查询控制在12个词以内 4. 输出JSON数组，不要多余解释 输入问题：{{question}}

3.2 检索规划与Top-K参数经验值

查询改写的结果会进入检索规划模块。这个模块根据查询类型决定检索策略：单点事实类问题只检索一次；对比类问题至少检索两个实体各自的信息再合并；步骤类问题需要检索多个操作主题；争议类问题必须覆盖至少两个不同观点来源。

规划输出是一个结构化的检索任务列表，每个任务包含来源类型、查询词、期望返回条数和时间窗口。比如一个关于“某机型值与不值”的问题，会被拆成“某机型核心参数”“某机型价格走势”“用户口碑汇总”“对比机型参数”四个并行任务。

Top-K参数这里我记录一下我们实测下来比较稳的范围：网页检索每个任务取前10条原始结果，进入信息抽取前先按标题和摘要做一轮粗糙筛选，筛掉明显与主题无关的，控制在4到5条；结构化数据源取前20条再做精确筛选；知识库检索取相似度Top5。总数不算多，但胜在质量。Top-K选择的关键是宁少勿滥，三条高质量来源足以合成一段可信答案，十条低质来源只会增加模型的信息冲突。

时间窗口参数同样重要。当问题涉及新鲜资讯时，把检索时间窗设为最近7天；涉及历史事件或产品参数时，不设时间限制。这个参数如果设错了，后果很微妙：新问题被旧内容覆盖，答案看着完整但已经过时，用户很难发现。v1.5里我们增加了“资讯类问题默认时间窗7天”的规则，并把时间提示嵌入答案生成阶段，让模型优先采用时间戳更新的内容。

3.3 信息抽取与答案合成：消除来源冲突

检索结果回来后，不能直接把原始网页文本全量喂给模型。网页文本里包含导航、广告、相关推荐等噪声，直接喂进去一是浪费token，二是干扰信息判断。v1.5在信息融合阶段加了一个抽取层，对每条来源做单文档摘要，只提取与当前问题相关的要点。

这个抽取的过程是：先对原文做分块处理，取标题、首段、含关键词密集的段落；再把块拼接成单文档摘要Prompt，要求模型只保留可验证的事实陈述，过滤掉评价类和营销类内容；最后把各文档摘要按主题聚类。主题聚类这一步很关键，它能把不同来源里讨论同一小议题的内容聚到一起，为后续冲突消解做准备。

冲突消解是我们踩过坑之后重点优化的环节。当多个来源对同一事实说法不一致时，系统不会简单取多数，而是综合考虑三个信号：来源的可信度评分、发布时间的新旧、信息具体程度。比如一篇实测文章说“续航8小时”，一篇厂商宣传稿说“续航12小时”，系统判断时会倾向实测数据。这些信号通过加权打分决定最终采纳哪一条，被放弃的说法也会记录在案，用于答案的“争议提示”字段。

答案合成阶段，我要求模型必须完成“先概括后展开”的结构。第一段直接回答用户核心问题，控制在3句话以内；后续段落按“证据链”展开，每一处关键判断都标注来源编号。这种结构不是为了让答案好看，而是方便用户在不确定时顺着编号快速定位原始出处。

3.4 自评与反思：阻止幻觉的最后一道闸门

v1.5较前版本最大的改动，是加了自评反思模块。以前流程是“检索—抽取—生成”一气呵成，答案出来了就结束。现在生成完答案后，系统会用一份自评检查清单对答案逐项打分，分数不达标就触发重新检索。

自评的四个维度我一直沿用：完整性（用户每个意图点是否都被覆盖）、忠实度（每个论断是否有至少一条来源支持）、简洁度（有没有车轱辘话）、可核验性（关键信息是否能定位到具体来源段落）。每个维度打分区间是0到1，加权平均后得到总分。完整性和忠实度权重各占0.3，简洁度和可核验性各占0.2。

当总分低于0.75时，系统进入反思循环。反思阶段先定位短板：哪个子问题信息不足、哪条论断缺少来源支撑，然后用这些短板生成补检查询，重新进入检索流程。这个循环最多3次，每轮反思都会把上一轮已确认的信息标记为“已验证”，防止重复劳动。

一个实测数据供参考：加入自评反思前，答案在检索类评测集的忠实度得分是0.81；加入后提升到0.89。代价是平均响应时间增加1.8秒。对搜索场景来说，这个时间换质量的取舍我认为完全值得，但如果你的产品对时延特别敏感，可以把自评阈值从0.75降到0.7，这样只有明显幻觉才会触发重检，大部分低风险答案会直接通过。

4. 榜单评测：分数是怎么一点点涨上去的

4.1 评测集构建与指标看板

说MiroThinker-v1.5刷新榜单，总得讲清楚榜单是怎么来的。我们没有用现成的公开数据集，而是自建了一个叫“综合搜索问答基准”的评测集，里面涵盖六个领域：科技产品参数、医疗健康常识、生活消费决策、政策类办事流程、故障排查类问题、开放观点类问题。每个领域约120题，合计720题，每道题都有标准答案和关键得分点。

评测时我们只用机械指标，避免人工评分的主观性。四个核心指标是：答案准确率（关键得分点是否命中）、信息完整度（用户子问题覆盖比例）、来源吻合度（每条论断是否有匹配引用）、端到端响应时间。最后一个漏斗指标是成本，按每次请求消耗的token金额计。

4.2 提分的四板斧：改写、召回、压缩、冷静

整个版本迭代下来，我们总结出四条最有效的提分路径。

第一板斧是强化查询改写。v1.0时代我们基本是拿用户原句直接搜，准确率只有0.62。后来把查询改写单独拎出来做，加多轮压缩和候选生成，准确率跳到0.71。这个改动几乎没有增加耗时，是性价比最高的一步。

第二板斧是多路召回。同一查询同时走网页搜索、百科结构和内部知识库，再把三路结果融合。融合不是简单拼接，而是按主题去重后做交叉验证。多路召回让来源单一导致的偏倚问题大幅减少，信息完整度从0.58升到0.73，代价是检索模块复杂度上升，但换来的是答案骨架明显更丰富。

第三板斧是信息压缩与去噪。早期直接把整篇文章喂给模型，答案总是带一些不相关内容，引用也跟着乱。改为先抽取再融合后，来源吻合度从0.69升到0.8，平均回答长度反而缩短了约20%。少即是多，在信息融合阶段体现得很清楚。

第四板斧是自评反思阈值管理。这一步提分不是靠单点爆发，而是靠把最后的10%修正掉。加入反思后准确率稳定在0.78到0.82之间。反思不是万能的，但它能兜住那些“看起来通顺、其实漏信息”的答案。

4.3 从v1.0到v1.5的版本演进回放

把版本演进摊开看，成绩提升不是单一技巧的功劳，而是一系列小改动叠加的结果。

注意看v1.1到v1.2的提升幅度其实有限，准确率只涨了0.02，但信息完整度涨了0.07。这说明多路召回对“答案能不能说全”很有帮助，对“说得对不对”帮助一般。真正把准确率拉开差距，靠的是v1.4的冲突消解和v1.5的反思机制。做评测复盘时不能只看一个总分，要拆开指标看，才知道该在哪个环节下功夫。

5. 常见问题与排查实录

5.1 检索结果发散、抓不住重点

症状是检索返回的页面主题过于宽泛，比如用户问“某款车隐藏功能”，却返回了大量“某款车全面评测”。问题通常出在查询改写阶段，改写后的查询词太长或太短都容易发散。太短则缺乏限定，太长则搜索引擎难以匹配。

处理办法：在检索规划阶段增加约束词注入。根据意图解析结果，为查询添加限定词，比如“隐藏功能 实测 汇总”“某款车 配置 说明书 暗藏功能”。另外一个常用手段是降低Top-K值，把候选从10条压到5条，强迫系统只保留高相关片段。让模型在几十条内容里挑和只有几条内容里挑，后者稳重得多。

5.2 反思循环反复触发，响应严重超时

v1.5刚上线时，我们发现一小部分问题的响应时间从6秒涨到15秒以上，排查后发现是反思循环触发了三轮重检。有个规律值得记一下：触发反思的问题大多属于争议类或比较类，这类问题天然缺少“唯一正确答案”，分数很难达到阈值，所以每轮都觉得没找够。

后来我们加了三个限制：最大反思轮数设为3，反思子查询一次最多3个；得分低于0.5的问题直接降级，输出“信息不足+已有来源汇总”而不是强行生成；引入置信度缓存，同一问题24小时内重复出现时直接复用上次的结果和反思记录。三个限制一加，平均耗时回到6秒出头，超时率从8%降到1%以下。

5.3 引用编号与内容对不上

引用错位是搜索智能体最容易挨骂的问题，用户顺着编号点开来源，发现页面里根本没有那句话，信任直接归零。早期排查发现，错位多发在多来源融合后的段落重写步骤，模型把多个来源的事实合并成一句通顺的话，却只贴了一个引用编号。

解决思路是改变“先写后标”的顺序：先让模型从某个来源的原文摘出关键句，再基于这些关键句组织表述，最后把引用编号绑定到对应原文位置。摘录与改写分离后，引用吻合度从0.8升到0.87。同时我们还加了一道校验程序，自动比对引用段落里是否包含答案里出现过的实体词，发现不匹配就触发该段的局部重写。

5.4 检索成本失控

成本问题通常不是出现在模型推理，而是出现在冗余检索。一个复杂问题被拆成4个子任务，每个子任务调一次搜索、对每个结果做一次抽取，好几个环节都是token消耗大户。

我们做了三类优化：第一，按意图裁剪检索源，事实型问题不走知识库全文检索；第二，抽取阶段批量处理，把多个结果拼在同一个Prompt里让模型一次抽取，而不是一条一条抽；第三，为简单问题分配小参数模型，直接走快捷路径，不经过主模型。整体成本大约降了30%，同时答案质量没有明显滑落。

5.5 排查速查表：按症状定位问题环节

排查这类系统问题，我最大的经验是：不要凭感觉调参数，先把中间结果打开看一遍。检索规划输出的查询词对不对、抽取模块选了哪几条内容、自评打分的各项数值，全部落盘成日志。大多数问题看一眼中间结果就能定位，因为各模块耦合度低，责任划分很清楚。

最后分享一个这次迭代中最值的体会：搜索智能体最难的地方不是让模型“会搜索”，而是让系统“知道自己的答案还不够好”。v1.5的成绩提升，很大程度上得益于自评反思这类控制机制，而不是模型本身变强了多少。做搜索产品，工程纪律比模型大小管用。如果你正在搭类似系统，我建议你优先把中间日志和评估闭环做好，形式上的“智能”会随着反馈循环自然涌现。