Publish Date: 2026-04-05

长期运行应用开发的 Harness 设计

发布于 2026 年 3 月 24 日

在 agent 编码的前沿领域，harness 设计是性能的关键。以下是我们如何在前端设计和长期自主软件工程中推动 Claude 进一步发展的方法。

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

在过去几个月里，我致力于两个相互关联的问题：让 Claude 产生高质量的前端设计，以及让它在没有人类干预的情况下构建完整的应用程序。这项工作起源于我们之前在前端设计技能和长期编码 agent harness 方面的努力，我的同事和我能够通过 prompt 工程和 harness 设计将 Claude 的性能提升到远超基线——但最终两者都遇到了瓶颈。

为了突破，我寻找了在两个截然不同的领域中都能有效的新型 AI 工程方法，一个由主观品味定义，另一个由可验证的正确性和可用性定义。受生成对抗网络（GANs）的启发，我设计了一个多 agent 结构，包含生成器和评估器 agent。构建一个能够可靠且有品味地评估输出的评估器，首先需要开发一套能够将”这个设计好吗”这样的主观判断转化为具体、可评分的术语的标准。

然后我将这些技术应用于长期自主编码，延续了我们要早期 harness 工作中的两个经验教训：将构建分解为可管理的块，以及使用结构化的人工制品在会话之间传递上下文。最终结果是一个三 agent 架构——规划器、生成器和评估器——它在长达数小时的自主编码会话中产生了丰富的全栈应用程序。

为什么简单实现会失败

我们之前已经证明，harness 设计对长期运行 agent 编码的有效性有重大影响。在早期的实验中，我们使用了一个初始化 agent 将产品规范分解为任务列表，以及一个编码 agent 一次实现一个功能，然后通过移交人工制品来在会话之间传递上下文。更广泛的开发者社区也达成了类似的见解，诸如使用 hooks 或脚本让 agent 保持持续迭代循环的”Ralph Wiggum”方法。

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

第一个问题是，随着上下文窗口的填充，模型倾向于在长任务中失去连贯性（参见我们关于上下文工程的文章）。一些模型还表现出”上下文焦虑”，即当它们接近自己认为的上下文限制时，开始过早地结束工作。上下文重置——完全清除上下文窗口并启动一个新的 agent，结合承载前一个 agent 状态和下一步骤的结构化移交——解决了这两个问题。

这与压缩不同，压缩是在原处总结对话的较早部分，以便同一个 agent 可以在缩短的历史记录上继续。虽然压缩保留了连续性，但它没有给 agent 一个全新的起点，这意味着上下文焦虑可能仍然存在。重置提供了一个全新的起点，代价是移交人工制品必须包含足够的状态，以便下一个 agent 能够干净地接手工作。在我们早期的测试中，我们发现 Claude Sonnet 4.5 表现出足够强烈的上下文焦虑，以至于仅靠压缩不足以实现强大的长任务性能，因此上下文重置成为 harness 设计的关键。这解决了核心问题，但给每次 harness 运行增加了编排复杂性、token 开销和延迟。

第二个问题，我们之前没有解决，是自我评估。当被要求评估他们自己产生的工作时，agent 倾向于自信地赞扬工作——即使对于人类观察者来说，质量明显平庸。这个问题对于设计等主观任务尤为突出，因为没有等效于可验证软件测试的二元检查。布局感觉精致还是通用的判断取决于观察者，而 agent 在评价自己的工作时会可靠地倾向于正面。

然而，即使在确实有可验证结果的任务上，agent 有时仍会表现出阻碍其完成任务的糟糕判断。将执行工作的 agent 与评判工作的 agent 分离，成为解决这个问题的强大杠杆。这种分离本身并不能立即消除那种宽容性；评估器仍然是一个倾向于对 LLM 生成的输出宽容的 LLM。但调整独立的评估器使其持怀疑态度，比让生成器对自己持批评态度要容易得多，而一旦存在外部反馈，生成器就有具体的东西可以迭代。

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

我首先从前端设计开始实验，这是自我评估问题最明显的地方。没有任何干预，Claude 通常倾向于安全、可预测的布局，技术上功能正常但视觉上不起眼。

