WebSailor: Navigating Super-human Reasoning for Web Agent

Paper: arXiv:2507.02592
Code: Alibaba-NLP/WebAgent
Code reference: main @ f72f75d8 (2026-02-27)

1. Motivation (研究动机)

WebSailor 关注的不是普通问答或单次搜索，而是接近 DeepResearch 这类 proprietary browsing agent 的复杂信息寻址能力：给定一个带有大量模糊约束的问题，agent 必须在开放互联网中反复搜索、访问、验证和综合证据，逐步压缩不确定性，最后给出一个可验证答案。论文的核心判断是，现有 open-source web agent 在 BrowseComp-en/zh 上接近零分，并不是因为底座模型完全没有知识，而是因为训练数据和训练范式很少显式塑造“在巨大信息空间中系统降低极端不确定性”的策略。传统 single-search、multi-hop QA、甚至很多 ReAct 轨迹都有相对清晰的推理链：先找实体 A，再找属性 B，最后拼接答案。BrowseComp 一类任务则没有预定义路径，错误搜索分支会快速膨胀，tool call 会吞掉上下文，agent 需要决定何时探索、何时剪枝、何时交叉验证。

论文把信息寻址任务按两维划分：初始不确定性高低，以及不确定性是否容易被规约。Level 1 是低不确定性任务，模型内化知识或一次 web search 即可回答；Level 2 是高初始不确定性但路径明确的 multi-hop QA，虽然步骤多，但每步实体连接关系较清楚；Level 3 是本文目标，问题同时具有高不确定性和高规约难度，实体关系非线性耦合、约束被模糊化、搜索入口不明显，需要 creative exploration 而不是固定脚本。这个划分解释了为什么“给模型接 search/visit 工具”不够：工具只是外部接口，真正缺失的是长期浏览中的策略性信息压缩能力。

Figure 2 解读：这张图把任务难度从简单事实查询推进到 Level 3 的 fuzzed graph sample。Level 1 的关键是答案附近信息几乎直接可见；Level 2 的关键是实体链条固定，agent 主要执行已知路线；Level 3 则通过 sample + fuzz 把多个实体、时间、属性和关系耦合起来，问题表述中还会把精确信息改写为模糊描述。WebSailor 的训练目标正是让模型熟悉这种“没有显式路线图”的探索模式。

这项工作试图解决三个互相耦合的瓶颈。第一，复杂训练数据难以人工构造。高质量 Level 3 问题必须足够难、真实、可验证，并且不能退化成模板化多跳问答；如果数据只覆盖线性路径，训练出的 agent 在 BrowseComp 上仍然会缺乏探索能力。第二，完整监督轨迹难以获得。强 open-source LRM 如 QwQ-32B 和 DeepSeek-R1 可以解出部分复杂问题，但它们的原生 reasoning 往往冗长、风格化，直接 SFT 会把 verbosity 和 stylistic prior 蒸馏给学生模型，并在几十轮 tool call 后触发 context overload。第三，agentic RL 成本极高。每个 rollout 都不是一次 forward，而是多轮 Thought-Action-Observation 与搜索环境交互；如果沿用 DAPO 式逐批动态补样，慢 rollout 会成为主要瓶颈。

值得研究这个问题的原因在于，一旦 open-source agent 能掌握 Level 3 信息寻址，它不仅能在 BrowseComp 上追近 proprietary agent，还能把这种训练迁移到更简单任务。论文声称 WebSailor 只在高难度数据上训练，却在 GAIA、XBench-DeepSearch 和 SimpleQA 上也保持竞争力，这说明“极端不确定性规约”不是单个 benchmark trick，而可能是 web agent 的基础能力：面对未知问题，先构建探索空间，再用工具收集证据，再用推理压缩候选集合，最后通过交叉验证确认答案。

2. Idea (核心思想)

WebSailor 的核心 insight 是：不要把 deep research 能力看成“更大模型 + 浏览工具”的自然涌现，而应把它拆成可训练的三件事：用 SailorFog-QA 合成 Level 3 高不确定性问题，用 expert LRM 的成功 action-observation trace 重构短而有效的 reasoning supervision，再用 RFT cold start + DUPO 进行低效率环境下的 agentic RL。这个组合直接针对复杂 web navigation 的两个本质难点：数据必须逼近真实互联网中的模糊信息拓扑，训练必须在稀疏奖励和慢交互下仍能筛出有学习价值的样本。

