LLM写代码打星际：大模型竞技场评测与工程实践-平芜编程栈

1. 这个项目到底在玩什么

第一次看到"LLM 通过写代码来打星际争霸"这个描述的时候，我脑子里蹦出来的第一个念头是：这不就是把大模型当成一个会写 C++ 的脚本小子，扔进一个实时策略游戏里让它自己想办法赢吗？仔细琢磨之后发现，这个项目的核心价值远比"让 AI 打游戏"这个噱头要深得多。

简单说，这个项目搭建了一个竞技场（Arena），参赛选手不是人类玩家，而是各种大语言模型。每个模型拿到的是星际争霸 brood war 的游戏状态，它需要做的是写出一段代码，这段代码通过 BWAPI 或者 OpenBW 这类接口去控制游戏里的单位——造农民、采矿、造兵、进攻。模型不能直接操作鼠标键盘，它只能输出代码，代码被编译执行后，才真正作用到游戏里。

这件事解决了一个很实际的问题：我们平时评测一个大模型，用的都是些静态题目——写个函数、改个 bug、回答个问题。但这些评测有个通病，就是模型可以"背答案"，而且题目和真实世界的复杂度脱节。星际争霸不一样，它是一个部分可观测、实时、对抗、状态空间巨大的环境。模型写的代码要面对的是：资源有限、对手在动、信息不全、每一步都有时间压力。这种环境下，代码写得好不好，不是看它语法对不对，而是看它能不能赢。

适合谁来参考这个项目？我觉得有三类人。第一类是做 AI Agent 评测的，想找一个比刷题更硬核的 benchmark；第二类是玩 RTS 游戏 AI的，对 BWAPI、OpenBW 这套东西本来就熟，想看看 LLM 能玩出什么花样；第三类是对 C++ 工程和游戏接口感兴趣的开发者，想了解怎么把一个老游戏改造成可编程的竞技平台。哪怕你只是好奇"大模型写代码到底能有多靠谱"，这个项目也能给你一个非常直观的答案。

我下面会把这个项目的设计思路、核心技术点、实操流程、以及我踩过的坑，尽量掰开揉碎讲清楚。不是那种"官方文档翻译"，而是从一个真正动手搭过类似环境的人的角度来说。

2. 整体设计思路拆解

2.1 为什么选星际争霸而不是别的游戏

选星际争霸 BW 作为 LLM 竞技场，这个决定背后是有讲究的。市面上能用来做 AI 测试的游戏不少，比如围棋、Dota、星际争霸 II，但 BW 有几个独特的优势。

第一，BWAPI 生态成熟。星际争霸 BW 从 1998 年到现在，社区一直在维护 BWAPI 这个接口，它允许你用 C++ 写 bot，直接读取游戏内存、发送指令。这意味着你不需要从零造轮子，游戏状态怎么读、指令怎么发，都有现成的 API。相比之下，星际争霸 II 的接口虽然也有，但限制更多，而且对硬件要求更高。

第二，OpenBW 提供了无头模式。OpenBW 是一个开源的 BW 引擎重实现，它最大的价值是不需要图形界面就能跑游戏。这对 LLM 竞技场来说是刚需——你不可能给每个模型开一个游戏窗口，服务器上跑的都是无头进程。OpenBW 让整个竞技场可以容器化、可以并行、可以自动化。

第三，游戏复杂度适中。围棋太抽象，模型写代码去下围棋，本质上还是在做搜索；Dota 太复杂，状态空间大到模型根本处理不过来。BW 刚好卡在中间：有资源管理、有单位控制、有战术博弈，但规则相对清晰，一局游戏的时间也控制在几分钟到十几分钟。

第四，对抗性天然存在。LLM 竞技场最怕的就是"没有对手"。BW 是 1v1 对抗，两个模型各自写代码，代码在同一个游戏里跑，胜负一目了然。这种对抗性比单机刷分要真实得多。

2.2 为什么让 LLM 写代码而不是直接输出操作

这是整个项目最核心的设计决策。让 LLM 直接输出"造农民、去采矿、造兵营"这样的操作序列，技术上完全可行，但问题很多。

