这项由斯坦福大学人工智能实验室主导的研究，于2026年6月以预印本形式发布在arXiv平台，论文编号为arXiv:2606.10662。研究方向涉及多智能体系统与大型语言模型的协作推理，感兴趣的读者可以通过该编号检索完整论文。

**研究背景：当AI团队变成了一个人的独角戏**

假设你开了一家公司，雇了十个员工同时处理一个大项目。听起来效率很高对吧？但现实却是这样的：所有人完成工作后，都必须把结果交给一个叫"主管"的人，由他来汇总、理解、再重新分配给下一批员工。随着员工越来越多，这个主管开始应接不暇——他不仅成了整个团队的瓶颈，还经常在传递信息的过程中，无意间丢失了一些关键细节。

这正是当前AI多智能体系统面临的困境。当研究者想让多个AI协同处理复杂任务时，他们通常会设置一个"主控AI"来统筹全局：分配任务、收集结果、整合答案，再发布新一轮指令。这种架构被称为"集中式协调"，就像一个只有一个收银台的超市，无论你开了多少个购物通道，最终所有人还是要排在同一条队伍里结账。

斯坦福大学的研究团队认为，这个"主管瓶颈"问题从根本上限制了AI协作的潜力。于是他们设计了一套全新的系统，名为**DELM（去中心化语言模型，Decentralized Language Models）**。在DELM的世界里，没有主管，没有强制汇报，所有AI都是平等的参与者，大家通过一块公共"进度黑板"来了解彼此的发现、避开彼此踩过的坑，同时各自独立地领取并完成新任务。

**一、为什么"主管AI"会成为绊脚石**

要理解DELM解决的核心问题，先得搞清楚传统方案到底哪里出了毛病。

传统的集中式多智能体系统工作方式，本质上是一种"传话游戏"。一个主控AI把任务拆分成若干小块，交给不同的子AI去处理。子AI完成后，把结果交还给主控AI，主控AI再把这些结果综合起来，判断哪些信息有用，然后再告诉下一批子AI"基于这些，你们去做下一步"。

这个过程有两个致命缺陷。第一个是效率问题：随着任务数量增加，所有信息的汇聚和重新分发都必须经过这个中心节点，就像一栋大楼里只有一部电梯，住户越多，等待时间就越长。第二个是信息失真问题：主控AI在整合信息时，不可避免地会做出取舍——可能会无意中软化某个重要约束、忽略某个关键失败，或者错误地理解某个子AI的发现。一旦信息在传递过程中被曲解，后续所有基于这个错误信息做出的决策都会跟着出错。

研究团队举了一个具体例子来说明信息失真的危害。在一个代码修复任务中，某个子AI发现了一个重要约束：在数据库查询中，把两个过滤条件合并成一个会破坏多值关系的搜索语义。这个发现至关重要。然而，当这个信息经过主控AI的"翻译"传达给其他子AI时，原本清晰的"不能合并"的约束，被主控AI重新描述为"对许多使用场景来说合并可以减少连接操作"——一个斩钉截铁的禁令，变成了一个灵活的建议。最终任务失败了，不是因为没有人找到正确答案，而是因为正确答案在传递过程中走了样。

**二、去中心化的核心思路：用公共黑板代替传话筒**

DELM的核心设计理念，可以用"公告栏协作"来理解。

设想一个没有主管的开放式办公室。每位员工从一块公共任务栏上自己领取任务，完成后把关键发现写在公告栏上。任何人在开始新任务之前，都可以先看看公告栏上已有什么进展——哪条路已经被证明走不通，哪个方案已经初步可行，哪些细节需要特别注意。没有人需要向任何人汇报，也没有任何人需要去整合所有人的工作成果，协作通过共享状态自然发生。

DELM正是这种模式的AI版本，它由三个核心组件构成。第一个是**平行智能体（Parallel Agents）**，就是那些独立工作的"员工"，它们可以同时处理不同的子任务，互相之间没有层级关系。第二个是**任务队列（Task Queue）**，就是那块公共任务栏，智能体们自己去领任务，而不是等待主管分配。第三个是最关键的**共享上下文（Shared Context）**，就是那块公告栏，所有已验证的发现都会被压缩成简洁的"摘要条目"写上去，供所有人随时查阅。