两个见解塑造了我为前端设计构建的 harness。首先，虽然美学不能完全简化为分数——而且个人品味总是会有所不同——但可以通过编码设计原则和偏好的评分标准来改进。”这个设计漂亮吗？”很难一致地回答，但”这是否遵循我们的良好设计原则？”给了 Claude 具体可评分的东西。其次，通过将前端生成与前端评分分离，我们可以创建一个反馈循环，推动生成器产生更强的输出。

基于此，我编写了四个评分标准，并在生成器和评估器 agent 的 prompt 中都提供了它们：

设计质量：设计感觉像一个连贯的整体，而不是零件的集合吗？这里的工作出色意味着颜色、排版、布局、图像和其他细节结合在一起，创造独特的情绪和身份。

原创性：是否有自定义决定的证据，还是这是模板布局、库默认值和 AI 生成的模式？人类设计师应该识别出有意识的创意选择。未经修改的股票组件——或 AI 生成的明显迹象，如白色卡片上的紫色渐变——在这里失败。

工艺：技术执行：排版层次、间距一致性、色彩和谐、对比度比率。这是一个能力检查，而不是创造力检查。大多数合理的实现在默认情况下在这里都做得很好；失败意味着基础被打破。

功能性：独立于美学的可用性。用户能否理解界面做什么、找到主要操作并在没有猜测的情况下完成任务？

我强调设计质量和原创性胜过工艺和功能性。Claude 在工艺和功能性方面默认已经得分很好，因为所需的技术能力自然倾向于模型。但在设计和原创性方面，Claude 通常产生充其量平庸的输出。这些标准明确惩罚高度通用的”AI 垃圾”模式，通过更重地权衡设计和原创性，它推动模型朝着更多审美风险的方向发展。

我使用带有详细分数分解的少样本示例校准了评估器。这确保了评估器的判断与我的偏好一致，并减少了迭代过程中的分数漂移。

我在 Claude Agent SDK 上构建了这个循环，这使得编排变得简单。生成器 agent 首先基于用户 prompt 创建 HTML/CSS/JS 前端。我给评估器提供了 Playwright MCP，让它可以在评分每个标准并编写详细评论之前直接与实时页面交互。在实践中，评估器会自己导航页面，截图并仔细研究实现，然后产生评估。该反馈作为输入流回生成器用于下一次迭代。我为每个生成运行 5 到 15 次迭代，每次迭代通常随着生成器响应评估器的批评而向更独特的方向推进。由于评估器主动导航页面而不是对静态截图进行评分，每个循环都需要实际的挂钟时间。完整运行长达四小时。我还指示生成器在每次评估后做出战略决定：如果分数趋势良好，则完善当前方向；如果方法不起作用，则转向完全不同的美学。

在多次运行中，评估器的评估在趋于平稳之前在迭代中有所改善，仍有提升空间。一些生成增量完善。其他生成在迭代之间进行了急剧的美学转变。

标准的措辞以我没有完全预料到的方式引导了生成器。包含诸如”最好的设计是博物馆质量”之类的短语将设计推向了特定的视觉趋同，表明与标准相关的 prompt 直接塑造了输出的特征。

虽然分数在迭代中普遍提高，但模式并不总是线性的。后期的实现作为一个整体往往更好，但我经常看到我更喜欢中间迭代而不是最后一个的情况。实现复杂性也倾向于在各轮中增加，生成器响应评估器的反馈而达到更雄心勃勃的解决方案。即使在第一次迭代中，输出也明显优于完全没有 prompt 的基线，这表明标准和相关的语言本身在任何评估器反馈导致进一步完善之前就将模型推向了远离通用默认值。

在一个值得注意的例子中，我 prompt 模型创建一个荷兰艺术博物馆的网站。到第九次迭代时，它为一个虚构的博物馆产生了一个干净、深色主题的着陆页。页面视觉上精致，但大体上符合我的期望。然后，在第十个循环中，它完全放弃了这种方法，并将网站重新构想为空间体验：一个在 CSS 透视中渲染的棋盘地板的 3D 房间，艺术品以自由形式的位置挂在墙上，以及基于门廊的画廊房间导航，而不是滚动或点击。这是一种我以前没有从单次生成中看到的创意飞跃。

