为什么推理扩展的终点是智能体集群：从上下文压缩到多智能体系统

或者说，为什么推理扩展最终会走向多智能体

2026年10月6日

A swarm of agents asking each other questions directly; the ones that answer them turn into specialists.

让我们从一件所有人都应该能达成共识的事情开始：推理扩展是有效的。事实上，它有效到 LLM 如今能够做出令人惊叹的壮举，比如可信地宣称自己解决了一个千禧年大奖难题——在我们发现推理遵循扩展定律之前，这看起来简直荒谬。在测试时给模型更多算力（让它思考更久、调用更多工具、检查自己的工作），它在任务上就会表现得更好。但只有一个问题：最终，你的上下文会用完。

我是说字面意义上的：你会填满预定义的上下文窗口。¹ 上下文窗口也一直没有变得更大：当前的前沿模型都止步于约 1M token。比如，你看不到任何正经模型拥有 100M token 的上下文窗口。然而，如今的智能体经常执行那些仅凭 1M token 上下文本应无法解决的任务。这怎么可能？

如果你在过去一年里用过编程智能体，你就已经知道解释这一差异的魔术了…… 压缩！

压缩

An agent fills its window, compacts it to a summary, and keeps going

压缩是这样运作的：一旦你接近上下文窗口的末端，你就让智能体写一份摘要，并把它的工作交接给一个全新的上下文，在那里这项工作被继续推进，直到上下文窗口再次被填满，你又得再次压缩。你一直这样做，直到（智能体认为）任务被解决。

压缩非常了不起。它让你可以让同一个智能体会话持续数天（或数周）而不会耗尽上下文。问题解决了，无限上下文，无限推理扩展，一切皆有可能。那我为什么还要写这篇博客文章呢？

嗯……压缩实际上并没有给你无限上下文。它做的是另一件事。一件更微妙的事。它提升了模型的所谓总上下文容量²，粗略地定义为模型能够承担的最大任务，而任务的大小就是一次性完成它所需的窗口大小。压缩能超出模型预定义上下文窗口多少，取决于智能体已经完成的工作中有多少必须在每次交接中存活下来。

这一局限背后的基本原理是：每一次压缩都是一次下注。做摘要的智能体必须现在就决定什么在之后会重要。通常它猜得足够准，³ 但有些任务比另一些更不容出错。⁴ 大多数真实任务也是部分可观测的，所以你看到的东西是否重要，往往取决于你还没看到的东西。正如那句老话所说，“做出预测很难，尤其是关于未来的预测”。⁵

让摘要损失更小（或者用我们的术语来说，提升总上下文容量）的一种方法是让智能体使用文件系统或 REPL 来卸载记忆。例如，智能体可以把某个复杂工作流的细节写到磁盘上，并在摘要中放一个指向相关文件的指针。

这其实帮了大忙！没有任何东西会在压缩的摧残中丢失。摘要只需要说明东西在哪里。所以我们的赌注变得没那么可怕了：问题过去是“我需要记住什么？”，现在变成了“我需要知道什么东西存在？”这让人想起那句名言：“绅士不必懂拉丁语，但他至少应该已经把它忘掉了。”⁶

但这仍然是一场赌注，而且伴随着新的代价。磁盘上的文件本身什么都不做；它们只是静静地待在那里。⁷要让这些东西发挥作用，下一个智能体必须（a）意识到它与当前任务相关，（b）去找到它，（c）把它读回自己的上下文中。最后一步相当烦人，因为读取会消耗上下文，而上下文正是我们一开始就快要用完的东西。⁸

换句话说，卸载到磁盘让我们能够持久保存信息，但上一个上下文窗口中的智能体通过阅读全部内容所理解到的东西已经消失了，每当有人需要时都得重新构建。

那么我们完蛋了吗？也许吧。但我们还有几招没使出来。

多智能体系统

首先，注意我们可以把压缩看作一个（退化的）多智能体系统：⁹每次压缩都会启动一个新的智能体，其初始上下文是上一个智能体摘要的函数。

第二种多智能体系统是一个主智能体协调若干子智能体。思路很简单：主智能体启动一个全新的智能体并给它一个任务（“找出重试逻辑在哪里”、“弄清楚这个测试为什么不稳定”），然后拿回一个答案。子智能体可能会烧掉 20 万 token 去读文件、跑东西。主智能体的上下文只增加了任务和答案，可能也就几千 token。

