四个 Gemini 智能体 27 小时通关《我的世界》：值得带走的是那本账，不是那一次赢

先说结论：四个 Gemini 4 Argon 智能体在《我的世界》里从出生点一路打到末影龙，用了 27 小时 14 分钟、写了 2783 个程序、死了 605 次。这是一次真实发生、留下完整记录的演示，但只跑了一次，说明不了下次能不能再成。我们的看法是：这篇论文最有用的不是「通关」，而是它留下的那本账：每个程序、每条消息、每次死亡都对得上时间。同一周，ChatGPT 给 GPT-6 Pro 加上了多个智能体并行干活、完成后可以逐个打开查看的功能。多智能体产品接下来该比的，正是「出了岔子，人能不能查清楚是谁、在哪一步」。

一件具体的事：从出生点到末影龙

先把任务讲清楚，因为它的难处不在某一步，而在每一步都依赖前一步。

要打败末影龙，得先在主世界收集材料、做工具，再进危险的下界拿烈焰棒和末影珍珠，合成末影之眼；末影之眼会朝最近的要塞飞，循着它找到地下的传送门房间，才能进入末地；进去之后还得弄明白怎么打。任何一环丢了东西、走错了路，前面的时间就白花了。

据论文（作者自报，arXiv 10-15 提交）的摘要和 ArXivSignals 对全文的摘要（下文过程细节除另注外均出自这两处），实验是这样搭的：四个 Gemini 4 Argon 智能体各控制一个玩家，另有一个不下场的「观察者」只读记录、写报告。智能体不看屏幕，而是用开源库 Mineflayer 写一小段 JavaScript 程序去移动、挖矿、合成、战斗；程序结束后，它读回一段文字（位置、血量、背包、周围方块或报错），再决定下一步。四个玩家共享游戏内聊天和一份团队记忆。研究者可以在实时面板上随时暂停或停止，论文说他们没有出手干预。世界是随机生成的，难度是「简单」。

结果：从第一个程序到服务器记下通关标记，27 小时 14 分钟；2783 个程序、229 条聊天消息、605 次死亡、服务器重启 6 次。

三个瞬间：分工、定位、救场

据 ArXivSignals 对论文的摘要，论文把过程拆成了几个能对上时间的片段，挑三个看。

分工是吵出来的。 第一个程序跑起来约十分钟后，一个智能体提议谁去采集、谁去挖矿、谁做工具；一分钟内另一个提出了不同的分法，第三个接受了修改版。后来的分工大致稳定成：一个管补给，一个管工具和下界要塞，一个准备传送门，第四个在最后的战斗里补位。论文的提示词鼓励「先观察再动手、验证结果、把经验写进记忆」，但没有规定谁干什么。

用代码把两次观察变成一个坐标。 末影之眼只指方向。一个智能体在两个地点各扔一次，用程序记录飞行轨迹，算出两条线的交点。这个估计点距真正的传送门房间约 43 米。

一次溺水，差两分半钟就丢了全部家当。 第 13 小时 10 分，一个携带全部 12 颗末影之眼的智能体淹死了。其他智能体在聊天里报出精确位置和物品消失的倒计时，离得最近的那个赶过去，把 12 颗全捡了回来，离物品消失还剩约两分半钟。摘要转述的论文统计里，229 条消息中有 173 条带精确坐标、64 条涉及共享箱子、20 条是物品救援（一条消息可以同时算进几类）。

最后一关也一样。进末地后，龙杀了玩家 69 次。约第 21 小时，一个智能体想明白了：柱子顶上的十个水晶在给龙回血，光打龙没用。办法很朴素：在柱子旁垒土上去，徒手打掉水晶再挖下来。十个水晶花了约 4 小时 40 分钟才打完；在最后一个水晶被打掉之前，龙的血量读数一直不低于 200 中的 198.5。

人在哪里接手

