VibeSearchBench：面向真实世界中长期主动搜索的评测基准

1 引言

基于大语言模型的 AI 智能体已成为强大的搜索专家 [12, 20]，能够通过数百次工具调用在复杂的真实网络环境中导航，寻找所谓的“大海捞针”。然而，评估与体验之间始终存在差距：前沿模型在 BrowseComp [21] 和 WideSearch [22] 等基准测试中不断取得更高分数，而真实终端用户却持续反馈结果“偏离主题”或“不理解我的意思”。

根本原因在于基准测试对搜索任务的设定方式与用户实际搜索方式之间存在错位。在实际场景中，大多数用户一开始无法、也确实不能完全阐明自己的信息需求。一次真实的搜索过程表现为用户与智能体之间的迭代交互：(用户)模糊的查询 →(智能体)部分结果与澄清 →(用户)表达逐渐浮现的偏好与需求 →(智能体)调整搜索方向 →(用户-智能体交互) →……信息需求逐步收敛为具体解决方案。我们将这类任务称为 VibeSearch。

现有的主流搜索基准测试（如表 1 所示）在三个关键方面未能捕捉到 VibeSearch 范式。（1）过度指定的查询。任务约束被详尽且明确地打包到单个提示词中（例如 WideSearch 会预先提供完整的表结构），没有为智能体留出主动引导用户意图的空间。（2）单轮交互。当前的基准测试不支持持续的用户-智能体交互，从而跳过了 VibeSearch 中最具挑战性和最有价值的步骤：主动且持续地挖掘用户的真实搜索意图。（3）固定结构的输出与评估。输出结果是根据预设结构（如项目、集合或表格）进行评估的。然而，现实世界中的知识关系本质上是复杂的，用户的搜索意图难以用僵化的结构来建模。

我们认为，有效的 VibeSearch 系统应遵循两个原则。首先，搜索应是一个双向收敛的过程，而非单向的问答。用户往往只有在看到一些相关信息后，才能清晰表达自己的偏好；因此，智能体应将返回部分结果与提出后续问题交替进行，与用户共同将模糊的需求演变为具体的解决方案，而不是遵循“先澄清、后搜索”的两阶段流程。其次，输出与评估应基于无预设模式的结构化信息。固定模式的评估虽然客观稳定，但与现实世界中复杂的知识结构不符 [28]；而自由文本评估则需要设计评估标准，这本质上是主观且不稳定的 [17, 23, 25]。我们观察到，一个没有任何预设模式的有向图，可以建模与搜索意图相关的任意目标信息，同时仍能实现细粒度、可客观验证的评估。

为填补这一空白，我们推出了 VibeSearchBench，这是一个旨在评估智能体长周期主动搜索能力的基准测试。我们人工筛选了 200 个高质量评估任务，涵盖两个子集——VibeSearch-Pro（专业场景）和 VibeSearch-Daily（日常生活场景），横跨 20 个领域，其中中英文任务各 100 个。为确保分布多样性，每个任务都涉及一个独立主题。每个任务包含一个用户画像，用于说明搜索者的背景和潜在意图，以及一个真实知识图谱，该图谱以无模式有向图的形式编码目标信息。基于这些组件，我们设计了：(i) 一个渐进式信息揭示的用户模拟器，可在与智能体的多轮交互中逐步透露信息需求；(ii) 一个图匹配评估框架，能够对检索到的信息进行客观且细粒度的评估。

然而，一个基准测试的价值，完全取决于其评估时的运行环境。如今，搜索功能绝大多数是通过部署为个人助手的智能体框架 [14, 10, 3] 来访问的，用户在其中通过多轮交互提出模糊、不断演变的查询，而非现有基准测试所假设的那种完全明确的单轮提示词。由于恰恰抽象掉了这种动态特性，当前的基准测试无法告诉我们前沿模型在实际部署中是如何进行搜索的——它们的分数所描述的场景，真实用户几乎永远不会遇到。VibeSearchBench 正是为了评估前沿模型在真实用户搜索场景下的表现而设计的，其部署方式与在智能体框架中一致。我们在 OpenClaw（一个广泛采用的生产级框架）上实例化了这一评估，并额外报告了 ReAct 的结果作为研究侧的参考基线。在七个前沿模型上的实验得出了三个关键发现。首先，所有模型表现均不佳：最佳模型（Claude Opus 4.6）的平均 F1 分数仅为 30.30，更高的主动性（每个用户轮次调用 7-8 次工具）与更好的性能相关，而过度的资源消耗则因上下文溢出而反常地降低了结果。其次，错误分析揭示了三个级联瓶颈：压缩轨迹因信息丢失导致 F1 分数下降 8-12 个点；由于意图引导效率低下，没有模型能成功达到用户模拟器的完成信号；模型生成了结构扁平的知识图谱，未能覆盖所需的知识。第三，对 OpenClaw 三个核心机制（子智能体协作、本地记忆和长期记忆）的消融实验表明，没有一个能带来显著改进，这表明 VibeSearch 的挑战需要模型层面的根本性进步，而非框架层面的架构增强。

2 相关工作

搜索基准测试。现有的搜索基准测试沿着深度和广度这两个互补维度评估智能体，但大多在完全指定、单轮交互的范式下运行。BrowseComp [21] 和 DeepSearchQA [9] 强调深度，要求持续的多跳浏览以检索难以找到的事实；WideSearch [22] 则针对广度，评估智能体将并行来源聚合到预指定表格中的能力；而 GISA [27] 将输出格式泛化为在固定模式匹配下的项目、集合、列表和表格。InteractComp [5] 引入了模糊查询和多轮交互，但其用户模拟器遵循简单规则，输出仍作为单一实体匹配进行评估。相比之下，VibeSearchBench 将基于角色的渐进式揭示与无模式图评估相结合，共同捕捉了不断演变的意图启发过程的真实动态以及现实世界信息的复杂关系结构。

野外环境下的智能体工具基准测试。随着智能体工具迅速成熟为广泛部署的个人助手产品，一系列并行的工作应运而生，旨在对其通用智能体能力进行基准测试，包括 Claw-Eval [24]、ClawBench [26]、WildClawBench [6]、QwenClawBench [15]、PinchBench [19] 和 Claw-Mark [11]。值得注意的是，这些基准测试中的大多数仍然将其部分任务分配给搜索和研究导向的场景，这反映了一个经验性观察：一旦此类工具在野外环境中部署，信息获取仍然是用户最频繁、要求最高的需求之一。这使得智能体工具与搜索的交集成为一个特别重要的研究场景，而非一个边缘领域。

3 VibeSearchBench

3.1 任务定义

我们将 VibeSearch 形式化定义如下。每个任务包含一个用户画像和一个真实知识图谱，其中 是实体集合， 是三元组集合（每个三元组表示头实体 与尾实体 之间的关系）。 是一个无模式限制的有向图，能够对与搜索意图相关的任意目标信息进行建模。

用户画像包含用户的背景资料（领域专长、偏好等）、一个初始模糊查询 、以及一系列分阶段的信息需求 ，其中 是第 阶段的触发条件， 是用户在该阶段将披露的新需求。

搜索过程被建模为多轮交互。在第 轮，智能体将对话历史和可用搜索工具作为输入，执行搜索操作，并生成回复 。用户模拟器评估 是否满足当前触发条件 ：若满足，则披露 并进入下一阶段；否则，推动智能体继续交互。交互过程持续进行，直到所有阶段均被处理或预算耗尽。

交互结束后，智能体将所有收集到的信息组织成一个预测知识图谱 ，以三元组列表形式输出。评估通过图匹配计算 与 之间的三元组级别精确率、召回率和 F1 值。

3.2 构建流程

专家标注。我们从 20 个领域招募专业标注人员。每位标注人员需完成以下工作：(1) 设计一个合理的搜索场景，包含一个初始模糊查询 ；(2) 模拟与 AI 助手的多轮交互，逐步细化其搜索需求；(3) 构建一个真实知识图谱，其节点和三元组与搜索意图及最终获取的信息保持一致。为确保分布多样性，每个任务覆盖不同的主题。该流程共生成 200 个任务，涵盖 VibeSearch-Pro（专业领域）和 VibeSearch-Daily（日常场景），其中中文和英文任务各 100 个。

