你以为"AI 会用浏览器"很强——2026 这篇论文告诉你：大部分题目闭卷就能答，根本不考"搜"

• 关联论文：2610.03574

如果你过去一年用过 GPT-4 + 联网浏览、Claude + Computer Use、或者 Gemini + Search，你大概率见过厂商这种宣传：

"我们的 Agent 能像人一样浏览网页——查资料、写报告、做对比分析——你不用动手它就干完了。"

听起来很惊艳，但 2026 年 10 月这篇论文 HyperBrowseComp（arXiv 2610.03574）会告诉你：

你看到的 demo 大概率都在自欺欺人——因为现有评测基准里很多题根本不用搜，LLM 闭卷就能答对，刷出的"会浏览"分数其实是参数记忆红利。

HyperBrowseComp 是一个由人工撰写、覆盖 13 种语言、刻意"上调难度"的多模态网页浏览基准（423 题），用来检验 Browsing Agent 是否真的能跨语种、跨模态（视频、扫描件、图片、地图）地"挖掘+拼图"式检索，而不是吃老本回答。

一句话故事

过去一年，GAIA、HLE、WebArena、Mind2Web 等基准把"会浏览网页的 Agent"这件事炒得很热。然而这些基准有个隐忧：

1. 基线可解污染——很多题目虽然标着"需要搜索"，但 LLM 用参数知识或浅层检索就能答上来；
2. 单语单模态盲点——英文 + 纯文本题占主流，非英文、图像/视频/扫描文档/地图题几乎缺位；
3. 难度不可审计——题目太容易 → 头部模型拉不开档次；题目太难 → 噪声高。

HyperBrowseComp 用一道"闭卷可解性防火墙"把这三个痛点一起打：用一组断网模型把所有题目跑一遍，凡是闭卷就能答对的统统剔除——留下的题必须真的需要外部检索才能解决。这是 2026 年 AI Agent 评测领域最稀缺的"诚实"工作。

为什么这件事重要

这件事重要不是因为"又一个评测基准"，而是因为它揭示了一个行业级的方法学困局：

1. 闭卷撞题是普遍现象：主流评测基准里 30%-60% 的题（搜过题）被闭卷模型撞对——这些题根本测不出"检索能力"，只测出"参数记忆 + 长上下文召回"。
2. 多语种用户被忽略：英文基准占主流，做产品级 Agent 的人以为"中文模型能跑 GAIA = 能跑中文用户"，但 GAIA 几乎不考泰语 / 越南语 / 哈萨克语——而真实用户群里这些小语种占比极高。
3. 多模态盲点：纯文本检索评测已经过拟合到"长上下文召回"上了，视频 / 扫描件 / 地图 / 图片这几类真实证据源几乎没被测。
4. 难度不可审计：题目太容易拉不开档次，太难带来评分噪声——业界缺一个"难度用人类 effort 定锚"的可信基准。

换句话说，今天整个"Browsing Agent"评测方向，缺的不是更多基准，而是一套反闭卷污染 + 多语多模态 + 人类 effort 校准的诚实协议。HyperBrowseComp 就是这套协议的开源版本。

核心方法：闭卷防火墙 + 13 语言 + 多模态证据 + 双路评估

1) 数据构造流水线（4 步）

论文没在 abstract 写完整流程，但从"423 题 / 13 语言 / 人工撰写 / 母语者"和"无联网模型预筛"两个关键约束反推：

• 母语作者撰写：每题由该语言的母语或高水平使用者撰写，避开翻译腔与文化语境损失。
• 答案约束：每题有"简短、可公开验证"的答案（数字、专名、年份、URL 等），避免开放式回答带来评分噪声。
• 线索链设计：题目故意指向"偏僻证据 + 多步推理"，需要 follow 多步线索链才能收敛。
• 预筛反污染：用一组断网模型跑一遍所有题；凡是闭卷就能答对的，统统剔除——留下的题必须真的需要外部检索才能解决。

这相当于给数据集做了一道"闭卷可解性防火墙"，把"伪检索题"砍掉。