与 WebDancer、Search-o1、R1-Searcher 等已有 open-source web/search agent 相比，WebSailor 的差别不只是换了底座或 prompt，而是把训练集本身推向 Level 3。WebDancer 训练轨迹在论文 Figure 3 中超过 50% 只需两个 tool calls，几乎没有超过十次交互的 long-tail；WebSailor 的 SailorFog-QA 则保留大量超过五次、甚至二十次以上 tool call 的正确轨迹，使模型在训练时就暴露于长程探索、剪枝和综合。与 DeepResearch、Doubao-Search、Grok-3 等 proprietary agent 相比，WebSailor 的目标是把类似推理模式用 open-source 模型和可复现后训练流程逼近出来。

方法上的关键创新可以概括为三层：数据层，随机游走式知识图 + subgraph sampling + information obfuscation 产生真实、模糊、非线性的 QA；监督层，只保留 expert LRM 的成功 action-observation sequence，再用另一个 instruction-following model 补写 short-CoT thought，避免直接模仿长而风格化的 LRM 输出；RL 层，在 RFT 后使用 Duplicating Sampling Policy Optimization (DUPO)，先过滤 rollout 全对的简单 case，再在训练 batch 内复制有非零 reward 方差的样本填坑，替代慢速 sequential resampling。

Figure 1 解读：图 1 展示 WebSailor 在 BrowseComp-en/zh 上相对 open-source agents 和 proprietary browsing agents 的位置。论文正文的 Table 1 给出精确值：WebSailor-72B 在 BrowseComp-en/zh 上为 12.0/30.1，WebSailor-32B 为 10.5/25.5，均明显超过 WebDancer-QwQ 的 3.8/18.0 和 WebThinker-RL 的 2.8/7.3；在 BrowseComp-zh 上，WebSailor-72B 接近 Doubao browsing 的 26.0，并缩小与 DeepResearch 42.9 的差距。图的重点不是绝对分数已经超过 DeepResearch，而是 open-source agent 从近零推进到能与部分 proprietary browsing 系统同台比较。

3. Method (方法)

3.1 问题形式化：ReAct 轨迹和 Level 3 搜索空间

WebSailor 采用 ReAct 框架。给定问题后，agent 反复生成 Thought、执行 Action、接收 Observation；Action 空间包含 final answer、search 和 visit。search 接收若干查询并返回每个 query 的 top-10 titles/snippets/URLs；visit 接收 URL 及访问目标，先用 Jina 获取网页内容，再由 summary model 根据 goal 抽取相关信息。完整轨迹写成： $H_{T} = (τ_{0}, a_{0}, o_{0}, \dots, τ_{i}, a_{i}, o_{i}, \dots, τ_{T}, a_{T})$ 其中 $τ_{i}, a_{i}, o_{i}$ 分别是第 $i$ 轮 thought、action 和 observation；第 $t$ 步的 thought 与 action 来自策略 $π (a, t ∣ H_{t - 1})$ 。这一定义很重要，因为 WebSailor 的训练不是只优化 final answer，而是优化中间决策：在上下文、历史搜索结果和网页摘要都不断变化时，模型如何产生下一步搜索、访问或收束答案。

从直觉上看，Level 3 任务的难点不在“知识点很偏”本身，而在搜索空间组合爆炸。一个模糊时间描述可能对应多个年份，一个带首字母的机构描述可能对应很多实体，一个定性数量约束可能对应多个候选。agent 如果像 multi-hop QA 一样线性前进，就会被错误实体带偏；如果暴力展开，则会需要成百上千次 tool call 并超出 context window。WebSailor 因而把训练目标定位为：让 agent 学会把部分证据组织成候选集合、主动寻找区分性约束、丢弃低置信分支，并在最终答案前执行 cross-check。

3.2 SailorFog-QA：用图结构和模糊化合成 Level 3 QA

SailorFog-QA 的构造从“rare entity”开始。论文 Appendix A.2 说明，作者先用 Wikidata SPARQL 根据数据库规则拿到稀有实体，然后通过 search/visit 获取初始节点的特征，把它设为 expansion node。接着从 expansion node 的特征中抽取相关实体和关系，形成图中的新节点与边；每轮以一定概率选择新相关实体作为下一个 expansion node，或回到历史节点继续扩展，直到图边数达到预设值。这个随机游走式过程会天然生成非线性、重叠、耦合的实体关系，避免只得到 Level 2 那种直链 multi-hop。

在有了复杂 graph 后，系统会采样不同 topology 的 subgraph，并基于这些 coupled entities and relations 生成 question-answer pair。关键步骤是 information obfuscation：把精确日期改成“early 2010s”或“around the mid-5th century”，把名称改成“someone with the initial F”这类部分遮蔽，把数量属性改成“less than 1%”这类定性描述。这样问题仍然 grounded in real-world internet，但初始不确定性被刻意放大，agent 不能直接 lookup，而必须比较多个候选并综合关系。

