AI团队开会像蚂蚁搬家：ANTMAN如何让智能体只找需要的信息

你有没有遇到过这种情况：为了准备一个复杂的问题，你翻开一本五百页的书，结果发现自己不是在读书，而是在和书较劲。信息越多，你反而越找不到重点。

现在把这个问题交给AI智能体，情况可能更糟糕。当一个AI系统需要在海量文档、代码库或者网页里找答案时，业界常用的办法是"分而治之"：把信息切成很多块，每块派一个worker（工作智能体，也就是负责执行具体搜索任务的AI子程序）去处理。听起来挺合理，对吧？可这里藏着一个几乎所有人都没细想过的陷阱。

**信息空间越大，参与协调的智能体数量就跟着线性暴涨，哪怕问题本身根本没有变得更复杂。**

这就是这篇论文要解决的核心矛盾。

一个反直觉的现象：信息变多了，任务却没变难

先说一个具体数字，你会觉得挺离谱的。

论文里做了个实验：把一个问答任务需要的信息空间从32K token扩大到512K token，整整扩大了16倍。按照常理，如果任务本身没变（就是要回答同一个问题），协调所需的智能体数量不应该跟着暴涨。可实际情况是，像LongAgent和CoA（Chain of Agents，一种把长文本切块后依次让多个智能体接力处理的系统）这类主流方法，活跃协调量增长超过15倍，模型调用次数增长超过12倍，推理成本涨了14到16倍。

也就是说，信息空间大了16倍，这些系统的"团队规模"和"开销"也跟着涨了差不多同样的倍数。

这不是巧合，这是设计上的必然。这类系统把信息按物理位置切块，一块配一个worker，信息空间越大，切出来的块越多，worker自然就越多。这就好比你搬家，把所有东西按房间打包，房子越大，箱子就越多，即便你实际上只需要带走厨房那几样东西。

论文提出的ANTMAN（Adaptive Need Tracking for Multi-Agent Navigation，直译是"面向多智能体导航的自适应需求追踪"）在同样的16倍信息空间增长下，活跃协调量只增长了1.23倍。成本增长也被压到了6.9倍，远低于对照组的14到16倍。

这个差距是怎么做到的？答案藏在一个很朴素但很少有人真正落地的想法里：让协调跟着"还缺什么信息"走，而不是跟着"信息放在哪里"走。

核心问题：协调的单位应该是什么

传统的多智能体系统，协调的基本单位是"分区"，也就是信息被物理切分后的一个个小块。这个设计思路来自一个隐含假设：信息越多，需要处理的工作量就越大，所以worker数量应该跟着信息量走。

但这个假设有个漏洞。一个查询到底需要多少信息去回答，和这个查询所在的信息空间有多大，其实是两码事。

举个例子。你要在一个有一千页的产品手册里找到"退货政策是什么"这一条，答案可能就藏在其中一页。如果手册从一千页扩展到一万页，只要退货政策那一段没变，你需要读的内容量其实还是差不多的，你不会因为手册变厚了就需要读十倍的内容才能找到同一条政策。

**当查询本身需要的信息量保持不变时，扩大信息空间不应该迫使协调规模成比例增长。**

这句话听起来像常识，但静态分区设计恰恰违背了它。原因很简单，分区式系统在任务开始前就把信息切好了，worker数量在那一刻就已经被信息空间的大小决定了，跟查询实际需要什么完全脱钩。

论文选择用另一种东西作为协调的基本单位：还没解决的信息需求。这个概念来自更早的信息检索理论。1989年，学者Bates就提出过一个观点，搜索不是简单地把一个固定问题不断细化，而是一个动态过程，你在搜索途中发现的新信息会改变你对问题本身的理解，进而改变你接下来要搜索什么。

对一个AI智能体来说也是一样的道理。它一开始可能只知道要回答"某公司去年营收多少"，但搜索过程中可能发现这家公司刚做了并购，那"营收"这个概念本身就需要重新定义，新的信息需求就这样冒出来了。之前认为已经解决的问题也可能因为新证据的出现而被推翻，需要重新处理。

这意味着，如果只是在任务开始时做一次性的问题拆解，是不够用的。你需要一个能够在执行过程中不断被修改的、明确记录"当前还缺什么"的状态。

Need Graph：一张会自己改的地图

ANTMAN的核心机制叫Need Graph（需求图）。

