以 Factorio Learning Environment 为参照重构 airi-factorio：AIRI 在自动化生产游戏中的 AI Agent 架构演进

AIRI 是 moeru-ai 社区自托管的开放 AI Companion 项目，而 airi-factorio 是其生态中让 AIRI 能够实际游玩 Factorio（异星工厂）这一自动化生产模拟游戏的子项目。本篇 DevLog 深度复盘了 airi-factorio 第一版基于「TypeScript 编写 Factorio Mod + RCON 控制 + LLM 生成 Lua 代码」的实现方案及其痛点，并围绕论文 Factorio Learning Environment (FLE) 提出的 Lab-play / Open-play 双模式评测框架，梳理出一条转向「Golang 实现 MCP Server + 原生操作封装」的重构路线。读完本文，你将理解 AI Agent 与游戏环境交互的两种典型架构形态，掌握 Mod 热重载、RCON 命令长度限制、/sc 与 /c 命令差异等实战细节，并看到 mcp-launcher 如何在这一重构中扮演核心角色。

背景：AIRI 与 airi-factorio 的定位

AIRI 是一个自托管的 AI Companion 项目，其能力矩阵中明确包含了「游玩 Minecraft 与 Factorio」这类与真实世界（游戏世界）交互的扩展场景。在仓库主 README 中，airi-factorio 被定位为「Allow AIRI to play Factorio」的 PoC 项目，并已提供可运行的演示版本；同时仓库还维护了配套的 Factorio RCON API（Factorio 无头服务器控制台（headless server console）的 RESTful API 封装）、autorio（Factorio 自动化库）以及 tstl-plugin-reload-factorio-mod（开发期重载 Factorio Mod 的 tstl 插件）等基础设施。这篇 DevLog 正是围绕这些基础设施的前身设计进行的一次系统性复盘与重构规划。

第一版 airi-factorio：五根支柱与它们的问题

作者 @LemonNeko 在半年前首次尝试编写能游玩 Factorio 的 AI Agent，第一版实现由五块关键技术拼装而成：

技术环节	实现方式	核心工具/手段
Mod 开发	使用 TypeScript 编写 Factorio Mod	tstl 将 TypeScript 编译为 Lua
游戏通信	通过 RCON 与 Factorio Mod 交互	factorio-rcon-api，调用 /c 命令执行 Mod 注册的函数
决策与代码生成	让 LLM 生成 Lua 代码控制玩家	通过 Prompt Engineering 告知 LLM 如何操作游戏、如何规划，并把 RCON 交互代码封装为 LLM 可调用的工具
聊天交互	通过游戏内置聊天系统与 LLM 交互	读取游戏标准输出，用正则表达式解析玩家聊天内容，再发给 LLM 处理
开发体验	DevContainer 开发环境 + 热重载 + 软链调试	为 tstl 编写插件实时监听代码变更，通过 RCON 把新 Mod 内容发送进游戏；用符号链接把 tstl 输出目录链接到游戏目录，便于直接查看编译产物

这套方案的初衷是「用更工程化的方式做游戏 AI 开发」，但它也带来了四个核心痛点：

1. 调试链路过长：主要操作逻辑都写在 Mod 内，修改后需要退出地图、回到主界面、再重新进入才能生效；一旦 data.lua 稍微复杂，甚至必须重启整个游戏。
2. RCON 命令长度限制：通过 /c 执行 LLM 生成的 Lua 代码时，Factorio 对单条命令有长度上限，代码一长就必须拆成多次执行，既繁琐又容易出错。
3. 聊天内容解析脆弱：依赖正则解析标准输出中的玩家聊天内容，鲁棒性差。
4. 可维护性不足：代码整体健壮性与可维护性差，新朋友想参与开发甚至只是想试运行，启动成本都很高。

值得一提的热重载思路：通过 tstl 插件实时监听代码变更，经 RCON 将新 Mod 代码发送给游戏；收到新代码后卸载全部接口并重新执行一次 Mod 代码实现热重载——但「如何妥善处理 Mod 已有状态」成为最大挑战。这是第一版中最具探索价值也最棘手的设计点。

Factorio Learning Environment：评测框架带来的启发

作者在规划重构时恰好读到论文 Factorio Learning Environment (FLE)。FLE 是一个专门用于评估 AI 在长期规划（long-term planning）、程序合成（program synthesis）、资源管理（resource management）与空间推理（spatial reasoning）四项能力上的测试框架，包含两种模式：

• Lab-play：在 24 个手工设计的关卡中测试，资源受限，考察 AI 能否用有限资源高效搭建生产线。
• Open-play：在程序化生成的无垠大地图上，以「建造最大的工厂」为目标，考察 AI 的长期自主目标设定、探索与扩张能力。

论文评测了当时主流的 Claude 3.5 Sonnet、GPT-4o、Deepseek-v3、Gemini-2 等模型，而在 Lab-play 模式下，即便是当时最强的 Claude 3.5 也仅完成了 7 个关卡——可见该任务对 LLM 的长链条推理能力挑战极大。

