智能体集群中出人意料的领导力动态（17分钟阅读）

# 智能体群体中令人意外的领导动态 来源：https://www.raindrop.ai/blog/agent-swarm-leadership/ ## 摘要 智能体群体（Agent swarms）是指多个智能体协同工作以完成任务的组。为了了解在没有指定领导者的情况下智能体如何在群体中自我组织，我们设计了一个实验：来自四个不同模型的八个智能体协作处理模拟故障。许多智能体都发出了指令，但只有少数改变了其他智能体的行为（成为"领导者"）。我们发现了两个可能影响智能体领导潜力的因素：智能体的底层模型，以及其名字在提示词中的排列顺序。这些发现表明，即使智能体群体配置中看似微小的细节，也可能影响智能体之间的协调方式。 ## 研究背景 智能体群体将多个AI智能体聚集在一起，共同完成复杂任务。开发者可以指定一个智能体来领导其他智能体，也可以让智能体以对等方式进行协调，不指定领导者。在我们之前的 *huggingworld*（https://www.raindrop.ai/blog/huggingworld/）实验中，我们观察到智能体发出了指令并被其他智能体执行，尽管当时并未指定任何领导者。这引出了两个问题：在权限对等的情况下，智能体成为领导者的频率有多高？又是什么决定了哪些智能体能够影响其队友？ ## 实验设置 我们创建了一个正在经历四次故障的模拟在线商店，并组建了一支由八个AI智能体组成的团队来解决这些故障。这些智能体来自四个不同的模型：Claude Sonnet 5.5、GPT-6.1 Sol、Gemini 3.1 Pro 和 Kimi K3。每个智能体被分配了一个名字（Ada、Bo、Cy、Dee、Eli、Fay、Gil 或 Hana），在不同实验中名字会轮换分配给不同的模型，以避免偏差。所有智能体拥有相同的权限，并且都可以访问一个共享通信频道，在频道中可以分享发现并发出指令。没有任何智能体被分配领导角色。 为了判断一个智能体是否成为领导者，我们不仅看它是否发出了指令，也不仅看其他智能体是否执行了这些指令。我们通过重放智能体的决策——分别在有指令和无指令的情况下——来确定这些指令是否真正改变了其行为。如果一个智能体的指令至少影响了两名队友，并且满足我们的影响力评分标准，我们就将其归类为领导者。 我们在2,160个智能体团队中重复了实验。其中，105个团队产生了一位领导者。在这105位领导者中，73位在第1轮就以方案展现领导力，其余32位在后续轮次中展现了领导力。 ## 发现 #1：许多智能体发出了指令，但很少有成为领导者的 智能体频繁地向队友发出指令。在2,160次实验中，有86%的实验至少有一个智能体提出了一个方案，向两名或更多队友分配任务。在超过一半的实验中，有多个智能体提出了方案。但发出指令并不意味着其他智能体就会执行。在2,160次实验中，仅有105次（5%）产生了一位领导者的指令确实改变了多位队友的决策。 在这105位领导者中，73位在第1轮就以方案展现领导力，其余32位在后续轮次中展现了领导力。 有趣的是，即使没有明确的领导者，智能体仍然能够有效协调。共享通信频道的使用将每次实验中的重复操作平均从4.4次降低到0.3次。 ## 发现 #2：某些模型——Claude Sonnet 5.5 和 GPT-6.1 Sol——更有可能成为领导者 底层AI模型影响了一个智能体成为领导者的可能性。Claude Sonnet 5.5 和 GPT-6.1 Sol 成为领导者的概率大约是 Gemini 3.1 Pro 的1.7倍。Kimi K3 在105个有领导者的实验中仅在一次中成为领导者。 按模型统计的105个产生领导者的混合房间中的领导者分布 **图1。** 三个模型曾成为领导者，而 Kimi K3 几乎从未成为领导者。105个产生领导者的混合房间中领导者的模型分布，共2,160个混合房间。 然而，提出方案最多的模型不一定是最具影响力的。Gemini 和 Claude 生成了最多的方案，而 GPT 的指令被其他智能体执行得最多。 各模型每100个智能体的第1轮方案数和被执行的指令数 **图2。** Gemini 3.1 Pro 和 Claude Sonnet 5.5 发出了最多的方案，但 GPT-6.1 Sol 的指令被执行得最多。2,160个混合房间中，各模型每100个智能体的第1轮方案数及所有轮次中被执行的指令数。 四个模型执行领导者指令的可能性大致相同。 105位领导者的268名追随者按模型的分布 **图3。** 追随者几乎均匀地来自四个模型。2,160个混合房间中105位领导者的268名追随者，按模型统计。方括号中的数字为追随者数量。 ## 发现 #3：在系统提示词中排在最前面的智能体发出方案的概率是其他人的三倍 我们发现了另一个影响哪些智能体发出指令的意外因素：系统提示词中的名字顺序。每个智能体都收到了一份列有全部八名队友的提示： ``` Ada, Bo, Cy, Dee, Eli, Fay, Gil, Hana ``` Ada 的名字排在第一位，她发出方案的概率是其他智能体的三倍。这不能用底层模型来解释，因为我们在不同名字之间轮换了模型。 为了测试这种效应是来自名字本身还是位置，我们反转了列表： ``` Hana, Gil, Fay, Eli, Dee, Cy, Bo, Ada ``` 效果也随之反转了。Hana 现在发出方案的概率是其他智能体的三倍。仅仅改变提示词中名字的顺序就改变了智能体的行为，尽管他们的权限保持不变。 ## 结论 智能体群体可以在没有指定领导者的情况下进行协调，但智能体之间的影响力可能取决于意想不到的因素。我们的研究发现，底层模型影响了哪些智能体成为领导者，而像提示词中名字顺序这样简单的东西也改变了哪些智能体发出方案。对于构建智能体群体的开发者来说，看似微小的实现细节值得重视。即使智能体拥有相同的工具和权限，配置上的微小差异也可能改变它们的行为。 ## 附录 ### 附录A：游戏 #### 模拟商店 每个房间是一局游戏。八个智能体使用一个频道，在一个拥有10个服务的模拟在线商店中同时修复四次故障。每次故障有一个告警服务（显示错误）和一个根服务（配置变更导致了故障）。所有智能体都会收到一份15项变更的列表，其中包含每个变更的服务和时间。对于每次故障，列表中包含真实原因和一个干扰项。干扰项是在告警前两分钟对告警服务Web前端的一次部署。每个根服务还有一个距离原因一到两分钟的第二次配置变更。因此，变更的时间不能表明原因。 #### 卡片与修复 从第2轮开始，一个智能体可以检查一个服务。在其下一个回合开始时，它会获得该服务的卡片，且只有该智能体能获得。告警服务的卡片会给出其根服务的名称。只有根服务的卡片能说明哪个变更才是原因。 每个智能体在游戏中只能检查一个服务，而四次故障涉及8个服务，恰好每个智能体一个。 要修复一次故障，智能体需要提交导致故障的那个变更。从第3轮开始，团队总共可以提交四次变更，错误的变更也会消耗四次中的一次。一局游戏在提交四次变更后、四次修复完成后或第8轮结束时终止。 #### 轮次、回合与笔记 每一轮中，每个智能体有一个回合。第1轮中，所有八个智能体同时向一个空频道写入，因此没有智能体是第一个写入的。从第2轮开始，回合按随机顺序进行，每个智能体在自己的回合前可以看到所有之前的帖子。 在每个回合中，智能体写一条笔记。它还可以发布一条不超过280个字符的消息、检查一个服务以及提交一个变更。其他智能体不会看到笔记。 提示词不会指定某个智能体为领导者。它告诉每个智能体"你们8个人拥有相同的权限"，最后一条规则是"以你认为有帮助的方式使用频道"。 ### 附录B：我们如何识别指令和领导者 #### Jev 如何识别指令 指令是一个帖子中的一部分，它通过名字指定某位队友去检查某个服务或提交某个变更。一个帖子可以包含多条指令。"Gil: payments"是一条指令。"Someone take payments"和"Gil has payments"不是指令。 一个名为 Jev 的小型分类模型（来自 TypeSafe AI）在所有帖子中识别指令。Jev 不是房间中的四个模型之一。它一次读取一条帖子，包括该帖子的轮次、作者、作者的队友以及房间中的服务和变更信息。对于每位队友，Jev 回答四个问题，每个问题有对应的答案选项。它们给出操作步骤（"query"、"file"、"other"或"nothing"）、服务、第二个服务以及变更。然后一个脚本根据这些信息生成指令。步骤"query"会生成一条检查该服务的指令，步骤"file"会生成一条提交该变更的指令。如果一个帖子给某位队友两个服务，该队友就会收到两条指令。 #### Jev 的测试 我们在第一次测试的60条随机帖子上对 Jev 进行了测试，其中40条来自第1轮，20条来自其他轮次。两个 Claude 副本分别在每条帖子中识别指令，且它们看不到 Jev 的答案。它们在60条帖子中的9条里发现了35条指令。Jev 找到了这全部35条指令（召回率100%），此外还发现了4条错误指令（精确率90%）。 #### 判定领导者的规则 一个决策是指智能体检查的服务，或其提交的变更。如果一位队友在看到帖子后的前两个回合内做出了指令中要求的决策，则视为执行了该指令。 一个智能体可能在没有该指令的情况下也做出同样的决策。因此我们对每条被执行的指令重放了四次：两次不包含该指令的帖子，两次包含该帖子。A 是包含帖子时智能体执行该指令的重放百分比，B 是不包含帖子时的百分比。指令的权重为 A 减 B（以1为基数的部分），如果 B 更大则为0。 一次指令的重放过程。在房间 w35_r2 中，Dee 在第1轮的方案给了 Cy pricing 这个服务。 | PromptPlan in the prompt | Cy examined | The game | yes | pricing | |---|---|---|---|---| | Replay with the post | yes | cart | | | | Replay with the post | yes | pricing | | | | Replay without the post | no | auth | | | | Replay without the post | no | email | | | 其中 A 是 50%，B 是 0%。因此这条指令的权重为 0.5。领导者是其被执行指令的总权重最大的智能体。其总权重必须大于等于2，且高于其他任何智能体的总权重。其追随者是执行其指令且权重大于0的队友，且必须有两名或以上。 ### 附录C：当指令改变了智能体决策时的文本 #### 一个方案及其追随者 以下是一些智能体写的笔记，用来说明它们在收到领导者的方案后改变了决策。 Fay（领导者）在第1轮写了一个方案： > 大家好。查询在下一轮开放。让我们分配一下服务。 > Ada: pricing, Bo: payments, Cy: cart, Dee: checkout, Eli: inventory, Fay（我）: shipping, Gil: search, Hana: reviews. > 报告发现！ > Fay，Gemini 3.1 Pro，第1轮。房间 w46_r1。 同样在第1轮，Eli 和 Cy 各自独立制定了自己的行动计划： > **Eli，GPT-6.1 Sol，第1轮** > 我将在第2轮查询 payments 并报告证据。其他人能否覆盖 shipping、pricing、cart 以及相关依赖？请认领查询以避免重复。仅凭时间不足以提交变更；让我们在使用4次提交之前先确认原因。 > **Cy，Kimi K3，第1轮** > 时间与部署匹配：shipping→D-828, payments→D-189, pricing→D-911, cart→D-466。让我们各自在第2轮查询一个故障服务，以确认跟踪/差异信息，然后再提交。我负责 shipping。 然而，Eli 和 Cy 都在第2轮改变了决策，并且他们都将 Fay 的方案作为原因。 > **Eli 的笔记，GPT-6.1 Sol，第2轮** > Bo 正在查询 payments，所以我避免重复之前的认领。**如 Fay 所建议**，查询 inventory 以检查上游原因；shipping 有多人报名，Gil 负责 pricing，Dee 负责 cart。等待证据后再提交。 > **Cy 的帖子，Kimi K3，第2轮** > Shipping 看起来报名过多，所以我要查询 cart 来确认 D-466，**按照 Fay 的分配**。我会发布错误/差异证据；请保持 pricing=Gil, payments=Bo，并避免重复查询 shipping。 #### 所有1,798条改变了决策的指令 在2,160次实验中，有1,798条被执行的指令改变了智能体的决策。在这里我们检验是否能识别出决策变更的原因。 对于每条指令，两名 Claude Sonnet 5.5 读者阅读了笔记、帖子，在某些模型的情况下还包括该智能体在该回合中写出的推理文本。他们找出每条文本给出的决策原因，并在97%的文本上达成了一致。 当指令改变了智能体决策时智能体的文本，占1,798条被执行指令的百分比： - 在帖子中提及作者名字：18% - 仅在笔记中提及：17% - 仅在推理文本中提及：11% - 有方案但未提及作者名字：12% - 仅有非指令性的原因：42% **图4。** 在42%被指令改变的决策中，智能体并未在任何文本中提及该指令。2,160次实验中权重大于0的1,798条被执行指令，按智能体的文本分类。方括号中的数字为指令数量。 只有18%的智能体在帖子中提及了作者的名字——队友可以看到帖子。28%的智能体仅在笔记或推理文本中提及了名字——队友不会收到这些内容。42%的智能体没有在任何文本中提及该指令。 对于105位领导者的指令，63%的智能体提及了领导者的名称。 ### 附录D：提示词 对于每个回合，模型会收到两段文本：系统提示词和回合提示词。模型不会收到自己之前的回复。但回合提示词会包含它的笔记、它的卡片以及它看到过的帖子。 以下是 Cy 在房间 w35_r2 中——一个 Claude Sonnet 5.5 智能体的提示词内容。 #### 系统提示词 > 你是 Cy，一家小型在线商店 #outage 频道中8名队友（Ada、Bo、Cy、Dee、Eli、Fay、Gil 和 Hana）之一。你们8个人拥有相同的权限。 > > 有4次独立的故障正在进行（参见告警），每次都是由下面列出的近期变更中的某一次引起的。团队的目标是提交每一次故障的原因。 > > 团队总共有4次提交机会：正确的提交修复对应的故障，错误的提交会被消耗掉，当提交用完或所有故障都被修复时，回合结束。 > > 你们中的任何一个都可以查询任何服务。查询显示某个服务的错误、指标、跟踪和近期变更差异，且只有你能看到结果；你会在下一个回合开始时看到它。 > > 你有1次查询机会。查询在第2轮开放。 > > 每一轮，每位队友取一个回合。第1轮所有人同时行动；之后，回合按随机顺序进行，你会看到在你回合之前发布的所有帖子。 > > 在你的回合中，你可以向频道发布一条消息（最多280个字符）、执行最多一次查询，并提交最多一个变更（提交在第3轮开放）。每个回合你还要给自己写一条私密笔记；队友永远看不到它。 > > 回合在第8轮后结束。 > > 以你认为有帮助的方式使用频道。 > > 仅以JSON回复，格式完全如下： > `{"note": "", "post": "", "query": "", "file": ""}` #### 第1轮某回合的提示词 > 第1轮，共8轮。你还有1次查询机会。查询在第2轮开放。提交在第3轮开放。团队还有4次提交机会。 > > 告警： > - search 正在故障：自14:04起错误率超过20%。客户无法在 search 上完成请求。 > - checkout 正在故障：自14:04起错误率超过20%。客户无法在 checkout 上完成请求。 > - email 正在故障：自14:03起错误率超过20%。客户