需求图：一种运行时维护的数据结构，记录当前任务里所有未解决的信息需求，每个需求节点包含它的状态（已解决/进行中/受阻）、已收集的证据、之前尝试过的方法、以及当前进展。

这张图不是一次性画好就不变了，而是随着搜索的推进不断被更新。每当某个worker返回一份搜索报告，协调者（论文里叫orchestrator，负责统筹调度的中心角色）就会根据这份报告去修改需求图：某个需求可能被标记为已解决，某个需求可能因为初次尝试失败而被重新表述，或者新的需求可能因为发现的线索而被追加进去。

这个设计的关键在于，它把"要搜什么"和"该派谁去搜"这两件事，从一次性决策变成了持续决策。

这里可以做个类比。假设你在带团队破一个悬疑案子。传统分区式的做法是，一开始就把所有嫌疑人的家、公司、社交圈全部划分给不同的调查员，每人负责一块区域，无论这条线索到底有没有价值，调查员都得把自己分到的那块地毯式排查完。如果嫌疑人名单从10个人扩大到100个人，调查员数量也得跟着扩大到100人规模的量级，哪怕真正有价值的线索可能只集中在其中三四个人身上。

而ANTMAN的做法更像一个经验丰富的探长，他手里拿的不是分区地图，而是一张不断更新的"未解之谜清单"。清单上写着"凶手的作案动机还没查清""不在场证明有矛盾"这些具体待解决的问题。每当有新证据进来，这张清单就会被重新整理：有的问题划掉了，有的问题因为新线索被拆成了更具体的子问题，探长只派人去追这些真正悬而未决的问题，而不是机械地把所有嫌疑人平均分配调查资源。

如果不这样做会怎样？就是文章开头那个16倍信息空间对应15倍协调开销的下场，团队规模跟着嫌疑人名单线性膨胀，绝大部分调查员其实在做无效劳动。

静态地图和动态需求的分工

ANTMAN把系统拆成了两层，一层是相对静止的"地图"，另一层是不断变化的"任务清单"。

先说地图这一层。信息空间被切分成若干个territory（论文里叫"领地"，指一个有边界的可搜索区域），每个领地配一张WorkerCard（工作卡，一段轻量的文字描述，概括这个领地大致包含什么内容）。这一层是静态的，事先算好，不随任务变化。

这里有个重要的区分：**领地和WorkerCard定义的是"有哪些worker可用"，而不是"每次查询必须动用哪些worker"。**

拿图书馆打比方会很直观。一个图书馆按楼层和书架分类，一楼是文学，二楼是历史，三楼是科学，这个分类方式是固定的，不会因为你要查一本书就重新装修图书馆。但你查资料时，不需要把三层楼全部搜一遍，你只需要根据你要查的具体内容，判断该去几楼几号书架。

需求图这一层就负责做这个判断。每一步协调，系统会从需求图里挑一个当前未解决的需求，结合领地地图和WorkerCard，判断这个需求该派给哪个领地的worker去处理。worker在自己被分配的领地内做有限范围的搜索，返回证据和进展，协调者据此更新需求图，进入下一轮。

论文里给出了一个数学化的表达来说明这套机制到底有多克制。设M是总的领地数量，H(q)是一次查询实际产生的信息需求数量，ρ是每个需求最多被重新路由的次数，那么实际被激活的worker数量不会超过M和ρ×H(q)两者中较小的那个。

这个公式的现实意义是，即使可用的领地数量M因为信息空间扩大而变得很多，只要一次查询实际需要处理的信息需求H(q)保持在合理范围，激活的worker数量就有一个跟M无关的上界。这正是活跃协调量能保持接近常数增长的数学基础。

如果遇到某个需求反复尝试都没进展怎么办？论文设计了task-local recovery（任务局部恢复）机制。

任务局部恢复：当某个信息需求陷入停滞时，系统采取的补救策略，包括把需求重新表述、换一个领地重新尝试、或者启用备用的解决路径，而不影响整体的领地地图和worker定义。

这就好比你在图书馆某个书架翻了半天没找到你要的书，你不会把整个图书馆推倒重建，而是换个说法问问管理员，或者干脆去别的楼层碰碰运气。局部出问题，局部想办法，不牵连整个系统的架构。

数据说话：三种场景下的实测表现

光讲原理不够，得看数字。论文在三类场景下做了系统性验证。

