When Search Agents Should Ask: DiscoBench for Clarification-Aware Deep Search

# When Search Agents Should Ask: DiscoBench for Clarification-Aware Deep Search
Source: [https://arxiv.org/html/2606.27669](https://arxiv.org/html/2606.27669)
Yiling Tao1,2,\*,§,Shihan Deng1,\*,Meiling Tao, Pengzhi Wei1,Zhichao Hu1,†,Zhihao Zhu1,†

1Hunyuan, Tencent2Shenzhen International Graduate School, Tsinghua University

###### Abstract

Search agents powered by large language models \(LLMs\) are increasingly used to solve complex information\-seeking tasks, requiring multi\-step retrieval and reasoning to fulfill user goals\. However, existing benchmarks often assume that user queries are complete and explicit, overlooking the fact that real\-world search requests are frequently vague, underspecified, or even factually incorrect\. In deep search scenarios, such ambiguity can propagate along multi\-step reasoning chains and lead agents toward incorrect search trajectories\. To address this gap, we introduceDiscoBench, a benchmark for clarification\-aware deep search, designed to evaluate whether search agents can proactively identify ambiguity, ask effective clarification questions, and recover correct reasoning paths through user interaction\.DiscoBenchcontains 211 samples and 463 ambiguity instances across 11 real\-world domains, covering four ambiguity types\. We further design a user simulator for multi\-turn interaction and evaluate model performance from four perspectives: task utility, ambiguity detection, interaction strategy, and cost efficiency\. Experiments on representative LLMs show that ambiguity detection and effective clarification are distinct capabilities, and that repeatedly searching instead of asking for clarification often performs worse than direct guessing, highlighting a critical gap between retrieval ability and interactive problem\-solving in current search agents\.

When Search Agents Should Ask:DiscoBenchfor Clarification\-Aware Deep Search

Yiling Tao1,2,\*,§, Shihan Deng1,\*, Meiling Tao,Pengzhi Wei1,Zhichao Hu1,†,Zhihao Zhu1,†1Hunyuan, Tencent2Shenzhen International Graduate School, Tsinghua University

11footnotetext:Equal contribution\.22footnotetext:Corresponding authors\. Correspondence to[elliotzhu@tencent\.com](https://arxiv.org/html/2606.27669v1/mailto:[email protected])44footnotetext:Work done during an internship at Tencent Hunyuan\.## 1Introduction

In recent years, search agents based on Large Language Models \(LLMs\) have made significant progress in the field of information retrievalMialonet al\.\([2023](https://arxiv.org/html/2606.27669#bib.bib3)\); Weiet al\.\([2025](https://arxiv.org/html/2606.27669#bib.bib2)\); Wonget al\.\([2025](https://arxiv.org/html/2606.27669#bib.bib4)\)\. The search paradigm is shifting from traditional static corpus retrieval to autonomous Web Search Agents capable of handling complex goalsXiet al\.\([2025](https://arxiv.org/html/2606.27669#bib.bib5)\); OpenAI \([2025](https://arxiv.org/html/2606.27669#bib.bib6)\); Google \([2025](https://arxiv.org/html/2606.27669#bib.bib7)\)\. These agents can simulate human navigation and browsing behaviors, achieving multi\-step reasoning and information integration in dynamic and complex internet environmentsWuet al\.\([2025](https://arxiv.org/html/2606.27669#bib.bib1)\); Zhouet al\.\([2024](https://arxiv.org/html/2606.27669#bib.bib26)\)\.

![Refer to caption](https://arxiv.org/html/2606.27669v1/x1.png)Figure 1:A motivating example of ambiguity propagation in interactive deep search\.However, current paradigms often presuppose that the user’s initial query is complete and explicit\. This assumption deviates significantly from real\-world information\-seeking behavior, where users often provide vague or fragmented queries due to blurred memories or cognitive load limitationsAliannejadiet al\.\([2019](https://arxiv.org/html/2606.27669#bib.bib27)\); Zamaniet al\.\([2020](https://arxiv.org/html/2606.27669#bib.bib28)\)\. In deep search scenarios, the impact of this discrepancy is further amplified\. Unlike traditional single\-hop retrievalKwiatkowskiet al\.\([2019](https://arxiv.org/html/2606.27669#bib.bib30)\), deep search involves complex multi\-step reasoning chainsTrivediet al\.\([2022](https://arxiv.org/html/2606.27669#bib.bib31)\), meaning any subtle ambiguity in the initial query can lead to cascading errors in subsequent navigation and information integration, wasting expensive computational resources on the wrong path\. As illustrated in Fig\.[1](https://arxiv.org/html/2606.27669#S1.F1), failing to proactively clarify ambiguous checkpoints further propagates errors throughout the remaining search process\. Consequently, introducing interactive clarification mechanisms to resolve ambiguity has become particularly important\. Meanwhile, search tasks naturally provide strong factual grounding, allowing both interaction quality and retrieval correctness to be objectively verified through external evidence\. This property offers a reliable signal for evaluating an agent’s ability to identify and resolve ambiguity in complex interactive settings\.

While the academic community has recognized the importance of query ambiguity and interaction, existing benchmarks still struggle to evaluate the disambiguation capabilities of search agents\. Mainstream retrieval benchmarks \(e\.g\., GAIAMialonet al\.\([2023](https://arxiv.org/html/2606.27669#bib.bib3)\), BrowseCompWeiet al\.\([2025](https://arxiv.org/html/2606.27669#bib.bib2)\), AgentBenchLiuet al\.\([2024](https://arxiv.org/html/2606.27669#bib.bib32)\)\) mostly assume explicit queries and focus on multi\-hop reasoning while neglecting proactive interaction\. Ambiguity\-focused datasets \(e\.g\., AmbigQAMinet al\.\([2020](https://arxiv.org/html/2606.27669#bib.bib8)\), DEEPAMBIGQAJiet al\.\([2025](https://arxiv.org/html/2606.27669#bib.bib9)\)\) primarily consist of static scenarios and lack dynamic interaction simulation, whereas interaction\-based benchmarks \(e\.g\., IN3Qianet al\.\([2024](https://arxiv.org/html/2606.27669#bib.bib10)\), UserBenchQianet al\.\([2025](https://arxiv.org/html/2606.27669#bib.bib11)\)\) are often confined to closed sandbox environments, falling short in the depth and breadth of Web\-scale open\-domain knowledge\. The recent INTERACTCOMPDenget al\.\([2025](https://arxiv.org/html/2606.27669#bib.bib12)\)has begun to address search interaction, yet it remains limited in terms of task authenticity, the amplification effects of ambiguity within long\-chain reasoning, and the naturalness of interaction modalities\.

To bridge these gaps, we introduceDiscoBench\(DeepInteractiveSearch withClarificatiOn Benchmark\)111Our code and data will be publicly released soon\., a benchmark for evaluating whether search agents can proactively clarify and resolve ambiguity during multi\-step search\. Unlike prior benchmarks that mainly focus on static query understanding,DiscoBenchmodels ambiguity as a dynamic phenomenon arising during multi\-step search trajectories\. At each ambiguous checkpoint, agents must proactively identify underspecified information and interact with the user to obtain discriminative clues, rather than relying on direct guessing or closed\-form option selection strategies\.

We conduct experiments onDiscoBenchacross a set of representative LLMs\. The results show that current search agents still struggle to determine when clarification is needed: even stronger models often fail to recognize ambiguity during the search process or ask effective clarification questions\. This suggests that deep interactive search requires not only stronger retrieval and reasoning abilities, but also better ambiguity awareness and proactive clarification strategies\. Our main contributions are as follows:

- •We constructDiscoBench, a benchmark that models ambiguity as a dynamic phenomenon propagating along multi\-step reasoning chains rather than a static property of individual queries, covering 211 samples with 463 ambiguity instances across 11 real\-world domains and four ambiguity types\.
- •We propose an ambiguity\-aware evaluation framework for multi\-turn interactive deep search, together with a user simulator that progressively reveals discriminative clues, enabling unified evaluation of ambiguity detection, clarification effectiveness, and interaction cost\.
- •Through extensive experiments, we reveal that ambiguity detection and effective clarification are distinct capabilities\. We further identify a dominant failure mode in which models repeatedly continue searching instead of asking for clarification, leading to lower success rates than direct guessing\. This finding highlights the need for mechanisms that explicitly bridge retrieval uncertainty and user interaction\.

![Refer to caption](https://arxiv.org/html/2606.27669v1/x2.png)Figure 2:Overview of the proposed interactive retrieval framework and evaluation protocol\.
## 2Related Work

### 2\.1Web Search Benchmark

Efforts to benchmark search agents often bifurcate into two dimensions\. One branch focuses on reasoning depth, challenging agents to navigate complex web hierarchies for multi\-hop tasks, such as GAIAMialonet al\.\([2023](https://arxiv.org/html/2606.27669#bib.bib3)\)and the BrowseComp seriesWeiet al\.\([2025](https://arxiv.org/html/2606.27669#bib.bib2)\); Zhouet al\.\([2025a](https://arxiv.org/html/2606.27669#bib.bib13)\); Chenet al\.\([2025](https://arxiv.org/html/2606.27669#bib.bib14)\)\. In parallel, other benchmarks explore information width, necessitating the synthesis of vast horizontal data, as seen in PaSaHeet al\.\([2025](https://arxiv.org/html/2606.27669#bib.bib15)\), SPARShiet al\.\([2025](https://arxiv.org/html/2606.27669#bib.bib16)\), and WideSearchWonget al\.\([2025](https://arxiv.org/html/2606.27669#bib.bib4)\)\. Complementary agent benchmarks like WebArenaZhouet al\.\([2024](https://arxiv.org/html/2606.27669#bib.bib26)\), VisualWebArenaKohet al\.\([2024](https://arxiv.org/html/2606.27669#bib.bib33)\), Mind2WebDenget al\.\([2023](https://arxiv.org/html/2606.27669#bib.bib34)\), and WebShopYaoet al\.\([2022](https://arxiv.org/html/2606.27669#bib.bib35)\)further evaluate web navigation capabilities in realistic environments\. Recent work, such as DeepWideSearchLanet al\.\([2025](https://arxiv.org/html/2606.27669#bib.bib17)\), has further begun to encompass both dimensions\. Constrained by the assumption of complete queries, these benchmarks leave query ambiguity unexplored, which remains an essential aspect of autonomous search\.

### 2\.2Ambiguity Benchmark

Research on query ambiguity has evolved into several taxonomies\. Semantic and structural ambiguity benchmarks represented by AmbiEntLiuet al\.\([2023](https://arxiv.org/html/2606.27669#bib.bib18)\)investigate logical divergences arising from linguistic properties\. In the realm of multi\-answer factual ambiguity, datasets such as AmbigQAMinet al\.\([2020](https://arxiv.org/html/2606.27669#bib.bib8)\)and ASQAStelmakhet al\.\([2022](https://arxiv.org/html/2606.27669#bib.bib19)\)focus on mapping single queries to multiple concurrent valid facts\. Furthermore, conditional and contextual ambiguity benchmarks including TempAmbigQAPiryaniet al\.\([2024](https://arxiv.org/html/2606.27669#bib.bib21)\), CondAmbigQALiet al\.\([2025](https://arxiv.org/html/2606.27669#bib.bib20)\)and SituatedQAZhang and Choi \([2021](https://arxiv.org/html/2606.27669#bib.bib36)\)address scenarios where answers depend on latent temporal or geographical backgrounds that remain unstated in the initial query\. While valuable, these benchmarks rely on a static evaluation paradigm that prioritizes answer identification over the dynamic, interactive process required for agent\-user collaboration to resolve uncertainty\.

### 2\.3Interactive Clarification Benchmark

Interactive benchmarks evaluate agent performance in multi\-turn collaborative environments\. For instance, ColBenchZhouet al\.\([2025b](https://arxiv.org/html/2606.27669#bib.bib22)\)and UserBenchQianet al\.\([2025](https://arxiv.org/html/2606.27669#bib.bib11)\)target code generation and travel planning, respectively, while IN3Qianet al\.\([2024](https://arxiv.org/html/2606.27669#bib.bib10)\)and GAIA2Frogeret al\.\([2026](https://arxiv.org/html/2606.27669#bib.bib25)\)investigate implicit intent understanding and conflicting requests in local environments\. In conversational QA, Abg\-CoQAGuoet al\.\([2021](https://arxiv.org/html/2606.27669#bib.bib23)\)requires agents to clarify coreference or semantic vagueness\. Although IDRbenchFenget al\.\([2026](https://arxiv.org/html/2606.27669#bib.bib24)\)recently introduced interactive clarification into deep research, it is not designed for open\-domain web search scenarios\. Most closely related, InteractCompDenget al\.\([2025](https://arxiv.org/html/2606.27669#bib.bib12)\)pioneers the evaluation of interactive disambiguation for search agents\. However, it still contains scenarios that rely more on internal knowledge than external retrieval and mainly focuses on initial entity ambiguity rather than cascading errors in deep reasoning\. Moreover, its binary feedback setting cannot fully capture the descriptive nature of real user interactions\.

## 3Task Formulation

We formulate multi\-turn interactive retrieval as a sequential question\-answering task in which an agent resolves a complex questionqqthrough a series of structured checkpoints\(C​PCP\), with the ability to interact with a user when ambiguity is encountered\. As illustrated in Fig\.[2](https://arxiv.org/html/2606.27669#S1.F2), the agent must determine whether the current retrieval state is ambiguous and decide whether to continue retrieval or request clarification from the user\.

#### Question and Checkpoints\.

Each questionqqis decomposed into an ordered sequence ofnncheckpoints\{C​P1,C​P2,…,C​Pn\}\\\{CP\_\{1\},CP\_\{2\},\\ldots,CP\_\{n\}\\\}, each representing an intermediate retrieval sub\-goal\. A checkpointC​PiCP\_\{i\}is assigned one of two types:

- •Unambi: an unambiguous checkpoint where the agent can answer directly via retrieval\.
- •Ambi: an ambiguous checkpoint containing one of four injected ambiguity types, which causes retrieval to return multiple candidates or no valid result\.

#### Agent Actions and User Interaction\.

At each checkpointC​PiCP\_\{i\}, the agent may execute one of three actions:

ai∈\{Search,Ask,Answer\}a\_\{i\}\\in\\\{\\textsc\{Search\},\\ \\textsc\{Ask\},\\ \\textsc\{Answer\}\\\}\(1\)For unambiguous checkpoints, the agent directly issuesSearch​\(qi\)\\textsc\{Search\}\(q\_\{i\}\)and proceeds withAnswer​\(ri\)\\textsc\{Answer\}\(r\_\{i\}\)\. For an ambiguous checkpointC​PkCP\_\{k\}, the agent should invokeAsk​\(⋅\)\\textsc\{Ask\}\(\\cdot\)to request supplementary information, upon which the user releases a pre\-defined cluecc\. The agent then refines its search and resolves the ambiguity before issuingAnswer​\(r∗\)\\textsc\{Answer\}\(r^\{\*\}\)\.

#### Evaluation\.

We evaluate the agent from four aspects: task utility, ambiguity detection, interaction strategy, and cost efficiency\.

## 4Methodology of Dataset Construction

![Refer to caption](https://arxiv.org/html/2606.27669v1/x3.png)Figure 3:Overview of the two\-phase dataset construction pipeline, including seed multi\-hop QA construction, ambiguity injection, discriminative fact generation, and quality control\.We constructDiscoBench, an interactive ambiguous question answering \(QA\) benchmark designed to evaluate whether LLMs can identify ambiguity, proactively request clarification, and recover correct reasoning trajectories in multi\-turn open\-domain search tasks\. As illustrated in Fig\.[3](https://arxiv.org/html/2606.27669#S4.F3), the construction pipeline consists of two phases: \(1\)Seed Data Preparation, which builds high\-quality multi\-hop reasoning chains, and \(2\)Ambiguous Data Construction, which injects ambiguity and generates discriminative facts for interactive disambiguation\. The entire pipeline adopts a semi\-automatic collaborative framework\.

### 4\.1Seed Data Preparation

The goal of Phase 1 is to construct high\-quality multi\-hop seed questions that serve as the foundation for subsequent ambiguity injection\.

#### Topic & Seed Collection\.

We first manually collect seed topics from 11 diverse knowledge domains to ensure broad domain coverage and knowledge diversity\. In terms of knowledge sources, we utilize encyclopedic resources \(e\.g\., Wikipedia and Baidu Baike\) together with search engine result pages from search engines \(e\.g\., Google, Bing, and Baidu\)\.DiscoBenchis primarily constructed in Chinese to better reflect realistic ambiguity patterns and retrieval behaviors in Chinese web environments\. To ensure realistic retrieval requirements, all questions are required to satisfy the following conditions: \(1\) the answer must be objectively verifiable; \(2\) the question cannot be solved purely through common sense reasoning; and \(3\) external retrieval is necessary for task completion\.

#### Multi\-hop QA Construction\.

Inspired by existing multi\-hop QA datasetsHoet al\.\([2020](https://arxiv.org/html/2606.27669#bib.bib37)\); Trivediet al\.\([2022](https://arxiv.org/html/2606.27669#bib.bib31)\), we adopt a collaborative framework that combines LLM\-based preliminary expansion with human verification and reconstruction\. Specifically, the LLM first generates preliminary single\-hop factual QA pairs based on manually collected seed topics, and further performs graph\-structured expansion with external retrieval results to construct candidate multi\-hop reasoning chains\. After automatic generation, human annotators further review and reconstruct the reasoning chains\. Finally, each Seed QA sample is organized into a structured multi\-hop instance, serving as the foundation for subsequent ambiguity construction\.

### 4\.2Ambiguous Data Construction

Phase 2 aims to inject ambiguity into existing multi\-hop reasoning chains, transforming deterministic QA tasks into interactive reasoning tasks that require clarification\.

#### Ambiguity Point Identification\.

Given a deterministic multi\-hop reasoning chain, we identify hops where ambiguity can be naturally introduced\. Instead of injecting ambiguity randomly, we focus on nodes whose target entity has similar alternatives, such that relaxing the distinguishing constraint leads to multiple plausible candidates\. A node is retained as a candidate ambiguity point if: \(1\) its target entity shares attributes with sibling entities; \(2\) the downstream reasoning chain remains executable under underspecification; and \(3\) the ambiguity can be resolved with a single user\-provided clue\. All candidate positions are further verified manually\.

#### Ambiguity Construction\.

After identifying ambiguity points, we inject ambiguity into the original reasoning chain by replacing strong constraints with shared attributes among multiple candidate entities\. Specifically, the system retrieves candidate entities satisfying the current reasoning constraints and uses LLMs to identify shared characteristics, such as common authors, temporal ranges, or organizational relations\. The original question is then rewritten using these shared features, allowing multiple candidates to satisfy the same description\. Human annotators further verify the naturalness, solvability, and logical consistency of the constructed ambiguous questions\.

#### Discriminative Facts Generation\.

To support interactive disambiguation, we construct discriminative facts for each ambiguity point, which simulate supplementary clues provided by users and distinguish the target entity from distractors\. Candidate facts are generated by retrieval\-augmented LLMs from perspectives such as entity attributes, temporal information, relations, numerical facts, version differences, and organizational associations, and are then manually verified for factual correctness, distinguishability, and naturalness\.

### 4\.3Data Statistics and Quality Control

Tab\.[1](https://arxiv.org/html/2606.27669#S4.T1)presents the overall statistics ofDiscoBench, including domain distribution, task difficulty, and ambiguity types\. Task difficulty is determined by the number of ambiguity checkpoints, where easy, medium, and hard correspond to 1, 2, and 3 ambiguity points, respectively\.DiscoBenchcovers four ambiguity types:Entity\(multiple entities satisfy the same description\),Version\(different temporal or version\-specific states\),Criteria\(different evaluation standards or ranking criteria\), andFactual Inaccuracy\(descriptions inconsistent with objective facts\)\.

DiscoBenchconstruction process involved an expert annotation instructor, six undergraduate annotators, and two quality inspectors\. Annotators are recruited from diverse academic backgrounds in multiple disciplines to ensure annotation diversity and broad domain coverage\. During the construction process, all samples were further reviewed for factual correctness, retrieval feasibility, logical consistency, and ambiguity solvability\.

Table 1:Data statistics ofDiscoBench\(211 samples, 463 ambiguity instances\)\.

## 5Experiments

### 5\.1Experimental Setup

Table 2:Main results onDiscoBenchunder Neutral/Guided prompting\. Acc\.: end\-to\-end accuracy; CP: checkpoint pass rate; Det\.: ambiguity detection; CE: clarification evaluation; Ask: average clarification turns\. Darker blue indicates stronger neutral\-prompt performance\.†GPT\-5\.4 failed on 37 neutral\-prompt questions due to usage\-policy filtering; guided results are omitted due to only 62 valid runs, so this model is excluded from subsequent analysis\.

#### Models and Tools\.

We evaluate Claude\-Opus\-4\.7, GPT\-5\.4, Gemini\-3\.1\-Pro\-Preview, Doubao\-Seed\-2\.0\-Pro\-High, DeepSeek\-V4\-Pro, Qwen\-3\.6\-Max, MiniMax\-M2\.7, GLM\-5\.1, MiMo\-v2\.5\-Pro, Kimi\-K2\.6, and Hunyuan\-3\.0\-Preview under the same interactive retrieval framework and checkpoint\-level evaluator\. For models supporting configurable reasoning effort, we use the maximum available reasoning\-effort setting in the main experiments\. AllSearchcalls are implemented using TavilyTavily Inc\. \([2026](https://arxiv.org/html/2606.27669#bib.bib38)\)as the backend search engine\. We use Gemini\-3\-Flash\-Medium as the simulated user model for multi\-turn interaction and ambiguity clarification during evaluation\.

#### Prompting Settings\.

We consider two prompting settings\. In the Neutral setting, the agent receives no explicit instruction that ambiguity may exist and must independently decide whether clarification is needed\. This setting evaluates the model’s spontaneous ambiguity detection and proactive interaction ability\. In the Guided setting, the prompt explicitly reminds the agent to be aware of potential ambiguity and to ask clarification questions when necessary, which provides an ambiguity\-aware condition and reflects the model’s upper\-bound performance when it is encouraged to interact\.

#### Metrics\.

We report metrics from four aspects\. For task utility, we use end\-to\-end accuracy and checkpoint pass rate\. For ambiguity detection, we report detection accuracy and detection F1\. For interaction quality, we report the accuracy of the clarification question \(CE\-A\) and the clarification\-to\-advance rate \(CE\-B\)\. For cost efficiency, we report average ask turns, tool\-use turns, and token consumption\. Detailed definitions of all metrics and additional analysis of token consumption are provided in Appendix[B](https://arxiv.org/html/2606.27669#A2)and Appendix[G](https://arxiv.org/html/2606.27669#A7)\.

### 5\.2Main Results

#### Frontier models still struggle with clarification\-aware deep search\.

As shown in Tab\.[2](https://arxiv.org/html/2606.27669#S5.T2), current frontier models still show limited performance onDiscoBench\. Under the Neutral setting, the best\-performing model, Doubao\-Seed\-2\.0\-Pro, achieves only 43\.1% end\-to\-end accuracy, while Gemini\-3\.1\-Pro reaches 40\.8%\. Most other models remain below 40%, and weaker models such as MiniMax\-M2\.7 and Qwen3\.6\-Max achieve only 16\.1% and 12\.3%, respectively\. At the same time, there is still a substantial gap between the pass rate of the checkpoint and end\-to\-end accuracy\. For example, Claude\-Opus\-4\.7 achieves a checkpoint pass rate of 57\.0% but only 39\.8% accuracy\. This suggests that models may solve several intermediate retrieval steps while still failing to complete the full reasoning trajectory due to unresolved ambiguity\. Therefore, deep search for clarity requires not only retrieval and reasoning ability, but also stable ambiguity recognition and interaction planning throughout the reasoning process\.

#### Guided prompting improves performance but still reveals limited clarification ability\.

Guided prompting generally improves model performance by explicitly encouraging the agent to identify ambiguity and ask clarification questions when necessary\. Averaged over the 10 models with valid results under both settings, end\-to\-end accuracy increases from 28\.6% to 33\.7%, checkpoint pass rate rises from 50\.1% to 57\.6%, and detection F1 improves substantially from 45\.3% to 64\.9%\. The improvement is mainly reflected in ambiguity detection rather than downstream reasoning, suggesting that Guided prompting primarily helps reduce missed ambiguity cases\. However, additional interaction does not always translate into better end\-to\-end performance\. For example, Claude\-Opus\-4\.7 achieves a higher checkpoint pass rate under Guided prompting while slightly decreasing in final accuracy, indicating that stronger local interaction behavior may still fail to recover the complete reasoning trajectory\. Overall, prompt engineering can partially activate ambiguity\-aware behavior, but current models still lack robust and stable clarification ability\. Additional analysis by reasoning effort is provided in Appendix[C](https://arxiv.org/html/2606.27669#A3), showing that higher reasoning effort improves performance\.

102030405101520253035Tool Use: average tool calls per questionAccuracy \(%\)ModelGemini\-3\.1\-Pro\-PreviewClaude\-Opus\-4\.7Doubao\-Seed\-2\.0\-ProKimi\-K2\.6GLM\-5\.1Xiaomi\-MiMo\-V2\.5\-ProHunyuan\-3\.0\-PreviewMiniMax\-M2\.7DeepSeek\-V4\-ProQwen3\.6\-MaxFigure 4:Performance–efficiency trade\-off under neutral prompting\.
#### Knowing when to ask and asking effectively are distinct capabilities\.

Detection and clarification metrics capture different aspects of proactive interaction: recognizing when clarification is needed and asking questions that effectively resolve ambiguity\. These abilities are not always aligned\. Qwen3\.6\-Max has only 16\.0% detection F1 and asks just 0\.07 questions per task under the Neutral setting, but achieves 94\.7% CE\-A and 89\.5% CE\-B, indicating strong conditional question quality but weak proactive clarification\. By contrast, MiniMax\-M2\.7 asks more often, with 0\.61/1\.10 asks under Neutral/Guided settings, yet its CE\-B remains lower at 60\.7%/66\.5%\. Thus, successful clarification\-aware search requires both ambiguity detection and effective question asking\.

#### More tool use does not necessarily lead to better performance\.

Fig\.[4](https://arxiv.org/html/2606.27669#S5.F4)further reveals that higher retrieval intensity does not consistently translate into better task performance\. Increasing search tool calls alone cannot reliably improve accuracy\. For example, Claude\-Opus\-4\.7 exhibits relatively high tool\-use frequency among evaluated models, yet its accuracy still remains below Gemini\-3\.1\-Pro and Doubao\-Seed\-2\.0\-Pro\. Meanwhile, several models also perform frequent retrieval actions while still achieving poor end\-to\-end performance\. These observations suggest thatDiscoBenchdoes not reward excessive or inefficient retrieval behavior\. Successful clarification\-aware deep search depends not on searching more, but on whether models can strategically allocate retrieval actions, identify ambiguity at the correct checkpoints, and effectively utilize retrieved evidence and user\-provided clues to recover the reasoning trajectory\.

### 5\.3Performance by Ambiguity Types

![Refer to caption](https://arxiv.org/html/2606.27669v1/figures/ambiguity_detection_rate.png)Figure 5:Detection performance across different ambiguity types\.Fig\.[5](https://arxiv.org/html/2606.27669#S5.F5)shows that models exhibit clear differences in detection performance across ambiguity types\. Stronger models, such as Gemini\-3\.1\-Pro and Doubao\-Seed\-2\.0\-Pro, generally achieve more balanced performance, while mid\-performing models, such as DeepSeek\-V4\-Pro and Claude\-Opus\-4\.7, show a more type\-dependent pattern\. In particular,Factual Inaccuracyis often easier to detect, likely because factual errors tend to create explicit conflicts with retrieved evidence, helping models recognize that the current question cannot be directly resolved\. In contrast,EntityandCriteriaambiguities are more challenging because they usually do not create explicit factual conflicts\. Instead, they require models to distinguish among multiple plausible entities or identify missing decision criteria, making models more likely to follow one plausible path prematurely\. This suggests that current search agents still struggle with ambiguities that require active clarification rather than direct fact checking\. Additional analysis by ambiguity complexity is provided in Appendix[D](https://arxiv.org/html/2606.27669#A4)\.

### 5\.4Behavioral Profile Analysis

Table 3:Pass rate by behavioral profile on the common subset \(N=146N=146ambi\-CPs\)\.DG denotes DirectGuess; SHG denotes SearchHeavyGuess; STA denotes SearchThenAsk;∗denotesN<30N<30\.

To better understand the behavioral differences behind model performance, we categorize ambiguous\-checkpoint trajectories into four interaction profiles based on the ordering ofSearchandAskactions: DirectGuess, SearchHeavyGuess, DirectAsk, and SearchThenAsk\. Detailed definitions and profile distributions are provided in Appendix[E](https://arxiv.org/html/2606.27669#A5)\.

#### Clarification substantially improves success rates\.

As shown in Tab\.[3](https://arxiv.org/html/2606.27669#S5.T3), SearchThenAsk consistently achieves the highest pass rate across all evaluated models, reaching an average of 93\.4%, substantially outperforming DirectGuess \(56\.5%\) and SearchHeavyGuess \(51\.9%\)\. The gap remains stable within every model, indicating that proactive clarification is critical for successful ambiguity resolution in deep search\.

#### Search\-heavy guessing reveals a major failure mode\.

Notably, SearchHeavyGuess even underperforms DirectGuess despite performing more retrieval steps\. Repeated retrieval often indicates that the model is already aware of multiple candidate entities\. Therefore, these failures arise not from completely missing ambiguity, but from failing to escalate retrieval uncertainty into clarification\. This finding further explains why increased tool use alone does not reliably improve performance\.

### 5\.5Ablation Study

#### Effect of Search Tool\.

Tab\.[4](https://arxiv.org/html/2606.27669#S5.T4)shows that the external search tool is crucial forDiscoBench\. After removing the search tool, all models suffer substantial accuracy drops\. For example, Doubao\-Seed\-2\.0\-Pro decreases from 43\.1% to 2\.4%, with a drop of 40\.7 points; Gemini\-3\.1\-Pro and DeepSeek\-V4\-Pro also drop by 20\.9 and 25\.7 points, respectively\. This indicates thatDiscoBenchcannot be solved by relying solely on parametric knowledge\. Models need external retrieval to gather evidence, verify intermediate constraints, and continuously revise the search trajectory\.

#### Effect of Ambiguity\.

The comparison with unambiguous questions further shows that ambiguity is a major source of task difficulty\. After removing ambiguity, all models achieve significantly higher accuracy, with improvements ranging from 26\.8% to 40\.2%\. This suggests that current search agents are better at answering well\-specified questions, but still easily fail when facing ambiguous ones\.

Table 4:Ablation results under neutral prompting\. Full denotes the originalDiscoBenchaccuracy from the main setting\.

## 6Conclusion

We introducedDiscoBench, a benchmark for evaluating clarification\-aware deep search\.DiscoBenchmodels ambiguity as a dynamic issue that emerges during multi\-step search and uses structured checkpoints to evaluate whether search agents can detect ambiguity, ask for clarification, and recover correct reasoning paths with user\-provided clues\. Experiments show that current LLM\-based search agents still struggle with interactive deep search\. Guided prompting improves ambiguity detection, but end\-to\-end performance remains limited\. Meanwhile, proactive clarification is substantially more effective than repeated search or direct guessing\. These findings suggest that future search agents need not only stronger retrieval and reasoning abilities, but also better ambiguity awareness and interaction planning\.

## Limitations

DiscoBenchprimarily focuses on four representative ambiguity types grounded in objective question answering scenarios\. More complex forms of ambiguity, such as subjective preference ambiguity, remain underexplored and are left for future work\. In addition, althoughDiscoBenchemploys an ambiguity\-aware multi\-turn user simulator with progressive clue disclosure, the interaction behavior is still generated by LLMs rather than real human users\. As a result, the current simulator may not fully capture the diversity, noisiness, and unpredictability of real\-world clarification interactions\.

## Ethical Considerations

DiscoBenchis constructed from publicly available web resources, including encyclopedic websites and search engine result pages, and does not involve private or personally identifiable information\. The benchmark is designed solely for research purposes to evaluate ambiguity handling and clarification abilities in search agents\. Although the user simulator is LLM\-based rather than collected from real users, we acknowledge that simulated interactions may not fully reflect the diversity of real\-world human behavior\.

## References

- Asking clarifying questions in open\-domain information\-seeking conversations\.InProceedings of the 42nd international acm sigir conference on research and development in information retrieval,pp\. 475–484\.Cited by:[§1](https://arxiv.org/html/2606.27669#S1.p2.1)\.
- Z\. Chen, X\. Ma, S\. Zhuang, P\. Nie, K\. Zou, A\. Liu, J\. Green, K\. Patel, R\. Meng, M\. Su,et al\.\(2025\)Browsecomp\-plus: a more fair and transparent evaluation benchmark of deep\-research agent\.arXiv preprint arXiv:2508\.06600\.Cited by:[§2\.1](https://arxiv.org/html/2606.27669#S2.SS1.p1.1)\.
- M\. Deng, L\. Huang, Y\. Fan, J\. Zhang, F\. Ren, J\. Bai, F\. Yang, D\. Miao, Z\. Yu, Y\. Wu,et al\.\(2025\)Interactcomp: evaluating search agents with ambiguous queries\.arXiv preprint arXiv:2510\.24668\.Cited by:[§1](https://arxiv.org/html/2606.27669#S1.p3.1),[§2\.3](https://arxiv.org/html/2606.27669#S2.SS3.p1.1)\.
- X\. Deng, Y\. Gu, B\. Zheng, S\. Chen, S\. Stevens, B\. Wang, H\. Sun, and Y\. Su \(2023\)Mind2web: towards a generalist agent for the web\.Advances in Neural Information Processing Systems36,pp\. 28091–28114\.Cited by:[§2\.1](https://arxiv.org/html/2606.27669#S2.SS1.p1.1)\.
- Y\. Feng, Q\. Huang, X\. Xie, Z\. Yang, J\. Yu, W\. Chen, and A\. K\. Tung \(2026\)IDRBench: interactive deep research benchmark\.arXiv preprint arXiv:2601\.06676\.Cited by:[§2\.3](https://arxiv.org/html/2606.27669#S2.SS3.p1.1)\.
- R\. Froger, P\. Andrews, M\. Bettini, A\. Budhiraja, R\. S\. Cabral, V\. Do, E\. Garreau, J\. Gaya, H\. Laurençon, M\. Lecanu,et al\.\(2026\)Gaia2: benchmarking llm agents on dynamic and asynchronous environments\.arXiv preprint arXiv:2602\.11964\.Cited by:[§2\.3](https://arxiv.org/html/2606.27669#S2.SS3.p1.1)\.
- Google \(2025\)Gemini deep research\.Note:[https://gemini\.google/overview/deep\-research/](https://gemini.google/overview/deep-research/)Accessed: 2026\-04\-13Cited by:[§1](https://arxiv.org/html/2606.27669#S1.p1.1)\.
- M\. Guo, M\. Zhang, S\. Reddy, and M\. Alikhani \(2021\)Abg\-coqa: clarifying ambiguity in conversational question answering\.In3rd Conference on Automated Knowledge Base Construction,Cited by:[§2\.3](https://arxiv.org/html/2606.27669#S2.SS3.p1.1)\.
- Y\. He, G\. Huang, P\. Feng, Y\. Lin, Y\. Zhang, H\. Li,et al\.\(2025\)Pasa: an llm agent for comprehensive academic paper search\.InProceedings of the 63rd Annual Meeting of the Association for Computational Linguistics \(Volume 1: Long Papers\),pp\. 11663–11679\.Cited by:[§2\.1](https://arxiv.org/html/2606.27669#S2.SS1.p1.1)\.
- X\. Ho, A\. D\. Nguyen, S\. Sugawara, and A\. Aizawa \(2020\)Constructing a multi\-hop qa dataset for comprehensive evaluation of reasoning steps\.InProceedings of the 28th International Conference on Computational Linguistics,pp\. 6609–6625\.Cited by:[§4\.1](https://arxiv.org/html/2606.27669#S4.SS1.SSS0.Px2.p1.1)\.
- J\. Ji, M\. Li, P\. Kumar, S\. Chang, and S\. Potdar \(2025\)DEEPAMBIGQA: ambiguous multi\-hop questions for benchmarking llm answer completeness\.arXiv preprint arXiv:2511\.01323\.Cited by:[§1](https://arxiv.org/html/2606.27669#S1.p3.1)\.
- J\. Y\. Koh, R\. Lo, L\. Jang, V\. Duvvur, M\. Lim, P\. Huang, G\. Neubig, S\. Zhou, R\. Salakhutdinov, and D\. Fried \(2024\)Visualwebarena: evaluating multimodal agents on realistic visual web tasks\.InProceedings of the 62nd Annual Meeting of the Association for Computational Linguistics \(Volume 1: Long Papers\),pp\. 881–905\.Cited by:[§2\.1](https://arxiv.org/html/2606.27669#S2.SS1.p1.1)\.
- T\. Kwiatkowski, J\. Palomaki, O\. Redfield, M\. Collins, A\. Parikh, C\. Alberti, D\. Epstein, I\. Polosukhin, J\. Devlin, K\. Lee,et al\.\(2019\)Natural questions: a benchmark for question answering research\.Transactions of the Association for Computational Linguistics7,pp\. 453–466\.Cited by:[§1](https://arxiv.org/html/2606.27669#S1.p2.1)\.
- T\. Lan, B\. Zhu, Q\. Jia, J\. Ren, H\. Li, L\. Wang, Z\. Xu, W\. Luo, and K\. Zhang \(2025\)Deepwidesearch: benchmarking depth and width in agentic information seeking\.arXiv preprint arXiv:2510\.20168\.Cited by:[§2\.1](https://arxiv.org/html/2606.27669#S2.SS1.p1.1)\.
- Z\. Li, Y\. Li, H\. Xie, and S\. J\. Qin \(2025\)Condambigqa: a benchmark and dataset for conditional ambiguous question answering\.InProceedings of the 2025 Conference on Empirical Methods in Natural Language Processing,pp\. 2269–2288\.Cited by:[§2\.2](https://arxiv.org/html/2606.27669#S2.SS2.p1.1)\.
- A\. Liu, Z\. Wu, J\. Michael, A\. Suhr, P\. West, A\. Koller, S\. Swayamdipta, N\. A\. Smith, and Y\. Choi \(2023\)We’re afraid language models aren’t modeling ambiguity\.InProceedings of the 2023 conference on empirical methods in natural language processing,pp\. 790–807\.Cited by:[§2\.2](https://arxiv.org/html/2606.27669#S2.SS2.p1.1)\.
- X\. Liu, H\. Yu, H\. Zhang, Y\. Xu, X\. Lei, H\. Lai, Y\. Gu, H\. Ding, K\. Men, K\. Yang,et al\.\(2024\)Agentbench: evaluating llms as agents\.InInternational Conference on Learning Representations,Vol\.2024,pp\. 52989–53046\.Cited by:[§1](https://arxiv.org/html/2606.27669#S1.p3.1)\.
- G\. Mialon, C\. Fourrier, T\. Wolf, Y\. LeCun, and T\. Scialom \(2023\)Gaia: a benchmark for general ai assistants\.InThe Twelfth International Conference on Learning Representations,Cited by:[§1](https://arxiv.org/html/2606.27669#S1.p1.1),[§1](https://arxiv.org/html/2606.27669#S1.p3.1),[§2\.1](https://arxiv.org/html/2606.27669#S2.SS1.p1.1)\.
- S\. Min, J\. Michael, H\. Hajishirzi, and L\. Zettlemoyer \(2020\)AmbigQA: answering ambiguous open\-domain questions\.InProceedings of the 2020 conference on empirical methods in natural language processing \(EMNLP\),pp\. 5783–5797\.Cited by:[§1](https://arxiv.org/html/2606.27669#S1.p3.1),[§2\.2](https://arxiv.org/html/2606.27669#S2.SS2.p1.1)\.
- OpenAI \(2025\)Introducing deep research\.Note:[https://openai\.com/index/introducing\-deep\-research/](https://openai.com/index/introducing-deep-research/)Accessed: 2026\-04\-13Cited by:[§1](https://arxiv.org/html/2606.27669#S1.p1.1)\.
- B\. Piryani, A\. Abdallah, J\. Mozafari, and A\. Jatowt \(2024\)Detecting temporal ambiguity in questions\.InFindings of the Association for Computational Linguistics: EMNLP 2024,pp\. 9620–9634\.Cited by:[§2\.2](https://arxiv.org/html/2606.27669#S2.SS2.p1.1)\.
- C\. Qian, B\. He, Z\. Zhuang, J\. Deng, Y\. Qin, X\. Cong, Z\. Zhang, J\. Zhou, Y\. Lin, Z\. Liu,et al\.\(2024\)Tell me more\! towards implicit user intention understanding of language model driven agents\.InProceedings of the 62nd Annual Meeting of the Association for Computational Linguistics \(Volume 1: Long Papers\),pp\. 1088–1113\.Cited by:[§1](https://arxiv.org/html/2606.27669#S1.p3.1),[§2\.3](https://arxiv.org/html/2606.27669#S2.SS3.p1.1)\.
- C\. Qian, Z\. Liu, A\. Prabhakar, Z\. Liu, J\. Zhang, H\. Chen, H\. Ji, W\. Yao, S\. Heinecke, S\. Savarese,et al\.\(2025\)Userbench: an interactive gym environment for user\-centric agents\.arXiv preprint arXiv:2507\.22034\.Cited by:[§1](https://arxiv.org/html/2606.27669#S1.p3.1),[§2\.3](https://arxiv.org/html/2606.27669#S2.SS3.p1.1)\.
- X\. Shi, Y\. Li, Q\. Kou, L\. Yu, J\. Xie, and H\. Zhou \(2025\)Spar: scholar paper retrieval with llm\-based agents for enhanced academic search\.arXiv preprint arXiv:2507\.15245\.Cited by:[§2\.1](https://arxiv.org/html/2606.27669#S2.SS1.p1.1)\.
- I\. Stelmakh, Y\. Luan, B\. Dhingra, and M\. Chang \(2022\)ASQA: factoid questions meet long\-form answers\.InProceedings of the 2022 Conference on Empirical Methods in Natural Language Processing,pp\. 8273–8288\.Cited by:[§2\.2](https://arxiv.org/html/2606.27669#S2.SS2.p1.1)\.
- Tavily Inc\. \(2026\)Tavily docs\.Note:[https://docs\.tavily\.com/welcome](https://docs.tavily.com/welcome)Cited by:[Appendix H](https://arxiv.org/html/2606.27669#A8.p1.1),[§5\.1](https://arxiv.org/html/2606.27669#S5.SS1.SSS0.Px1.p1.1)\.
- H\. Trivedi, N\. Balasubramanian, T\. Khot, and A\. Sabharwal \(2022\)♫ MuSiQue: multihop questions via single\-hop question composition\.Transactions of the Association for Computational Linguistics10,pp\. 539–554\.Cited by:[§1](https://arxiv.org/html/2606.27669#S1.p2.1),[§4\.1](https://arxiv.org/html/2606.27669#S4.SS1.SSS0.Px2.p1.1)\.
- J\. Wei, Z\. Sun, S\. Papay, S\. McKinney, J\. Han, I\. Fulford, H\. W\. Chung, A\. T\. Passos, W\. Fedus, and A\. Glaese \(2025\)Browsecomp: a simple yet challenging benchmark for browsing agents\.arXiv preprint arXiv:2504\.12516\.Cited by:[§1](https://arxiv.org/html/2606.27669#S1.p1.1),[§1](https://arxiv.org/html/2606.27669#S1.p3.1),[§2\.1](https://arxiv.org/html/2606.27669#S2.SS1.p1.1)\.
- R\. Wong, J\. Wang, J\. Zhao, L\. Chen, Y\. Gao, L\. Zhang, X\. Zhou, Z\. Wang, K\. Xiang, G\. Zhang,et al\.\(2025\)Widesearch: benchmarking agentic broad info\-seeking\.arXiv preprint arXiv:2508\.07999\.Cited by:[§1](https://arxiv.org/html/2606.27669#S1.p1.1),[§2\.1](https://arxiv.org/html/2606.27669#S2.SS1.p1.1)\.
- J\. Wu, W\. Yin, Y\. Jiang, Z\. Wang, Z\. Xi, R\. Fang, L\. Zhang, Y\. He, D\. Zhou, P\. Xie,et al\.\(2025\)Webwalker: benchmarking llms in web traversal\.InProceedings of the 63rd Annual Meeting of the Association for Computational Linguistics \(Volume 1: Long Papers\),pp\. 10290–10305\.Cited by:[§1](https://arxiv.org/html/2606.27669#S1.p1.1)\.
- Y\. Xi, J\. Lin, Y\. Xiao, Z\. Zhou, R\. Shan, T\. Gao, J\. Zhu, W\. Liu, Y\. Yu, and W\. Zhang \(2025\)A survey of llm\-based deep search agents: paradigm, optimization, evaluation, and challenges\.arXiv preprint arXiv:2508\.05668\.Cited by:[§1](https://arxiv.org/html/2606.27669#S1.p1.1)\.
- S\. Yao, H\. Chen, J\. Yang, and K\. Narasimhan \(2022\)Webshop: towards scalable real\-world web interaction with grounded language agents\.Advances in Neural Information Processing Systems35,pp\. 20744–20757\.Cited by:[§2\.1](https://arxiv.org/html/2606.27669#S2.SS1.p1.1)\.
- H\. Zamani, B\. Mitra, E\. Chen, G\. Lueck, F\. Diaz, P\. N\. Bennett, N\. Craswell, and S\. T\. Dumais \(2020\)Analyzing and learning from user interactions for search clarification\.InProceedings of the 43rd international acm sigir conference on research and development in information retrieval,pp\. 1181–1190\.Cited by:[§1](https://arxiv.org/html/2606.27669#S1.p2.1)\.
- M\. Zhang and E\. Choi \(2021\)SituatedQA: incorporating extra\-linguistic contexts into qa\.InProceedings of the 2021 Conference on Empirical Methods in Natural Language Processing,pp\. 7371–7387\.Cited by:[§2\.2](https://arxiv.org/html/2606.27669#S2.SS2.p1.1)\.
- P\. Zhou, B\. Leon, X\. Ying, C\. Zhang, Y\. Shao, Q\. Ye, D\. Chong, Z\. Jin, C\. Xie, M\. Cao,et al\.\(2025a\)Browsecomp\-zh: benchmarking web browsing ability of large language models in chinese\.arXiv preprint arXiv:2504\.19314\.Cited by:[§2\.1](https://arxiv.org/html/2606.27669#S2.SS1.p1.1)\.
- S\. Zhou, F\. F\. Xu, H\. Zhu, X\. Zhou, R\. Lo, A\. Sridhar, X\. Cheng, T\. Ou, Y\. Bisk, D\. Fried,et al\.\(2024\)Webarena: a realistic web environment for building autonomous agents\.InInternational Conference on Learning Representations,Vol\.2024,pp\. 15585–15606\.Cited by:[§1](https://arxiv.org/html/2606.27669#S1.p1.1),[§2\.1](https://arxiv.org/html/2606.27669#S2.SS1.p1.1)\.
- Y\. Zhou, S\. Jiang, Y\. Tian, J\. Weston, S\. Levine, S\. Sukhbaatar, and X\. Li \(2025b\)Sweet\-rl: training multi\-turn llm agents on collaborative reasoning tasks\.arXiv preprint arXiv:2503\.15478\.Cited by:[§2\.3](https://arxiv.org/html/2606.27669#S2.SS3.p1.1)\.

## Appendix AAuthor Contributions

#### Benchmark Design and Methodology\.

Yiling Tao, Shihan Deng, Zhihao Zhu, and Pengzhi Wei jointly contributed to the design ofDiscoBench, and the overall methodology was integrated and proposed by Shihan Deng and Yiling Tao\.

#### Data Construction and Annotation\.

Shihan Deng led the construction of the multi\-hop seed data, while Yiling Tao led the ambiguity data construction pipeline\. Shihan Deng, Zhihao Zhu, Yiling Tao, and Pengzhi Wei were responsible for the critical quality control and final verification of the constructed data\.

#### Evaluation Framework and User Simulator\.

Yiling Tao and Shihan Deng jointly designed the framework, and Shihan Deng was primarily responsible for its code construction and implementation\.

#### Experiments and Analysis\.

Shihan Deng conducted the main experiments\. The result analysis was performed by Yiling Tao, Shihan Deng, and Zhihao Zhu\.

#### Paper Writing\.

Yiling Tao led the paper writing, and Meiling Tao produced all the figures and organized the key information\. Zhihao Zhu and Shihan Deng participated in revising the manuscript\.

#### Project Supervision\.

Zhichao Hu and Zhihao Zhu supervised the project and served as the corresponding authors\.

## Appendix BEvaluation Metrics

This section provides detailed definitions of the evaluation metrics used in our experiments\. All metrics are computed at the question level or checkpoint level and then averaged over all valid questions for each model\.

### B\.1End\-to\-End Accuracy

End\-to\-end accuracy evaluates whether the agent’s final answer to the full question matches the ground\-truth answer\. Equivalence between the two answers is determined by an LLM\-based answer\-equivalence judge, which abstracts away surface\-form variations such as transliterations, date formats, and list ordering\.

For each questionqq, leta^q\\hat\{a\}\_\{q\}denote the agent’s final answer andaq⋆a\_\{q\}^\{\\star\}the ground\-truth answer, and letequiv​\(a^q,aq⋆\)∈\{0,1\}\\mathrm\{equiv\}\(\\hat\{a\}\_\{q\},a\_\{q\}^\{\\star\}\)\\in\\\{0,1\\\}denote the judge’s binary verdict, where11indicates that the two answers are judged equivalent and0otherwise\. The per\-question correctness indicator is defined as:

Acc​\(q\)=equiv​\(a^q,aq⋆\)\.\\mathrm\{Acc\}\(q\)=\\mathrm\{equiv\}\\\!\\left\(\\hat\{a\}\_\{q\},\\,a\_\{q\}^\{\\star\}\\right\)\.\(2\)
The model\-level end\-to\-end accuracy is computed by averaging over all valid questions:

Acc=1\|Q\|​∑q∈QAcc​\(q\),\\mathrm\{Acc\}=\\frac\{1\}\{\|Q\|\}\\sum\_\{q\\in Q\}\\mathrm\{Acc\}\(q\),\(3\)whereQQdenotes the set of valid evaluated questions\. This question\-level normalization ensures that each question contributes equally to the final score\.

### B\.2Checkpoint Pass Rate

Each question inDiscoBenchis decomposed into a sequence of checkpoints\. A checkpoint is counted as successfully advanced if the agent either answers the checkpoint correctly and proceeds to the next checkpoint, or correctly completes the final checkpoint\. In our evaluator logs, this corresponds to one of two outcomes: \(1\)correct\_answer, where the agent correctly resolves a regular checkpoint; \(2\)missed\_ambiguity\_correct, where the agent misses the ambiguity at an ambiguous checkpoint but still happens to answer it correctly\.

For each questionqq, letNqN\_\{q\}denote the ground\-truth number of checkpoints, and letAqA\_\{q\}denote the number of checkpoints that are successfully advanced\. The checkpoint pass score for questionqqis defined as:

CP​\(q\)=AqNq\.\\text\{CP\}\(q\)=\\frac\{A\_\{q\}\}\{N\_\{q\}\}\.\(4\)
The model\-level checkpoint pass rate is computed by averaging over all valid questions:

CP=1\|𝒬\|​∑q∈𝒬CP​\(q\),\\text\{CP\}=\\frac\{1\}\{\|\\mathcal\{Q\}\|\}\\sum\_\{q\\in\\mathcal\{Q\}\}\\text\{CP\}\(q\),\(5\)where𝒬\\mathcal\{Q\}denotes the set of valid evaluated questions\. This question\-level normalization ensures that each question contributes equally to the final score, regardless of how many checkpoints it contains\.

### B\.3Ambiguity Detection Metrics

We evaluate ambiguity detection at the checkpoint level\. For each reached checkpoint, we compare the ground\-truth checkpoint type with the agent’s interaction behavior\. A checkpoint is labeled asAmbiif it contains an injected ambiguity, andNon\-Ambiotherwise\. We define the four detection outcomes as follows:

- •True Positive \(TP\): the checkpoint isAmbi, and the agent correctly asks a clarification question targeting the ambiguity\.
- •False Negative \(FN\): the checkpoint isAmbi, but the agent fails to ask or does not correctly target the ambiguity\.
- •False Positive \(FP\): the checkpoint isNon\-Ambi, but the agent unnecessarily asks for clarification\.
- •True Negative \(TN\): the checkpoint isNon\-Ambi, and the agent proceeds without asking for clarification\.

Accordingly,T​P\+F​NTP\+FNcorresponds to all reached ambiguous checkpoints, whileF​P\+T​NFP\+TNcorresponds to all reached non\-ambiguous checkpoints\. The total number of evaluated detection decisions isT​P\+T​N\+F​P\+F​NTP\+TN\+FP\+FN\.

#### Detection Accuracy\.

Detection accuracy measures the overall correctness of ambiguity detection decisions:

Detection Accuracy=T​P\+T​NT​P\+T​N\+F​P\+F​N\.\\text\{Detection Accuracy\}=\\frac\{TP\+TN\}\{TP\+TN\+FP\+FN\}\.\(6\)

#### Detection F1 Score\.

We further report detection F1 to better account for the imbalance between ambiguous and non\-ambiguous checkpoints\. Precision and recall are defined as:

P=T​PT​P\+F​P,R=T​PT​P\+F​N\.P=\\frac\{TP\}\{TP\+FP\},\\quad R=\\frac\{TP\}\{TP\+FN\}\.\(7\)
The detection F1 score is computed as:

Detection F1=2⋅P⋅RP\+R\.\\text\{Detection F1\}=\\frac\{2\\cdot P\\cdot R\}\{P\+R\}\.\(8\)
Here, recall measures the proportion of ambiguous checkpoints that are correctly detected, while precision measures how often the agent’s clarification decisions are correct\. F1 provides a more robust measure when ambiguous and non\-ambiguous checkpoints are unevenly distributed\.

### B\.4Clarification Effectiveness

Clarification effectiveness evaluates the quality and usefulness of the agent’s clarification behavior\. Both metrics share the same denominator: the number of checkpoints where the agent actively invokesAsk, regardless of whether the question is correct\.

Let𝒞\\mathcal\{C\}denote the set of evaluated checkpoints, and let𝒞asked\\mathcal\{C\}\_\{\\texttt\{asked\}\}denote the set of checkpoints where the agent invokesAsk:

𝒞asked=\{c∈𝒞:asked​\(c\)\}\.\\mathcal\{C\}\_\{\\texttt\{asked\}\}=\\\{c\\in\\mathcal\{C\}:\\texttt\{asked\}\(c\)\\\}\.\(9\)
We further define:

𝒞right=\{c∈𝒞asked:asked\_right​\(c\)\},\\mathcal\{C\}\_\{\\texttt\{right\}\}=\\\{c\\in\\mathcal\{C\}\_\{\\texttt\{asked\}\}:\\texttt\{asked\\\_right\}\(c\)\\\},\(10\)𝒞adv=\{c∈𝒞asked:cp\_advanced​\(c\)\}\.\\mathcal\{C\}\_\{\\texttt\{adv\}\}=\\\{c\\in\\mathcal\{C\}\_\{\\texttt\{asked\}\}:\\texttt\{cp\\\_advanced\}\(c\)\\\}\.\(11\)
#### CE\-A: Clarification Question Accuracy\.

CE\-A measures whether the agent asks the right clarification question when it decides to interact:

CE\-A=\|𝒞right\|\|𝒞asked\|\.\\text\{CE\-A\}=\\frac\{\\left\|\\mathcal\{C\}\_\{\\texttt\{right\}\}\\right\|\}\{\\left\|\\mathcal\{C\}\_\{\\texttt\{asked\}\}\\right\|\}\.\(12\)

#### CE\-B: Clarification\-to\-Advance Rate\.

CE\-B measures whether a correct clarification eventually helps the agent advance the current checkpoint:

CE\-B=\|𝒞right∩𝒞adv\|\|𝒞asked\|\.\\text\{CE\-B\}=\\frac\{\\left\|\\mathcal\{C\}\_\{\\texttt\{right\}\}\\cap\\mathcal\{C\}\_\{\\texttt\{adv\}\}\\right\|\}\{\\left\|\\mathcal\{C\}\_\{\\texttt\{asked\}\}\\right\|\}\.\(13\)
CE\-A reflects whether the agent asks in the correct direction, while CE\-B further evaluates whether the agent can use the returned clue to successfully advance the checkpoint\.

## Appendix CAdditional Analysis by Reasoning Effort

![Refer to caption](https://arxiv.org/html/2606.27669v1/x4.png)Figure 6:Reasoning\-effort comparison for Doubao\-Seed\-2\.0\-Pro under neutral prompting\.Fig\.[6](https://arxiv.org/html/2606.27669#A3.F6)shows that increasing reasoning effort leads to consistent overall improvements\. Taking Doubao\-Seed\-2\.0\-Pro as an example, when the reasoning effort is increased from medium to high, the average score rises from 45\.7% to 54\.0%, with an overall gain of 8\.3 points\. The improvements are particularly pronounced on ambiguity\-related metrics: Det\. F1 increases by 9\.0 points, and Ambi\. Rec\. improves from 37\.2% to 47\.3%, yielding a 10\.1\-point gain, which is larger than the improvement on CP\. This suggests that higher reasoning effort mainly helps models identify ambiguous search states, compare multiple candidate entities, and incorporate user clues into subsequent search refinement\.

This result is consistent with the characteristics ofDiscoBench\. Clarification\-aware deep search requires models not only to retrieve the final answer, but also to continuously judge whether the evidence is sufficient across multiple ambiguity checkpoints, while maintaining and revising the search trajectory\. However, even under the high\-effort setting, the accuracy remains below 45% and Ambi\. Rec\. remains below 50%, indicating that simply increasing reasoning effort is still insufficient for robust clarification\-aware behavior\. Models still need stronger mechanisms for ambiguity localization, evidence verification, and deciding when to ask rather than directly guess\.

## Appendix DAdditional Analysis by Ambiguity Complexity

![Refer to caption](https://arxiv.org/html/2606.27669v1/x5.png)Figure 7:Performance across ambiguity\-complexity levels under neutral prompting\.Fig\.[7](https://arxiv.org/html/2606.27669#A4.F7)presents model performance across different levels of complexity of ambiguity under neutral prompting\. Across nearly all evaluated models, accuracy consistently decreases from Easy to Hard, showing that ambiguity complexity introduces substantial additional difficulty beyond ordinary retrieval and reasoning\. Although stronger models such as Doubao\-Seed\-2\.0\-Pro \(High\), Gemini\-3\.1\-Pro, Claude\-Opus\-4\.7, and DeepSeek\-V4\-Pro achieve relatively strong performance on Easy examples, their accuracy still drops markedly on Hard examples\. This suggests that increasing ambiguity complexity challenges not only evidence retrieval, but also the model’s ability to recognize underspecified states and proactively request clarification during multi\-step search\.

The performance gap between Easy and Hard settings further indicates that stronger reasoning ability alone is insufficient for robust clarification\-aware search\. As ambiguity becomes more subtle and accumulates across multiple checkpoints, models are increasingly prone to following plausible but incorrect search trajectories without initiating clarification\. Lower\-performing models exhibit the same downward trend from a lower baseline, indicating simultaneous weaknesses in both basic task completion and ambiguity resolution\.

## Appendix EProfile Classification Details

#### Behavioral profiles\.

We classify ambiguous\-checkpoint trajectories into four profiles:

- •DirectGuess: noAskwith search count≤K\\leq K\.
- •SearchHeavyGuess: noAskwith search count\>K\>K\.
- •DirectAsk: ask before any retrieval\.
- •SearchThenAsk: retrieve before clarification\.

The thresholdK=3K\\\!=\\\!3is determined data\-driven as the median search count among successful no\-ask trajectories\.

#### DirectAsk rarity\.

DirectAsk is extremely rare, accounting for only0–77trajectories per model\. For 7 of 9 models, the count satisfiesN≤1N\\\!\\leq\\\!1, indicating that current models almost never initiate clarification before retrieval\.

#### Common Subset Robustness\.

The common subset contains 146 ambi\-CPs reached by all 9 models in Tab\.[3](https://arxiv.org/html/2606.27669#S5.T3)\. GPT\-5\.4 is excluded due to prompt filtering, while Qwen is excluded because of insufficient reach\. Model rankings on the common subset remain highly consistent with the full dataset \(Spearmanρ=0\.95\\rho\\\!=\\\!0\.95\), indicating that the observed behavioral patterns are robust to reach\-rate differences\.

Table 5:Behavioral profile distribution \(%\) on the common subset \(N=146N\\\!=\\\!146ambi\-CPs\)\. Models are sorted by STA ratio\.DG denotes DirectGuess; SHG denotes SearchHeavyGuess; DA denotes DirectAsk; STA denotes SearchThenAsk\.

## Appendix FEvaluated Models and API Configurations

Table 6:Evaluated models and reasoning configurations\.Reasoningshorthand:*xhigh / high / medium*– provider’s discrete reasoning\-effort or thinking\-level setting;*thinking*– thinking/reasoning mode enabled \(no effort granularity exposed\);*adapt\.*– adaptive thinking budget\.Model \(paper\)ProviderAPI IdentifierReasoningGPT\-5\.4OpenAIgpt\-5\.4\-2026\-03\-05xhighGemini\-3\.1\-Pro\-PreviewGooglegemini\-3\.1\-pro\-previewhighClaude\-Opus\-4\.7Anthropicclaude\-opus\-4\-7adapt\.; maxDoubao\-Seed\-2\.0\-Pro\-HighByteDancedoubao\-seed\-2\-0\-pro\-260215highDoubao\-Seed\-2\.0\-Pro\-MediumByteDancedoubao\-seed\-2\-0\-pro\-260215mediumDeepSeek\-V4\-ProDeepSeekdeepseek\-v4\-prothinking; maxQwen3\.6\-MaxAlibabaqwen3\.6\-max\-previewthinkingKimi\-K2\.6Moonshot AIkimi\-k2\.6thinkingMiMo\-v2\.5\-ProXiaomimimo\-v2\.5\-prothinkingHunyuan\-3\.0\-PreviewTencenthy3\-previewhighMiniMax\-M2\.7MiniMaxMiniMax\-M2\.7thinkingGLM\-5\.1†Zhipu AIz\-ai/glm\-5\.1thinkingUser simulator and checkpoint judgeGemini\-3\-Flash\-MediumGooglegemini\-3\-flash\-previewmedium

†GLM\-5\.1 is accessed via the OpenRouter gateway \(z\-ai/glm\-5\.1\) rather than a direct Zhipu AI endpoint\.

Tab\.[6](https://arxiv.org/html/2606.27669#A6.T6)lists the API configuration of every model used in our main experiments and ablation studies, restricted to the information needed to reproduce a call: the model name used in the paper, the provider, the API identifier used at invocation time, and the reasoning\- or thinking\-mode setting\. To control for the confound of reasoning budget, models exposing a configurable effort level are run at the highest available setting in the main experiments; Doubao\-Seed\-2\.0\-Pro\-Medium is additionally included only for the reasoning\-effort analysis in Appendix[C](https://arxiv.org/html/2606.27669#A3)\. Frontier proprietary models \(GPT\-5\.4, Gemini\-3\.1\-Pro\-Preview, and Claude\-Opus\-4\.7\) are restricted to a concurrency of55by provider\-side rate limits, whereas the remaining agent endpoints permit a concurrency of300300; this asymmetry influences wall\-clock evaluation cost but not per\-question correctness\. AllSearchcalls are executed through Tavily regardless of the agent backbone\. A single auxiliary model, Gemini\-3\-Flash\-Medium running with thinking level set tomedium, serves both as the simulated user that releases discriminative clues during clarification turns and as the checkpoint\-level judge that scores each step; its configuration is listed in the bottom block of Tab\.[6](https://arxiv.org/html/2606.27669#A6.T6)and uses a concurrency of100100\.

## Appendix GToken Consumption

To provide a supplementary reference for inference cost, we report the token consumption of the evaluated models in the main experiments and ablation studies\. Tab\.[7](https://arxiv.org/html/2606.27669#A7.T7)summarizes the total input and output tokens under the Neutral and Guided prompting settings\. The Guided entry of GPT\-5\.4 is left blank because its Guided runs were excluded from the main analysis due to insufficient valid results\. Doubao\-Seed\-2\.0\-Pro\-Medium is included only for the reasoning\-effort analysis under the Neutral setting, and therefore does not have a corresponding Guided entry\.

Tab\.[8](https://arxiv.org/html/2606.27669#A7.T8)further reports token consumption for the two ablation settings used in the main text: removing the search tool and evaluating on unambiguous questions\. These ablation runs are conducted under neutral prompting and are reported separately from the main Neutral/Guided comparison\.

Table 7:Token consumption of evaluated models under the Neutral and Guided prompting settings\.
Table 8:Token consumption in the ablation studies under neutral prompting\.
## Appendix HReproducibility under a Black\-Box Search Backend

AllSearchcalls inDiscoBenchare routed through TavilyTavily Inc\. \([2026](https://arxiv.org/html/2606.27669#bib.bib38)\), a hosted web\-search API whose index, ranking model, and freshness policies are not publicly disclosed\. From the agent’s point of view the backend therefore behaves as a black box: the same query issued on different days can return different snippet sets, different rankings, and even different source domains, both because the web itself is non\-stationary \(pages appear, are edited, or are de\-indexed\) and because Tavily’s own retrieval and re\-ranking stack can be updated without notice\. Strict bit\-exact reproducibility of an end\-to\-end trajectory is therefore not achievable\.

#### Solvability of individual instances\.

This stochasticity does not, however, undermine the solvability of individual questions, because the gold answer inDiscoBenchis by construction time\-invariant\. Every question is built on stable, verifiable factual knowledge, so the correct answer does not drift as the web changes\. Tavily’s black\-box behavior varies only the*retrieval surface*: which snippet from which source is returned, and in what order\. Since the underlying evidence lives in well\-established, widely indexed public sources, any reasonably comprehensive web index can be expected to surface at least one supporting snippet for a reasonable query\.DiscoBenchtherefore remains solvable in principle on every run\.

#### Variance across runs\.

The black\-box effect manifests not as a change in answerability but as variance in*trajectory shape and retrieval efficiency*: the specific snippets surfaced, their ranking, and therefore which queries are sufficient and how manySearchcalls an agent needs before the relevant evidence appears in its context window\. Two runs of the same agent on the same question may consequently take different paths and consume different numbers of tool calls even when both ultimately succeed\.

#### Implications for interpretation and replication\.

A model’s reported score onDiscoBenchshould be read as an expectation over Tavily snapshots rather than as a per\-run deterministic quantity, and an individual incorrect trajectory should be inspected for its underlying cause—retrieval ordering on a given day versus a genuine ambiguity\-handling failure—before being attributed to model capability\. To make replications maximally comparable, we recommend that future users ofDiscoBench\(i\) run all compared agents within a short, contiguous evaluation window so they observe near\-identical Tavily snapshots, and \(ii\) where feasible, cache and release the raw Tavily responses alongside model outputs, which converts a hard reproducibility problem \(re\-deriving an identical live web view\) into a tractable one \(replaying a fixed snippet log\)\.

## Appendix IExamples

To illustrate the design ofDiscoBench, we walk through three cases from the benchmark, each spotlighting a different ambiguity type\. Case 1 \(Tab\.[9](https://arxiv.org/html/2606.27669#A9.T9)\) shows cascading Entity ambiguity along a multi\-hop chain; Case 2 \(Tab\.[10](https://arxiv.org/html/2606.27669#A9.T10)\) pairs Factual Inaccuracy \(CP1\) with Version ambiguity \(CP3\) in a single trajectory, forcing the agent to switch detection strategies mid\-chain; Case 3 \(Tab\.[11](https://arxiv.org/html/2606.27669#A9.T11)\) presents Criteria ambiguity, where identical surface wording maps to two distinct ranking standards\. Each case lists the original question, the ambiguity\-injected rewrite shown to the agent, and the checkpoint trajectory with ground\-truth types, targets, ambiguity logic, and the discriminative clue the user simulator releases upon a well\-targetedAsk\. In every table, English rows \(gray tint\) precede the original Chinese \(cream tint\)\. Colored text tracks each substitution thread: the same color appears on the original constraint, its weakened rewrite, and the clue that later restores it\.

#### Case 1: cascading Entity ambiguity across a multi\-hop chain\.

Tab\.[9](https://arxiv.org/html/2606.27669#A9.T9)presents a four\-checkpoint question from the*Video Games*domain\. The original question fully specifies two distinguishing awards – theGWB Indie Game Awards Bronze Prizeand the2012 Top Ten Most Anticipated Web Games– which uniquely pin down the two target entities*My Time at Sandrock*\(a Pathea Games title\) and*Jingtian Zhanshen Online*\(a ZQ Game title\)\. The ambiguity\-injection step replaces each of these strong constraints with the generic phrase “*won an award*”, producing two cascading Ambi checkpoints \(CP1and CP3\) of type*Entity*: at each, the rewritten constraint matches multiple notable award\-winning products of the queried company, so an unaidedSearchreturns more than one candidate\. The agent should detect this and invokeAsk; the user simulator then releases the original award name as a discriminative clue, allowing a refinedSearchto lock onto the target\. This case also exposes the benchmark’s central failure mode,*silent cascading*: an incorrect resolution at CP1\(e\.g\.,*Portia*instead of*Sandrock*\) still routes to a syntactically valid publisher at CP2, but every downstream checkpoint then targets the wrong entity, with no local indication of the upstream error\.

#### Case 2: Factual Inaccuracy followed by Version ambiguity\.

Tab\.[10](https://arxiv.org/html/2606.27669#A9.T10)presents a four\-checkpoint question from the*Sports*domain\. Two substitution threads run through the trajectory but follow different injection patterns\. Thread A \(CP1\) is a*Factual Inaccuracy*: the original country nickname “Land of Windmills” \(the Netherlands\) is replaced by “Land of Hajimi”, a fabricated term that does not refer to any real country\. The agent cannot resolve this checkpoint through retrieval alone – a faithful search returns no match – and must invokeAskrather than guess\. Thread B \(CP3\) is a*Version*ambiguity: the original match identifier “at the 60th minute of a 2018 CSL match” is weakened to the looser window “in a CSL match in March–April”\. Within that window Wang Chu came on as a substitute in two different matches on different dates, replacing Wang Gang in one and Cao Yongjing in the other; only the precise date disambiguates which match is meant\. The two threads together stress thatDiscoBenchrequires the agent to switch*detection mode*within a single trajectory rather than apply a single clarification heuristic uniformly\.

#### Case 3: Criteria ambiguity in a long bridging chain\.

Tab\.[11](https://arxiv.org/html/2606.27669#A9.T11)presents a three\-checkpoint question spanning the*Technology*domain\. Unlike Case 1 and Case 2, here a single colored phrase in the original is*deleted*rather than*replaced*: the qualifier “also nicknamed the ‘Ice City’” is removed during ambiguity injection\. After deletion, the surviving constraint – “a city whose Chinese name has three characters and lies above 40∘N, listed among the top three \[beer\-festival\] cities” – can be satisfied under two distinct enumeration criteria: the world’s top three beer festivals \(yielding Munich, 慕尼黑,∼\\sim48∘N\) or China’s top three beer festivals \(yielding Harbin, 哈尔滨,∼\\sim45∘N\)\. The agent must recognize that a single description fits two rankings and clarify*which ranking*the user intends before proceeding\.

Table 9:Case 1 \(Entity, cascading\)\.Four\-checkpoint question from the*Video Games*domain; two cascading Entity\-type Ambi checkpoints \(CP1, CP3\)\. Text color marks the two substitution threads\.Table 10:Case 2 \(Factual Inaccuracy \+ Version\)\.Four\-checkpoint question from the*Sports*domain; CP1injects a fabricated country nickname, CP3injects an under\-specified timing window admitting two candidate teammates\.Table 11:Case 3 \(Criteria\)\.Three\-checkpoint question in the*Technology*domain; one Criteria\-type Ambi checkpoint \(CP2\)\. The substitution thread here is*removed*rather than replaced, so the colored phrase appears only in the original question and in the discriminative clue\.

## Appendix JAnnotation Details

#### Recruitment and compensation\.

Annotators and quality inspectors were undergraduate students recruited from multiple institutions, with diverse academic backgrounds across several disciplines\. They were compensated on a per\-item \(piece\-rate\) basis, with a total payout of $39,000 for the entire annotation effort\.

#### Annotator consent\.

All annotators and inspectors were informed in advance that their annotations would be released as part of a public benchmark and consented to this use\.

#### Ethics review\.

The annotation task involved creating factual question–answer pairs from publicly available web resources and did not involve the collection of personal or sensitive information, so IRB approval was not required\.

## Appendix KQuality Inspection

This section provides further details on the quality control \(QC\) process introduced in Section[4\.3](https://arxiv.org/html/2606.27669#S4.SS3)\. During the two\-phase construction pipeline \(Section 4\), the initial LLM\-assisted generation and human annotation produced a larger pool of candidate samples\. After preliminary filtering for deduplication, format compliance, and basic factual verification, 314 candidate samples were retained\. We then applied a multi\-stage QC pipeline to these 314 samples to identify and remove low\-quality items before assembling the final benchmark\. The pipeline combines automatic structural checks, LLM\-based probing, and manual review, and employs a multi\-agent architecture in which a coordinating agent dispatches candidate samples in batches to specialized sub\-agents operating under strictly constrained prompts\.

#### Stage 1: Structural Validation\.

An automatic script verifies every candidate sample for field completeness \(all required fields non\-empty\), checkpoint\-structure consistency \(each sample contains at least oneAmbiand one terminal checkpoint; everyAmbinode carries a non\-emptyambiguity\_logicandclue\_if\_asked\), and difficulty–label alignment \(Easy / Medium / Hard corresponds to 1 / 2 / 3 ambiguity checkpoints, respectively\)\.

#### Stage 2: LLM\-Based Probing\.

Each sample is independently tested under two complementary conditions to assess whether the task genuinely requires multi\-step retrieval and multi\-turn clarification\. In both cases, the sub\-agent receives the*complete rewritten question*\(i\.e\., the full user query after ambiguity injection\) rather than individual checkpoint sub\-questions\. The prompt templates are provided in Box[K](https://arxiv.org/html/2606.27669#A11.SS0.SSS0.Px6)\.

- •Closed\-book probing\.The sub\-agent answers the full question using only parametric knowledge, with all retrieval tools disabled\. A correct answer signals potentialknowledge leakage\. Because the complete question may expose intermediate entities that would not be visible when checkpoints are processed sequentially, flagged samples are individually reviewed to distinguish genuine leakage from artifacts of the holistic testing format\.
- •Open\-book probing\.The sub\-agent is given access to a search tool \(capped at 25 calls to prevent runaway retrieval loops\) but is strictly prohibited from asking clarification questions\. A correct answer under this constraint signalsclarification\-free solvability: the injected ambiguity may not effectively require multi\-turn clarification\.

Answer equivalence between sub\-agent outputs and ground\-truth answers is determined by a separate LLM\-based judge, accounting for surface\-form variations such as transliterations, date formats, and title markers\.

#### Stage 3: Ambiguity and Factual\-Error Assessment\.

For each ambiguous checkpoint, a sub\-agent assesses whether the ambiguity issurface\-level, i\.e\., whether a typical user could enumerate the candidate entities from the question text alone using only commonsense knowledge\. Surface\-level ambiguity suggests that an agent could resolve the checkpoint by simply asking the user to choose among obvious candidates, without performing any retrieval\. Separately, for checkpoints of theFactual Inaccuracytype, the sub\-agent evaluates whether the injected error is recognizable without retrieval\. Errors that a typical user could identify through commonsense alone \(e\.g\., historically impossible dates or well\-known factual contradictions\) undermine the intended interaction pattern, as the agent should need retrieval evidence to detect and challenge such inaccuracies\.

#### Stage 4: Manual Review and Answer Verification\.

All automatically flagged samples undergo manual review covering three aspects: \(1\)question and ambiguity design, including whether the question text uniquely constrains the expected answer, whether the injected ambiguity is realistically triggerable during retrieval, and whether sub\-questions are logically coherent with the overall reasoning chain; \(2\)clue and retrieval quality, including whether the discriminative clue is natural and sufficient for disambiguation, and whether the target answer is retrievable through mainstream search engines; and \(3\)answer correctness, where we cross\-check ground\-truth annotations against external sources\. When the open\-book sub\-agent produces a plausible alternative answer differing from the ground truth, we verify whether the discrepancy reflects a legitimate alternative interpretation or an annotation error, and correct or supplement the ground truth where necessary\. Samples with correctable issues are revised; only samples with fundamental design flaws are removed\.

#### Stage 5: Final Verdict\.

A rule\-based decision tree aggregates the signals from the preceding stages to determine whether each sample effectively requires both deep retrieval and multi\-turn clarification\. A sample is removed when its quality signals indicate otherwise: commonsense\-recognizable factual errors are removed because they do not require retrieval to detect; knowledge leakage combined with clarification\-free solvability is removed because neither retrieval nor interaction is necessary; and surface\-level ambiguity combined with clarification\-free solvability is removed because the disambiguation does not depend on retrieved evidence\. Individual weak signals that may stem from the holistic prompt format are not grounds for removal on their own, but are noted for inspection\.

#### Results\.

Tab\.[12](https://arxiv.org/html/2606.27669#A11.T12)summarizes the QC outcomes\. Of the 314 candidate samples, 236 \(75\.2%\) passed quality control and 78 \(24\.8%\) were removed\. The finalDiscoBenchbenchmark comprises 211 samples drawn from those that passed, forming the common subset evaluable across all tested models after accounting for content\-policy restrictions of individual model providers\.

QC PROBING PROMPTS\-\-\- Closed\-book probing \-\-\-You are a knowledge assistant\. Answer the following question using only your training data\.\[Mandatory rules\]1\. You must NOT use any tools \(WebSearch, WebFetch, Bash, Read, etc\.\)\.2\. You must NOT say "I need to search" or "I cannot determine\." Even if uncertain, give your best guess\.3\. Do not explain your reasoning\. Output the answer directly\.Question: \{question\}Output exactly one line of JSON:\{"task\_id":"<id\>", "answer":"<your answer\>","confidence":"high\|medium\|low","used\_tools":false\}\-\-\- Open\-book probing \-\-\-You are a research assistant\. You may use WebSearch and WebFetch tools\.\[Mandatory rules\]1\. You may use WebSearch and WebFetch\.2\. You must NOT ask the user for clarification or say "the question is ambiguous\." Even if ambiguous, make your best judgment based on retrieval results and give a final answer\.3\. Total WebSearch and WebFetch calls must not exceed 25\. After 25 calls, give your best guess based on available information\.4\. You may only answer once; do not split across multiple turns\.Question: \{question\}Output exactly one line of JSON:\{"task\_id":"<id\>", "answer":"<your answer\>","search\_count":<int\>,"ambiguity\_noticed":true\|false\}

Table 12:Quality control results on the 314 candidate samples\.CategoryN%Overall QC outcomePassed23675\.2Removed7824\.8Removal reasons \(N = 78\)Commonsense factual error4962\.8Leakage \+ solvable w/o clarif\.2126\.9Knowledge leakage only33\.8Solvable w/o clarif\. \+ surface amb\.33\.8Other \(structural / answer defects\)22\.6

## Appendix LPrompt Templates

### L\.1Multi\-Turn Responder Prompt

MULTI\_TURN\_RESPONDER\_PROMPTRole: Multi\-turn dialogue simulated userYou play the role of a real user who is having a multi\-turn dialogue with an intelligent assistant \(Agent\), guiding it step by step through checkpoints to complete a complex query task\.Your responsibility: based on the current\-turn configuration and the Agent’s utterance in this turn, determine the state and output exactly one valid JSON object\.1\. Task ConfigurationFinal answer \(final\_answer\): \{final\_answer\}Forbidden information \(forbidden\_info\) \-\- These strings must never appear directly in reply; they may only be hinted at indirectly through clue\_if\_asked:\{forbidden\_info\}Note: You can only see the information under "Current Turn" below\. You cannot see fields from any other checkpoint\. This is a strict guarantee of progressive disclosure\. Make judgments only within the context of the current step\.2\. Current Turn State\- Current step: Step \{current\_step\} / \{total\_steps\}\- Whether this is the last step: \{is\_last\_checkpoint\} \(values: yes / no; treat it as the last step only when it equals yes\)\- Standard question for this step, question \(the system has automatically appended it to the Agent after the previous reply\): \{current\_question\}\- Goal for this step, goal: \{current\_goal\}\- Ambiguity description for this step, ambiguity\_logic: \{current\_ambiguity\_logic\}\- Clue for this step, clue\_if\_asked: \{current\_clue\_if\_asked\}\(If it is null or empty, this step has no ambiguity; otherwise, this step has ambiguity\.\)\- Whether the ambiguity in this step has been clarified, ambiguity\_clarified: \{current\_ambiguity\_clarified\} \(values: yes / no\)\- This is maintained by the system state machine\. It changes to yes when the previous status was ambiguity\_detected, and resets to no when entering a new checkpoint\.\- This field is authoritative: if it is yes, it means the Agent has already asked about this step’s ambiguity and received the clue\. It is forbidden to classify the turn as any missed\_ambiguity status\.\- If it is no, this step has ambiguity, and the Agent directly uses answer, then use case 3c or 3w\.\- Agent tool hint for this turn, tool\_name\_hint: \{tool\_name\_hint\} \(values: ask / answer / unknown\)3\. Global Hard Constraints \(check each item before output\)\- H1\. reply must not contain any forbidden\_info string\. Do not repeat entity names even in an affirmative reply\.\- H2\. reply must not repeat or imply the next question\. The system will automatically append the next checkpoint’s standard question after your reply; repeating it would cause the Agent to see two nearly identical user messages\.\- H3\. reply should use everyday spoken language \("yes", "right", "found it"\) and must not contain meta terms such as "checkpoint", "configuration", "goal", or "ambiguity\_logic"\.\- H4\. Progressive disclosure: provide feedback only for the current step, and do not reveal information from later steps\.\- H5\. The output must be valid JSON, with no Markdown code block or any text outside the JSON object\.4\. Decision Matrix \(match from top to bottom; stop at the first match\)1c\. Trigger: tool\_name\_hint == ask and the Agent asks exactly about the ambiguity point corresponding to this step’s ambiguity\_logic\. Status: ambiguity\_detected\.1w\. Trigger: tool\_name\_hint == ask, this step has ambiguity, and the Agent asks about another ambiguity, a later step, or an irrelevant clarification\. Status: wrong\_ambiguity\_detected\.5c\. Trigger: this is the last step \(is\_last\_checkpoint == yes\) and the Agent’s final answer matches final\_answer\. Status: task\_completed\.5w\. Trigger: this is the last step and the final answer does not match final\_answer\. Status: wrong\_answer\.2c\. Trigger: tool\_name\_hint == answer, the answer contains the key entity in goal and is logically correct, and either this step has no ambiguity or ambiguity\_clarified == yes\. Status: correct\_answer\.2w\. Trigger: tool\_name\_hint == answer, this step has no ambiguity, and the answer does not contain the key entity or is logically wrong\. Status: wrong\_answer\.3c\. Trigger: tool\_name\_hint == answer, this step has ambiguity, ambiguity\_clarified == no, and the answer happens to be correct\. Status: missed\_ambiguity\_correct\.3w\. Trigger: tool\_name\_hint == answer, this step has ambiguity, ambiguity\_clarified == no, and the answer is wrong\. Status: missed\_ambiguity\_wrong\.4\. Trigger: tool\_name\_hint == unknown, and agent\_input is neither a question nor an answer statement \(pure reasoning, search only, or empty text\)\. Status: search\_only\.4\.1 Conflict Between Hint and Text\- If tool\_name\_hint == ask but agent\_input is clearly a declarative answer, treat it as tool misuse and handle it as case 2w or 3w\. Set failure\_reason to tool\_misuse: <one sentence\>\.\- If tool\_name\_hint == answer but agent\_input is clearly a question, also treat it as tool misuse and handle it as case 1c or 1w\.4\.2 Basis for Determining Historical ClarificationPrimary source: directly inspect the ambiguity\_clarified field in Section 2\. If it is yes, the ambiguity has been clarified, and it is forbidden to classify the turn as any missed\_ambiguity status\.Supplementary source: the end of the dialogue history may include \[Clarification records already occurred in this checkpoint\] \(appended by the system from an authoritative data source; absolutely reliable and unaffected by truncation\)\. This is only a human\-readable note\. If it conflicts with ambiguity\_clarified, follow ambiguity\_clarified\.5\. Replies and JSON Templates for Each CaseCase 1c: ambiguity\_detected\- If clue\_if\_asked is non\-empty, state it in natural spoken language\.\- If clue\_if\_asked is empty, write: "There should be no ambiguity in this step; you can continue searching\."Example \(Agent: "There are two candidate works in that year\. Which one do you mean?"\):\{"status": "ambiguity\_detected", "should\_continue": true, "failure\_reason": null, "reply": "I remember it was an urban sci\-fi TV series\."\}Case 1w: wrong\_ambiguity\_detected\- Do not reveal clue\_if\_asked, and do not mention any forbidden\_info\.\- Decline naturally in spoken language\.\{"status": "wrong\_ambiguity\_detected", "should\_continue": true, "failure\_reason": "wrong\_ambiguity\_detected", "reply": "That is not the point I need to clarify\."\}Case 2c: correct\_answer \(not the last step\)\- reply should be only a short confirmation, without entity names and without repeating the next question\.\- Acceptable replies: yes / right / found it / that’s it / mhm\.\{"status": "correct\_answer", "should\_continue": true, "failure\_reason": null, "reply": "yes"\}Case 2w: wrong\_answer \(not the last step, no ambiguity\)\- reply must be exactly wrong\.\- Set failure\_reason to wrong\_answer: <one\-sentence reason\>\.\{"status": "wrong\_answer", "should\_continue": false, "failure\_reason": "wrong\_answer: the returned entity does not match the correct answer", "reply": "wrong"\}Case 3c: missed\_ambiguity\_correct\- reply should be a short confirmation, without entity names and without repeating the next question\.\{"status": "missed\_ambiguity\_correct", "should\_continue": true, "failure\_reason": "missed\_ambiguity: the Agent directly gave the correct answer without asking which candidate was intended", "reply": "right"\}Case 3w: missed\_ambiguity\_wrong\- reply must be exactly wrong\.\{"status": "missed\_ambiguity\_wrong", "should\_continue": false, "failure\_reason": "missed\_ambiguity: the Agent gave a wrong answer without asking about the ambiguity", "reply": "wrong"\}Case 4: search\_only\- The Agent used neither ask nor answer in this turn \(search only, pure reasoning, or empty text\)\.\- Write a light prompt such as Did you find anything? / Hmm?\.\{"status": "search\_only", "should\_continue": true, "failure\_reason": "search\_only", "reply": "Did you find anything?"\}Case 5c: task\_completed \(last step and final answer is correct\)\- reply must be exactly correct; no other content is allowed\.\{"status": "task\_completed", "should\_continue": false, "failure\_reason": null, "reply": "correct"\}Case 5w: wrong\_answer \(last step and final answer is wrong\)\- reply must be exactly wrong\.\{"status": "wrong\_answer", "should\_continue": false, "failure\_reason": "wrong\_answer: final answer does not match final\_answer", "reply": "wrong"\}6\. Output Schema \(single authoritative schema\)\{"status": "ambiguity\_detected \| wrong\_ambiguity\_detected \| correct\_answer \| wrong\_answer \| missed\_ambiguity\_correct \| missed\_ambiguity\_wrong \| search\_only \| task\_completed","should\_continue": true,"failure\_reason": "null \| <tag\> \| <tag\>: <one sentence\>","reply": "one spoken English sentence shown to the Agent"\}\- status: required; must be one of the enum values above\.\- should\_continue: required Boolean; cases 2w / 3w / 5c / 5w are false, all others are true\.\- failure\_reason: successful cases must use null; for failures, prefer the following tags \(optionally append : <one sentence\>\):\- wrong\_answer, missed\_ambiguity, wrong\_ambiguity\_detected, search\_only, tool\_misuse\- reply: required, and must satisfy all H1\-H4 constraints in Section 3\.7\. Dialogue History\{conversation\_history\}8\. Agent Input for This Turn\{agent\_input\}9\. Your OutputOutput exactly one JSON object according to the schema in Section 6\. Do not output any other text\.Before output, check mentally \(do not write this into reply\):\- reply contains no forbidden\_info\- reply does not repeat the next question\- reply uses spoken language\- status, should\_continue, and failure\_reason are mutually consistent\- The entire output is valid JSON and contains exactly one JSON object

### L\.2Neutral System Prompt

NEUTRAL\_SYSTEM\_PROMPTTask DescriptionYou are an intelligent agent having a multi\-turn dialogue with the user to complete a complex query task step by step\. Each step is a complete question\. You need to search for information and provide an answer\.Multi\-turn Interaction ModeThis is a multi\-turn dialogue task\. The user will provide sub\-questions step by step\. For each sub\-question, follow these requirements:1\. Use the search tool to search for relevant information\. Multiple search calls may be issued in parallel within one step\.2\. Based on the search results obtained, perform one of the following actions:1\. If the information after searching is insufficient to uniquely identify the answer, call the ask tool to request clarification\.2\. If the information is insufficient but can be resolved through additional retrieval, continue searching and return to step 2\.3\. If the search results are clear, call the answer tool to provide the final answer for this step\.Special notes:1\. Strictly distinguish between the ask and answer tools\.2\. Every turn must end with a call to either ask or answer\. Once you have obtained the answer or need to interact with the user, you must end the search phase by calling either ask or answer\.Tool ResponsibilitiesTool 0: search \-\- retrieve online informationCalling rules:\- Use it to collect facts related to the current question from online information sources\.\- Multiple different queries may be issued in parallel within one turn, and the results will be returned together\.\- Queries should use precise keyword combinations \(entity name \+ limiting dimension, e\.g\., "Qi Wei 2021 TV drama urban sci\-fi"\) and avoid full\-sentence natural language queries\.\- Under a single question, historical query results remain in the context and can be inspected at any time\.\- If Chinese entities are involved \(person names / film and television / companies / place names\), Baidu Baike or Chinese\-site keywords may be prioritized\.Tool 1: ask \-\- ask the user a clarification questionCalling rules:\- When the information required for the current sub\-question cannot be obtained through retrieval alone, request an additional clue from the user\.\- The question should focus on the specific missing discriminative dimension, using comparative or directional wording so that the user can reply easily\.\- Ask about only one dimension at a time so that the returned clue is singular and usable\.\- Do not ask the user for facts that can be obtained through search\.Tool 2: answer \-\- submit the final answerCalling rules:\- Call it when the answer to the sub\-question can be determined from the obtained information\.\- Once called, the final answer is submitted, and no further ask or search operations can be performed under the current sub\-question\.Important Constraints\- Every turn must end with a tool call; plain text without a tool call is not accepted\.\- Do not misuse tools: when interaction with the user is needed, use ask, not answer; when a clear result should be returned, use answer, not ask\.\- Within the same turn, ask / answer may be called at most once\. Once ask or answer is called, the current turn ends immediately, and the next turn can begin only after the user replies\.\- Under each sub\-question, you can see all search results and ask / answer interaction logs\. Reuse existing information first to avoid duplicate searches\.Answer Format Requirements \(only for the answer field of the answer tool\)When giving an answer \(not when actively interacting with the user\), the answer should:\- Be as concise as possible and directly answer the user’s question\.\- Not contain explanations or narrative descriptions\.\- Use Arabic numerals if it is a number\.\- Not use articles or abbreviations if it is a string\.Before calling any tool, think step by step: Is the current information sufficient to uniquely identify the answer? If yes, use answer; if no, continue search or use ask to interact with the user\.

### L\.3Guided System Prompt

GUIDED\_SYSTEM\_PROMPTTask DescriptionYou are an intelligent agent having a multi\-turn dialogue with the user to complete a complex query task step by step\. Each step is a complete question\. You need to search for information and provide an answer\.Question Prior \(Important\)The questions in this task usually deliberately replace proper names with "shared features / vague references"\. The question text may point to multiple candidate entities at the same time\. The discriminative facts needed to distinguish candidates are held by the user and will be released only if you proactively use ask\. Therefore:\- If literal searching returns two or more candidates that all satisfy the constraints, this is not a retrieval failure but the intended form of the question\. The correct action is ask, not choosing one candidate and using answer\.\- Do not make a guessed answer based on which candidate is more popular or more likely\. Even if the guess is correct, it still counts as missing the ambiguity\.\- A small number of non\-ambiguous bridging steps may also exist, where the search result is unique\. In those cases, directly use answer\. The criterion is the number of search\-result candidates, not the length of the question\.Multi\-turn Interaction ModeThis is a multi\-turn dialogue task\. The user will provide sub\-questions step by step\. For each sub\-question, follow these requirements:1\. Use the search tool to search for relevant information\. Multiple search calls may be issued in parallel within one step\.2\. Based on the search results obtained, perform one of the following actions:1\. If searching finds multiple candidates or the information is insufficient to uniquely identify the answer, call the ask tool to request clarification from the user\.2\. If the information is insufficient but can be resolved through additional retrieval, continue searching and return to step 2\.3\. If the search results clearly identify a single entity, call the answer tool to provide the final answer for this step\.Special notes:1\. Strictly distinguish between the ask and answer tools\.2\. Every turn must end with a call to either ask or answer\. Once you have obtained the answer or need to interact with the user, you must end the search phase by calling either ask or answer\.Tool ResponsibilitiesTool 0: search \-\- retrieve online informationCalling rules:\- Use it to collect facts related to the current question from online information sources\.\- Multiple different queries may be issued in parallel within one turn, and the results will be returned together\.\- Queries should use precise keyword combinations \(entity name \+ limiting dimension, e\.g\., "Qi Wei 2021 TV drama urban sci\-fi"\) and avoid full\-sentence natural language queries\.\- Under a single question, historical query results remain in the context and can be inspected at any time\.\- If Chinese entities are involved \(person names / film and television / companies / place names\), Baidu Baike or Chinese\-site keywords may be prioritized\.Tool 1: ask \-\- ask the user a clarification questionCalling rules:\- When searching returns two or more candidates that all satisfy the question constraints, or when the required information cannot be obtained through retrieval alone, request an additional clue from the user\.\- The question should focus on the specific missing discriminative dimension, using comparative or directional wording \(e\.g\., "Is it A or B?" / "Which feature is it closer to?"\)\.\- Ask about only one dimension at a time so that the returned clue is singular and usable\.\- Do not ask the user for facts that can be obtained through search\.Tool 2: answer \-\- submit the final answerCalling rules:\- Call it only after a single candidate entity has been uniquely identified and the current question can be answered directly\.\- Once called, the final answer is submitted, and no further ask or search operations can be performed under the current sub\-question\.Important Constraints\- Every turn must end with a tool call; plain text without a tool call is not accepted\.\- Do not misuse tools: when search results contain multiple candidates, use ask; do not submit a guess with answer\. When a unique candidate is identified, use answer, not ask\.\- Within the same turn, ask / answer may be called at most once\. Once ask or answer is called, the current turn ends immediately, and the next turn can begin only after the user replies\.\- Under each sub\-question, you can see all search results and ask / answer interaction logs\. Reuse existing information first to avoid duplicate searches\.Answer Format Requirements \(only for the answer field of the answer tool\)When giving an answer \(not when actively interacting with the user\), the answer should:\- Be as concise as possible and directly answer the user’s question\.\- Not contain explanations or narrative descriptions\.\- Use Arabic numerals if it is a number\.\- Not use articles or abbreviations if it is a string\.Before calling any tool, think step by step: Have the current search results uniquely identified one entity? If yes, use answer; if multiple candidates are found or information is insufficient, continue search or use ask to interact with the user\.

### L\.4System Prompt without Search

SYSTEM\_PROMPT\_w/oSEARCHTask DescriptionYou are an intelligent agent having a multi\-turn dialogue with the user to complete a complex query task step by step\. Each step is a complete question\. You need to obtain the necessary information and provide the answer using only multi\-turn interaction with the user\.Environment Constraint \(Important\)This task provides no retrieval / search tool\. You cannot access the Internet or any external knowledge base\.\- Any detail that requires fact verification must be obtained by using ask\.\- You are not allowed to make a guessed answer based on memory, common sense, or probability\. Even if the guess is correct, it still counts as missing the ambiguity\.\- The only two tools are ask and answer\.Multi\-turn Interaction ModeThis is a multi\-turn dialogue task\. The user will provide sub\-questions step by step\. For each sub\-question, follow these requirements:1\. Read the current sub\-question and identify discriminative points that require clarification, such as vague references, multiple candidates, or missing dimensions\.2\. Based on the information already available, perform one of the following actions:1\. If the information is insufficient to uniquely identify the answer, call the ask tool to request clarification from the user\.2\. If the information is sufficient to uniquely identify the answer, call the answer tool to provide the final answer for this step\.Special notes:1\. Strictly distinguish between the ask and answer tools\.2\. Every turn must end with a call to either ask or answer\. Once you have obtained the answer or need to interact with the user, you must end the current turn by calling either ask or answer\.Tool ResponsibilitiesTool 0: ask \-\- ask the user a clarification questionCalling rules:\- When the information required for the current sub\-question cannot be determined from the existing context alone, request an additional clue from the user\.\- The question should focus on the specific missing discriminative dimension, using comparative or directional wording \(e\.g\., "Is it A or B?" / "Which feature is it closer to?"\)\.\- Ask about only one dimension at a time so that the returned clue is singular and usable\.\- Because there is no search, any factual detail \(person name / time / value / ranking / affiliation, etc\.\) should be asked about whenever it is not yet certain\. Do not assume it yourself\.Tool 1: answer \-\- submit the final answerCalling rules:\- Call it only after a single candidate entity has been uniquely identified and the current question can be answered directly\.\- Once called, the final answer is submitted, and no further ask operations can be performed under the current sub\-question\.Important Constraints\- Every turn must end with a tool call; plain text without a tool call is not accepted\.\- Do not misuse tools: when information is insufficient, use ask; do not submit a guess with answer\. When a unique candidate is identified, use answer, not ask\.\- Within the same turn, ask / answer may be called at most once\. Once ask or answer is called, the current turn ends immediately, and the next turn can begin only after the user replies\.\- Under each sub\-question, you can see all ask / answer interaction logs\. Reuse existing clues first\.Answer Format Requirements \(only for the answer field of the answer tool\)When giving an answer \(not when actively interacting with the user\), the answer should:\- Be as concise as possible and directly answer the user’s question\.\- Not contain explanations or narrative descriptions\.\- Use Arabic numerals if it is a number\.\- Not use articles or abbreviations if it is a string\.Before calling any tool, think step by step: Is the currently known information sufficient to uniquely identify the answer? If yes, use answer; if no, use ask to request the key clue from the user\.

### L\.5System Prompt without Ask

SYSTEM\_PROMPT\_w/oASKTask DescriptionYou are an intelligent agent\. You need to solve a query question through search and provide the correct answer\.Tool ResponsibilitiesTool 0: search \-\- retrieve online informationCalling rules:\- Use it to collect facts related to the current question from online information sources\.\- Multiple different queries may be issued in parallel within one turn, and the results will be returned together\.\- Queries should use precise keyword combinations \(entity name \+ limiting dimension\) and avoid full\-sentence natural language queries\.\- If Chinese entities are involved \(person names / film and television / companies / place names\), prioritize Baidu Baike or Chinese\-site keywords\.\- Avoid arbitrary URL navigation\. Do not directly visit specific URLs that may not exist; obtain relevant URLs through a search engine\.Tool 1: answer \-\- submit the final answerCalling rules:\- Call it when the answer can be determined from the search results\.\- Once called, the final answer is submitted and cannot be retracted\.Important Constraints\- Every turn must end with a tool call; plain text without a tool call is not accepted\.\- Seeking help from a human is strictly forbidden\.\- Results such as "failure", "I cannot answer", or "not found" are not accepted\. You must keep searching until the answer is found\.\- Your answer must strictly follow the output format required by the task \(alphabetical order, ordering, units, rounding rules, number of decimal places, etc\.\)\.Answer Format Requirements \(constraining the answer parameter of the answer tool\)\- It should be a number, or an as\-short\-as\-possible phrase, or a comma\-separated list consisting of numbers and/or strings\.\- Do not include explanations or narrative descriptions of the answer\.\- Numbers: use Arabic numerals\. Do not use thousands separators, and unless otherwise specified, do not include unit symbols such as $ or %\.\- Strings: do not use articles or abbreviations \(e\.g\., for city names\)\.\- Comma\-separated lists: apply the corresponding rules above depending on whether each list element is a number or a string\.Before calling the answer tool, think step by step: Is the current information sufficient to uniquely identify the answer? If yes, call answer; if no, continue search\.