利物浦大学、伦敦大学学院和华为诺亚方舟实验室联手造出一个"AI情报官"，它能把整个互联网变成一张巨大的结构化表格

这项由英国利物浦大学、伦敦大学学院以及华为诺亚方舟实验室共同开展的研究，于2026年4月以预印本形式发布，论文编号为arXiv:2604.27221。有兴趣深入了解完整技术细节的读者，可以通过这个编号在arXiv平台找到原文。

假设你是一位记者，接到了一个艰巨的任务：把2010年至2025年间泰勒·斯威夫特所有官方巡回演唱会的日期、城市和场馆，整理成一张干净的表格，一条数据都不能少。光是想一想，头皮就发麻——毕竟这横跨15年、涉及六次巡演、有534场演出需要逐一核实。你大概需要花上好几天，搜索无数网页，反复比对，才能拼出一张相对完整的清单。

现在再换一个场景：你是一位分析师，需要整理2014年到2024年间AMD发布的所有基于Zen架构的处理器，包含时间、产品系列、型号、核心架构、制造工艺、核心数、线程数、主频、二三级缓存、显卡型号等整整12列信息，共有331行数据。这个任务的难度更是呈几何级数上升，因为每一个单元格都需要被核实。

这两个场景描述的，正是现实世界中对AI代理系统日益迫切的需求。人们希望有一个"AI情报官"，能够自主地在互联网上大规模搜集、核实、整理信息，并输出一张结构严整、内容可靠的大表格。然而，现有的AI助手系统在面对这类任务时，往往力不从心：要么搜集的内容残缺不全，要么在大量信息面前开始混乱出错，要么根本无法把上百条数据组织成一张格式统一的表格。

正是为了解决这个问题，这支跨机构的研究团队提出了一套名为"Web2BigTable"的多智能体框架，它的目标非常明确——把互联网变成一张可以随时调取的巨大结构化表格。

一、为什么一个AI"侦探"搞不定，必须组一支"侦探队"

要理解Web2BigTable解决了什么问题，先要弄清楚现有AI系统卡在哪里。

当前的AI代理系统在处理网络搜索任务时，大体上面临两种截然不同的挑战。第一种叫"深度搜索"，就像一个侦探追查一个复杂案件：一步一步地推理，从A线索跳到B，再跳到C，最终锁定唯一正确答案。比如"某个第五代韩国女团的成员有一个小12岁的弟弟，这个团叫什么名字？"——这需要在娱乐数据库、粉丝百科、传记资料之间来回穿梭，才能找到那个唯一的答案。

第二种叫"广度搜索"，性质完全不同。它不是追踪一个目标，而是同时追踪几百个目标。就像整理一份城市黄页，你不只是要找到一家餐厅，而是要把城里所有的餐厅都找出来，并且记录下每一家的地址、电话、营业时间、菜系……而且每一条信息都必须准确，不能有遗漏，也不能有格式不一致的情况。

现有的单个AI代理系统——哪怕是最强大的那种——在面对广度搜索任务时，都会遇到一个根本性的瓶颈：它的"工作记忆"是有限的。就像一个侦探的脑子，同时装着太多案件信息时，就会开始混淆，开始遗漏，开始犯错。当任务需要追踪几百行数据，来回查证，AI的上下文窗口就会溢出，整个任务就开始崩塌。

更深层的问题是，单个AI代理的任务分解方式通常是静态的——它在开始时就决定怎么分工，之后即便发现原来的计划有问题，也很难调整。就像一个侦探一开始就把调查方向押错了，后来即便发现了新线索，也很难彻底改变调查路径。

研究团队认为，解决这个问题的关键不是让单个AI更聪明，而是让一支AI团队更协调。Web2BigTable的核心思路，就是用一种"指挥官+侦探队"的结构来替代单打独斗的AI侦探。

二、指挥官与侦探队：系统的两层结构

Web2BigTable的架构由两个层次组成，可以用一个警察局的运作来理解。

