长时间运行应用开发的编排架构设计

作者：Prithvi Rajasekaran，Labs 团队成员。

在过去几个月里，我一直在解决两个相互关联的问题：让 Claude 生成高质量的前端设计，以及让它在无人干预的情况下构建完整的应用程序。这项工作源于我们早期在前端设计 skill 和长时间运行编码智能体编排架构方面的探索，我和同事们通过提示工程和编排架构（harness）设计将 Claude 的表现提升到远超基线水平——但两者最终都触及了天花板。

为了突破瓶颈，我探索了新颖的 AI 工程方法，这些方法需要在两个截然不同的领域中都能奏效：一个由主观审美定义，另一个由可验证的正确性和可用性定义。受生成对抗网络（GANs）的启发，我设计了一个包含**生成器（generator）和评估器（evaluator）**的多智能体结构。要构建一个评分可靠且有品味的评估器，首先需要开发一套标准，能够将”这个设计好不好？“这类主观判断转化为具体的、可评分的维度。

然后我将这些技术应用于长时间运行的自主编码，从早期的编排架构工作中延续了两个经验：将构建任务分解为可处理的小块，以及使用结构化产物在会话之间传递上下文。最终成果是一个三智能体架构——规划器（planner）、生成器（generator）和评估器（evaluator）——在多小时的自主编码会话中生产出功能丰富的全栈应用。

为什么朴素的实现方式效果不佳

我们此前已经证明，编排架构设计对长时间运行的智能体编码效果有重大影响。在早期的实验中，我们使用一个初始化智能体将产品规格分解为任务列表，编码智能体逐个实现功能，然后交接产物以跨会话传递上下文。更广泛的开发者社区也得出了类似的见解，如”Ralph Wiggum”方法使用 hooks 或脚本让智能体保持在持续迭代循环中。

但一些问题始终存在。对于更复杂的任务，智能体随着时间推移仍然会偏离轨道。在分解这个问题时，我们观察到智能体执行此类任务时的两种常见失败模式。

第一种是模型在冗长任务中随着上下文窗口填满而逐渐失去连贯性（参见我们关于上下文工程的文章）。一些模型还表现出”上下文焦虑”，即当它们认为接近上下文限制时会过早地开始收尾工作。上下文重置——完全清空上下文窗口并启动一个新的智能体，结合结构化交接来传递前一个智能体的状态和后续步骤——可以解决这两个问题。

这与压缩（compaction）不同，压缩是将对话早期部分就地总结，让同一个智能体在缩短的历史记录上继续工作。虽然压缩保持了连续性，但不会给智能体一个全新的起点，这意味着上下文焦虑仍然可能持续。重置提供了一个干净的起点，代价是交接产物需要包含足够的状态让下一个智能体能够顺利接手工作。在我们早期的测试中，我们发现 Claude Sonnet 4.5 的上下文焦虑非常明显，仅靠压缩不足以实现强大的长任务性能，因此上下文重置成为编排架构设计的关键要素。这解决了核心问题，但为每次编排运行增加了编排复杂性、token 开销和延迟。

第二个问题是自我评估，这是我们之前未曾解决的。当被要求评估自己的工作时，智能体往往会自信地赞美自己的成果——即使在人类观察者看来，质量明显平庸。这个问题在设计等主观任务中尤为突出，因为没有等同于可验证软件测试的二元检查。布局是精致还是普通，这是一个判断问题，而智能体在给自己的工作评分时总是倾向于积极评价。

然而，即使在有可验证结果的任务上，智能体在完成任务时有时也会表现出糟糕的判断力，妨碍其表现。将执行工作的智能体与评判工作的智能体分开，被证明是解决这个问题的有力杠杆。这种分离本身并不能立即消除宽容倾向；评估器仍然是一个倾向于对 LLM 生成输出给予好评的 LLM。但调优一个独立的评估器使其保持怀疑态度，比让生成器对自己的工作持批判态度要容易得多，一旦有了这种外部反馈，生成器就有了可以据此迭代的具体依据。

前端设计：让主观质量变得可评分

我首先在前端设计领域进行实验，因为自我评估问题在这里最为明显。在没有任何干预的情况下，Claude 通常会倾向于安全、可预测的布局——技术上可用但视觉上毫无亮点。

