克劳德·欧普斯5的挑战循环：多智能体迭代如何打造可玩的浏览器游戏
一种新的克劳德·欧普斯5提示模式在AI编程社区迅速传播，开发者利用它从简短描述中制作出令人惊讶的精美浏览器游戏原型。
Claude Opus 5的“闯关循环”：多智能体迭代如何打造可玩的浏览器游戏
引言
一种全新的Claude Opus 5提示模式在AI编程社区中迅速传播开来，因为开发者们利用它从简短的最初指令中创造出了令人惊讶的精美浏览器游戏原型。
这种方法现在被称为**“闯关循环”**（Gauntlet Loop）。
其核心思想很简单：不要让同一个智能体构建一次、评判自己的工作然后就此打住。给主导智能体一个高层目标，让它将项目分解为更小的部分，指派专业构建者，并使用独立的评审智能体将实际输出与具体的质量标准进行比较。
如果生成的结果未能通过比较，就返回进行又一轮迭代。
Matt Shumer在利用Claude Code和Opus 5创建了一款受现代《使命召唤》游戏启发的浏览器第一人称射击游戏后，推广了这一方法。他随后发布了提示词、源代码以及工作流程的说明。
另一位开发者Anshu Chimala采用了类似的工作流程，构建了**《漫长的沉默》**（The Long Silence），一款在浏览器中运行的程序化太空探索游戏。
这些项目应该被准确地描述。它们并不表明一个提示词就能立即产出一款商业级AAA游戏。它们表明，一个强大的编码智能体，在获得工具、子智能体、长时间执行、可衡量的质量门槛和反复验证的情况下，可以将原型推进到远超传统一次到位提示所能达到的程度。
病毒式演示背后的提示模式
Shumer最初的任务设定了一个有意为之的极端目标：构建一款视觉雄心堪比现代AAA级大作的第一人称射击游戏。
关键部分不在于游戏类型，而在于评估结构。
工作流程指示智能体：
- 将整体目标分解为更小的部分。
- 将这些部分委派给专业子智能体。
- 使用独立的评审智能体检查结果。
- 将生成的产物与真实参考进行比较。
- 拒绝未达到标准的工作。
- 持续迭代，而非在固定轮数后停止。
Shumer后来将这种方法正式化为**“闯关循环”**（Gauntlet Loop）。
简化版本如下所示：
目标
↓
主导智能体
↓
任务分解
↓
构建智能体
↓
实际输出
↓
独立评审
↓
与参考进行对比
↓
通过？ ── 是 → 整合
│
否
↓
解释最大差距
↓
构建者改进
↓
重复
具体的质量门槛至关重要
“做出
“更好”这种反馈很弱，因为模型必须自行定义什么叫“更好”。
而“铁人循环”则给了评判者一个外部参照物。
对于游戏，可以是来自成熟商业作品中的截图。
对于网站，可以是同类别中的几个领先站点。
对于后端工程，可能是：
- 一套测试套件
- 一个延迟目标
- 一个参考实现
- 一次安全审查
- 一个可靠性阈值
目标并不一定完全可达。其作用是防止智能体过早宣布成功。
绝不让建造者成为唯一裁判
第二条关键规则是独立性。
建造者知道自己做每个选择的原因，很容易为自己的结果辩护。而一个全新的评判者接收到的是实际的产物，并不了解实现的来龙去脉。
对于视觉工作，评判者可以检查渲染出的像素。
对于软件，评判者可以检查测试和运行时行为。
对于性能工作，评判者可以检查真实测量数据。
更广泛的原则是：生成和评估应当是两件分开的事。
Claude of Duty：让这个循环火起来的项目
Shumer最初的演示已作为 Claude of Duty 公开发布。
其GitHub仓库描述了一个基于Three.js和WebGL2的第一人称射击游戏，包含约 11个子系统中的55,000行代码。
仓库说明该游戏未使用任何外部美术资源。纹理、网格、动画和声音均由代码程序化生成。
其系统包括：
- 渲染
- 材质
- 大气与天空
- 世界几何
- 物理
- 玩家移动
- 武器
- 特效
- 敌方AI
- UI
- 程序化音频
称该项目为“一次完成”并不意味着所有内容都出现在一次回复中。据Shumer所说，一个高层次提示启动了一个长时间运行的Claude Code会话，随后该会话派生出子代理、编写文件、运行工具、渲染游戏、检查输出，并不断修改。
验证工具本身也是成果的一部分
仓库中包含以下工具：
- 可复现截图
- 评审图像集
- 逐像素图像对比
- 帧时间分析
- 脚本化试玩
其自述文件也比一些病毒式传播的帖子更加谨慎：明确表示最终项目 并不 匹配现代《使命召唤》游戏的水平。
这反而让实验更有价值。真正的结果不是“AI已经取代了AAA工作室”，而是：一个刻意设定的高参照物，能让智能体在普通提示词早已停下的地方，继续工作很久。
24小时太空游戏：The Long Silence
随后，Anshu Chimala将类似的工作流程应用到了 The Long Silence 上，这是一款使用Claude Opus 5构建的程序化浏览器太空探索游戏。
公开仓库说明该游戏使用WebGL2、Three.js风格的浏览器渲染和自定义GLSL。
并采用种子式程序化内容生成，而非下载传统美术资源库。
源文章描述了约24小时的开发过程，主要分为三个阶段。
第一步：将目标交给 Opus 5，让其自行选择架构
首个请求是使用 Three.js 创建一款太空探索游戏。
需求有意保持高层级：
- 让玩家可以移动。
- 让玩家可以驾驶飞船。
- 避免过于塑料感的视觉风格。
- 在浏览器中稳定运行。
- 在可行的情况下追求流畅性能。
大部分世界构建和技术架构都留给了代理自行决定。
这遵循了该方法的核心原则：
明确终点，而非路线。
源文章还提到，Claude Code 在该过程中连接了与 Blender 相关的工具。公开仓库中包含一个用于 Blender 硬表面建模的 Claude 技能目录，确认了可复用的 Blender 指令已成为项目的一部分。
第二步：运行长时视觉优化循环
首个可玩版本完成后，项目进入了漫长的视觉精细化阶段。
多个子代理分别处理不同区域，同时一个评审代理将截图与精良的太空游戏参考图进行对比。
重点不是简单告诉 Opus 5“让游戏更好看”。评审代理需要识别可见差距，并将薄弱区域送回再次迭代。
源文章提到，星空（Starfield）等作品被用作质量基准。
长循环也需要停止条件。有用的停止点包括：
- 达到可衡量的目标。
- 评审代理无法再发现重大差距。
- 改进幅度太小，不足以证明计算成本的合理性。
- 分配的时间或预算已耗尽。
- 人类负责人认为结果已足够。
循环是一种压力机制，而非输出最终会变得“完美”的保证。
第三步：人工重新排序优先级、清理与技能提取
该过程并非完全无人干预。
据源文章所述，Chimala 远程检查进度，并在代理在某一区域投入过多精力时进行干预。
长时运行结束后，使用了额外的 Claude 会话来：
- 修复渲染问题
- 清理代码
- 为项目部署做准备
随后，模型被要求将可复用的经验总结为一项技能。
公开仓库中包含：
.claude/skills/blender-hardsurface
这对于长时间运行的代理工作是一个有用的模式。一个项目不仅可以产出制品，还可以沉淀可复用的操作知识：哪些工具有效、哪些测试重要、哪些失败过，以及未来任务应如何结构化。
The Long Silence 构建了自己的验证工具
公开仓库中最突出的部分之一是
验证工具集。
README 中记录了以下命令：
node tools/play.mjs
node tools/survey.mjs
node tools/probe.mjs "<js>" --shot out.png
node tools/sheet.mjs a.png b.png --out s.png
node tools/levels.mjs shots/*.png
node tools/judgeset.mjs
这些命令的文档化用途包括：
play.mjs：17 项交互断言，涵盖飞行、扫描、折叠和跳跃survey.mjs：主要场景截图及性能报告probe.mjs：单次浏览器表达式执行与单张截图sheet.mjs：用于视觉对比的缩略图联系表levels.mjs：色调与曝光统计judgeset.mjs：重建视觉评审集
关键在于，智能体不仅创建了游戏本身，还创建了用于评判游戏的机制。
这就是为什么一个长期运行的智能体比简单的“生成即停止”工作流能够更可靠地改进的原因之一。
该仓库展示了真实的工程权衡
README 记录了几项实际的图形决策：
- 浮动原点系统处理非常大的空间距离。
- 行星被烘焙成立方体贴图，以避免每帧进行昂贵的过程式求值。
- 大气层使用散射计算。
- 后处理包括泛光、色调映射、镜头效果、颗粒和抗锯齿。
- 动态渲染缩放保护帧率。
仓库还说明，浏览器验证是在启用 GPU 栅格化的真实 Chromium 实例上运行的。
这些细节很重要，因为它们展示了模型在处理熟悉的工程约束时的表现：性能、精度、可重复性、浏览器行为和视觉质量。
结果可玩，但仍是一个原型
《The Long Silence》可在浏览器中公开游玩。
其仓库提供了标准开发命令：
npm install
npm run dev
npm run build
游戏包含太空飞行、扫描、程序化环境、导航、探索目标以及多种界面系统。
这使它不仅仅是一个静态模型。
但它仍不等同于大型工作室历时数年开发的商业 AAA 游戏。
AAA 级制作通常需要大型团队负责以下方面：
- 美术
- 关卡设计
- 动画
- 音频
- 叙事
- 多人游戏
- 质量保证
- 无障碍支持
- 认证
- 性能优化
- 运营维护
更站得住脚的结论是：一名开发者如今可以编排前沿编码智能体，创造出视觉上雄心勃勃、技术上非平凡的的可玩原型，速度远超以往的实际可行性。
社区开发者开始复用这一模式
Shumer 发布提示词和代码后，该工作流迅速传播。
卡丁车赛车
Ryan Campbell 采用了类似的模式
循环推进一个浏览器卡丁车赛车项目，不断迭代渲染、控制、摄像机行为以及移动端性能。
Shumer 公开的 Gauntlet Loop 目录后来展示了用该方法制作的、可在浏览器中游玩的赛车实验。
Claudepunk 2077
设计师 Yogi Suria 分享了一个赛博朋克风格的 Three.js 项目，其灵感来自同样的提示模式。
这个例子表明，该方法并不局限于某一种游戏类型。参考目标、美术方向和工具链都可以改变，而“构建-批评-重复”的结构保持不变。
同样的模式也可以用于其他编码代理
消息源还展示了一位开发者通过 Codex 使用 GPT-5.6 Sol 尝试类似提示的过程。
这位开发者报告称构建时间约为两个小时，并形容结果不错，但不如 Shumer 的演示那样精致。
这表明 Gauntlet Loop 本质上并非 Claude 专属。
该模式依赖于一个具备以下能力的智能体环境：
- 访问文件
- 运行代码
- 渲染输出
- 检查截图
- 使用工具
- 持续多轮运行
- 委派任务
- 根据反馈进行修改
不同模型在循环中的表现可能有所差异，但该架构是可移植的。
为什么批评者代理会改变结果
传统的生成流程通常是这样的：
用户 → 模型 → 输出 → 用户
Gauntlet Loop 增加了一个评估层：
用户
↓
主代理
↓
构建者
↓
产物
↓
独立批评者
↓
测量差距
↓
构建者修订
↓
新产物
这创造了更多在交付前发现低质量输出的机会。
批评者应该检验现实
代理说“页面现在应该具备响应式”不如在移动端宽度下打开页面并实际检查来得有力。
“游戏应该更快”不如测量帧时间来得有力。
“渲染看起来更好了”不如对比截图来得有力。
最好的反馈信号是扎根于真实产物之中的。
新上下文减少自我辩解
构建者会记住自己所做的每一个妥协。
这可能会使评审产生偏差。
一个独立的批评者可以提出一个更简单的问题：结果是否真的达到了标准？
这映照了人类的工作流程。开发者使用测试和代码审查。设计师使用视觉评审和用户测试。作者使用编辑。
AI 代理可以以更高的频率复现这种分离。
为什么 Opus 5 适合这种工作流程
Anthropic 于 2026 年 7 月 24 日发布了 Claude Opus 5。
其官方发布
材料强调在编码、长时间多步骤工作、验证和迭代方面表现更强。
Anthropic 特别指出，Opus 5 在以下方面表现更好：
- 检查自身工作
- 反复迭代直到任务成功
- 找到根本原因
- 在需要时构建测试框架
- 在较长任务中保持进度
- 在交回工作前检查视觉输出
这些行为与 Gauntlet Loop 高度吻合。
该提示词并未赋予模型新的能力。它创建了一种结构，反复迫使模型使用其已有的能力。
Anthropic 还表示，Opus 5 在相同基础价格下比 Opus 4.8 更高效：每百万输入 token 5 美元，每百万输出 token 25 美元。
Opus 5 仍需监督
长时间运行的智能体仍可能面临以下问题：
- 上下文漂移
- 优先级错乱
- 计算资源浪费
- 局部决策薄弱
- 集成冲突
- 工具故障
- 视觉不一致
因此，人工检查点仍然有用。
最强的工作流程不是“再也不看智能体一眼”，而是“让智能体在两次高价值人工干预之间工作更长时间”。
实用的 Gauntlet Loop 模板
该方法可以推广到游戏之外的领域。
第一步：定义目标
描述期望的结果，而不是规定每一个实现细节。
构建一款精致的浏览器太空探索游戏，具备流畅的操作、
强烈的视觉氛围和稳定的性能。
第二步：定义真正的质量标准
使用评论者可以检查的内容。
对于视觉工作：
将光照、深度、构图和界面精致度与一组精选的高质量商业游戏截图进行对比。
对于软件，使用测试、基准测试或参考实现。
第三步：让主导智能体分解工作
智能体可以拆分组件，例如：
- 移动
- 光照
- 环境
- UI
- 音频
- 特效
- 性能
第四步：区分构建者与评论者角色
对于重要组件，使用：
- 一个构建者
- 一个具有全新上下文的评论者
第五步：返回最大的有效差距
评论者应指出最大的可操作差异，而不是列出一长串模糊的抱怨。
第六步：重复
持续迭代，直到质量、预算或时间达到停止点。
第七步：执行集成检查
并行智能体可能产出局部良好但全局不一致的工作。
最终的集成智能体可以检查：
- 共享接口
- 视觉一致性
- 命名
- 重复逻辑
- 性能
- 跨系统冲突
第八步：保存可复用知识
将流程中有用的部分存储为：
- 技能
- 测试脚本
- 基准测试
- 提示词模板
- 审查工具
后续运行应从先前的经验教训开始。
该模式最适合的场景
当质量可以被反复衡量时，Gauntlet Loop 最为有效。
合适的候选场景包括：
- 前端开发
- 游戏
- 测试驱动编码
- 重构
- 性能优化
- 研究报告
- 营销页面
- 演示文稿
- 视觉设计
但当评论者缺乏可靠信号时，该模式效果较弱。
没有截图、测试的评论者，
基准测试、参考资料或真实用户反馈也可能只是让模型多产出一种“意见”而已。
成本与控制仍然重要
长时间运行的多智能体工作流可能会消耗大量的计算资源。
每一轮审查可能都需要：
- 新的模型调用
- 浏览器渲染
- 图像分析
- 工具执行
- 代码生成
- 测试
实用的预算控制手段包括：
- 最大运行时间
- 最大模型开销
- 最大批评轮数
- 最低改进阈值
- 关键里程碑后的人工审批
严格的批评者可以提高质量，但它也可能在剩余改进已经不划算的情况下，让系统持续运行很久。
常见问题
什么是 Gauntlet Loop？
Gauntlet Loop 是一种由 Matt Shumer 推广的多智能体提示方法。一个主导智能体将目标分解为更小的任务，构建智能体负责产出成果，独立的批评智能体将实际输出与具体参考进行比较，达不到要求的结果会被打回重来。
Claude of Duty 真的只用一条提示词就构建出来了吗？
根据 Shumer 的说法，这个项目始于一个高层次的提示词，但它并非在一次模型响应中就生成。Claude Code 随后工作了数小时，派生出子智能体，编写了大约 55,000 行代码，使用工具，检查输出，并进行迭代。
Claude Opus 5 在 24 小时内创造了一款真正的 3A 游戏吗？
不是。这些演示是技术上令人印象深刻的浏览器游戏和原型，但它们并不等同于商业 3A 大作。Claude of Duty 的代码仓库本身也说明最终结果无法与作为其质量参照的现代《使命召唤》作品相提并论。
什么是 The Long Silence？
The Long Silence 是 Anshu Chimala 制作的一款基于浏览器的程序化太空探索游戏。其公开仓库显示，它使用 Claude Opus 5 构建，并包含自定义渲染、程序化生成内容以及基于浏览器的验证工具。
为什么要使用独立的批评智能体？
一个全新的批评者不太可能为构建者自身的实现决策辩护。它可以检查实际产物，并在要求再次修订之前，将其与测试、截图、基准测试或参考示例进行比较。
Gauntlet Loop 只适用于 Claude Opus 5 吗？
不是。这种架构可以应用于其他支持工具、文件编辑、代码执行、视觉检查和重复工作的编码智能体。源文包含一个 GPT-5.6 Sol 和 Codex 的示例。
我需要 Claude Code 吗？
完整的工作流程需要一个智能体运行环境，而非普通的聊天界面。Claude Code 是一个选择，因为它可以处理文件、运行命令、连接工具，并协调长时间运行的编码任务。
最大的限制是什么？
当质量标准模糊或无法衡量时，长时间运行的循环可能会浪费时间和计算资源。人类所有者仍然应该设置预算、检查进度、在必要时重新调整优先级，并决定何时进一步的迭代已失去价值。
相关工具
- Claude Code：Anthropic 的智能体编码环境，适用于代码库、工具和长期开发任务。
- Claude Opus 5：Anthropic 的官方公告。
涵盖 Opus 5 的编码、验证、迭代及长周期任务能力。
- Three.js：本文讨论的浏览器游戏项目所使用的 JavaScript 3D 库。
- Blender：一款开源 3D 创作套件，可通过外部工具接入智能体工作流程。
- Model Context Protocol：一种开放协议，用于将 AI 应用连接到外部工具和数据源。
相关链接
- 如何运行 Gauntlet Loop：Matt Shumer 对构建者/批评者提示架构的详细讲解。
- GitHub 上的 Claude of Duty：通过 Shumer 的 Opus 5 工作流程制作的开源 Three.js 第一人称射击游戏。
- Claude of Duty 原始提示词：用于启动该实验的公开提示词。
- GitHub 上的 The Long Silence：开源浏览器太空游戏及其验证工具。
- 游玩 The Long Silence：该项目的实时 WebGL2 版本。
- Anthropic：推出 Claude Opus 5：关于 Opus 5 能力、定价及长时运行智能体行为的官方信息。
- Anthropic MCP 文档：Anthropic 对 Claude 各产品中 Model Context Protocol 支持的概述。
总结
爆火的 Opus 5 游戏实验更应该被理解为对一种工作流程的展示，而非神奇的“一次生成”。Gauntlet Loop 结合了任务分解、专家构建者、独立批评者、具体质量标准以及反复迭代。
The Long Silence 展示了这种模式在约一天时长的智能体项目中可以达到的程度。其公开仓库不仅包含可玩的游戏，还包括验证脚本、截图工具、交互断言以及可复用的智能体指令。
该方法仍然依赖于人类判断、计算预算、良好的参考资料以及智能体工作台。它并不等同于让浏览器原型媲美工作室出品的 3A 级游戏。
真正的转变在于，一个高层级目标现在就能启动一个长期运行的“构建–测量–批评–改进”循环，在人类需要介入之前完成远更多的工作。