这次我们来看一个非常有想法的实验项目用 6 个 AI 智能体组成一个“虚拟开发团队”从零搭建一款类似《GTA》风格的开放世界小镇游戏。项目对应的开源仓库是 GitHub 上的 my_ai_town也就是“AI 小镇”项目页同时提供了 macOS 和 Windows 两个平台的游戏下载包。这个项目最大的看点不是某个单点 AI 功能而是“多 Agent 协作”的工程化实践。传统开发游戏需要策划、程序、美术、测试等不同角色配合而这个项目尝试把整个流程拆成 6 个 AI 岗位由调度层统一组织最后拼出一个可以双击运行的游戏。如果你关心 AI Agent 开发、AI 应用开发、AI 工程实践或者想看看 AI Coding 工具链到底能不能走通一个完整项目这篇文章可以仔细看。下面我会从核心能力、6 个 Agent 的分工方式、安装部署、功能验证、任务调度、资源占用、常见问题和工程化建议几个维度展开。全文会给出可复制的命令和代码模板不会只讲概念。1. 核心能力速览先把项目最关键的信息放在最前面方便快速判断值不值得试。能力项说明项目类型AI Agent 协作生成的开放世界小游戏工程项目来源GitHub: mewamew/my_ai_town提供 AI 小镇游戏下载核心思路6 个 AI 智能体分工完成策划、程序、场景、NPC、UI、测试最终拼装为可运行游戏主要功能开放世界小镇场景、角色移动与交互、NPC 对话、任务链、建筑和载具生成技术栈以 Python 为主线Web 技术渲染前端具体组件以仓库 README 为准运行平台macOS、Windows 均可工程源码可跨平台构建启动方式游戏提供一键运行包Agent 开发工程通过命令行启动是否需要 GPU不是硬性要求若用本地大模型启动 Agent建议 16GB 内存以上有 GPU 更好API 能力Agent 之间通过消息队列通信可以将任务提交、状态查询暴露为 HTTP 接口批量任务多 Agent 调度天然支持多轮迭代、批量场景生成和批量回归测试适合人群AI Agent 工程师、游戏自动化开发、游戏策划、AIGC 内容生产、AI Coding 研究者从材料看这个项目属于“AI Agent 驱动的内容生产”类型。它和单纯调用 ChatGPT 写代码不一样的地方在于多了一个协调层和 6 个角色化 Agent每个 Agent 拥有独立职责并且通过明确的任务输入输出来衔接。2. 项目定位6 个 AI 一起做游戏解决什么问题先说清楚一个关键点这个项目并不是要让 6 个 AI 同时在一个代码库里随便改文件而是把一个游戏开发流程拆成 6 个阶段化、角色化的任务再交给不同 Agent 执行。这样做的好处有三个。第一降低单次 Prompt 的复杂度。如果让一个 AI 直接“写一个 GTA 风格游戏”它很容易生成一堆结构混乱、互相冲突的代码。拆成 6 个 Agent 后每个 Agent 只需要处理自己领域内的局部任务例如“生成地图 JSON”“生成 NPC 对话脚本”“生成 UI 布局代码”上下文更聚焦输出质量也会更稳定。第二方便人工介入检查。每一个 Agent 的输出都可以作为一个独立产物保存在目录中例如assets/map.json、assets/npc_dialogue.json、src/ui/*.js。人工可以逐个审查也可以跳过某个 Agent 的结果直接用自己准备的素材替换。第三天然支持批量迭代。6 个 Agent 的任务队列可以并行处理多个小镇建筑、多个 NPC 行为脚本、多组对话内容。只要任务结构设计得够清晰横向扩展只是增加队列消费者的数量。这个项目从 0 到 1 的完整链路可以概括为项目需求描述 - Agent 1 架构与策划产出游戏设计文档和任务拆解 - Agent 2 系统程序产出核心逻辑源码 - Agent 3 场景生成产出地图、建筑、载具资源 - Agent 4 NPC 行为产出 NPC 对话和行为脚本 - Agent 5 UI 与交互产出界面和操作反馈 - Agent 6 测试与调优回归验证并修复 - 打包输出可运行游戏实际运行中不同 Agent 之间并不是严格的串行关系。Agent 3 的场景生成和 Agent 4 的 NPC 逻辑可以并行因为 NPC 行为脚本只要依赖地图坐标和建筑 ID 即可不需要等 UI 完成。这样能够将整体构建时间明显压缩。3. 6 个 AI 智能体的角色与协作方式这一节是项目的核心。从构建逻辑来看6 个 AI 分别承担 6 个岗位每个岗位都有固定的输入、输出和交付格式。下面逐个拆解。3.1 Agent 1架构与策划职责把“类似《GTA》的开放世界小镇”这个模糊需求拆解为可执行的设计文档和任务列表。输入项目需求描述。输出game_design.md、task_breakdown.json。协作对象向 Agent 2 提供功能清单向 Agent 3 提供场景区域规划。task_breakdown.json是全局调度的重要依据结构可以设计成{ project: ai_town, modules: [ { id: core_movement, owner: agent_2, depends_on: [], description: 角色移动与碰撞逻辑 }, { id: map_generation, owner: agent_3, depends_on: [scene_plan], description: 生成小镇地图与建筑分布 }, { id: npc_dialogue, owner: agent_4, depends_on: [map_generation], description: 生成 NPC 对话树 } ] }有了这个文件调度器就可以判断哪些任务可以先跑哪些任务要等依赖完成。3.2 Agent 2系统程序职责负责核心游戏逻辑包括角色移动、碰撞检测、交互、任务系统、数据存储。输入Agent 1 输出的功能清单。输出src/core/*.py或src/core/*.js。协作对象与 Agent 3 确认地图数据的读取格式与 Agent 5 确认 UI 回调接口。编程类 Agent 的 Prompt 模板可以这么写你是项目中的系统程序 Agent。请基于以下任务描述实现功能代码。 任务{task_description} 依赖模块{dependency_modules} 输出目录src/core 要求 1. 使用模块化函数不要把所有逻辑写在一个大文件里。 2. 保留简单的 JSON 输入输出接口方便其他 Agent 对接。 3. 注释写明函数职责和参数说明。3.3 Agent 3场景与地图生成职责生成小镇地图数据、建筑位置、道路连接、载具刷新点等场景资源。输入Agent 1 的场景区域规划。输出assets/map/*.json、assets/buildings/*.png或assets/textures/*。协作对象把建筑坐标表提供给 Agent 4把场景渲染所需资源提供给 Agent 5。地图 JSON 的通用结构如下{ tile_size: 64, regions: [ { name: downtown, bounds: [0, 0, 1280, 960], buildings: [ {id: b_01, type: shop, position: [128, 192], size: [128, 96]}, {id: b_02, type: garage, position: [640, 320], size: [256, 128]} ] } ], spawn_points: [ {id: spawn_01, position: [64, 64], type: vehicle} ] }3.4 Agent 4NPC 行为逻辑职责生成 NPC 的对话树、日程行为、任务触发条件。输入Agent 3 的建筑坐标表和 Agent 1 的任务设计。输出assets/npc/*.json、src/npc/*.py。协作对象对话文本交给 UI 层展示行为状态由核心逻辑层调用。NPC 对话 JSON 示例{ npc_id: npc_shopkeeper_01, name: 小镇杂货店老板, schedule: [ {time: 09:00, action: open_shop, location: b_01}, {time: 12:00, action: lunch, location: b_02}, {time: 18:00, action: close_shop, location: b_01} ], dialogue_tree: [ { node_id: d_01, trigger: player_approach, text: 欢迎来到杂货店今天有特价商品。, options: [ {text: 买一瓶饮料, next: d_02}, {text: 打听小镇传闻, next: d_03} ] } ] }3.5 Agent 5UI 与交互职责生成游戏界面布局、HUD、对话窗口、背包菜单等。输入Agent 2 的回调接口、Agent 4 的对话树。输出src/ui/*.html、src/ui/*.css、src/ui/*.js。协作对象确认 Core 层暴露的 JavaScript 或 WebSocket 接口。3.6 Agent 6测试与调优职责运行自动化测试收集报错信息生成问题清单并把修复建议返回给对应 Agent。输入Agent 2 到 Agent 5 的全部产物。输出test_report.md、test/logs/*.log。协作对象可以触发 Agent 2 或 Agent 4 重新生成问题代码。测试逻辑的关键是“可重复执行”。建议测试脚本做成命令行形式python run_tests.py --module core --input assets/map/downtown.json4. 适用场景与使用边界这个项目适合下面几类人AI Agent 研究与开发。如果你想研究多 Agent 任务调度、角色 Prompt 设计、任务队列状态管理这个项目提供了一个贴近真实生产的例子。游戏自动化开发。不一定是做商业级游戏而是验证“AI 能否按岗位产出模块化游戏资源”这条链路。课程设计与毕业设计。用 6 个 AI 协作产出一个可运行游戏工程完整度、展示效果和实验数据都比较好写。AIGC 工作流搭建。Agent 的输入输出结构同样适用于自动生成短视频素材、H5 页面、营销小游戏等场景。需要注意边界不要期待它能直接生成《GTA 5》级别的 3D 开放世界。这个项目的目标是 2D 或轻量 2.5D 的小镇模拟重点在 Agent 协作机制不在画质。如果要用 AI 生成的角色形象、建筑贴图、配音素材做外部发布需要确认素材版权和肖像授权。涉及 NPC 对话生成要增加敏感词过滤和人工复核避免角色说出不当内容。本地部署大模型时需要注意模型许可证和部署合规问题不要将禁止商用或限制用途的模型直接用于生产环境。5. 环境准备与前置条件在动手前先把环境确认一遍。这个项目同时涉及 Agent 服务和游戏客户端建议按下面清单检查。5.1 操作系统Windows 10/11 或 macOS 12 以上。如果你打算改代码做二次开发Linux 也可以但 Windows/macOS 上调试游戏客户端更方便。5.2 基础运行时Python 3.10 或更高版本。Node.js 18 或更高版本部分前端渲染和构建工具依赖它。Git用于拉取仓库代码。Python 版本检查命令python --version node --version git --version5.3 大模型服务6 个 AI Agent 需要一个 LLM 作为“大脑”可以选择调用云端 API也可以使用本地 Ollama 或 vLLM。两种方式资源要求不一样云端 API对本地硬件要求低推荐第一次上手使用。本地 Ollama需要 16GB 以上内存推荐 20GB 以上显存或大内存机型否则推理速度会比较慢。环境变量示例export LLM_API_BASEhttps://api.openai.com/v1 export LLM_API_KEYyour_api_key_here export LLM_MODELgpt-4o-mini如果你使用本地 Ollama可以简化为export LLM_API_BASEhttp://127.0.0.1:11434/v1 export LLM_MODELqwen2.5:14b5.4 磁盘与网络仓库本身很小但模型缓存和生成资源会占用空间。建议预留 10GB 以上磁盘空间。下载模型时需要稳定的网络环境如果使用本地模型提前下载好再离线使用。5.5 端口规划Agent 服务和游戏前端一般会使用不同端口。默认规划参考8000Agent 调度服务。7860游戏 Web 界面和 Stable Diffusion WebUI 默认端口一致可能冲突。5173Vite 前端开发服务器默认端口。如果启动后发现端口被占用优先改项目自己的端口配置不要直接杀掉系统服务。6. 安装部署与启动方式部署分为两种方式一种是直接玩现成的 AI 小镇游戏下载包另一种是拉取源码跑 Agent 工程。建议先跑游戏包看效果再碰 Agent 工作流。6.1 下载并运行游戏包从项目页提供的“AI小镇_macw”下载对应系统的压缩包解压后Windows双击AI小镇.exe或start.bat。macOS双击应用文件若提示未验证开发者需要到“系统设置 - 隐私与安全性”中允许打开。打开后你应该能看到一个小镇场景可以控制角色移动、与 NPC 交互、进入建筑这就是 Agent 工作的最终产物。6.2 拉取 Agent 工程源码git clone https://github.com/mewamew/my_ai_town.git cd my_ai_town创建虚拟环境python -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate安装依赖pip install -r requirements.txt如果仓库提供了前端依赖清单还需要执行npm install6.3 配置环境变量在项目根目录创建.env文件按实际使用的模型服务填写LLM_API_BASEhttp://127.0.0.1:11434/v1 LLM_MODELqwen2.5:14b AGENT_TEAM_SIZE6 OUTPUT_DIR./outputs LOG_DIR./logs6.4 启动 Agent 调度服务python run_pipeline.py --config config/agent_team.yaml启动后观察日志如果看到 6 个 Agent 依次初始化完成说明协作链路已经起来了。调度服务会读取任务拆解文件按依赖关系分发任务。6.5 启动游戏预览python serve_game.py --host 127.0.0.1 --port 7860浏览器访问http://127.0.0.1:7860如果页面能显示小镇地图并且角色可以移动说明 Agent 产出的代码和资源已经被正确加载。7. 功能测试与效果验证部署完成不等于功能可用。建议按下面的测试顺序逐项验证。7.1 测试 1角色移动与碰撞测试目的确认 Agent 2 产出的核心逻辑有效。操作打开游戏页面使用方向键或 WASD 控制角色移动。预期结果角色能在小镇地图上移动无法穿过建筑。判断标准移动流畅无控制台报错。常见失败地图碰撞数据缺失检查assets/map/*.json中的bounds字段是否覆盖建筑区域。7.2 测试 2NPC 对话测试目的确认 Agent 4 生成的对话树可正常触发。操作控制角色走到杂货店老板旁边点击交互按钮。预期结果弹出对话窗口显示对话文本和选项。判断标准选项点击后能跳转到对应对话节点。常见失败NPC 坐标与建筑坐标不一致导致无法触发。7.3 测试 3任务链测试目的确认 Agent 1 设计的任务拆解能落地为游戏玩法。操作接受 NPC 发布的任务按步骤完成。预期结果任务状态从“进行中”变为“已完成”并触发奖励逻辑。判断标准任务进度在 UI 中可见。常见失败任务脚本引用了不存在的物品 ID。7.4 测试 4批量生成验证测试目的验证多 Agent 并行任务是否可靠。操作在调度配置中把building_count从 10 改成 50重新触发 Agent 3。预期结果生成 50 个建筑资源且放入地图后不会重叠。判断标准生成的 JSON 文件数量正确格式校验通过。常见失败超过上下文窗口导致输出被截断需要增加校验机制。7.5 测试 5重新构建回归修改某个 Agent 的任务描述例如“增加 2 个新的 NPC”然后重新运行完整流水线。预期结果只有 Agent 4 及相关依赖任务重新执行Agent 3 不会全量重跑。这一步能确认任务缓存和依赖判断是否正常工作。8. Agent 任务调度与批量构建多 Agent 项目最终都要面对两个问题任务怎么分发结果怎么汇总。这个项目的调度思路可以抽象成如下模型。8.1 任务队列设计每个 Agent 对应一个输入队列和一个输出队列。调度器把任务写入 Agent 的输入队列Agent 执行完后把产物路径写入输出队列并通知下游 Agent。这里给出一套通用任务提交接口设计实际项目中需要按仓库的接口路径调整。import requests import json # 提交任务到 Agent 调度服务 task { task_id: scene_downtown_v2, agent: agent_3, description: 生成 downtown 区域的 50 个建筑坐标和贴图, dependencies: [scene_plan_v2], output_dir: ./outputs/map/downtown_v2 } resp requests.post( urlhttp://127.0.0.1:8000/agent/task, jsontask, timeout10 ) print(resp.json())返回结果{ status: accepted, task_id: scene_downtown_v2, queue_position: 3 }8.2 查询任务状态resp requests.get( urlhttp://127.0.0.1:8000/agent/task/scene_downtown_v2, timeout10 ) print(resp.json())返回示例{ task_id: scene_downtown_v2, status: completed, outputs: [ outputs/map/downtown_v2/map.json, outputs/map/downtown_v2/buildings/ ] }8.3 批量任务的失败重试批量生成最怕中途失败。建议每个 Agent 都具备“输出校验 自动重试”的能力。例如 Agent 3 生成地图 JSON 后首先用 JSON Schema 校验校验失败就重新调用一次模型连续三次失败才报警。python batch_generate.py --task scene_downtown_v2 --retry 3 --wait 58.4 Agent 回调通知长任务不适合用轮询方式一直占线程。可以在任务提交时增加回调 URL。task { task_id: scene_downtown_v2, agent: agent_3, callback_url: http://127.0.0.1:9000/webhook/agent_done } requests.post( urlhttp://127.0.0.1:8000/agent/task, jsontask, timeout10 )下游收到回调后可以直接读取输出文件并继续处理。这种方式更适合 6 个 Agent 并行的场景。9. 资源占用与性能观察多 Agent 项目的资源占用要分两部分看LLM 推理占用和游戏运行占用。9.1 LLM 推理占用云端 API本机只跑 Agent 调度和文件处理内存占用通常在 2GB 到 4GB。本地 Ollama 14B 模型内存占用大约 10GB 到 16GB显存充足时会优先使用显存。本地 7B 量化模型内存占用 6GB 到 10GB速度可以接受。同时并发 6 个 Agent 时LLM 推理会成为主要瓶颈。如果只有一张显卡建议把 Agent 并发度降到 2 到 3否则会排队严重。观察资源占用Linux/macOS 可以使用top -o %MEM nvidia-smiWindows 推荐使用任务管理器的“性能”标签页重点观察内存和 GPU 的“专用 GPU 内存”。9.2 游戏运行占用游戏本身是轻量的 Web 项目浏览器渲染为主CPU 和内存占用不会太高。如果玩起来卡顿优先排查浏览器硬件加速是否开启以及地图资源文件是否过大。9.3 降低占用的方法批量任务控制在队列中串行执行不一次全部并发。使用本地模型时选择 7B 或更小的量化版本。优先调用云端 API适合开发和测试。生成的临时文件及时清理避免大量 JSON 日志堆积。关闭不必要的 Agent 日志输出只保留错误级别。9.4 避免端口冲突和进程残留项目频繁启停容易留下残留进程。Linux/macOS 可以这样查看lsof -i :8000 lsof -i :7860找到残留 PID 后按需清理。Windows 使用netstat -ano | findstr :7860 taskkill /PID pid /F10. 常见问题与排查方法这里整理了我认为最高频的 8 类问题按排查优先级排序。问题现象可能原因排查方式解决方案游戏页面打不开服务未启动或端口冲突查看服务日志检查端口监听更换端口重新启动服务Agent 任务一直排队并发数设置过低或模型响应慢查看任务队列状态调高并发或换更快的模型服务生成的 JSON 文件不合法模型输出被截断用 JSON 解析器验证文件增加输出校验和重试机制NPC 无法触发对话坐标数据不匹配对比 NPC JSON 和地图 JSON修改 NPC 坐标或建筑坐标地图资源缺失建筑显示空白Agent 3 任务失败或产物未复制检查输出目录是否有文件重新触发 Agent 3 任务显存或内存占用过高本地模型过大或并发过高查看 nvidia-smi 或任务管理器换小模型降低并发依赖安装失败Python 或 Node 版本不匹配查看 pip/npm 报错信息按 README 指定版本安装Agent 输出风格不稳定Prompt 缺少输入输出约束检查任务描述模板增加格式要求示例11. 最佳实践与使用建议把这类多 Agent 项目从“能跑”推进到“稳定用”建议从下面几个方向入手。11.1 先小参数跑通再批量放大第一次运行不要直接让 Agent 生成 50 个建筑先把数量改到 3 个。小规模跑通的意义在于验证依赖关系和输出格式如果格式不对批量再大也没意义。11.2 保留一套最小可运行配置在仓库目录下建立config/minimal.yaml记录已验证可用的模型名称、并发数和端口配置。后续调试坏了可以直接回滚到这个配置。11.3 输入素材、输出产物、模型缓存分目录管理建议使用下面的目录结构ai_town_project/ ├── inputs/ # 人工准备的素材和需求文件 ├── outputs/ # Agent 生成的游戏资源 ├── models/ # 本地模型缓存 ├── logs/ # Agent 运行日志 └── src/ # 核心代码这样清理临时文件时不会误删 Agent 产物。11.4 批量任务必须加日志和失败重试任务越复杂失败概率越高。每个 Agent 的输入输出都要记录日志失败任务要支持手动重跑不要因为一个建筑生成失败导致整条流水线中断。11.5 API 服务要限制访问范围调度服务默认监听127.0.0.1就行不要直接暴露到公网。如果确实需要远程调用要加 API Key 校验和 IP 白名单。11.6 内容生成必须做合规检查AI 生成的 NPC 对话、角色形象、建筑贴图在对外发布前必须复核。涉及真实人物肖像、知名品牌标识、受版权保护的素材没有授权就不要用。12. 总结这个项目最值得尝试的点是把“AI 写代码”升级成了“AI 团队写代码”。6 个 Agent 的分工模式本质上是一个可迁移到任何内容生产流程的工程框架。你可以用它做游戏也可以改成 AI 生成短视频脚本、AI 批量搭建 H5 落地页、AI 运营虚拟社区。如果你刚接触多 Agent 开发建议先把游戏下载包跑一遍感受最终产物再进入源码层观察任务调度和 Agent Prompt。最容易踩的坑就是先把并发拉满导致模型排队、输出混乱。建议始终保持“小批量 - 校验 - 放大”的节奏。对这个项目后续可以继续扩展的方向包括接入更强的本地多模态模型让 Agent 3 直接生成 3D 场景贴图增加 Agent 之间的记忆共享让 NPC 行为更加连续把调度服务改造成更通用的 Agent 平台不局限于游戏场景。第一步先从仓库里把游戏下载包跑起来。