整个系统的运作流程可以分为五个环节。首先，系统根据输入任务自动生成初始的子任务列表，放入任务队列。接着，多个智能体并行地从队列中领取任务，读取公告栏上的当前进展，进行各自的推理工作。完成后，每个智能体的输出会被压缩和验证，只有通过审核的条目才能写入公告栏。当任务队列清空后，系统会检查当前进展是否足以回答问题，如果不够，就生成新一轮子任务；如果够了，就基于公告栏上的所有已验证信息给出最终答案。

值得特别注意的是，DELM与另一种看似相似的"点对点通信"系统有本质区别。在点对点系统中，智能体直接互相发消息，信息流动是双向的，也是分散的，容易造成混乱和冲突。而DELM的共享上下文是一个单一的、经过验证的公共知识库，一旦某条信息写入，就对所有人可见，且其内容已经经过严格审核，不会包含未经证实的声明。

**三、不让谣言上公告栏：严格的准入验证机制**

公告栏的价值在于它的可信度。如果任何人都能随意在上面写东西，包括未经证实的猜测或错误结论，那后来的人就无法信任上面的信息，公告栏就失去了意义。这正是DELM设计"准入验证"机制的原因。

每当一个智能体完成任务后，它的输出不会直接写入共享上下文，而是先经历一个"质检"流程。对于推理过程产生的结论——比如一个成功的解决方案、一个被证伪的假设、一个需要后续注意的约束——系统会检查这个结论是否真实地反映了推理过程中发生的事情，而不是被夸大或曲解了。对于来自外部文档或知识库的信息，验证过程更为严格：系统首先确保摘要中的每一条声明都能在原始文本中找到对应的原文支撑，然后再检查从摘要进一步压缩成的简洁条目是否忠实保留了所有关键信息和重要限定语。

研究团队在论文中分享了一个生动的验证成功案例。在一个法律问题中，某个智能体提交了这样一条信息："彭佐伊诉德士古案仅获得条件性确认，惩罚性赔偿从30亿美元减至10亿美元。"问题在于，该智能体引用的那份摘要只提到了"条件性确认与折让"，完全没有提及任何具体的赔偿金额。验证器（一个专门做质检的AI）发现了这个问题，直接拒绝了这条提交，并指出："该声明中称惩罚性赔偿从30亿美元减至10亿美元，但这在引用的摘要中没有依据，摘要仅提到存在折让，未给出具体金额。"智能体在收到反馈后重新生成了不含这个无根据数字的版本，才得以通过审核写入共享上下文。

这个机制的价值显而易见：在集中式系统中，错误可能在整合阶段被引入，且一旦进入主控AI的"记忆"，就会像病毒一样感染所有后续推理。而在DELM中，每条公告栏信息都经过独立核实，后来的智能体可以放心地在这些信息基础上继续工作，而不必担心自己在一座错误信息构建的沙滩上建高楼。

**四、既看大图，又能深挖细节：分层摘要的精妙设计**

公告栏还面临另一个实际问题：如果每条摘要都写得非常详细，公告栏很快就会被塞满，没有人有时间全部看完；但如果摘要太简短，重要细节又会丢失。

DELM用一种三层架构来解决这个矛盾。对于需要处理的长文档，系统会构建三个层次的表示。最底层是**原始文档**本身，完整保留所有细节，但通常太长无法直接放入智能体的工作记忆中。中间层是**参考锚定摘要**，将文档内容拆解为一系列简短的陈述句，每句话都附带一个"地址标签"，指向原文中的具体语句（通过记录该语句的开头和结尾词语来定位）。最顶层是**高度浓缩的简洁条目**，只保留对回答当前问题最相关的核心信息，长度约为100个词元，这是唯一写入公告栏的内容。

智能体在工作时，默认只读公告栏上的简洁条目。当它觉得某个条目可能包含解答问题所需的关键细节时，可以发出"展开"指令，系统就会把对应的中间层摘要加载进来。如果中间层摘要还不够详细，智能体可以进一步发出"深度展开"指令，直接获取原始文档的相关片段。这种"按需加载"的设计，类似于手机应用里的"加载更多"按钮——大多数情况下浏览简短摘要就够了，只在真正需要时才去翻看完整内容，既节省了资源，又不丢失信息。