扩展到全栈编码

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

架构

在我们早期的长期 harness 中，我们已经通过一个初始化 agent、一次实现一个功能的编码 agent 以及会话之间的上下文重置解决了连贯的多会话编码。上下文重置是一个关键解锁：harness 使用了 Sonnet 4.5，它表现出了前面提到的”上下文焦虑”倾向。创建一个能够很好地在上下文重置之间工作的 harness，对于保持模型在任务上至关重要。Opus 4.5 在很大程度上自己消除了这种行为，因此我能够完全从这个 harness 中删除上下文重置。agent 在整个构建过程中作为一个连续会话运行，Claude Agent SDK 的自动压缩沿着方式处理上下文增长。

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

规划器：我们之前的长期 harness 需要用户提前提供详细规范。我想自动化这一步，所以我创建了一个规划器 agent，它接收简单的 1-4 句 prompt 并将其扩展为完整的产品规范。我 prompt 它在范围上要雄心勃勃，并专注于产品上下文和高层技术设计，而不是详细的技术实现。这种强调的原因是，如果规划器试图提前指定细节技术细节并且出错了，规范中的错误会级联到下游实现中。约束 agent 要产生的交付成果并让它们在工作时弄清楚路径似乎更明智。我还要求规划器找到机会将 AI 功能编织到产品规范中。（参见底部附录中的示例。）

生成器：早期 harness 的一次一个功能的方法在范围管理方面效果很好。我在这里应用了类似的模型，指示生成器以冲刺方式工作，每次从规范中选取一个功能。每个冲刺使用 React、Vite、FastAPI 和 SQLite（后来是 PostgreSQL）堆栈实现应用程序，生成器被指示在每个冲刺结束时自我评估其工作，然后再交给 QA。它还有用于版本控制的 git。

评估器：早期 harness 产生的应用程序看起来令人印象深刻，但当你实际尝试使用它们时，仍然有真正的错误。为了捕捉这些，评估器使用 Playwright MCP 像用户一样点击运行中的应用程序，测试 UI 功能、API 端点和数据库状态。然后它根据它发现的错误以及基于前端实验建模的一组标准对每个冲刺进行评分，这里调整为涵盖产品深度、功能性、视觉设计和代码质量。每个标准都有一个硬性阈值，如果任何一个低于阈值，冲刺就会失败，生成器会收到关于出了什么问题的详细反馈。

在每个冲刺之前，生成器和评估器协商冲刺合同：在任何代码编写之前就商定该工作块的”完成”是什么样子。这之所以存在，是因为产品规范故意是高层次的，我希望有一个步骤来填补用户故事和可测试实现之间的差距。生成器提出它将构建什么以及如何验证成功，评估器审查该提案以确保生成器正在构建正确的东西。两者迭代直到达成一致。

通信通过文件处理：一个 agent 会写一个文件，另一个 agent 会读取它并在该文件内或用新文件响应，前一个 agent 会依次读取该文件。然后生成器根据商定的合同构建，然后再将工作交给 QA。这使工作忠实地符合规范，而不会过早地过度指定实现。

运行 harness

对于这个 harness 的第一个版本，我使用了 Claude Opus 4.5，用完整 harness 和单 agent 系统对比运行用户 prompt。我使用 Opus 4.5 是因为开始这些实验时它是我们最好的编码模型。

我写了以下 prompt 来生成复古视频游戏制作器：

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

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

Harness	持续时间	成本
Solo	20 分钟	$9
Full harness	6 小时	$200

harness 贵了 20 多倍，但输出质量的差异显而易见。

我期望的是一个界面，可以在其中构建关卡及其组件（精灵、实体、瓦片布局），然后点击播放实际玩关卡。我先打开了 solo 运行的输出，初始应用程序似乎符合那些期望。