现在有趣的部分来了。在我们的框架里，子智能体的答案就是……它上下文的摘要。所以子智能体实际上也是一种做压缩的方式！但有一个关键区别：摘要是在问题已知之后才写出来的。压缩必须猜测什么以后会重要。卸载给子智能体则不需要猜测，因为你是在需要的时候才启动子智能体。¹⁰

额外的好处是，如果你有几个独立的问题，可以同时启动多个子智能体。并行是个不错的附加优势，但即使它们必须一个接一个地跑，出于上述原因，子智能体在这些任务上仍然会胜过压缩。（这一点后面会很重要。）

子智能体特别适合那些可以分解为子任务、且在交接和交付时有清晰边界的工作负载。对于这类任务，它们提升的总上下文容量远超压缩，因为主智能体永远不必持有中间那段混乱的部分。

但子智能体也并非没有缺点。它们有和磁盘相反的问题：它们会忘掉一切。子智能体一旦给出答案，它就消失了，连同它那 20 万 token 的读代码、跑测试、排除各种可能性的经历一起消失。下次你有相关问题时，你得启动一个新的，它会把那些阅读工作全部重做一遍。你也没法在十轮对话之后追问它，比如“等等，你刚才那话是什么意思？”

所以现在我们有了两个半吊子解决方案。卸载到磁盘能记住，但不能思考。子智能体能思考，但不能记住。嗯。

雇佣子智能体

你大概能看出这要往哪儿去了。第四个角是显而易见的那一个：就……别杀掉子智能体。把它留在身边。必要的话就雇佣它。就是别把它拆掉。

持久化子代理会保留其上下文（以及它的文件，还有它留下的任何正在运行的东西）。当你对它处理过的某件事有新的问题时，你直接问它就行。它已经读过了所有内容，所以不必从头开始，而你自己的上下文只会因问题和答案而增长。

现在我们两全其美。像磁盘一样，什么都不会丢失。像子代理一样，摘要会在你知道自己需要什么之后才写出来。与两者都不同的是，你明天可以带着不同的问题再问一次。这意味着压缩不再是一次性的赌注。你永远不必预先决定要保留什么，因为你总是可以回来再问。

现在回到我们那个退化的多代理系统。压缩是一连串代理串联工作，每一个都依赖于前一个，而且在任何时刻只有一个“活着”。任何没能进入摘要的内容都消失了，因为知道它的那个代理已经没了。

有了持久化代理，多个代理可以同时存活。当然，它们也可以同时运行：把问题拆成子问题，并行解决，更快完成。¹¹这是支持多代理的显而易见理由，¹²而且确实如此。从基础设施的角度来看，有很多很好的理由说明这为什么重要。但即使它们必须轮流来、一个接一个，它们的上下文仍然会并排存在。它们也是在上下文上并行的，而这正是如今讨论不足的地方：总上下文容量增长到（大致）每个代理一个窗口。¹³

当然，这些代理中的每一个仍然可以压缩！一个已经工作了一段时间的子代理可以总结并继续，就像之前一样。所以两者很好地叠加在一起：压缩让每个代理沿时间方向延伸，而更多代理让整个系统向侧面延伸。你最终得到几条并排的链，它们可以互相提问。

天下没有免费的午餐

让我们先退一步看。这些技巧实际上都在做什么？压缩、卸载到磁盘、子代理、持久化代理：它们都是构建上下文的方式。在理想世界里，你已经在单个窗口中拥有恰好正确的上下文，只需让模型吐出答案（或采取正确的行动序列）。¹⁴在实践中，模型必须自己构建它。推理通过思考来构建它，代理通过行动（读文件、跑测试）来构建它，而上面所说的一切都是关于构建比单个窗口能容纳的更多上下文。

一旦代理在现实世界中行动，构建上下文就是推理扩展的主要形态。这也是为什么我强烈反对像许多人那样把多代理称为“新的扩展轴”。我们仍然在扩展推理计算，只是以一种更有结构化的方式在做。