研究团队在论文中举了一个财务分析的案例来说明这种设计的必要性。某份文档同时包含一份年报中的2024年息税前利润预测区间，以及一份半年度中期报告中更新的、更窄的预测区间。简洁条目只能标注"该文档包含2024年利润展望信息"，无法区分哪个数字是最新的。中间层摘要则可以标记出"中期报告中的预测区间位于第72段第2节"，并明确提示"具体数字需要从原文获取"。最终，通过深度展开，智能体精确检索到了那段原文："我们将运营利润（息税前利润）的展望范围收窄至6.2亿至6.7亿欧元。"如果没有中间层作为桥梁，从模糊的简洁条目直接跳到这个具体数字，几乎是不可能完成的任务。

**五、在软件工程测试中，DELM如何让失败变成共同财富**

为了检验DELM的实际效果，研究团队在两个完全不同的测试场景中进行了评估。第一个是**SWE-bench Verified**，一个软件工程基准测试，包含来自真实GitHub代码库的问题修复任务。测试方式是让AI多次尝试同一个问题（分别尝试2次和4次），看是否至少有一次能给出正确的修复方案。

在这个场景中，研究团队设计了三种对比方案：最简单的是让多个AI完全独立地尝试，互相不共享任何信息；"集中式并行"方案让多个AI同时工作，但每一步的成果都汇聚到主控AI处进行整合再分发；DELM则让所有AI通过共享上下文协调，但没有任何主控角色。

结果显示，使用Gemini 3 Flash作为基础模型时，单次尝试的平均成功率上，完全独立的方案大约在55%左右，集中式并行方案约为56.4%，而DELM达到了65.7%，领先幅度超过9个百分点。当看4次尝试中至少成功一次的通过率时，DELM达到77.4%，而最强的对比方案只有75.1%。更令人印象深刻的是，DELM每个任务的平均花费仅为0.12美元，大约是其他方案的一半。

这种效率提升来自三个具体机制，研究团队通过分析实际运行记录来加以说明。第一个机制是**共享失败**。在独立尝试的场景中，如果一个AI花了大量时间去探索一条错误的路径，其他AI并不知道这条路是死胡同，可能会重蹈覆辙。而在DELM中，失败的探索会被记录为公告栏上的一条"此路不通"信息，后续的AI可以直接跳过这条路径。在一个修复Python`lambdify`函数的任务中，第一个AI尝试修改Python打印层，发现无效；这个失败被写入公告栏后，第二个AI立即转向了另一条路径，找到了真正的问题所在——在`lambdify.py`的第964行，有一段代码手动拼接了元组但遗漏了对单元素元组的特殊处理。第三个AI随即定位了具体缺陷。三个AI配合完成了一个如果各自独立工作可能需要更多尝试才能解决的任务。

第二个机制是**保护约束不被稀释**。前面提到的Django过滤器案例就是最好的例证。在集中式并行方案中，子AI找到的关键约束经过主控AI的重新表述后变成了"建议"，约束失去了约束力。而DELM的公告栏直接记录了"单个`.filter()`调用会破坏多值关系的多词搜索语义"，这条约束被完整保留，后续AI在此基础上找到了正确的解决方案——用`lookup_spawns_duplicates`谓词来判断何时可以安全地进行优化，何时必须保持分开的过滤器。

第三个机制是**紧凑的进度传递**。DELM不是把整个调试过程的每一步都分享给其他AI，而是通过LLM摘要器将有用的发现压缩成一段简洁的"补丁摘要"，包括"修改了哪个文件"、"核心思路是什么"、"用什么证据验证"。后续AI不需要读完整的命令历史和文件内容，只需要读这段摘要就能了解前人的发现并继续推进。这直接将某个任务的花费从0.399美元降至0.125美元，降幅超过68%。

**六、在长文档理解测试中，DELM如何构建可靠的知识全景**

第二个测试场景是**LongBench-v2多文档问答**，包含125个需要跨多份文档进行多步推理的问题，涵盖金融、政府文件、新闻、法律和学术论文五个领域。