然而，当我点击浏览时，问题开始出现。布局浪费了空间，固定高度的面板让视口的大部分保持空白。工作流程很僵化。尝试填充关卡提示我先创建精灵和实体，但 UI 中没有任何东西引导我朝该顺序进行。更重要的是，实际游戏是坏的。我的实体出现在屏幕上，但没有任何东西响应输入。深入研究代码发现，实体定义和游戏运行时之间的连线被破坏了，表面上没有任何迹象表明问题在哪里。

评估了 solo 运行后，我将注意力转向了 harness 运行。这次运行从相同的单句 prompt 开始，但规划器步骤将 prompt 扩展为分布在 10 个冲刺中的 16 个功能规范。它远远超出了 solo 运行尝试的内容。除了核心编辑器和播放模式，规范还要求精灵动画系统、行为模板、音效和音乐、AI 辅助的精灵生成器和关卡设计器，以及具有可共享链接的游戏导出。我给规划器提供了我们的前端设计技能的访问权限，它读取并使用该技能创建应用程序的视觉设计语言作为规范的一部分。对于每个冲刺，生成器和评估器协商一个合同，定义冲刺的具体实现细节，以及将测试的可测试行为以验证完成。

应用程序立即显示出比 solo 运行更多的精致和流畅性。画布使用了整个视口，面板大小合理，界面具有与规范中的设计方向一致的视觉身份。我在 solo 运行中看到的一些笨拙仍然存在——工作流程仍然没有明确说明你应该在尝试填充关卡之前构建精灵和实体，我不得不通过摸索来弄清楚这读作基础模型产品直觉的差距，而不是 harness 设计要解决的问题，虽然它确实表明了一个地方，harness 内部的有针对性迭代可以帮助进一步提高输出质量。

浏览编辑器时，新运行相对于 solo 的优势变得更加明显。精灵编辑器更丰富、功能更全，工具调色板更干净、颜色选择器更好、缩放控制更可用。

因为我要求规划器将 AI 功能编织到其规范中，应用程序还附带了内置的 Claude 集成，让我可以通过 prompt 生成游戏的不同部分。这显著加快了工作流程。

最大的区别在于播放模式。我实际上能够移动我的实体并玩游戏。物理有一些粗糙的边缘——我的角色跳到了平台上但最终与其重叠，这感觉直观上不对——但核心东西有效，这是 solo 运行未能做到的。稍微移动后，我在 AI 的游戏关卡构造方面确实遇到了一些限制。有一堵大墙，我无法跳过，所以我被困住了。这表明有一些常识性改进和边缘情况，harness 可以处理以进一步完善应用程序。

阅读日志可以清楚地看到，评估器保持实现符合规范。每个冲刺，它遍历冲刺合同的测试标准，并通过 Playwright 练习运行的应用程序，对任何偏离预期行为的内容记录错误。合同很细粒度——仅冲刺 3 就有 27 个涵盖关卡编辑器的标准——评估器的发现具体到足以采取行动而无需额外调查。下表显示了我们的评估器识别的几个问题示例：

合同标准	评估器发现
矩形填充工具允许点击拖拽以用选定的瓦片填充矩形区域	失败——工具仅在拖拽开始/结束点放置瓦片，而不是填充区域。`fillRectangle` 函数存在但在 `mouseUp` 上未正确触发。
用户可以选择和删除放置的实体生成点	失败——`LevelEditor.tsx:892` 处的删除键处理程序要求同时设置 `selection` 和 `selectedEntityId`，但单击实体仅设置 `selectedEntityId`。条件应该是 `selection \|\| (selectedEntityId && activeLayer === 'entity')`。
用户可以通过 API 重新排序动画帧	失败——`PUT /frames/reorder` 路由定义在 `/{frame_id}` 路由之后。FastAPI 将 ‘reorder’ 匹配为 frame_id 整数并返回 422：”无法将字符串解析为整数。”