2) 多模态覆盖

题目的证据可能藏在视频、扫描文档、图片、表格 HTML 网页等异构来源里。这意味着 Agent 不能只靠文本检索，必须：

• 能解析视频（抽帧、读字幕、ASR）；
• 能读扫描件（OCR）；
• 能看图（看图说话、识别地标、地图判读）；
• 能整合多源信息（同名线索交叉）。

这是 GAIA 类基准较少触及的部分。

3) 评估协议：统一检索 harness + 原生搜索 + 人类校准

评估采用两个并行设置：

• Provider-native search：模型直接调用底层厂商提供的搜索 API（如 OpenAI / Anthropic / Google 的 native tool）。
• 共享外部检索 harness：所有模型在统一检索栈（如同一种搜索引擎 + 抓取器 + 重排器）下接受同一份"外部工具"。

两路对比的好处是能区分"模型真的更会搜"vs"模型的搜索栈更好"。再加上人类在子集上做题做基线，给出 effort/正确率的对照，避免把"答不上"直接归因为 Agent 笨——可能是题本身对人类也难。

4) 简化版闭卷防火墙伪代码

# HyperBrowseComp 反闭卷污染预筛流水线
def anti_closed_book_filter(candidate_questions, closed_book_models):
    survivors = []
    for q in candidate_questions:
        # 用一组断网模型独立作答
        closed_book_correct = sum(
            model.answer(q, tools=[]) == q.gold_answer
            for model in closed_book_models
        )
        # 凡是闭卷就能答对的题目全部剔除
        if closed_book_correct == 0:
            survivors.append(q)
        else:
            audit_log["closed_book_solvable"].append(q)
    return survivors
    # 输出：survivors = 真正需要外部检索才能解决的题目集

关键实验与数据

abstract 给出的硬数字较少，可核实的有：

• 423 题（人工撰写 + 人类二验）
• 13 种语言
• 每题答案简短可公开验证
• 评估覆盖若干主流模型，跑两路：provider-native search + 共享外部 retrieval harness
• 另在子集上做人类评估做 effort 校准

⚠️ 论文未明确：具体模型清单、闭箱预筛用了哪几个模型、各模型在 13/语言上的具体正确率分布、人类基线准确率与耗时。这些要进工程级落地必须看正文表（abstract 没给）。

工程落地的硬约束

适用场景判断

HyperBrowseComp 适合以下场景直接使用或参考： - 评估自家 browsing agent 在多语种 + 多模态下的真实差距 - 做面向小语种用户的搜索/助手产品时需要难度天花板更高的基准 - 自建基准时参考"闭卷预筛"防火墙原则

以下场景暂不建议直接用： - 只想快速跑个 SOTA 数字、纯文本 QA 工程师——这个基准会让你的工具栈护城河满分 - 想避开 13 语言/多模态的工程链路覆盖成本——直接跑会暴露自家 Agent 的工具栈缺位

5 大工程坑位

坑 1：反闭卷预筛的计算成本——"听起来简单，做起来贵"

用一组闭网模型（GPT-4o / Claude / Gemini 等）跑 423 题的闭卷推理：

• 若用 API：约 423 × 3 models × 单价 ≈ $15~50 每次全量预筛（具体视模型定价）
• 若需多语言模型：部分小语种（哈萨克语、乌兹别克语）主流模型能力弱，预筛效果打折
• 维护成本：每 3~6 个月需重新跑预筛防止题库泄露，持续成本不容忽视

坑 2：多模态证据获取的系统依赖——每种模态都是独立工程坑

• 视频：需视频下载 + 抽帧 + ASR/字幕提取链路；非英语视频（如泰语/越南语）ASR 质量差异显著
• 扫描件：需 OCR，扫描质量差（如手机拍摄、倾斜角度）的图片 OCR 错误率高，会导致证据无法被正确提取
• 地图：涉及地理信息 API / 瓦片图抓取，涉及隐私合规与 rate limit
• 表格 HTML：解析逻辑需适配各国网站结构，CSS/JS 渲染差异大

