原文: English original · Anthropic/OpenAI 官方

面向长时间运行应用开发的 harness 设计

发布于 2026 年 3 月 24 日

Harness 设计是 agentic coding 前沿性能的关键。下面介绍我们如何在 frontend design 和长时间运行的自主软件工程中进一步推进 Claude。

作者 Prithvi Rajasekaran，来自我们的 Labs 团队。

过去几个月里，我一直在研究两个相互关联的问题：让 Claude 产出高质量的 frontend design 作品，以及让它在没有人工干预的情况下构建完整应用。这项工作源自我们早先在 frontend design skill 和 long-running coding agent harness 上的努力。当时我和同事通过 prompt engineering 与 harness 设计，把 Claude 的表现大幅提升到 baseline 之上，但两者最终都碰到了天花板。

为了突破这个限制，我寻找了能够同时适用于两个差异很大的领域的新型 AI 工程方法：一个领域由主观品味定义，另一个领域由可验证的正确性和可用性定义。受 Generative Adversarial Networks（GANs）启发，我设计了一种多 agent 结构，其中包含一个 generator agent 和一个 evaluator agent。

要构建一个能够可靠且有品味地给输出打分的 evaluator，首先需要制定一组标准，把“这个设计好吗？”这样的主观判断转化为具体、可评分的条目。

随后我把这些技术应用到长时间运行的自主 coding 中，并沿用了早先 harness 工作中的两条经验：把构建过程拆成可处理的工作块，以及用结构化 artifacts 在 sessions 之间交接上下文。最终结果是一个三 agent 架构：planner、generator 和 evaluator。它能够在持续数小时的自主 coding sessions 中产出丰富的 full-stack 应用。

为什么朴素实现会力不从心

我们此前已经展示过，harness 设计会显著影响长时间运行的 agentic coding 效果。在早先的一个实验中，我们使用 initializer agent 将产品规格拆解为任务列表，再由 coding agent 每次实现一个功能，并交接 artifacts 来跨 sessions 保留上下文。

更广泛的开发者社区也逐渐收敛到类似洞见，例如 “Ralph Wiggum” 方法会使用 hooks 或 scripts，让 agents 保持在连续迭代循环中。

但有些问题始终存在。对于更复杂的任务，agent 仍然容易随着时间推移偏离轨道。在拆解这个问题时，我们观察到 agents 执行这类任务时常见的两种失败模式。

第一，随着 context window 填满，模型往往会在长任务中丧失连贯性（参见我们关于面向 AI agents 的有效上下文工程的文章）。一些模型还会表现出 “context anxiety”：当它们接近自己认为的 context limit 时，会过早开始收尾。Context resets，也就是完全清空 context window，启动一个新的 agent，并通过结构化 handoff 携带前一个 agent 的状态和下一步事项，可以同时解决这两个问题。

这不同于 compaction。Compaction 会在原位置总结对话早期部分，让同一个 agent 在压缩后的历史上继续工作。Compaction 虽然保留了连续性，但没有给 agent 一个干净的新起点，因此 context anxiety 仍然可能持续。Reset 提供了干净起点，代价是 handoff artifact 必须包含足够状态，让下一个 agent 能顺畅接手。

在早先测试中，我们发现 Claude Sonnet 4.5 表现出足够强的 context anxiety，单靠 compaction 不足以带来强劲的长任务表现，因此 context resets 成为 harness 设计中的关键。这解决了核心问题，但也为每次 harness 运行增加了编排复杂度、token 开销和延迟。

第二个问题我们此前没有处理过，那就是自我评估。当被要求评价自己产出的工作时，agents 往往会自信地夸赞成果，即便在人类观察者看来，质量明显平庸。这个问题在设计这类主观任务上尤其突出，因为这里没有等同于可验证软件测试的二元检查。

一个 layout 看起来精致还是模板化，本质上是判断题，而 agents 在给自己的工作打分时会稳定地偏正面。