用户画像合成。基于已标注的多轮查询和真实图谱，我们合成了结构化的用户画像。每个画像定义了信息披露阶段，其中每个阶段指定了：(1) 触发条件（例如，智能体主动询问某个方面，或回复中包含特定信息）；(2) 条件满足时用户的回复内容；以及 (3) 条件未满足时的行为策略（例如，推动智能体继续、评论结果或请求更多细节）。原始标注人员会审查并修订每个画像，以确保其与真实图谱的一致性。

质量控制。我们采用双重审查机制来确保数据质量。每项任务标注完成后，会由两位不属于标注人员的领域专家独立审查。审查内容包括：(1) 搜索场景的合理性和真实性；(2) 多轮交互流程的自然性和逻辑连贯性；(3) 信息需求逐步披露的合理性；(4) 真实图谱中事实信息的正确性；以及 (5) 用户画像与真实图谱之间的一致性。两位审查员的意见必须同时通过；任何在任一维度上未通过的任务都将被退回给标注人员进行修改或重做，直至满足所有质量标准。

3.3 用户模拟器

用户模拟器通过获取角色设定和智能体的响应来生成用户的回复，从而驱动多轮交互。它遵循四个核心原则：(1) 渐进式披露：信息需求分阶段逐步披露，迫使智能体主动挖掘更深层次的需求。(2) 条件驱动转换：每个阶段仅在满足明确的触发条件时才会推进（例如，智能体提及特定信息、询问相关方面或完成一个里程碑）。(3) 持续施压：当条件未满足时，模拟器会通过评论结果、请求详细信息或催促完成来持续互动。(4) 自然对话：模拟器会回应智能体的每一个问题，包括不相关的问题（例如，“没有特别偏好”），确保交互的真实性。我们使用一个大语言模型作为骨干，通过系统提示词将这些原则编码为行为规则。我们在第19条中展示了该提示词。

3.4 基于图的评估

我们提出了一种基于信息蕴含的评估框架，该框架使用大语言模型作为评判者来执行图匹配，能够处理语义等价的表达（例如，实体别名、关系同义词），这与精确匹配不同。对于召回率，评判者会判断每个真实三元组是否被预测图“覆盖”，考虑直接匹配、包含关系、多个三元组的联合覆盖，或通过现有预测关系进行的组合推导。精确率计算为参与覆盖至少一个真实三元组的预测三元组所占的比例。F1分数是精确率和召回率的调和平均数。真实三元组被分批处理并并行评估以提高效率。正式细节见附录A。

3.5 统计数据

表2展示了VibeSearchBench的总体统计数据。该基准测试包含200个任务，均匀分布在VibeSearch-Pro（专业领域）和VibeSearch-Daily（日常生活）两个子集中，涵盖100个中文任务和100个英文任务，涉及20个不同的领域。每个任务的真实知识图谱平均包含212.43个节点和298.32个三元组，反映了所需信息的丰富程度。VibeSearch-Pro的知识图谱明显大于VibeSearch-Daily（373.56个三元组对比223.07个三元组），表明专业领域的任务涉及更复杂的知识结构。每个任务平均涉及139.70个不同的来源URL，URL与三元组的比率为0.47，表明每个来源通常提取多个事实。VibeSearch-Daily的该比率（0.54）高于VibeSearch-Pro（0.42），表明日常生活信息源更为分散，且单个信息源的信息量较少。代表性示例见附录C。

4 实验

4.1 实验设置

模型。我们在VibeSearchBench上评估了七款前沿大语言模型：Claude Opus 4.6 [2]、GPT-5.4 [13]、Gemini-3.1 Pro [8]、Seed2.0 Pro [16]、Kimi K2.6 [1]、DeepSeek-V4-Pro [4] 和 Qwen-3.5-397B-A17B [18]。这些模型涵盖了闭源和开源前沿模型。

智能体框架。我们在以下框架下进行实验：（1）ReAct，经典的推理与行动框架，智能体在每一步交替进行推理和工具执行；（2）OpenClaw，一个快速成熟的智能体工具包，被广泛用作个人助手。比较这两个框架旨在揭示不同的交互范式如何影响VibeSearch的性能。

实现细节。所有模型均使用默认参数运行；搜索工具配置详见附录 B。我们将最大上下文窗口设置为 256k。对于 ReAct，我们为其配备了一种简单的压缩机制来处理上下文溢出情况：当模型的上下文即将超过 256k 个 token 时，我们让其总结自身上下文，然后基于此摘要继续与用户交互。我们使用 Seed-2.0-Pro 作为用户模拟器的骨干模型。每个模型在每个任务上运行 3 次，并报告平均结果。我们采用第 3.4 节中定义的三元组级别精确率、召回率和 F1 值作为评估指标。

4.2 主要结果

表 3 展示了所有模型在两种框架下的结果。

总体情况。即使是最强的模型 Claude Opus 4.6，在 OpenClaw 下也仅达到 30.30 的平均 F1 值，所有模型得分均低于 33，这表明当前模型对于 VibeSearch 任务仍远未达到要求。一个清晰的层级结构显现出来：Claude Opus 4.6 和 DeepSeek-V4-Pro 构成第一梯队（F1 值 27），Kimi K2.6 处于中间范围，GPT-5.4 和 Qwen3.5-397B-A17B 则落后（20–23）。OpenClaw 在大多数模型上略优于 ReAct（Claude +2.43，GPT +1.88），但 Kimi K2.6（26.09 对比 26.17）和 Gemini-3.1 Pro（23.54 对比 23.62）未显示出显著差异，这表明智能体工具框架的收益取决于底层模型的能力。Seed2.0 Pro 的每日 F1 值在 OpenClaw 下显著提升（20.58 至 24.64），表明较弱的模型可能从框架支持中获益更多。

精确率与召回率。大多数模型表现出召回率高于精确率（例如，Claude：P=24.88，R=36.34），倾向于以牺牲大量无关三元组为代价来追求广泛覆盖。这种不平衡在每日任务上尤为明显，Claude 的召回率达到 39.20，而精确率降至 21.60。唯一的例外是 Gemini-3.1 Pro（P=34.61，R=20.63），它保守地输出高置信度信息，但在专业任务上遗漏了近 84% 的真实三元组。Kimi K2.6 实现了最均衡的配置（P=28.29，R=27.52），既避免了过度生成，也避免了探索不足。

专业版对比日常版。专业子集的 F1 值始终高于日常版（例如，Claude：29.79 对比 25.95；DeepSeek：28.70 对比 25.37），因为专业领域的信息集中且结构良好。日常场景更具挑战性，因为（1）信息更加分散（URL 到三元组的比率为 0.54 对比 0.42），并且（2）用户需求更加多样化且更难预测。Gemini-3.1 Pro 是一个显著的例外，它在日常版上取得了更高的 F1 值（24.66 对比 22.41），因为当真实图谱较小时（日常版：223 个三元组对比专业版：374 个），其仅使用片段策略所受的惩罚较小。

4.3 交互行为

表 4 展示了所有模型在两种框架下的交互行为统计数据。

主动性。#Asst/#User 比率衡量的是智能体在用户交互轮次之间执行的独立搜索和推理工作量；比率越高，表明主动性越强。Claude Opus 4.6 的比率最高（ReAct：8.26），平均每次用户回复执行 7-8 次工具调用，同时 F1 分数也最高，这证明了主动性与性能之间的直接联系。Gemini-3.1 Pro 的比率最低（2.84），被动等待用户驱动的探索，导致覆盖范围严重受限。

