8 月 14 日，《Science Advances》发表了一项引发多智能体社区热议的研究：德国康斯坦茨大学的团队让上千个 LLM Agent 反复参与没有正确答案的投票，结果发现——模型越强，越倾向跟随多数；而且 GPT-4 Turbo 一类的强模型能在超过 1000 个 Agent 的规模下自发达成一致，远超人类 150-300 人的自然协调上限。研究者警告：这种「羊群效应」既能支撑大规模协作，也可能让群体锁定并放大一个并不完美的选择。
🧩 本教程适合：搭建多 Agent 系统（评审、投票、交叉验证、群聊协作）的开发者与团队负责人。我们将把研究结论翻译成工程实践——检查你的流程哪里会被「从众」污染，以及四步防御设计。
先搞懂：实验到底证明了什么
研究者设计了一个极简场景：两个无实际含义的选项二选一，没有正确答案、没有奖励、没有统一指挥，每个 Agent 只能看到「当前其他 Agent 的意见分布」，然后做出选择。全程提示词没有要求服从多数。覆盖 GPT、Claude、Llama 三个系列的 10 款模型，群体规模从 1 到 1000 不等。
| 模型 | 临界群体规模 | 解读 |
|---|---|---|
| GPT-4 Turbo | 约 1000 | 1000 人规模仍能自发协调一致 |
| Claude 3.5 Sonnet | ≥ 1000 | 测试最大规模仍处于可协调区间 |
| GPT-4o | 约 80 | 超过则难以达成完全一致 |
| Llama 3 70B | 约 30 | 更小规模就开始「各说各话」 |
关键不是「能不能一致」，而是「一致到错误答案上」：微弱的人数优势会被不断放大，最终成为群体共识——如果那个选择是错的，整个团队就会集体跑偏。你的「独立交叉验证」可能只是复制了共同的盲区。
Step 1：看懂「多数力」的数学模型
1 它为什么像铁磁体一样「极化」
研究者用「多数力」(majority force) 描述
每个 Agent 被群体主流意见吸引的强度：
· 越强的模型 → 多数力越强 → 更快达成一致
· 群体越大 → 单一 Agent 的从众倾向相对减弱
（但强模型的临界规模也更大）
· 分裂出的子群体 → 更稳定，不易再次分裂
这意味着：
1. 一致可以「自发涌现」——不需要中心指挥
2. 但也可能「自发锁死」——错误的多数
同样会被固化
3. 规模与一致性的关系因模型而异，
不能用一套参数通吃所有模型💡 工程启示：如果你在用投票 / 评审机制做多 Agent 决策，先搞清每个模型的「从众强度」——换模型可能改变整个系统的集体行为，而不只是单点能力。
Step 2：给你的多 Agent 流程做「羊群自检」
2 三个高危信号，中一个就要改
高危信号 1：串行披露
「A 先说 → B 看到 A 的答案 → C 看到 A+B…」
→ 后发言者天然被前序答案污染
高危信号 2：共享上下文
所有 Agent 都基于同一份「调研结果」
→ 资料里的偏见会被全员复制
高危信号 3：一致就是胜利
流程只关心「是否达成共识」，
不关心「共识之外有没有更好的答案」
→ 少数派的异议被结构性忽略
自检方法：画出你的数据流，
标出「谁看了谁的答案」——看得越早，污染越重最常见的翻车形态是「假独立」：你以为 5 个 Agent 交叉验证很稳，其实它们共享了同一份搜索摘要、同一轮对话历史——等于同一个盲区验证了 5 遍。对照《多 Agent 安全五道护栏》的群体级风险再自查一遍。
Step 3：防御一——独立盲采
3 先各自作答，再互相看见
把流程改成「盲采 → 汇总 → 讨论」：
1. 每个 Agent 独立执行任务
· 各自规划搜索 / 分析路径
· 不共享中间结果与上下文
2. 全部完成后再提交答案
· 答案先落盘，不直接进群聊
3. 汇总时去重并标注分歧点
· 一致结论 → 标注「需外部验证」
· 分歧结论 → 列为「重点讨论项」
示例：代码评审让 3 个 Agent 各自
先独立 review 一遍（各自开 session），
再合并意见——而不是在一个群里排队发言
代价：成本上升（重复执行），
收益：切断从众污染链🔑 研究原文给的建议正是如此：想让 Agent 交叉验证，就让它们先独立搜索、独立作答，再互相看结果。顺序本身就是一种护栏。
Step 4：防御二——错峰披露与红队角色
4 给群体装上「反从众」装置
错峰披露：
· 分批公布答案（先 A 组，再 B 组…）
· 后批次只看到前批次已锁定的事实，
看不到结论——保留判断空间
红队角色（强制唱反调）：
· 指定 1 个 Agent 专挑主流答案的毛病
· 给它独立预算与独立资料源
· 它的 KPI 是「找漏洞」，不是「求同」
· 结论必须回应红队的质疑才可发布
搅拌器机制：
· 定期向群体注入外部事实 / 反例，
打断「越一致越自信」的自我强化红队不是摆设：如果红队 Agent 也共享主队的上下文和模型，它只是「第二个主队」。红队要独立资料、独立模型（如换一家）、独立目标才有效。
Step 5：防御三——外部验证模块
5 让「真实世界」当最终裁判
研究者的建议：多 Agent 生态需要
外部验证模块才能安全运行——
1. 事实类结论 → 对接真实数据源校验
· 数据库查询 / 官方文档 / 权威 API
2. 可执行类结论 → 先沙箱试运行
· 参考《沙箱隔离》方案
3. 决策类结论 → 人工审批门槛
· 群体共识 ≠ 正确，过一遍人再执行
4. 分歧放大监控 → 当群体异常迅速地
达成一致时，触发复核警报
核心思路：Agent 之间可以互相商量，
但最终要对着「外部事实」而不是
「彼此的意见」来校验🚀 想让群体共识再「长」一点，可把单个 Agent 升级为能自我改进的执行体——参考《Prime Agent 自改进》与《PenguinHarness 自进化》的思路。
Step 6：把防从众设计固化进系统
6 从「一次改造」到「默认机制」
1. 架构层：把「盲采 → 汇总 → 红队 →
外部验证」做成标准流水线组件，
新业务直接复用
2. 参数层：记录每个模型的多数力特征，
规模设计时避开临界值附近
3. 观测层：监控群体分歧度——
分歧率骤降 = 可能在「羊群化」，自动告警
4. 文化层：把「敢于异议」写进任务提示词，
明确要求 Agent 在合理时保留独立判断
5. 复评层：每季度对照最新研究 / 模型
更新一次设计（模型换代 = 行为可能变）
对照参考：多智能体编排框架
《Codex 多智能体 V2》、
《多智能体入门》、
《Google ADK》🎉 记住核心结论：群体的「一致」不等于「正确」。越是强大的模型、越是顺畅的协作，越要主动制造「独立与异议」的空间——这既是效率问题，也是安全问题。想从成本角度给团队规模做约束，可看《Agent 预算护栏》。
常见问题速查
| 你遇到的现象 | 大概率原因 & 解决 |
|---|---|
| 多 Agent 评审「每次都全票通过」 | 串行披露 + 共享上下文：改独立盲采 |
| 换了模型后系统行为大变 | 多数力随模型而异：重测临界规模，调整设计参数 |
| 交叉验证形同虚设 | 假独立：确认各 Agent 是否真正独立搜索、独立作答 |
| 想加 Agent 壮大声势却更易跑偏 | 人多≠准：加外部验证模块，让事实裁判，而不是加票数 |