不过，即便任务拥有可验证结果，agents 有时仍会表现出糟糕判断，从而阻碍它们完成任务。把执行工作的 agent 与评判工作的 agent 分离，被证明是解决这个问题的有力杠杆。这种分离本身不会立刻消除宽松倾向；evaluator 依然是 LLM，仍然倾向于对 LLM 生成的输出宽容。

但事实证明，把一个独立 evaluator 调校得更怀疑，要比让 generator 批判自己的工作容易得多。而一旦有了外部反馈，generator 就有了可以据此迭代的具体对象。

Frontend design：让主观质量可以评分

我先从 frontend design 开始实验，因为自我评估问题在这里最明显。在没有任何干预时，Claude 通常会趋向安全、可预测的 layouts：技术上可用，但视觉上平平无奇。

我为 frontend design 构建 harness 时，两个洞见起到了关键作用。第一，美感无法完全化约为分数，个人品味也总会不同，但可以通过编码设计原则和偏好的评分标准来改进。“这个设计美吗？”很难稳定回答，但“这是否遵循了我们的优秀设计原则？”给了 Claude 一个可以具体评分的对象。

第二，通过把 frontend generation 和 frontend grading 分离，我们可以创建一个反馈循环，推动 generator 朝更强输出前进。

基于这个思路，我写了四条评分标准，并在 prompt 中同时提供给 generator 和 evaluator agents：

• Design quality：设计是否像一个连贯整体，而不是零散部件的集合？这里的强输出意味着颜色、字体、layout、图像以及其他细节共同形成了鲜明的情绪和识别度。
• Originality：有没有定制化决策的证据，还是只是模板 layouts、库默认值和 AI 生成模式？人类设计师应该能看出有意的创意选择。未经修改的 stock components，或 AI 生成的典型迹象，比如白色 cards 上的紫色 gradients，在这里会失败。
• Craft：技术执行，包括字体层级、间距一致性、色彩和谐、对比度比例。这是能力检查，而不是创造力检查。多数合理实现默认就能做得不错；失败意味着基础出现问题。
• Functionality：独立于美感的可用性。用户能否理解界面做什么、找到主要操作，并在不靠猜的情况下完成任务？

我强调 design quality 和 originality，高于 craft 和 functionality。Claude 默认已经能在 craft 和 functionality 上拿到不错分数，因为所需的技术能力对模型来说往往比较自然。但在 design 和 originality 上，Claude 经常产出最多只能算平淡的结果。标准明确惩罚高度通用的 “AI slop” 模式，并通过更高权重的 design 和 originality，推动模型承担更多审美风险。

我用 few-shot examples 和详细分数拆解来校准 evaluator。这确保 evaluator 的判断与我的偏好一致，也减少了多轮迭代中的分数漂移。

我把循环构建在 Claude Agent SDK 上，这让编排保持直接。Generator agent 首先基于用户 prompt 创建 HTML/CSS/JS frontend。我给 evaluator 配置了 Playwright MCP，让它能够在打分前直接与实时页面交互，对每个标准评分并写出详细批评。实践中，evaluator 会自行浏览页面、截图，并仔细研究实现，然后产出评估。

这些反馈会回流给 generator，作为下一轮迭代的输入。每次生成我会运行 5 到 15 轮迭代；随着 generator 响应 evaluator 的批评，每轮通常都会把结果推向更鲜明的方向。因为 evaluator 会主动浏览页面，而不是给静态截图打分，每个循环都需要真实的墙钟时间。完整运行最长会拉到四小时。

我还要求 generator 在每次评估后做出策略决策：如果分数走势良好，就细化当前方向；如果当前方案不奏效，就转向完全不同的美学方向。

跨多次运行看，evaluator 的评估会在多轮迭代中逐步改善，然后进入平台期，仍然留有提升空间。有些生成会渐进式打磨。有些则会在迭代之间发生剧烈的审美转向。