上层是"指挥官"，也叫编排器（Orchestrator）。指挥官的工作不是亲自跑现场调查，而是分析案件，决定如何分工。面对一个复杂的搜索任务，指挥官把它拆解成若干独立的子任务，然后分配给不同的侦探去并行调查。比如面对那534场泰勒·斯威夫特演唱会的任务，指挥官会决定：一号侦探负责调查Fearless巡演，二号侦探负责Speak Now巡演，三号负责The Red Tour……以此类推，每个侦探专注于一段特定的事，互不干扰。

下层是多个并行工作的"侦探"，也叫工作者代理（Worker Agent）。每个侦探拿到自己的子任务后，独立开展网络搜索，阅读网页内容，核实信息，最终把自己调查到的数据整理成表格的一部分，上交给指挥官。指挥官再把所有侦探的成果汇总，拼成一张完整的大表格。

这种两层结构的好处显而易见：任务被分散到多个侦探身上，每个侦探只需要处理一个有限范围的子任务，不会被海量信息淹没。多个侦探同时工作，效率也大幅提升。

但光有指挥官和侦探队还不够，这支团队还需要两个关键的基础设施：一个可以互相看到彼此进展的"公共白板"，以及一套随着经验积累不断完善的"调查技能手册"。

三、公共白板：让侦探们不做重复劳动

Web2BigTable设计了一个叫"共享工作板"（Shared Workboard）的机制，相当于侦探队办公室里那面贴满便利贴的大白板，所有人都能看到，但每个人只能往自己负责的区域写东西。

这面白板采用Markdown格式，分为三个区域。第一个区域是任务清单，列出所有子任务和各自的完成状态，让每个侦探随时都能看到整体进度，知道哪些已经搞定，哪些还在进行中。第二个区域是共享背景信息，由指挥官提前填写，包括提取规则、目标表格格式等，确保所有侦探输出的内容格式统一。第三个区域是各侦探的专属结果槽，每个侦探只能往自己的标签区域写数据，防止互相覆盖。

这套机制产生了三种自然的协作行为。当一个侦探发现某些条目已经被同事调查清楚了，它会自动跳过这些，把精力集中在还没有覆盖的部分，避免重复劳动。当一个侦探注意到某些类别的数据明显缺失时，它会调整自己的搜索策略，主动去填补空缺。当一个侦探发现同事找到了非常有用的信息来源（比如某个特别权威的网站），它会在自己的搜索中也优先参考这个来源，提高整体数据质量。

侦探们不只是在全部完成后才提交结果，而是在调查过程中就持续地把中间发现写到白板上。这样一来，先完成的侦探的工作成果，可以为后来的侦探提供参考，形成一种自然的信息流动。写白板的操作有文件锁保护，确保两个侦探不会同时修改同一区域而导致数据混乱。

四、技能手册：经验的积累与传承

公共白板解决了"侦探们如何在同一次任务中协作"的问题，但另一个同样重要的问题是：这支侦探队如何随着时间推移，越来越擅长完成这类任务？

Web2BigTable的答案是两个层次的"技能库"，分别服务于指挥官和侦探们，以纯文本的Markdown文件形式存储，人类完全可以阅读和修改。

指挥官的技能库专注于任务分解策略。指挥官需要决定的一个核心问题是：对于这个特定的任务，应该按时间段分工，还是按实体类别分工，还是按数据来源分工？这个决策至关重要，选错了就会导致某些侦探不堪重负而另一些侦探无事可做，覆盖率急剧下降。

这套技能并非人工手写，而是通过一个叫"运行-验证-反思"的闭环过程自动生成。研究团队在正式使用系统之前，会先用少量有标准答案的训练任务（每个基准测试只用20个）来"培训"这支侦探队。培训流程分三步走：先让系统用当前的技能完整地跑一次任务，然后把输出结果和标准答案逐格比对，找出哪些行漏掉了、哪些列有错误，最后由一个专门的"反思LLM"分析失败模式，提炼出可复用的分解策略，写入指挥官的技能文件。