交互效率。Claude Opus 4.6 的用户交互轮次最少（ReAct：13.3），信息披露效率最高。GPT-5.4 是一个值得注意的反例：尽管其助手交互轮次很高（99.6），但其用户交互轮次也是最高的（OpenClaw：19.9），导致 #Asst/#User 比率并不突出（4.34）。更关键的是，其上下文压缩次数远超所有其他模型（1.27，其他模型为 0.7），因为冗长的输出会频繁触发上下文溢出，破坏先前检索到的信息并迫使进行冗余的重新搜索，形成了一个“冗长输出 → 上下文溢出 → 信息丢失 → 性能下降”的恶性循环，这从根本上解释了为何它资源消耗最高，F1 分数却最差。

框架对交互模式的影响。在 OpenClaw 框架下，Claude 的助手交互轮次减少（109.8 → 93.6），同时 F1 分数提升（27.87 → 30.30），表明每轮交互效率更高。Seed2.0 Pro 则呈现相反模式：助手交互轮次增加（73.0 → 84.8），同时 F1 分数也提升（23.22 → 25.23），得益于探索空间的扩大。

4.4 成本-性能分析

资源消耗与性能之间不存在正相关关系。图3展示了各模型输出token数量及工具调用次数与F1得分之间的关系。如图所示，资源消耗与F1得分并非正相关。GPT-5.4消耗的资源最多（输出token和工具调用次数均远超其他模型），但F1得分最低，原因是冗长的输出会频繁触发上下文压缩，导致后续搜索沦为重复劳动。Gemini-3.1 Pro的资源消耗最低，且几乎从不使用访问工具（Pro：0.05次），导致信息获取深度严重不足。Claude Opus 4.6和DeepSeek-V4-Pro在中等资源消耗水平下取得了最佳F1得分，这表明存在一个效率最佳点：探索不足会限制覆盖范围，而过度探索则会因上下文管理负担而降低性能。

5 分析

5.1 错误分析

我们分析了所有ReAct轨迹，并沿三个流水线阶段对失败进行了分类（表5）。这些失败会级联放大：检索过程中的上下文溢出导致智能体遗忘先前已披露的需求，从而在下游产生不对齐的输出。完整的错误分析见附录E。

信息检索与上下文管理失败。模型陷入两种对称性失败之间：过度探索导致的上下文溢出，与保守检索造成的信息缺口。如表5的Comp.%和F1列所示，压缩后的轨迹在F1分数上持续下降8-12个点（平均值从0.26降至0.16）。GPT-5.4是前者的典型：其压缩率最高（72.0%），F1分数从零压缩时的0.25降至两次及以上压缩时的0.12（表14），冗长输出引发了叠加溢出循环。Gemini-3.1 Pro则是后者的代表：它完全避免压缩（0.0%），但几乎从不访问搜索结果摘要之外的页面（在Pro上平均每项任务仅访问1.1个页面）；在Daily数据集上，Gemini至少访问一个页面的轨迹，其召回率高出55%（0.34对比0.22；附录E）。Kimi K2.6取得了最佳平衡，搜索量适中，且在活跃搜索模型中压缩率最低（6.8%）。

多轮交互与意图引导失败。所有运行中几乎没有任何轨迹到达用户模拟器的[DONE]信号；所有轨迹均以智能体主动给出答案或达到最大轮数而终止。如表15所示，超过15轮用户交互的轨迹平均F1分数仅为0.18，而10轮左右的轨迹为0.23，这既反映了任务本身难度更高（因信息分散需要更多轮次），也反映了在错误问题上浪费了轮次。我们进一步衡量了用户消息中包含敷衍模式（表明意图引导失败）和重定向模式（表明过早推进阶段；表16）的比例。Gemini-3.1 Pro的被动策略（#Asst/#User比率为2.84）产生了最高的敷衍回复率（在Daily数据集上为7.9%），而所有模型的重定向率均稳定在3-6%之间，这揭示了一种普遍倾向：在完全满足当前需求之前就推进到下一阶段。

知识图谱构建与输出失败。我们通过分析每个关系的覆盖率（表17），考察了预测知识图谱与真实知识图谱之间的结构对齐情况。模型能够有效提取事实，但无法对其进行层级化组织：即使是最优模型，在事实性关系（如 participating_country、restructuring_year）上能达到 100% 的覆盖率，但在组织性和层级性关系（如 includes_phase、case_participated）上却为 0%，仅生成扁平的实例级三元组。如表 5 的 Over% 和 Under% 列所示，这一结构性差距导致了两种截然不同的失败模式。过度生成影响了 54% 的 Claude 轨迹，主要源于文献元数据提取（无效率 99%）和主观评估（无效率 95–99%；表 18）。欠生成主导了 46% 的 Gemini 轨迹，原因是保守的检索导致大部分信息未被提取。格式失败进一步引发了灾难性崩溃：Seed2.0 Pro 因格式错误的 JSON 输出产生了 28 条零 F1 轨迹（在所有模型中最多），这凸显了知识图谱构建在长交互历史下仍然脆弱。

5.2 OpenClaw 分析

我们以 Kimi K2.6 和 Qwen3.5-397B-A17B 作为基础模型，对 OpenClaw 框架的三个核心机制进行消融实验：子智能体协作、本地记忆和长期记忆。所有实验重复 3 次并取平均值。辅助指标（#Asst、#Tools、Compact）来自 Pro 子集。

子智能体。将检索任务委托给 4.0–8.2 个子智能体会显著增加工作负载（#Asst 增加 64%–129%，#Tools 增加 82%–129%），但 F1 分数并未呈现一致的提升（Kimi Pro 下降 0.95，Qwen Pro 提升 1.53）。Qwen 的压缩率从 0.20 降至 0.08，证实子智能体确实减轻了上下文压力，但 F1 分数几乎没有改善，这是因为跨智能体信息协调在主智能体整合过程中造成了显著的信息损失。

本地记忆。尽管采用率很高（Kimi 76.3%，Qwen 53.2%），F1 分数仍保持不变（下降 0.5）。记忆操作带来了显著的上下文开销：Kimi 的助手轮次增加了 25%，压缩率翻倍（0.11 升至 0.23）；Qwen 将工作从检索转向记忆维护（#Tools 减少 17%），但压缩率仍然上升。持久化带来的收益被引入的上下文压力所抵消。

终身记忆。所有条件下 F1 值的差异均低于 1.0，表明跨任务知识迁移未能生效。终身记忆几乎不改变行为：Kimi 的 #Asst 和 #Tools 与朴素基线相同（52.3 vs. 52.5，76.8 vs. 76.8），但压缩率仍然增加（0.07→0.14，Qwen 0.18→0.27）。两个模型表现出不同的失败模式：Kimi 主动查询预构建记忆（采纳率 84.0%），但检索到的策略过于通用；Qwen 基本忽略记忆（采纳率 19.3%），回归标准行为。

总结。前沿智能体框架的三种核心机制均未能显著提升 VibeSearch 性能，这表明所需能力（演化意图理解、分散信息整合和结构化知识构建）无法仅通过外部架构增强来解决。关键在于基础模型的进步：更强的长上下文整合能力和更精确的意图建模。

5.3 元评估分析

我们随机抽取 50 条轨迹供领域专家评审，并使用三个 LLM 评判者（Qwen3.5-397B-A17B、Kimi K2.6、Seed2.0 Pro）。三者与人类专家的总体一致性均超过 98.5%（Kimi 最高，达 98.92%），证实该评估框架可可靠地替代人工标注。

6 结论

我们推出了 VibeSearchBench，这是一个用于评估大语言模型智能体在长周期主动搜索任务中的基准测试。在该任务中，智能体必须通过多轮交互协作来提炼模糊的用户意图，并生成无固定模式的信息图谱。对七款前沿模型在 ReAct 和 OpenClaw 两种框架下的评估显示，即使是最优模型也仅达到 30.30 的 F1 分数，上下文溢出、意图引导效率低下以及知识图谱输出结构扁平化被识别为关键瓶颈。消融实验进一步证实，架构层面的增强（子智能体、局部记忆、长期记忆）并未带来有意义的性能提升。此外，不同模型上框架效果的不一致性（例如，OpenClaw 提升了 Claude 的表现，但对 Kimi 没有影响）凸显出，针对广泛采用的智能体框架进行优化对于实际部署至关重要。

贡献