标准的措辞以我没有完全预料到的方式引导了 generator。加入 “the best designs are museum quality” 这样的短语，会把设计推向某种特定的视觉收敛，这表明与标准相关的 prompting 直接塑造了输出的气质。

虽然分数通常会随着迭代提高，但模式并不总是干净的线性。后期实现整体上往往更好，但我经常看到自己更喜欢中间某轮，而不是最后一轮。实现复杂度也倾向于随轮次上升，因为 generator 会为了回应 evaluator 的反馈而追求更有野心的方案。

即便在第一轮，输出也明显优于完全没有 prompting 的 baseline，这说明标准及其相关语言本身已经在任何 evaluator 反馈带来进一步细化之前，把模型从通用默认值上拉开了。

一个值得注意的例子是，我 prompt 模型为一家荷兰艺术博物馆创建网站。到第九轮时，它已经为一家虚构博物馆产出一个干净的深色主题 landing page。页面在视觉上很精致，但大体符合我的预期。

然后，在第十个循环中，它完全抛弃了原方案，把网站重新想象成一个空间体验：一个用 CSS perspective 渲染出棋盘格地板的 3D 房间，墙上以自由位置悬挂艺术作品，并用门廊式导航在 gallery rooms 之间切换，而不是滚动或点击。这种创意跃迁，是我此前从单次生成中没有见过的。

扩展到 full-stack coding

带着这些发现，我把这个受 GAN 启发的模式应用到 full-stack 开发。Generator-evaluator 循环自然对应软件开发生命周期，其中 code review 和 QA 承担着与设计 evaluator 相同的结构性角色。

架构

在早先的 long-running harness 中，我们已经通过 initializer agent、每次处理一个功能的 coding agent，以及 sessions 之间的 context resets，解决了多 session coding 的连贯性问题。Context resets 是关键解锁点：该 harness 使用 Sonnet 4.5，而它表现出了前文提到的 “context anxiety” 倾向。创建一个能在 context resets 之间良好工作的 harness，是让模型保持在任务上的关键。

Opus 4.5 基本自行消除了这种行为，因此我能够在这个 harness 中完全去掉 context resets。Agents 在整个构建过程中以一个连续 session 运行，并由 Claude Agent SDK 的自动 compaction 处理沿途的上下文增长。

在这项工作中，我基于原始 harness 的基础构建了一个三 agent 系统，每个 agent 都对应我在早先运行中观察到的一个具体缺口。系统包含以下 agent personas：

Planner：我们之前的长时间运行 harness 要求用户预先提供详细 spec。我希望自动化这一步，因此创建了一个 planner agent，它接收简单的 1 到 4 句话 prompt，并扩展成完整产品 spec。我 prompt 它在范围上保持有野心，并聚焦于产品上下文和高层技术设计，而不是详细技术实现。

之所以这样强调，是因为我担心如果 planner 试图在一开始指定颗粒度很细的技术细节，并且弄错了，spec 中的错误会级联到下游实现。更聪明的做法似乎是约束 agents 应产出的 deliverables，然后让它们在工作中自行找出路径。我也要求 planner 寻找机会把 AI features 融入产品 specs。（参见底部 Appendix 中的示例。）

Generator：早先 harness 中一次一个功能的方法对范围管理很有效。我在这里应用了类似模型，指示 generator 以 sprints 方式工作，每次从 spec 中拿起一个功能。每个 sprint 都用 React、Vite、FastAPI 和 SQLite（后来改为 PostgreSQL）技术栈实现应用，并要求 generator 在每个 sprint 结束时先自我评估，然后交给 QA。它还使用 git 做版本控制。

Evaluator：早先 harness 产出的应用经常看起来令人印象深刻，但真正试用时仍有实际 bug。为了捕捉这些问题，evaluator 使用 Playwright MCP 像用户一样点击运行中的应用，测试 UI 功能、API endpoints 和数据库状态。然后它根据发现的 bug，以及一组源自 frontend 实验的标准为每个 sprint 打分；这些标准在这里改造为覆盖产品深度、功能性、视觉设计和代码质量。

