四个Gemini智能体通关Minecraft：多智能体协作的真实代价

四个 Gemini 4 Argon 智能体在无人干预的情况下通关了 Minecraft 生存模式，击败末影龙。它们写了 2,783 个程序，死亡 605 次，连续运行 27 小时。没有预设角色、没有手写游戏逻辑、没有人类调试——只有四个智能体、Mineflayer 库、共享内存和游戏内聊天。

Four Gemini Agents Beat Minecraft 多智能体协作

这不是一次演示。它是对多智能体编排在复杂长时间运行环境中的压力测试——状态会发散、工具会失效、协调失败会级联放大。真正有价值的部分不是击败末影龙这个里程碑，而是底层管线暴露出的问题。

实验设置：四个智能体、一个目标、零编排器

每个智能体通过 Mineflayer 控制一个 Minecraft 玩家。Mineflayer 是一个开源 Node.js 库，将游戏状态和玩家行为暴露为 JavaScript API。智能体能够读取世界状态（物品栏、生命值、附近方块和实体）、执行动作（移动、挖掘、合成、攻击）、收发游戏内聊天消息，并访问一个共享内存存储。

任务目标是击败末影龙。这需要挖掘资源、合成工具、搭建基地、找到要塞、激活末地传送门并与龙战斗——在随机生成的世界中跨越数百个相互依赖的步骤。

研究者提供了一个实时仪表盘用于可观测性，但从未介入。智能体自主规划、编码、调试并从失败中恢复。

Mineflayer 的工作机制：Minecraft 采用客户端-服务端架构，客户端通过自定义二进制协议与服务器通信，协议涵盖登录握手、区块数据下发、实体位置更新、方块变更等数百种数据包。Mineflayer 在 Node.js 中实现了完整的协议栈，将这些底层数据包解析为 JavaScript 对象（如 bot.entity.position、bot.inventory.items()），并将玩家动作封装为异步函数（如 bot.dig(block)、bot.craft(recipe)）。这意味着智能体调用一行函数时，底层实际上是发送若干数据包、等待服务器确认、更新本地缓存，再解析响应。这种抽象让智能体无需理解协议细节，但也意味着每次动作都可能因网络延迟、服务器拒绝或游戏状态变化而失败，必须处理 Promise 拒绝和重试逻辑。

没有中央编排器的协调机制

大多数多智能体系统使用监督者或协调者来分配任务、解决冲突。这个实验没有。智能体通过两个通道协调：

游戏内聊天：智能体广播意图、请求帮助、分享发现。聊天是异步的、有损的（智能体可能漏掉消息），且非结构化，没有协议约束。

共享内存：一个所有智能体均可访问的键值存储，用于保存基地位置、资源计数、任务分配等持久状态。

角色是自然涌现的。一个智能体专注挖矿，另一个专注合成，第三个负责探索。没有显式角色分配。智能体通过聊天协商，并根据其他智能体的行为动态调整。

失败模式的必然性

这种协调模型会产生可预测的失败模式：

过期读取：智能体 A 读取共享内存，智能体 B 更新了它，智能体 A 仍基于旧状态行动。
竞态条件：两个智能体读到相同的资源计数，于是决定合成同一件物品。
聊天过载：随着消息增多，关键信息被淹没。
角色漂移：智能体中途切换任务，导致依赖关系无法满足。

论文没有详细说明这些情况的发生频率，但 605 次死亡和 27 小时的运行时长暗示它们相当频繁。

涌现式协调的理论背景：多智能体系统中，协调机制通常分为显式（中央调度器、合同网协议、拍卖机制）和隐式（共享环境、信号素、模仿）两类。无编排器实验属于隐式协调，其核心思想是：智能体通过改变环境（共享内存、游戏世界）留下痕迹，其他智能体读取这些痕迹并调整行为，从而产生全局有序。这种方法在群体智能（蚁群、鸟群）中已有大量研究，优势是去中心化、鲁棒性强（单个智能体失效不致命），劣势是收敛慢、易产生振荡。本文中智能体通过聊天和共享内存交换意图，本质上是将环境痕迹（共享内存键值）与直接通信（聊天）结合，但缺乏冲突解决协议（如互斥锁、版本向量），因此过期读取和竞态条件不可避免。

Mineflayer 作为工具边界

Mineflayer 将 Minecraft 协议抽象为 JavaScript 函数。比如移动到坐标、挖掘方块、合成物品，都只需调用一行高层 API。

这种抽象既是优势也是约束。

优势：智能体不需要理解 Minecraft 的网络协议或底层游戏机制，调用高层函数即可。

约束：Mineflayer 的 API 定义了智能体能感知什么、能做什么。如果库没有暴露某个游戏特性，智能体就无法使用。如果某个函数有 bug，智能体就继承这个 bug。

工具边界的三条教训

抽象泄漏：当地形生成出乎意料时，寻路可能失败。智能体必须检测并从中恢复。
异步地狱：许多 Mineflayer 函数是异步的。智能体必须管理 Promise、处理超时、在失败时重试。
状态同步：Mineflayer 维护本地状态（物品栏、位置）。如果本地状态与服务器发散，智能体会做出错误决策。

智能体写了 2,783 个程序。其中很多可能是在修复 Mineflayer 或自身代码的边界情况。

共享内存架构的取舍