在这个场景中，DELM的竞争对手包括直接输入全文让AI一次性回答的基础方案、通过工具辅助进行编程式文档检索的方案，以及ReadAgent（一个也使用摘要记忆的系统，但摘要是有损压缩，且不做准入验证）。

最终结果显示，DELM在四个主流AI模型家族上全面领先。以GPT-5.4为基础模型时，DELM达到了60.1%的平均准确率，而最强基准方案（使用Claude Code进行文档检索）只有54.4%，提升了5.7个百分点。以Claude Sonnet 4.6为基础模型时，提升幅度为5.3个百分点（59.8% vs 54.5%）。以Gemini 3 Flash为基础模型时提升4.4个百分点（61.5% vs 57.1%），以DeepSeek-V4-Pro为基础模型时提升3.6个百分点（67.5% vs 63.9%）。

为了理解究竟是哪些设计起了关键作用，研究团队做了"拆件测试"——分别去掉准入验证和去掉分层摘要，看准确率如何变化。去掉准入验证后，准确率从60.1%跌至55.2%，下降了4.9个百分点，说明未经核实的信息一旦进入共享上下文，确实会腐蚀后续推理。去掉分层摘要（只保留简洁条目而不构建中间层）后，准确率跌至57.7%，下降2.4个百分点，说明中间层在精确定位原文证据时发挥了不可替代的作用。

研究团队还测试了简洁条目长度和摘要模型的选择是否影响结果。关于条目长度，当长度从50个词元增加到100个词元时，准确率从58.3%提升到60.1%；但从100个词元增加到150个词元时，准确率几乎不变（60.3%），说明存在一个"信息饱和点"，条目只要足够捕捉文档的核心相关性就够了，更长并不代表更好。关于摘要模型，研究团队分别测试了一个轻量级的低成本模型（DeepSeek-V4-Flash）和两个高性能模型，结果发现三者的准确率几乎相同（60.1%、60.4%、59.9%），这意味着DELM可以用最便宜的模型来做文档摘要，把计算资源留给真正需要深度推理的子任务，在不牺牲准确率的前提下大幅降低成本。

**七、与代码执行系统的组合：取长补短的混合策略**

任何系统都有其适用范围，DELM也不例外。研究团队坦诚地在论文中讨论了DELM的局限性，并探索了如何通过组合来弥补。

测试使用的第三个基准是**OOLONG**，一个聚焦于数据聚合的长文本推理测试。这类任务的典型形式是：给你一份包含时间戳和用户标注的条目记录，让你统计满足特定条件的条目数量，或者比较不同类别的分布。这本质上是一个需要精确计算的结构化数据处理问题，而不是开放式的语义推理。

在这个场景中，DELM的对手是**RLM（递归语言模型）**，一个让AI通过编写和执行代码来处理长文本的系统。RLM的核心思路是把文本当作数据库，AI可以写代码来过滤、统计、排序和聚合数据，执行结果作为下一步推理的输入。这对于需要精确计数和多条件过滤的任务来说极为有效。

测试结果印证了这种直觉：在OOLONG上，RLM达到56.0%的准确率，而DELM只有53.3%。原因很直接——需要精确统计多少个条目满足三个条件的问题，自然语言推理的可靠性不如一段编写严谨的代码。

然而，在LongBench-v2多文档问答上，情况正好相反：DELM达到57.9%，RLM只有55.8%。这反映了两种系统的根本差异：RLM本质上仍然是集中式的——所有递归子调用的结果最终都要汇聚到一个根进程，由它来协调和整合。这对于数值聚合来说完全够用，但对于需要在多份语义密集的文档中寻找相互印证的证据的任务，集中式整合的局限性就暴露出来了。

研究团队的解决方案是把两者结合：用DELM的去中心化协调架构来管理任务分发和共享上下文，但把RLM作为每个智能体内部的执行引擎。在这个混合系统中，没有主控AI，所有智能体都是平等的RLM实例，它们通过共享上下文互相了解进展，通过任务队列自主领取工作，但在处理具体任务时，使用代码执行来完成精确的数值操作。结果这种组合方案在两个测试上都达到了最佳表现：OOLONG准确率提升到64.0%（比RLM单独提升8个百分点，比DELM单独提升10.7个百分点），LongBench-v2准确率提升到60.3%（比两者单独使用都有提升），同时每任务成本降到了0.40美元，低于RLM单独使用的0.43美元。

