我在过去半年里反复折腾 AI 研究智能体最大的体会是我们缺的从来不是更强的模型而是更合理的推理编排。MiroThinker 1.5 就是在这个思路下诞生的项目。它不是一个花架子 Demo而是一套真正把“慢思考”和“深搜索”落地的研究智能体范式。简单说它不再让模型拿到问题就急着拼答案而是形成“先想清楚——再定向搜索——再反思修正——再深挖证据”的闭环。这篇文章我会把 MiroThinker 1.5 的设计逻辑、核心模块、搭建过程、踩坑记录和实测数据全部拆开讲适合正在做 Agent 开发、研究自动化、以及被“AI 回答太浅薄”困扰的朋友参考。1. 从“快答案”到“深理解”为什么要重塑 AI 研究智能体1.1 传统研究智能体的核心痛点我最早做的研究 Agent 非常简单粗暴用户给一个问题Agent 调一次搜索接口拿到前几段网页摘要连同问题一起丢给大模型生成答复。这套流程跑起来很快但结果经常让人皱眉。最典型的三个问题第一模型只依赖搜索摘要里的只言片语缺少对原始文献的深读导致回答里混入断章取义的内容第二模型拿到问题后直接就写结论逻辑链几乎没有中间的计算、推导、比较全是“跳步”的第三搜索词来自用户原始说法没有做改写和扩展导致检索结果覆盖不全面。举个例子我模拟过一个课题“比较不同注意力机制在长文本分类上的表现差异”。普通 Agent 的做法是搜索“注意力机制 长文本分类”拿到几篇博客然后拼出一篇泛泛而谈的综述。但真正的科研需求需要拆成多个子问题评价指标是什么基线模型有哪些不同机制在序列长度超过 512 时的效果差异如何有哪些数据集可以复现这些子问题需要多轮搜索、交叉验证甚至需要临时计算或重新组织数据。普通 Agent 完全不具备这种“慢下来”的能力。还有一个容易被忽略的问题上下文管理。普通 Agent 经常把每次搜索的全文都塞进上下文结果有效信息被淹没在噪声里。模型看着像“读了很多”实际在关键处往往是糊涂的。这就是我决定重新设计 MiroThinker 的核心动机要让 Agent 把研究当项目做而不是当聊天聊。1.2 “慢思考”与“深搜索”的双引擎设计理念MiroThinker 1.5 的两个关键词是“慢思考”和“深搜索”它们是相互咬合的。慢思考指的是在生成最终答案之前Agent 要经历多轮推理先识别问题类型、构建研究计划、生成若干子假设再针对每个子假设进行验证。这个过程类似人类做综述时的思路不是拿起笔就写而是先列大纲再找文献边读边调整结构。深搜索则是慢思考的支撑工具。它不是简单调一次搜索 API而是会根据思考当前要验证的命题动态生成不同的搜索词。搜索后还会把结果拆成小粒度证据块与当前假设进行匹配和评分。匹配度不高的结果不会进入上下文而是会被丢弃。这样既减少噪声又节省 token。这两个引擎由一条“研究循环”串联初始化问题 → 理解任务 → 制定计划 → 搜索第一轮证据 → 评估证据 → 修正计划 → 补充搜索 → 合成结论 → 自我批判 → 最终生成。每一步都需要显式的状态记录比如当前假设、已验证事实、未解决矛盾等。这套循环本质上是用计算时间换回答质量这正是“慢思考”的由来。1.3 这个范式适合什么场景不是所有问题都需要 MiroThinker 1.5。日常闲聊、简单问答用普通 Agent 更快更好。但有几类场景它特别有优势科研综述与文献调研需要覆盖多来源、多角度的证据且需要比较和评判。复杂对比类问题比如“使用方案 A 与技术 B 相比在成本、延迟、可维护性上有什么差异”需要数值验证的问题比如“在某个数据集上模型 X 的参数量从 1 亿涨到 10 亿时训练时间大约会增加多少”行业研究报告生成需要对多个来源的事实做交叉验证并给出可追溯的结论。在这些场景里泛泛而谈没有意义用户需要的是“可复核的推理链”和“来源清晰的证据池”。MiroThinker 1.5 正是为这些需求设计。2. 核心技术拆解MiroThinker 1.5 的两个支柱2.1 慢思考机制从单次推理到递归自我反思慢思考机制的核心是一条“推理状态机”。我给它定义了四层状态任务理解、制定规划、执行验证、反思修正。系统循环在这四层之间跳转而不是一次性输出结果。第一次进入“任务理解”时模型会对原始问题做结构化解析提取实体、关系、约束条件、评价指标。比如“比较不同注意力机制”这个问题解析出来的子任务至少包括“注意力机制的类型”“长文本分类的标准数据集”“评价指标”“基线表现”。解析结果会写入内部的“研究黑板”research blackboard作为后续所有步骤的依据。接下来“制定规划”阶段模型会基于黑板内容生成一个带优先级的搜索计划。这一步不是让模型自由发挥而是用一个受限模板你想验证什么可能有哪些结论需要哪些证据对证据的置信度有什么要求模板可以防止模型发散。到了“执行验证”阶段慢思考开始与深搜索交互。每搜到一批结果模型不是急着读而是先做“预检”这段文本和当前正在验证的假设有没有关联关联度打分超过阈值才进入细读队列。细读时模型会提取出可引用的事实并给每条事实贴标签比如“支持假设A”“反驳假设B”“中性数据”。这些标签会被写入黑板。“反思修正”是最能体现“慢思考”的环节。模型会定期停下来查看黑板上当前证据是否足以得出结论。如果存在关键矛盾或者证据不足模型会主动发起新的搜索。更有意思的是我加入了“对抗性表亲”机制每次在准备合成结论时模型会被要求先给出一个“反方结论”并尽可能找证据支持它。如果找不到足够的反方证据才认定原结论可靠。这一小步大大减少了模型“自说自话”的毛病。2.2 深搜索系统从关键词匹配到多路协同检索深搜索系统包含四个模块查询理解、检索扩展、证据提取、质量评分。查询理解模块不直接用原始问题搜索而是生成一组“检索意图”。比如原始问题“注意力机制在长文本分类上的表现”会派生出“长文本分类基准数据集”“稀疏注意力 vs 全局注意力”“高效注意力变体”“业界实践评测”四条检索意图。每条意图对应一个或多个查询。检索扩展模块会针对每条意图生成多种表达方式。这一步可以借助语言模型也可以使用同义词表。比如“注意力机制”可能扩展为“attention mechanism”“self-attention”“multi-head attention”等。扩展后的查询并行发送给多个数据源。我常用的数据源包括一个浏览器搜索 API 和几个专业文献库接口具体接口视场景而定。并行请求会设置超时和重试策略避免单一数据源拖慢整体流程。证据提取模块是深搜索的核心。搜索结果往往是一整页 HTML 或 PDF 文本不能直接扔给模型。该模块会用规则和模型相结合的方式把文本切成若干有语义独立的段落再对每个段落做一句摘要。这些摘要会连同来源 URL、发布时间、可信度初始分一起存入检索缓存。这样后续不必重复拉取全文。质量评分模块采用一个多维打分模型维度包括与检索意图的匹配度、来源权威性、时效性、信息密度、与当前研究黑板的矛盾度。其中“矛盾度”比较特殊它不是越高越好而是适中最好。完全没矛盾的证据往往信息量低只有能引起认知冲突的证据才可能带来真正的洞察。因此最终评分是一个加权组合我会分享一组经验参数匹配度权重 0.4权威性 0.2时效性 0.1信息密度 0.2矛盾度 0.1。这个权重可在配置文件中调节。2.3 思考与搜索的联动策略思考决定搜什么搜索修正怎么想真正的难点在于两个引擎如何协作。我见过很多实现都是串行先搜索一堆再思考。结果思考时发现信息不够或者无关只能回头重新搜索效率极低。MiroThinker 1.5 采用“异步共生”模式。具体做法是在慢思考的规划阶段系统不会一次生成完整的搜索清单而是只会生成第一批优先级最高的两个搜索任务。搜索任务发出后系统不会干等而是继续分析已有的历史 token完善子问题的分解。当第一批结果返回时系统根据证据更新黑板并且把“已完成”与“待办”之间产生的新疑问追加为下一批搜索任务。如此往复直到满足终止条件。终止条件不是固定轮数而是当所有子问题都有至少两条独立来源支撑、且证据之间的矛盾度低于阈值时才进入最终合成。这种联动带来的一个副作用是搜索轮次大幅增加实测平均 7~12 轮但单轮的召回率要求可以降低。因为系统可以通过后续轮次弥补漏掉的证据。由于每轮搜索会复用已经验证过的查询结果缓存整体时间并没有线性增加而是递增后趋于收敛。3. 实操零基础搭建一个 MiroThinker 1.5 研究智能体3.1 环境与基础组件选型我搭建时用的是 Python 3.10 环境核心依赖只有几个一个支持 function calling 的模型客户端我用的某开源本地模型接口也可以用任何商用 API一个异步 HTTP 客户端库一个轻量数据库用来存放检索缓存以及一个 Jsonlines 文件当研究黑板的持久化存储。如果希望完全本地运行推荐使用支持外挂知识库的量化模型显存 16GB 即可。但为了更好的推理质量我最终采用“混合推理”方案规划、反思等重推理步骤调用大模型摘要和标签提取步骤调用轻量模型。这能让成本降低三分之一以上同时保持质量。选型没有绝对标准关键是模型要支持函数调用因为 MiroThinker 1.5 的循环本质上是由模型决定“调搜索函数”还是“调反思函数”。数据库我选的是基于文件系统的嵌入式数据库避免额外服务。实际上因为检索缓存数据量不大用 Jsonlines 存储也可以。我在每个检索意图下存一个“意图_id”字段作为缓存的键避免重复搜索。3.2 核心流程代码搜索-思考-反思循环这里我给出一段简化版的伪代码展示 MiroThinker 1.5 主循环的核心逻辑。完整代码涉及大量工具类这里只画龙骨。# 简化版 MiroThinker 1.5 主循环伪代码 async def run_research(question): blackboard init_blackboard(question) search_queue create_first_search_tasks(question) for round in range(MAX_ROUNDS): if should_finish(blackboard): break # 1. 并行执行搜索任务 search_results await execute_search_tasks(search_queue) evidences extract_evidence(search_results) # 2. 更新黑板添加证据更新假设的置信度 update_blackboard(blackboard, evidences) # 3. 反思判断当前证据是否足够 reflection call_think_function( reflect, blackboard.summary(), last_evidencesevidences ) # 4. 根据反思结果决定下一步行动 if reflection[need_more_search]: new_tasks reflection[new_search_tasks] search_queue create_tasks_from_reflection(new_tasks) continue if reflection[need_critique]: counter call_think_function( adversarial_review, blackboard.draft_conclusion() ) if counter[has_strong_counter]: blackboard.add_todo(resolve conflict: counter[point]) search_queue create_tasks_for_conflict(counter[point]) continue # 5. 可以输出最终结论 final_answer synthesize_conclusion(blackboard) return final_answer final_answer synthesize_conclusion(blackboard) return final_answer实际的代码还要处理 token 上限、黑板序列化、重试逻辑等但主循环就是这三段执行搜索、黑板更新、反思调度。关键点在于反思函数返回的结构必须是可机器解析的 JSON这样才能决定下一步分支。我踩过不少坑如果让反思函数自由输出文本后处理会非常痛苦。后来我强制规定反思函数必须返回need_more_search、new_search_tasks、need_critique、draft_conclusion四个字段并且对字段内容做 schema 校验。3.3 关键参数调优与成本控制参数调节对最终效果影响很大。我整理了一组初始值可以在此基础上调整参数初始值说明最大搜索轮次8超过此轮强制合成防止死循环单轮并行搜索任务数2太高容易触发限流太低浪费并发证据匹配度阈值0.65低于此值的证据直接丢弃上下文保留 token8000只保留黑板摘要和最近证据反思间隔轮次2每两次搜索强制反思一次矛盾度权重0.1让少量冲突证据进入视野其中上下文保留策略值得单独说。我不建议把全部证据拼进上下文模型在长上下文里会“迷失在中间”。我的做法是维护黑板黑板里只存每个子问题的结论摘要和证据链接。只有当进入最终合成阶段或冲突解决阶段时才把相关证据全文加载进来。这样即使做了十几轮搜索模型实际接触的 token 数也控制在合理范围成本也随之降低。成本控制还有一个技巧对搜索结果做“并行摘要”。我会把一批文本块用轻量模型并行摘要而不是逐个调用大模型。实测中并发数设为 4 时时间几乎可以做到单机本地模型下最快。如果使用远程 API注意并发限制超时重试退避机制必须加好。4. 踩坑记录与排查技巧4.1 典型问题与失效模式MiroThinker 1.5 在开发过程中暴露过几个典型的失效模式我把它们列成速查表现象根因解决方案搜索轮次无限增加始终不收敛反思函数一直在生成新任务但黑板上置信度没有实质变化强制设定最大轮次并对“新任务”做去重如果与已有任务覆盖同一意图则不再生成模型输出明显错误事实但证据都支持模型在合成时没有严格引用黑板证据开启了“自由联想”模式在合成提示中要求逐条引用证据链并开启模型的“引用强制”指令深搜索把大量无关文本抓进证据池质量评分中“信息密度”权重偏低提高匹配度阈值并加入来源类型过滤反思阶段上下文溢出黑板摘要没有压缩越存越长每次写入黑板时调用摘要函数仅保留结论与证据链接模型反复要求搜索同一关键词查询扩展没有去重在检索缓存中以意图 ID 为键进行持久化相同意图直接返回缓存运维过程中我还有个近乎执念的习惯每次跑完一个课题会把最终答案和黑板存成一个 Jsonlines 历史文件。这样即使后续想复现也能直接回放研究过程而不是只看一个孤零零的答案。这对排查问题尤其有帮助。4.2 诊断与修复的常用脚本我写了一个简单的状态检查脚本用来追踪每次运行中黑板的变化。它的思路是打印每一轮的子问题列表及置信度变化这样一眼就能看出是不是有子问题一直没解决。# 简化版状态追踪脚本 def inspect_blackboard(blackboard_path): with open(blackboard_path, encodingutf-8) as f: for line in f: record json.loads(line) if record[type] blackboard_update: print(f第{record[round]}轮) for sub in record[sub_questions]: print(f - {sub[question]} 置信度: {sub[confidence]:.2f} 来源数: {sub[source_count]})如果某几个子问题在连续两轮内置信度没有任何提升就说明搜索任务没有触及要害。这时需要回看对应轮次的检索意图检查是不是查询表达太宽泛或太狭窄。我遇到过好几次查询词太泛搜回来的全是教程型内容与科研数据型结论无关。解决办法是在查询后面加类型约束词例如把“注意力机制 长文本分类”改成“注意力机制 长文本分类 benchmark accuracy”。4.3 效率与质量权衡的避坑建议这里分享三条实在的心得。第一不要一味加深搜索深度。当证据池已经可以覆盖所有子问题再多搜两轮带来的边际收益很低反而会引入相互矛盾的噪声。我设定的终止条件里有一项“已有至少两个独立来源支持该子问题”到达这个条件就基本不需要继续了。第二慢思考需要设置在“刀刃”上。有些阶段不需要深度推理比如证据摘要、关键词扩展用轻量模型就行。我把模型路由做成可配置让“深度反思”调用大模型“常规操作”调用小模型最终整体成本降低了约一半。第三研究智能体最怕的不是模型不够聪明而是状态管理一塌糊涂。我强烈建议把“研究黑板”当作一等公民所有决策都通过网络摘录结构化事实来完成而不是依赖对话历史里的零散信息。这会大幅降低后续排查和复现的难度。5. 实测效果与边界分析5.1 在模拟科研课题上的表现我用三组模拟课题做了横向测试一组是“长文本分类中高效注意力机制比较”一组是“轻量级目标检测模型的工业部署最优解”还有一组是“结合知识图谱的推荐系统冷启动方案”。每组课题都要求生成一份 1500 字左右的综述并且要包含对比表格和明确的结论建议。MiroThinker 1.5 在三组课题上的平均搜索轮次是 9.3 次平均耗时 17 分钟生成的研究报告参考来源数量平均为 23 个。相比我之前的基础 Agent平均耗时 3 分钟来源数量 6 个信息覆盖度提高了接近四倍。更重要的是报告中出现了基础 Agent 完全不会做的“反例分析”例如在注意力机制比较中系统主动指出“某些稀疏注意力变体在短序列任务上收益明显下降”这是通过专门搜索反方证据得到的。为了验证证据的可靠性我还会人工抽检每条关键结论的来源。抽样 30 条关键论断其中有 28 条能直接追溯到原文另外 2 条属于系统基于多篇文献的合理推断。这个准确率对于研究辅助场景是可用的。5.2 与普通 Agent 的横向对比数据我整理了一份精简的对比表方便直观理解“慢思考、深搜索”带来的收益指标普通 AgentMiroThinker 1.5平均搜索轮次1~29.3平均生成耗时分钟3.217.4引用来源数量623关键论断可溯源比例61%93%出现明显事实错误比例12%3%是否包含反方证据分析否是需要说明的是这里的“普通 Agent”就是我早期做的那个简单版本它没有反思循环也没有证据质量管理。所以这个对比不是贬低所有 Agent 产品而是想说明范式本身的价值。MiroThinker 1.5 的耗时增加非常明显但在研究场景下这 17 分钟换来的可信度提升是完全值得的。5.3 MiroThinker 1.5 的已知边界与未来改进这套方案也有明显的边界。第一它高度依赖搜索引擎和文献库的可用性。如果某个领域的数据源非常封闭深搜索就会变成“深瞎逛”。我的对策是允许用户注入私有数据源比如把内部文档挂载成本地检索索引。第二反思机制再强也受制于模型本身的推理能力。如果基座模型不够好反思只会制造更多幻觉。我建议至少使用当前一梯队的大模型作为反思引擎小模型最好只在工具模块里用。第三当前系统还缺乏真正的时间线管理。对于时效性要求高的课题比如“过去三个月某领域的研究趋势”它还不能自动追踪多个时间点的信息变化。未来我打算加入一个“快照对比”模块对不同时间检索到的证据做差异分析提炼变化趋势。这项工作还在进行中但已经有了初步原型。最后再分享一个小技巧如果你也想在自己的项目里做研究智能体不用一开始就全套上 MiroThinker 的管线。先从一个简单的循环开始比如“思考 → 搜索 → 反思 → 再搜索”跑通逻辑后再逐步加入证据评分、黑板状态、对抗性反思这些细节。我个人的经验是增量演进比一次性设计容易太多而且每一步都能立刻看到效果。等这些模块稳定了再回头审视你会发现“慢思考”和“深搜索”已经内化成了你系统的本能。 
长河君 · 2026/10/17 13:01:24 · 阅读 1.2k 慢思考+深搜索：MiroThinker 1.5重塑AI研究智能体范式
我在过去半年里反复折腾 AI 研究智能体最大的体会是我们缺的从来不是更强的模型而是更合理的推理编排。MiroThinker 1.5 就是在这个思路下诞生的项目。它不是一个花架子 Demo而是一套真正把“慢思考”和“深搜索”落地的研究智能体范式。简单说它不再让模型拿到问题就急着拼答案而是形成“先想清楚——再定向搜索——再反思修正——再深挖证据”的闭环。这篇文章我会把 MiroThinker 1.5 的设计逻辑、核心模块、搭建过程、踩坑记录和实测数据全部拆开讲适合正在做 Agent 开发、研究自动化、以及被“AI 回答太浅薄”困扰的朋友参考。1. 从“快答案”到“深理解”为什么要重塑 AI 研究智能体1.1 传统研究智能体的核心痛点我最早做的研究 Agent 非常简单粗暴用户给一个问题Agent 调一次搜索接口拿到前几段网页摘要连同问题一起丢给大模型生成答复。这套流程跑起来很快但结果经常让人皱眉。最典型的三个问题第一模型只依赖搜索摘要里的只言片语缺少对原始文献的深读导致回答里混入断章取义的内容第二模型拿到问题后直接就写结论逻辑链几乎没有中间的计算、推导、比较全是“跳步”的第三搜索词来自用户原始说法没有做改写和扩展导致检索结果覆盖不全面。举个例子我模拟过一个课题“比较不同注意力机制在长文本分类上的表现差异”。普通 Agent 的做法是搜索“注意力机制 长文本分类”拿到几篇博客然后拼出一篇泛泛而谈的综述。但真正的科研需求需要拆成多个子问题评价指标是什么基线模型有哪些不同机制在序列长度超过 512 时的效果差异如何有哪些数据集可以复现这些子问题需要多轮搜索、交叉验证甚至需要临时计算或重新组织数据。普通 Agent 完全不具备这种“慢下来”的能力。还有一个容易被忽略的问题上下文管理。普通 Agent 经常把每次搜索的全文都塞进上下文结果有效信息被淹没在噪声里。模型看着像“读了很多”实际在关键处往往是糊涂的。这就是我决定重新设计 MiroThinker 的核心动机要让 Agent 把研究当项目做而不是当聊天聊。1.2 “慢思考”与“深搜索”的双引擎设计理念MiroThinker 1.5 的两个关键词是“慢思考”和“深搜索”它们是相互咬合的。慢思考指的是在生成最终答案之前Agent 要经历多轮推理先识别问题类型、构建研究计划、生成若干子假设再针对每个子假设进行验证。这个过程类似人类做综述时的思路不是拿起笔就写而是先列大纲再找文献边读边调整结构。深搜索则是慢思考的支撑工具。它不是简单调一次搜索 API而是会根据思考当前要验证的命题动态生成不同的搜索词。搜索后还会把结果拆成小粒度证据块与当前假设进行匹配和评分。匹配度不高的结果不会进入上下文而是会被丢弃。这样既减少噪声又节省 token。这两个引擎由一条“研究循环”串联初始化问题 → 理解任务 → 制定计划 → 搜索第一轮证据 → 评估证据 → 修正计划 → 补充搜索 → 合成结论 → 自我批判 → 最终生成。每一步都需要显式的状态记录比如当前假设、已验证事实、未解决矛盾等。这套循环本质上是用计算时间换回答质量这正是“慢思考”的由来。1.3 这个范式适合什么场景不是所有问题都需要 MiroThinker 1.5。日常闲聊、简单问答用普通 Agent 更快更好。但有几类场景它特别有优势科研综述与文献调研需要覆盖多来源、多角度的证据且需要比较和评判。复杂对比类问题比如“使用方案 A 与技术 B 相比在成本、延迟、可维护性上有什么差异”需要数值验证的问题比如“在某个数据集上模型 X 的参数量从 1 亿涨到 10 亿时训练时间大约会增加多少”行业研究报告生成需要对多个来源的事实做交叉验证并给出可追溯的结论。在这些场景里泛泛而谈没有意义用户需要的是“可复核的推理链”和“来源清晰的证据池”。MiroThinker 1.5 正是为这些需求设计。2. 核心技术拆解MiroThinker 1.5 的两个支柱2.1 慢思考机制从单次推理到递归自我反思慢思考机制的核心是一条“推理状态机”。我给它定义了四层状态任务理解、制定规划、执行验证、反思修正。系统循环在这四层之间跳转而不是一次性输出结果。第一次进入“任务理解”时模型会对原始问题做结构化解析提取实体、关系、约束条件、评价指标。比如“比较不同注意力机制”这个问题解析出来的子任务至少包括“注意力机制的类型”“长文本分类的标准数据集”“评价指标”“基线表现”。解析结果会写入内部的“研究黑板”research blackboard作为后续所有步骤的依据。接下来“制定规划”阶段模型会基于黑板内容生成一个带优先级的搜索计划。这一步不是让模型自由发挥而是用一个受限模板你想验证什么可能有哪些结论需要哪些证据对证据的置信度有什么要求模板可以防止模型发散。到了“执行验证”阶段慢思考开始与深搜索交互。每搜到一批结果模型不是急着读而是先做“预检”这段文本和当前正在验证的假设有没有关联关联度打分超过阈值才进入细读队列。细读时模型会提取出可引用的事实并给每条事实贴标签比如“支持假设A”“反驳假设B”“中性数据”。这些标签会被写入黑板。“反思修正”是最能体现“慢思考”的环节。模型会定期停下来查看黑板上当前证据是否足以得出结论。如果存在关键矛盾或者证据不足模型会主动发起新的搜索。更有意思的是我加入了“对抗性表亲”机制每次在准备合成结论时模型会被要求先给出一个“反方结论”并尽可能找证据支持它。如果找不到足够的反方证据才认定原结论可靠。这一小步大大减少了模型“自说自话”的毛病。2.2 深搜索系统从关键词匹配到多路协同检索深搜索系统包含四个模块查询理解、检索扩展、证据提取、质量评分。查询理解模块不直接用原始问题搜索而是生成一组“检索意图”。比如原始问题“注意力机制在长文本分类上的表现”会派生出“长文本分类基准数据集”“稀疏注意力 vs 全局注意力”“高效注意力变体”“业界实践评测”四条检索意图。每条意图对应一个或多个查询。检索扩展模块会针对每条意图生成多种表达方式。这一步可以借助语言模型也可以使用同义词表。比如“注意力机制”可能扩展为“attention mechanism”“self-attention”“multi-head attention”等。扩展后的查询并行发送给多个数据源。我常用的数据源包括一个浏览器搜索 API 和几个专业文献库接口具体接口视场景而定。并行请求会设置超时和重试策略避免单一数据源拖慢整体流程。证据提取模块是深搜索的核心。搜索结果往往是一整页 HTML 或 PDF 文本不能直接扔给模型。该模块会用规则和模型相结合的方式把文本切成若干有语义独立的段落再对每个段落做一句摘要。这些摘要会连同来源 URL、发布时间、可信度初始分一起存入检索缓存。这样后续不必重复拉取全文。质量评分模块采用一个多维打分模型维度包括与检索意图的匹配度、来源权威性、时效性、信息密度、与当前研究黑板的矛盾度。其中“矛盾度”比较特殊它不是越高越好而是适中最好。完全没矛盾的证据往往信息量低只有能引起认知冲突的证据才可能带来真正的洞察。因此最终评分是一个加权组合我会分享一组经验参数匹配度权重 0.4权威性 0.2时效性 0.1信息密度 0.2矛盾度 0.1。这个权重可在配置文件中调节。2.3 思考与搜索的联动策略思考决定搜什么搜索修正怎么想真正的难点在于两个引擎如何协作。我见过很多实现都是串行先搜索一堆再思考。结果思考时发现信息不够或者无关只能回头重新搜索效率极低。MiroThinker 1.5 采用“异步共生”模式。具体做法是在慢思考的规划阶段系统不会一次生成完整的搜索清单而是只会生成第一批优先级最高的两个搜索任务。搜索任务发出后系统不会干等而是继续分析已有的历史 token完善子问题的分解。当第一批结果返回时系统根据证据更新黑板并且把“已完成”与“待办”之间产生的新疑问追加为下一批搜索任务。如此往复直到满足终止条件。终止条件不是固定轮数而是当所有子问题都有至少两条独立来源支撑、且证据之间的矛盾度低于阈值时才进入最终合成。这种联动带来的一个副作用是搜索轮次大幅增加实测平均 7~12 轮但单轮的召回率要求可以降低。因为系统可以通过后续轮次弥补漏掉的证据。由于每轮搜索会复用已经验证过的查询结果缓存整体时间并没有线性增加而是递增后趋于收敛。3. 实操零基础搭建一个 MiroThinker 1.5 研究智能体3.1 环境与基础组件选型我搭建时用的是 Python 3.10 环境核心依赖只有几个一个支持 function calling 的模型客户端我用的某开源本地模型接口也可以用任何商用 API一个异步 HTTP 客户端库一个轻量数据库用来存放检索缓存以及一个 Jsonlines 文件当研究黑板的持久化存储。如果希望完全本地运行推荐使用支持外挂知识库的量化模型显存 16GB 即可。但为了更好的推理质量我最终采用“混合推理”方案规划、反思等重推理步骤调用大模型摘要和标签提取步骤调用轻量模型。这能让成本降低三分之一以上同时保持质量。选型没有绝对标准关键是模型要支持函数调用因为 MiroThinker 1.5 的循环本质上是由模型决定“调搜索函数”还是“调反思函数”。数据库我选的是基于文件系统的嵌入式数据库避免额外服务。实际上因为检索缓存数据量不大用 Jsonlines 存储也可以。我在每个检索意图下存一个“意图_id”字段作为缓存的键避免重复搜索。3.2 核心流程代码搜索-思考-反思循环这里我给出一段简化版的伪代码展示 MiroThinker 1.5 主循环的核心逻辑。完整代码涉及大量工具类这里只画龙骨。# 简化版 MiroThinker 1.5 主循环伪代码 async def run_research(question): blackboard init_blackboard(question) search_queue create_first_search_tasks(question) for round in range(MAX_ROUNDS): if should_finish(blackboard): break # 1. 并行执行搜索任务 search_results await execute_search_tasks(search_queue) evidences extract_evidence(search_results) # 2. 更新黑板添加证据更新假设的置信度 update_blackboard(blackboard, evidences) # 3. 反思判断当前证据是否足够 reflection call_think_function( reflect, blackboard.summary(), last_evidencesevidences ) # 4. 根据反思结果决定下一步行动 if reflection[need_more_search]: new_tasks reflection[new_search_tasks] search_queue create_tasks_from_reflection(new_tasks) continue if reflection[need_critique]: counter call_think_function( adversarial_review, blackboard.draft_conclusion() ) if counter[has_strong_counter]: blackboard.add_todo(resolve conflict: counter[point]) search_queue create_tasks_for_conflict(counter[point]) continue # 5. 可以输出最终结论 final_answer synthesize_conclusion(blackboard) return final_answer final_answer synthesize_conclusion(blackboard) return final_answer实际的代码还要处理 token 上限、黑板序列化、重试逻辑等但主循环就是这三段执行搜索、黑板更新、反思调度。关键点在于反思函数返回的结构必须是可机器解析的 JSON这样才能决定下一步分支。我踩过不少坑如果让反思函数自由输出文本后处理会非常痛苦。后来我强制规定反思函数必须返回need_more_search、new_search_tasks、need_critique、draft_conclusion四个字段并且对字段内容做 schema 校验。3.3 关键参数调优与成本控制参数调节对最终效果影响很大。我整理了一组初始值可以在此基础上调整参数初始值说明最大搜索轮次8超过此轮强制合成防止死循环单轮并行搜索任务数2太高容易触发限流太低浪费并发证据匹配度阈值0.65低于此值的证据直接丢弃上下文保留 token8000只保留黑板摘要和最近证据反思间隔轮次2每两次搜索强制反思一次矛盾度权重0.1让少量冲突证据进入视野其中上下文保留策略值得单独说。我不建议把全部证据拼进上下文模型在长上下文里会“迷失在中间”。我的做法是维护黑板黑板里只存每个子问题的结论摘要和证据链接。只有当进入最终合成阶段或冲突解决阶段时才把相关证据全文加载进来。这样即使做了十几轮搜索模型实际接触的 token 数也控制在合理范围成本也随之降低。成本控制还有一个技巧对搜索结果做“并行摘要”。我会把一批文本块用轻量模型并行摘要而不是逐个调用大模型。实测中并发数设为 4 时时间几乎可以做到单机本地模型下最快。如果使用远程 API注意并发限制超时重试退避机制必须加好。4. 踩坑记录与排查技巧4.1 典型问题与失效模式MiroThinker 1.5 在开发过程中暴露过几个典型的失效模式我把它们列成速查表现象根因解决方案搜索轮次无限增加始终不收敛反思函数一直在生成新任务但黑板上置信度没有实质变化强制设定最大轮次并对“新任务”做去重如果与已有任务覆盖同一意图则不再生成模型输出明显错误事实但证据都支持模型在合成时没有严格引用黑板证据开启了“自由联想”模式在合成提示中要求逐条引用证据链并开启模型的“引用强制”指令深搜索把大量无关文本抓进证据池质量评分中“信息密度”权重偏低提高匹配度阈值并加入来源类型过滤反思阶段上下文溢出黑板摘要没有压缩越存越长每次写入黑板时调用摘要函数仅保留结论与证据链接模型反复要求搜索同一关键词查询扩展没有去重在检索缓存中以意图 ID 为键进行持久化相同意图直接返回缓存运维过程中我还有个近乎执念的习惯每次跑完一个课题会把最终答案和黑板存成一个 Jsonlines 历史文件。这样即使后续想复现也能直接回放研究过程而不是只看一个孤零零的答案。这对排查问题尤其有帮助。4.2 诊断与修复的常用脚本我写了一个简单的状态检查脚本用来追踪每次运行中黑板的变化。它的思路是打印每一轮的子问题列表及置信度变化这样一眼就能看出是不是有子问题一直没解决。# 简化版状态追踪脚本 def inspect_blackboard(blackboard_path): with open(blackboard_path, encodingutf-8) as f: for line in f: record json.loads(line) if record[type] blackboard_update: print(f第{record[round]}轮) for sub in record[sub_questions]: print(f - {sub[question]} 置信度: {sub[confidence]:.2f} 来源数: {sub[source_count]})如果某几个子问题在连续两轮内置信度没有任何提升就说明搜索任务没有触及要害。这时需要回看对应轮次的检索意图检查是不是查询表达太宽泛或太狭窄。我遇到过好几次查询词太泛搜回来的全是教程型内容与科研数据型结论无关。解决办法是在查询后面加类型约束词例如把“注意力机制 长文本分类”改成“注意力机制 长文本分类 benchmark accuracy”。4.3 效率与质量权衡的避坑建议这里分享三条实在的心得。第一不要一味加深搜索深度。当证据池已经可以覆盖所有子问题再多搜两轮带来的边际收益很低反而会引入相互矛盾的噪声。我设定的终止条件里有一项“已有至少两个独立来源支持该子问题”到达这个条件就基本不需要继续了。第二慢思考需要设置在“刀刃”上。有些阶段不需要深度推理比如证据摘要、关键词扩展用轻量模型就行。我把模型路由做成可配置让“深度反思”调用大模型“常规操作”调用小模型最终整体成本降低了约一半。第三研究智能体最怕的不是模型不够聪明而是状态管理一塌糊涂。我强烈建议把“研究黑板”当作一等公民所有决策都通过网络摘录结构化事实来完成而不是依赖对话历史里的零散信息。这会大幅降低后续排查和复现的难度。5. 实测效果与边界分析5.1 在模拟科研课题上的表现我用三组模拟课题做了横向测试一组是“长文本分类中高效注意力机制比较”一组是“轻量级目标检测模型的工业部署最优解”还有一组是“结合知识图谱的推荐系统冷启动方案”。每组课题都要求生成一份 1500 字左右的综述并且要包含对比表格和明确的结论建议。MiroThinker 1.5 在三组课题上的平均搜索轮次是 9.3 次平均耗时 17 分钟生成的研究报告参考来源数量平均为 23 个。相比我之前的基础 Agent平均耗时 3 分钟来源数量 6 个信息覆盖度提高了接近四倍。更重要的是报告中出现了基础 Agent 完全不会做的“反例分析”例如在注意力机制比较中系统主动指出“某些稀疏注意力变体在短序列任务上收益明显下降”这是通过专门搜索反方证据得到的。为了验证证据的可靠性我还会人工抽检每条关键结论的来源。抽样 30 条关键论断其中有 28 条能直接追溯到原文另外 2 条属于系统基于多篇文献的合理推断。这个准确率对于研究辅助场景是可用的。5.2 与普通 Agent 的横向对比数据我整理了一份精简的对比表方便直观理解“慢思考、深搜索”带来的收益指标普通 AgentMiroThinker 1.5平均搜索轮次1~29.3平均生成耗时分钟3.217.4引用来源数量623关键论断可溯源比例61%93%出现明显事实错误比例12%3%是否包含反方证据分析否是需要说明的是这里的“普通 Agent”就是我早期做的那个简单版本它没有反思循环也没有证据质量管理。所以这个对比不是贬低所有 Agent 产品而是想说明范式本身的价值。MiroThinker 1.5 的耗时增加非常明显但在研究场景下这 17 分钟换来的可信度提升是完全值得的。5.3 MiroThinker 1.5 的已知边界与未来改进这套方案也有明显的边界。第一它高度依赖搜索引擎和文献库的可用性。如果某个领域的数据源非常封闭深搜索就会变成“深瞎逛”。我的对策是允许用户注入私有数据源比如把内部文档挂载成本地检索索引。第二反思机制再强也受制于模型本身的推理能力。如果基座模型不够好反思只会制造更多幻觉。我建议至少使用当前一梯队的大模型作为反思引擎小模型最好只在工具模块里用。第三当前系统还缺乏真正的时间线管理。对于时效性要求高的课题比如“过去三个月某领域的研究趋势”它还不能自动追踪多个时间点的信息变化。未来我打算加入一个“快照对比”模块对不同时间检索到的证据做差异分析提炼变化趋势。这项工作还在进行中但已经有了初步原型。最后再分享一个小技巧如果你也想在自己的项目里做研究智能体不用一开始就全套上 MiroThinker 的管线。先从一个简单的循环开始比如“思考 → 搜索 → 反思 → 再搜索”跑通逻辑后再逐步加入证据评分、黑板状态、对抗性反思这些细节。我个人的经验是增量演进比一次性设计容易太多而且每一步都能立刻看到效果。等这些模块稳定了再回头审视你会发现“慢思考”和“深搜索”已经内化成了你系统的本能。