论文没有说明共享内存的具体实现，但可以推断出一些约束：读取频繁（智能体不断检查基地位置、资源计数、任务状态），写入较少（资源存入、任务完成或计划变更时才更新），且没有事务机制（智能体在多步操作中不锁定内存，这导致竞态条件）。

一个可能的架构选择是内存键值存储，最终一致性，冲突解决用最后写入胜出，数据结构为非结构化 JSON。这种设计优先考虑速度和简单性，而非正确性。对研究演示可以接受，对生产环境则有问题。

生产环境需要什么

版本化写入：智能体在更新时附带版本号，检测并解决冲突。
事件日志：所有状态变更追加到日志中，智能体可以重放历史来调试发散。
模式验证：对共享内存强制结构约束，防止智能体写入格式错误的数据。
访问控制：限制哪些智能体能写入哪些键，防止意外覆盖。

最终一致性与最后写入胜出：最终一致性（eventual consistency）是分布式系统中的一种一致性模型，保证如果没有新的更新，所有副本最终会收敛到相同值，但不保证读取立刻看到最新写入。最后写入胜出（last-write-wins, LWW）是一种冲突解决策略，当多个写入并发发生时，以时间戳或版本号最大的写入为准。LWW 实现简单、无需协调，但可能丢失更新——在本文场景中，如果智能体 A 和 B 同时读到资源计数为 5，各自决定合成一个物品并写回 3，实际消耗了 4 个资源但最终只记录为 3，导致资源计数错误。这种错误在长时间运行中会累积，表现为智能体认为有足够资源却无法合成、或重复合成同一物品。

可观测性：缺失的关键层

研究者有一个实时仪表盘，但论文没有描述它展示了什么。要调试四个运行 27 小时的智能体，至少需要以下维度的观测能力：

单智能体指标：当前任务和子任务、物品栏状态、生命值和位置、最近收发的聊天消息、写入和执行的程序、错误和重试。

系统级指标：共享内存状态和更新频率、任务依赖图、资源流动（谁挖了什么、谁合成了什么）、死亡事件和原因、各主要里程碑的耗时。

追踪关联：将聊天消息关联到状态变更、将死亡关联到最近动作、将程序写入关联到执行结果。

没有这些，调试一次 27 小时的运行几乎不可能。Minecraft 无法确定性重放，因此可观测性必须是实时且全面的。

确定性重放与可观测性的关系：在传统分布式系统中，确定性重放（deterministic replay）允许通过记录所有非确定性输入（网络消息、时钟、随机种子）来精确重放执行过程，从而离线调试。Minecraft 无法确定性重放，因为世界生成包含随机种子、实体 AI 包含随机性、网络时序不可复现，即使记录所有输入也无法保证相同结果。因此，智能体系统的调试必须依赖实时可观测性——在运行时捕获足够细粒度的状态快照和事件日志，才能事后分析失败原因。这就解释了为什么论文强调仪表盘的重要性：没有实时追踪，27 小时的运行一旦失败，几乎无法定位根因，只能重新运行并祈祷问题复现。

角色涌现：通过模仿实现协调

智能体没有收到角色分配。角色是通过观察和模仿涌现的。一个智能体看到另一个在挖铁，推断铁是需要的，于是转而挖煤以避免重复劳动。

这种模式在以下条件下有效：智能体能观察彼此的行为（聊天、共享内存、世界状态）；任务具有天然并行性（挖矿、合成、探索相互独立）；智能体能从角色冲突中恢复（两个智能体挖同一种资源效率低但不致命）。

在以下条件下会失败：依赖关系紧密（智能体 A 需要智能体 B 先完成）；角色需要持续专注（中途切换任务浪费进度）；协调开销超过任务复杂度（聊天太多，干活太少）。

605 次死亡说明角色冲突相当常见。智能体可能重复劳动、留下未完成的任务，或在战斗中协调失败。

代码生成的大规模实践

27 小时写了 2,783 个程序，大约每 35 秒一个。大多数可能是小脚本：挖 10 个方块、合成 5 个火把、移动到坐标。但也有一些是复杂的：寻路、战斗逻辑、合成链。

代码质量面临几个根本性挑战。没有测试——智能体无法为 Minecraft 脚本写单元测试，它们通过在世界中运行来测试。没有版本控制——智能体覆盖程序，如果新版本出问题，只能凭记忆重写。没有代码审查——智能体不审查彼此的代码，bug 会传播。

这更接近 REPL 驱动的开发，而非软件工程。智能体快速迭代、接受失败、继续前进。

技术判断：何时用、何时不用

适合使用无中央编排器多智能体协调的场景：任务天然并行且松耦合；智能体能观察彼此的状态和行为；协调开销低；失败可恢复；有强大的可观测性来调试发散。典型例子包括分布式数据处理、群体机器人、协同编辑。

应避免使用的场景：任务依赖紧密且需要严格顺序；协调开销超过任务复杂度；失败是灾难性的（金融交易、安全关键系统）；无法承受过期读取或竞态条件;可观测性薄弱或缺失。典型例子包括数据库事务、实时交易、医疗设备。

这是一个研究里程碑，不是生产模式。四个智能体通过蛮力击败了 Minecraft：605 次死亡、2,783 个程序、27 小时运行。协调模型（聊天加共享内存）简单但脆弱，过期读取、竞态条件和角色冲突不可避免。

真正的价值不在于末影龙本身。而在于它证明了一件事：智能体可以通过简单原语（聊天、共享内存）在复杂环境中实现协调。管线很混乱，但它能工作。