两个洞察塑造了我为前端设计构建的编排架构。首先，虽然美学不能完全被简化为一个分数——个人品味总会有所不同——但可以通过编码设计原则和偏好的评分标准来改进。“这个设计美吗？“很难一致地回答，但”这个设计是否遵循了我们对好设计的原则？“给了 Claude 具体的评分依据。其次，通过将前端生成与前端评分分开，我们可以创建一个反馈循环，驱动生成器产出更强的结果。

基于此，我编写了四个评分标准，同时提供给生成器和评估器智能体的提示词中：

• 设计质量： 设计是否感觉像一个连贯的整体，而不是一堆零件的集合？在这方面表现出色意味着颜色、排版、布局、图像和其他细节结合在一起，创造出独特的氛围和身份。
• 原创性： 是否有定制决策的证据，还是模板布局、库默认设置和 AI 生成模式？人类设计师应该能识别出有意的创意选择。未修改的现成组件——或 AI 生成的典型特征如紫色渐变覆盖白色卡片——在这里不及格。
• 工艺： 技术执行：排版层级、间距一致性、色彩和谐、对比度。这是能力检查而非创意检查。大多数合理的实现默认情况下都能通过；不及格意味着基础功能有问题。
• 功能性： 独立于美学的可用性。用户是否能理解界面的功能，找到主要操作，并在不猜测的情况下完成任务？

我强调设计质量和原创性，而非工艺和功能性。Claude 在工艺和功能性方面默认就能得到较好的分数，因为所需的技术能力对模型来说是自然而然的。但在设计和原创性方面，Claude 经常产出充其量只是乏味的结果。这些标准明确惩罚了高度通用的”AI 垃圾”模式，通过更重地加权设计和原创性，推动模型在美学上承担更多风险。

我使用带有详细分数分解的 few-shot 示例来校准评估器。这确保了评估器的判断与我的偏好一致，并减少了跨迭代的分数漂移。

我在 Claude Agent SDK 上构建了这个循环，使编排保持简洁。生成器智能体首先根据用户提示创建一个 HTML/CSS/JS 前端。我给评估器配备了 Playwright MCP，让它可以在评分每个标准并撰写详细评价之前，直接与实时页面交互。在实践中，评估器会自行导航页面，截图并仔细研究实现，然后产出评估结果。反馈流回生成器作为下一次迭代的输入。每次生成我运行 5 到 15 次迭代，每次迭代通常推动生成器朝着更独特的方向发展，因为它在回应评估器的批评。由于评估器是在主动导航页面而非对静态截图评分，每个周期需要真实的时间。完整运行可长达四个小时。我还指示生成器在每次评估后做出战略决策：如果分数趋势良好就完善当前方向，如果方法不奏效就转向完全不同的美学。

跨运行来看，评估器的评分在迭代过程中有所提高，然后趋于平稳，但仍有提升空间。一些生成是渐进式改进，另一些则在迭代之间发生了剧烈的美学转变。

标准的措辞以我没有完全预料到的方式引导了生成器。加入”最好的设计具有博物馆品质”这样的短语推动设计朝着特定的视觉趋同方向发展，表明与标准相关的提示直接塑造了输出的特征。

虽然分数通常随迭代而提高，但模式并不总是线性的。后期实现整体上往往更好，但我经常看到更偏好中间迭代而非最后一个的情况。实现复杂度也倾向于跨轮次增加，生成器在回应评估器反馈时寻求更雄心勃勃的解决方案。即使在第一次迭代中，输出也明显优于完全没有提示的基线，这表明标准及其关联语言本身就在任何评估器反馈导致进一步改进之前，将模型从通用默认值引导开来。

一个值得注意的例子：我提示模型为一家荷兰艺术博物馆创建网站。到第九次迭代时，它已经为一个虚构博物馆制作了一个干净的深色主题着陆页。页面视觉效果精致，但基本符合我的预期。然后在第十个周期，它完全推翻了之前的方案，将网站重新设想为一个空间体验：一个带有棋盘格地板的 3D 房间（用 CSS 透视渲染），画作以自由形式挂在墙上，通过门廊而非滚动或点击在画廊房间之间导航。这是一种我之前从未在单次生成中见过的创造性飞跃。

扩展到全栈编码

有了这些发现，我将这种 GAN 启发的模式应用于全栈开发。生成器-评估器循环自然地映射到软件开发生命周期，其中代码审查和 QA 扮演着与设计评估器相同的结构角色。