SailorFog-QA 有三点方法价值。第一，数据来自真实互联网实体和网页信息，训练分布更接近 web agent 的部署环境。第二，subgraph topology 多样，会自然产生 deduction、composition、comparison 等不同 reasoning pattern，而不是手写模板。第三，潜在问题数量随图大小非线性增长，适合 scale。论文给出的示例包括：通过“late antique writer around mid-5th century death year”和“scientific chronology”交叉定位答案，或者通过南美首都相关歌曲、地方 civic honor、Colombia arts institution 等模糊约束定位音乐作品。这些问题在人类两小时检索约束下也很难，因为一开始没有显然入口。

def build_sailorfog_qa(seed_rules, max_edges, web_tools, obfuscator):
    graph = Graph()
    seed = wikidata_sparql_sample_rare_entity(seed_rules)
    graph.add_node(seed, features=web_tools.search_and_visit(seed))
    frontier = [seed]
 
    while graph.num_edges() < max_edges:
        node = random.choice(frontier if random.random() < 0.5 else graph.nodes())
        features = web_tools.search_and_visit(node)
        related_entities = extract_related_entities_and_relations(features)
        for entity, relation in related_entities:
            graph.add_edge(node, entity, relation=relation)
            graph.nodes[entity]["features"] = web_tools.search_and_visit(entity)
            frontier.append(entity)
 
    subgraph = sample_diverse_topology_subgraph(graph)
    clean_question, answer = formulate_qa_from_subgraph(subgraph)
    foggy_question = obfuscator.mask_dates_names_quantities(clean_question)
    return {"question": foggy_question, "answer": answer, "subgraph": subgraph}

这段伪代码对应论文 §3.1 和 Appendix A.2；released repo 在 WebAgent/WebSailor/dataset/sailorfog-QA.jsonl 提供样例数据，但当前 main@f72f75d8 没有公开完整数据生成脚本，因此这里的构造逻辑是 paper-derived pseudocode，而不是逐行复现代码。

3.3 Expert trajectory reconstruction：保留 action-observation，重构 short-CoT

合成 QA 后，下一步是生成可用于 cold start 的轨迹。直接使用 QwQ-32B 等 expert LRM 的完整输出有两个问题：一是 stylistic contamination，模型会模仿 teacher 冗长而强风格的推理；二是 context overload，几十次 tool call 的长 reasoning 会迅速挤占上下文，使后续训练和推理不可控。因此 WebSailor 采取“去思维、留行动、再补短思维”的方案。

具体做法是先提示 expert open-source LRM 生成完整解题轨迹，然后丢弃原始 verbose thoughts，只保留成功的 action-observation sequence $(a_{0}, o_{0}, a_{1}, o_{1}, \dots)$ 。这条序列保留了解题路径的 what/how，但缺少 why。接着对每一步 $t$ ，给定历史 $H_{t - 1} = (\overset{τ}{^}_{0}, a_{0}, o_{0}, \dots, \overset{τ}{^}_{t - 1}, a_{t - 1}, o_{t - 1})$ 以及 expert 的动作 $a_{t}$ 和观察 $o_{t}$ ，用另一个强 instruction-following model $π^{\*}$ 生成简洁 thought： $\overset{τ}{^}_{t} \sim π^{\*} (τ ∣ H_{t - 1}, a_{t}, o_{t})$ 最终轨迹为 $\hat{H}_{T} = (\overset{τ}{^}_{0}, a_{0}, o_{0}, \dots, \overset{τ}{^}_{T}, a_{T}, o_{T})$ 。这个设计的直觉是，agent 需要学会“为什么下一步要查这个、访问那个、排除某候选”，但不需要复制 teacher 的长篇内心独白。short-CoT 让监督信号更接近 action-oriented planning，也为后续长程 agentic RL 留出上下文预算。

def reconstruct_short_cot(expert_trace, thought_model):
    actions_observations = [(step.action, step.observation) for step in expert_trace]
    rebuilt_history = []
    for action, observation in actions_observations:
        thought = thought_model.generate(
            history=rebuilt_history,
            chosen_action=action,
            next_observation=observation,
            style="concise action-oriented short-CoT",
        )
        rebuilt_history.append({"thought": thought, "action": action, "observation": observation})
    return rebuilt_history

3.4 RFT cold start：少量高质量轨迹先建立 tool-use skeleton

论文虽然引用了近期“跳过 SFT、直接 RL”的趋势，但在 web agent 场景中明确反驳了这种做法。原因是 Level 3 browsing reward 极稀疏：初始 policy 往往不会得到正确答案，RL feedback 接近零；同时 rollout 慢，靠 self-exploration 从零发现长程策略成本太高。因此 WebSailor 先做一个 modest RFT cold start，使用略多于 2k 条高质量样本，让模型掌握基本 tool-use 格式和 long-horizon reasoning skeleton。