以泰勒·斯威夫特演唱会任务为例，早期系统默认采用"按时间段分工"策略，把15年分成六个时间窗口，每个侦探负责一段。这导致了严重的问题：某个负责2019-2023年的侦探需要独自处理Era's Tour的130多场演出，完全超载；而且每个时间窗口里混杂了多次巡演的数据，搜索关键词很难精确，结果一团糟，只找到了534场中的234场。

经过反思后，系统自动生成了一条新的分解技能，核心原则是：当任务的目标是一批有名称的具体实体时（比如不同名称的巡演），应该按实体名称分工，而不是按时间分工。同时技能中还规定：如果某个实体预计有超过80条记录，应该进一步按地区拆分；必须有一个专门的"覆盖检查侦探"来发现遗漏；如果检查后还有超过10%的条目缺失，触发第二轮补充调查。这条技能被写入技能文件后，再次面对类似任务时，系统就会自动调用它，最终找到556条不重复的记录，行级F1值达到93.8%。

侦探们也有自己的技能库，专注于执行层面的能力，包括如何找到权威数据来源、如何处理格式不一致的网页内容、如何修复工具执行失败的情况等。当一个侦探需要某项特定能力时，它会通过一套混合搜索机制（结合关键词匹配和语义向量检索）在超过8000个预配置技能中寻找合适的工具。如果找不到，它会自己生成一个新的Python脚本或知识文档，这个新创建的技能会立即共享给所有其他正在工作的侦探，任何侦探创造的新技能，整个团队都能立即受益。如果一个技能执行失败，侦探会自动启动错误修复循环，把出错信息和当前代码一起交给语言模型分析，生成修正版本，经过代码语法验证后替换原版本。

五、训练与推理：两套模式，各司其职

理解了上述机制之后，整个系统的运作可以分成两个清晰的阶段来看。

训练阶段（也就是"培训侦探队"的阶段）在一小批有标准答案的任务上运行。每跑完一个任务，系统就把输出和标准答案比对，生成结构化的错误报告，然后通过反思机制更新指挥官的分解技能和侦探们的执行技能。整个过程不需要调整任何语言模型的参数，完全通过修改纯文本技能文件来实现学习，这被研究者称为"无梯度更新的自我进化"。训练完成后，技能文件被冻结。

推理阶段（也就是"执行真实任务"的阶段）使用冻结的技能文件作为只读输入，不再做任何学习或更新。指挥官读取技能文件，决定如何分解任务；侦探们读取技能文件，决定如何执行搜索；公共白板在任务执行过程中动态更新，任务结束后自动清空。整个推理过程是一次性的前向传递，不做任何反思或记忆更新。

这种训练-推理分离的设计非常优雅：它意味着系统可以用极少的训练样本（只有20个）就积累有效的策略，同时在面对真实的未见过的任务时，能以稳定可靠的方式执行，而不会因为边运行边学习而产生不稳定的行为。

六、实验数据：用数字说话

研究团队在两个基准测试上评估了Web2BigTable。

第一个是WideSearch，专门为测试大规模结构化信息提取能力设计，包含200个手工标注的任务（100个英文，100个中文），跨越15个领域，需要提取多维度的原子数据并组织成表格。评估指标包括三层：成功率（Success Rate，即整张表格完全正确的比例）、行级F1（衡量正确检索到了多少行数据）和条目级F1（最细粒度，衡量每个单元格是否正确）。每个系统独立运行4次，报告平均值和最佳值。

第二个是XBench-DeepSearch，一个专业标注的中文深度搜索基准测试，专注于多跳推理和跨源验证，恰好和WideSearch形成互补——一个测广度，一个测深度。

在WideSearch上，Web2BigTable取得了压倒性的领先：平均成功率38.50，是第二名（5.10，来自o3-high多智能体框架）的整整7.5倍；行级F1为63.53，超出第二名25.03分；条目级F1为80.12，超出第二名14.42分。