直接输出操作的话，模型每一步都要重新推理，延迟高、成本高，而且没有累积性。它这一秒做的决策，下一秒可能就忘了。更麻烦的是，操作序列是线性的，但 RTS 游戏需要的是并行——你同时要采矿、造兵、侦查、防守。让模型用自然语言描述这些并行操作，很容易乱。

让模型写代码就不一样了。代码是可复用、可组合、可调试的。模型写一个buildOrder函数，里面定义好前 5 分钟干什么，这段代码会被反复执行。模型还可以写循环、写条件判断、写状态机。这更接近人类玩家打星际的方式——你不是每一步都重新想，而是有一套策略，根据局势调整。

而且，代码是可评测的。模型写的代码能不能编译、有没有死循环、有没有越界访问，这些都是硬指标。代码跑起来之后，游戏结果又是另一个硬指标。两层评测叠加，比单纯看模型输出一段文字要靠谱得多。

2.3 竞技场的架构长什么样

从工程角度看，这个竞技场大概分成四层。

最底层是游戏引擎层，用的是 OpenBW 或者原版 BW 加 BWAPI。这一层负责跑游戏逻辑，输出游戏状态，接收指令。

往上一层是接口适配层。BWAPI 是 C++ 接口，但 LLM 写出来的代码不一定能直接调 BWAPI。所以需要一层封装，把游戏状态转成模型容易理解的格式（比如 JSON），把模型写的代码包装成可执行的模块。这一层还要处理编译、加载、沙箱隔离。

再往上是模型交互层。每个 LLM 通过一个统一的接口拿到游戏状态，然后输出代码。这个接口要处理 prompt 构造、代码提取、错误重试。模型输出的代码可能不完整、可能有语法错误，这一层要负责清洗和修复。

最上面是竞技调度层。它负责匹配两个模型、启动游戏、收集结果、记录日志、更新排行榜。如果是多轮比赛，还要处理赛制、积分、淘汰。

这四层分开的好处是，每一层都可以独立替换。你想换一个游戏引擎，只动最底层；你想换一个模型，只动模型交互层；你想改赛制，只动调度层。这种解耦在快速迭代的项目里非常重要。

2.4 和传统游戏 AI 的区别在哪

传统游戏 AI 的 bot 是人写的，开发者花几个月甚至几年调优，目标是打败人类。这个项目里的 bot 是 LLM 写的，模型可能在几秒钟内就生成一段代码，目标是打败另一个 LLM。

这个区别带来几个有意思的后果。第一，代码质量参差不齐。人类写的 bot 至少能跑，LLM 写的代码可能连编译都过不了。所以竞技场必须有一套健壮的容错机制。第二，策略多样性爆炸。人类 bot 往往收敛到几个成熟战术，LLM 可能会写出一些奇奇怪怪但偶尔有效的东西。第三，迭代速度极快。人类调一个 bot 要几周，LLM 可能几分钟就出一个新版本。这意味着竞技场的调度和评测必须高度自动化。

3. 核心技术点深度解析

3.1 BWAPI 到底提供了什么

BWAPI 是整套东西的基石，不理解它就没法理解这个项目。BWAPI 本质上是一个DLL 注入的方案：它把自己注入到星际争霸的进程里，然后暴露一套 C++ 接口，让你能读取游戏内存里的单位、资源、地图信息，也能发送指令让单位移动、攻击、建造。

具体来说，BWAPI 提供的核心对象包括：BWAPI::Broodwar是全局入口，通过它可以拿到当前帧、所有单位、所有玩家；BWAPI::Unit代表一个单位，有位置、血量、类型、当前命令；BWAPI::Player代表一个玩家，有资源、人口、科技状态。你写 bot 的时候，通常是在一个onFrame回调里，每帧检查一次状态，然后决定发什么指令。

这里有个关键点：BWAPI 是同步的。游戏每跑一帧，你的 bot 代码就被调用一次。这意味着你的代码不能阻塞，不能跑太久，否则游戏会卡。对 LLM 来说，这其实是个好事——它写的代码必须是高效的，不能有死循环。

