1. 问题与动机
这篇论文的核心判断是：Deep Research 不等同于 Deep Search。已有搜索型 Agent 主要围绕封闭式问答、信息定位、证据核验来构造训练数据，这类任务容易自动验证，也适合规模化合成，但它主要训练“找答案”的能力。真实研究任务还要求模型制定分析框架、处理开放目标、整合冲突证据、理解用户上传文件、按约束生成可交付报告。作者认为当前瓶颈不是缺少搜索工具，而是缺少同时覆盖信息获取、知识综合、规划决策、文件理解、结构化输出和技能调用的高质量长轨迹。
论文把这一差距落实到能力覆盖上：对比 Tongyi-DeepResearch、OpenSeeker、OpenResearcher、MiroThinker、REDSearcher、Vision-DeepResearch、Step-DeepResearch 等系统后，作者指出很多模型覆盖长程推理，但对 deep research instruction following、report writing、file/document 任务、dynamic skills usage 的显式覆盖不足。S1-DeepResearch 的目标就是构造能训练这些能力的统一数据底座，并发布 32B 模型和 15K 高质量 agentic trajectories。对搜索/推荐从业者来说，这个问题很现实：复杂搜索需求通常不是“找一个网页”，而是需要多源检索、证据压缩、冲突消解、排序解释和可读交付物，这正是传统 RAG 或单轮搜索 Agent 容易断裂的地方。
2. 方法详解
S1-DeepResearch 的方法由三段数据构造系统和一个监督微调目标组成。第一段是 Graph-Grounded Task Formulation and Complexity Evolution。系统先从 Wikipedia Entities 初始化 seed entity pool，然后用四级过滤选实体：基于拓扑和流行度过滤 sitelinks 与 2-hop neighbors，去掉过冷和过泛实体；过滤低信息密度实体，例如纯时间或数值实体；做 searchability verification，要求候选实体能搜到足够有效网页；最后做安全过滤，排除敏感或不稳定主题。实体选好后，用 Wikidata 多跳关系和开放网页检索构造 directed acyclic graph，并把网页中的文本实体、关系、事件以及图片/图表中的视觉概念解析为异构节点。再通过 community detection 把大图切成语义内聚的 connected subgraphs。
第二步是 query generation 和 self-evolution。系统在生成任务前注入约束，约束空间包含 9 个维度：Source、Argumentation、Reasoning、Objective、Hypothetical、Output Format、Output Scale、Execution、Contextual。开放式任务用这些约束生成研究型问题，封闭式任务则从子图生成可追溯答案。为了避免问题太容易，封闭式 QA 还做语义驱动的 query evolution：逐步弱化显式实体线索，把实体替换为背景描述、功能角色或关系表达，迫使模型进行多跳探索，而不是靠关键词直连答案。
第二大阶段是 AgentLoop Execution and Trajectory Refinement。任务进入沙箱环境后，Agent 通过原子工具完成 rollout。工具环境不是固定工作流，而是通用工具池，覆盖 web search、web visit、academic search、file parsing、code execution、bash、image search、image QA、video QA 等 9 类工具。每条轨迹由 user task、中间 reasoning/tool action、environment observation、final response 组成。系统还对不同场景做 refinement：例如把部分轨迹重塑为原生多模态查询、上传文件输入、可执行 artifact delivery，或要求最终输出符合 deep research report 的质量标准。
第三阶段是 Multi-Dimensional Trajectory Verification。作者为五类能力分别设计自动 verifier，检查动作序列、约束满足、引用与证据一致性、输出格式和任务完成质量。以报告生成场景为例，verifier 不只看最终文本流畅度，还检查正文引用是否与参考列表对齐、引用证据是否实质支持对应 claim。训练阶段采用 Qwen3-32B 作为 backbone，对筛选后的轨迹做 supervised fine-tuning。损失只监督 assistant-side actions 和 final answers，environment observations 作为外部输出不参与 loss。这个设计让模型学习“在已有观察条件下选择下一步动作”以及“证据足够后如何综合最终响应”。
3. 核心技术贡献
第一，论文把 deep research 的训练数据从 search-centric 扩展到五类能力：long-chain complex reasoning、deep research instruction following、deep research report writing、file understanding and generation、skills usage。相比只训练网页搜索和答案核验，这种覆盖更接近真实研究助手。
第二，graph-grounded 任务构造把开放式研究任务变得可控。用实体图和约束空间先定义探索边界，再生成任务，可以同时保留开放性和可验证性。它解决了开放任务难以规模化生成、难以过滤质量的问题。
第三，AgentLoop 和多维 verifier 让轨迹不仅包含最终答案，还包含工具调用、观察、约束执行、证据引用和交付物生成过程。对模型训练而言，这相当于把“研究工作流”压成可监督的行为数据，而不只是给一个理想答案。
第四，S1-DeepResearch-32B 证明 32B 级模型通过高质量 agentic trajectory SFT 能接近更大模型在部分 deep research benchmark 上的表现。论文反复强调参数效率：提升来自覆盖五类能力的数据，而不是简单扩大模型规模。
4. 实验结果分析
评测覆盖 20 个 benchmark 和 5 个能力维度。公共 benchmark 包括 BrowseComp、BrowseComp-ZH、GAIA、HLE、xBench-DeepSearch、LiveVQA、MM-Search、BrowseComp-VL、RealXBench、MM-BrowseComp、HLE-VL、DeepResearch Bench、DeepResearch Bench II、ResearchRubrics、ComplexBench、GAIA attachment subset、GTA 等。内部 benchmark 包括 FileSys、DeepResearchIF、SkillsUse：FileSys 有 454 个样本，覆盖 DOCX、PDF、HTML、XLSX、SVG、数据可视化等 artifact generation；DeepResearchIF 有 900 个样本，覆盖 9 个顶层约束类别和 26 个细粒度约束；SkillsUse 有 400 个 query，并按 Result、Execution、Skill Usage 等维度评估。
| 任务 | S1-DeepResearch-32B | 对比基线 | 关键观察 |
|---|---|---|---|
| Text long-horizon overall | 53.5 | Qwen3-32B 17.8 / Qwen3-235B 23.0 | 32B SFT 后大幅超过同源 backbone 和 235B 基线 |
| xBench-DeepSearch | 79.3 | Qwen3-32B 39.0 / Qwen3-235B 45.0 | 职业场景深搜索收益明显 |
| Deep research report overall | 48.7 | Qwen3-32B 35.2 / Qwen3-235B 37.3 | 学到证据收集到报告构造的完整流程 |
| DeepResearchIF Query-Level Acc. | 25.2 | Qwen3-32B 4.1 / Qwen3-235B 7.4 | 复杂研究约束跟随显著增强 |
| DeepResearchIF constraint macro avg | 74.3 | Qwen3-32B 28.9 / Qwen3-235B 54.9 | 9 类约束注入带来稳定收益 |
| FileSys | 69.3 | Qwen3-32B 44.7 / Qwen3-235B 37.0 | artifact 生成能力明显提升 |
| SkillUse overall | 70.1 | Qwen3-32B 44.9 / DeepSeek-V3.2 70.8 | 接近 671B 级通用模型 |
消融不是以传统组件 ablation 表呈现，而是通过能力维度和轨迹统计分析解释贡献。数据统计显示，不同能力的轨迹形态明显不同：deep research report generation 平均工具调用最多，为 23.5 次，total length 约 51,625，final answer length 约 8,921；long-horizon reasoning text 有 18,246 个样本，平均 10.7 次工具调用；multimodal long-horizon 有 5,203 个样本，平均 8.8 次工具调用且工具类型更丰富；file understanding & generation 有 8,507 个样本，最终答案短但中间解析和执行步骤重要。整体 49,299 条轨迹平均 9.7 次工具调用、20,431 token 总长度、1.92 类工具。
结果中也有不足。BrowseComp 上 S1 为 36.7，低于 Gemini-3.1-Pro-Preview 的 85.9、Claude-4.6 的 74.7，也低于 MiroThinker-1.7 的 74.0；HLE(Text) 为 30.3，落后多个前沿模型。多模态方面差距更明显：S1 使用外部感知工具把视觉输入转成文本观察，在 LiveVQA 为 67.7、MM-Search 为 54.4、BrowseComp-VL 为 39.1，明显低于部分原生多模态或专门多模态 deep research 系统。作者把这归因于 tool-augmented perception 与端到端多模态表征之间的架构差异，细粒度视觉 grounding、空间推理和跨模态对齐仍然是间接的。
5. 局限与未来方向
作者在局限和讨论中给出的主要限制有三类。第一，当前训练主要是 SFT，虽然能模仿高质量轨迹，但没有充分利用长期交互环境中的反馈信号。作者明确提出未来要研究 agentic reinforcement learning 和 online preference optimization，用长程反馈进一步改进规划、决策和自适应工具使用。
第二，多模态能力是外部工具增强，而不是原生多模态建模。图像先由感知工具转成文本观察，再给语言模型推理，这会削弱细粒度视觉定位、空间关系理解和跨模态一致性。因此在 BrowseComp-VL、MM-BrowseComp、HLE-VL 等 benchmark 上，S1 与专门多模态系统仍有差距。
第三，开放式 deep research 的验证仍依赖自动 verifier 和任务约束设计。论文已经用引用对齐、证据支持和场景化 verifier 降低幻觉，但对于真实业务中的主观质量、长期用户满意度、在线收益和安全风险，仍需要人工评估与线上反馈闭环。作者没有充分展开成本、延迟和工具失败恢复，这些是工业部署必须补齐的部分。
6. 工业实践意义
对搜索/推荐团队最重要的启发是：如果要做 Agentic Search，不应把目标设为“让模型多搜几轮”，而应把复杂搜索过程拆成可观测、可训练、可验证的轨迹。S1 的数据结构非常适合迁移到社区 UGC 搜索：用户 query、检索动作、帖子/评论观察、过滤器选择、重排解释、证据引用、最终摘要都可以成为轨迹中的 token 与事件。这样后续无论做 SFT、reward model 还是离线评估，都有明确对象。
第二个启发是任务生成和评估都需要约束空间。社区搜索中的约束可以包括内容来源（站内帖子、问答、评论、作者主页）、时间范围、证据数量、观点多样性、输出格式、安全边界和业务目标（CTR、满意度、举报风险）。这些约束如果只写在 prompt 中很难度量；如果结构化进任务和日志，就能像 DeepResearchIF 一样做 constraint-level macro evaluation。
第三，工具池要保持原子化。S1 没有把 deep research 写成一个固定大流程，而是提供 search、visit、academic search、file parsing、code、bash、image/video QA 等原子工具，让模型学习何时组合。搜索系统也应把 query rewrite、dense/sparse recall、profile lookup、entity expansion、freshness filter、rerank、citation extraction、risk check 拆成可观测工具，并记录每次调用的成本、延迟和收益。
第四，报告生成不是附属功能，而是复杂搜索的最终交付形态。对 UGC 短文本搜索，用户经常需要“比较几类观点”“总结某事件时间线”“找到可靠经验帖”。这类需求的 KPI 不能只看 nDCG，还要看证据覆盖、引用正确率、结论一致性和可读性。S1 的 file/report/skill benchmarks 提醒我们：最终交付物和中间轨迹同样需要评估。
落地时建议从低风险场景开始：先用离线日志合成 1K-5K 条复杂查询轨迹，覆盖多源召回、证据筛选和摘要生成；再为每条轨迹加 verifier，例如引用是否指向真实帖子、关键 claim 是否有证据、是否满足时间/来源约束；最后只在复杂查询或长尾问题上触发 Agentic Search，并设置工具调用预算。不要一开始就让 Agent 接管所有搜索流量，因为多轮工具调用会带来延迟、成本和稳定性问题。