来源说明Mistral AI 官网《Mistral 推出 Agentic Search多步检索提升 AI 系统复杂文档查询准确率》2026-08-20https://mistral.ai/news/agentic-search数据核实RuntimeWire、Pivot News、TPS Report 等媒体对同一发布的报道文中评测数据均为 Mistral 官方自测、未独立验证一、先看痛点一次性 RAG 在长文档上为什么翻车传统 RAG 的流程大家都很熟把文档切成 chunk、向量化、建索引查询时做一次 top-k 召回把命中的片段拼进 prompt让模型直接作答。这个流程在答案就藏在某一段里的简单场景很好用但遇到复杂文档就暴露三条固定限制只查一次第一次命中什么就是什么模型不会根据结果回头改检索词再搜一遍分块粒度固定答案跨在两个 chunk 之间、藏在表格里、落在脚注里时top-k 召回经常漏不迭代没有打开文档看看再决定下一步看哪的机制模型只能拿碎片硬答。Mistral 在发布里举了一个很典型的例子问1953 年美国全年月度国防开支总和一次性检索只能找到覆盖半年的公报拼出来是个残缺答案而多步检索第二次搜索就找到了 1954 年 2 月的一份财政部公报里面含全年 12 个月的数据读取相关页后算出总和 44,463 百万美元。答案不在第一次命中里但检索循环能找到它。二、Agentic Search 的核心把检索变成模型驱动的循环Mistral 于 2026-08-20 发布 Agentic Search。它不是替换你的检索索引而是在索引之上加一层文件系统式工具让模型自己决定先搜什么、打开哪份文档、翻到哪页、读哪段、在哪份文档里做匹配。每一步工具的结果都喂回模型模型再决定下一步直到它认为证据够了才作答。五个核心工具全部模仿人在文件浏览器里的操作工具作用类比search在整个语料库做语义/混合检索返回候选文档全局搜索open打开一份目标文档双击文件navigate跳到文档的某一页、某一节或某一区域翻目录跳转read读取指定位置的具体内容阅读正文grep在已打开的那份文档里做词法匹配文档内 CtrlF这套机制有两个关键设计。第一无需微调任何会调用工具的模型都能驱动这个循环检索质量跟着模型的推理能力走而不是被 chunking 策略卡死。第二按需读取模型只在需要时才打开、才读取而不是每次都灌入一大堆 top-k 文本块所以多步循环反而更省 token见下面的数据。三、公开评测数据官方自测未独立验证Mistral 用自家 Mistral Medium 3.5 和第三方 Z.ai GLM-5.2 做了测试测试用的是默认分块、默认排序没有针对性调优FinanceBench368 份 SEC 申报文件150 题Mistral Medium 3.526.7% → 86%其中仅 search 循环就贡献 47.3 个百分点open/navigate/read/grep 再贡献 8.7 个百分点GLM-5.226.7% → 86%search 贡献 52.6 个百分点导航类工具再 6.7 个百分点。OfficeQA Pro133 题696 份扫描版美国财政部公报约 89,000 页GLM-5.26.3% → 51.9%提升 45.6 个百分点。成本与延迟相对只用 search 的循环token 使用Mistral Medium 3.5 下降 23.9%GLM-5.2 下降 33.7%FinanceBench p90 延迟从 255 秒降到 154 秒平均延迟从 108 秒降到 71 秒。注意这些数字是 Mistral 自测口径第三方尚未独立复现。学习者拿去写文章没问题但落地前务必用自己数据集压一遍。四、最小循环代码示意非官方 APIAgentic Search 的产品形态是 Mistral Search Toolkit SDK含 QueryEngine、VectorRetriever 等组件并提供了一个 MCP server让任何智能体都能调用同样的五个工具。下面这个骨架只表达多步检索循环的通用结构不是官方 SDK 的调用方式# agentic_search_loop.py —— 多步检索循环的最小骨架示意代码非官方 APIdefagentic_search_loop(query,tools,model,max_steps8):messages[{role:user,content:query}]for_inrange(max_steps):# 必须设上限防止检索空转replymodel.chat(messages)# 模型决定下一步动作ifreply.finished:# 模型认为证据足够停止returnreply.answer observationtools.execute(reply.tool_call)# 路由到 search/open/read 等messages.append({role:tool,content:observation})# 观测回填returntimeout# 超上限后兜底返回代码里几个关键点messages完整的对话历史。每次工具结果必须作为tool角色的消息追加回去模型才能看到上一步的结果再决策这是循环能收敛的前提tools.execute(tool_call)把模型发出的工具调用路由到 search/open/navigate/read/grep 之一返回结构化观测文本max_steps检索循环必须有步数上限否则模型可能在文档之间反复横跳、白烧 tokenreply.finished模型给出证据够了的信号或等价地直接输出最终答案循环在此终止。五、什么时候该用什么时候别用Mistral 的定位说得很明确Agentic Search 不是一次性检索的替代品该用长申报文件、法律合同、技术规格这类密集文档需要跨多份文档对比、对账的问题答案必须能溯源到具体文档位置的场景表格和扫描件这类版式即含义的内容。别用短文档直接查找、高吞吐的关键词/语义搜索、答案位置已知的简单问答。这些场景一次性 RAG 更快、更省。索引仍然是地基多步循环只是让模型在已经命中的候选集里继续挖掘索引质量差循环再聪明也没用。六、对 AI Agent 学习者的三点启示这是 RAG 向 Agentic Retrieval 演进的标志检索从一条固定管道变成一组模型可调用的工具方向值得跟踪。你也可以在自己熟悉的框架里复刻这套模式比如用 LangGraph 或 OpenAI Agents 注册 search/open/read/grep 四个工具跑一个同样的循环。工具分发正在走向 MCPMistral 把检索能力打包成 MCP server意味着任何遵循 MCP 的智能体都能接入。学习 Agent 开发时把MCP 化当作工具设计的默认姿势会更省力。评测口径要留个心眼官方自测数据通常没有独立验证选型对比时看别人的复现结果别只盯着宣传数字。一次性检索是把答案在哪赌在第一次召回上多步检索是把怎么找的决策权交给模型。对学习者来说与其继续堆更细的分块和更强的 embedding不如先学会让模型边查边想——这可能是 RAG 类应用下一步最重要的能力。