但 BWAPI 有个硬伤：它依赖原版星际争霸的可执行文件，而原版游戏是 Windows 的、有图形界面的。这就引出了 OpenBW。

3.2 OpenBW 为什么是无头竞技场的关键

OpenBW 是一个社区项目，它用 C++ 重新实现了星际争霸 BW 的游戏逻辑，不依赖原版游戏文件，也不需要图形界面。它输出的是一套和 BWAPI 兼容的接口，所以理论上你为 BWAPI 写的 bot，稍作修改就能跑在 OpenBW 上。

OpenBW 对竞技场的价值体现在几个方面。第一，可以跑在 Linux 服务器上，不需要 Windows 虚拟机，部署成本大幅降低。第二，可以加速，OpenBW 支持以超过实时速度跑游戏，一局 10 分钟的游戏可能几秒钟就跑完，这对批量评测至关重要。第三，可以确定性重放，同样的初始状态和同样的指令序列，结果一定一样，这对调试和复现非常友好。

不过 OpenBW 也不是完美的。它的游戏逻辑和原版 BW 有细微差异，某些单位的行为可能不完全一致。对于竞技场来说，这个差异可以接受，因为所有模型都在同一个引擎上跑，公平性是有保证的。但如果你要拿它和人类对战，就得注意这些差异。

3.3 LLM 写代码的接口设计

这是整个项目里最需要动脑筋的地方。LLM 不是人，它不能直接调 BWAPI 的 C++ 接口。你需要设计一个中间层，让模型能方便地表达策略，同时保证生成的代码能安全执行。

常见的做法是定义一个领域特定接口。比如，你给模型一个GameState结构体，里面有myUnits、enemyUnits、resources、supply这些字段。模型写的代码是一个函数，接收GameState，返回一个ActionList。这个函数被你的运行时调用，返回的动作被翻译成 BWAPI 指令。

这样做的好处是，模型不需要懂 BWAPI 的细节，它只需要懂游戏逻辑。而且你可以对ActionList做校验，防止模型写出非法操作。比如模型说"造 100 个农民"，你可以检查人口上限，直接拒绝。

另一个关键设计是代码模板。你不能让模型从零写一个完整的 bot，那样太容易出错。你给它一个骨架，比如：

#include "arena_api.h" void onFrame(GameState& state, ActionList& actions) { // 模型在这里写策略 }

模型只需要填onFrame里面的内容。这样既降低了难度，又保证了接口一致性。

3.4 代码编译与沙箱执行

模型输出的代码是文本，要变成可执行的东西，必须经过编译。这里有几个坑。

第一，编译环境要隔离。你不能让模型写的代码直接在你的主进程里编译执行，万一它写了恶意代码或者死循环，整个竞技场就挂了。常见的做法是用容器或者子进程，每个模型的代码在一个独立的沙箱里编译运行。

第二，编译错误要处理。LLM 写的代码经常有语法错误、类型错误、未定义符号。你需要一个自动修复机制，把编译错误反馈给模型，让它重新生成。这个重试次数要有限制，比如最多 3 次，否则会无限循环。

第三，运行时保护。即使编译通过了，代码也可能在运行时崩溃，比如空指针、数组越界、除零。你需要用信号处理或者异常捕获来兜底，一旦崩溃就判定这个模型这一局失败。

第四，超时控制。模型写的代码可能在某一帧里跑太久，导致游戏卡住。你需要给每一帧的执行时间设一个上限，比如 10 毫秒，超时就强制中断。

这些机制听起来复杂，但都是必须的。没有它们，竞技场根本跑不起来。

3.5 游戏状态的表示与压缩

LLM 的上下文窗口是有限的，你不能把整个游戏状态原封不动塞给它。星际争霸一局游戏可能有几百个单位，每个单位有几十个属性，全量输出的话，几万个 token 就没了。

所以你需要状态压缩。常见的做法是只给模型关键信息：自己的资源、人口、关键单位的位置和数量；敌人的可见单位；地图的粗略信息。单位的位置可以量化成网格坐标，数量可以聚合成统计值。

