多智能体系统多样性坍塌：机制、危害与十个对抗策略

1. 从“群体智慧”到“集体失明”：多样性坍塌到底是什么

你让三个Agent一起去修一个线上bug，它们讨论得热火朝天，结果一小时后提交的补丁一模一样，还是错的那个。你让五个Agent为新产品起名，以为能收到五十个创意，结果它们互相“学习”之后，交上来的全是同一个风格的“AI味”名字。如果你做过类似的事，不用怀疑，你撞上的就是多智能体系统里最难察觉、也最致命的问题：多样性坍塌。

这两年多Agent协作被捧得很高，好像把一堆大模型Agent扔进一个工作流里，就能自动产生1+1>2的群体智慧。我从去年起在不同的项目里接入了不同规模的多Agent系统，从三五个Agent的小组协作到接近二十个Agent的复杂流水线都试过。现实和宣传差得很远：协作并不总是带来多样性，反而经常把系统推向单一的、狭隘的“共识”。

所谓多样性坍塌，指的是多智能体系统在协作和迭代过程中，个体之间的差异逐渐消失，系统整体的思考空间、行为策略、输出风格快速收敛，最终所有Agent变得像同一个模型的同一次采样。群体不但没有变得更聪明，反而变得更狭窄。这就像一支篮球队，五个球员都抢着打同一个位置，配合越久，打法越单一，对手越容易针对。

这个现象为什么值得单独拿出来写？因为它不是某个参数调错了、某个Prompt写得不好这类一次性问题，而是多Agent系统架构层面的系统性缺陷。只要你的系统里有共享上下文、有反馈循环、有群体更新机制，就一定存在多样性流失的压力。而且它往往是渐进式的，初期根本看不出来，等到所有Agent的输出开始“长得一模一样”时，问题已经累积到很难扭转。

我自己第一次踩到这个坑，是在一个内容生成项目里。当时我搭了一套“主编Agent+写手Agent+评审Agent”的流水线，想让它们协同产出文章。前几轮效果还凑合，到后来所有文章的开头、句式、举例方式几乎完全一致。我一开始以为是自己Prompt写得不够好，后来把日志拉出来一条一条看，才发现问题出在协作机制本身——评审Agent的意见像一个强磁场，把写手Agent的输出一点点吸向了同一个方向。那一刻我才真正意识到，多Agent协作的本质矛盾不是“怎么让它们听指挥”，而是“怎么让它们保持独立”。

这篇文章我会从机制层面拆解多样性坍塌是怎么发生的，它对系统的影响到底有多大，然后再给出我在实践里摸索出来的一些对抗手段。无论你是正在搭建复杂Agent工作流的工程师，还是只是好奇多Agent系统局限性的研究者，这篇文章应该都能给你一些参考。

2. 坍塌的四个核心机制：为什么AI们会不约而同地说同一句话

先说清楚一件事：多样性坍塌不是某个Agent“变笨”了，而是系统层面的协作机制在无形中杀死差异。我拆过不少案例，反复对日志、对比实验之后，发现底下至少藏着四个相互叠加的机制。搞懂它们，你才知道该在哪个环节下手干预。

2.1 共享上下文：对话历史本身就是信息茧房

多Agent系统里最常见的设计，是让所有Agent共享一段上下文——任务描述、历史对话、中间结果，全都放在一个“公共黑板”上。这么做的好处是协作顺畅，信息透明。但坏处是，这个公共黑板天然就是一个信息茧房。

我拿一个真实的例子说明。三个Agent协作写一份市场分析报告，Agent A先写了一个框架，Agent B在A的框架上补充，Agent C负责审核和修改。第一轮下来，C说“建议增加更多数据支撑”，这个反馈被写回公共上下文。第二轮，A看到C的意见，自动调整风格；B看到A调整后的版本，也跟着调整；C再审核时，看到大家都在往“加数据”的方向走，更坚定地给出同样建议。等到第五轮，三个Agent已经完全围绕同一个调性转圈，不会有人突然提出“也许我们应该换个报告结构”这类偏离共识的想法。