这些数字背后有一个特别值得关注的事实：Web2BigTable使用的两个底层语言模型——GPT-5 mini（负责指挥官）和Gemini 3 Flash（负责侦探），单独作为AI代理时的表现非常普通，GPT-5 mini的条目级F1只有33.28，Gemini 3 Flash更低，只有31.61。但装进Web2BigTable框架后，这两个模型的组合达到了80.12，提升了将近50个百分点。与此同时，那些使用了远比GPT-5 mini和Gemini 3 Flash更强大的模型的竞争系统（比如用Claude Sonnet 4或o3-high的多智能体框架），最高也只做到62.20的条目级F1，仍然比Web2BigTable低了将近18分。这有力地说明，Web2BigTable的性能提升来自框架设计，而不是底层语言模型的能力高低。

在XBench-DeepSearch上，Web2BigTable取得了73.0的准确率，超过了第二名Minimax-M2（72.0）和MiroFlow（72.0）。这个结果尤其有意思，因为深度搜索任务的性质和广度搜索完全不同，这说明Web2BigTable的框架设计具有一定的通用性，不只擅长处理"信息量大但每条信息简单"的任务，也能处理"需要多步推理才能得出结论"的任务。在这个基准测试上，系统使用5个并行侦探而非10个，因为深度搜索更需要一个侦探把推理链拉得足够长，而不是同时拉开很多条线。

七、拆开来看，每块积木的贡献

研究团队还做了一组拆解实验，逐一移除某个组件，观察性能变化，来搞清楚每个设计决策究竟贡献了多少。

移除学习到的指挥官分解技能——也就是让指挥官回到默认的语言模型推理来决定如何分工——带来了最大的性能崩塌。WideSearch成功率从38.50骤降到7.00，行级F1从63.53跌至45.23，XBench准确率从73.0跌至41.0，下降了32分。这表明"指挥官学到的分解策略"是整个系统最重要的组件，没有它，无论侦探们有多能干，整体结果都会千疮百孔。

移除公共白板——让侦探们各自独立工作，互相看不到彼此的进展——导致WideSearch行级F1从63.53降到54.81，XBench准确率从73.0降到60.0。没有白板，侦探们会重复搜索相同的内容，发现了覆盖空白也没办法通知其他人去填补，找到好的信息来源也没法共享给队友。

移除侦探们的技能进化——让侦探只能使用默认工具，不能创建新技能、不能修复错误——带来的影响最小但也显著，WideSearch行级F1从63.53降到59.67，XBench准确率降到64.0。大多数任务用基础工具就能应付，但遇到需要特殊处理方式的任务时，无法自我进化的侦探会卡住。

三组实验合在一起，清楚地呈现了一个结论：三个机制都有贡献，移除任何一个都会让性能下降，而指挥官的学习型分解策略是其中最关键的一环。

八、三个真实案例，看清系统的工作方式

研究论文中给出了三个详细的案例研究，展示了系统在真实任务中的具体行为。

第一个是泰勒·斯威夫特演唱会任务（前文已经详细介绍过）。没有技能的系统按时间分工，找到234行，行级F1 26.8%。用上技能后按巡演名称分工，找到556行，行级F1 93.8%。

第二个是AMD Zen架构处理器任务，要求整理2014年至2024年所有基于Zen架构的处理器，有12列信息，331行数据。没有技能的系统按时间分工，只找到137行，行级F1仅18%，条目级F1更只有32%——因为12列的数据要求让每一个错误的影响都被放大了。用上技能后，系统识别出这是一个"有多条产品线横跨多年"的任务，自动切换为按产品线分工的策略：一个侦探专门负责Ryzen桌面处理器（全部年份），一个专门负责EPYC服务器（Zen 1-2代），另一个专门负责EPYC服务器（Zen 3-5代），再有专门负责移动版、工作站版、嵌入式版的侦探，最后还有一个专门做规格验证（检查缓存大小和显卡核心数这类细节字段）的侦探。最终找到约334行，行级F1 89%，条目级F1 96%，和单个AI代理的10.5%行级F1、25.3%条目级F1相比，提升幅度触目惊心。

