我最初按照 Patrick Loeber 的教程做了实验，然后继续扩展。我把它移植到 Textual，并将原来的 Matplotlib 图表整合为 Textual Plot 图表。应用分成独立的客户端和服务器进程，通过 ZeroMQ 通信。模拟结果存储在数据库中。
Textual 客户端可以配置模拟，将配置发送给服务器，启动实验，并在运行过程中进行监控。
它早就不只是一款贪吃蛇游戏了。
但它仍然是一个应用程序。架构是在这样一个假设下逐渐形成的：有人坐在客户端前，亲手进行实验。
Fr3d 改变了这个假设。
我从现有的贪吃蛇代码中拆分出一个新的独立项目：Snake Lab Server。
核心想法很简单：Snake Lab Server 不需要关心是谁在进行实验。
客户端通过 ZeroMQ 提交 JSON 配置，服务器验证配置、将实验排队、运行模拟、收集指标，并将结果存储到 MariaDB。
服务器本身作为 systemd 服务运行。
这意味着 LLM 可以使用它，Python 脚本可以使用它，终端应用也可以使用它。甚至未来我还没想到的软件也可以使用它。
模拟器根本不需要知道客户端是谁。
我也把 Textual 客户端移植到了新系统。因为我仍然想自己提交实验，更重要的是，我还想亲眼观看它们运行。
比起盯着日志文件里滚动的数字，看着蛇在棋盘上移动，要令人满足得多。
但现在，Textual 界面只不过是众多客户端之一。
这是一项重要区别。
我还希望 Snake Lab Server 对“什么才算一场实验”有比较严格的定义。
接受模拟任务之前，必须验证配置。运行时使用的配置会被记录，结果也会被记录。整个模拟过程中持续采集指标，包括逐局游戏与逐个 episode 的数据。
这是因为我不只想问：
这条蛇得分提高了吗？
我还想问：
我们究竟运行了什么？发生了什么？
如果将来要让自动化系统开展数百次实验，那么即使实验结束很久以后，也必须能够回答这个问题。
否则，我拥有的就不是实验室。
而是一台老虎机。
至此，Snake Lab Server 建成了。
它还不是 Fr3d。
还没有一个自主 LLM 科学家来检查结果、分析配置并决定下一步实验。那部分仍有待开发。
但现在，至少有了它工作的地方。
最初，我只是让 AI 学着玩贪吃蛇。后来，它变成一个客户端/服务器应用，用于研究和实验。现在，它又演变成一项专门的服务，让其他软件能够对贪吃蛇 AI 进行受控实验。
实验室已经准备好了。
接下来，我需要造出科学家。