RFT 过滤有三层。第一，只保留最终答案正确的 expert trajectory，保证监督信号可靠。第二，丢弃超过 32k tokens 的轨迹，因为 expert model 的长上下文能力可能高于 policy model，过长样本会导致训练和推理不可承受。第三，只保留超过 5 次 tool calls 的轨迹，因为复杂 planning strategy 通常出现在较长决策序列中；这也与 Figure 3 的 long-tail 复杂度分布一致。训练目标只增强 agent 生成 thoughts/actions 的能力，环境 observations 对应 tokens 会被 mask，不进入 loss。

def filter_and_train_rft(trajectories, model, optimizer):
    kept = []
    for traj in trajectories:
        if not traj.final_answer_is_correct:
            continue
        if traj.token_count > 32_000:
            continue
        if traj.num_tool_calls <= 5:
            continue
        kept.append(traj)
 
    for batch in dataloader(kept, batch_size=32):
        input_ids, labels = format_react_trajectory(batch)
        labels = mask_environment_observation_tokens(labels, tags=("<tool_response>", "</tool_response>"))
        loss = model(input_ids=input_ids, labels=labels).loss
        loss.backward()
        optimizer.step()
        optimizer.zero_grad()

论文 Appendix A.4 给出训练配置：SFT 使用 Megatron，batch size 32，learning rate $5 \times 1 0^{- 6}$ ，minimum LR $1 0^{- 10}$ ，warmup + cosine decay schedule，weight decay 0.1。当前 released repo 没有 Megatron SFT launch script 或 config 文件，因此这些训练数值只能锚定论文 Appendix A.4；released code 中可核验的是推理/评测脚本而非 SFT 训练脚本。

3.5 DUPO：用 batch 内复制替代慢速动态补样

RFT 后，WebSailor 使用 Duplicating Sampling Policy Optimization (DUPO) 做 agentic RL。Agent RL 与普通 reasoning RL 的不同在于 rollout 要与 search/visit 环境多轮交互，速度远慢于纯文本 generation。DAPO 的 dynamic sampling 会过滤全对或全错 case，再补入新的 QA；但在 agent 场景中，这可能要求同一 batch 内顺序跑更多新 case，进一步拖慢训练。DUPO 的解决思路是把筛选提前和本地化：训练前先去掉 8 个 rollouts 全对的简单 case；训练中如果某 case 的 group reward 标准差为 0，即全对或全错，就在当前 batch 中用其他 reward 方差非零的 case 随机复制填补空位，而不是重新 rollout 新 QA。论文称相对 DAPO 约有 2–3 倍 speedup。

DUPO 的目标继承 group-relative advantage 思路。对问题答案对 $(q, y)$ ，从 old policy 采样 $G$ 个输出，目标近似为 token-level clipped policy gradient： $J (θ) = E_{(q, y) \sim D, {o_{i}}_{i = 1}^{G} \sim π_{θ_{o l d}} (\cdot ∣ co n t e x t)} [\frac{1}{\sum _{i = 1}^{G} ∣ o _{i} ∣} \sum_{i = 1}^{G} \sum_{t = 1}^{∣ o_{i} ∣} min (r_{i, t} (θ) \hat{A}_{i, t}, clip (r_{i, t} (θ), 1 - ϵ_{l o w}, 1 + ϵ_{hi g h}) \hat{A}_{i, t})]$ 约束为 $0 < ∣ {o_{i} ∣ i s_e q u i v a l e n t (y, o_{i})} ∣ < G$ ，也就是同组不能全错或全对。重要性采样比率和 advantage 为： $r_{i, t} (θ) = \frac{π _{θ} ( o _{i, t} ∣ co n t e x t )}{π _{θ_{o l d}} ( o _{i, t} ∣ co n t e x t )}, \hat{A}_{i, t} = \frac{R _{i} - mean ({ R _{i} } _{i = 1}^{G} )}{std ({ R _{i} } _{i = 1}^{G} )}$ 这里 $o_{i}$ 指模型生成 tokens，不是整条 tool trajectory；context 包含模型生成内容和 tool response。reward 是 rule-based format validation 和 answer validation 的加权和： $R_{i} = 0.1 R_{i}^{f or ma t} + 0.9 R_{i}^{an s w er}$ format score 检查 <think>、<tool_call> 等 tag 和 ReAct 序列是否合规；answer score 用 LLM-as-a-judge 判断最终答案是否正确。这个 reward 设计体现了 web agent 的双重需求：格式错会导致工具无法调用，答案错则表示不确定性没有被成功压缩。