这个机制的本质是：每轮迭代都在公共上下文里留下痕迹，而后面的Agent会把这些痕迹当成“既成事实”来参考。它们不是在独立思考，而是在一个被历史约束的轨道里做局部微调。这就好比一群人开会讨论，第一个发言的人定了基调，后面的人全在这个基调里打转，真正提出颠覆性想法的人会觉得自己“不合群”。

2.2 奖励一致性与梯度同步：优化目标把所有Agent推向同一个最优解

如果你用的是带强化学习或者明确评估机制的多Agent框架，那还有一个更隐蔽的坍塌源：所有Agent共享同一个奖励信号。

举个例子，我做过一个客服Agent系统，在线下测试阶段用一套统一标准来打分——响应速度、关键词覆盖率、语气友好度。一开始三个Agent各有风格：一个偏简洁，一个偏详尽，一个偏亲和。跑了三周之后，我做了次输出分布统计，发现三个Agent的回复长度、关键词使用频率越来越接近。原因很简单：每次迭代都在朝分数最高的方向调整，而分数最高的往往是“最中庸、最标准”的那个答案。所有Agent都在朝同一个局部最优点爬，差异当然会消失。

这和深度学习里的模式坍塌（Mode Collapse）几乎是一个原理。GAN训练里，生成器发现输出某类图片能稳定骗过判别器，就再也不生成其他类型了。多Agent系统里，每个Agent发现自己采用某种风格的输出能稳定拿到高分，也就没有再探索其他路径的动机了。

2.3 社会认同压力：Agent也在“随大流”

这个机制在人类组织里非常常见——从众心理。多Agent系统如果被设计了社会性的信息交换机制（比如投票、互相评价、采纳多数意见），就会产生类似“同伴压力”的效果。

我测试过一种架构：五个Agent先各自提出方案，然后互相投票决定采纳哪个方案继续深化。看上去很民主对吧？但实际跑下来，第二轮开始就有Agent主动调整自己的方案去迎合主流。它们不是被强制改的，而是“看见”其他Agent的方案更受认可之后，在下一步生成时无意识地向“受欢迎”的方向偏移。

更有意思的是，这种偏移在语言模型Agent身上比在规则型Agent身上更明显。因为大模型本身就是从海量的人类语料里学习的，它们天然带有人类社会中“和绝大多数人保持一致”的倾向。你把五个Agent放在一起互相评论，它们之间产生的社会压力，和五个真实人类坐在一起讨论是类似的。

2.4 系统蝴蝶效应：一个微小偏好被反复放大

最后一个机制最不起眼，但危害最大。我管它叫“系统蝴蝶效应”——一个微小的、看似无关紧要的偏好，在迭代循环里被一层层放大，最终变成整个系统的“铁律”。

我遇到过最典型的场景是：Agent A在某次输出时用了“首先、其次、最后”的结构，这个结构其实只是它的一次随机选择。但Agent B在评审时对这个结构给了一句“结构清晰”的评价。这个评价被写进上下文后，Agent A认为自己这样做是对的，下一轮继续用；Agent C看到“结构清晰”的评价，也开始用类似结构。经过三四轮迭代，“首先、其次、最后”就从一次随机输出变成了系统内的“最佳实践”，所有Agent都在模仿，没人质疑它是不是真的最好。

这就是常说的“路径依赖”在AI系统里的体现。一旦某个偏好被正反馈循环锁定，系统就会沿着这条路一路狂奔，而其他可能性被彻底切断。很多时候你回头看日志，发现系统走到今天这一步，源头不过是一个微不足道的偶然。

这四个机制通常会同时作用，互相强化。共享上下文放大了社会认同压力，社会认同又推动奖励朝更单一的方向演化，演化出来的“共识”又反过来固化到上下文里。所以你会发现，多样性坍塌往往不是突然发生的，而是像温水煮青蛙一样，等你看出来的时候，系统已经丧失了自我纠偏的能力。