让评估器在这个水平上运行需要工作。开箱即用，Claude 是一个糟糕的 QA agent。在早期运行中，我看到它识别出合法问题，然后自己说服自己认为这不是什么大问题，并仍然批准工作。它还倾向于进行表面测试，而不是探索边缘情况，因此更微妙的错误经常溜过。调整循环是读取评估器的日志，找到其判断与我的判断不同的示例，并更新 QA 的 prompt 以解决这些问题。这种开发循环经过几轮后，评估器的评估才以我认为合理的方式进行。即使在那时，harness 输出也显示了模型 QA 能力的局限性：小的布局问题、感觉不直观的地方交互，以及评估器没有彻底练习的更深层嵌套功能中未发现的错误。显然有更多的验证提升空间可以通过进一步调整来捕获。但与 solo 运行相比，后者的应用程序核心功能根本不工作，提升是显而易见的。

迭代 harness

第一组 harness 结果令人鼓舞，但它也很庞大、缓慢且昂贵。合乎逻辑的下一步是找到简化 harness 而不降低其性能的方法。这部分是常识，部分是更一般原则的功能：harness 中的每个组件都编码了一个关于模型自己不能做什么的假设，这些假设值得进行压力测试，既因为它们可能不正确，也因为随着模型的改进，它们可能很快过时。我们的博客文章”构建有效的 Agent”将潜在想法框架为”找到尽可能简单的解决方案，仅在需要时增加复杂性”，这是一种在维护 agent harness 的任何人身上持续显示的模式。

在我第一次简化的尝试中，我大幅度削减了 harness 并尝试了一些有创意的新想法，但我无法复现原始的性能。也很难判断 harness 设计的哪些部分实际上是承重的，以及在什么方面。基于那次经验，我转向了更有条理的方法，一次删除一个组件并审查它对最终结果的影响。

在经历这些迭代循环时，我们还发布了 Opus 4.6，这为进一步减少 harness 复杂性提供了动机。有充分的理由期望 4.6 需要的支撑少于 4.5。从我们的发布博客：”[Opus 4.6] 计划更仔细，在更长时间内持续 agent 任务，可以在更大的代码库中更可靠地运行，并且具有更好的代码审查和调试技能来捕捉自己的错误。”它还在长上下文检索方面有显著改善。这些是 harness 已经构建来补充的所有能力。

删除冲刺结构

我首先完全删除了冲刺结构。冲刺结构有助于将工作分解为块，以便模型连贯地工作。鉴于 Opus 4.6 的改进，有充分的理由相信模型可以在没有这种分解的情况下本机处理工作。

我保留了规划器和评估器，因为每个都继续增加明显的价值。没有规划器，生成器范围不足：给定原始 prompt，它会开始构建而不用先规范其工作，最终创建一个功能不如规划器丰富的应用程序。

删除了冲刺结构后，我将评估器移动到运行结束时的一次通过，而不是每次冲刺都评分。由于模型更强大，评估器在某些运行中的承重作用发生了变化，其有用性取决于任务相对于模型自己能可靠地做什么而处于的位置。在 4.5 上，这个边界很接近：我们的构建处于生成器能够良好 solo 的边缘，评估器在整个构建中捕捉到有意义的问题。在 4.6 上，模型的原始能力增加了，因此边界向外移动。曾经需要评估器检查才能连贯实现的任务，现在通常在生成器自己能良好处理的范围内，对于这些范围内的任务，评估器成为不必要的开销。但对于仍处于生成器能力边缘的构建部分，评估器继续提供真正的提升。

实际含义是，评估器不是一个固定的肯定或否定决定。当任务超出了当前模型可靠 solo 能做的事情时，它是值得成本的。

除了结构简化，我还添加了 prompt 来改进 harness 将 AI 功能构建到每个应用程序中的方式，特别是让生成器构建一个能够通过工具驱动应用程序自身功能的适当 agent。这需要真正的迭代，因为相关知识足够新，Claude 的训练数据对其覆盖稀薄。但通过足够的调整，生成器正确构建了 agent。

更新后的 harness 的结果

为了将更新后的 harness 投入测试，我使用了以下 prompt 来生成数字音频工作站（DAW），一个用于作曲、录音和混音歌曲的音乐制作程序：

在浏览器中使用 Web Audio API 构建功能齐全的 DAW。

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

大部分时间用于构建器，它在没有 Opus 4.5 所需的冲刺分解的情况下连贯运行了两个多小时。

