2025 年 4 月 OpenAI 发布网页搜索评测 BrowseComp 时，GPT-4o 加上网页浏览能力的正确率为 1.9%，专门训练的 Deep Research 则达到 51.5%。到 2026 年 7 月，美团团队已注意到，部分顶尖模型的成绩超过 90%。BenchLM 汇总的分数中，GPT-5.6 Sol 为 92.2%，Kimi K3 为 91.2%，GPT-5.5 Pro 为 90.1%，三者相差约 2.1 个百分点。高分模型逐渐聚集，给评测增加难度成为新的课题。
这也涉及评测范围：在问题和参考答案固定的搜索任务中取得高分，能在多大程度上反映 Agent 自主搜索、持续规划和动态执行的能力？BrowseComp 本身使用网络搜索，并不是只读取一组静态网页。
美团 LongCat 团队于 7 月 24 日集中介绍了 LoHoSearch 和 MineExplorer 两套基准。前者用知识图谱构造更难的搜索题，后者在 Minecraft 世界中测试分钟级、含隐藏前置条件的行动任务。两项工作的论文和数据集均已公开，MineExplorer 还提供了代码与训练环境，可通过 arXiv、GitHub 和 HuggingFace 获取。
人工出题较难控制搜索空间和条件复杂度
BrowseComp 的 1,266 道题由人工设计。出题者基于自己知道的实体和关系构思问题，再反过来验证答案是否唯一。当搜索 Agent 能力较弱时，这套流程产出的题目足以形成有效区分。但人工出题有一个系统性局限：标注者无法站在全局知识网络视角判断哪些条件的候选空间足够大、哪些约束的搜索难度足够高。
LoHoSearch 论文中的一个对比数据说明了这个问题。BrowseComp 中需要检索的「隐藏实体」在维基百科上的入度（反映流行度的指标）明显偏高——这表明人工题目更倾向于选取知名实体，其检索路径和候选空间可能相对有限。相比之下，LoHoSearch 基于覆盖 762 万个维基百科实体的知识图谱自动构建题目，能够系统性地挑选搜索空间大、结构复杂的实体组合，在生成阶段调节影响检索难度的因素。
美团用 DeepSeek-V4-Flash 对比测试：该模型在 BrowseComp 上的准确率为 58.84%，在 LoHoSearch 上为 10.02%。只看答对的轨迹，平均工具调用次数从 35 次增至 61 次，中位数从 26 次升至 59 次。改变出题方式后，模型需要更多轮检索才能找到答案。
LoHoSearch 用知识图谱构造 544 道复杂搜索题
LoHoSearch 的核心思路是「让机器出题」。构建流程分四步：
建图。 从英文维基百科抽取 762 万个实体节点和 2.65 亿条有向边（页面间超链接），每个实体的类型取自 Wikidata 的 P31 类别。这张图谱为后续系统性挑选「难题」提供了全局视野。
控制难度。 LoHoSearch 从两个维度定义搜索难度：搜索空间（满足一个条件的候选实体数量）和结构复杂度（需同时满足的条件数量及依赖关系）。两者恰好是人工出题最难精确控制的变量。针对这两个维度，LoHoSearch 设计了树结构和图结构两种子图：树结构主要放大搜索空间；图结构在此基础上通过环形依赖和交叉约束叠加了结构复杂度。
质量把关。 子图采样后，系统将结构化关系改写为自然语言题目，再经自动验证（检查题目是否完整覆盖子图关系、标准答案是否满足所有条件）和人工复核。最终 75.5% 的题目直接通过人工复核，22.3% 经微调后接受，仅 2.2% 因严重问题被丢弃。
最终数据集。 544 道经人工核验的题目，覆盖音乐、地理、影视、体育等 11 个领域。
在论文已评测模型中，GPT-5.5 准确率最高，为 34.74%。DeepSeek-V4-Pro、Claude-Opus-4.6 和 Kimi-K2.6 集中在 15.53%–15.99%，其余模型均低于 14%。在 DeepSeek-V4-Flash 的对照中，图结构题目的准确率（8.01%）低于树结构（11.89%），说明交叉约束和循环依赖会进一步增加搜索难度。
现有上下文管理策略在 LoHoSearch 上仍有帮助，但收益较小。以 DeepSeek-V4-Flash 配合标准 ReAct 为基线，表现最好的组合（Discard-all + Verify）仅带来 6.8 个百分点的绝对提升，而同一套策略在 BrowseComp 上可带来 14 个百分点的增益。论文认为，LoHoSearch 需要更长的推理链，简单压缩轨迹或重启搜索，仍难以充分保留长程任务所需的信息。对 DeepSeek-V4-Flash 采样 16 次，至少有一次答对的比例（pass@16）升至 38.3%；按模型置信度选择一个答案的 best-of-N 策略则为 24.6%。模型有时已经生成正确答案，却未能把它选出来。
MineExplorer 测试模型能否推断前置步骤并完成行动
LoHoSearch 关注搜索过程，MineExplorer 则要求模型在持续变化的游戏环境中采取行动。
MineExplorer 以 Minecraft 为环境，但设计上刻意剥离了游戏专有知识。每一个原子任务都经过 LLM 裁判判断其主要依赖的是通用世界常识还是 Minecraft 专有机制，后者被过滤掉。团队希望借此减少游戏知识对结果的影响，更集中地测试模型在动态环境中的探索能力。
评测设置上，每个任务实例最多运行 1,800 个环境步（每步 0.1 秒），对应 3 分钟的环境交互。模型需要根据动作之后更新的画面，持续调整策略；这里的时长是环境运行时间，并非模型完成评测所花的总时间。
MineExplorer 将任务按依赖层级的「跳数」分级。单跳任务给出直接目标，多跳任务则包含未在指令中列出的前置任务，Agent 必须从环境中推断需要先做什么。举一个示意性的例子：指令可能要求「建造一个庇护所」，Agent 却需要先判断应去哪里取得材料，再安排后续步骤。这模拟了真实世界中 Agent 工作的关键特征：目标通常是结果导向的，执行路径需要自己规划。
最终数据集包含 813 个人工验证的复合任务。18 个模型、横跨 8 个家族的评测结果给出了三个清晰的发现：
第一，前置步骤越多，成功率越低。 最强模型 Claude-Opus-4.6 整体任务成功率只有 41%。从 1 跳任务（77%）到 4 跳任务（12%），每增加一层隐藏前置依赖，成功率就掉一个台阶。其他被测模型在多跳任务上也普遍表现更差。
第二，推理得分普遍低于感知。 几乎所有被测模型都呈现同一顺序：感知分数 > 行动分数 > 推理分数。以 Claude-Opus-4.6 为例，感知分 61.91，推理分 54.71。这提示，将观察结果转化为有效策略仍是需要改进的环节。
第三，导航是主要失败原因。 对 Claude-Opus-4.6 的失败归因分析显示，导航失败占近 60%。团队还分析了步数和历史画面的影响：较难的任务即使达到步数上限也常常无法完成；历史帧增加到一定程度后，旧画面反而可能干扰判断。团队认为，如何结合历史信息判断当前状态，比单纯增加步数或记忆更值得研究。
搜索和行动测试互补，都有各自的适用范围
LoHoSearch 和 MineExplorer 测量的是两种不同但互补的深层能力。
LoHoSearch 追问的是：当搜索空间足够大、约束条件足够复杂时，Agent 能否有效搜索、持续推理并在长程搜索中管理上下文？MineExplorer 追问的是：当环境持续变化、目标需要推断前置条件、每个动作都会改变世界状态时，Agent 能否制定并执行多步计划？
两套结果说明，检索难度、前置条件和环境变化都会影响表现。BrowseComp 主要测试找到特定信息的能力，更复杂的搜索和行动任务需要补充评测；它们的分数也应按各自任务和配置解释。
两套基准也有共同的局限。它们提供的都是受控环境下的能力测量：LoHoSearch 根据维基百科快照构造问题，但评测时仍通过搜索引擎和网页工具检索；MineExplorer 依赖 Minecraft 的规则。真实部署还会遇到 API 不稳定、网页变化、信息过时、对抗性输入和成本约束，这些问题并未在两项评测中得到系统覆盖。美团团队的论文以「Working in progress」标注 MineExplorer，LoHoSearch 的题目规模（544 道）也意味着大规模重复评测的统计稳健性有待检验。
开发者可据此检查信息保留、规划和导航问题
如果把这两项工作放在一起看，它们为 Agent 开发者提供了几个可操作的信号：
按实际任务补充评测。 BrowseComp 已有模型得分超过 90%，LoHoSearch 本轮最高分不到 35%，MineExplorer 的最强模型在四跳任务上也不到 15%。这些来自不同模型和测试条件的结果，提示开发者分别验证搜索与行动能力，不能当作同一模型的连续成绩。
检查长程搜索中的信息保留。 LoHoSearch 的实验表明，BrowseComp 上验证有效的 Summary/Discard-all 策略在长程搜索中收益大幅收窄。需要更长的推理链和更精细的信息保留机制，而不是简单地压缩或丢弃轨迹。
结合失败案例改进规划和导航。 MineExplorer 中，推理与导航暴露出较多问题。开发者可以先检查模型是否理解前置条件、能否到达目标，再据此决定改进哪些模块；这并不排除其他场景需要提高视觉感知能力。
把总分拆成不同能力和难度。 单一排行榜分数难以解释失败原因。LoHoSearch 区分了搜索空间和结构复杂度两个维度，MineExplorer 区分了感知、行动和推理三个维度，并进一步按跳数分级。这些维度拆分比总分更有诊断价值：它能告诉开发者问题出在哪个环节，而不仅仅是「模型不行」。
两套基准都已开源。LoHoSearch 的数据集在 HuggingFace 上可直接获取；MineExplorer 的代码在 GitHub 上提供了完整的评测流程，支持接入任意兼容 OpenAI API 的模型。搜索 Agent 或多模态 Agent 团队可以用这两套工具补充现有评测，定位模型在复杂检索和多步行动中具体卡在哪一步。