我看智能体，习惯先问一个问题：人需要在哪一步接手？这次的答案有点特别：中途没有人接手，但人在开局就已经接手过了。

第一，界面是人搭的。据 ArXivSignals 的摘要，论文承认 Mineflayer 给智能体的是结构化的游戏状态，甚至能看到岩石后面的方块和龙的内部状态，寻路插件还替它规划绕开障碍的路线。这和用键盘鼠标看画面打游戏，是两种难度。

第二，世界是简单难度，据摘要，模型训练时就见过《我的世界》和 Mineflayer，论文也没有说智能体是从零学会这个游戏的。

第三，过程并不顺：22% 的程序以报错结束，服务器重启 6 次，末地的战斗拖了将近十四个小时。

第四，也是最要紧的一条：只跑了一次。没有换随机种子重复，也没有对照组。论文摘要说会讨论「结果的局限」；ArXivSignals 的摘要把它概括为一次有记录的演示，而不是可靠性估计。

所以我不会把这条读成「AI 能自主玩通《我的世界》」。更准确的说法是：在人把环境翻译成文本、把寻路做好的前提下，四个通用编程智能体有一次把一个跨越一天多、上千步相互依赖的目标走完了。

为什么这本账比那次赢更重要

据 ArXivSignals 的摘要，论文里有一段话值得注意：观察者加上人工抽查，没有发现「钻规则空子」，也没有任何程序调用服务器命令。能这么说，是因为每个程序、每段输出、每条消息、每次死亡都被记了下来，能和服务器日志对上时间。

这就是多智能体真正落地时最缺的东西。一个智能体干活，出错了你翻它的记录就行；四个智能体分工，问题往往出在交接处：谁以为谁拿着末影之眼，谁报了一个错坐标，谁把别人的经验当成了自己的。这次救回 12 颗末影之眼，靠的正是一条带坐标和倒计时的消息。反过来想，如果那条消息里的坐标错了，事后也能查到是哪一条。

同一周，OpenAI 在 ChatGPT 更新日志里写，聊天里的 GPT-6 Pro 升级后响应更快、更会用插件和工具，并且可以让多个智能体并行处理一个任务的不同部分：你能在对话里看到它们的进度，打开已完成的子任务看每个智能体做了什么（企业宣称）。目前正向符合条件的 Pro 用户推送，企业工作区看管理员设置。OpenAI 没有给出速度、完成率或质量的数字。

把这两件事放在一起看，方向是一致的：智能体从「一个人干」变成「一组人干」，产品的竞争点会从「单个模型多聪明」，挪到「分工谁来定、失败了谁补位、人能不能逐个打开查账」。ChatGPT 把「打开每个子任务」做进界面，是对的第一步；但一个能打开的子任务列表，和一份能逐条对上时间的记录之间，还差得很远。

我们不知道什么

• 重复跑十次，能成几次？论文只报告了一次成功，没有多种子结果，也没有公开总花费。
• 换成看画面操作，或者换成真实的软件工程任务，这种分工方式还管不管用？论文提到真实工作需要同样的长程编码与协作，但这一点没有被这次实验检验。
• 据 ArXivSignals 的摘要，论文没有描述公开代码、检查点或完整日志，外部研究者暂时无法复现。
• ChatGPT 的并行智能体，实际任务里比单个智能体快多少、错多少，怎么计入额度，OpenAI 都没说。

我们的看法

多智能体这条线，接下来会有更多「一次通关」「一夜刷满基准」的消息。我的判断标准很简单：先问跑了几次，再问人在哪一步接手，最后问出了错能不能查到是谁。这篇论文在第三个问题上给了一个好样板，在第一个问题上什么也没回答。

什么情况下我会改口：如果作者补上多个随机种子的成功率，而且成功率稳定；或者 OpenAI 公布并行智能体在真实任务上的完成率和返工率，我会把「演示」这个定位往「能力」那边挪。在那之前，把它当作一本写得很好的施工日志来读，比当作战报来读更有用。