def dupo_update(policy, old_policy, batch_qas, reward_fn, optimizer, group_size=8):
    # pretraining-time filter: remove cases that are too easy under 8 rollouts
    candidate_groups = []
    for qa in batch_qas:
        outputs = rollout_agent(old_policy, qa, n=group_size)
        rewards = torch.tensor([reward_fn(qa.answer, out) for out in outputs])
        if rewards.std() > 0:
            candidate_groups.append((qa, outputs, rewards))
 
    # in-batch duplication: fill removed slots with informative non-zero-std cases
    while len(candidate_groups) < len(batch_qas):
        candidate_groups.append(random.choice(candidate_groups))
 
    loss_terms = []
    for qa, outputs, rewards in candidate_groups:
        advantages = (rewards - rewards.mean()) / (rewards.std() + 1e-8)
        for output, advantage in zip(outputs, advantages):
            logp = policy.token_logprobs(output.generated_tokens, context=output.context)
            old_logp = old_policy.token_logprobs(output.generated_tokens, context=output.context)
            ratio = torch.exp(logp - old_logp)
            clipped = ratio.clamp(1 - eps_low, 1 + eps_high)
            token_loss = -torch.min(ratio * advantage, clipped * advantage).mean()
            loss_terms.append(token_loss)
 
    loss = torch.stack(loss_terms).mean()
    loss.backward()
    optimizer.step()
    optimizer.zero_grad()

RL 配置来自 Appendix A.4：每组 rollout number 为 8，temperature=1.0，top-p=1.0，batch size 128，mini batch size 32，learning rate $1 0^{- 6}$ 。论文还说明 RL 最多训练 50 steps，这是由 synchronous RL framework 的效率瓶颈限制；未来会迁移到 asynchronous training。当前 released repo 没有 DUPO/verl 训练脚本，因此伪代码按论文公式和描述重建；这不是逐行代码实现。

3.6 Released code：当前公开代码主要覆盖 inference/evaluation/tool wrappers

代码搜索结果显示，论文对应公共仓库是 Alibaba-NLP/WebAgent，本笔记锚定 main@f72f75d8 (2026-02-27)。仓库中 WebAgent/WebSailor/README.md、dataset/sailorfog-QA.jsonl 和 src/ 提供 WebSailor 介绍、样例数据、ReAct 推理、tool wrappers 与评测脚本；没有公开完整 SailorFog-QA 生成、RFT、DUPO 或 Megatron/verl training launch config。论文公式与 released code 实现差异：论文 §4.2 定义了 DUPO 目标和 batch duplication 策略，但 main@f72f75d8 的 WebAgent/WebSailor/src/ 未包含对应训练实现；因此本笔记对 DUPO 的伪代码以论文公式为准，对可执行推理/评测部分以 released code 为准。

react_agent.py 中的 MultiTurnReactAgent 是推理核心。它保存 llm_generate_cfg 和 llm_local_path，调用 OpenAI-compatible server，生成时使用 temperature 和 top_p，并设置 stop sequences 避免模型直接生成 <tool_response>。_run 函数从数据中取 question/answer，拼接 system/user prompt，循环调用模型；如果 assistant content 中有 <tool_call>...</tool_call>，就解析 JSON，调用 _call_tool，再把结果包在 <tool_response>...</tool_response> 中作为 user message 追加；如果出现 <answer>...</answer>，就停止并抽取 prediction。若达到调用次数上限仍未回答，则记录 exceed available llm calls 或触发最终回答提示。

class WebSailorReactLoop:
    def run(self, question, answer, model, tools, max_llm_calls=100):
        messages = [
            {"role": "system", "content": SYSTEM_PROMPT_MULTI + current_date()},
            {"role": "user", "content": USER_PROMPT + question},
        ]
        for _ in range(max_llm_calls):
            content = call_openai_compatible_server(
                model=model,
                messages=messages,
                temperature=0.6,
                top_p=0.95,
                stop=["<tool_response>"],
            )
            messages.append({"role": "assistant", "content": strip_tool_response(content)})
 
            if has_tool_call(content):
                call = json.loads(extract_between(content, "<tool_call>", "</tool_call>"))
                result = tools[call["name"]](**call["arguments"])
                messages.append({"role": "user", "content": f"<tool_response>\n{result}\n</tool_response>"})
 
            if has_answer(content):
                return {"prediction": extract_answer(content), "messages": messages, "termination": "answer"}
 
        return {"prediction": "No answer found.", "messages": messages, "termination": "exceed available llm calls"}