Agent 和阶段	持续时间	成本
规划器	4.7 分钟	$0.46
构建（第 1 轮）	2 小时 7 分钟	$71.08
QA（第 1 轮）	8.8 分钟	$3.24
构建（第 2 轮）	1 小时 2 分钟	$36.89
QA（第 2 轮）	6.8 分钟	$3.09
构建（第 3 轮）	10.9 分钟	$5.88
QA（第 3 轮）	9.6 分钟	$4.06
V2 Harness 总计	3 小时 50 分钟	$124.70

与之前的 harness 一样，规划器将单行 prompt 扩展为完整规范。从日志中，我可以看到生成器模型在规划应用程序、设计 agent、连接 agent 并在交给 QA 之前对其进行测试方面做得很好。

尽管如此，QA agent 仍然捕捉到了真正的差距。在它的第一轮反馈中，它指出：

这是一个强大的应用程序，具有卓越的设计保真度、坚实的 AI agent 和良好的后端。主要失败点是功能完整性——虽然应用程序看起来令人印象深刻且 AI 集成效果良好，但几个核心 DAW 功能仅显示而没有交互深度：片段无法在时间线上拖动/移动，没有乐器 UI 面板（合成器旋钮、鼓垫），没有视觉效果编辑器（EQ 曲线、压缩器电平表）。这些不是边缘情况——它们是使 DAW 可用的核心交互，并且规范明确要求它们。

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

剩余差距：

音频录制仍然仅为存根（按钮切换但没有麦克风捕获）

通过边缘拖动调整片段大小和片段分割未实现

效果可视化是数字滑块，而不是图形的（没有 EQ 曲线）

当留下自己的设备时，生成器仍然可能遗漏细节或存根功能，而 QA 仍然在捕捉这些最后一英里问题以便生成器修复方面增加了价值。

基于 prompt，我期望的是一个程序，可以在其中创建旋律、和声和鼓模式，将它们编排成歌曲，并一路上从集成 agent 获得帮助。下面的视频显示了结果。

该应用程序远非专业音乐制作程序，agent 的歌曲作曲技能显然还需要大量工作。此外，Claude 实际上听不到，这使得 QA 反馈循环在音乐品味方面效果较差。

但最终应用程序具有功能性音乐制作程序的所有核心部分：在浏览器中运行的工作编排视图、混音器和传输。除此之外，我能够完全通过 prompt 组合一个简短的歌曲片段：agent 设置了速度和调性，放下旋律，构建鼓轨，调整混音器电平并添加混响。歌曲作曲的核心原语都在场，agent 可以通过工具自主驱动它们，使用工具从端到端创建简单的制作。你可以说它还没有音准完美——但它正在接近那里。

下一步

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

考虑到这一点，这项工作中值得传承的几点经验。始终良好的做法是与你正在构建的模型进行实验，在现实问题上读取其痕迹，并调整其性能以实现你想要的结果。在处理更复杂的任务时，有时从分解任务并将专门化的 agent 应用于问题的每个方面可以获得提升。当新模型发布时，通常良好的做法是重新检查 harness，删除不再承重的性能部分，并添加新部分以实现以前可能无法实现的更大能力。

从这项工作中，我的信念是，有趣的 harness 组合空间不会随着模型的改进而缩小。相反，它会移动，AI 工程师有趣的工作是继续找到下一个新颖的组合。

致谢

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

还要感谢 Jake Eaton、Alyssa Leonard 和 Stef Sequeira 帮助塑造这篇文章。

附录

规划器 agent 生成的示例计划

RetroForge - 2D 复古游戏制作器

概述

RetroForge 是一个基于网络的创意工作室，用于设计和构建 2D 复古风格的视频游戏。它将经典 8 位和 16 位游戏美学的怀旧魅力与现代、直观的编辑工具结合在一起——让从爱好者创作者到独立开发者的任何人都可以无需编写传统代码来让他们的游戏想法变为现实。

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

RetroForge 的目标用户是那些喜欢复古游戏美学但想要现代便利的创作者。无论是重现童年时期的平台游戏、RPG 还是动作游戏，还是在复古约束内发明全新的体验，用户都可以快速原型制作、视觉迭代并与他人分享他们的创作。

功能