架构

在我们早期的长时间运行编排架构中，我们通过初始化智能体、逐功能工作的编码智能体和会话间上下文重置来解决连贯的多会话编码问题。上下文重置是关键突破：该编排架构使用 Sonnet 4.5，它表现出前面提到的”上下文焦虑”倾向。构建一个在上下文重置中运行良好的编排架构是保持模型专注的关键。Opus 4.5 基本上自行消除了这种行为，所以我能够从该编排架构中完全去除上下文重置。智能体在整个构建过程中作为一个连续会话运行，Claude Agent SDK 的自动压缩沿途处理上下文增长。

在这项工作中，我在原始编排架构的基础上构建了一个三智能体系统，每个智能体解决我在之前运行中观察到的特定差距。系统包含以下智能体角色：

规划器（Planner）： 我们之前的长时间运行编排架构要求用户预先提供详细的规格说明。我想自动化这一步，所以创建了一个规划器智能体，接受简单的 1-4 句提示并将其扩展为完整的产品规格。我提示它在范围上要有雄心，关注产品上下文和高层技术设计，而非详细的技术实现。这样强调是因为担心如果规划器试图预先指定细粒度的技术细节并出错，规格中的错误会级联到下游实现中。让智能体在要交付的产物上受限，让它们在工作过程中自行找出路径，似乎更明智。我还要求规划器在产品规格中寻找融入 AI 功能的机会。（参见底部附录中的示例。）

生成器（Generator）： 早期编排架构中逐功能实现的方法在范围管理上效果良好。我在这里应用了类似的模型，指示生成器以 sprint 方式工作，每次从规格中挑选一个功能。每个 sprint 使用 React、Vite、FastAPI 和 SQLite（后来是 PostgreSQL）技术栈实现应用，生成器被指示在每个 sprint 结束时自我评估工作，然后交给 QA。它还使用 git 进行版本控制。

评估器（Evaluator）： 早期编排架构产出的应用往往看起来令人印象深刻，但当你实际使用时仍有真实的 bug。为了捕获这些问题，评估器使用 Playwright MCP 像用户一样点击运行中的应用，测试 UI 功能、API 端点和数据库状态。然后它根据发现的 bug 和一套源自前端实验的标准（这里适配为涵盖产品深度、功能性、视觉设计和代码质量）为每个 sprint 评分。每个标准有一个硬阈值，如果任何一个低于阈值，sprint 就失败，生成器会收到关于哪里出了问题的详细反馈。

在每个 sprint 之前，生成器和评估器会协商一份 sprint 合约：在编写任何代码之前就”完成”的定义达成一致。之所以存在这个步骤，是因为产品规格是有意保持高层次的，而我希望有一个步骤来弥合用户故事和可测试实现之间的差距。生成器提出它将构建什么以及如何验证成功，评估器审查该提案以确保生成器构建的是正确的东西。双方迭代直到达成一致。

通信通过文件处理：一个智能体写文件，另一个智能体读取并在该文件中回应，或用一个新文件回应，前一个智能体再读取。然后生成器根据商定的合约进行构建，再将工作交给 QA。这使工作忠实于规格，同时不会过早地过度指定实现。

运行编排架构

对于该编排架构的第一个版本，我使用 Claude Opus 4.5，将用户提示同时输入完整编排架构和单智能体系统进行对比。我使用 Opus 4.5 是因为在我开始这些实验时，它是我们最好的编码模型。

我写了以下提示来生成一个复古电子游戏制作器：

创建一个 2D 复古游戏制作器，功能包括关卡编辑器、精灵编辑器、实体行为和可玩测试模式。

下表显示了编排类型、运行时长和总成本。

编排架构的成本超过 20 倍，但输出质量的差异立刻显而易见。

我期望的是一个界面，可以在其中构建关卡及其组件（精灵、实体、瓦片布局），然后按下播放键实际玩这个关卡。我首先打开单智能体运行的输出，初始应用似乎符合这些期望。

但随着我点击浏览，问题开始浮现。布局浪费空间，固定高度的面板让大部分视口空白。工作流程僵硬。尝试填充关卡时，提示我先创建精灵和实体，但 UI 中没有任何东西引导我按这个顺序操作。更重要的是，实际游戏是坏的。我的实体出现在屏幕上，但没有任何东西响应输入。深入代码发现实体定义和游戏运行时之间的连接断了，表面上看不出问题在哪里。

