先说一个我的判断：多Agent模式目前正处于快速发展期，尤其在游戏化交互这个细分领域，蕴藏着巨大潜力尚未被充分挖掘。

近段时间我一直关注Agent智能体的最新进展，恰好看到有网友分享利用多Agent技术开发了《谁是卧底》的游戏——这个创意非常巧妙，值得深入分析。

不过遗憾的是，原作者并未开放Agent配置。于是决定自己动手实现。最终完成的版本功能齐全，今天把整个设计思路完整公开。

为什么一定要采用多Agent模式？核心原因很简单：AI能够模拟多名玩家，游戏的趣味性和过程的可控性都大幅提升。如果仅用单机逻辑，就无法体现Agent协作的独特魅力。

具体实现上，我使用了扣子（Coze）平台，大模型主要选用Kimi。下面是整体架构配置。

其中大部分Agent都需要调用工作流，才能完成更复杂的任务逻辑。

下面逐一拆解每个Agent的职责。

游戏初始化Agent，负责随机指定卧底，同时生成卧底和平民各自对应的词汇。

这个Agent调用的工作流名为undercover_init，涉及三类节点：

• 代码节点：处理数据格式，例如随机选取卧底、整理大模型生成的词汇。代码量非常精简，几行就能完成。

• 大模型节点：核心任务，负责生成卧底和平民的词汇。

• 变量节点：将卧底编号、词汇存储到变量中，便于后续Agent读取使用。

来运行一下测试效果。

人类玩家发言Agent，接收用户对词汇的描述，并将描述内容存入变量。

AI玩家发言Agent，调用工作流，用AI模拟两位玩家进行发言。这里有一个关键设计：每位AI玩家在发言前，都必须参考之前玩家的发言，既确保内容不重复，又要巧妙隐藏自己的身份。

人类玩家投票Agent，对卧底进行投票，并保存投票结果。

AI玩家投票Agent，AI玩家对卧底进行投票，并展示最终的投票结果。

游戏结果Agent，根据投票结果判定胜负。

目前这个版本仅包含3位玩家，是最基础的版本，因此一轮即定胜负。后续扩展更多玩家并不困难：如果第一轮投票卧底未被淘汰，就移除被投出的玩家，然后跳转到前面的Agent继续游戏流程。

这个游戏看似简单，但从构思到实现，断断续续花费了一周时间。最想分享的一个体会：AI输出的结果天然带有不确定性，必须根据实际场景选择不同的模型、调整参数，才能达到理想效果。