OPPO AI Agent Team
9 min
Abstract
Recent deep research agents primarily improve performance by scaling reasoning depth, but this leads to high inference cost and latency in search-intensive scenarios. Moreover, generalization across heterogeneous research settings remains challenging. In this work, we propose \emph{Search More, Think Less} (SMTL), a framework for long-horizon agentic search that targets both efficiency and generalization. SMTL replaces sequential reasoning with parallel evidence acquisition, enabling efficient context management under constrained context budgets. To support generalization across task types, we further introduce a unified data synthesis pipeline that constructs search tasks spanning both deterministic question answering and open-ended research scenarios with task appropriate evaluation metrics. We train an end-to-end agent using supervised fine-tuning and reinforcement learning, achieving strong and often state of the art performance across benchmarks including BrowseComp (48.6\%), GAIA (75.7\%), Xbench (82.0\%), and DeepResearch Bench (45.9\%). Compared to Mirothinker-v1.0, SMTL with maximum 100 interaction steps reduces the average number of reasoning steps on BrowseComp by 70.7\%, while improving accuracy.
Sam: They pick a central fact as the target. Then they grab a small connected chunk around it—like scouting the block around your house. They use a step-by-step neighbor search called breadth-first search, which just means checking close connections first. This creates puzzle pieces where you need several links to reach the answer. For precise questions with one right answer, they layer queries from outer edges inward. This verifies no shortcuts leak the solution—like building a riddle that needs all clues. For broader research, they make open questions needing a full summary across the chunk.
Alex: So the data forces parallel checking because the facts are intertwined in these chunks. What about training—did they just feed it these trajectories?
Sam: First, supervised fine-tuning uses teacher AI paths on this data. It caps lengths and favors efficient ones with multiple tool uses per step. Then reinforcement learning rewards correct final answers. It punishes format errors using a method that filters bad runs for stable updates. This builds habits for parallel info grabs under memory limits.
Alex: And for those memory squeezes in long runs?
Sam: When context fills up, it resets by refreshing the plan from recent history. It drops old details but keeps the structure—like summarizing notes before starting a new page. This lets it handle longer tasks in fixed space.
Alex: Okay, so that reset keeps things manageable for really long searches. But how does all this parallel work actually show up—like, does it really cut down the total effort without dropping quality?
Sam: The paper compares it directly on BrowseComp. Their main model reaches higher accuracy using roughly one-third the steps of a baseline like MiroThinker. This comes from packing more tool calls into each step—gathering evidence across subtasks at once.
Alex: One-third the steps but higher scores—that's a clear win on efficiency. What makes the parallel subtasks so much quicker at finding the key info?
Sam: They break the query into several possible side paths right away—like splitting a treasure hunt into teams checking different maps simultaneously. Each team runs its own searches or page checks. Then they share notes periodically to update the main plan and drop dead ends.
Alex: So it's not deeper thinking per step, but broader searching that speeds convergence. Does this hold up across different benchmarks?
Sam: It generalizes well. Their larger model leads or ties top scores across deep search and research tests—like on GAIA—without task-specific tweaks.
Alex: Interesting—broader evidence seems to help both types. What if you give it more steps to work with?
Sam: Ablations show success on hard tasks plateaus early. Extra budget mainly helps explore more paths on tough cases via re-planning. Wider web results per query also lift performance by packing denser info per action.
Alex: Huh, so scaling search width beats just adding length. That ties back to the whole "search more" idea. But to pull off that wider search in parallel, they must have specific tools—what are those?
Sam: The agent uses just two main tools. One queries a search engine for top results—like typing into Google and getting the first few links with short previews. They call this web_search. The other visits a specific page and pulls out a summary tailored to the question—like telling a note-taker to only jot facts about a certain topic. It's named crawl_page.
Alex: So web_search scouts leads broadly, and crawl_page dives deep but stays on track. That setup lets multiple subtasks run without overlap waste?
Sam: Yes. In parallel steps, it fires off several at once, gathering snippets and summaries from different angles before merging.
Alex: Makes sense for speed. Earlier you mentioned data from connected web chunks—how do they ensure those chunks have solid, factual info for training?
Sam: For deep search data, they extract details tied to key people or things strictly from text evidence—like pulling traits that appear word-for-word. No guessing allowed. Then they score descriptions for fact strength: high if packed with numbers, dates, or places. From that, they craft layered questions needing multi-step verification.
Alex: Huh, so fact filters keep training realistic, mimicking tough web hunts. Overall, it's a tight loop from data to tools to efficient runs. But how does the agent actually get instructed to break tasks into those parallel subtasks?
Sam: Detailed system prompts guide every step. First, it splits the overall question into a few clear goals—say, three to five independent pieces that can be tackled side by side. It lists them out right away, like assigning jobs to different team members. Then, in each round, it picks tools for multiple goals at once. It explains why, runs the searches, and notes findings. Periodically, it recaps progress—which goals are done or stuck—and updates the list.
Alex: So it's like a team huddle after scouts report back, adjusting the plan on the fly.
Sam: Yes. For exact answers, the prompt stresses a tight cycle: plan once up front, refine as needed, verify everything. Broader research builds toward a full report with sources cited inline, like a structured essay.
Alex: Huh, so the prompts enforce that team-like sync, turning broad searches into traceable reports. One clear efficiency edge there. So overall, this SMTL approach delivers fewer steps and better results across benchmarks. But no method's perfect; what are the main limits?
Sam: A key reliance is on external tools like the Serper search API and Jina reader service. Performance ties closely to settings like how many top results per search. Since training uses synthetic data from web chunks, it might falter on rare real-world cases not captured there. The paper notes these sensitivities.
Alex: Fair points—tool dependence and data gaps make sense as watch-outs. Practically, could this speed up tools like browser assistants for everyday deep dives?
Sam: Yes, it points toward real-time agents in browsers or workplaces. The step reductions make scalable help feasible without huge costs.
Alex: A meaningful step forward, then, with eyes on those limits. Thanks, Sam—that's a clear picture of efficient search agents.
Sam: My pleasure, Alex. Thanks for listening to ResearchPod.