每条标准都有硬阈值；如果任意一条低于阈值，sprint 就失败，generator 会收到关于问题所在的详细反馈。

每个 sprint 开始前，generator 和 evaluator 会协商一个 sprint contract：在写任何代码之前，就这块工作中什么算 “done” 达成一致。这个步骤存在的原因是，产品 spec 被有意保持在高层级，我希望有一个环节弥合 user stories 与可测试实现之间的距离。Generator 提出它将构建什么，以及如何验证成功；evaluator 审查这个提案，确保 generator 正在构建正确的东西。

两者会持续迭代，直到达成一致。

通信通过文件完成：一个 agent 写入文件，另一个 agent 读取文件，并在该文件中或通过新文件回应，随后前一个 agent 再读取。Generator 随后按照达成一致的 contract 构建，再把工作交给 QA。这让工作忠实于 spec，同时避免过早过度规定实现。

运行 harness

在这个 harness 的第一版中，我使用 Claude Opus 4.5，同时让用户 prompts 分别跑完整 harness 和单 agent 系统来做对比。我使用 Opus 4.5，是因为开始这些实验时，它是我们最好的 coding model。

我写了下面的 prompt 来生成一个复古电子游戏制作器：

Create a 2D retro game maker with features including a level editor, sprite editor, entity behaviors, and a playable test mode.

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

这个 harness 贵了超过 20 倍，但输出质量差异立刻显现出来。

我预期会得到一个界面，可以构建关卡及其组成部分（sprites、entities、tile layout），然后点击 play 来实际游玩这个关卡。我先打开 solo run 的输出，初始应用看起来符合这些预期。

然而随着我点击浏览，问题开始浮现。Layout 浪费空间，固定高度 panels 让大部分 viewport 空着。workflow 很僵硬。尝试填充关卡时，应用提示我先创建 sprites 和 entities，但 UI 中没有任何东西引导我按这个顺序操作。更关键的是，实际游戏坏了。我的 entities 出现在屏幕上，但没有任何东西响应输入。

深入查看代码后发现，entity definitions 与 game runtime 之间的接线坏了，而界面上没有任何提示能说明问题在哪里。

打开界面 Sprite editor 游戏玩法

打开 solo harness 创建的应用时的初始界面。

在 solo harness 创建的 sprite editor 中创建 sprite。

尝试游玩我创建的关卡，但没有成功。

评估完 solo run 后，我把注意力转向 harness run。这次运行从同一句 prompt 开始，但 planner 步骤把 prompt 扩展成横跨十个 sprints、包含 16 个功能的 spec。它远远超出了 solo run 试图完成的范围。除了核心 editors 和 play mode，spec 还要求 sprite animation system、behavior templates、音效和音乐、AI 辅助的 sprite generator 与 level designer，以及带可分享 links 的 game export。

我让 planner 可以访问我们的 frontend design skill，它读取后用来为应用创建视觉设计语言，并纳入 spec。对于每个 sprint，generator 和 evaluator 会协商 contract，定义该 sprint 的具体实现细节，以及用于验证完成度的可测试行为。

这个应用一上来就比 solo run 更精致、更顺滑。Canvas 使用了完整 viewport，panels 大小合理，界面有一致的视觉身份，并且贴合 spec 中的设计方向。Solo run 中的一些生硬感仍然存在：workflow 还是没有明确告诉你，应该先构建 sprites 和 entities，再尝试填充关卡；我必须自己摸索出来。

这更像是基础模型产品直觉上的缺口，而不是 harness 本来要解决的问题，不过它确实提示了一个地方：可以通过 harness 内部的定向迭代进一步提高输出质量。