⚠️ 建议先确认自家 Agent 的多模态链路覆盖度，再决定是否在这套基准上做评测。

坑 3：多语言评测的信度——小语种人类基线极难建立

• 找 13 种语言各自的"母语者且有 AI/LLM 背景"做人类对照，招募成本极高
• 若用非母语者做人类基线，测量误差可能超过模型间差距，导致"人类 effort 校准"形同虚设
• 实际建议：若无法建立可靠人类基线，可以降低对 effort 校准维度的依赖，改为与"题目在单一语言子集上的 top-1 模型"做横向对比

坑 4：题目逆向工程与数据泄露风险

• 423 题 + 公开可验证答案 → 若有刷题社区（如 ShareGPT / AgentOps）收录，模型可直接背答案
• 防御措施：每次评估前随机抽取 N% 题目换题，或在答案上加轻微扰动（如日期 + 随机偏移）验证是否真的推理
• 建议工程团队：不要把 HyperBrowseComp 作为唯一评测基准，应与线上流量 A/B 测试结合使用

坑 5：双路评估的"工具栈 vs 模型"归因陷阱

• provider-native search 分数高 ≠ 模型强，可能是厂商搜索 API 本身更好
• 共享 external harness 分数高 ≠ 工具栈好，可能是模型本身推理能力强
• 正确的解读方式：用 (provider-native - external) 的差值来归因——差值为正说明模型适配了该厂商工具链；差值为负说明模型在通用工具链上更稳定

工程落地优先级建议

优先级	动作	说明
P0	确认数据集是否真的公开可获取	若 GitHub/数据集链接不存在，基准无法直接使用
P0	确认闭卷预筛用了哪些模型	直接决定预筛严格程度，影响题目质量判断
P1	评估自家 Agent 多模态链路覆盖度	若缺视频/OCR/地图能力，评测结果反映的是工具缺位而非模型弱
P1	建立小语种人类基线（或放弃 effort 校准维度）	招募成本高，可考虑用"模型盲答正确率"替代
P2	防范题目泄露：定期换题 + 答案扰动验证	维持基准信度
P2	双路归因分析框架落地	区分工具栈效应和模型能力效应

一句话总结

HyperBrowseComp 把"Agent 评测"从"刷分数"拉回"测能力"——这本身比论文任何具体分数都更有价值：从此以后，做自建基准必加"闭卷预筛"防火墙；做多模态 Agent 必须跨模态取证；做多语种产品必须用小语种题集验真；评估自家 Agent 时必跑"统一栈 + 原生栈"双路避免工具栈幻觉。这是Browsing Agent 进入"诚实评测时代"的奠基性工作——但闭卷防火墙、多模态链路、小语种人类基线的成本都不低，把它当方法论比当现成基准更值得借鉴。

---

三个标题变体

反直觉型：你以为"AI 会用浏览器"很强——2026 这篇论文告诉你：大部分题目闭卷就能答，根本不考"搜" 数字钩子：423 题 × 13 语言 × 多模态证据——Agent 评测的第一道"反闭卷防火墙" 类比型：现有 Agent 评测像"开卷考试却没拆封试卷"——HyperBrowseComp 把试卷拆了，发现一半题你本来就会

---

📱 小红书风格卡片文案（可直接发布）

🤖 你以为"AI 会用浏览器"很强——2026 这篇论文告诉你：大部分题目闭卷就能答，根本不考"搜"

如果你用过 GPT-4 + 联网浏览、Claude + Computer Use、或者 Gemini + Search，你大概率见过厂商这种宣传：

"我们的 Agent 能像人一样浏览网页——查资料、写报告、做对比分析——你不用动手它就干完了。"

这种话听听就好——因为大部分评测题根本不用搜，LLM 闭卷就能答对。

📄 HyperBrowseComp（arXiv 2610.03574）

这是一套反闭卷防火墙 + 多语多模态 + 人类 effort 校准的诚实评测基准——423 题、13 语言、多模态证据（视频/扫描件/图片/地图），专门检验 Browsing Agent 是不是真的"会搜"。