FLE 的三点架构优势：Python REPL、原生操作封装与 /sc 命令

作者发现 FLE 的实现方法与 airi-factorio 高度相似，却在三个关键点上做得更好：

1. Python REPL 直执行，而非让 LLM 生成 Lua：FLE 用 Python 编写，LLM 生成 Python 代码后在 Python REPL 中直接执行，并能直接从标准输出读取结果。由于 Python 生态的数据集与库远多于 Lua，代码生成准确率更高，也能生成更复杂的逻辑。
2. Lua Mod 只保留原子操作，复杂逻辑上移到 Python：Lua Mod 内只实现 place_entity 这类放置实体的原语操作，更复杂的逻辑全部写在 Python 侧。这从根源上降低了 Lua Mod 的 bug 可能性，从而大幅减少「重启游戏」的频率。
3. 用 /sc 替代 /c 执行 Lua 代码：/sc（silent command）不会把代码回显到控制台，控制台保持干净，只留下必要内容，显著降低了标准输出解析的难度。

此外，FLE 还精心分析了所有必需配方的生产过程与难度，总结出「生产一件物品的成本如何计算」「LLM 得分如何计算」等公式，用于更科学地评估 LLM 能力；并在论文附录中公开了其 system prompt，其中规定了环境结构、响应格式、最佳实践以及如何理解游戏输出等关键内容。

回到 airi-factorio：为什么用 MCP 而不是 Python

面对 FLE 的优势，作者的第一反应并不是「转投 Python」，而是基于自身技术栈做出理性取舍：

我不想写 Python，我只熟悉 TypeScript 和 Golang。

恰好当时团队刚完成 mcp-launcher——一个「适合所有可能 MCP 服务器的构建器」，定位类似「模型界的 Ollama」。于是重构方案确定为：用 Golang 实现一个 MCP Server，让 LLM 通过 MCP（Model Context Protocol）协议调用它，从而在不引入 Python 的情况下，获得与 FLE 同等的「代码生成质量 + 环境解耦」收益。

MCP Server 方案在 AIRI 生态中并非孤例：仓库 MCP Server 配置说明 展示了桌面端如何通过「Settings → Modules → MCP Server → Add server」填写 Identifier、Command、Arguments 以及可选的工作目录与环境变量来接入外部工具进程，并支持 Test、Save and restart、Reveal in file manager、Edit JSON 等维护手段，同时强调「只运行你信任的 MCP Server，因为它们可以在本地执行命令并访问你授予的环境变量」。这与 DevLog 中「通过 mcp-launcher 用 Golang 实现 MCP Server」的设想互为印证：MCP 已是 AIRI 连接外部工具的标准通路。

重构后的目标架构：聊天入 Mod，操作走 MCP

重构前后架构图如下（来自本文档同目录的 assets）：

重构后的核心变化有两点：

1. 玩家聊天内容不再直接发给 LLM：改为存放在 RconChat Mod 中，LLM 通过 MCP Server 读取这些内容。这条变化把「聊天解析」从脆弱的正则标准输出解析中解放出来。
2. 不再让 LLM 生成 Lua 代码：借助 MCP Server 方案，将 RCON 交互代码封装为 MCP 工具暴露给 LLM，LLM 以结构化的工具调用代替代码生成，天然规避了 /c 命令长度限制与 Lua 代码可维护性问题。

至于 system prompt，作者承认当前提示词虽由 AI 生成但仍不够清晰、优先级不明，计划参照 FLE 公开的 system prompt 进行改进。

结语与后续脉络

「我们基本上又推翻之前的所有设计了，重新开始。」——这句结语准确概括了本次 DevLog 的性质：它既是一次对第一版方案的坦诚复盘，也是一份面向 FLE 论文的重构路线图。若读者感兴趣，作者建议精读 FLE 论文及其开源代码，并欢迎对文中理解提出修正。

作为后续验证，AIRI 社区在 2025.08.26 的 DevLog 中呈现了 airi-factorio 向纯视觉（pure vision）方向的实际进展：通过将 Factorio 客户端容器化（xvfb 虚拟显示 + x11vnc + websockify + noVNC）、基于 YOLO11n 训练目标检测模型并在浏览器中用 onnxruntime-web 以 WebGPU 实时推理（约 20ms/帧），让 AI 真正「看见」游戏画面——这与本文「MCP Server 化」的重构相辅相成，共同构成 airi-factorio 从「LLM 生成 Lua 代码」走向「感知 + 工具调用」的完整演进路径。

---

关联资源速览

• 本文对应文档：DevLog @ 2025.07.18
• 后续进展：DevLog @ 2025.08.26：纯视觉方向进展
• AIRI 主 README 中的相关生态：README.md
• MCP Server 在 AIRI 桌面端的接入方式：setup-and-use 文档