在开源 AI 代理领域,MiroMindAI 推出的 MiroThinker 代表了搜索代理模型的重要突破。作为旗舰研究代理模型,MiroThinker 不仅专注于工具增强推理和实时信息检索,更引入了 "交互式扩展" 作为继模型大小、上下文长度之后的第三个性能维度。本文将从工程实现角度,深入分析 MiroThinker 的工具增强推理架构及其交互式扩展机制。
一、MiroThinker 核心定位与交互式扩展创新
MiroThinker v1.5(2026 年 1 月 5 日发布)是目前开源搜索代理领域的领先模型,支持 256K 上下文窗口,最多 400 个工具调用,在多个基准测试上达到开源 SOTA 水平。与仅关注模型规模或上下文长度的传统方法不同,MiroThinker 探索了交互式扩展这一新维度 —— 系统性地训练模型处理更深、更频繁的代理 - 环境交互。
正如论文所述:"Unlike previous agents that only scale up model size or context length, MiroThinker explores interaction scaling at the model level—systematically training the model to handle deeper and more frequent agent–environment interactions as a third dimension of performance improvement." 这种创新使得模型能够利用环境反馈和外部信息获取来纠正错误、优化轨迹,而非孤立地进行测试时扩展。
二、工具增强推理架构设计
2.1 ReAct 范式与单代理设置
MiroThinker 基于 ReAct(Reasoning + Acting)范式构建单代理系统。给定查询 q,模型在推理、工具调用和观察之间迭代循环,直到任务终止。在步骤 t,代理维护轨迹 H_t = {(T₁, A₁, O₁), ..., (T_{t-1}, A_{t-1}, O_{t-1})},其中 T_i、A_i 和 O_i 分别表示思维、动作和观察。
思维模型 f_θ 生成内部思维上下文 T_t = f_θ(q, H_t),随后动作策略 A_t = π_θ(H_t, T_t) 输出结构化工具调用。环境执行调用并返回工具响应 O_t = Tool (A_t),更新轨迹为 H_{t+1} = H_t ∪ {(T_t, A_t, O_t)}。当模型不再输出动作时,进入总结阶段生成最终答案 y = g_θ(H_t)。
2.2 模块化工具接口设计
MiroThinker 的工具接口采用模块化设计,每个工具封装特定能力:
执行环境:使用 Linux 沙箱提供隔离运行时,支持 create_sandbox 创建实例,run_command 执行 shell 命令,run_python_code 执行 Python 代码。
文件管理:实现双向文件传输功能,包括 upload_file_from_local_to_sandbox、download_file_from_sandbox_to_local,以及 download_file_from_internet_to_sandbox 从 URL 直接检索远程资源。
信息检索:包含 Google 搜索工具(google_search)返回结构化搜索结果,以及网页抓取工具(scrape_and_extract_info)进行条件信息提取。后者内部使用轻量级 LLM(如 Qwen3-14B)根据代理调用时的指定提取任务相关信息,将冗长的网页内容浓缩为聚焦的文本证据。
2.3 基于最近性的上下文管理策略
为高效利用 256K 上下文窗口,MiroThinker 实施了两项关键策略:
最近性上下文保留:在标准 ReAct 范式中,所有工具输出都保留在消息历史中,常导致上下文利用效率低下。经验观察表明,模型的后续动作主要依赖于最近的观察而非遥远的观察。MiroThinker 采用保留预算 K∈ℕ,仅保留最近 K 个工具响应,同时保留完整的思维和动作序列。
具体实现中,定义步骤 t 时最近响应的索引集 S_t (K) = {i ∈ {1,...,t-1} | i ≥ t-K},构建最近性过滤历史Ĥ_t = {(T_i, A_i, Ô_i)}_{i=1}^{t-1},其中 Ô_i = {O_i, if i ∈ S_t (K); ∅, otherwise}。这种策略在保持推理和动作轨迹的同时,将模型的注意力集中在最相关的观察上,为扩展推理和更深工具使用轨迹释放额外上下文空间。
结果截断:对于可能产生过长输出的工具(如 run_command、run_python_code),当响应超过预定义长度限制时进行截断,并在末尾附加 "[Result truncated]" 标签。
三、交互式扩展的训练实现
3.1 三阶段训练流程
MiroThinker 基于 Qwen2.5 和 Qwen3 模型,采用三阶段训练流程:
第一阶段:代理监督微调(SFT) 构建大规模 SFT 数据集𝒟_SFT = {(x_i, H_i)}{i=1}^N,每个实例将任务指令 x_i 与专家轨迹 H_i = {(T{i,t}, A_{i,t}, O_{i,t})}{t=1}^{T_i} 配对。训练目标为ℒ_SFT (θ) = -𝔼{(x,H)}[∑{t=1}^{T_H} log π_θ(T_t, A_t | x, H{<t})],使模型学习模仿涉及多跳推理和工具使用的专家轨迹。
第二阶段:代理偏好优化(DPO) 构建成对偏好数据集𝒟_PO = {(x_i, H_i^+, H_i^-)}{i=1}^M,基于最终答案正确性确定偏好。使用 DPO 目标结合首选轨迹的辅助 SFT 损失:ℒ_PO (θ) = 𝔼{(x,H^+,H^-)}[L_DPO(x,H^+,H^-)] + λℒ_SFT^{(+)}(θ)。
第三阶段:代理强化学习(GRPO) 采用 Group Relative Policy Optimization 进行完全在线策略训练。奖励函数 R (x,H) = α_c R_correct (H) - α_f R_format (H),结合解决方案正确性和格式遵循惩罚。GRPO 目标最大化期望优势同时保持与参考策略的接近性。
3.2 交互式扩展的实证效果
强化学习训练显著改变了代理 - 环境交互模式。如图 5 所示,RL 调优的 MiroThinker-v1.0-30B 模型在 BrowseComp、BrowseComp-ZH、HLE 和 GAIA 基准上展现出比 SFT 对应物更长的交互轨迹。在可验证奖励的引导下,RL 使模型能够探索更详尽的解决方案路径,显著增加交互深度,系统性地探测多种策略并在得出结论前验证中间结果。
这种行为转变直接与准确性提升相关,平均带来 8-10 个百分点的增益。交互深度与性能之间的这种一致关系被称为交互式扩展:随着工具增强交互的频率和深度增加,研究推理能力相应提高。这形成了继模型大小和上下文长度之后的第三个扩展维度。
四、工程部署参数与配置
4.1 最小配置要求
MiroThinker v1.5 和 v1.0 的最小配置仅需 3 个 MCP 服务器:
-
tool-python:执行环境和文件管理(E2B 沙箱)
- 环境变量:
E2B_API_KEY - 工具:create_sandbox、run_command、run_python_code 等
- 环境变量:
-
search_and_scrape_webpage:通过 Serper API 进行 Google 搜索
- 环境变量:
SERPER_API_KEY、SERPER_BASE_URL - 工具:google_search
- 环境变量:
-
jina_scrape_llm_summary:基于 LLM 的信息提取网页抓取
- 环境变量:
JINA_API_KEY、JINA_BASE_URL、SUMMARY_LLM_*参数
- 环境变量:
4.2 预配置代理设置
apps/miroflow-agent/conf/agent/目录包含多个预配置代理设置:
- mirothinker_v1.5_keep5_max200:单代理带上下文管理,最多 200 轮,保留最近 5 个结果(推荐大多数任务)
- mirothinker_v1.5_keep5_max400:单代理带上下文管理,最多 400 轮,保留最近 5 个结果(仅用于 BrowseComp 和 BrowseComp-ZH)
- mirothinker_v1.0_keep5:单代理带上下文管理,最多 600 轮,保留最近 5 个结果
上下文保留参数keep_tool_result控制保留策略:设置为 - 1 保留所有工具结果,设置为正整数 K 仅保留最近 K 个工具响应。
4.3 模型服务与部署
推荐使用 SGLang 或 vLLM 服务 MiroThinker 模型:
NUM_GPUS=4
PORT=61002
MODEL_PATH=miromind-ai/MiroThinker-v1.5-30B
python3 -m sglang.launch_server \
--model-path $MODEL_PATH \
--tp $NUM_GPUS \
--dp 1 \
--host 0.0.0.0 \
--port $PORT \
--trust-remote-code
五、性能基准与局限性分析
5.1 基准测试表现
MiroThinker v1.5 在多个基准测试上表现优异:
- HLE-Text:39.2%(超越 Kimi-K2-Thinking)
- BrowseComp:69.8%(开源 SOTA)
- BrowseComp-ZH:71.5%(中文搜索代理领先)
- GAIA-Val-165:80.8%(超越多个商业模型)
特别值得注意的是,MiroThinker-v1.5-30B 仅使用 1/30 的参数就超越了 Kimi-K2-Thinking 在 BrowseComp-ZH 上的表现,展示了其参数效率。
5.2 当前局限性
尽管性能卓越,MiroThinker 仍存在一些局限性:
工具使用质量:交互扩展虽然支持更丰富的工具交互,但也暴露了工具使用质量的限制。RL 调优模型比 SFT 模型更频繁地调用外部工具,但部分调用产生边际或冗余贡献,表明需要进一步优化工具使用效率。
过长的思维链:强化学习倾向于鼓励模型产生更长响应以提高准确性,可能导致过长、重复且可读性较差的推理链,减慢任务完成速度并降低用户体验。
语言混合问题:对于非英语输入,模型响应可能表现出多语言混合。例如,当用户查询为中文时,模型的内部推理或中间输出可能包含中英文元素混合,可能导致中文性能欠佳。
沙箱能力限制:模型尚未完全熟练掌握代码执行和文件管理工具。偶尔可能生成导致沙箱超时的代码或命令,或误用代码执行工具读取网页或 PDF,而这些任务本应由专用网页抓取工具更高效处理。
六、未来发展方向
MiroThinker 的成功为开源研究代理设定了新标准,其交互式扩展范式为未来发展方向提供了重要启示:
工具使用效率优化:需要开发更精细的工具调用策略,减少冗余调用,提高每次工具使用的信息增益。这可能涉及工具选择的学习、参数优化的自适应,以及工具组合的智能规划。
多模态扩展:当前 MiroThinker 主要专注于文本处理,未来可扩展至多模态工具使用,包括图像分析、音频处理和视频理解,构建更全面的研究代理。
分布式代理协作:虽然当前采用单代理设置,但 MiroFlow 框架已支持多代理协作。未来可探索分布式代理系统,其中多个专业化代理协同工作,处理复杂的研究工作流。
自适应上下文管理:当前的最近性保留策略使用固定预算 K,未来可开发自适应策略,根据任务复杂度、工具响应信息密度和剩余上下文空间动态调整保留策略。
跨语言优化:针对中文等非英语语言的性能优化,需要更平衡的多语言训练数据和针对特定语言特性的工具适配。
结论
MiroThinker 通过引入交互式扩展作为第三性能维度,重新定义了开源搜索代理的能力边界。其工具增强推理架构、基于最近性的上下文管理策略,以及三阶段训练流程,为构建下一代研究代理提供了可复制的工程实现方案。随着社区对交互式扩展范式的进一步探索和优化,我们有理由期待更强大、更高效的开源研究代理系统的出现,推动 AI 研究能力的民主化进程。
MiroThinker 不仅是一个高性能模型,更是一个开放平台,为研究交互式扩展、工具增强推理和代理系统设计提供了丰富的实验基础。其开源性质确保了透明度、可重复性和社区驱动的创新,这正是推动 AI 研究向前发展的关键要素。
参考资料:
- MiroThinker GitHub 仓库:https://github.com/MiroMindAI/MiroThinker
- MiroThinker 技术论文:https://arxiv.org/abs/2511.11793
- MiroFlow 框架文档:https://github.com/MiroMindAI/MiroFlow