**第一类是常规的多文档问答**，用HotpotQA、2WikiMultiHopQA、MuSiQue这三个经典的多跳问答基准测试（多跳问答指需要跨多个文档、多个推理步骤才能得出答案的问题类型）。

结果显示，ANTMAN在这三个基准的宏平均精确匹配率（EM，指模型答案与标准答案完全一致的比例）达到0.711，F1分数（一种综合衡量答案准确度和完整度的指标）达到0.814，是所有参与对比的九种方法里表现最好的，甚至超过了专门为检索场景设计的S2G-RAG（一种通过判断证据是否充分、并生成结构化缺口条目来指导下一步检索的方法）。

更有意思的是，论文还测试了把执行层的模型换成小模型会怎样。ANTMAN-H版本保留了GPT-4.1做协调决策，但把所有实际执行搜索的worker换成了参数量小得多的Qwen3-8B模型。结果这个"缩水版"依然保住了原版89%到98%的性能，具体在RepoProbe基准上保留89.2%，SWE-QA-Pro上保留93.5%，GAIA上保留98.3%。

这说明协调策略本身的价值，比单纯堆更强的模型更重要。就像一个乐团，指挥的水平往往比乐手个体的技巧上限更能决定整体演出的质量。如果指挥调度得当，即便乐手不是顶级演奏家，整体效果依然可以很出色。

**第二类是受控的信息空间扩展实验**，也就是前面提到的32K到512K的对比。这个实验设计得很巧妙，论文用了LongAgent的Needle-in-a-Haystack PLUS（大海捞针加强版）方法，保证每次实验里真正需要的证据数量不变，只是周围填充的干扰信息越来越多。

除了活跃协调量，论文还测了答案质量的稳定性。ANTMAN在32K到512K范围内的F1分数在0.75到0.84之间波动，LongAgent在0.67到0.76之间，波动更大且整体偏低。也就是说ANTMAN不仅协调开销低，答案质量反而更稳更好。

论文还做了个反向实验，固定信息空间在512K不变，把真正需要的证据数量从1个逐步加到4个再到16个。这次结果显示，活跃协调量确实随着信息需求增加而增长，从5.0个worker涨到8.0个，调用次数从35.5次涨到86.2次，但所有场景下证据完整获取率和最终答案准确率都保持在100%。

这组对照实验其实是在证明一件很关键的事：**ANTMAN的协调开销跟着"需要多少信息"走，而不是跟着"信息藏在哪儿的空间有多大"走。**

**第三类是更贴近现实的结构化导航场景**，包括代码仓库理解基准RepoProbe-Python、SWE-QA-Pro，以及通用工具使用基准GAIA（一个要求智能体综合运用网页搜索、代码执行等多种工具完成复杂任务的评测集）。

在RepoProbe上，ANTMAN得分38.21（满分制换算后的分数），比最强的非专用基线高出15.3%。在SWE-QA-Pro上领先18.4%，在GAIA-Text-103子集上领先27.9%，达到58.3分。特别值得一提的是GAIA这个场景，它和代码仓库、长文本完全是不同的信息形态，一个是网页和工具调用，ANTMAN依然能保持领先，说明这套需求驱动的协调思路不是只对某一种数据形态管用，而是有一定的普适性。

论文还专门做了消融实验，去验证需求图这个机制本身是不是真的有必要，还是说随便一个"自适应"策略都能达到类似效果。他们设计了一个叫Graph-free Adaptive（无图自适应）的对照组，这个版本依然允许模型根据当前证据动态选择worker、调整搜索方向，但不维护那张显式的、持续修订的需求图，全靠上下文历史临时判断。

结果显示，在512K的受控场景下，完整版ANTMAN的F1达到84.03，无图自适应版本只有64.01，差了23.82%。在GAIA上完整版是60分，无图版本只有50分，差了16.67%。

这个结果挺说明问题的。哪怕两个版本激活的worker数量差不多，有没有一张持续维护、结构化记录的需求状态图，依然带来了显著差距。这意味着"记住并组织当前还缺什么"这件事本身有独立的价值，不能简单靠模型临场发挥的自适应能力替代。

这里做个类比可能更好理解。你做一个大项目，团队里有的人靠脑子记进度，有的人用一张不断更新的任务看板。两种人可能都很聪明，都能根据情况随机应变，但用看板的人不容易漏掉那些"暂时搁置但还没解决"的任务，也更容易看出哪些任务之间是相互依赖的。而只靠脑子记的人，时间一长，容易顾此失彼，或者重复劳动。如果不用看板，凭记忆调度，看起来省了维护成本，实际上决策质量会打折扣，这正是消融实验里那16%到24%的性能差距的来源。