Z.Y.¹,†, S.L.¹,†, Lei Huang¹,†, Yunfan Zhang², Jiajie Wu², Yida Zhao², Jialong Wu², Kuan Li², Suyang Wu², XingYu¹, Xiang Cheng¹,‡

小红书 Dots Studio 通用后训练团队²²²https://unipat.ai/UniPat AI † 核心贡献者 ‡ 项目负责人

参考文献

• [1] M. AI Kimi k2.6：推进开源编程。外部链接：链接 引用自：§4.1。
• [2] Anthropic 推出 Claude Opus 4.6。外部链接：链接 引用自：§4.1。
• [3] Claude Code。外部链接：链接 引用自：§1。
• [4] DeepSeek-AI DeepSeek-V4：迈向高效百万 token 上下文智能。外部链接：链接 引用自：§4.1。
• [5] M. Deng, L. Huang, Y. Fan, J. Zhang, F. Ren, J. Bai, F. Yang, D. Miao, Z. Yu, Y. Wu, Y. Zhang, F. Teng, Y. Wan, S. Hu, Y. Li, X. Jin, C. Hu, H. Li, Q. Fu, T. Zhong, X. Wang, X. Tang, N. Tang, C. Wu, and Y. Luo (2025) InteractComp：使用模糊查询评估搜索智能体。外部链接：2510.24668, 链接 引用自：表 1, §2。
• [6] WildClawBench 外部链接：链接 引用自：§2。
• [7] M. Du, B. Xu, C. Zhu, L. Zhang, X. Wang, and Z. Mao (2026) DeepResearch Bench：深度研究智能体的综合基准测试。收录于：第十四届国际学习表征会议，外部链接：链接 引用自：表 1。
• [8] Google Gemini 3.1 Pro 模型卡。外部链接：链接 引用自：§4.1。
• [9] N. Gupta、R. Chatterjee、L. Haas、C. Tao、A. Wang、C. Liu、H. Oiwa、E. Gribovskaya、J. Ackermann、J. Blitzer、S. Goldshtein 和 D. Das（2026）《DeepSearchQA：弥合深度研究智能体的全面性差距》。外部链接：2601.20975，链接 被引用于：表1，§2。
• [10] Hermes 智能体。外部链接：链接 被引用于：§1。
• [11] F. Meng、L. Du、Z. Wu、G. Chen、X. Liu、J. Liao、C. Jiang、Z. Wan、J. Gu、P. Zhou、R. Huang、Z. Zhao、S. Ding、A. Yu、B. Peng、B. Xia、H. Sun、H. Liang、J. Xie、J. Chen、J. Song、L. Yang、M. Xu、Q. Qiu、R. Fu、S. Zhai、S. Wang、T. Ma、T. Wu、W. Jin、Y. Wang、Y. Dai、Y. Lai、Y. Shu、Y. Liu、Y. Hao、Y. Niu、J. Huang、J. Zhuo、Z. Shen、L. Wu、H. Yao、C. Chen、C. Xie、Y. Zhou、J. Zhang、Z. Zheng、M. Hu 和 M. Q. Shieh（2026）《ClawMark：面向多轮、多日、多模态协作者智能体的真实世界基准》。外部链接：2604.23781，链接 被引用于：§2。
• [12] OpenAI 深度研究系统卡。外部链接：链接 被引用于：§1。
• [13] OpenAI GPT-5.4 思考系统卡。外部链接：链接 被引用于：§4.1。
• [14] OpenClaw——个人 AI 助手。外部链接：链接 被引用于：§1。
• [15] Qwen 团队与阿里巴巴数据（2026年4月）《QwenClawBench：面向 OpenClaw 智能体的真实用户分布基准》。外部链接：链接 被引用于：§2。
• [16] B. Seed《Seed2.0 模型卡：迈向应对真实世界复杂性的智能前沿》。外部链接：链接 被引用于：§4.1。
• [17] M. Sharma、C. B. C. Zhang、C. Bandi、C. Wang、A. Aich、H. Nghiem、T. Rabbani、Y. Htet、B. Jang、S. Basu、A. Balwani、D. Peskoff、M. Ayestaran、S. M. Hendryx、B. Kenstler 和 B. Liu（2025）《ResearchRubrics：用于评估深度研究智能体的提示词与评分标准基准》。外部链接：2511.07685，链接 被引用于：§1。
• [18] A. Q. 团队《Qwen3.5：迈向原生多模态智能体》。外部链接：链接 被引用于：§4.1。
• [19] P. 团队（2026）《PinchBench：面向 AI 编码智能体的真实世界基准》。外部链接：链接 被引用于：§2。
• [20] T. D. Team、B. Li、B. Zhang、D. Zhang、F. Huang、G. Li、G. Chen、H. Yin、J. Wu、J. Zhou、K. Li、L. Su、L. Ou、L. Zhang、P. Xie、R. Ye、W. Yin、X. Yu、X. Wang、X. Wu、X. Chen、Y. Zhao、Z. Zhang、Z. Tao、Z. Zhang、Z. Qiao、C. Wang、D. Yu、G. Fu、H. Shen、J. Yang、J. Lin、J. Zhang、K. Zeng、L. Yang、H. Yin、M. Song、M. Yan、M. Liao、P. Xia、Q. Xiao、R. Min、R. Ding、R. Fang、S. Chen、S. Huang、S. Wang、S. Cai、W. Shen、X. Wang、X. Guan、X. Geng、Y. Shi、Y. Wu、Z. Chen、Z. Li 和 Y. Jiang (2025) 通义深度研究技术报告。外部链接：2510.24701，链接 被引用自：§1。
• [21] J. Wei、Z. Sun、S. Papay、S. McKinney、J. Han、I. Fulford、H. W. Chung、A. T. Passos、W. Fedus 和 A. Glaese (2025) BrowseComp：一个简单但富有挑战性的浏览智能体基准测试。外部链接：2504.12516，链接 被引用自：表1，§1，§2。
• [22] R. Wong、J. Wang、J. Zhao、L. Chen、Y. Gao、L. Zhang、X. Zhou、Z. Wang、K. Xiang、G. Zhang、W. Huang、Y. Wang 和 K. Wang (2025) WideSearch：对智能体广泛信息搜索能力的基准测试。外部链接：2508.07999，链接 被引用自：表1，§1，§2。
• [23] Q. Yang、Y. Liu、J. Li、J. Bai、H. Chen、K. Chen、T. Duan、J. Dong、X. Hu、Z. Jia、Y. Liu、T. Peng、Y. Ren、R. Tian、Z. Wang、Y. Xiao、G. Yao、L. Yin、G. Zhang、C. Zhang、J. Jiao、Z. Zheng 和 Y. Gong (2026) OneMillion-bench：语言智能体距离人类专家还有多远？外部链接：2603.07980，链接 被引用自：§1。
• [24] B. Ye、R. Li、Q. Yang、Y. Liu、L. Yao、H. Lv、Z. Xie、C. An、L. Li、L. Kong、Q. Liu、Z. Sui 和 T. Yang (2026) Claw-eval：迈向可信赖的自主智能体评估。外部链接：2604.06132，链接 被引用自：§2。
• [25] F. Ye、Y. Hu、P. Zhu、Y. Li、Z. Jin、Y. Xiao、Y. Wang、L. Wang、Z. Zhang、L. Wang、Y. Deng、B. Wang、Y. Zhang、L. Su、X. Wang、H. Zhao、C. Wei、Q. Ren、B. Hooi、A. Bo、S. Yan 和 L. Bing (2026) MiroEval：在过程与结果上对多模态深度研究智能体进行基准测试。外部链接：2603.28407，链接 被引用自：§1。
• [26] Y. Zhang, Y. Wang, Y. Zhu, P. Du, J. Miao, X. Lu, W. Xu, Y. Hao, S. Cai, X. Wang, H. Zhang, X. Wu, Y. Lu, M. Lei, K. Zou, H. Yin, P. Nie, L. Chen, D. Jiang, W. Chen, 和 K. R. Allen (2026) 《ClawBench：AI 智能体能否完成日常在线任务？》。外部链接：2604.08523，链接。引用自：第 2 节。
• [27] Y. Zhu, X. Zhang, M. Zhang, J. Jin, L. Zhang, X. Song, K. Zhao, W. Zeng, R. Tang, H. Li, J. Wen, 和 Z. Dou (2026) 《GISA：通用信息搜索助手的基准测试》。外部链接：2602.08543，链接。引用自：表 1，第 2 节。
• [28] J. Ziomek, W. Bankes, L. Wolf, S. S. Ramesh, X. Tang, 和 I. Bogunovic (2026) 《LLM-WikiRace 基准测试：大语言模型能在现实知识图谱上规划多远？》。外部链接：2602.16902，链接。引用自：第 1 节。

