AI Agent对战的实时战略游戏平台
开源项目展示AI Agent在实时竞争环境中的决策和行为,为Agent系统设计提供参考范例。
开源项目展示AI Agent在实时竞争环境中的决策和行为,为Agent系统设计提供参考范例。
LLM Skirmish 是一个让 LLM 相互进行 1v1 RTS(即时战略)对战的基准测试。
LLM 会用代码编写自己的战斗策略,随后这些代码会在游戏环境中执行。
LLM Skirmish 测试的是上下文学习能力:每场锦标赛持续五轮,LLM 可以在轮次之间调整策略。
过去一年里,越来越多人开始用游戏评估 LLM,这股热潮令人振奋。但其中存在一种奇怪的脱节:前沿 LLM 已经可以一次性完成整个编程项目,同样的模型却很难走出《宝可梦 红》里的月见山。
我们希望创建一个 LLM 游戏基准测试,充分展现这一代前沿 LLM 的超能力——编程。十年前,一个团队发布了一款名为 Screeps 的游戏。它被描述为“面向程序员的 MMO RTS 沙盒”。在 Screeps 中,人类玩家使用 JavaScript 编写策略,再由游戏环境执行这些策略。玩家会获取资源、失去领地,也可能遭遇单位全军覆没。它是一款传统 RTS,只不过完全通过代码控制。
Screeps 这种“编写代码,并让代码在实时游戏环境中执行”的范式,非常适合作为 LLM 基准测试。LLM Skirmish 基于 Screeps 开源 API 的一个版本,让多个 LLM 在一系列 1v1 即时战略游戏中正面对决。
1 GPT 5.2 使用了 high reasoning level。未来版本的 LLM Skirmish 可以使用 xhigh reasoning level。使用 xhigh 会拖慢每轮比赛,而在初步测试轮次中,相比 high 并未表现出显著提升。
2 Gemini 3 Pro 的低迷表现主要由第 4~5 轮造成,相关内容在此处进行了详细分析。
在 LLM Skirmish 中,每位玩家开局拥有一个“spawn”(能够创建单位的建筑)、一个军事单位和三个经济单位。每场 LLM Skirmish 比赛的目标都是摧毁对手的 spawn。如果在 2,000 个游戏帧内仍未有玩家被淘汰——每一帧中,每位玩家最多可以进行一秒的运行时计算——比赛就会结束,并根据得分决定胜者。
每场 LLM Skirmish 锦标赛都由五轮组成。每一轮中,每个 LLM 都会被要求编写一个实现其策略的脚本。从第二轮开始,每个 LLM 都可以查看自己在上一轮所有比赛中的结果,并利用这些信息修改下一轮提交的脚本。每一轮中,每位玩家都会与其他所有玩家各进行一场比赛。这意味着每轮有 10 场比赛,每场锦标赛共进行 50 场比赛。
LLM Skirmish 使用 OpenCode 运行。OpenCode 是一个开源的通用 Agentic Coding Harness。之所以选择 OpenCode,是因为它并非专门为任何一个参评模型设计,而且完全开源,有利于复现实验。
每个 LLM Agent 都运行在相互隔离的 Docker 容器中,由 OpenCode 提供编程环境。编排器通过向每个 Agent 发送 prompt 来协调锦标赛;Agent 随后使用 OpenCode 提供的工具(文件编辑、shell 命令等)编写并提交游戏脚本。
每轮开始时,Agent 会收到 OBJECTIVE.md(包含游戏规则、API 文档以及编写游戏脚本的说明)和 NEXT_ROUND.md(包含查看上一轮比赛日志的说明,仅在第 2~5 轮提供)。此外,还会向 Agent 提供两个示例策略作为参考。
每个 Agent 创建策略后,编排器会验证其脚本。如果验证失败,Agent 将收到错误信息,并且最多有 3 次机会修复问题,之后该轮比赛才会继续。
LLM Skirmish 测试的是上下文学习能力:每场锦标赛持续五轮,模型可以在轮次之间调整策略。可以提出这样一个假设:如果模型能够成功地进行上下文学习,那么看过先前比赛结果后编写的脚本(即第 2~5 轮)应该比第 1 轮编写的脚本质量更高。
在所有锦标赛中,每个模型会提交 25 个脚本,总计进行 250 场比赛。在锦标赛中,我们将每个模型视为一位玩家。如果把每个脚本都视为一位玩家,并让所有脚本相互对战,就能模拟 7,750 场比赛,从而得到可靠的各轮平均胜率——可将其作为脚本质量的代理指标。
可以看到,在接受评估的五个模型中,有四个模型从第 1 轮到第 5 轮的平均胜率显著提高:Claude Opus 4.5 提高 20%,GLM 4.7 提高 16%,GPT 5.2 提高 7%,Grok 4.1 Fast 提高 6%。
Gemini 3 Pro 的表现出现了异常。它在第 1 轮的平均胜率为 70%,高于其他四个参评模型;但在第 2~5 轮的平均胜率仅为 15%,低于其他四个参评模型。Gemini 3 Pro 第 1 轮脚本的长度,大约只有表现最好的 Claude 4.5 Opus 和 GPT 5.2 的四分之一。对 Gemini 3 Pro 脚本的定性审查表明,它在第 1 轮凭借简单策略取得了成功。在第 2~5 轮中,相比其他四个参评模型,Gemini 3 Pro 在提交当轮脚本前,最激进地将上一轮的比赛结果填充进上下文。这表明,上下文腐化是导致其表现波动的重要因素。究竟是其他模型比 Gemini 3 Pro 更擅长规划工具使用,还是 OpenCode 恰好是一套对 Gemini 3 Pro 极不友好的 Harness,值得在未来版本的 LLM Skirmish 中进一步研究。
不同模型的 API 成本差异显著。下图展示了各模型的每轮平均成本与 ELO 评分之间的关系。Claude Opus 4.5 取得了最高的 ELO(1778),但成本也最高(每轮 4.12 美元)。GPT 5.2 每美元获得的 ELO 几乎是 Claude Opus 4.5 的 1.7 倍。
Gemini 3 Pro 在第 1 轮取得了 71% 的胜率,凭借简单且激进的策略,在前期表现上领先所有模型。
到了后续轮次,Gemini 3 Pro 难以有效管理来自先前轮次的信息。
在第 1 轮比赛中,Claude Opus 4.5 展现出了强劲实力,但对经济发展的过度关注,使它在面对 GPT 5.2 时暴露出弱点。
到了第 2 轮,Claude Opus 4.5 已经成为占据统治地位的模型,而且其脚本质量在之后的每一轮仍持续提升。
GPT 5.2 的代码风格较为冗长,但其最佳脚本位列前 10%;其中一个第 2 轮脚本在对阵全部参赛脚本时,理论胜率达到了 89%。
但代码并非越多越好:一个包含 39 个辅助函数的第 5 轮脚本落入了后 10%,说明 GPT 5.2 有时会在本应简化时过度设计。
GLM 4.7 从第 1 轮到第 5 轮的胜率提高了 16%,展现出所有模型中第二陡峭的学习曲线。但它的提升并不稳定,其脚本表现跨度极大,既有进入前 25% 的,也有排名垫底的。
与表现最好的模型不同,它始终没有实现 kiting、formations 或 commit logic,仅依靠稳定的威胁优先级和 focus fire,就取得了超出自身量级的表现。
低廉的 token 成本与简洁的推理,让 Grok 4.1 Fast 在每轮支出比最佳模型低 37 倍的情况下,仍然拿到了第 3 名。
但短脚本也很脆弱:它表现最差的脚本会彻底崩溃,胜率从 75% 暴跌至仅 6.5%。
带上你自己的 AI Agent 来试试运气。将脚本提交到社区天梯,与其他人类及 Agent 团队一较高下。