6个AI组队开发类GTA开放世界游戏:AI小镇项目全解析
当“AI 编程”还停留在帮你补全函数、写个测试用例的阶段时已经有人用 6 个 AI 组成了一支“游戏开发小队”从零做出了一个类 GTA 的开放世界游戏。最近在 GitHub 上看到my_ai_town这个项目第一眼就被吸引了它不是又一个纸面概念而是一个能在本地跑起来的“AI 小镇”。小镇里的每一个 NPC 都不是传统游戏里那种只会重复对话的脚本而是由大模型驱动的智能体他们有自己的记忆会记住昨天和谁吵过架有自己的计划早上会去咖啡馆晚上可能去广场散步甚至当你故意制造一个突发事件他们还会根据过往经验生成“合情合理”的反应。这种感觉非常接近 GTA 中那种“世界仍在运转”的沙盒体验只不过驱动角色的不是游戏策划写好的剧情线而是通用大语言模型。很多开发者看到这类项目的第一反应是“6 个 AI 到底怎么配合这不会又是标题党吧”我的判断是AI 目前还不能替你完成一款 3A 大作的完整生产管线但确实已经能把一个需要策划、程序、美术、测试多人协作数月的可玩原型压缩到个人开发者几天就能跑通的程度。真正的难点不在某一个 AI 有多强而在于如何把不同类型的 AI 放进合适的“岗位”让它们形成流水线。这篇文章会围绕my_ai_town这个开源项目展开拆解 6 个 AI 如何分工、NPC 的“记忆”和“计划”是怎么设计的、本地环境如何从零搭建、核心代码如何改造以及你踩坑时最需要关注哪几个环节。1. 这篇文章真正要解决的问题如果你是第一次接触“AI 做游戏”这个方向肯定会被各种信息淹没有人说用 AI 能画游戏原画有人说 AI 能写游戏代码还有人直接拿大模型驱动 NPC 对话。但单个 AI 能力再强也只是“工具”真正决定成败的是组合方式。这里真正要解决三个问题第一游戏原型的开发成本问题。传统开放世界游戏之所以贵是因为需要大量人工设计地图、角色行为树、对话文本。而大模型驱动的 NPC 可以让世界“自己讲故事”大幅度减少脚本编写量。第二多个 AI 工具如何协作。一个完整的 AI 游戏项目里需要代码生成、美术素材、角色文案、测试反馈、环境部署等多个环节。单纯用 ChatGPT 聊天或者单纯用 Stable Diffusion 画图都不可能独立完成一个项目。你需要一套清晰的“AI 团队”工作流。第三开发者如何快速从零跑通。很多项目文档不全或者严重依赖国外 API导致新手倒在第一步。本文给出的步骤会尽量覆盖从克隆仓库、安装依赖、配置密钥到启动运行的全过程。这篇文章适合谁不是那些想一步登天做出 GTA 6 的人而是具备基本编程基础、想做 AI 游戏原型或想要学习 AI Agent 工程化的开发者。如果你已经会 Python 或 JavaScript那么跟着本文跑通一个项目并理解背后的 Agent 设计逻辑会比单纯刷十篇“AI 工具推荐”有用得多。2. AI 小镇项目概览它为什么像 GTA从项目名称和下载包来看my_ai_town是一个桌面端可运行的开源项目。游戏本身是一个俯视角的 2D 小镇玩家可以操控角色在街区移动周围有房屋、公园、咖啡馆等场景。看到这里你会发现它和 GTA 有非常相似的地方开放地图、自由探索、大量可交互 NPC。但和 GTA 最不一样的地方是 NPC 的决策方式。传统游戏里NPC 的行为逻辑通常由状态机或行为树控制。比如if player is near: if player has key: open door else: say 你需要一把钥匙这种模式的优点是稳定可控缺点是“所有 NPC 都很像工具人”。而my_ai_town这类项目用的是大语言模型驱动的 Agent 架构。每个 NPC 都有独立的记忆流、计划和反思机制。他们看到的、听到的、做过的事都会形成记忆当需要做出反应时模型会根据当前场景和历史记忆生成一个自然语言指令再映射为游戏里的移动、对话或交互行为。因此玩家在游戏中看到的不是预先写好的几句台词而是每个 NPC 基于自身“人生经历”生成的动态反应。这和斯坦福大学的 Generative Agents 研究思路非常一致。my_ai_town可以看作是一个社区版、可二次开发的实现。它不需要 PS5 级别的画质但抓住了 GTA 这类游戏的核心体验——世界里的角色看起来是“活着”的。从工程角度看它又非常轻量前端用 Web 技术渲染后端通过 API 调用大模型数据用 JSON 文件或本地数据库存储。这种结构对个人开发者非常友好不需要重型服务器也方便调试。3. 六类 AI 如何组成游戏开发小队所谓“6 个 AI 联手”并不是指 6 个 AGI 坐在一个房间里开需求会而是指游戏生产链路中 6 种不同能力的 AI 协同工作。下面我会用一个表格给出分工然后逐个说明它们在项目中承担的具体职责。AI 角色对应人类岗位常用工具示例负责内容AI 编程助手程序员GitHub Copilot、Cursor、Claude Code编写后端逻辑、Agent 框架、NPC 决策代码AI 绘画生成美术Stable Diffusion、Midjourney、DALL·E生成地图瓦片、角色头像、道具图标AI 文案与对话策划/编剧ChatGPT、Claude、DeepSeekNPC 人设、对话风格、任务剧情AI 产品设计主策划ChatGPT MindMap游戏规则、玩法循环、系统边界AI 测试助手测试工程师Playwright LLM自动跑通流程、生成测试报告、分析日志AI 部署运维运维Docker 自动化脚本环境初始化、依赖安装、进程守护、日志监控在my_ai_town项目里这 6 类 AI 并不是每时每刻都在工作。最核心的是前四个编程、美术、文案、架构。测试和部署更多是辅助作用但对于本地快速验证也必不可少。为什么强调“分工”因为大模型存在“能力边界”。你让 GPT-4 写一段 Python 调用 OpenAI API 很轻松但让它直接生成一套完整的 GTA 式地图素材效果通常很差。反过来Stable Diffusion 能画出漂亮的像素风角色却没法帮你调通 WebSocket 通信。把对的任务交给对的基础模型才有实践价值。4. 核心原理大模型怎么让 NPC 拥有“记忆”和“计划”要让 NPC 表现得像真实居民不能只是每次随机吐一句话而是需要一个完整的“记忆-反思-计划”循环。4.1 记忆流Memory Stream每个 NPC 都会把经历写成结构化记录存到记忆流里。记忆通常包含时间戳、观察内容、参与者、地点等。比如{ time: 2025-01-20T08:15:00, npc: 林晓, event: 在咖啡馆遇到了李明聊起周末的市集活动, location: coffee_shop }记忆流是 Agent 的“数据库”也是它理解世界的基础。4.2 记忆检索Memory Retrieval当游戏里发生新事件比如“玩家在小镇广场放了一个烟花”NPC 不一定会把这件事写进长期记忆但需要先根据当前场景检索相关历史记忆。检索的作用类似于搜索通过时间近、重要程度高、语义相关三个维度找到几条最相关的记忆作为 Prompt 上下文。这段代码就是记忆检索的简化逻辑# memory_retrieval.py def retrieve_memories(npc_name, current_context, k5): memories load_memories(npc_name) scored [] for mem in memories: score 0.0 # 1. 时间衰减越近的分数越高 score recency_score(mem[time]) # 2. 关键词匹配上下文相关的重要事件加分 score relevance_score(mem[event], current_context) scored.append((score, mem)) scored.sort(keylambda x: x[0], reverseTrue) return [mem for _, mem in scored[:k]]4.3 反思Reflection如果所有行为都依赖原始记忆模型很容易被琐碎信息干扰。反思机制会让 NPC 定期把大量低层记忆总结成高层结论。例如NPC 连续三天看到李明在傍晚去同一个地方反思系统会生成一个新记忆“李明最近似乎总是傍晚去图书馆可能是在准备考试。”这个新记忆会进入记忆流并影响后续行为。4.4 计划Planning有了记忆和反思NPC 就能生成行动计划。计划通常是一个分层结构上午做什么、下午做什么、突发情况怎么应对。在代码层面它可能是def generate_plan(memories, current_time): prompt f你是一个小镇居民根据你的记忆制定当前时刻的计划。 return llm_generate(prompt)这个计划并不需要特别精细只需要能指导 NPC 在某个时间点移动到目的地然后触发相应动作即可。这样的设计让 NPC 看起来有自己的“生活节奏”而不是站桩等玩家。5. 环境准备与项目启动从零跑通 AI 小镇接下来进入实操环节。由于my_ai_town是开源项目且下载包同时提供了 Mac 和 Windows 版本所以本地启动思路是通用的。5.1 你需要准备的工具工具版本建议作用Git任意较新版本拉取项目代码Node.js16 或以上运行前端与部分构建工具Python3.9 或以上运行后端 Agent 服务npm 或 yarn任意较新版本安装前端依赖LLM API KeyOpenAI、智谱、通义等大模型对话与理解能力API Key 是真正容易踩坑的地方。如果无法访问国外大模型服务可以先把OPENAI_BASE环境变量替换为国内兼容接口或者使用国产模型。项目配置文件里一般会有模型名称、API 地址、密钥等字段具体以仓库说明为准。5.2 拉取项目与安装依赖先克隆仓库再进入目录git clone https://github.com/mewamew/my_ai_town.git cd my_ai_town如果项目是前后端分离的仓库通常会有backend/和frontend/两个目录。先安装 Python 依赖python -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate pip install -r requirements.txt再安装前端依赖npm install如果requirements.txt文件位置不同可以在仓库里用find . -name requirements.txt快速定位。5.3 配置环境变量项目根目录下通常会有一个.env.example文件。复制一份为.envcp .env.example .env然后编辑.env填入你的 API Key# .env OPENAI_API_KEYsk-xxxxxxxxxxxxxxxxxxxxxxxx MODEL_NAMEgpt-4 MAX_TOKEN1024 TEMPERATURE0.7重点提醒.env里面包含密钥千万不要上传到 Git更不要在截图里发给别人。项目仓库的.gitignore通常会忽略它但你也要自己留意。5.4 启动后端服务后端服务负责加载 NPC 配置、调用大模型、处理对话与行动。启动命令通常类似python main.py启动后终端会出现类似Server started at port 8000的日志。如果端口被占用可以先查一下端口lsof -i :8000然后修改配置文件里的端口号。5.5 启动前端页面另开一个终端在项目根目录下执行npm run dev前端开发服务器启动后会输出一个本地访问地址例如http://localhost:5173。在浏览器打开这个地址就能看到 AI 小镇的主界面。下载包中提供的“ai小镇_macw”其实就是一个已经配置好运行环境的桌面版本适合不熟悉命令行的朋友直接试玩。但从开发学习角度看我更推荐用命令行方式自己拉一遍这样后续改代码和调试会方便很多。6. 三个核心示例代码让 NPC 会思考、会说话、会行动纯跑通项目只能算体验者想让 NPC 变成自己的“镇民”需要读懂并修改关键代码。下面给出三个最核心的代码示例分别对应对话、记忆、行动决策。6.1 示例一调用大模型生成 NPC 的对话反应每个 NPC 在说话前都需要把“角色设定 当前事件 相关记忆”拼成 Prompt再请求大模型。# npc_agent.py import os from openai import OpenAI client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) def get_npc_response(npc_name, context, memory_list): memory_str \n.join([f- {m[event]} for m in memory_list]) prompt f 你叫{npc_name}是AI小镇的一名居民。 你性格温和喜欢观察细节。 你最近记得的事情 {memory_str} 刚刚发生的场景 {context} 请用不超过两句话给出你的自然反应。 resp client.chat.completions.create( modelos.getenv(MODEL_NAME, gpt-4), messages[{role: user, content: prompt}], temperaturefloat(os.getenv(TEMPERATURE, 0.7)), max_tokensint(os.getenv(MAX_TOKEN, 1024)) ) return resp.choices[0].message.content.strip()这段代码的关键是 Prompt 设计。NPC 的性格、记忆和当前事件必须同时出现模型才能生成稳定、且有个人风格的回复。如果你把记忆列表去掉得到的就是一段泛泛而谈的话失去了“小镇居民”的特色。6.2 示例二记忆的存储与读取记忆是 NPC 的长期财富。每次发生事件都应该写进记忆文件。# memory_store.py import json from datetime import datetime def save_memory(npc_name: str, event: str): record { time: datetime.now().isoformat(), event: event } with open(fmemory_{npc_name}.json, a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n) def load_recent_memories(npc_name: str, k: int 5): memories [] try: with open(fmemory_{npc_name}.json, r, encodingutf-8) as f: lines f.readlines()[-k:] for line in lines: memories.append(json.loads(line)) except FileNotFoundError: pass return memories使用建议保存记忆时尽量使用结构化数据而不仅是纯文本。这样后续做检索、过滤和统计都会方便很多。my_ai_town项目里可能用的是 SQLite 或 JSON 文件这里给出 JSON 的轻量方案方便你读懂项目逻辑。6.3 示例三NPC 的决策循环NPC 在游戏循环中需要根据当前状态决定下一步行动。这里以一个简化版决策函数为例// npc_scheduler.ts interface Memory { time: string; event: string; } function decideAction(memories: Memory[], currentTime: number): string { const hungry memories.some(m m.event.includes(饥饿)); const danger memories.some(m m.event.includes(争吵)); if (danger) { return 远离争吵者去公园散步; } if (hungry) { return 去餐厅点一份午餐; } if (currentTime 19) { return 回家休息; } return 在广场闲逛; }这只是最基础的行为选择。真实项目里你还可以把“计划”交给大模型生成让 NPC 在每天醒来时自动安排日程。这三个示例合并起来就是 Agent 的核心闭环看记忆检索→ 想大模型决策→ 做行动映射→ 记写入新记忆。理解了这个闭环你就能自己扩展地图、新增 NPC、设计更多互动事件。7. 运行结果与效果验证项目启动后打开前端页面你会看到一个 2D 的小镇地图。玩家可以用键盘 WASD 控制角色移动地图上会同步显示多个 NPC 的位置和状态。验证 AI 效果建议按以下步骤来移动玩家接近某个 NPC看它是否会自动说出一句话或做出反应。在聊天框或命令行里输入一个自定义事件例如“林晓在咖啡馆捡到一个钱包”然后观察该 NPC 以及附近其他 NPC 是否在后续行为中提及这件事。观察 NPC 的日程变化如果已经是中午应该有 NPC 走向餐厅如果到了晚上应该有 NPC 回家。查看后端日志正常运行时日志里会输出每次大模型请求的内容和返回结果。这个日志是判断 AI 是否正在工作的最直接证据。如果一切正常你会发现 AI 小镇并不是一个静态地图而是一个“事件驱动”的模拟世界。NPC 之间的对话、移动、记忆积累让小镇看起来很热闹。如果某个 NPC 完全没有反应第一时间不要改代码。先确认后端日志中有没有请求记录如果没有说明事件没有触发到后端或者是 Prompt 构建环节出了问题。8. 常见问题与排查思路我在跑类似项目时最容易遇到下面这些问题。整理成表格方便你对照排查。问题现象可能原因排查方式解决方案启动时端口被占用前后端端口冲突或残留进程使用 lsof / netstat 查看端口状态修改配置文件端口或结束占用进程NPC 完全无响应API Key 无效、余额不足查看后端日志检查 .env 是否被正确加载重新生成 API Key或切换可用模型服务生成对话速度很慢网络延迟、模型上下文太长查看单次请求耗时清理记忆列表、限制 max_tokens、使用流式输出NPC 行为“精神分裂”Prompt 中没有固定角色人设检查 prompt 模板是否包含角色卡在 Prompt 开头加入稳定的角色设定和禁止行为前端白屏依赖未安装、构建失败打开浏览器开发者工具看 Console 报错重新执行 npm install检查 Node 版本调用 API 报 404API 地址不对检查 base_url 与模型名称更换为兼容接口或修改文档中的端点记忆文件无限增长没有对旧记忆做压缩检查存储策略定期把旧记忆总结成更高层印象删除细节记录在这些问题中Prompt 问题最容易误导新手。不少开发者会觉得“NPC 说话不符合人设”是模型能力问题实际上大部分是因为 Prompt 里没有给出足够的角色背景。my_ai_town项目里通常会有characters/目录里面放每个 NPC 的设定文件你可以通过修改这些文件来改善行为。9. 最佳实践与工程建议把 AI 小镇这类项目从“能跑”变成“好用”下面几条经验值得记住。9.1 用环境变量管理一切密钥不要硬编码 API Key。统一使用.env文件并确保不提交到 Git。团队协作时提供一个.env.example让成员自行复制。9.2 严格控制 token 成本大模型按 token 计费而 NPC 对话又天然高频。建议每次请求前精简上下文只传入最近 3-5 条记忆并设置max_tokens上限。如果项目需要长期运行可以加一层缓存对相同或相似的 Prompt 返回之前的结果。9.3 不要让同步请求阻塞游戏循环LLM 调用通常需要秒级响应如果所有 NPC 同一个时间发起请求游戏会卡死。正确做法是把所有模型请求放到队列里异步处理前端先播放“思考中”的动画等返回结果后再更新状态。9.4 给 NPC 做“记忆压缩”记忆无限增长会让检索越来越慢、Prompt 越来越长。更好的方式是每个 NPC 维护一条短期记忆库和一条长期印象库。短期记忆保存最近一天的细节每天结束时用大模型总结出几条长期印象再清空短期记忆。这样既保留了个性又控制了成本。9.5 为 Agent 接入工具调用要谨慎如果想让 NPC 执行复杂操作比如“去商店购买物品”不要把系统命令暴露给模型。正确做法是定义一组白名单函数让模型只输出“函数名参数”再由代码安全执行。否则一旦 Prompt 被用户诱导可能造成安全风险。9.6 保存 NPC 配置与 Prompt 模板到 Git整个项目最有价值的资产除了代码就是 NPC 人设和 Prompt 模板。把它们变成 JSON 或 Markdown 文件纳入版本管理。这样每次调整都能对比效果也方便后续团队协作。10. 总结与后续学习方向用 6 个 AI 从零做一个类 GTA 的游戏听起来很科幻但my_ai_town这类项目证明这条路已经可以走了。现在的 AI 并不是要取代游戏开发者而是把过去需要大量人力的内容生成、自动化测试和智能交互环节变成个人开发者也能负担的事情。你不需要会画像素画不需要写几百条 NPC 对话只需要把大模型、记忆流、决策循环这些核心组件组合起来。如果你看完这篇文章完全可以先照着项目仓库把环境跑通然后把本文里的三个示例代码和实际代码做对比理解项目里的 Agent 是怎么工作的。之后再尝试增加一个新 NPC或者修改某个角色的性格参数。这一步做完你对 AI Agent 应用开发的感受会比刷十篇教程都要深。下一步可以继续关注几个方向一是用国产大模型替换国外 API降低延迟和成本二是把 2D 地图换成 3D 场景让玩家沉浸感更强三是引入语音合成和语音识别让 NPC 可以开口说话并听懂玩家指令。这个项目真正迷人的地方不是因为它“像 GTA”而是它让你第一次感觉到游戏里的角色是有“记忆”的。