**八、这项研究尚未解决的问题和未来方向**

研究团队在论文末尾坦率地讨论了DELM目前的三个主要局限性。

第一个是准入验证本身有开销。每条公告栏信息都要经过审核，这增加了系统的运行成本。虽然研究已经证明可以用轻量级模型来做验证，但如果能进一步开发更快速的规则式检查或专门训练的小型验证模型，系统效率还能进一步提升。

第二个是任务分解的质量直接影响最终结果。DELM依赖智能体自己生成子任务，如果分解得太粗糙，子任务会描述不清；如果分解得太细碎，则会产生大量不必要的并行开销。未来一个有趣的研究方向是训练能够根据共享上下文的当前状态动态决定"何时拆分、何时合并、何时终止"的自适应智能体。

第三个是提示词的可移植性问题。不同的AI模型家族对提示词的敏感度不同，DELM在某个模型上表现优异的提示词未必在另一个模型上同样有效。将DELM与提示词自动演化方法结合，让系统能够针对每个模型族自动调优分解、摘要和验证的提示词，是一个很有价值的未来方向。

研究团队还特别提到了自动化科研这个应用场景。科研工作恰好同时具备两个DELM最擅长的特征：需要并行探索多条假设，以及需要从大量文献和实验数据中提取互相印证的证据。一个基于DELM的自动化科研系统，可以让不同的AI线程同时阅读不同的论文、分析不同的实验结果，同时通过共享上下文避免重复阅读同一篇文献或重复跑同一个失败的实验，这对于加速科学发现具有相当大的想象空间。

**归根结底，这项研究告诉我们什么**

说到底，DELM揭示的是一个朴素的道理：更多的工人并不等于更高的效率，关键在于他们能否顺畅地共享进展。集中式协调系统把平行执行和信息共享分开了——子AI们可以并行工作，但进展只能串行传递。DELM把这两者统一了起来：工作是并行的，进展的共享也是并行的，且共享的内容经过了严格的质量把关。

这项研究的意义不只停留在AI协作框架的设计层面。它提供了一种关于"可靠知识积累"的思考框架：不是把所有信息都堆进一个全知的中央系统，而是让每一条信息在被纳入公共知识库之前，就已经经过了独立的核实。这种设计理念，在团队协作、知识管理乃至社会信息系统的设计中都有值得参考的地方。

对这项研究感兴趣的读者，可以通过arXiv编号**2606.10662**找到完整论文，标题为"Decentralized Multi-Agent Systems with Shared Context"，来自斯坦福大学人工智能实验室。

**Q&A**

Q1：DELM和传统多智能体系统最大的区别是什么？

A：传统多智能体系统依赖一个主控AI来分配任务、汇总结果，所有信息必须经过这个中心节点，容易造成效率瓶颈和信息失真。DELM去掉了主控AI，改用一块所有智能体都能读写的公共"进度黑板"来协调，智能体自己领取任务、自己把发现写上去，但写入前必须经过严格的事实核查，确保公告栏上的信息可靠。

Q2：DELM的验证机制具体是怎么工作的？

A：每当一个智能体完成任务想要写入共享上下文时，系统会先审查这条信息是否有原文支撑。对于文档内容，要求摘要中的每条声明都能在原文中找到对应的原句；对于推理结论，要检查它是否忠实反映了推理过程中的真实发现。通过审核才能写入，不通过则退回修改或直接删除不支持的声明。

Q3：DELM在哪些任务上表现不够好？

A：DELM在需要精确数值计算的聚合类任务上表现不如代码执行系统。比如统计满足多个条件的条目数量这类问题，自然语言推理不如编写代码来得可靠和精确。对此，论文提出了将DELM与递归语言模型RLM结合的混合方案，在保留去中心化协调优势的同时，利用代码执行来完成精确计算，结果比两者单独使用都更好。