评估完单智能体运行后，我转向编排架构运行。这次运行从相同的一句话提示开始，但规划器步骤将提示扩展为一个包含 16 个功能、分布在 10 个 sprint 中的规格。它远远超出了单智能体运行所尝试的范围。除了核心编辑器和播放模式外，规格还包括精灵动画系统、行为模板、音效和音乐、AI 辅助的精灵生成器和关卡设计器，以及带有分享链接的游戏导出。我让规划器访问了我们的前端设计 skill，它阅读并使用该 skill 为应用创建了视觉设计语言作为规格的一部分。对于每个 sprint，生成器和评估器协商了一份合约，定义了 sprint 的具体实现细节和将被测试以验证完成的可测试行为。

应用立刻显示出比单智能体运行更多的精致和流畅。画布使用了整个视口，面板大小合理，界面有一致的视觉标识，跟踪了规格中的设计方向。我在单智能体运行中看到的一些笨拙之处确实仍然存在——工作流程仍然没有明确表示应该在尝试填充关卡之前先构建精灵和实体，我不得不自己摸索。这看起来是基础模型在产品直觉方面的差距，而不是编排架构设计要解决的问题，尽管这确实暗示了编排架构内定向迭代可以进一步提高输出质量的地方。

浏览编辑器时，新运行相对于单智能体的优势变得更加明显。精灵编辑器更丰富、功能更完善，有更干净的工具面板、更好的颜色选择器和更好用的缩放控件。

因为我要求规划器在规格中融入 AI 功能，应用还带有内置的 Claude 集成，让我可以通过提示生成游戏的不同部分。这显著加快了工作流程。

最大的区别在游戏模式中。我实际上能够移动实体并玩游戏。物理引擎有一些粗糙的边缘——我的角色跳上平台后与平台重叠，直觉上感觉不对——但核心功能是工作的，而单智能体运行没有做到这一点。走动一会后，我确实遇到了一些 AI 游戏关卡构建的局限性。有一堵大墙我跳不过去，所以我被困住了。这表明编排架构可以处理一些常识性的改进和边缘情况来进一步完善应用。

阅读日志后，很明显评估器让实现保持与规格一致。每个 sprint，它按照 sprint 合约的测试标准走查运行中的应用（通过 Playwright），对任何偏离预期行为的地方提交 bug。合约非常细粒度——仅 Sprint 3 就有 27 个标准覆盖关卡编辑器——评估器的发现足够具体，无需额外调查即可采取行动。下表展示了评估器发现的几个问题示例：

让评估器达到这个水平需要大量工作。开箱即用时，Claude 是一个糟糕的 QA 智能体。在早期运行中，我看到它识别出合理的问题，然后说服自己这些不是大问题，并批准了工作。它还倾向于表面测试，而不是探测边缘情况，所以更微妙的 bug 经常被遗漏。调优循环是：阅读评估器的日志，找到其判断与我不一致的例子，然后更新 QA 的提示来解决这些问题。经过几轮这样的开发循环，评估器才开始以我认为合理的方式评分。即便如此，编排架构的输出仍然显示了模型 QA 能力的局限：小的布局问题、某些地方操作不直观、以及评估器未充分测试的更深层嵌套功能中的未发现 bug。显然还有更多验证空间可以通过进一步调优来获取。但与核心功能根本不工作的单智能体运行相比，提升是显而易见的。

迭代编排架构

第一组编排架构结果令人鼓舞，但也笨重、缓慢且昂贵。合乎逻辑的下一步是找到简化编排架构的方法，同时不降低其性能。这部分是常识，部分是一个更一般原则的体现：编排架构中的每个组件都编码了对模型无法自行完成之事的假设，这些假设值得压力测试——因为它们可能是不正确的，也因为随着模型改进，它们可能很快过时。我们的博客文章构建有效的智能体将其基本理念表述为”找到最简单的可能解决方案，只在需要时增加复杂性”，这是维护智能体编排架构的人一直会看到的模式。