在几个 editors 中操作时，新运行相对 solo 的优势更明显。Sprite editor 更丰富、功能更完整，有更清晰的工具 palettes、更好的 color picker，以及更可用的 zoom controls。

因为我要求 planner 把 AI features 融入 specs，应用还内置了 Claude integration，让我可以通过 prompting 生成游戏中的不同部分。这显著加快了 workflow。

打开界面 Sprite editor AI game design AI game design 游戏玩法

初始界面：在 full harness 构建的应用中创建新游戏。

Sprite editor 感觉更清爽，也更容易使用。

使用内置 AI feature 生成关卡。

使用内置 AI feature 生成关卡。

游玩我生成的游戏。

最大的差异在 play mode。我真的能够移动自己的 entity 并游玩游戏。物理效果还有一些粗糙边角：我的角色跳到平台上后与平台重叠了，这在直觉上不对。但核心功能确实可用，而 solo run 没做到。移动一会儿后，我确实碰到 AI 构建游戏关卡的一些限制。有一堵很大的墙我跳不过去，所以被卡住了。

这表明还有一些常识性改进和边界情况，harness 可以处理，以进一步打磨应用。

阅读 logs 后很清楚，evaluator 让实现始终贴合 spec。每个 sprint 中，它都会逐条走过 sprint contract 的测试标准，并通过 Playwright 操作运行中的应用，对任何偏离预期行为的地方提交 bugs。Contracts 非常细，单 Sprint 3 就有 27 条覆盖 level editor 的标准；evaluator 的发现也足够具体，无需额外调查就能采取行动。

下表展示了 evaluator 识别出的几个问题示例：

让 evaluator 达到这个水平需要下功夫。开箱即用时，Claude 是一个很差的 QA agent。在早期运行中，我看到它识别出了真实问题，随后又说服自己觉得这些问题无关紧要，并批准了工作。它也倾向于做表层测试，而不是探查边界情况，因此更微妙的 bugs 经常漏掉。调校循环是阅读 evaluator 的 logs，找出其判断与我不一致的例子，然后更新 QA 的 prompt 来解决这些问题。

经过好几轮这样的开发循环，evaluator 的评分方式才达到我认为合理的程度。即便如此，harness 输出仍然显示出模型 QA 能力的限制：小的 layout 问题、某些地方感觉不直观的交互，以及 evaluator 没有充分测试到的更深层嵌套功能中的未发现 bugs。显然还有更多验证空间可以通过进一步调校来捕获。

但与 solo run 相比，应用的核心功能在那里根本不能工作，提升是显而易见的。

迭代 harness

第一组 harness 结果令人鼓舞，但它也庞大、缓慢且昂贵。合理的下一步是寻找简化 harness 的方式，同时不降低性能。这一方面是常识，另一方面也来自一个更普遍的原则：harness 中的每个组件都编码了一个关于模型无法独自完成什么的假设，而这些假设值得 stress testing。原因有两个：它们可能不正确，而且随着模型改进，它们很快会过期。

我们的博客文章 Building Effective Agents 将底层思想表述为“找到尽可能简单的方案，并且只在需要时增加复杂度”。对于任何维护 agent harness 的人来说，这都是持续出现的模式。

在第一次简化尝试中，我大幅削减 harness，并尝试了一些有创意的新想法，但没能复现原始版本的性能。与此同时，也变得难以判断 harness 设计中的哪些部分是真正 load-bearing 的，以及它们以何种方式起作用。基于这次经验，我转向更有方法的做法：每次移除一个组件，并审查它对最终结果产生了什么影响。

在我经历这些迭代循环时，我们也发布了 Opus 4.6，这进一步促使我减少 harness 复杂度。我们有充分理由预期 4.6 会比 4.5 更少需要 scaffolding。来自我们的发布博客：“[Opus 4.6] plans more carefully, sustains agentic tasks for longer, can operate more reliably in larger codebases, and has better code review and debugging skills to catch its own mistakes.” 它在 long-context retrieval 上也有显著改善。

