GladeKit MCP：给 Unity 和 Godot 插上 AI 的翅膀

想象这样一个场景：你正在开发一款 Unity 平台跳跃游戏，凌晨两点，你突然想在场景中添加一个新的角色动画状态机。传统方式下，你得翻遍文档、手写 StateMachine 代码、反复在编辑器里调试。现在，你只需要在 Claude Code 中说一句话——「给玩家角色加一个冲刺后摇」，AI 就能自动操作 Unity 编辑器：创建 Animation Controller、配置 Blend Tree、在脚本中挂接 Trigger。这不是科幻，这是 GladeKit MCP 正在做的事。

图1：GladeKit MCP 在 Cursor 中的运行效果演示

从痛点出发：AI 编程助手为何「听不懂」游戏开发

通用 AI 编程助手（如 Copilot、Claude）擅长处理纯代码任务，但游戏开发有其特殊性：大量逻辑发生在编辑器可视化操作中，而非纯代码里。「创建一个材质」「调整光照烘焙参数」「在场景中添加一个粒子系统」——这些对人类开发者来说是鼠标拖拽的操作，对 AI 来说却是盲区。

GitHub 上另一个知名的 Unity MCP 方案（IvanMurzak/Unity-MCP）解决了「运行时 AI」的问题，但它的核心能力在于编译后的游戏中调用 AI，而非编辑器内的自动化操作。GladeKit 则瞄准了更深层的痛点：让 AI 在编辑器层面「长出双手」。

该项目的创始人（GitHub: danielfang7）曾在博客中详细阐述过 GladeKit 的设计哲学：Agent 的本质是一个循环——感知、决策、执行、反馈。在通用编程场景下，这个循环运行得相当顺畅；但在游戏编辑器中，AI 缺乏对场景状态、GameObject 层级、组件关系的感知能力，导致它无法做出精准决策。GladeKit 的核心思路就是给 AI 装备这种感知能力：让它读懂场景结构、知道当前选中了什么、理解材质和光照系统的上下文。

架构解析：双桥接 + MCP 标准协议

GladeKit MCP 的架构设计相当精巧，由三个核心组件构成：

Python MCP Server（mcp-server/）是整个系统的中枢。它基于 Model Context Protocol 构建，通过 stdio 传输协议与各 AI 客户端通信。服务端的核心模块包括：

• server.py：MCP 服务端主入口，基于 mcp[cli]>=1.0 框架
• bridge.py：与编辑器桥接层的通信模块，同时支持 HTTP（Unity，端口 8765）和 WebSocket（Godot，端口 8766）两种传输方式
• search.py：语义搜索模块，通过 OpenAI embeddings 实现项目内 C# 脚本的语义检索
• cloud.py：云智能层（RAG + 跨会话记忆），可选功能
• asset_pipeline/：免费 CC0 资产管道模块
• tools/：260+ 工具的注册与分发逻辑
• prompts.py：Unity/Godot 感知型系统提示词生成
• skill.py：技能校准模块，根据用户水平自动调整输出详细程度

Unity C# 桥接插件（unity-bridge/）是另一个重量级组件。这是一个标准的 Unity Package Manager（UPM）包，安装方式为 Window > Package Manager > + > Add from git URL。核心结构包括：

• Bridge/：HTTP 服务器实现，在 localhost:8765 端口监听来自 MCP Server 的请求
• Services/：包含 UnityContextGatherer（场景层级采集）、AssetPipelineGuard（资产变更守护）、BackupManager（操作前自动备份）、PlayModeObserver（Play Mode 状态监控）、BridgeDiagnostics（诊断）等
• SRP/：渲染管线感知模块，能自动检测 URP/HDRP/Built-in
• Tools/：暴露给 MCP Server 的各类工具实现

值得注意的是，桥接插件中大量使用了 Assembly Definition（.asmdef）进行程序集隔离，避免与用户项目产生程序集引用冲突。

Godot 桥接插件（godot-bridge/）则通过 WebSocket 协议连接，服务端在 localhost:8766，支持 Godot 4.3+ 的 GDScript 项目，涵盖 Forward+ 和 Compatibility 两种渲染器。