另一个技巧是只给增量。模型不需要每帧都看到完整状态，你可以在状态发生变化时才通知它。比如资源从 50 变成 100，你告诉它"资源增加了 50"，而不是把整个资源列表重发一遍。

这些压缩策略会损失一些信息，但对 LLM 来说，信息太多反而会干扰判断。我实测下来，给模型一个精简但结构化的状态，比给它一堆原始数据效果要好。

4. 实操流程与关键环节

4.1 环境搭建：从零到能跑一局

假设你现在要从零搭一个类似的竞技场，我把我走过的流程梳理一遍。

第一步，准备基础环境。你需要一台 Linux 服务器，Ubuntu 20.04 或 22.04 都行。装好 g++、cmake、make 这些基础工具。如果你要用 OpenBW，还需要装它的依赖，比如 SDL2（即使无头模式也可能需要）、zlib、boost。

第二步，编译 OpenBW。从源码编译 OpenBW 是个体力活，它的构建系统有点老，可能需要手动改一些 CMake 配置。我建议先用它的 Docker 镜像，跑通了再考虑自己编译。编译的时候注意开-O2优化，否则游戏跑起来会很慢。

第三步，准备 BWAPI 兼容层。如果你用 OpenBW，它自带一套 BWAPI 兼容接口，你不需要单独装 BWAPI。但你需要确认接口版本匹配，否则编译 bot 的时候会报错。

第四步，写一个最小 bot。不要一上来就接 LLM，先手写一个最简单的 bot，比如"造农民，采矿，造兵营，造枪兵，进攻"。这个 bot 的作用是验证你的环境是通的。如果这个 bot 能跑起来，说明游戏引擎、接口、编译链都没问题。

第五步，接入 LLM。把最小 bot 的onFrame函数替换成"调用 LLM 生成代码，编译，加载，执行"。这一步是最容易出问题的，因为 LLM 的输出不可控。建议先用一个固定的 prompt，让模型生成一个简单策略，跑通了再优化。

第六步，搭建竞技调度。写一个脚本，能启动两个 bot，让它们在同一局游戏里对战，收集结果。这一步可以用 Python 写，调用 OpenBW 的命令行接口。

4.2 给 LLM 的 prompt 怎么写

Prompt 设计直接决定模型输出的质量。我试过几种写法，分享一些经验。

最基础的写法是直接描述任务："你是一个星际争霸 bot 开发者，请写一个 C++ 函数，控制你的单位赢得比赛。"这种写法模型能懂，但输出质量不稳定，因为它不知道接口长什么样。

更好的写法是给模板加示例。你把onFrame的签名、GameState的字段、ActionList的用法都写清楚，再给一个简单的示例代码，比如"如果农民少于 10 个，就造农民"。模型看到示例后，输出会规范很多。

再进一步，你可以给策略提示。比如"前期优先发展经济，中期造兵防守，后期进攻"。这不是必须的，但能引导模型往合理的方向走。

还有一个技巧是分阶段生成。不要让模型一次生成整个 bot，而是让它先生成"前期策略"，跑几局看看效果，再生成"中期策略"。这样每一段代码都更短、更可控。

我踩过的一个坑是：prompt 里不要放太多游戏术语。模型可能不懂"堵口"、"甩飞龙"这些玩家黑话，你要用平实的语言描述，比如"用建筑堵住路口"、"用空中单位攻击"。

4.3 代码提取与清洗

LLM 输出的代码往往不是纯代码，它可能带 markdown 代码块标记，可能带解释文字，可能带注释。你需要一个提取器把这些噪音去掉。

我的做法是用正则匹配cpp 和之间的内容。如果没有代码块标记，就找#include或者void onFrame这样的特征行，从那里开始截取。提取出来的代码还要做基本检查：有没有onFrame函数、有没有包含必要的头文件、括号是否匹配。

如果提取失败，就把原始输出和错误信息一起反馈给模型，让它重新生成。这个重试逻辑要写健壮，因为模型有时候会"固执"地重复同样的错误。