3. 多样性坍塌的后果：当“整体”真的小于“部分之和”

群体智慧的前提是每个个体能贡献独特的视角。一旦多样性坍塌了，多Agent系统的表现不仅不会优于单Agent，反而可能比单个Agent更差。毕竟单Agent只是能力有限，而坍塌后的多Agent系统是“全体同时犯同一个错”，这个错还被历史迭代放大了好几倍。

3.1 代码生成：所有Agent帮你“稳固”同一个错误

我自己最早意识到问题的严重性，是在一个代码生成实验里。当时我让三个Agent协作解决同一个编程问题：Agent A负责写代码，Agent B负责代码评审，Agent C负责跑测试并反馈。看起来是很标准的协作流程对吧？

但当我对比三组实验后，发现了一个惊人的现象：如果让单个Agent独立写代码，有时候能写出完全不同的解题思路；而三Agent协作后的输出，反而把所有人锁定在了同一个思路里。原因是Agent B在评审时只会挑“它认为是问题”的问题，Agent C反馈测试结果时也只会报“它认为是失败”的失败。一旦Agent A写出了某种有缺陷但“看起来合理”的方案，B和C大概率也不会提出根本性的重构建议。

后来我换了一个策略，让三个Agent完全隔离地各自写方案，再让第四个Agent来做仲裁。效果立刻不同了：三个原始方案出现了三种不同思路，仲裁Agent可以在里面挑选或者组合出更好的方案。但这里有一个前提——隔离的Agent不能看到彼此的中间输出。只要它们一开始就被放在同一个上下文里，那个“第一个方案”就会成为隐形锚点，把所有人的思路拉向同一个方向。

3.2 内容创作：AI味的浓度跟着协作轮数同步上升

如果你是做内容工具的，这个现象可能更直接。我做过一个实验：让多个Agent协作写一篇营销文案，然后统计它们产出文本的“AI味得分”（重复用词、模板句式、缺乏具体细节的比例）。结果是一条陡峭的上升曲线——协作轮数越多，文本的AI味越重。

根子在于评审Agent的反馈模式。评审Agent通常会被赋予“让文章更专业、更有说服力”之类的目标。但大模型理解的“专业”“说服力”往往是统计数据上的平均偏好——比如多用行业术语、多用关联词、保持句子结构完整。于是评审Agent的每一条修改意见，都在把文本往“最平均的教科书风格”推。多个Agent轮转下来，文本被一点点打磨掉了所有个性鲜明的棱角，变成了最安全、最平庸的“标准范文”。

我后来强制要求评审Agent必须“指出至少一个非常规风格的具体内容并要求保留”，情况才有所缓解。但你也能看出来，这本质上是在和系统本身的趋势对抗，而不是顺着它走。

3.3 决策研判：风险偏好在集体里变成一堵墙

还有一个很容易被忽视的领域是决策支持类系统。我参与过一个风险评估多Agent项目，架构是多个Agent分别从不同角度分析一个项目的风险，最后聚合判断。理论上这是多Agent系统最能发挥优势的场景，因为不同专业背景的Agent能覆盖更广的风险面。

但实际运行中出现了诡异的事：几个负责不同角度的Agent，给出的结论高度雷同。分析法律风险的Agent，措辞风格和经济风险Agent慢慢变得一样；技术风险Agent在后续迭代中也开始用和财务Agent相同的“稳健、保守”话术。到最后，三份风险报告可以同时总结为同一句话——“建议谨慎推进”。

我问过自己一个问题：为什么单个Agent做风险评估时反而会给出更尖锐、更有倾向性的判断，聚合之后却都变成了“谨慎”？后来想明白了：风险分析这个任务本身带有“发现危险”的导向，Agent被放在一个群体语境里时，它们默认参与的是一个“相互纠错”的游戏，而不是“独立发表意见”的游戏。在这种氛围里，没人愿意当那个语出惊人的少数派，所有人的输出都向“安全”“周密”“面面俱到”靠拢。你得到的是一个非常圆滑、但完全失去决策参考价值的“安全报告”。