在我第一次尝试简化时，我大幅削减了编排架构并尝试了一些创造性的新想法，但未能复现原始版本的性能。也变得难以判断编排架构设计的哪些部分实际上是承重的，以及以何种方式。基于这次经验，我转向更有条理的方法，每次移除一个组件并审查它对最终结果的影响。

在我经历这些迭代周期时，我们还发布了 Opus 4.6，这提供了进一步减少编排架构复杂性的动力。有充分理由期望 4.6 比 4.5 需要更少的脚手架。来自我们的发布博客：“[Opus 4.6] 规划更谨慎，能更长时间地维持智能体任务，可以更可靠地在大型代码库中运行，并且拥有更好的代码审查和调试技能来捕获自己的错误。“它在长上下文检索方面也有大幅改进。这些都是编排架构之前需要补充的能力。

移除 Sprint 构造

我首先完全移除了 sprint 构造。sprint 结构帮助将工作分解为模型可以连贯处理的块。鉴于 Opus 4.6 的改进，有充分理由相信模型可以在没有这种分解的情况下原生处理工作。

我保留了规划器和评估器，因为两者都继续增加明显的价值。没有规划器，生成器会低估范围：给出原始提示后，它会开始构建而不先规划工作，最终创建出比规划器更少功能的应用。

移除 sprint 构造后，我将评估器转为运行末尾的单次通过，而不是按 sprint 评分。由于模型能力大大增强，这改变了评估器在某些运行中的承重程度，其有用性取决于任务相对于模型可以可靠自主完成之处的位置。在 4.5 上，这个边界很近：我们的构建处于生成器能够单独完成的边缘，评估器在整个构建过程中捕获了有意义的问题。在 4.6 上，模型的原始能力提高了，边界也外移了。以前需要评估器检查才能连贯实现的任务，现在往往在生成器自己能处理的范围内，对于在该边界内的任务，评估器成了不必要的开销。但对于仍处于生成器能力边缘的构建部分，评估器继续提供真实的提升。

实际意义是，评估器不是一个固定的”用还是不用”决定。当任务超出当前模型可靠独立完成的范围时，它就值得付出成本。

在结构简化的同时，我还增加了提示来改进编排架构如何在每个应用中构建 AI 功能，特别是让生成器构建一个可以通过工具驱动应用自身功能的适当智能体。这需要真正的迭代，因为相关知识足够新，Claude 的训练数据对此覆盖不足。但经过足够的调优，生成器能够正确地构建智能体。

更新后编排架构的结果

为了测试更新后的编排架构，我使用以下提示生成一个数字音频工作站（DAW），一个用于作曲、录音和混音的音乐制作程序：

在浏览器中使用 Web Audio API 构建一个功能完整的 DAW。

运行仍然漫长且昂贵，大约 4 小时，token 成本 $124。

大部分时间花在了构建器上，它在没有 Opus 4.5 所需的 sprint 分解的情况下连贯运行超过两个小时。

与之前的编排架构一样，规划器将一行提示扩展为完整规格。从日志中我可以看到，生成器模型在规划应用和智能体设计、连接智能体以及在交给 QA 之前测试方面做得很好。

话虽如此，QA 智能体仍然捕获了真实的差距。在第一轮反馈中，它指出：

这是一个强大的应用，设计保真度出色，AI 智能体扎实，后端良好。主要的失败点在于功能完整性——虽然应用看起来令人印象深刻，AI 集成运行良好，但几个核心 DAW 功能仅有展示而缺乏交互深度：片段无法在时间线上拖拽/移动，没有乐器 UI 面板（合成器旋钮、鼓垫），也没有视觉效果编辑器（EQ 曲线、压缩器仪表）。这些不是边缘情况——它们是让 DAW 可用的核心交互，规格明确要求了它们。

在第二轮反馈中，它再次捕获了几个功能差距：

剩余差距：

• 音频录制仍然只是桩代码（按钮切换但没有麦克风捕获）
• 拖拽边缘调整片段大小和片段分割未实现
• 效果可视化是数字滑块，不是图形化的（没有 EQ 曲线）

生成器在自行运作时仍然容易遗漏细节或对功能做桩处理，QA 在捕获这些最后一英里问题以供生成器修复方面仍然有价值。

根据提示，我期望的是一个程序，可以在其中创建旋律、和声和鼓点模式，将它们编排成一首歌，并在过程中得到集成智能体的帮助。下面的视频展示了结果。