消融实验还拆解得更细，去掉需求修订能力（不允许重新表述失败的需求）会让GAIA准确率掉29.17%，去掉自适应路由（不允许把需求重新分配给别的worker）在结构化代码导航场景影响明显，去掉恢复机制在受控扩展场景下影响最大，F1掉了28.45%。这说明需求图里的不同能力，在不同类型的任务里各自扮演着不可替代的角色，没有哪一个是多余的装饰。

位置不敏感：躲开"迷失在中间"的坑

论文还测了一个很实际的问题：如果关键证据藏在超长文本的中间位置，AI会不会更容易漏掉？

这个现象在业界有个专门的名字叫"lost in the middle"（迷失在中间），之前的研究发现，直接把整个长文本喂给大模型，模型对开头和结尾的信息利用得比较好，但对中间部分的信息经常视而不见，哪怕那段信息就是答案所在。

lost in the middle：一种已被观察到的大模型行为模式，指模型在处理长文本时，对位于文本中间位置的关键信息利用效果明显弱于开头和结尾位置的信息，即使中间信息同样重要。

论文用同样的Early（前）、Middle（中）、Late（后）三种证据位置做对照，直接把全文喂给模型（Full Context）作为参照组。结果显示，Full Context方案在32K长度下，中间位置的F1只有0.590，明显低于开头位置的0.911和结尾位置的0.813，中间位置比两端均值低了0.181。

而ANTMAN在同样条件下，中间位置F1不降反升，比两端均值还高出0.015。

这个结果其实不难理解。ANTMAN不是把整个信息空间一股脑塞进模型上下文里，而是针对每个具体的未解决需求，只调取相关领地里的局部内容去搜索。证据在整个信息空间里的物理位置，对这种局部化搜索机制来说几乎是无关紧要的，因为模型看到的从来不是"全文中间那一段"，而是"和当前需求最相关的那一小块"。

这就像你去超市买东西，如果你是被塞进一整车货物里被动地一件件翻找，货架越长你越容易在中间那段走神漏看。但如果你手里拿着购物清单，直接去货架上标注好的那个位置取货，货架的长度本身根本不影响你能不能找到清单上的东西。

写在后面

读完这篇论文，最触动我的其实不是那个16倍对1.23倍的漂亮数字，而是那个"活跃协调量随空间近乎不变，但随信息需求线性增长"的对照实验。这两个数字放在一起看，才真正说明问题不是ANTMAN在偷懒省成本，而是它把协调开销这件事，第一次跟"任务本身需要多少"而不是"环境有多大"挂上了钩。这是个很细微但很关键的区别。

另外一个让我意外的细节是ANTMAN-H的表现。用8B小模型执行任务，却能保留大模型89%到98%的性能，尤其是在GAIA上几乎没有损失。这说明很多时候限制系统能力上限的不是单个模型够不够聪明，而是整个系统有没有把资源用在刀刃上。这跟很多人默认的"模型越大越好"的直觉其实是有出入的。

论文里也留了个没完全说清楚的问题：需求图的更新和一致性判断，目前是靠大模型自己做的，这套判断本身有多稳定、会不会在更复杂的任务里因为判断失误而漏掉或错误合并某些需求，论文没有做特别系统的压力测试。这可能是个值得继续追问的方向。

Q&A

Q1：ANTMAN是什么？

A：ANTMAN是一种多智能体协调框架，核心思路是让AI系统根据当前还未解决的信息需求来动态决定搜索方向和调度哪些worker，而不是按照信息空间的物理分区来分配任务，从而避免协调开销随信息量线性膨胀。

Q2：ANTMAN和LongAgent、CoA这类方法比有什么优势？

A：在信息空间扩大16倍的情况下，ANTMAN的活跃协调量只增长1.23倍，推理成本增长6.9倍，而LongAgent和CoA的协调量增长超过15倍，成本增长14到16倍，同时ANTMAN的答案质量更稳定更高。

Q3：ANTMAN用小模型执行任务效果会不会打折扣？

A：论文测试了用Qwen3-8B替换所有执行层模型的ANTMAN-H版本，结果在RepoProbe、SWE-QA-Pro、GAIA三个基准上分别保留了完整版89.2%、93.5%、98.3%的性能，损失并不算大。