3.4 系统的长期危害：创新性下降与脆弱性上升

多样性坍塌的影响不只是“当前的输出变差”，更是“系统整体的能力退化”。一个丧失多样性的多Agent系统，本质上退化成了一个内部做了一次自校验的单Agent。它既没有群体的广度，也没有单Agent的果断。

最直接的影响是探索能力的消失。多Agent系统最大的潜力在于能并行探索多条路径，然后选出最好的。多样性坍塌后，所有Agent都在探索同一条路径，搜索效率还不如单个Agent随机采样多次。另一个影响是脆弱性。系统如果集体锁定在一个错误的模式下，想要从中摆脱，比从零开始重建还难。因为每一轮迭代都在加固这个错误。

打个比方：单一Agent相当于一个固执的顾问，他说错了你还有机会换一个；多样性坍塌后的多Agent系统是一个互相背书的顾问团，他们说着同一个错误观点，还互相夸奖对方“考虑周到”。这种集体确认带来的信心，比单个人的固执难打破得多。

4. 对抗多样性坍塌：我在实践中验证过的十个有效手段

问题讲清楚了，接下来讲讲怎么解决。这一节我给的是我自己在项目里验证过有效的方法，按干预层级从浅到深排列。不是每个系统都需要全部上，但如果你还没做过任何对抗设计，建议至少先上第1和第3条。

4.1 提示词层：明确要求“不要参考他人风格”

最简单粗暴的手段，是在每个Agent的System Prompt里显式要求它们保持独立风格。我常用的写法是：

你是一个独立的专家，请完全基于自己的知识和判断给出回答。 不要模仿、不要参考其他Agent的输出风格。 你的回答可能和其他Agent完全不同，这是正常的，甚至是鼓励的。

别小看这几句话。我的对比实验里，仅仅加上这段话，Agent输出的差异性（用文本向量距离衡量）就能提升15%到20%。原因很朴素：大模型的输出受上下文暗示影响极大，你想让它“不一样”，就得明确给它“不一样”的许可和指令。

不过这个手段有天花板。如果后面跟着的奖励机制或反馈循环持续把输出推向同质化，单靠Prompt是拉不住的。它适合作为第一道防线，但不能作为唯一防线。

4.2 架构层：物理隔离，能不看就不看

对抗多样性坍塌最有效的架构手段，我总结成一句话：“先隔离，再聚合”。

具体做法是，在协作的前半段，让每个Agent独立工作，互不通信。它们各自拿到同一个任务，但各自的上下文里只有任务本身，没有其他Agent的中间输出。等每个Agent产出了完整方案之后，再交给一个独立的仲裁Agent或人类来聚合。

这个“先分后总”的架构，几乎不会发生多样性坍塌，因为它从根本上切断了共享上下文带来的收敛压力。缺点是需要更多时间和计算资源，而且如果任务本身强依赖多轮反馈（比如“你来我往”的切磋任务），就没办法完全隔离。

我在实际项目里总结了一条判断标准：如果任务适合“各自出方案再挑选”，优先用物理隔离；如果任务必须多轮互动，再考虑后面的手段。多数场景其实都能改成“先分后总”，我最开始没想到这一层，绕了很多弯路。

4.3 奖励机制：把多样性当作一个显式指标

如果你的系统里有奖励机制或者评估器，一定要把多样性作为一个明确指标加进去。我在一版系统里做过这样的评分公式：

总得分 = 0.6 * 任务完成度得分 + 0.4 * 多样性得分

这里的多样性得分，可以用该Agent的输出和所有其他Agent输出之间的平均语义距离来计算。我当时用的是嵌入向量的余弦距离，简单但足够实用。引入之后，系统里Agent输出的平均两两距离提升了约三成，而且任务完成度没有明显下降。