这个应用远非专业音乐制作程序，智能体的歌曲创作技能显然还需要大量改进。此外，Claude 实际上无法听到声音，这使得 QA 反馈循环在音乐品味方面不太有效。

但最终应用具备了一个功能性音乐制作程序的所有核心部件：浏览器中运行的编排视图、混音器和播放控制。除此之外，我完全通过提示拼凑了一个短歌曲片段：智能体设定了速度和调性，铺下旋律，构建鼓轨，调整混音器电平，并添加了混响。歌曲创作的核心基本元素都在，智能体可以自主驱动它们，使用工具从头到尾创建一个简单的制作。你可能会说它还不够完美——但正在进步。

未来展望

随着模型持续改进，我们大致可以预期它们能够工作更长时间，处理更复杂的任务。在某些情况下，这意味着围绕模型的脚手架随着时间推移变得不那么重要，开发者可以等待下一个模型，看到某些问题自行解决。另一方面，模型越好，开发编排架构来完成超出模型基线能力的复杂任务的空间就越大。

考虑到这一点，这项工作有几个值得延续的经验教训。始终良好的做法是：对你正在使用的模型进行实验，阅读它在真实问题上的轨迹，并调优其性能以达到你期望的结果。在处理更复杂的任务时，有时可以通过分解任务并对问题的每个方面应用专门的智能体来获得提升空间。当新模型到来时，通常良好的做法是重新审视编排架构，剥离不再对性能承重的部分，并添加新的部分以实现之前可能无法达到的更大能力。

从这项工作中，我的信念是：有趣的编排架构组合空间不会随着模型改进而缩小。相反，它在移动，AI 工程师有趣的工作就是不断发现下一个新颖的组合。

致谢

特别感谢 Mike Krieger、Michael Agaby、Justin Young、Jeremy Hadfield、David Hershey、Julius Tarng、Xiaoyi Zhang、Barry Zhang、Orowa Sidker、Michael Tingley、Ibrahim Madha、Martina Long 和 Canyon Robbins 对这项工作的贡献。

同时感谢 Jake Eaton、Alyssa Leonard 和 Stef Sequeira 在文章撰写中的帮助。

附录

规划器智能体生成的示例计划。

RetroForge - 2D 复古游戏制作器

概述
RetroForge 是一个基于 Web 的创意工作室，用于设计和构建 2D 复古风格的电子游戏。它将经典 8 位和 16 位游戏美学的怀旧魅力与现代直观的编辑工具相结合——让从业余创作者到独立开发者的任何人都能在不编写传统代码的情况下将游戏创意变为现实。

该平台提供四个集成的创意模块：用于设计游戏世界的基于瓦片的关卡编辑器、用于制作视觉资源的像素艺术精灵编辑器、用于定义游戏逻辑的可视化实体行为系统，以及用于实时游戏测试的即时可玩测试模式。通过在全程融入 AI 辅助（由 Claude 驱动），RetroForge 加速了创意过程——帮助用户通过自然语言交互生成精灵、设计关卡和配置行为。

RetroForge 面向热爱复古游戏美学但想要现代便利的创作者。无论是重现童年的平台游戏、RPG 或动作游戏，还是在复古约束下发明全新体验，用户都可以快速原型设计、可视化迭代，并与他人分享创作。

功能
1. 项目仪表板与管理
项目仪表板是 RetroForge 中所有创意工作的主页。用户需要一种清晰有序的方式来管理游戏项目——创建新项目、返回进行中的作品，以及一目了然地了解每个项目包含的内容。

用户故事：作为用户，我希望：

- 创建一个带有名称和描述的新游戏项目，以便开始设计游戏
- 看到所有现有项目显示为视觉卡片，展示项目名称、最后修改日期和缩略图预览，以便快速找到并继续我的工作
- 打开任何项目进入完整的游戏编辑器工作空间，以便工作
- 删除不再需要的项目，带有确认对话框以防止意外，以便保持工作空间整洁
- 复制现有项目作为新游戏的起点，以便重用之前的工作

项目数据模型：每个项目包含：

项目元数据（名称、描述、创建/修改时间戳）
画布设置（分辨率：如 256x224、320x240 或 160x144）
瓦片大小配置（8x8、16x16 或 32x32 像素）
调色板选择
所有关联的精灵、瓦片集、关卡和实体定义

...