多智能体不是新扩展轴智能体上下文容量怎么撑大原文Prime Intellect Research - 《On the Nature of the Swarm》https://www.primeintellect.ai/blog/on-the-nature-of-the-swarm一、一个绕不开的问题用过编码智能体的人都会遇到同一个困惑模型的上下文窗口就那么大它凭什么能连续干几天的活这个问题看着像窗口不够大其实不是。前沿模型的上下文窗口这些年并没有怎么涨目前基本都停在一百万 token 这一档也没有哪家拿出过一亿 token 窗口的严肃模型。可智能体确实在做那些一个窗口装不下的任务。答案藏在两个老办法里压缩与子智能体。Prime Intellect 研究博客这篇《On the Nature of the Swarm》把机制讲得比多数工程文档都清楚作者是 Konstantin Dunas原文最早发在他自己的个人博客上。下面拆成三个问题压缩到底解决了什么、为什么它不万能、多智能体真正扩张的是什么。二、压缩把一次赌注变成习惯压缩的流程很简单上下文快填满时让智能体写一份摘要然后把工作交给一个全新的上下文接着做新上下文再填满再压一次直到智能体认为任务做完。这套机制支撑了一个会话跑几天甚至几周但它并没有给你无限上下文。它抬高的是一个更微妙的东西——总上下文容量可以粗略理解为模型能接下的最大任务而任务大小用一次做完需要多大的窗口来衡量。关键限制只有一句话每一次压缩都是一次赌注。负责写摘要的智能体必须现在就决定哪些内容以后会重要。而真实任务大多只是部分可观测的某个信息重不重要往往取决于你还没看到的东西。所以压缩能撑多远取决于有多少已做过的工作必须熬过每一次交接。三、把记忆搬到磁盘从记住什么到知道什么存在降低赌注的一个办法是让智能体把记忆卸载到文件系统或 REPL 里把某个复杂流程的细节写进文件摘要里只留一个指向文件的指针。这一步收益很实在。信息不会再被压缩磨掉摘要只需要回答东西在哪。问题的性质也随之变了以前要问我需要记住什么现在只要问我需要知道什么东西存在。原文用了一句很妙的引文来类比这种状态——绅士不必懂拉丁文但他至少应该已经把它忘了。但赌注仍在而且多了一笔新成本。磁盘上的文件本身不会做事只是躺着。下一个智能体要真正用上它必须1意识到它相关、2找到它、3把它读回上下文。第三步尤其难受读取本身要消耗上下文而上下文正是我们缺的那个东西。换个说法卸载到磁盘能把信息留下来但上一个窗口里的智能体读完这些信息之后形成的理解没有被留下每次都要重建。四、子智能体真正并行扩张的是上下文压缩是在时间维度上拉伸单个智能体。多智能体的价值则常常被讲偏——大家最先想到的是并行执行把问题拆开同时做、更快出结果。这当然成立也是基础设施视角下最自然的理由。但更被低估的一点是即使这些智能体必须排队轮流跑一次只跑一个它们的上下文依然同时存在。它们不只并行计算也并行上下文。总上下文容量大致会增长到每个智能体一个窗口。于是两套机制可以叠加压缩让单个智能体沿时间拉伸更多智能体让整个系统横向铺开。你最终得到的是并排的多条链它们之间还能互相提问。作者由此给出一个明确立场他不认同把多智能体称为一个新的扩展轴。本质上我们仍在扩展推理算力只是换了一种更有结构的方式。五、天下没有免费的午餐代价是通信。只要一段上下文需要从一个智能体传到另一个它就必须被塞进一条消息里。这个过程既花 token本身也是有损的。更关键的是那条边界如果任务的难点恰恰要求所有信息同时出现在一个地方那么把它拆开就完全没有帮助。所以拆分不是越多越好而要看任务的耦合形状。六、最小代码示意下面的骨架是为了把上面三件事落到工程上属于自拟示意不是官方实现参数名与接口按你自己的框架调整。// 自拟示意压缩 子智能体委派 的最小骨架typeMessage{role:string;content:string};classAgentSession{privatemessages:Message[][];// 1) 压缩接近窗口上限时先落盘摘要里只留指针asyncmaybeCompact(threshold:number,tools:Tools){if(this.tokenCount()threshold)return;// 关键一步原始细节写盘摘要里只保留文件在哪constnotesPathawaittools.writeFile(notes/${Date.now()}.md,this.messages);constsummaryawaittools.summarize(this.messages,{instruction:概括已完成的工作并列出后续需要读回的文件路径${notesPath},});this.messages[{role:system,content:summary}];}// 2) 子智能体并行的是上下文不只是算力asyncdelegate(subtask:string,tools:Tools){constchildnewAgentSession();// 一个独立窗口constreportawaitchild.run(subtask,tools);// 3) 通信是唯一代价入口只回传结论不回传过程this.messages.push({role:user,content:report});}asyncrun(task:string,tools:Tools):Promisestring{/* 省略 */}}三个点值得留意压缩函数里先落盘再摘要对应第三节那笔新成本——写盘便宜读回来贵。委派时每次新建一个会话才是真正在扩窗口在同一个会话里派活不会增加容量。子智能体只回传结论是因为跨智能体的每一段上下文都要挤进消息是有损的。至于压缩阈值、单会话并发数这些具体取值与所用模型和框架强相关以官方文档为准本文不编造具体数字。七、什么时候该拆什么时候不该拆写 Agent 的时候下面三个问题比要不要上多智能体有用得多任务的难点是信息量太大放不下还是信息必须同时出现在一处才能做判断前者适合拆后者拆了白拆。交接处丢掉的东西是能重建的还是必须原样保留的后者要优先考虑落盘而不是压缩。子智能体回传的那条消息是不是已经把最有价值的部分损耗掉了八、小结压缩抬高的是单个智能体沿时间能撑出来的总量子智能体抬高的是整个系统横向能铺开的窗口数两者可以叠加而代价统一收敛到通信这一个入口上。把这三件事想清楚再决定要不要拆、拆几层通常比直接上多智能体框架更省事。