2025 年 4 月 OpenAI 发布 BrowseComp 时，最强的 GPT-4o 加上网页浏览能力正确率不过 1.9%。到 2026 年 7 月，GPT-5.6 Sol 已经做到 92.2%，紧跟其后的 Kimi K3（91.2%）和 GPT-5.5 Pro（90.1%）之间差距不足 2.1 个百分点。一个设计来测「谁更会搜索」的基准，正在变成一场大家都能拿 A 的考试。
这不是 BrowseComp 独有的问题。当静态搜索基准上的高分不再能区分模型，评测设计者面临一个更根本的追问：Agent 在给定明确问题、静态网页和可枚举答案的任务中表现出的能力，是否等于它在真实世界中自主搜索、持续规划和动态执行的能力？
美团 LongCat 团队于 7 月 24 日同时发布的两套基准——LoHoSearch 和 MineExplorer——正是对这个问题的直接回应。前者用知识图谱重新定义了搜索评测的难度上限；后者把模型丢进实时运转的 Minecraft 世界，测量它们在分钟级、含隐藏前置条件的任务中的真实表现。两项工作均已开源，论文、代码和数据集可通过 arXiv、GitHub 和 HuggingFace 获取。
BrowseComp 为什么饱和了
BrowseComp 的 1,266 道题由人工设计。出题者基于自己知道的实体和关系构思问题，再反过来验证答案是否唯一。当搜索 Agent 能力较弱时，这套流程产出的题目足以形成有效区分。但人工出题有一个系统性局限：标注者无法站在全局知识网络视角判断哪些条件的候选空间足够大、哪些约束的搜索难度足够高。
LoHoSearch 论文中的一个对比数据说明了这个问题。BrowseComp 中需要检索的「隐藏实体」在维基百科上的入度（反映流行度的指标）明显偏高——人工出题不自觉地选了更知名的实体，路径偏短，搜索空间偏小。相比之下，LoHoSearch 基于覆盖 762 万个维基百科实体的知识图谱自动构建题目，能够系统性地挑选搜索空间大、结构复杂的实体组合，使每道题的检索难度在生成阶段就被精确控制。
效果立竿见影：同一个 DeepSeek-V4-Flash 模型，在 BrowseComp 上拿到 58.84%，在 LoHoSearch 上跌到 10.02%。解一道 LoHoSearch 题目的平均工具调用次数从 35 次增至 61 次，中位数从 26 次升至 59 次。难度跃升不是靠增加题目数量，而是靠改变出题方式。
LoHoSearch：知识图谱如何重构搜索评测
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%。图结构题目的准确率（8.01%）明显低于树结构（11.89%），验证了结构复杂度是独立于搜索空间之外的额外难度维度。
LoHoSearch 还揭示了一个此前不易观察的问题：现有上下文管理策略在这里大面积失效。以标准 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 专有机制，后者被过滤掉。这意味着它测的不是「AI 会不会玩 Minecraft」，而是「AI 能不能在一个有物理规则、会动态演化的世界里自主探索」。
评测设置上，每个任务实例运行 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 这类基准上被观察到——不是因为 BrowseComp 设计得不好，而是因为它的测量范围已经被模型填满了。
两套基准也有共同的局限。它们提供的都是受控环境下的能力测量：LoHoSearch 依赖维基百科的固定快照，MineExplorer 依赖 Minecraft 的物理规则。真实部署中的 Agent 还要面对 API 不稳定、网页结构变化、信息过时、对抗性输入和成本约束——这些变量都不在这两套基准的覆盖范围内。美团团队的论文以「Working in progress」标注 MineExplorer，LoHoSearch 的题目规模（544 道）也意味着大规模重复评测的统计稳健性有待检验。
对 Agent 开发者的实际含义
如果把这两项工作放在一起看，它们为 Agent 开发者提供了几个可操作的信号：
不要用 BrowseComp 的高分论证搜索 Agent 已就绪。 一个在 BrowseComp 上拿到 90% 以上的模型，在 LoHoSearch 上可能不到 35%，在 MineExplorer 的四跳任务上可能不到 15%。这三个数字之间的落差，就是当前搜索 Agent「高分低能」的量化边界。
上下文管理策略需要重新设计。 LoHoSearch 的实验表明，BrowseComp 上验证有效的 Summary/Discard-all 策略在长程搜索中收益大幅收窄。需要更长的推理链和更精细的信息保留机制，而不是简单地压缩或丢弃轨迹。
多模态 Agent 的瓶颈排序需要重新审视。 MineExplorer 清楚指出感知不再是第一瓶颈，规划和导航才是。在分配工程资源时，把算力投给更好的视觉编码器，不如投给更好的规划模块和空间推理能力。
评测本身需要分层。 单一排行榜分数掩盖了太多东西。LoHoSearch 区分了搜索空间和结构复杂度两个维度，MineExplorer 区分了感知、行动和推理三个维度，并进一步按跳数分级。这些维度拆分比总分更有诊断价值：它能告诉开发者问题出在哪个环节，而不仅仅是「模型不行」。
两套基准都已开源。LoHoSearch 的数据集在 HuggingFace 上可直接获取；MineExplorer 的代码在 GitHub 上提供了完整的评测流程，支持接入任意兼容 OpenAI API 的模型。对于正在构建搜索 Agent 或多模态 Agent 的团队，这两个基准提供的不是又一组排行榜数字，而是两套诊断工具——告诉你在 BrowseComp 的高分之外，Agent 还差多远。