当然，天下没有免费的午餐。代价是通信。每当一段上下文需要从一个代理传到另一个代理时，它都必须被压缩进一条消息里，这既消耗 token，本身也是有损的。¹⁵如果一项任务最难的部分需要所有东西同时集中在一处，那么把它拆开根本无济于事。

需要明确的是，这一切都不会让我变得不那么乐观。OpenAI 刚刚让 10,000 个智能体解决了纳维-斯托克斯方程。¹⁶ 两年前，你很难找到一个理智的人会认为这会发生。但集群并非万能灵药。你不能只是把一百万个智能体扔向一个难题，然后指望答案自己掉出来。首先，智能体本身必须足够好——而且要好到能够自我组织、有效协调，而不仅仅是重复劳动。诚然，很多开销可能可以通过训练消除（那些擅长与成千上万个自身副本协作的智能体），但有些通信成本是结构性的。

从树到集群

到目前为止，一切都是树状的：一个根智能体生成子智能体，子智能体再生成自己的子智能体，结果向上回流。但一旦智能体可以互相发消息，树就会把每一次对话都路由经过根节点。根节点的上下文会被填满，所以它必须压缩，然后……我们又回到了起点，只是上升了一个层级。树把上下文问题转移到了根节点。

显而易见的解决办法是让兄弟节点直接对话。但一旦兄弟节点可以联系任何需要的对象，你就得问：根节点到底是干什么用的？没有人需要为了完成工作而听命于上级。不如让它们全都成为对等节点。

所以：没有根节点。你把若干个智能体放进一个共享世界，让它们作为网状结构中的对等节点彼此协调。就像每个智能体仍然可以压缩一样，每个智能体也仍然可以生成自己的子智能体。所以你可以在网状结构内部拥有树。

这没问题。去掉根节点并不意味着层级结构毫无用处——毕竟公司仍然有 CEO。科斯在近 90 年前就问过这个问题：如果市场如此擅长协调，为什么还会存在企业？¹⁷ 他的答案是：因为利用市场并非免费。每一次，你都必须找到合适的人，解释你想要什么，并就条款达成一致。而在企业内，有人可以直接决定。所以，企业恰恰存在于这种协调方式比平等协调更便宜的地方。智能体也是如此：从没有层级开始，在能带来收益的地方再添加一点层级。

这种方法奏效的原因之一是专业化。在集群中，没有人需要分配角色；角色会自然形成。假设某个智能体碰巧先看了前端。现在它在那里有了上下文，也许还构建了一个小工具。于是下一个前端问题就会交给它，因为这比其他人从头开始更便宜，而它回答的每个问题都会让它在前端工作上更擅长一点。一个随机的早期差异会随着时间推移固化为一个角色。

这正是树结构真正有害的地方。下两级的子智能体受制于其父节点：它只为生成它的那个智能体工作。所以，如果我们的前端专家位于某个分支，而另一个分支中的智能体有一个前端问题，它不能直接去问。问题必须向上传到它们的共同祖先，再向下传回来，途中经过那些完全不关心前端的上下文。

所以树结构有两个选择，都很糟糕。要么每个分支都培养自己的前端专家，于是我们又回到了反复重新发现同样东西的老路（而这正是持久化本应解决的问题）。要么其他分支没有这个专家，于是专家学到的一切永远只能帮助一个分支。而在网状结构中，任何人都可以直接问它。它的上下文会被任何需要的人复用。

代理越多，这个问题就越严重。有10个代理时，树状结构大概还行。但如果有10,000个，让它们彼此发现并自行分工的同伴网络就合理得多。¹⁸

经济学家们在约80年前就有过这场争论。哈耶克的观点¹⁹是：中央计划之所以失败，是因为运行一个经济体所需的知识分散在数百万人手中，无法全部汇集到中心。根代理就是一个中央计划者。要规划得好，它需要全部上下文，而全部上下文恰恰是装不进一个窗口的东西。（要让这个类比成立，集群并不需要价格或市场。关键在于知识存在于何处，以及谁有权据此行动。）

集群应该是什么样子？

现在，我还不知道正确的结构是什么。纯粹的网状结构大概也不是答案。我的猜测是，我们先照搬人类组织的方式。给代理们我们使用的工具（共享的git仓库、问题跟踪器、Slack），让它们对共享状态有结构化的访问，这个共享状态可以作为唯一的事实来源。正确的结构可能还取决于规模：一个五人的初创公司靠几个Slack频道就能运转，而一个10,000人的公司则不行。布鲁克斯定律之类。²⁰