260+ 工具：覆盖游戏开发的每一个角落

GladeKit 的工具集覆盖了 16+ 个类别，基本涵盖游戏开发的全流程：

Scene（场景）、GameObjects（游戏对象）、Scripts（脚本）、Prefabs（预制件）、Materials（材质）、Lighting（光照）、VFX & Audio（特效与音频）、Animation（动画）、IK（反向动力学）、Physics 3D/2D（物理）、Tilemaps（瓦片地图）、Camera（相机）、UI（用户界面）、Input System（输入系统）、Terrain & NavMesh（地形与导航网格）、Profiler（性能分析器）、Asset Pipeline（资产管道）。

所有工具中有一个设计亮点：get_relevant_tools 元工具。当用户提出一个模糊任务时（如「帮我做一个射击手感」），AI 会先调用此工具，结合 RAG 上下文推荐最相关的工具集，而不是把 260+ 工具一股脑塞给 LLM——后者很容易触发 128 工具的上限限制。

GLADE.md：游戏设计文档即上下文

传统 MCP 工具的项目感知能力很弱——AI 只能看到当前对话中的代码，无法理解项目的整体设计意图。GladeKit 引入了一个极具巧思的机制：在 Unity 项目根目录放置一个 GLADE.md 文件，里面写游戏设计文档（Game Design Document）。MCP Server 在每次请求中自动将 GDD 注入上下文，让 AI 理解「为什么要这么做」而非「只做被要求的事」。

例如，你可以在 GLADE.md 中写：「当前我们在做的是一款 Rougelike 卡牌游戏，玩家通过卡牌组合触发不同技能。」这样当你让 AI「加一个新的攻击效果」时，它会主动考虑卡牌机制、伤害数值平衡等设计上下文。

部署体验：极低门槛，但需要一点配置

GladeKit 的部署体验分两部分：

Python MCP Server：通过 uvx gladekit-mcp 一行命令安装和启动。uv 是 Rust 编写的 Python 包管理工具，安装速度极快。整个过程不需要 pip、不需要虚拟环境，对 AI 客户端来说这是一个透明的子进程。

Unity/Godot 桥接插件：Unity 通过 UPM 加载 Godot 通过解压 addons 文件夹，整个过程符合引擎的原生插件生态。Unity 用户需要在 Project Settings > AI > MCP Servers 中配置 PATH 环境变量（这是官方推荐的路径检测机制），Godot 用户则只需启用插件即可。

不过需要注意的是，项目不支持 Docker 容器化部署，也不提供 Web UI——它是完全本地化的开发工具。硬件要求极低，不需要 GPU，普通开发机即可流畅运行。

局限与争议

GladeKit 目前也有一些明显的局限性：

1. Godot Mono/C# 项目不支持：当前 Godot 桥接仅支持 GDScript 项目，使用 C# 开发的 Godot 项目暂时无法接入
2. Unity 版本要求：Unity AI Gateway 集成需要 Unity 6000.3+，老版本用户只能通过外部 MCP 客户端连接
3. 安全风险：AI 直接操作编辑器意味着它可能执行破坏性操作（如误删场景对象）。桥接层提供了 BackupManager 和 GameObjectStateBackup，但这不能完全消除风险
4. 云智能层的付费墙：RAG 知识库和跨会话记忆需要 GLADEKIT_API_KEY，目前需要付费订阅

行业意义：游戏开发 AI 工具的新范式

GladeKit 的出现代表了游戏 AI 开发工具的一个重要方向：让 AI 工具从「辅助写代码」升级到「辅助做游戏」。它将 MCP 协议在游戏引擎领域的落地推进了一大步。

从增长曲线看，项目在 2026 年 4 月创建，到 7 月已有 179 star、21 fork、15 个主题标签，并在 YouTube 上出现了用该工具 21 分钟内构建完整 Unity 跑酷游戏的教程。这说明社区对编辑器级 AI 工具的需求是真实且旺盛的。

更重要的是，GladeKit 的双桥接架构——Python MCP Server + 引擎原生插件——为其他创意工具（Blender、Unreal、DaVinci Resolve 等）的 MCP 集成提供了一个可复制的范式。