HybridDeepResearch：跨越SQL与搜索，顶尖模型Pass@8仅54%
Benchmarking Hybrid Deep Research Across Database Querying and Web Search
当前的自主智能体（Autonomous Agents）在单项能力上已经展现出惊人的熟练度：面对开放式网络，深度研究（Deep Research）系统能自主规划数十次关键词检索与网页浏览，撰写出长篇报告；面对企业级关系型数据库，先进的 Text-to-SQL 模型也可以精准解析多表关联与复杂聚合条件。
ArXiv URL：https://arxiv.org/abs/2609.09410v1
然而，真实世界中的高价值分析任务，从来不会温顺地局限在单一环境内部。在金融审计、供应链风控或科研调查中，智能体既要处理来自关系型数据库的高度严密、精准的结构化表项，又要结合来自公开网络、新闻资讯甚至社交媒体的模糊、非结构化文本。以往的基准评测往往将这两项能力割裂开来，给外界造成了一种“智能体已能独立胜任复杂研究”的假象。
由来自首尔大学、Snowflake、加利福尼亚大学洛杉矶分校（UCLA）、香港大学与休斯顿大学的研究团队联合推出的 HybridDeepResearch，正是为了打破这一信息孤岛。作为首个明确要求协同使用“网页搜索”与“数据库 SQL 查询”才能得出最终答案的深度研究基准，该研究揭示了一个严峻的工程与认知瓶颈：智能体在跨系统转移证据时，极易丢失上下文约束（Constraint Handoff 失败）。
即便强如 GPT-5、Claude-Sonnet-4.6 以及开源顶尖的 GLM-5.2，在严格平衡的困难子集上，能够至少答对一次的 Pass@8 也仅仅徘徊在 50% 到 54% 之间；若衡量 8 次重复实验的平均准确率（Avg@8），所有模型的表现更是跌破了 30%。这说明，大模型面对跨模态联合探索时不仅胜率有限，更极度缺乏输出的稳定性。
致命的“交接时刻”：为什么两门工具加起来会失效？
传统评测通常假设环境是均质的。如果一个智能体既懂 SQL 语法，又擅长网络搜索关键词提炼，系统工程师往往预期把这两个工具挂载到同一个 ReAct 或多智能体流程里，问题就能迎刃而解。但真正的断层恰恰发生在两套工具交接证据的瞬间（Handoff）。
数据库环境是确定且严苛的，任何一个键名拼错、多余的空格或类型不匹配都会直接导致报错或空结果；而网络搜索环境则是宽泛、嘈杂且充满歧义的。当智能体需要把数据库里查出的精确代码、特定主键或实体名称，带入开放网络进行发散检索时，它常常会“泛化过度”，将原本严格的实体边界稀释为宽泛的检索词，导致后续步骤彻底偏航。反之，当智能体在海量网页中搜寻到某个现实线索后，又经常无法将其准确提炼为 SQL 语句中的严谨断言（Predicate），甚至套用错误的计算聚合公式。
为了系统化解构这种跨系统的认知脱节，HybridDeepResearch 将混合研究任务抽象为三种最具代表性的信息流拓扑模式：
第一种是 SQL 到搜索（SQL2S）。这是一种自内向外的发散过程。数据库作为严密的锚点，首先通过确定性的查询锁死某个关键实体或中间数值；智能体必须准确提取该结果，以此作为核心前提，转向开放网络搜寻相关的未知答案。在此过程中，智能体一旦因为网络信息的扰动而放宽了数据库给出的初始条件，整个推理链条就会立刻崩塌。
第二种是 搜索到 SQL（S2SQL）。这是一种自外向内的收敛过程。智能体需要先在非结构化的网络海洋中抽丝剥茧，定位出符合特定现实情境的实体或时间约束，随后必须将该线索精准无损地“翻译”为数据库的 WHERE 条件或过滤子句，驱动底层数据库执行最终计算。这里考验的是智能体在模糊信息与严密逻辑断言之间的映射保真度。
第三种是 并行交集（Parallel）。SQL 引擎与网络搜索引擎在起始阶段独立运作，分别拉取一份可能很大的候选实体集。最终答案并不单独存在于任何一边，而是两份候选集合唯一的数学交集。智能体不仅需要保持双线作战的能力，还要抵御诱惑，不能过早听信单侧工具呈现的局部结果，必须完成严格的双向交叉验证。
铸造“混合锁”：杜绝一切偷懒捷径的数据构建
在评测基准设计中，最致命的缺陷莫过于“单模态泄漏”——即一道号称需要调用多种工具的复合题目，实际上被模型依靠内部参数记忆猜出，或是单凭一次幸运的 Google 搜索就直接撞出答案。如果允许这类漏洞存在，评测反映的就只是搜索技巧或预训练记忆容量，而非真正的跨模态协同能力。
为了确保每一道题目都具有严格的“工具必然性”，HybridDeepResearch 构建了一套极为周密的过滤与合成流水线。
整个流程始于“双向接地实体锚定”（Dual-Grounded Entity Anchoring）。研究团队以 LiveSQLBench-Base-Lite 中的高质量真实数据库作为底层依托，挑选兼具数据库记录与外部知识图谱标识的核心实体作为种子节点。为了规避命名歧义（例如一个叫“Monaco”的值在库里究竟是指国家、城市还是赛车赛事），系统在实体入选阶段就通过多方校对确保其现实指向的唯一性。
在确定种子实体后，生成流程沿着两条轨道对称展开：
在非结构化轨道上，系统从 Wikidata、维基百科全文字段以及精选的 FineWeb 语料中提取与实体紧密交织的多元线索，组装成多线索收敛图（Convergent Multi-Clue Graph）。为了彻底切断模型利用简单关键词匹配“捡漏”的可能，流水线引入了精细的线索模糊机制（Controlled Clue Blurring），刻意隐去最具特异性的直接标识符，迫使模型必须在真实交互中整合多条微弱证据。
在结构化轨道上，系统抽取并泛化了来自高难度 SQL 基准的真实查询模式，强制生成具有多表关联、多层嵌套等复杂语法的真实查询。最终，根据目标模式的逻辑要求，两套轨道通过特定角色拼装在一起，形成结构与文本互为扣环的最终问答实例。
更为关键的是被称为 “混合锁”（The Hybrid Lock） 的全自动消融审查机制。所有合成出的任务实例，在正式入库前都必须强制接受严厉的“截肢测试”：评测流水线会派遣两组独立的单一工具智能体，分别在“仅允许使用网络搜索”和“仅允许执行 SQL”的极端环境下尝试破解题目。凡是在单模态测试中有任何一次被成功解答、或者表现出答案泄漏倾向的题目，都会被流水线无情废弃。只有那些在单侧工具面前坚不可摧、唯有双工具协同才能解开的实例，才能进入人工复核阶段。
最终成型的 HybridDeepResearch 包含了 380 道经过自动化消融与人工校验的高难度问题，横跨 9 个涵盖真实业务场景的数据库。为了在有限的 API 预算下提供无偏差的模型诊断，研究团队还精心挑选并构建了一个包含 120 道题目的平衡困难子集，严格保证 SQL2S、S2SQL 和 Parallel 三种模式各占 40 题。
实验残酷真相：单向传递远比想象中脆弱
在评测中，研究团队不仅囊括了顶尖闭源主力模型 GPT-5、Claude-Sonnet-4.6，还选取了以 GLM-5.2-FP4 与 Qwen3.5 全系列为代表的开源力量，并将其分别挂载于轻量单智能体框架 smolagents 和工业级多智能体编排框架 MiroFlow 之上。
在平衡困难子集上的受控对比实验揭示了一系列反直觉的实验现象。
| 模型 | 整体 Pass@8 | 整体 Avg@8 | S2SQL Pass@8 | SQL2S Pass@8 | Parallel Pass@8 |
|---|---|---|---|---|---|
| GPT-5 | 54.17 | 24.58 | 42.50 | 50.00 | 70.00 |
| Claude-Sonnet-4.6 | 50.00 | 28.12 | 35.00 | 45.00 | 70.00 |
| GLM-5.2-FP4 | 50.83 | 24.38 | 32.50 | 47.50 | 72.50 |
| Qwen3.5-397B-A17B | 44.17 | 19.38 | 27.50 | 37.50 | 67.50 |
这项实验结果呈现出三个极其深刻的技术特征：
第一，所有模型在 Pass@8 与 Avg@8 之间都裂开了一条巨大鸿沟。以 GPT-5 为例，其 Pass@8 可以达到 54.17%，意味着在给定的 8 次独立尝试中，有一半以上的难题至少能被懵对一次；然而，其 Avg@8 骤降至 24.58%，Claude-Sonnet-4.6 亦仅录得 28.12%。这表明目前的智能体在处理跨系统混合研究时，策略路径具有极高的随机性与不稳定性，完全不具备工业级应用所需的稳定复现水准。
第二，“定向约束传递”的难度呈断崖式高于“并行交集匹配”。所有测试对象都在 Parallel 模式下拿到了全场最高分（大部分模型的 Pass@8 均在 70% 左右），而在 S2SQL 和 SQL2S 任务中却表现惨烈。最艰难的 S2SQL 任务中，即便是 GPT-5，Pass@8 也仅有 42.50%，开源模型更普遍跌至 20%~30% 的低谷。
在 Parallel 模式下，智能体处理的是相对独立的两个目标，只要各自把候选集列出来，最终的求交集更多依赖于纯粹的符号比对，信息并没有发生复杂的模态形变。但一旦进入 SQL2S 或 S2SQL，智能体必须承担起“模态转换器”的角色——将精准的数据库字段值转化为网络语义空间里合理的搜索短语，或者将网页里的口语化事实精准地锚定为数据库 Schema 里的特定字段和函数逻辑。任何一处微小的语义形变，都会导致下一阶段的工具执行彻底脱轨。
第三，多智能体协作框架提升了探索上限，但难以提升执行确定性。在全量数据集的对比测试中，多智能体架构 MiroFlow 凭借更多的工作节点和多轮重试机制，显著推高了 Pass@8 的上限（在 Qwen 架构上普遍比单智能体 smolagents 高出 5 到 8 个百分点）。然而，从 Avg@8 来看，两者的差距微乎其微。多智能体框架固然可以通过广泛撒网“碰巧”找回之前遗失的条件，但伴随而来的海量工具调用、上下文窗口急剧膨胀，也导致了更频繁的超时（Timeout）与自我打架。
剖析败因：智能体究竟在哪里走漏了风声？
通过对模型长交互轨迹的细致复盘，研究人员总结出了导致跨系统研究崩溃的三种典型病态模式：
在 Parallel 场景下，最普遍的死因是过早承诺与求证惰性。智能体在调取一侧工具（例如先跑了一趟 Web 搜索）并抓取到几个看似非常合理的候选实体后，往往在注意力机制内部建立了强烈的先验偏见。在后续执行数据库查询时，它不再老老实实执行完整的并集检索，而是不由自主地退化成针对该单个候选实体的偏向性验证；一旦数据库返回空或者产生微小偏差，模型便不知所措，最终直接返回只被单侧工具支持的片面结论。
在 SQL2S 任务中，实体漂移（Entity Drift） 成为阻断推理的核心推手。智能体通过严谨的 SQL 查询拿到了确切的约束（例如某个小众冷门项目的代号），但在随后的网络搜索阶段，由于该代号在搜索引擎上最初的几次检索未能迅速返回高置信度结果，智能体为了“完成任务”，开始频繁更换检索词，逐步引入更通用、更宽泛的上位词。在这一退让过程中，数据库赋予它的初始强约束被悄然稀释，智能体最终带回了一篇文笔流畅、但实际上早已脱离了指定数据库限制的错误报告。
在 S2SQL 任务中，则是语义到代数的映射断裂。多数时候，智能体凭借强大的通识理解能力，确实能在互联网中锁定正确的目标实体；但当需要把这一实体作为条件写回数据库时，模型却在 SQL 语法层面的聚合计算、嵌套过滤或特定公式映射上栽了跟头。由于没有完全吃透目标数据库复杂的 Schema 关系与隐性业务规则，模型往往写出了语法正确但逻辑不对称的 SQL，最终让原本已经到手的线索沦为空谈。
走出单模态舒适区
HybridDeepResearch 的提出，给当前过热的“智能体深度研究”浪潮浇下了一盆及时的冷水。它清晰地表明，能够在单一模态下刷出高分的大模型，一旦被置于需要多系统无缝衔接的真实生产力场景下，其表现依旧脆弱不堪。
解决这一难题，仅靠增加模型参数量或在上下文窗口中堆叠更多的步骤或许并不够用。行业亟需在以下方向建立新的认知架构：智能体不仅需要学会“用工具”，更需要掌握在工具转换之间维持符号一致性与语义边界的能力；如何设计出具有强状态保持功能的上下文交接机制、如何在非结构化文本与严谨数据断言之间建立更稳固的双向翻译管道，将成为决定下一代企业级 Agent 能否真正落地的胜负手。