run_multi_react.py 负责多轮 rollout 和并发评测。它支持 gaia、browsecomp_zh、browsecomp_en、simple_qa、xbench-deepsearch、hle 等 dataset，默认 temperature=0.6、top_p=0.95、max_workers=20、roll_out_count=3。脚本按 output_base/model_name_sglang/dataset_name/ 建目录，每个 rollout 写 iter{idx}.jsonl，会跳过已处理 question，并用 ThreadPoolExecutor 并发调用 MultiTurnReactAgent._run。llm_cfg 中还设 max_input_tokens=320000、max_retries=10、model_type='qwen_dashscope'。这些是 released inference/eval 代码中的实际覆盖值，不是论文 Appendix 的训练参数。

def run_parallel_rollouts(model, dataset_items, output_dir, roll_out_count=3, max_workers=20):
    for rollout_idx in range(1, roll_out_count + 1):
        output_file = output_dir / f"iter{rollout_idx}.jsonl"
        processed = load_processed_questions(output_file)
        tasks = [{"item": item, "rollout_id": rollout_idx} for item in dataset_items if item["question"] not in processed]
        agent = MultiTurnReactAgent(
            llm={"model": model, "generate_cfg": {"max_input_tokens": 320000, "max_retries": 10, "temperature": 0.6, "top_p": 0.95}},
            function_list=["search", "visit"],
            system_message=SYSTEM_PROMPT_MULTI + "\nCurrent date: " + today(),
        )
        with ThreadPoolExecutor(max_workers=max_workers) as pool:
            for result in as_completed([pool.submit(agent._run, task, model, USER_PROMPT) for task in tasks]):
                append_jsonl(output_file, result.result())

tool_search.py 注册 search 工具，参数是 query array；实现中使用 GOOGLE_SEARCH_KEY 调用 https://google.serper.dev/search，每个 query 请求 top-10 organic results，并用 ThreadPoolExecutor(max_workers=3) 并发多个 query。tool_visit.py 注册 visit 工具，参数是 URL(s) 和 goal；它通过 Jina 读取网页内容，再使用 extractor prompt 调用 summary model，从 webpage_content 中抽取 rational/evidence/summary。evaluate.py 使用不同 judge prompt 处理 GAIA/XBench/BrowseComp/SimpleQA，计算 Pass@1、Pass@3、Best Pass@1、Avg Pass@3，并统计 invalid、extra length、平均 tool action、visit/search action、answer length 与 thinking length。

Code reference: main @ f72f75d8 (2026-02-27) — pseudocode and mapping based on this commit

Paper Concept	Source File	Key Class/Function
WebSailor overview / model links / training paradigm summary	`WebAgent/WebSailor/README.md`	README sections: Introduction, Quick Start, Complete Training Paradigm
SailorFog-QA sample data	`WebAgent/WebSailor/dataset/sailorfog-QA.jsonl`	JSONL examples
ReAct inference loop	`WebAgent/WebSailor/src/react_agent.py`	`MultiTurnReactAgent.__init__`, `call_server`, `count_tokens`, `_run`
Parallel rollout generation	`WebAgent/WebSailor/src/run_multi_react.py`	argument parser, `ThreadPoolExecutor`, rollout JSONL writing
Search tool wrapper	`WebAgent/WebSailor/src/tool_search.py`	`Search.google_search`, `Search.call`
Visit + summarization wrapper	`WebAgent/WebSailor/src/tool_visit.py`	`Visit.call`, `jina_readpage`, `call_server`
Evaluation and pass@k	`WebAgent/WebSailor/src/evaluate.py`	`call_llm_judge`, `calculate_pass_at_k`, `calculate_best_pass_at_1`, `aggregate_statistics`
Evaluation launch defaults	`WebAgent/WebSailor/src/run.sh`	dataset/model/output env vars, `TEMPERATURE=0.6`
DUPO / RFT training	released repo gap	paper §4 + Appendix A.4; no full training implementation in `main@f72f75d8`

4. Experimental Setup (实验设置)

模型方面，论文在 Qwen-2.5-3B、Qwen-2.5-7B、Qwen-2.5-32B、Qwen-2.5-72B 上执行 RFT 和 RL，得到 WebSailor-3B/7B/32B/72B。主要 benchmark 有四个：BrowseComp-en，用于评估 agent 在英文 hard-to-find、multi-faceted internet information 上的能力；BrowseComp-zh，是中文版本；GAIA，要求 tool use 和 multi-modality，论文只使用 text-only validation subset 中的 103 cases；XBench-DeepSearch，是动态、professional-aligned 的 deep information retrieval 与复杂 search benchmark。额外分析中还用 SimpleQA 验证 Level 1 兼容性；完整 SimpleQA 有 4,326 QA，论文随机采样 200 QA 进行评测。

