DOOM 跑进 ChatGPT 和 Claude：MCP Apps 真正被测试的是宿主边界

开发者 Chris Nager 做了一个可玩的 DOOM MCP 应用。它可以在支持 MCP Apps 的 AI 客户端里以内联界面启动；如果宿主不支持，或环境受限，就退回一个普通浏览器 URL。

原项目展示过它在 Claude web、ChatGPT web、Claude macOS 等环境里的运行效果。iOS 端只属于部分运行。

这件事容易被看成猎奇：DOOM 又跑进了一个奇怪地方。但我更在意的是另一层：AI 客户端是不是开始从“聊天窗口 + 工具调用”，变成一个能放进真实交互式 Web 应用的宿主。

边界问题，也会一起进来。

DOOM 怎么通过 MCP 在客户端里启动

这个项目不是 OpenAI 或 Anthropic 给 ChatGPT、Claude 加了原生 DOOM。更准确地说，它是开发者用 MCP app 和网页做出的实验项目。

它的核心组件很少：TypeScript MCP server、浏览器 DOOM shell、签名 token，以及两个路由：/doom/play 和 /doom/mcp。

浏览器里的 DOOM 运行基于 cloudflare/doom-wasm。默认内容用的是 Freedoom Phase 1，主要是为了避开原版 DOOM 资源再分发的版权问题。

MCP 侧也只保留了两个工具。

这套设计的重点不是“把游戏塞进聊天框”。

重点是渐进增强：能内联就内联，不能内联也别崩。对开发者来说，这比一次性押注某个客户端更现实。

做 MCP 工具的人也该从这里拿到一个动作判断：不要默认所有客户端都支持同一种 UI 能力。先做回退链接，再谈更复杂的内联体验。

真正麻烦的不是 DOOM，而是 iframe 和 CSP

标题里有 DOOM，很容易让人以为难点是性能。

实际不是。

DOOM 跑在浏览器里早有成熟路径。这个项目里更麻烦的是宿主环境：iframe、CSP、资源路径、Netlify 函数打包、WAD 文件加载来源、blob preload 行为。

早期方案用过嵌套 iframe。结构看起来清楚：MCP app 里再嵌一个网页。但它很快会撞上 frame-src、跨源加载和宿主限制。

最后的取舍是：让 DOOM canvas 直接运行在 MCP app iframe 内，而不是在 MCP app 里再套一层 iframe。

这个选择很关键。

AI 客户端没有绕开 Web 的规则。它只是把 Web 的规则搬进了一个新容器。浏览器同源策略、内容安全策略、焦点输入、资源加载路径，都会重新变成工程成本。

对两类人影响最直接。

一类是做 AI 工具的开发者。以前只要返回文本、表格、图表，现在如果想做内联应用，就得提前检查键盘输入、canvas、音频、二进制资源能不能在宿主里稳定工作。

另一类是做 Web 嵌入和浏览器游戏移植的人。MCP host 可以是新的入口，但不是一个无差别浏览器。开发时要把“内联失败后怎么打开网页”当成默认路径，而不是兜底补丁。

这也是目前最现实的限制：不是所有客户端都能内联跑；受限环境只能拿 URL；移动端支持还不完整。没有这些前提，讨论体验会偏乐观。

为什么删功能，反而更像正确选择

原项目一度包含 save/load、状态报告、截图、持久化适配器、服务器验证 bootstrap 等功能。最后基本删掉。

留下来的，是一个最小闭环：能启动、能回退、能玩。

这不是偷懒。恰恰是对边界的判断。

MCP Apps 还在早期。不同宿主的支持程度不一，移动端限制更明显。此时把存档、截图、持久化都做满，调试成本会被宿主差异放大。

更稳的路线，是先证明一件事：同一个交互应用，能不能在 AI 客户端和普通浏览器之间切换。

过去浏览器扩展、小程序、Slack App、Figma 插件都经历过类似阶段。入口开放以后，开发者很快发现，真正卡人的往往不是 API 首页，而是权限、沙箱、审核、资源加载和 UI 容器。

MCP Apps 也不会例外。

接下来最该看的，不是还有多少经典游戏能被塞进去，而是几个更硬的变量：宿主 iframe 策略是否稳定，CSP 白名单怎么给，键盘和音频输入能不能正常交给内联应用，移动端是否会放开更多能力。

如果这些规则不稳，开发团队就应该少做重交互，先做轻 UI 和可回退流程。采购或内部工具选型也可以先观望，不急着把关键业务流程迁进聊天客户端。

回到这个 DOOM 项目，它好看的地方不在游戏本身。

好看在于它把 MCP Apps 的问题压缩成了一个小样本：当 AI 客户端开始承载应用，最先被测试的不是想象力，而是沙箱里的边界感。