第三个是ByteDance Seed团队和DeepSeek的大模型论文汇编任务，要从两家机构各自的官方网站收集2023年1月至2025年6月间发表的所有大语言模型相关论文，同时需要处理一个复杂的日期规范化问题：如果同一篇论文在机构网站和arXiv上都有记录，以arXiv上的首次提交时间为准。没有技能的系统按时间分工，把30个月切成五个时间块，每个侦探都在混合地搜索两家机构，结果Seed团队约120篇论文只零散找到一些，DeepSeek更是大量漏掉，日期冲突问题也完全没有被处理，只找到67行，行级F1 41%。用上技能后，系统识别这是一个"有多个命名数据源"的任务，改为按数据源分工：多个侦探专门负责Seed团队（按年份再细分），一个侦探专门负责DeepSeek的全部记录，还有两个专门负责arXiv交叉核验和作者列表规范化的侦探。甚至在验证侦探发现有8篇论文的发布日期在机构网站和arXiv之间存在超过30天的差异后，指挥官还临时派出了补充侦探去专门解决这8条记录。最终找到134行，行级F1 91%，条目级F1 94%。

这三个案例清晰地展示了一个规律：系统的性能飞跃，来自于在任务分解这个关键决策上的精准判断——根据任务的内在结构（是按时间、按实体、还是按来源）选择最合适的分工方式，而不是不加思索地套用一个默认策略。

归根结底，Web2BigTable做的事情可以用一句话概括：它把一个不可能完成的单人任务，拆解成一支经过良好训练的团队能够胜任的协作项目。两个在单打独斗时表现平平的AI模型，在这套框架中协同工作，打败了使用远比它们强大的模型的竞争系统。这个结果传递出一个清晰的信号：在需要广度覆盖的信息搜集任务中，"如何组织工作"比"用多厉害的工具"更加关键。

当然，这项研究也有一些值得继续探索的边界。系统目前在训练阶段仍然需要有标准答案的参考数据，如果面对全新领域的任务，需要先用少量样本完成一轮培训。另外，在实时性极强的信息领域（比如股票数据或突发新闻），互联网本身信息的可靠性和一致性会影响最终表格的质量，这不是框架本身能完全解决的问题。

对于有兴趣进一步研究的读者，可以在GitHub上找到Web2BigTable的完整代码，地址在论文中有注明，也可以通过arXiv编号2604.27221查阅完整技术文档，从中读到更多关于数学形式化、算法细节和理论基础（包括附录中提到的基于Stackelberg博弈和随机反思记忆上升算法的理论扩展工作）的内容。

Q&A

Q1：Web2BigTable和普通的AI搜索助手有什么本质区别？

A：普通AI搜索助手通常是单个模型在处理任务，面对需要几百行数据的大表格任务时，会因为记忆容量不足而出错或遗漏。Web2BigTable的核心区别在于它用一套"指挥官+侦探队"的分工结构来处理任务，多个AI侦探并行工作，通过共享白板协调进度，同时会通过过去的经验自动学习更好的任务分解策略。两个普通模型装进这个框架后，性能反而超过了单独使用更强大模型的系统。

Q2：Web2BigTable训练的时候需要多少数据？

A：系统在每个基准测试上只用20个有标准答案的训练样本来学习分解策略，这个数量非常小。训练过程不需要调整任何语言模型的参数，完全通过修改纯文本技能文件来积累经验，被研究者称为"无梯度更新的自我进化"。20个训练样本就能带来显著的性能提升，这是该框架的一个重要特点。

Q3：Web2BigTable输出的表格数据可靠吗，会不会有错误？

A：可靠性是相对的。在实验测试中，Web2BigTable在行级F1上达到了63.53（满分100），条目级F1达到80.12，明显优于现有竞争系统。但这也意味着仍然有约20%的单元格信息存在错误或缺失，因为互联网上的信息本身就存在不一致和缺失的情况。系统会要求每条信息至少有两个独立来源支撑，一定程度上提高了可靠性，但面对真实世界中数据质量参差不齐的信息，完美的准确率仍然是一个持续优化的目标。