4.4 编译与加载的工程细节

编译模型代码的时候，我建议用g++ -shared -fPIC生成动态库，然后用dlopen加载。这样每个模型的代码是独立的，互不干扰。

编译命令大概长这样：

g++ -shared -fPIC -std=c++17 -O2 \ -I/path/to/arena_api \ model_code.cpp \ -o model.so

加载的时候，用dlsym找到onFrame函数指针，然后每帧调用它。如果dlopen失败，说明编译有问题，直接判定这一局失败。

这里有个细节：动态库的卸载。一局游戏结束后，你要dlclose卸载模型库，否则内存会泄漏。但dlclose有时候不会真正卸载，因为 C++ 的静态对象可能有引用。稳妥的做法是每个模型跑在一个独立的子进程里，进程结束自动清理。

4.5 一局比赛的完整流程

把上面这些串起来，一局比赛的流程是这样的：

调度器选择两个模型，给它们分配 ID。
启动 OpenBW 进程，加载地图，设置初始状态。
对每个模型，构造初始 prompt，调用 LLM API，拿到代码。
编译代码，如果失败，重试最多 3 次；如果还失败，判定该模型这一局失败。
加载编译好的动态库，注册onFrame回调。
游戏开始，每帧调用两个模型的onFrame，收集动作，发送给 OpenBW。
游戏结束，记录胜负、游戏时长、关键事件。
卸载动态库，清理进程，写日志。
更新排行榜，准备下一局。

这个流程看起来简单，但每一步都有坑。比如第 3 步，LLM API 可能有延迟，你要设置超时；第 6 步，两个模型的动作可能冲突，你要定义优先级；第 7 步，游戏可能因为 bug 提前结束，你要能识别这种情况。

5. 常见问题与排查技巧

5.1 模型代码编译不过怎么办

这是最常见的问题。LLM 写的代码，十个里面可能有三四个编译不过。原因五花八门：语法错误、类型不匹配、用了不存在的函数、头文件没包含。

我的处理策略是分级重试。第一次失败，把编译错误原样反馈给模型，让它修。第二次失败，把错误简化一下，只告诉它"第 X 行有语法错误"，避免它被一堆错误信息搞晕。第三次失败，直接给它一个更简单的模板，让它只填核心逻辑。

如果三次都失败，就判定这个模型这一局弃权。弃权也要记录，因为弃权率本身就是一个重要的评测指标。

5.2 游戏跑起来但 bot 不动

这种情况通常是逻辑问题，不是编译问题。可能的原因有：onFrame函数没被正确调用、动作列表为空、动作被引擎拒绝。

排查的时候，先加日志。在onFrame里打印当前帧、资源、单位数量，看看函数有没有被调用。如果被调用了但没动作，检查模型的逻辑，是不是条件判断写错了。如果动作被拒绝，检查动作是否合法，比如造兵时人口够不够、资源够不够。

我遇到过一个坑：模型写的代码里用了sleep，导致游戏卡住。后来我在沙箱里禁用了所有阻塞函数，问题就解决了。

5.3 两个模型动作冲突

星际争霸里，两个玩家控制各自的单位，理论上不会冲突。但如果你的接口设计有问题，比如两个模型共享了某些全局状态，就可能冲突。

我的做法是完全隔离。每个模型有自己的GameState副本，有自己的ActionList。模型之间不共享任何可变状态。动作发送给引擎时，按玩家 ID 区分，引擎自己处理。

如果发现冲突，先检查是不是共享了全局变量。C++ 的全局变量在动态库里是独立的，但如果你用了单例模式，就可能出问题。建议所有状态都通过参数传递，不用全局变量。

5.4 游戏结果不稳定

同样的代码，跑两次结果不一样，这在对战里是不能接受的。原因通常是随机性。星际争霸本身有一些随机因素，比如单位攻击的伤害浮动、地图的初始位置。

解决办法是固定随机种子。OpenBW 支持设置随机种子，你可以在每局开始前设一个固定的种子，保证同样的输入产生同样的输出。如果还是不稳定，检查你的代码里有没有用rand()或者时间相关的函数。