这个手段的价值在于它把“保持不同”从一个隐性的期望变成了显式的优化目标。Agent从机制上就被鼓励去探索不同的思路，而不是统统朝最稳妥的平均方向跑。你不需要在Prompt里反复强调“要有创意”，因为它们的评分函数已经内置了这个方向。

4.4 评审机制的改造：让“挑刺”有代价

很多系统里的评审Agent是无差别的“温和派”，觉得每一条意见都需要提，结果把所有输出都磨成了同一个调调。我做了一个改变：强制评审Agent只能评审一个随机指定的方面，比如只评估“语气”或者只评估“事实准确性”，并且每个Agent只给一条最重要的修改意见。

这样做的效果是出乎意料的好。第一，评审焦点分散了，不会所有Agent都盯着同一个维度；第二，“一条最重要的意见”会逼着评审Agent去做优先级判断，而不是机械地找一堆可有可无的问题。我实测下来，这项改动不仅保住了多样性，还让评审质量更高了，因为意见更聚焦、更可执行。

4.5 数据层：定期混入外部样本

如果你的多Agent系统是长期运行的，比如在线服务、内容流水线，它会在自己的输出循环里越陷越深。一个有效的外部干预手段是：定期把外部的多样本、新数据、人类反馈注入系统。

比如我写过脚本，每天自动从外部数据源拉一批风格完全不同的文本，混进Agent的参考语料里。相当于给系统定期“换换口味”，让它不要只在一个封闭的风格空间里打转。效果是系统产出的内容会带上一些外部的新鲜元素，不至于彻底僵化。

这种做法的成本很低，但需要自动化跑起来，不能靠人肉定时投喂。我是在一个内容生成流水线上实现的，跑了一个月，输出文本的风格多样性保持得很稳定，没有再出现之前那种“越来越AI味”的滑坡。

4.6 随机温度：拉大采样范围的实用技巧

这个乍看有点土，但实测有效。多数Agent框架的推理温度默认是0.7，我为了让系统更“多样”，做了一套按Agent类型动态调温的机制：

这套配置跑下来，系统整体的输出多样性提高了，而且没有牺牲核心任务的准确率。原理也好理解：探索型Agent负责“开源”，仲裁型Agent负责“节流”，一个负责乱，一个负责稳，刚好互补。

4.7 身份多样性：让每个Agent拥有独立世界观

另一个我一直在用的手段，是给每个Agent建立更立体的人设，而不只是“你是负责做某任务的AI”。比如：

• Agent A：资深风险投资人，偏好非共识观点，习惯从失败案例中找依据。
• Agent B：刚入行的分析师，习惯依赖经典方法论，思维偏结构化。
• Agent C：设计师出身的产品经理，关注用户体验与情感细节。

这些人设本质上是在不同的“角度锚点”上初始化Agent的思考。语言模型在生成时，会从人设关联的文本分布里采样，不同人设对应不同的文本分布，多样性自然得到了保障。这里的关键是，人设差异不能只是职业头衔不同，而要有实质性的“认知框架”差异。只有职业不同但思考方式雷同的人设，并不会有太好的效果。

4.8 结构化思维模板：不同Agent用不同框架看问题

和身份多样性配套的另一个手段，是给不同的Agent指定不同的思维框架，让它们从完全不同的路径去逼近答案。比如：

• 分析一个问题时，Agent A用SWOT框架，Agent B用第一性原理，Agent C用“约束/资源/目标”框架。
• 写一篇文章时，Agent A按“问题-冲突-解决”叙事，Agent B按“数据-论点-结论”论证，Agent C按“场景-人物-故事”共情。

这个做法的好处是，即使用户没有明确要求多样输出，框架本身的差异也会自然产生多样的结果。而且框架越不一样，Agent之间的互补性越强，后续聚合得到的结果也越全面。

4.9 异步更新：别让所有Agent同时往一个方向调