这些能力正是该 harness 原本被构建来补充的部分。

移除 sprint 结构

我首先完全移除了 sprint 结构。Sprint 结构此前帮助模型把工作拆成块，以便连贯处理。鉴于 Opus 4.6 的改进，我们有充分理由相信，模型可以在没有这类拆解的情况下原生处理这项工作。

我保留了 planner 和 evaluator，因为两者仍然继续提供明显价值。没有 planner 时，generator 会缩小范围：拿到原始 prompt 后，它会在没有先为工作编写 spec 的情况下直接开始构建，最终创建出一个功能不如 planner 规划版本丰富的应用。

移除 sprint 结构后，我把 evaluator 改为在运行结束时做一次单次检查，而不是每个 sprint 打分。由于模型能力强了许多，这改变了 evaluator 在某些运行中是否 load-bearing；它是否有用取决于任务相对于模型能够独自稳定完成的边界处在什么位置。在 4.5 上，这条边界很近：我们的 builds 位于 generator 能够 solo 做好的边缘，evaluator 能在整个 build 中捕获有意义的问题。

在 4.6 上，模型原始能力增强，所以边界外移。过去需要 evaluator 检查才能连贯实现的任务，现在经常已经落在 generator 能自行处理好的范围内；对于这条边界以内的任务，evaluator 就成了不必要的开销。但对于 build 中仍然位于 generator 能力边缘的部分，evaluator 继续带来真实提升。

实际含义是，是否使用 evaluator 不是固定的 yes-or-no 决策。当任务超出当前模型 solo 可靠完成的范围时，它值得付出成本。

除了结构简化，我还添加了 prompting，以改进 harness 将 AI features 构建进每个应用的方式，具体来说，是让 generator 构建一个合适的 agent，能够通过 tools 驱动应用自身功能。这需要真正的迭代，因为相关知识足够新，Claude 的训练数据覆盖得比较薄。但经过足够调校后，generator 能够正确构建 agents。

更新后 harness 的结果

为了测试更新后的 harness，我使用下面的 prompt 生成一个 Digital Audio Workstation（DAW），也就是用于作曲、录音和混音的音乐制作程序：

Build a fully featured DAW in the browser using the Web Audio API.

这次运行仍然漫长且昂贵，大约 4 小时，token 成本为 124 美元。

大部分时间花在 builder 上；它在没有 Opus 4.5 曾经需要的 sprint 拆解的情况下，连贯运行了两个多小时。

与之前的 harness 一样，planner 把一行 prompt 扩展成完整 spec。从 logs 看，generator model 很好地规划了应用和 agent 设计，完成集成，并在交给 QA 前进行了测试。

话虽如此，QA agent 仍然抓到了真实缺口。在第一轮反馈中，它指出：

这是一个很强的应用，具备出色的设计还原度、扎实的 AI agent 和良好的 backend。主要失败点在于 Feature Completeness：虽然应用看起来令人印象深刻，AI integration 也运行良好，但几个核心 DAW features 只是 display-only，没有交互深度：clips 不能在 timeline 上拖拽或移动，没有 instrument UI panels（synth knobs、drum pads），也没有可视化 effect editors（EQ curves、compressor meters）。

这些不是边界情况，而是让 DAW 可用的核心交互，并且 spec 明确要求了它们。

在第二轮反馈中，它再次抓到了几个功能缺口：

剩余缺口：

• Audio recording 仍然只是 stub-only（按钮会切换，但没有 mic capture）
• 通过 edge drag 调整 clip resize，以及 clip split，尚未实现
• Effect visualizations 是数字 sliders，而不是图形化呈现（没有 EQ curve）

如果让 generator 完全靠自己，它仍然容易漏掉细节或留下 stub features；QA 仍然能通过捕捉这些 last mile 问题为 generator 提供价值，让其修复。

