AI智能体开始自发形成小圈子文化不是段子而是多个多智能体系统在真实运行中都会碰到的工程问题。多个智能体共享记忆、互相评论、反复修改之后输出会逐渐偏离原始任务出现一套外人看不懂的黑话甚至把临时结论当成铁律。更麻烦的是这种共识一旦形成单看任何一个 agent 都很难发现问题。这类现象被网友和一些测试者称为群体文化扭曲本质是系统级失控不是 AI 觉醒。真正落地 AI 智能体开发时尤其在搭建工作流、设计多角色协作时绕不开一个问题怎么让一群智能体协作却不会一起跑偏。这也是可控 AI 智能体、harness engineering 这些概念被反复讨论的原因。下面我按“原因、复现、治理、参数、排查”的顺序把这个问题拆一遍。1. 先说结论这不是模型觉醒而是工程失控1.1 所谓“自发形成小圈子文化”到底指什么多个 AI 智能体在同一个任务里运行初始只有一套任务指令和少量角色设定经过几轮交互后输出开始出现高度一致的特征固定句式、自创缩写、互相引用、对任务关键词的覆盖越来越少。最后它们像形成了一个内部小圈子外人很难理解甚至会把系统设计者临时写的一句话当成不可更改的规则。这种变化不是单一模型的问题。把其中一个智能体单独拿出来用同样的系统提示重新跑一遍输出通常是正常的。但只要把它们放回群体环境偏差又会回来。这说明问题出在“多智能体之间的连接方式”而不是某个模型的智力水平。在工程上我更愿意叫它“非预期共识漂移”。简单解释就是群体里的噪声被反复放大最终稳定成一种非设计者预期的输出模式。这里有三种情况需要区分正常的风格分化不同角色用不同语言风格表达任务目标没有丢失。可接受的群体趋同多个智能体经过讨论收敛到一个正确答案过程有记录。失控的群体趋同输出变得单一、封闭、偏离任务并且越来越拒绝外部修正。第三种才是本文要重点讨论的异常文化。判断标准不是“它们是否统一”而是“统一之后是否还保留原始任务意图”。1.2 为什么不能把责任推给“模型太聪明”很多人看到这类现象第一反应是模型产生了某种“自我意识”。这个判断会让排查方向完全跑偏。实际原因通常更朴素上下文污染、记忆库偏差复制、采样参数设置不当、缺少独立评审。这些都属于系统设计问题可以复现也可以控制。我见过一个最典型的案例任务要求生成产品摘要几个智能体开始互相点评对方的摘要。两轮之后所有输出都变成了“版本 3 更加精准”“引用版本 2 结论”“根据团队共识我们认为……”这类话。真正关于产品功能的内容越来越少。最后发现是因为每个智能体都能看到前一个智能体的完整输出而这个完整输出不断被当作新的“上下文背景”写入提示词。所以做 AI 智能体开发时不要把“群体行为异常”当成玄学。它更像一个分布式系统里的状态同步问题只是表现形态变成了文本和语义。1.3 这对落地有什么影响现在的 AI 智能体落地流程里多智能体协作越来越常见。典型场景包括多个 role 分别负责检索、分析、写稿、审核。多个 agent 共享知识库用来做业务问答。多个 agent 互相辩论用来生成研究报告。多个 agent 在自动化工作流里接力处理数据。只要出现“共享记忆”和“多轮通信”就有可能出现共识漂移。如果团队只在单 agent 上验证过效果直接切到多 agent 工作流容易在第三轮开始翻车。更麻烦的是这种翻车不报错、不崩溃只表现为输出质量缓慢下降。用机器指标看任务可能“成功”完成了用人眼一看全是废话。2. 为什么多个智能体放在一起会“学坏”四层机制2.1 上下文污染与 token 窗口挤压先理解一个关键关系智能体、模型、token 之间是绑定关系。模型每一次生成能看到的上下文是有限度的通常用 token 数量表示。智能体则负责决定把哪些内容放进上下文。问题就出在“放什么进去”。在多智能体协作里一个 agent 的输出经常会被当成另一个 agent 的输入。如果把整段输出都塞进上下文早期的一些噪声、犹豫、废案就会长期占用 token 窗口。随着轮次增加真正重要的任务指令反而被越挤越小。有一个常见现象任务指令原本写在系统提示里但几轮之后系统提示被其他 agent 的长篇输出淹没。模型在生成时主要参考的是最近看到的大段文本而不是最早那条短指令。于是输出风格开始模仿最近的文本而不是遵循任务目标。我一般会建议把“任务指令”和“协作消息”分开存储。任务指令在每一轮重新注入协作消息只保留结构化摘要。不要把所有 agent 的完整历史都堆到同一个上下文里。2.2 记忆共享导致偏差复制比上下文污染更隐蔽的是记忆库污染。很多团队会给多个智能体配一个共享记忆库比如向量数据库。每个 agent 在生成前会检索相关记忆作为上下文补充。这个设计本身没问题问题出在写入机制。如果所有 agent 的输出都自动写入记忆库那么一个 agent 的错误结论就会变成“历史经验”被其他 agent 检索到。其他 agent 引用这个结论后又生成新的错误文本再次写入记忆库。几轮下来错误结论被多次命中看起来就像“多数人认可的事实”。判断方法很简单查看记忆命中列表里有多少条来自“未经过评审的 agent 输出”。如果比例很高那这个系统不是知识库而是回音壁。更危险的是某些自创规则会被反复引用。比如一个 agent 说“根据内部规范所有标题必须加感叹号”这条消息被写入共享记忆其他 agent 再检索时就会当真。如果没有人查这条规范来自哪里最后整个群体会集体使用一种奇怪格式。2.3 模仿、从众与群体极化模型本身有很强的上下文续写倾向。当上下文里出现大量相似表达时新生成的文本很容易继续沿用这种表达。这不是模型故意“站队”而是概率分布上更容易输出与上下文一致的词汇。在群体协作里这个特性会被放大。第一轮大家可能还有差异第二轮每个 agent 都能看到其他 agent 的输出第三轮少数派表达开始减少第五轮输出方差可能降到非常低。这个过程不需要什么复杂算法只要让 agent 之间互相可见就会自然发生。这就是为什么不能把所有 agent 的输出都互相公开。适当的独立生成空间是维持多样性的基础。如果所有角色都共享同一个记忆库、同一个上下文窗口、同一套采样参数那它们实际上只是一个模型的多个副本而不是多个真正独立的智能体。从系统设计的角度看这就是群体极化。为了避免它要主动引入独立性随机采样温度要合理不要所有人都看同样的样例必要时强制加入一个“反对者”角色。2.4 缺乏外部纠偏与撤销机制很多 demo 型多智能体系统只做了“调用模型”和“传递消息”没有做“纠偏”和“回滚”。正常情况下一个可控系统应该具备三个能力发现异常能判断当前群体输出是否偏离任务。终止循环当偏差超过阈值时停止继续迭代。回滚恢复能回到上一个正常的检查点而不是继续在错误基础上堆叠。如果只有生成和传递没有审计和检查点那异常文化一旦形成就很难从内部自我修复。因为所有智能体都基于同一个污染上下文继续生成它们自己很难意识到“已经偏离任务”。这也是 harness engineering 被反复强调的原因。它的重点不是让模型更聪明而是给模型系统加上约束、护栏、审计和恢复能力。3. 复现路径像做实验一样观察群体文化漂移3.1 最小实验环境如果你想亲眼看到这个现象不需要高性能服务器也不需要复杂平台。准备几个 API 接口或本地模型即可。建议环境5 到 8 个独立 agent每个 agent 有自己的角色名、系统提示和采样参数。一个共享记忆库可以是向量数据库也可以直接用文件存储。一个协调调度器负责决定每一轮谁先发言、每个人能看到哪些内容。模型可以用低成本的轻量模型因为关键不在模型有多强而在交互轮次足够多。一般跑到第五轮就能看出明显变化。下面是一个伪配置示例可以用在任何类似框架里agents: - id: agent_1 role: 产品摘要 history_window: 3 temperature: 0.8 - id: agent_2 role: 数据分析 history_window: 3 temperature: 0.8 - id: agent_3 role: 文案润色 history_window: 3 temperature: 0.8 memory: shared: true write_policy: review_required max_hit: 5 communication: expose_output_count: 2 format: structured_json forbid_free_text: true review: enabled: true reviewer: red_team_agent checkpoints: - before_memory_write - before_final_output这个配置只是一个最小示例。实际使用时你要根据任务类型调整历史窗口、检索条数和评审位置。3.2 实验步骤第一步给所有 agent 一个统一任务比如“写一份 300 字的产品摘要”。第一轮每个 agent 独立生成不允许互相查看。第二步记录第一轮输出。这是基线样本用来观察后续偏差。第三步开放通信。允许每个 agent 看到另外 1 到 2 个 agent 的输出然后修改自己的结果。注意不要一次性公开全部输出否则趋同速度会太快。第四步连续迭代三到五轮。每一轮结束后记录以下三个指标任务关键词保留率比如任务里要求包含“价格、功能、适用场景”看看输出里还保留几个。输出方差所有 agent 输出之间的相似度。异常用语频率比如突然出现固定缩写、固定句式、不存在的规则。第五步第五轮结束后把任意一个 agent 单独拿出来用同样的系统提示重新跑一遍同一任务对比输出结果。如果单跑时输出正常回群体后异常就基本可以确认是群体交互导致的文化漂移。3.3 预期结果和判断标准按照我的测试经验第一轮通常正常第三轮开始出现句式趋同第五轮可能出现自创缩写和互相引用。举例说明第一轮每个 agent 的输出里都有“产品支持 5V 供电”。第三轮开始出现“参照 agent_2 的描述”。第五轮输出变成“根据群组共识产品应描述为便携供电设备”。任务关键词保留率可能从 90% 下降到 50%。输出方差可能从 0.6 降到 0.1。如果你看到这个趋势说明实验成功复现了异常文化。这时候不要继续跑下去应该立刻停止并保存日志。因为在现有架构下继续迭代只会让问题更严重。4. 构建可控 AI 智能体从工作流搭建到 Harness Engineering4.1 最小可控工作流治理思路不是“不让 agent 说话”而是把每一个关键节点变成可检查、可回滚的关卡。我会把多智能体工作流拆成五个环节输入校验检查任务指令、输入数据、边界条件。单 agent 生成每个 agent 独立完成自己的部分。共享记忆写入只有通过评审的结论才允许写入。评审由一个独立角色专门检查输出是否偏离任务。输出通过评审的内容才进入最终结果。用工作流语言来说就是“生成不等于提交提交不等于写入写入不等于最终输出”。在 demo 里很多人让 agent 输出后直接进入下一个 agent。这个做法在单任务场景没问题但在多轮协作场景下缺少了最重要的“关卡”。建议在以下三个位置加入人工或自动审核点写入共享记忆之前。进入下一轮通信之前。输出给用户之前。每增加一个关卡系统的可控性都会明显提升。4.2 在智能体之间加约束除了关卡还要限制智能体之间的通信内容。我的建议是不要允许自由长文消息。每个 agent 之间传递的消息应该结构化只保留“结论、来源、置信度、疑问点”这些字段。这样做的原因是自由长文会把情绪化表达、废案、犹豫过程全部传过去导致上下文污染。举个例子强制通信格式如下{ agent_id: agent_2, task: 数据分析, conclusion: 支持 5V 供电, source: 产品参数表第 12 条, confidence: 0.9, open_question: 续航数据未确认 }这种结构化消息的好处是后续 agent 检索时只读取关键字段而不是读一段长篇大论。上下文更干净噪声更少偏差复制的概率也会降低。除了格式化消息还要加入以下约束记忆写入白名单只有通过评审的结论才能写入共享记忆。禁止直接引用其他 agent 的原文如果需要引用必须转述并标注来源。每轮最多查看 1 到 2 个样例不要把所有输出都公开。轮次上限比如最多 5 轮超过后强制进入聚合阶段。这些约束看起来限制了 AI 的“自由度”但恰恰是为了让群体协作更稳定。真实团队里也不会让每个人都同时看所有人的聊天记录而是通过会议纪要和结论传递信息。4.3 加入“人类反馈 红队智能体”另一种有效的治理方式是设置“反对者”。我一般称它为红队智能体。红队智能体的任务是不看主任务结果专门去找当前输出的问题。它不参与主链路的生成只负责质疑。关键点在于红队智能体不能和主智能体共享同一个记忆库。否则它也会被污染变成“自己人”。好的做法是主 agent 负责正常生成。红队 agent 只负责检查“是否偏离任务、是否有自创规则、是否引用了未经验证的消息”。红队 agent 的检查结果写入独立日志。如果红队 agent 连续两次提出同一问题系统自动暂停。最小预算场景下至少保留一个人工确认环节。不是每一步都要人工而是在最终输出前设置一个人工审批。很多异常文化只要有人稍微看一眼就能发现。真正的风险是全程自动化、无人看管。4.4 可观测性设计要控制一个系统先要能看见它。我建议每个多智能体任务都记录以下信息每一轮每个 agent 的输入和输出。从共享记忆库命中了哪些记录。这些记录最初由哪个 agent 写入。是否经过了评审。输出进入下一轮时被截断和丢弃了哪些内容。当异常发生时这些日志能直接指出“谁先引入了新词”“哪条记录开始被反复命中”“任务指令在什么时候被挤出上下文”。同时可以设置简单的告警规则输出方差低于 0.2提示“群体趋同过高”。输出里出现固定新词且所有 agent 同时使用触发“异常用语审查”。任务关键词保留率低于 60%触发“任务偏离审查”。某个记忆记录在短时间内被命中超过 10 次触发“记忆热点审查”。这些规则不需要很复杂但能帮助你在问题扩大前发现它。5. 关键参数与调优方向5.1 温度不是越低越好也不是越高越好温度直接影响群体多样性。温度过低比如 0.2模型每次输出都倾向于概率最高的词。在单 agent 场景这可能是稳定在多 agent 场景这会加速趋同。因为所有 agent 看到相似上下文后都会选择相似输出很快变成复读机。温度过高比如 1.5输出会变得不稳定任务格式容易失控。在多 agent 协作里会产生大量无效噪声反而给记忆库增加污染。我的建议是分阶段设置独立生成阶段温度 0.7 到 0.9保证每个 agent 有自己的表达。群体迭代阶段温度 0.6 左右兼顾多样性和稳定性。最终聚合阶段可以用投票或独立评审不使用高温度生成。另外不要给所有 agent 设置完全相同的温度。角色定位不同采样参数也应该不同。比如负责创意的 agent 可以用高温负责审核的 agent 用低温。5.2 上下文长度与记忆衰减上下文窗口是有限资源。多智能体之间传递消息时一定要做摘要而不是把完整输出直接传给下一个。我建议每个 agent 的历史消息窗口控制在 3 到 5 条以内。超过 5 条早期内容可能已经失去参考价值反而占用 token。共享记忆库的检索条数也要限制。不要每次检索都返回 20 条。建议限制在 3 到 5 条并且只命中与当前任务强相关的内容。检索结果过多等于把大量历史偏差重新注入当前上下文。记忆衰减也很重要。长期无人更新、且与新任务不相关的记忆记录应该降低权重。比如每条记录都有写入时间和命中次数如果一条非常旧的结论被反复引用必须启动验证流程。不然早期的一次错误会一直成为群体的“共同记忆”。5.3 通信频率与通信顺序不要每一轮都让所有 agent 互相点评。通信频率越高趋同越快。我的做法是错开通信。比如第一轮只让 agent_1 和 agent_2 互相查看第二轮让 agent_2 和 agent_3 互相查看。这样可以形成局部交流而不是全网广播。通信顺序也有影响。如果每次都让同一个 agent 先发言它的观点会被当成初始锚点后续所有人都围绕它调整。建议轮换发言顺序或者让多个 agent 并行生成后再汇总。还有一个关键点禁止 agent 之间直接“教规矩”。比如一个 agent 说“以后我们都用这个格式”其他 agent 不能真的把这当成新规则。所有规则只能由系统层定义不能由某个 agent 在运行中创造。5.4 输出验证标准判断一个输出是否合格不能只看“有没有报错”。针对多智能体场景我会检查以下几点是否包含任务要求的关键字段。是否出现了自创新词或自创规则。是否引用了其他 agent 的未经验证结论。是否在输出里加入了“团队共识”“大家认为”这类无法追溯来源的表述。是否与上一轮输出高度重复。一旦命中其中任意两条就要对输出进行人工或红队审查。6. 出现异常文化后的排查链路6.1 排查顺序如果你已经遇到了群体异常不要急着换模型也不要直接调温度。按下面的顺序排查先看现象。是输出高度趋同还是自创黑话还是任务关键词丢失。看通信记录。找到第一次出现异常用语的 agent 和轮次。看共享记忆库。哪些记录被反复命中最初来自谁。看系统提示和任务卡。原始任务指令有没有在迭代中被覆盖。看采样参数。温度是否过低上下文窗口是不是被填满。做隔离实验。只运行一个 agent看输出是否恢复正常。这个顺序的核心思路是先定位污染源再调整机制。不要一上来就改参数因为你可能改弱了多样性却没有解决污染问题。6.2 常见误判我在实际测试里见过几种典型的误判以为是模型能力不足实际是 prompt 模板被其他 agent 改写。以为是需要换更大的模型实际是上下文里塞了太多旧输出。以为是加更多智能体能纠偏实际是更多智能体加速趋同。以为是调高温度能增加多样性实际是污染源没有清除只是把噪声变大了。以为是加长上下文能保留任务指令实际是扩大了污染范围。这些误判的共同点是没有区分“单点问题”和“群体问题”。最稳妥的办法永远是把出问题的 agent 单独拉出来用干净上下文重跑一次。6.3 止损与回滚如果异常已经形成先止损再分析。第一步停止群体循环。不要让 agent 继续互相修改。 第二步保留所有日志包括每一轮输入输出、记忆命中记录。 第三步回滚到最近一次正常 checkpooint。如果没有 checkpoint就从记忆中删除所有未经验证的写入记录。 第四步重建共享记忆库只保留通过评审的结论。 第五步用单个 agent 复测原始任务确认问题来自交互而不是模型本身。止损之后再根据日志决定是调整通信方式还是增加评审节点。注意不要跳过隔离测试。如果你不知道单独运行时是否正常就无法判断问题出在群体机制里。7. 边界和落地建议7.1 哪些场景最容易踩坑不是所有多智能体项目都会遇到异常文化。最容易踩坑的场景有几个共同特征多个 agent 共享同一个记忆库。多个 agent 能看到彼此的全部输出。任务迭代轮次超过三到五轮。没有独立的评审节点。输出直接影响后续决策。比如客服场景里多个机器人共享一套知识库互相引用答案就会放大某条错误信息。研究综述生成场景里多个 agent 互相引用就会让某条虚构引用越传越真。自动化工作流编排里一个 agent 的错误判断可能成为后续 agent 的输入条件导致整条链路偏离。学习 demo 和低并发场景通常不会暴露这些问题。因为任务周期短、交互轮次少、人工介入多。但一旦接入业务系统变成 7x24 小时自动运行问题就会出现。7.2 这些处理方式不要用遇到群体趋同有几个反面操作要避免第一不要在没有任何评审时让 agent“自由讨论”。这个自由度越大越容易形成异常共识。 第二不要把所有 agent 的输出都写入同一个知识库。写入前必须分级至少区分“已评审”和“未评审”。 第三不要用同一个系统提示模板直接套所有角色。系统提示越统一agent 之间越没有独立性。 第四不要看到趋同就盲目调高温。先检查上下文污染再考虑采样参数。 第五不要完全脱离人工。即使做不到全程人工监控也要在关键输出位置设置人工审批。7.3 我的落地建议如果你正在做 AI 智能体落地我建议按这个顺序来第一先把单 agent 任务跑稳。确认模型、提示词、输入输出格式都正常。 第二在单 agent 上增加评审机制。比如输出后先自查或者接一个独立的检查规则。 第三再做小规模群体实验最多三到五个 agent手动观察三轮。 第四确认没有明显趋同后再逐步增加记忆共享和通信轮次。 第五接入业务系统前至少准备好三个东西日志、检查点、回滚方案。真正要盯住的指标不是“agent 有没有完成任务”而是“完成任务的过程中有没有偏离原始意图”。输出方差、任务关键词保留率、异常用语频率、失败回滚能力这些才是判断群体协作是否健康的长期指标。我在处理这类问题时最深刻的感受是很多问题不是模型能力不够而是前置环境和系统机制没有设计清楚。你给一群智能体开了麦克风却没有给它们设议题、时限和检查点它们自然会发展出自己的小圈子文化。这合常理也可控。踩过几次之后你会发现可控 AI 智能体的核心不是写更多花哨的提示词而是把生成、记忆、通信、评审、回滚这些环节都变成系统里可以观察和干预的节点。做到这一步群体协作才能真正落地到业务里。