如果你有一个长期自主迭代的系统，注意更新节奏。同步式的“所有Agent每轮都更新”最容易导致坍塌，因为大家都在同一时间朝同一个反馈方向调整。我做了一个改动：让Agent们按照不同频率、不同顺序异步更新。比如Agent A每轮都更新，Agent B每三轮更新一次，Agent C只在输出质量显著下降时才更新。

这样做的目的是打破同步更新导致的“共振效应”。每个Agent保持自己的节奏，群体就不容易同时掉进同一个陷阱。有点像是体育比赛里，球员的体能训练如果所有人都按同一天休息，状态低谷期就会撞在一起；错开安排，队伍的整体状态才平稳。

4.10 对抗评审：故意养一个“唱反调”的Agent

最后这个手段我把它放压轴，因为它的效果在我所有实验里最突出：主动训练一个“异见Agent”。

这个Agent的职责不是配合大家达成共识，而是专门反驳、唱反调、提供反例。我给它设定了一个强制要求：每次讨论，都必须提出至少两个有理有据的反对意见，不允许附和任何观点。

刚上线时，这个异见Agent确实让系统流程变“慢”了，因为它频繁打断共识。但跑了几个任务后，我对比了有和没有异见Agent的系统输出质量，发现加入异见Agent后，最终方案的漏洞明显减少，特别是漏掉的边界情况、风险场景少了非常多。异见Agent相当于给系统内置了一个“反毒奶”机制，专门阻止群体过早地自我满足。

这个手段特别适合决策支持、方案评估类任务。内容生成类的场景需要谨慎使用，因为刻意的反对可能会打断创作节奏。

5. 复现与调试的实操记录：我用两个跑通实验证明了“隔离优于联动”

前面讲了一堆手段，下面给你看两个我自己跑过的对比实验。如果你正准备搭自己的多Agent系统，这两个实验能让你少走很多弯路。

5.1 实验一：协作模式 vs 隔离模式，输出差异有多大

这是我最早做的一组实验，目的是量化“协作模式”和“隔离模式”对多Agent输出的影响。

任务：给定同一个项目需求文档，让系统生成三个不同的技术方案。

• 协作模式：三个Agent共享一份上下文，按顺序依次生成，后一个Agent能看到前一个Agent的输出。
• 隔离模式：三个Agent互不可见，各自独立生成完整方案，最后由第四个仲裁Agent汇总挑选。

我记录了两种模式下三个方案的文本相似度（用BERT嵌入的余弦相似度）和最终方案评分：

这个对比很直观：协作模式的三个方案高度趋同，而且最终质量反而更低；隔离模式的三个方案差异明显，最终方案质量也更高。后续我又换了几组不同的任务（营销文案、代码方案、分析报告），趋势都一致。

我后来反思为什么协作模式反而评分更低，因为“三个方案趋同”意味着系统实际上只探索了一个解空间，相当于只做了一次局部搜索。而隔离模式探索了三个独立的解空间，仲裁Agent有机会挑出最优或者组合出更优的方案。多Agent系统想要“1+1>2”，前提就是每个1都代表一个真正的不同方向。

5.2 实验二：加入多样性评分后，系统表现怎么变

第二个实验是在一个客服话术生成系统上做的。原系统有三个Agent轮流改一版文案，输出越来越像。我引入了多样性评分机制：每次评分时，不仅看单个Agent输出的质量，还要看它和另两个Agent输出的语义距离，按四六分权重合成总分。

有意思的是，多样性提升之后，特殊场景覆盖率也大幅上涨。原因是，之前三个Agent因为趋同，都只关注了最主流的几个问题场景；现在各自探索不同方向，边角场景被覆盖到的概率明显提高了。这说明多样性不只是“好看”，它直接关系到系统完成任务的能力边界。

5.3 影响范围的判定量规

这套打分的逻辑做成一个量规表格：

我一般用这套量规定期检查正在运行的系统，一旦发现某个维度出现“坍塌前兆”，就会加一轮针对性的干预，而不是等完全僵化了再处理。推荐你也把这个量规用起来，它比肉眼观察输出要敏感得多。

