在 Minecraft 里它是什么？

言出法随是一个可以被 AI 操控的服务端玩家，AI 通过一套套"工作流"来操控它。

致谢

这一章提到的几个项目，都在言出法随的来路上帮过大忙，先在这里鞠躬谢过！

• Voyager：言出法随最早的设想，就是"一个免配置版的 Voyager"。是它让我第一次看到，大语言模型真的能在 Minecraft 里自己探索、自己动手。
• Mindcraft：非常优秀的项目，几乎就是我想要的样子；只可惜身体还是借 mineflayer 的。
• mineflayer：虽然言出法随最后没走网络包这条路，但正是把它研究了一遍，我才想清楚言出法随到底想要什么。
• Carpet：它的假玩家干活的思路也启发了我，言出法随的身体正在疯狂长出血肉。
• Mekanism：它的机器沿用原版 Minecraft 那一套容器逻辑，没有另起炉灶，所以言出法随一行适配代码都没写，也能凑过去打开它的熔炉、往里塞两块矿石，这份"没适配也能蹭上一点"的体验，正是我选服务端玩家的底气之一。

最初的设想

言出法随最早的设想，是做一个免配置版的 Voyager：玩家在客户端装一个模组，就拥有了自己的 AI。这个 AI 去调用 mineflayer 提供的 API，操控一个角色，于是你就有了自己的智能体。

mineflayer 是怎么"冒充"玩家的？

Minecraft 分客户端和服务端。你在客户端上的每一个操作，本质上都是在和服务端互相发包、收包、拿数据，这段逻辑原本由原版 Minecraft 负责。mineflayer 把这段收包发包的逻辑接了过来，于是在服务端眼里，它就是一个真实的玩家。

我想大部分网络游戏都可以这么干：只要破译了一个游戏的网络包，不打开客户端也能"玩"。这类程序还有一个人尽皆知的名字：外挂。当然，这只是外挂的其中一种。

为什么放弃 mineflayer

我当然不会因为背上外挂的骂名就放弃这条路线：Minecraft 的客户端外挂已经这么多了，多一个言出法随也无所谓。真正的问题在别处，主要有三个。

1. 要把整个 mineflayer 翻译成 Java。 mineflayer 是用 Node 写的网络包逆向。按我的初衷，要给玩家一个免配置的环境，就得照着 mineflayer，把 Node 那一套全部翻译成 Java。听起来工作量不小，但其实还不算太难，真正难的是后面两个。

2. 服务器容不下它。 我希望玩家能在服务器里自由使用言出法随，和朋友们一起玩 AI。可如果它是一个纯客户端的"外挂"模组，就得做各种防封处理。据我当时的调研，服务器一般都会封掉这类自动机器人；而且这样的外挂客户端对服务器的伤害也很大：服务器管不了这些机器人，它们可能带来巨大的性能开销，还会引出玩家之间的各种矛盾。

3. 很难适配别的模组。 mineflayer 是逆向网络包的，要适配别的模组，我想就得把那个模组的网络包也逆向一遍。对开源模组来说这不算难事，但开发成本还是上去了。更糟的是，没适配的模组就完全用不了。我希望的是：哪怕没适配，她至少也能用上一点点，开拓开拓眼界。

服务端玩家

于是就迭代出了言出法随第二版的架构：选用和 Carpet 同类的服务端玩家。从这里开始，我的思路就和 mineflayer 彻底脱钩了。

服务端玩家给言出法随带来了近乎原生的操作体验。即使没做任何适配，言出法随也能试着打开一些别的模组的容器，比如 Mekanism 的熔炉，这就是"原生"带来的好处。（虽然也就只能往里放放东西，不过至少不是完全用不了，看起来是好一点了，对吧？）

选择让 AI 操控一个服务端玩家，有两个原因：

• 服务端方便管理：将来服主可以合理地分配资源、设置权限；
• 近乎原生的操作：对原版的兼容性大大提高。

结论

至此，第一个问题有了答案：言出法随是一个可以被 AI 操控的服务端玩家。