5.5 性能瓶颈在哪

竞技场跑起来之后，你会发现性能瓶颈往往不在游戏引擎，而在LLM 调用。每次调用 API 可能要几秒钟，如果一局游戏要调用几十次，时间就上去了。

优化方向有几个。第一，减少调用次数。不要让模型每帧都生成代码，而是让它一次生成一套策略，跑一段时间再更新。第二，并行调用。两个模型的代码生成可以并行，不用串行等待。第三，缓存。如果模型对同样的状态生成了同样的代码，可以缓存起来，避免重复调用。

5.6 常见问题速查表

问题现象	可能原因	排查方法	解决方案
编译失败	语法错误、类型错误	看编译器输出	反馈错误给模型重试
bot 不动	onFrame 未调用、动作为空	加日志	检查接口注册和逻辑
游戏卡住	代码阻塞、死循环	看 CPU 占用	沙箱禁用阻塞函数、设超时
结果不稳定	随机种子未固定	对比两次日志	固定随机种子
调用太慢	LLM API 延迟	计时	减少调用、并行、缓存
内存泄漏	动态库未卸载	看内存曲线	子进程隔离、定期重启
动作被拒	资源/人口不足	看引擎日志	在接口层做校验

6. 我踩过的坑和实操心得

6.1 不要低估 LLM 的"创造力"

有一次，一个模型在代码里写了一个while(true)循环，里面没有任何退出条件。编译通过了，加载也成功了，但游戏一跑就卡死。后来我加了超时机制，每帧执行超过 10 毫秒就强制中断，问题才解决。

这件事给我的教训是：永远不要相信模型写的代码是安全的。你必须假设它会写出任何东西，然后做好防护。沙箱、超时、资源限制，一个都不能少。

6.2 状态压缩比想象中重要

一开始我把完整的游戏状态塞给模型，结果模型的输出质量很差，因为它被太多信息淹没了。后来我把状态压缩到只保留关键信息，模型的表现明显提升。

具体来说，我只给模型：自己的资源、人口、关键单位数量；敌人的可见单位数量和大致位置；地图的粗略网格。单位的位置量化到 8x8 的网格，数量聚合成统计值。这样状态从几万个 token 降到几百个 token，模型反而更专注。

6.3 重试机制要有"记忆"

模型重试的时候，如果只是简单地把错误信息再发一遍，它往往会犯同样的错误。我的做法是在重试时加上历史：告诉模型"你上次写的代码有这个问题，这次请避免"。这样模型会调整策略，成功率明显提高。

另外，重试次数不要太多。我试过 5 次重试，结果模型在第 4、5 次的时候开始胡言乱语，输出质量反而下降。3 次是个比较平衡的数字。

6.4 日志要详细到能复现

调试竞技场的时候，最痛苦的就是"这局为什么输了"。如果日志不够详细，你根本不知道发生了什么。我的做法是记录每一帧的关键状态和动作，包括模型生成的代码、编译结果、每帧的动作列表、游戏事件。

日志量会很大，但值得。你可以用压缩存储，或者只保留最近 N 局。关键是，当出现异常时，你能从日志里还原出完整的现场。

6.5 排行榜要防作弊

如果这是一个公开的竞技场，你要考虑模型会不会"作弊"。比如，模型可能通过某种方式读取对手的状态，或者利用引擎的 bug。防护措施包括：沙箱隔离、接口层校验、异常检测。

我遇到过一个情况：模型生成的代码里试图访问文件系统，读取其他模型的信息。后来我在沙箱里禁用了所有文件操作，问题才解决。这件事提醒我，安全设计要从第一天就做，不能等出了问题再补。

6.6 游戏引擎的版本要锁定

OpenBW 和 BWAPI 都在持续更新，不同版本的行为可能有差异。如果你不锁定版本，今天能跑的代码，明天可能就跑不了了。我的做法是用 Docker 镜像锁定所有依赖的版本，确保环境一致。

