我们在 Minecraft 和 Mindustry 中运行了 AI 代理群
Y Combinator Labs 的实验在 Minecraft 和 Mindustry 中放出由 LLM 驱动的代理群，凸显了 AI 在复杂实时游戏环境中的潜力与当前极限。评论者指出，尽管这些模型能够推理，但它们在延迟、协调和基础执行上都表现吃力，常常从有效游玩退化为滑稽的官僚主义。这条讨论借由这些结果进一步探问：大型推理模型、代理群，以及编写代码的执行框架是否真是交互式世界的合适架构，以及什么样的混合设计（宏观 LLM + 微观确定性控制）可能更有效。
对实验的总体反应
- 许多人觉得这些演示很有趣、很可爱，而且技术上令人印象深刻，但也强调了严重的局限性。
- 一些评论者认为这些代理“玩”Minecraft 的方式像回合制一样迟缓，让文明建设的感觉变成了官僚化且低效的流程。
- 也有人对嵌入式 Minecraft 查看器比对 AI 本身更感兴趣。
延迟、控制与架构
- 一个反复出现的主题是：由于高延迟以及逐 token 计算，大型 LLM 并不适合实时动作游戏。
- 评论者认为这些任务更像机器人控制：移动和战斗需要紧密、持续的反馈回路。
- 有人建议的模式是：对微观动作（移动、战斗、“点击狂刷循环”）使用确定性脚本或更小、更快的模型，而只让 LLM 负责更高层的规划。
- 也有人提到现有的一些方案：用一个负责亚秒级动作的 mod/bot、一个独立的宏观决策服务器，以及只负责策略/设计的 LLM，这样更实用。
行为、官僚主义与“中层经理”气质
- 多代理运行常常会在琐碎问题上演变成复杂的协调、委员会和流程（例如：仅一份骨粉的角色分配、对小失误的详细复盘）。
- 评论者把这与题材（“建造文明”类 Minecraft 内容）、人类训练数据，以及多代理系统普遍容易走向挑毛病和官僚化的倾向联系起来。
- 日志被广泛视为喜剧金矿：代理们像焦虑的高级工程师或惊慌失措的中层经理。
模型差异与推理局限
- 有人认为需要编写 JavaScript/Python 动作脚本，这暴露了 LLM 在对环境进行连续逻辑控制方面的困难。
- 也有人反驳说，让模型生成确定性的辅助代码其实是一种优势，也是降低错误和成本的自然方式。
- 这些实验带来的观察包括：
- 基于 GPT 的代理似乎更具攻击性、更爱探索，也更擅长诊断工具 bug 并分享绕过方法。
- 基于 Claude 的代理则往往更谨慎、防御性更强，沟通方式更像“Slack 风格”，在工具出 bug 时有时会得出任务不可能完成的结论。
代理群与更简单的系统
- 也有人质疑：如果所有代理都使用同一个底层模型，那么 50 个代理的“群体”究竟有多大价值。
- 批评点包括：角色重复、token 浪费、涌现出的办公室政治，以及与单个指令清晰的代理相比几乎没有实际收益。
- 支持多代理系统的人则认为：当代理确实拥有不同的工具、知识和作用范围，或者问题高度可并行化时，它们会很有帮助。