附录 A 评估细节

本附录提供了第 3.4 节所述基于图的评估框架的正式定义和实现细节。

A.1 三元组召回率

对于真实关系图中的每个三元组，我们使用大语言模型作为评判者来判断预测图是否蕴含该三元组所表达的事实信息。当且仅当满足以下任一条件时，该真实三元组被判定为“已覆盖”：

1. 1.

   某个预测三元组直接表达了相同的信息；

2. 2.

   某个预测三元组包含更多信息，并涵盖了该真实三元组；

3. 3.

   多个预测三元组共同覆盖了该真实三元组的信息；

4. 4.

   可以通过预测图中已有的显式关系对多个预测三元组进行组合，从而推导出该真实三元组。

三元组召回率定义为被覆盖的真实三元组所占的比例：

A.2 三元组精确率

在召回率评估过程中，大语言模型评判者会同时记录每个被覆盖的真实三元组的支撑证据，即哪些预测三元组参与了覆盖。如果一个预测三元组参与了至少一个真实三元组的覆盖，则该预测三元组被视为“有效”。三元组精确率定义为有效预测三元组所占的比例：

A.3 三元组 F1 值

三元组级别的 F1 值是精确率和召回率的调和平均数：

A.4 实现细节

为提升评估效率，我们将真实三元组划分为多个批次并进行并行评估。大语言模型评判提示词包含详细的评判标准、常见错误警告以及示例，以确保评估的准确性和一致性。具体提示词见第20条。

附录B 工具规格说明

我们为智能体配备了四种工具，涵盖网络搜索、网页内容访问、学术文献检索和代码执行。所有工具均通过函数调用暴露给模型，智能体可在每个推理步骤中自由调用任意工具。

搜索。

一个通用网络搜索工具。智能体提供查询字符串，工具返回顶部搜索结果（包括标题、URL和摘要文本）。这是所有模型中最常用的工具，用于发现相关信息来源并获取初步线索。

{
  "name": "search",
  "description": "Searches for information related to
    query and displays topn results.",
  "parameters": {
    "properties": {
      "query": {"type": "string",
        "description": "The search query string."},
      "topn": {"type": "integer",
        "description": "Number of results to return.",
        "default": 10}
    },
    "required": ["query"]
  }
}

访问。

一个网页内容访问工具。智能体提供一个或多个URL以及目标描述，工具访问指定页面并返回针对该目标定制的内容摘要。与仅依赖搜索结果摘要相比，访问工具能从网页中提取更详细、更完整的信息。我们的实验表明（第5.1节），访问工具的使用与信息覆盖率高度相关。