Baseline 分三组。Direct Inference 包括 Qwen-2.5-32B、Qwen-2.5-72B、GPT-4o、GPT-4.1，以及 reasoning models QwQ-32B、o4-mini、DeepSeek-R1；小模型没有列入 direct baseline，因为它们在 BrowseComp 上基本为零。Proprietary Browsing Agents 包括 OpenAI DeepResearch、Grok-DeepResearch、Doubao with Deep Think and Search；由于 API 可访问性或成本，并非所有 benchmark 都覆盖。Open-source Agents 包括 Search-o1、WebThinker、R1-Searcher、WebDancer 等；这些是 WebSailor 需要正面超越的 open-source web/search agent。

评测指标默认 pass@k。pass@1 在非零 temperature 下报告，温度和 top-p 设置为 0.6 和 0.95；accuracy 由 LLM-as-a-judge 判断。pass@1 公式为： $p a ss @1 = \frac{1}{n} \sum_{i = 1}^{n} p_{i}$ 其中 $p_{i}$ 表示第 $i$ 个 response 是否正确；当 $k > 1$ 时重复生成 $k$ 次。Released code 中 evaluate.py 对 calculate_pass_at_k 的实现是：对每个 query 检查前 $k$ 个 round 的 judgement 中是否包含 Correct，若包含则该 query 计为通过；calculate_best_pass_at_1 则取三轮中单轮 Pass@1 的最大值。

训练配置需要区分论文训练和 released inference/eval 代码。论文 Appendix A.4：SFT 使用 Megatron，batch size 32，LR $5 e - 6$ ，minimum LR $1 e - 10$ ，warmup + cosine decay，weight decay 0.1；RL 使用 verl，group rollout number 8，temperature 1.0，top-p 1.0，batch size 128，mini batch size 32，LR $1 e - 6$ 。Released code 中没有对应训练 launch script；

实际可核验的 eval defaults 是 WebAgent/WebSailor/src/run_multi_react.py 的 temperature=0.6、top_p=0.95、max_workers=20、roll_out_count=3、max_input_tokens=320000、max_retries=10，以及 WebAgent/WebSailor/src/run.sh 的 TEMPERATURE=0.6。

工具实现方面，Appendix A.1 与代码一致地说明 search 返回每个 query top-10 结果，visit 用 Jina 读取网页并用 Qwen-2.5-72B summary model 按 goal 总结。

实验设计还有两个关键 analysis。第一，用 expert-generated correct trajectories 的 tool call 数量作为复杂度 proxy，比对 SailorFog-QA、BrowseComp-en 和 WebDancer-QA。第二，比对 RFT 后 RL 的 Pass@1/Pass@3 增益，以及直接 RL 与 RFT cold-start + RL 的收敛差异，以验证 RFT 和 DUPO 不只是工程加速，而是确实改变了 long-horizon tool-use 行为。

5. Experimental Results (实验结果)

主结果见 Table 1。Direct Inference 在 BrowseComp-en/zh 上普遍很低：Qwen-2.5-32B 为 0.6/3.9，Qwen-2.5-72B 为 0.6/7.0，GPT-4o 为 0.6/6.2，GPT-4.1 为 1.5/14.4；reasoning models 稍好，o4-mini 为 6.1/15.2，DeepSeek-R1 为 2.0/26.3，但它们没有 browsing 时仍不能稳定解决复杂信息寻址。Proprietary browsing agents 中 DeepResearch 在 BrowseComp-en/zh 和 GAIA 上为 51.5/42.9/67.4，Doubao browsing 在 BrowseComp-zh 为 26.0，Grok-3 browsing 在 BrowseComp-zh 为 12.9。Open-source baselines 中 WebDancer-QwQ 为 3.8/18.0/39.0/51.5，WebThinker-RL 为 2.8/7.3/24.0/48.5。

WebSailor 的主要提升集中在 open-source agent 维度。WebSailor-3B 在 BrowseComp-en/zh、XBench-DeepSearch、GAIA 上为 3.3/9.7/27.7/33.0；WebSailor-7B 为 6.7/14.2/34.3/37.9；WebSailor-32B 为 10.5/25.5/53.3/53.2；WebSailor-72B 为 12.0/30.1/55.0/55.4。尤其 WebSailor-7B 在 BrowseComp-en 上达到 6.7，超过 WebDancer-32B 的 2.5 和 WebThinker-RL 的 2.8，说明提升不只是参数规模，而来自数据与训练范式。GAIA 上优势相对小，作者人工检查认为是因为相当一部分 GAIA 任务需要数学和计算能力，而 WebSailor 主要优化 information retrieval；但纯信息检索子集上仍较强。