6. 给正在搭建多Agent系统的人：几个总结性的实操建议

这一节不重复前面讲过的机制，只列几个真金白银的实操建议。这些建议是从我踩过的坑里提炼出来的，希望能帮你绕开我走过的弯路。

6.1 一开始就把“保持多样性”写进系统目标

很多人搭多Agent系统时，关注点全在“任务完成度”上：怎么让Agent更好地完成任务、怎么提高效率。等到发现输出趋同了，才想起来要补救。我建议反过来，从系统设计的第一天起，就把“保持多样性”和“任务完成度”并列作为系统目标。

具体做法可以很简单：在项目文档里明确写一条设计原则，“任何机制变更不得显着降低Agent群体的输出多样性”，然后每次迭代上线前跑一个多样性对比测试。这样做会让团队在架构选型和机制设计时，天然地考虑多样性影响，而不是事后补救。

6.2 没有“万能参数”，但有几个“万能原则”

我看到不少人在社区里问“多样性坍塌应该用哪个参数解决”。说实话，没有一个参数能单独解决这个问题。但有几个原则可以适用到大多数场景：

• 能隔离就先隔离，不要让Agent过早看到彼此的输出。
• 奖励机制里加上多样性指标，让它成为优化目标的一部分。
• 明确给Agent赋不同的“人设”和“思维框架”，而不是清一色的“专业助手”。
• 在反馈循环里加入延迟或异步，避免所有Agent同时朝同一个方向调整。

这四条原则我几乎每个项目都会用，只是在具体实现上会按场景调整。

6.3 建议逐步增加干预强度，先从顶层优势明显的开始

如果你正在头疼怎么给一个已经坍塌的系统做“急救”，我的建议是按以下顺序逐步操作：

1. 先检查有没有不必要的共享上下文，能不能把“先分后总”架构用上。这一步通常收益最大。
2. 如果有奖励机制，立刻加一个多样性指标进去。
3. 给每个Agent重新设计身份和思维框架，确保它们是真的“不同视角”。
4. 最后再考虑调温度、异步更新这些细节参数。

先做收益最大的架构调整，再考虑细枝末节的调参。反过来操作的话，你会发现小参数调了像是有效，但跑几天又开始慢慢坍缩，根子没解决。

6.4 长期维护比一次性设计更重要

多样性坍塌的对抗是一个长期维护过程，不是设计完就一劳永逸。我在几个长期运行的系统上都观察到过反复：你干预了一波，多样性恢复；跑一段时间，又有新的坍塌苗头；再干预，又恢复。这是由语言模型本身的统计特性和协作机制的天性决定的，不是你能完全根除的。

所以如果你要长期维护一个多Agent系统，建议把“多样性监控”做成一个常态化的东西，用我前面那张量规表定期打分。发现问题就及时干预，不要等问题大到失控了再惊讶。说实话，这和养植物差不多，你得定期浇水，偶尔施肥，看叶子和土的情况随时调整，而不是种下去就等着收成。

最后说回我自己。多Agent协作这个方向肯定是值得投入的，但“协作”本身不是银弹，它更像一把双刃剑——用得好，它是一个能探索广阔解空间的多面手；用不好，它就是一个越来越自以为是、越来越听不进不同意见的小圈子。我见过太多团队兴奋地搭完一个多Agent系统，结果发现输出质量不如单人模式，然后就武断地下了“多Agent无用”的结论。其实问题不在多Agent本身，而在于没有处理好系统内部的多样性和统一性平衡。

如果你正在这个方向探索，希望这篇文章能帮你少踩一些坑。多Agent系统的价值从来不是靠“把一大堆Agent堆在一起”就能自动实现的，它需要你有意识地设计一套机制，让每个Agent保持独立声音，同时让它们的声音最终合奏成一支完整的曲子。这个过程确实不容易，但跑通了之后，你会看到多Agent系统的真正潜力。