基于 prompt，我预期会得到一个程序，可以创建旋律、和声与鼓点，将它们编排成歌曲，并在过程中获得集成 agent 的帮助。下面的视频展示了结果。

[Video: DAW app result demonstration.]

这个应用距离专业音乐制作程序还很远，agent 的歌曲创作能力显然也还需要大量改进。此外，Claude 实际上听不见声音，这让 QA 反馈循环在音乐品味方面没那么有效。

但最终应用具备一个可用音乐制作程序的全部核心部分：可在浏览器中运行的 arrangement view、mixer 和 transport。不止如此，我还能够完全通过 prompting 拼出一段短歌片段：agent 设置了速度和调性，写下旋律，构建鼓轨，调整 mixer levels，并添加 reverb。

歌曲创作所需的核心 primitives 已经存在，agent 也能够自主驱动它们，使用 tools 从头到尾创建一个简单作品。你可以说它还不是 pitch-perfect，但它正在接近。

接下来会怎样

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

带着这个认识，这项工作中有几条经验值得延续。始终应该围绕你正在构建的模型做实验，在真实问题上阅读它的 traces，并调校其表现，以达成你期望的结果。在处理更复杂任务时，有时可以通过拆解任务，并为问题的每个方面应用 specialized agents，获得额外提升空间。

而当新模型到来时，通常也应该重新审视 harness，去掉那些对性能不再 load-bearing 的部分，并添加新的部分，以获得此前可能无法实现的更强能力。

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

致谢

特别感谢 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 帮助打磨本文。

Appendix

Planner agent 生成的示例 plan。

RetroForge - 2D Retro Game Maker

Overview
RetroForge 是一个基于 web 的创作工作室，用于设计和构建 2D 复古风格电子游戏。它把经典 8-bit 与 16-bit 游戏美学的怀旧魅力，同现代、直观的编辑工具结合起来，让从业余创作者到独立开发者的任何人，都可以在不编写传统代码的情况下，把自己的游戏想法变成现实。

该平台提供四个集成创作模块：一个基于 tiles 的 Level Editor，用于设计游戏世界；一个 pixel-art Sprite Editor，用于制作视觉 assets；一个可视化 Entity Behavior system，用于定义游戏逻辑；以及一个即时 Playable Test Mode，用于实时 gameplay 测试。通过将 AI assistance 贯穿其中（由 Claude 提供支持），RetroForge 加速了创作过程，帮助用户通过 natural language interaction 生成 sprites、设计 levels 并配置 behaviors。

RetroForge 面向热爱复古游戏美学、但也希望拥有现代便利性的创作者。无论是重现童年时代的 platformers、RPGs 或 action games，还是在复古约束中发明全新体验，用户都可以快速 prototype、可视化迭代，并与他人分享自己的作品。

Features
1. Project Dashboard & Management
Project Dashboard 是 RetroForge 中所有创作工作的 home base。用户需要一种清晰、有组织的方式来管理游戏 projects，包括创建新项目、回到进行中的作品，并一眼理解每个 project 包含什么。

User Stories: As a user, I want to:
- 创建一个带名称和描述的新 game project，以便开始设计我的游戏
- 看到所有现有 projects 以 visual cards 形式展示，其中显示 project name、last modified date 和 thumbnail preview，以便快速找到并继续我的工作
- 打开任意 project 进入完整 game editor workspace，以便处理我的游戏
- 删除不再需要的 projects，并通过 confirmation dialog 防止误操作，以便保持 workspace 有序
- 复制一个现有 project，作为新游戏的起点，以便复用之前的工作

Project Data Model: Each project contains:

Project metadata（name、description、created/modified timestamps）
Canvas settings（resolution: e.g., 256x224, 320x240, or 160x144）
Tile size configuration（8x8, 16x16, or 32x32 pixels）
Color palette selection
All associated sprites, tilesets, levels, and entity definitions

...