Figure 3a–3b 解读：左图把 SailorFog-QA 与 BrowseComp-en 的正确轨迹 tool call 分布相对照，右图把 SailorFog-QA 与 WebDancer-QA 相对照。论文的结论是 WebDancer-QA 严重偏简单，超过 50% 轨迹只需要两次 tool call，几乎没有超过十次；SailorFog-QA 则有明显 long-tail，大量样本超过五次，甚至超过二十次 tool call，并且与 BrowseComp-en 的复杂度轮廓更接近。注意图中展示的是最终过滤前的数据，之后 RFT 会保留超过五次 tool call 的轨迹。

SailorFog-QA 的 pass rate 分析进一步说明数据难度。Table 2 中，o4-mini 在 SailorFog-QA、WebDancer-QA、BrowseComp-en 上的 pass@1 分别为 47.3、90.2、26.3；DeepSeek-R1 分别为 38.9、84.4、9.5。也就是说，SailorFog-QA 比 WebDancer-QA 难得多，但仍比 BrowseComp-en 略容易，因为 BrowseComp-en 自身过滤了简单 case。作者也指出，低准确率部分来自任务固有歧义：某些模糊条件可能有多个交叉点，类似 BrowseComp-en 的情况；但他们会确保答案满足 question 指定约束。

Figure 4 解读：WebSailor 只用高难度数据训练，但在 SimpleQA 这个更接近 Level 1 的事实问答抽样上仍排在前列。论文报告完整 SimpleQA 有 4,326 QA，实验随机采样 200 条；图中 WebSailor-72B 达到 93.5，WebSailor 系列和多个 agent-based 方法明显优于 direct answering baseline。这个结果支持“从复杂不确定性训练中学到的搜索-验证习惯可以向简单任务下兼容”的观点，但也暗示可能存在 over-thinking 风险。

Figure 5 解读：图 5 比较 RFT 阶段和 RL 阶段在 Pass@1、Pass@3 上的增益，覆盖 BrowseComp-en、BrowseComp-zh、GAIA、XBench。可见 RL 在所有 benchmark 上都有提升，BrowseComp-en/zh 这类最难任务增益更突出；正文解释为，复杂任务的成功轨迹更长更不稳定，初始 Pass@1 与 Pass@3 gap 更大，RL 通过强化成功策略和剪掉无效策略，提高单次采样时的稳定性。因此 RL 对 Pass@1 的相对增益通常大于 Pass@3，说明 sample efficiency 被改善。

Figure 6a–6c 解读：图 6 对比 Qwen-2.5-instruct-32B 直接 RL 与 RFT cold start 后 RL。直接 RL 的 Pass@1 提升幅度可能更大，但最终收敛性能显著低于 cold-start 模型；工具调用数也显示差异，cold-start 模型的 tool call count 高且稳定，而 direct RL 虽然逐渐增加，仍明显偏低，说明它难以通过自探索学会 long-horizon reasoning。BrowseComp-en 上差距更大，支持论文关于“少量高质量 RFT 是复杂 web agent 的必要 bootstrap”的论断。

方法限制也很明确。第一，过滤掉超过 32k tokens 的训练轨迹是工程上必要的，但会限制模型处理更复杂问题；失败案例中许多错误来自 context limit，且 inference length 增大时性能可能下降。第二，WebSailor 会 over-thinking，对简单问题也可能执行多步 tool call；作者认为这不完全是坏事，因为某些情况下 agent 是在 cross-verification，但在成本敏感场景仍需控制。第三，RL 仅训练 50 steps，主要受 synchronous RL framework 效率限制；即使 DUPO 有 2–3 倍 speedup，agentic RL 仍慢，未来需要 asynchronous training。综合来看，WebSailor 的贡献是把 open-source web agent 推向 Level 3 复杂信息寻址，但 released code 当前还不支持完整复现训练流程，复现者更容易从模型权重、数据样例和 inference/eval pipeline 入手。

Paper Notes

探索

WebSailor: Navigating Super-human Reasoning for Web Agent

WebSailor: Navigating Super-human Reasoning for Web Agent

1. Motivation (研究动机)

2. Idea (核心思想)

3. Method (方法)

3.1 问题形式化：ReAct 轨迹和 Level 3 搜索空间

3.2 SailorFog-QA：用图结构和模糊化合成 Level 3 QA

3.3 Expert trajectory reconstruction：保留 action-observation，重构 short-CoT

3.4 RFT cold start：少量高质量轨迹先建立 tool-use skeleton

3.5 DUPO：用 batch 内复制替代慢速动态补样

3.6 Released code：当前公开代码主要覆盖 inference/evaluation/tool wrappers

4. Experimental Setup (实验设置)

5. Experimental Results (实验结果)

目录