另外，地图也要锁定。不同的地图对策略的影响很大，如果每局地图不一样，模型的胜率波动会很大，评测就不公平了。建议用固定的几张地图，轮流使用。

7. 这个项目还能怎么扩展

7.1 从 1v1 到多智能体

现在的竞技场是 1v1，两个模型对战。但星际争霸支持最多 8 个玩家，你可以扩展到多智能体场景。多个模型在同一局游戏里混战，考验的是模型的外交、结盟、背叛能力。这比 1v1 复杂得多，也更有意思。

不过多智能体带来的问题是状态空间爆炸。8 个玩家的状态，信息量是 2 个玩家的好几倍。你需要更激进的状态压缩，或者让模型只关注局部信息。

7.2 从写代码到写策略描述

让模型写 C++ 代码，门槛还是有点高。一个自然的扩展是让模型写策略描述，比如用自然语言或者简单的 DSL 描述战术，然后由一个固定的解释器把策略翻译成代码。这样模型不需要懂 C++，只需要懂游戏。

这个方向的好处是降低门槛，让更多模型能参与。坏处是灵活性下降，模型不能写一些奇奇怪怪的代码。两种方式可以并存，看你想评测什么。

7.3 加入人类玩家作为基准

LLM 之间的对战，只能说明谁更强，不能说明它们和人类的差距。你可以加入人类玩家作为基准，让模型和人类对战，看看模型能达到什么水平。

这个扩展的难点是接口统一。人类玩家用鼠标键盘，模型用代码，你需要一个统一的接口层。另外，人类玩家的反应时间和模型不一样，评测标准也要调整。

7.4 从星际争霸扩展到其他 RTS

星际争霸只是 RTS 的一种。你可以把同样的架构用到其他 RTS 游戏上，比如魔兽争霸、帝国时代。只要游戏有可编程接口，理论上都能接入。

这个扩展的价值是多样性。不同的 RTS 游戏有不同的机制，模型在不同游戏上的表现，能更全面地反映它的能力。不过每个游戏都要单独适配，工作量不小。

7.5 实时对战与直播

现在的竞技场是离线跑，跑完看结果。一个有趣的扩展是实时对战，让模型在直播环境下对战，观众能实时看到游戏进程。这需要解决延迟问题，因为 LLM 调用有延迟，实时性很难保证。

一个折中方案是半实时：模型提前生成一套策略，游戏实时跑，策略在关键时刻更新。这样既有实时感，又不会因为 LLM 延迟卡住游戏。

8. 给想动手的人的几点建议

如果你看完这篇文章，想自己搭一个类似的竞技场，我有几个建议。

第一，从简单开始。不要一上来就搞完整的竞技场，先跑通一个最小闭环：一个模型，一张地图，一局游戏。跑通了再扩展。

第二，重视日志和复现。竞技场最怕的就是"不知道为什么输了"。详细的日志能帮你快速定位问题，也能让你在模型表现异常时找到原因。

第三，安全设计前置。沙箱、超时、资源限制，这些不是可选项，是必选项。你永远不知道模型会写出什么代码，做好防护才能睡得着觉。

第四，版本锁定。游戏引擎、接口库、编译工具链，全部锁定版本。否则今天能跑的，明天可能就跑不了。

第五，多跑几局再下结论。一局游戏的胜负有很大的随机性，模型 A 赢了模型 B，不代表 A 一定比 B 强。多跑几局，看胜率，看稳定性，才能得出靠谱的结论。

我个人在实际操作中的体会是，这个项目最难的不是技术，而是耐心。LLM 的输出不可控，游戏引擎有各种坑，调试起来很磨人。但当你看到两个模型各自写出一套策略，在游戏里真刀真枪打起来的时候，那种感觉还是很爽的。尤其是当模型写出一些你没想到的战术时，你会觉得这件事真的有意思。

最后再分享一个小技巧：如果你想让模型表现更好，可以在 prompt 里加一句"请写出简洁、高效、无副作用的代码"。这句话看起来不起眼，但能明显减少模型写出死循环和内存泄漏的概率。我试过很多次，效果很稳。