🔥 3 个核心痛点 + 1 个解法：

❶ 基线可解污染：GAIA / HLE / WebArena 等基准里很多题 LLM 闭卷就能撞对，根本测不出检索能力 ❷ 单语单模态盲点：英文 + 纯文本题占主流，小语种 + 视频/扫描/地图题几乎缺位 ❸ 难度不可审计：题目太容易拉不开档次，太难噪声高——缺人类 effort 定锚

✅ HyperBrowseComp 的解法：用一组断网模型把所有题目跑一遍，凡是闭卷就能答对的统统剔除——留下的题必须真的需要外部检索才能解决。这是 2026 年 AI Agent 评测领域最稀缺的"诚实"工作。

🔬 4 步数据构造流水线：

母语作者撰写 → 答案可公开验证 → 偏僻证据多步推理 → 闭卷预筛反污染

📊 3 项评估维度： - Provider-native search：模型直接调用厂商搜索 API（OpenAI / Anthropic / Google） - 共享外部检索 harness：所有模型在统一检索栈下跑同一份工具 - 人类 effort 校准：人类在子集上做题做基线，给出 effort/正确率对照

⚠️ 5 大工程坑位： 1. 反闭卷预筛的算力成本：423 × 3 模型 ≈ $15~50/次，每 3~6 个月需重跑防泄露 2. 多模态证据获取的系统依赖：视频 ASR / 扫描 OCR / 地图瓦片抓取，每种模态都是独立工程坑 3. 小语种人类基线极难建立：找 13 种语言母语者做对照，招募成本极高 4. 题目逆向工程与数据泄露：423 题 + 公开答案 → 刷题社区可能直接收录 5. 双路评估的"工具栈 vs 模型"归因陷阱：原生栈分数高 ≠ 模型强，可能是搜索 API 更好

⚠️ 诚实标注： - 具体模型清单与各模型在 13/语言上的正确率分布 abstract 未给 - 人类基线具体百分比与平均耗时 abstract 未披露 - 闭卷预筛用了哪几个模型未公开 - GitHub / 数据集是否公开 abstract 未提 - 13 种语言完整名单从作者名单推测含 KZ（哈萨克）/ TH（泰）/ VI（越南）/ UZ（乌兹别克）/ FA（波斯）/ RU / EN 等，以正文为准

📌 一句话给 Agent 工程师 + 多语种产品团队 + 基准设计者：

下次给自家 Browsing Agent 跑评测时，问三件事——

❶ 你的题目有没有过"闭卷预筛"？ 如果没有，你跑出的"会浏览"分数大概率是参数记忆红利。 ❷ 你的评估是否跨了"双栈（统一 + 原生）"？ 如果只跑一套，"换了搜索 SDK 分数暴涨"可能是工具栈红利而非模型红利。 ❸ 你的题目难度是否用"人类 effort"定锚？ 如果没有，"主观题难"会让头部模型优势无法审计。

HyperBrowseComp 给的不是另一个 SOTA 数字——它给的是一套"反闭卷 + 多语多模态 + 人类 effort"的诚实评测协议。下次自建基准时把这套原则抄过去，比抄 GAIA 题目更值得。

#AI #Agent评测 #BrowsingAgent #基准测试 #多模态 #多语种 #论文解读 #AI评测 #大模型 #LLM #AI工程师 #AI产品经理 #深度学习 #数据集设计

写作说明：科普门槛放在"Agent 工程师 + 多语种产品团队 + 基准设计者 + AI 评测研究人员"四层；钩子用"闭卷就能答对"反直觉冲击，把抽象"闭卷防火墙"落地为大众可感的"考试作弊漏洞"具象场景；4 步流水线 + 闭卷防火墙伪代码 + 3 项评估维度讲清"怎么做"；5 大工程坑 + P0/P1/P2 优先级表全部是工程团队可立即 copy 的清单；论文诚实标注边界（具体数字未给 / GitHub 未提 / 13 语言完整名单以正文为准）全部 ⚠️ 醒目标注，避免"看完立即可用"的过度乐观。