{
  "name": "visit",
  "description": "Visit one or more webpages and return
    a summary of their content tailored to the
    specified goal.",
  "parameters": {
    "properties": {
      "url": {"type": "array",
        "items": {"type": "string"}, "minItems": 1,
        "description": "A list of webpage URLs to visit."},
      "goal": {"type": "string",
        "description": "The specific information to extract
          or focus on when summarizing the webpage content."}
    },
    "required": ["url", "goal"]
  }
}

学术搜索。

一个学术文献检索工具。智能体提供查询字符串，工具在Google Scholar中搜索相关论文，返回标题、链接、发表日期、来源和摘要文本。该工具主要用于VibeSearch-Pro子集，用于检索特定领域的学术信息。

{
  "name": "scholar_search",
  "description": "Search Google Scholar for academic
    papers and publications. Returns titles, links,
    dates, sources, and snippets.",
  "parameters": {
    "properties": {
      "query": {"type": "string",
        "description": "The search query for
          Google Scholar."}
    },
    "required": ["query"]
  }
}

Python。

一个代码执行工具。智能体提供Python代码，工具在沙盒环境中执行该代码，返回标准输出和标准错误。该工具主要用于数据处理和计算任务，例如解析结构化数据、执行数值计算或格式化输出结果。

{
  "name": "python",
  "description": "A utility that executes Python 3.11
    code. Returns both stdout and stderr.",
  "parameters": {
    "properties": {
      "code": {"type": "string",
        "description": "The Python code to be executed."}
    },
    "required": ["code"]
  }
}

附录C 任务示例

我们从每个子集中各选取一个任务示例，以展示 VibeSearch 任务的结构与复杂度。针对每个示例，我们呈现用户画像以及真实知识图谱中的一个代表性子图。受篇幅所限，完整知识图谱在此省略；相关统计信息已在图注中给出。

C.1 VibeSearch-Pro 示例（数学 / 分析学历史）

C.1.1 用户画像

核心身份。

我是一名 24 岁的自学者，一年前从计算机科学转行到纯数学。业余时间一直在研读实分析和复分析的教材，并且反复遇到同一小批数学家的名字出现在几乎所有关键定理上——主要是柯西、魏尔斯特拉斯、黎曼。我好奇的不仅是这些定理的运作方式，更是从牛顿和莱布尼茨时代早期定义松散的微积分，发展到我现在所学的严谨框架的完整历程。我计划为其他自学数学的学习者撰写一个共六部分的博客系列，详细梳理这段历史，因此需要准确详尽的信息来确保文章内容无误。我平时聊天比较随意，想到什么就会追问很多后续问题，并且不关心与分析学发展无关的旁支信息。

阶段性信息披露。

该用户画像定义了 11 个渐进的信息披露阶段。每个阶段都有一个触发条件、一句预设台词，以及在触发条件未满足时的兜底行为。完整规范如下所示。

• •

  阶段 1：关于分析学演变的初始问题。触发条件：对话开始。台词：“微积分是如何从牛顿和莱布尼茨时代那种直观的工具，演变成我们今天所拥有的严谨的实分析和复分析的？”

• •

  第二阶段：关于优先权争议和微积分先驱的提问。触发条件：在助手对微积分发展史进行初步概述，提及牛顿和莱布尼茨是微积分的发明者，或提到两人之间的任何冲突或争议之后。提问内容：“哦对了，我听说他们是独立发明的，但存在优先权争议？到底发生了什么？英国皇家学会对此发布了什么报告？另外，在他们之前，微积分的先驱者都有谁？我见过一种说法，称一位印度数学家更早地提出了级数展开——这是真的吗？”若未满足条件：先追问更早期微积分时代的更多细节。

• •

  第三阶段：关于争议影响和早期微积分传播的提问。触发条件：在助手完整回答了关于牛顿-莱布尼茨优先权争议、英国皇家学会报告以及牛顿/莱布尼茨之前的微积分先驱等问题之后。提问内容：“等等，这场争议竟然导致英国数学界与欧洲大陆长期隔绝？这太不可思议了。在那之后，伯努利兄弟具体是如何帮助传播微积分的？他们与洛必达是什么关系？另外，他们提出的最速降线问题在早期微积分传播中发挥了什么作用？”若未满足条件：先要求完整回答上一组问题。

• •

  第四阶段：关于雅各布·伯努利、常数 e 和早期微积分批评的提问。触发条件：当助手主动询问用户是否想了解更多关于早期微积分传播时代特定人物的细节时。提问内容：“哦对，我还想知道雅各布·伯努利与常数 e 的发现有什么关联？另外，你提到后来有人使微积分变得严谨——第一个公开批评微积分缺乏严谨性的人是谁，他用了什么著名的比喻？”若未满足条件：继续讨论伯努利兄弟和微积分的早期传播。

• •

  第五阶段：询问柯西的基础教材与波尔查诺被忽视的著作。触发条件：当助手完整回答了关于雅各布·伯努利与微积分早期公开批评的相关问题之后。用户提问：“我还记得读过，柯西在法国工程学校的教学最终变成了一本超级基础的微积分教材？这是怎么发生的？另外，我听说有个叫波尔查诺的人在1817年就已经对微积分的一个关键定理给出了严谨证明，但我在教科书里从没见过他的名字——他的工作为什么被忽视了这么久？”若未满足：则继续追问前一组问题的完整答案。

• •

  第六阶段：询问ε-δ定义的演变与实数构造。触发条件：当助手主动询问用户是否想了解更多关于柯西和波尔查诺之后的严谨化过程时。用户提问：“当然，我对此非常好奇。在波尔查诺和魏尔斯特拉斯之间，还有谁对我们今天使用的ε-δ定义的发展做出了贡献？魏尔斯特拉斯的导师在一致收敛概念中扮演了什么角色？另外，当时围绕实数发展出了哪两种不同的构造方法？”若未满足：则继续讨论柯西和波尔查诺对严谨化的贡献。

• •

  第七阶段：询问魏尔斯特拉斯的生平及其病态函数。触发条件：当助手完整回答了关于ε-δ发展、一致收敛和实数构造的问题之后。用户提问：“魏尔斯特拉斯在我的分析教科书里无处不在，我对他很好奇——他的学位路径是不是真的很不寻常？他最后是怎么成为教授的？还有，当他在1872年发表那个处处连续但处处不可导的函数时，数学界是什么反应？”若未满足：则继续追问前一组问题的完整答案。

• •

  第八阶段：关于实分析定理归属与积分演进的提问。触发条件：当助手主动询问用户是否想了解更多特定实分析定理的历史时。对话内容：“是的，这是我注意到的一个大问题！在实分析中那些以人名命名的定理——比如波尔查诺-魏尔斯特拉斯定理、海涅-博雷尔定理、极值定理——是否存在名称与真正首次证明者不符的情况？另外，魏尔斯特拉斯逼近定理后来是如何被推广的？黎曼积分又是如何最终演变为我们在测度论中使用的更现代积分形式的？”未满足时：继续讨论魏尔斯特拉斯的工作和生平。

• •

  第九阶段：关于复分析定理归属问题的提问。触发条件：当助手对实分析定理归属、魏尔斯特拉斯逼近定理的推广以及积分理论的演进等问题给出完整回答之后。对话内容：“等等，归属问题这么普遍吗？那复分析定理呢？我知道柯西-黎曼方程，但我听说最早的实际发现者并不是柯西和黎曼？欧拉公式和辐角原理在复分析基础中扮演了什么角色？另外，我听说刘维尔定理实际上并不是刘维尔证明的，洛朗级数的归属也存在争议？这是真的吗？”未满足时：推动对先前一组问题的完整回答。

• •

  第十阶段：关于复分析证明漏洞及剩余归属问题的提问。触发条件：当助手主动询问用户是否想了解更多其他复分析定理的历史时。对话内容：“当然，我非常想了解。黎曼映射定理的原始证明据说有缺陷？后来是谁修正了它？皮卡大定理也存在归属问题吗？还有，谁给出了代数基本定理第一个完全严谨的证明？我记得高斯在1799年发表了一个证明，但其中存在漏洞？”未满足时：继续讨论已经提出的复分析归属问题。

• •

  第11阶段：询问数学家关系与机构历史。触发条件：在助手完整回答关于黎曼映射定理缺陷、皮卡大定理归属以及代数基本定理证明历史的问题之后。提示语：“这一切太迷人了，我每天都在使用的定理背后竟有这么多隐藏的历史。最后，我想了解这些数学家之间的关系网络——谁指导了谁，哪些大学是这些工作的主要中心？魏尔斯特拉斯指导过哪些后来做出重要贡献的学生？黎曼的教职资格论文题目是如何选定的？柯西和波尔查诺的学术生涯都曾受到政治影响——具体发生了什么？除了他的定理，刘维尔还有哪些重要贡献？哥廷根、巴黎综合理工学院和柏林在不同时代各自如何成为数学中心？”若未满足条件：则继续要求助手完整回答之前的一组问题。

行为指令。

严格按照阶段顺序（阶段1、阶段2……）披露信息，一次只披露一个阶段，绝不跳过或合并阶段。当触发条件未满足时，持续推动助手完成当前任务。对于触发条件为“助手主动提问”的阶段，若助手尚未提出相关问题，则围绕当前主题继续互动，但不要主动提供该阶段的信息。若助手询问任何不属于任何阶段的内容，则以敷衍方式回应（例如“我对那个不太关心”）。绝不透露用户不应知道的答案信息。

C.1.2 真实知识图谱

该任务的完整知识图谱包含260个节点、349条三元组和112种独特关系类型，按深度层次结构组织，涵盖5个主题维度和23个子主题。表10展示了来自“微积分的诞生与优先权之争”分支的一个代表性子图。

该子图展示了 Pro 子集知识图谱的层级组织：抽象的主题维度（维度、子主题）通过特定领域的关系（前驱人物、提出、著作、出版年份、符号体系、发明符号、指控者、官方调查）连接到具体的历史实体。关系类型是无模式且语义丰富的，反映了用户信息需求的探索性。

C.2 VibeSearch-Daily 示例（娱乐 / 游戏选择）

C.2.1 用户画像

核心身份。

我是一名29岁的自由职业平面设计师，同时也兼职做游戏内容创作。我在自己的小型TikTok频道上发布游戏评测和游戏美术设计的深度解析。我已经玩了20多年游戏，所以在花钱和花时间这件事上相当挑剔。我每年只买几款新游戏，所以希望它们质量过硬，没有骗局或隐藏费用。由于我制作游戏美术相关的内容，我会格外关注游戏背后美术团队的质量，并且对不同游戏引擎和美术制作流程如何影响最终产品非常熟悉。我说话比较直接，不喜欢一次性提太多要求让人应接不暇，所以我会在交流过程中逐步补充额外的筛选条件，或者等别人直接问我的偏好时再说。我不在意多人模式或DLC计划之类的额外内容，只关注我提到的那些标准。

分阶段信息披露。

该用户画像定义了10个渐进式的信息披露阶段，实现了一个多步骤的过滤流程。

• •

  阶段1：初始游戏请求。触发条件：对话开始。话术：“我正在找一些值得购买和游玩的好游戏，你能帮我推荐合适的选项吗？”

• •

  阶段2：指定2025年发售要求。触发条件：在助手提供任何初始游戏推荐之后。话术：“哦对了，我只想要2025年新发售的游戏，不要老游戏。” 若未满足：坚持要求初始推荐。

• •

  阶段3：指定Steam 2025年度最佳奖项要求。触发条件：在助手将列表筛选为仅限2025年发售的游戏之后。话术：“很好，现在进一步缩小范围，只保留在Steam 2025年度最佳榜单中获得白金奖或金奖的游戏，这些对我来说是最可靠的选择。” 若未满足：坚持要求仅限2025年的游戏列表。

• •

  阶段4：询问游戏基本信息。触发条件：在助手提供筛选后的2025年Steam白金/金奖获奖游戏列表之后。话术：“完美，你能告诉我这些游戏在Steam上的原价以及运行它们所需的最低显卡配置要求吗？” 若未满足：坚持要求正确的获奖游戏列表。

• •

  阶段 5：筛选游戏规模与商业模式。触发条件：助手提供筛选列表中所有游戏的价格及最低 GPU 信息后。对话内容：“好的，现在我想筛选出 3A 和 2A 级游戏。另外，我只买买断制游戏，完全不要任何内购游戏，我讨厌在买了基础游戏后还要额外花钱。” 未满足时：要求提供完整的基本信息。

• •

  阶段 6：筛选第三方游戏引擎。触发条件：助手将列表筛选为仅包含无内购的 3A/2A 买断制游戏后。对话内容：“太好了，现在能告诉我这些剩余游戏分别由哪家公司开发，以及它们使用了什么游戏引擎吗？我完全不信任自研引擎，所以只保留使用第三方授权引擎的开发商，好吗？” 未满足时：要求确认之前的筛选条件。

• •

  阶段 7：披露内部美术部门要求。触发条件：助手主动询问与游戏开发商内部制作团队或美术制作流程相关的偏好时。对话内容：“哦对了，我只想要那些拥有自己内部美术部门的开发商开发的游戏，不要把所有美术工作外包的公司，那些公司的质量通常很不稳定。” 未满足时：继续讨论当前的引擎筛选结果。

• •

  阶段 8：披露美术团队的 DICE 奖项要求。触发条件：助手主动询问与开发商美术团队奖项或荣誉相关的偏好时。对话内容：“完美，我还只想要那些内部美术部门在 2025 年之前获得过 DICE 奖项或提名的开发商，我非常看重游戏中高质量、获奖级的美术设计。” 未满足时：继续讨论美术部门筛选结果。

• •

  第9阶段：请求美术团队及奖项详情。触发条件：在助手将名单筛选为仅包含那些内部美术部门在2025年前获得过DICE Awards认可的开发者之后。话术：“太好了，现在对于所有满足我全部要求的剩余游戏，你能告诉我开发者内部美术部门的名称、他们在2025年前获得或提名了哪个具体的DICE奖项类别，以及当年DICE颁奖典礼的举办地点吗？” 条件不满足时：推动确认之前的筛选条件。

• •

  第10阶段：请求最终完整总结。触发条件：在助手提供了剩余游戏所有必需的美术团队和奖项详情之后。话术：“完美，你能把所有满足我要求的游戏整理成一个完整、易读的总结吗？包含我们讨论过的所有细节，这样我就能轻松比较了。” 条件不满足时：推动获取完整的奖项详情。

行为指令。

与专业版示例相同的严格阶段顺序。第7和第8阶段需要助手主动推进：如果助手没有询问开发者团队或美术奖项，用户会继续讨论当前话题，但绝不会主动提供这些信息。如果助手询问了任何阶段未涵盖的内容，则回复“我不太关心那个”或“无所谓”。切勿透露用户不应知道的答案信息。

C.2.2 真实知识图谱

该任务的完整知识图谱包含108个节点、229个三元组和14种唯一关系类型，采用扁平分层结构组织（共8层，对应筛选流程）。表11展示了一个代表性子图，说明了选定游戏的筛选链。

该子图展示了 Daily 子集知识图谱中分层、面向过滤的结构：每一层对应一个用户需求阶段，图谱既捕获了通过每个过滤器的实体，也捕获了过滤决策所需的属性。关系类型结构统一（例如，所有游戏共享相同的属性关系），反映了日常信息需求的系统性、标准驱动特性。

附录 D 完整实验结果

D.1 完整性能结果

表 12 展示了在两个子集上，所有模型在两种框架下的完整性能结果，包括平均和最优运行的精确率、召回率和 F1 值。最优与平均之间的差距反映了多次运行的方差：所有模型的最优 F1 值比平均 F1 值高出约 4–6 个百分点，表明单次运行的随机性对性能有不可忽视的影响。采用多轮运行并报告最优结果，能更好地反映每个模型的能力上限。

D.2 工具调用次数与模型 token 消耗

表 13 展示了在两种框架下，所有模型在每个任务上的平均工具调用次数和模型 token 消耗。

输入 token 分析。

输入 token 的差异主要由对话轮次数量以及工具返回内容的长度决定。GPT-5.4 和 Claude Opus 4.6 在 Pro 子集上的输入 token 均超过 10,000K，原因是这两个模型频繁调用工具并维持较长的对话历史，导致每一轮都需要将完整的对话历史作为输入。Gemini-3.1 Pro 的输入 token 最少（1,400K），这与其极低的工具调用次数一致。值得注意的是，Seed2.0 Pro 尽管工具调用次数较少（搜索 57.77 次，访问 10.32 次），但其输入 token 却相对较高（ReAct Daily：4,532K），这是因为其输出 token 量很大（76–92K），这些输出在后续轮次中会被反复作为输入使用。

学术搜索表现出强烈的领域依赖性。

学术搜索工具的使用呈现出显著的领域差异。在 Pro 子集上，所有模型调用学术搜索的频率都远高于 Daily 子集。例如，Claude Opus 4.6 在 Pro 子集上平均调用 23.13 次学术搜索，而在 Daily 子集上仅 0.41 次；GPT-5.4 在 Pro 子集上平均调用 27.23 次，而在 Daily 子集上仅 0.60 次。这与预期相符：Pro 子集涵盖计算机科学、医学、法律、物理和金融等领域，这些领域以学术文献作为关键信息来源。

访问工具的使用情况差异巨大。

Gemini-3.1 Pro 几乎从不使用访问工具（Pro：0.05 次，Daily：0.46 次），而其他模型则大量使用。Claude Opus 4.6 和 GPT-5.4 的访问次数最高（每项任务 30–56 次），表明它们倾向于从搜索结果中访问特定网页以获取详细信息。这直接影响检索深度：Gemini-3.1 Pro 呈现出的高精度、低召回率特征（第 3.2 节），正是其仅依赖搜索摘要而不访问网页完整内容的直接结果。

Python 工具的使用较少且因模型而异。

Python 工具的使用率相对较低，且在不同模型间存在差异。Claude Opus 4.6 在 Daily 子集上使用频率最高（ReAct 框架下：11.67 次调用），主要用于数据处理和结果格式化。Gemini-3.1 Pro 在 Daily 子集上也有中等程度的使用（7.23 次调用），但其 Python 调用倾向于简单计算而非深度数据处理。Seed2.0 Pro 和 Kimi K2.6 几乎从不使用 Python 工具（两者调用次数均低于 0.5 次）。

附录 E 详细错误分析

本附录提供了支持第 5.1 节错误分析的详细定量证据。所有结果均在 ReAct 框架下报告。

E.1 上下文压缩与检索深度

性能下降呈现出惊人的单调性：每次压缩都会使 F1 值降低约 6 个百分点，而输出量则几乎翻倍。经历两次或更多次压缩的轨迹，其产生的 Token 数量是未压缩轨迹的 3.2 倍，但 F1 值却不到后者的一半，这证实了压缩会直接破坏已检索到的信息和中间推理过程。这种恶性循环正是 GPT-5.4 在 ReAct 框架下处于资源消耗最高但总体 F1 值最低这一矛盾局面的定量机制。

在另一个极端，Gemini-3.1 Pro 实现了零压缩，但却面临检索深度不足的问题：它几乎从不调用页面访问工具（在 Pro 子集上平均访问 1.1 次，在 Daily 子集上平均访问 1.9 次），几乎完全依赖搜索摘要。在 VibeSearch-Daily 上，Gemini-3.1 Pro 访问至少一个页面的轨迹，其召回率达到 0.34，而仅依赖搜索摘要的轨迹召回率仅为 0.22（相对提升了 55%）。这一差距在 Daily 任务中尤为明显，因为该子集的 URL 与三元组比率更高（0.54，而 Pro 子集为 0.42），表明信息分散在更多来源中，使得页面级别的信息提取变得至关重要。

E.2 渐进式披露阶段完成情况

在所有轨迹中，几乎没有一次运行能到达 [DONE] 信号；所有运行都以智能体主动回答或达到最大轮数而终止，这意味着每个模型都留下了用户部分潜在需求未被满足。

所有模型均呈现一致的负相关性，低轮次（10 轮）与高轮次（>15 轮）轨迹之间的差距达到 1–9 个 F1 点。这一悖论（解锁更多阶段但性能更差）存在两种互补的解释：（1）本质上更困难的任务需要更多轮次，因为信息更分散、知识图谱更复杂，使得高覆盖率本身就更难实现；（2）未能高效满足触发条件的智能体会浪费轮次，积累上下文并增加压缩风险。

E.3 交互策略与意图引导

呈现出两种模式。首先，拒绝率从 Pro 版（0.6–1.8%）到 Daily 版（2.1–7.9%）显著上升，反映出在日常场景中理解用户意图的难度更大。在极端情况下，Gemini-3.1 Pro 达到了最高的拒绝率（Daily 版为 7.9%），这是其被动策略的结果：在所有模型中，它的 #助手/#用户 比率最低（Pro 版为 2.88，Daily 版为 3.06），因此缺乏提出针对性追问的上下文。然而，仅靠主动性并不能解决问题：Claude Opus 4.6 是最主动的模型（#助手/#用户 = 8.68），但在 Pro 版上也录得了最高的拒绝率（1.8%），这表明过度的主动性会产生用户拒绝的无关追问。这说明决定有效意图挖掘的是交互质量，而不仅仅是数量。

其次，所有模型的重定向率保持惊人的一致，在 5–6%（Pro 版）和 3–6%（Daily 版）之间，揭示了一种普遍的“浅层覆盖”倾向：智能体在完全满足当前需求之前，就持续进入新阶段。这种一致性表明，过早的阶段推进是当前智能体架构的系统性局限，而非特定模型的缺陷。

GPT-5.4 在 Daily 版上还表现出独特的异常终止模式：错误循环（6 例）、上下文长度溢出（7 例）和空响应（1 例），这些都是其上下文管理危机的后果。Claude Opus 4.6 在 Daily 版上触发了 21 次最大轮次终止，此时高主动性适得其反，因为模型持续搜索而非生成输出。非回答类终止的 F1 值（0.183）显著低于正常回答类终止（0.261）。

E.4 知识图谱结构对齐

这种二分法揭示出，模型完全能够提取显式的事实性断言，但从根本上无法重建复杂知识领域的组织架构。例如，一个真实三元组如（"产业政策演进"，"理论基础维度"，"产业政策理论基础"）捕捉的是顶层分类结构，而模型生成的却是（"产业政策"，"has_theoretical_foundation"，"市场失灵"）（事实正确但结构错位，将具体实例放在了真实数据预期为抽象类别的位置）。

E.5 无效预测类型分析

无效预测可分为三个不同的类别：

1. 1.

   书目元数据（页码、卷、DOI、卷/页码）：无效率 98%。模型机械地提取完全超出用户信息需求的引文信息。这是导致 Claude Opus 4.6 精确率异常偏低（Pro 上为 0.137）的主要原因。

2. 2.

   主观评估（重要性、结构创新、核心贡献）：无效率 95%。模型注入关于概念重要性的评价性判断，而非提取事实信息，产生的是与用户搜索意图毫无关联的自我生成式评估。

3. 3.

   无关知识（上诉机构法官、合适的合并结构）：无效性 100%。Gemini-3.1 Pro 从参数化知识中生成了从未通过搜索检索到的三元组（可能准确，但并非用户所请求的内容）。

最后，输出格式失败会导致灾难性的零 F1 结果。Seed2.0 Pro 有 28 条零 F1 轨迹，主要原因是格式错误的 JSON（缺少冒号、非标准键名）。其他零 F1 案例源于空输出或完全的模式不匹配（例如，单个任务上 237 个三元组，F1 = 0）。这些失败凸显出，在长交互历史的压力下，最终的知识图谱构建步骤仍然是一项脆弱的能力。

附录 F 标注细节

我们聘请了 60 多位专家来标注此任务。我们按任务数量付费，每个通过质量检查的任务支付约 300 美元。整个数据集的标注总成本约为 60,000 美元。

附录 G 提示词详情

本附录提供了用于用户模拟器和三元组提取模块的完整提示词。

# Role
You are simulating a real user who is interacting with a research assistant. You must behave
exactly like a genuine human user -- natural, conversational, and responsive to every question
the assistant asks.

# Persona
{user_persona}

# Initial Research Goal
{initial_query}

# Core Principle
Your persona contains a sequence of numbered stages. Each stage has a trigger condition and a
line you will say when the condition is met. You disclose information one stage at a time,
strictly in order. When a trigger condition is not met, you persistently push the assistant to
complete the current work.

# Instructions

## 1. Trigger conditions and disclosure (MOST IMPORTANT)
Your persona lists stages in order. Each stage has a trigger condition that can be one of:
- The assistant’s reply mentions or contains certain information (e.g., lists products, gives
  prices)
- The assistant proactively asks about a certain aspect (e.g., skin type, budget)
- The assistant completes a task or reaches a milestone (e.g., finishes filtering, provides
  ingredients)

When the trigger condition is met: say that stage’s line and advance to the next stage.

When the trigger condition is NOT met:
- You must persistently push the assistant -- comment on results, request more details, urge
  completion, question completeness or accuracy.
- For stages where the trigger is "assistant proactively asks about X": if the assistant hasn’t
  asked, continue interacting around the current topic. But do NOT volunteer that stage’s
  information, and NEVER tell the assistant what to ask.
- You must NEVER skip the current stage.

## 2. Simulate a real user -- respond to EVERY question
A real user answers every question they are asked:
- If the assistant asks about an aspect that matches the current stage’s trigger: reveal that
  stage’s content.
- If the assistant asks about an aspect NOT covered by ANY stage in your persona: respond that
  you don’t care about it (e.g., "I don’t really care about that", "no preference").
- If the assistant asks multiple questions in one turn: address ALL of them in a single reply.

## 3. Follow stage order strictly
- Disclose information strictly in order.
- Never skip any stage, never disclose multiple stages at once.
- Only disclose one stage per turn.

## 4. Persist when trigger conditions are not met
When the current stage’s trigger condition is NOT met:
- Keep interacting and push the assistant toward fulfilling the condition.
- Do NOT go silent, do NOT give up, do NOT change the subject.

## 5. No idle chitchat -- stay on task
- NEVER engage in idle pleasantries, goodbyes, or small talk. You are here to get research done.
- If the assistant seems to be wrapping up but you still have undisclosed stages, keep the
  conversation going.

## 6. Completion
- If the assistant has addressed ALL stages comprehensively, output exactly: [DONE]
- Do NOT output [DONE] until every single stage has been triggered and addressed.

## 7. General rules
- Your responses should be natural and conversational.
- Do NOT ask the assistant to output triples or a knowledge graph.
- Do NOT use Markdown formatting in your responses.
- NEVER reveal answer information you shouldn’t know.
- Output ONLY your response or [DONE], nothing else.

Now, please extract a structured knowledge graph based on our entire conversation.

# Extraction Principles
Extract all information that meets the user’s information needs throughout the entire search
process. The user has provided multi-turn inputs during the conversation, and each round of
interaction has generated its own information needs and research discoveries. You must extract
information relevant to the user’s needs from every single turn, including intermediate results
that were later filtered or narrowed down.

Example: If in the first turn the user asked to find the top 20 beauty brands by sales on
TikTok, and in the second turn the user asked to identify which of those brands have female
spokespersons -- then the final knowledge graph must contain all 20 brands found in the first
turn (along with their sales/ranking information), rather than just keeping the subset of brands
with female spokespersons filtered in the second turn. The research discoveries from each turn
possess independent value.

# Extraction Content
1. Discovered Entities: All specific entities such as products, brands, goods, institutions, and
   people found during the research -- including entities explored in intermediate turns.
2. Attributes relevant to user needs in any turn: For each entity, extract every attribute
   dimension related to any of the user’s questions throughout the entire conversation.

# Rules
- Be exhaustive: Extract all relevant triples from every turn of the conversation.
- Extract only what the user asked for: Only extract triples related to the information needs
  the user explicitly expressed.
- Try not to use "Yes" or "No" as entities in triples: describe facts with objective information.
- One fact per triple: Do not cram multiple independent pieces of information into the tail of a
  single triple.
- Only include information you actually found during your research; do not fabricate data.
- Output the JSON array directly in your response. Do not call any tools.
- Output ONLY the JSON array, with no additional explanations.

# Output Format
Output as an array of JSON triples, where each triple contains a head, relation, and tail:
[{"head": "Entity A", "relation": "Relation", "tail": "Entity B"}, ...]