但关键在于：我们甚至不必锁定结构。我们可以让代理们自己改变结构，这样我们就能把苦涩的教训重新引入进来。²¹所以我们可以用人类的结构来播种集群，然后让代理们在解决手头问题的过程中对它加以改进。

关于如何构建代理集群，还有很多可说的，但我留到下次再说。

感谢Sebastian Müller和Sami Jaghouar的校对和宝贵反馈！

不要与上下文腐烂混淆：那是指代理随着上下文填满而表现变差，因此“有效”上下文窗口（代理表现达到峰值的窗口）比宣传的要小。 ↩︎
这是我编的。如果你有更好的名字，或者已经以别的名字发明了这个概念，告诉我（我不在乎）。 ↩︎
根据我的经验，对大多数任务来说，100万token的工作上下文可以很好地压缩到16k token。 ↩︎
想想一次漫长的调试过程：第一天，一次不稳定的测试运行打印出一行奇怪的内容，你把它当作噪声忽略掉，于是摘要把它丢掉了。这个不稳定现象再也没出现过。到了第三天，那行内容本会是整个bug的关键，但没人记得它存在过。注意，更聪明的摘要器在这里也救不了你：在第一天，根据当时任何人所知，丢掉那行是合理的判断。 ↩︎
通常归功于尼尔斯·玻尔或约吉·贝拉，但它似乎是一句古老的丹麦谚语。最早的印刷版本见于Karl Kristian Steincke 1948年的回忆录。 ↩︎
通常归于Brander Matthews。塞缪尔·约翰逊在1775年更直白地表达了同样的观点，据詹姆斯·鲍斯韦尔记载：“知识有两种。要么我们自己懂一个主题，要么我们知道去哪里能找到关于它的信息。” ↩︎
而当它们坐在那里时，世界在继续前进：文件被覆盖，状态发生变化，所以你保存的东西可能悄悄过时。这个问题有它自己的解决办法，而且并不是多代理特有的问题，所以我就说到这里。 ↩︎
还记得那次不稳定运行中出现的奇怪行吗？它现在在磁盘上的某个地方。但第三天的 agent 不知道它存在，更不知道它重要，所以它不知道要去找它，也不知道该 grep 什么。它又回到了阅读。↩︎
多智能体系统有很多种，我们找到了一些不错的抽象来表达它们。这篇文章有更多内容。 ↩︎
它仍然可能误读问题或带回错误的东西。但向一个已知目标压缩比向一个未知目标压缩要容易得多。 ↩︎
当然，是在不违反 Amdahl 定律的前提下。 ↩︎
Noam Brown 在 Dwarkesh Podcast 上称之为“一种并行而非纯串行地扩展测试时计算的方式”。 ↩︎
只要任务能拆分成各部分之间可以通过短消息应付的部分。如果每个部分都需要其他所有部分的完整上下文，那么再怎么拆分也无济于事，你又回到了需要更大窗口的局面。 ↩︎
这假设模型完美地使用其上下文。在实践中，一个小而专注的上下文往往胜过一个庞大而混乱的上下文，但那是我说过要忽略的上下文腐化问题。 ↩︎
这有个花哨的名字叫通信复杂度：当各方各自掌握问题的一部分时，他们必须交换多少信息才能解决问题。 ↩︎
OpenAI 的说法，数学家们仍在验证。 ↩︎
Ronald Coase，The Nature of the Firm（1937）。 ↩︎
人类组织也弄明白了这一点：大公司里的数据库专家会收到来自每个团队的问题。如果他们只能为自己的经理工作，那每个团队都需要一个。 ↩︎
F. A. Hayek，The Use of Knowledge in Society（1945）。 ↩︎
出自 Fred Brooks 的The Mythical Man-Month：给一个已经延迟的软件项目增加人手会让它更延迟，部分原因是沟通路径的数量大致随团队规模的平方增长。 ↩︎
Rich Sutton，The Bitter Lesson（2019）：随计算扩展的通用方法最终会击败建立在人类知识之上的方法。 ↩︎