面向长期运行型应用开发的 Harness 设计 （原文译文）
发布于 2026 年 3 月 24 日
Harness 设计是前沿智能体编程（agentic coding）领域实现高性能的关键。本文将介绍我们如何通过这一设计，在前端开发和长期自主软件工程领域进一步提升 Claude 的能力。
作者：普里特维・拉贾塞卡兰（Prithvi Rajasekaran），Anthropic 实验室团队成员
过去几个月里，我一直在攻克两个相互关联的难题：一是让 Claude 生成高质量前端设计，二是让它在无需人工干预的情况下构建完整应用。这项工作源于我们早期在前端设计能力和长期运行型编码智能体 Harness 上的探索 —— 当时我和同事通过提示词工程与 Harness 设计，已将 Claude 的性能提升至远超基准水平，但两者最终都遇到了瓶颈。
为实现突破，我探索了适用于两个截然不同领域的全新 AI 工程方法：一个领域（前端设计）依赖主观审美判断，另一个（自主编程）则强调可验证的正确性与可用性。受生成对抗网络（GANs）启发，我设计了包含生成器智能体（generator） 和评估器智能体（evaluator） 的多智能体架构。要打造一个能可靠且有 “审美” 地评估输出结果的评估器，首先需要制定一套标准，将 “这个设计是否优秀” 这类主观判断转化为具体、可量化的评分指标。
随后，我将这些技术应用于长期自主编程任务，并延续了早期 Harness 开发中的两个核心经验：将构建过程拆解为可处理的模块，以及通过结构化产物在不同会话间传递上下文。最终形成的三智能体架构 —— 规划器（planner）、生成器（generator）和评估器（evaluator）—— 能够在数小时的自主编码会话中，生成功能完善的全栈应用。
朴素实现方案的局限性
我们此前已证明，Harness 设计对长期运行型智能体编程的有效性至关重要。在早期实验中，我们通过初始化智能体将产品需求分解为任务清单，再由编码智能体逐一实现功能，并通过产物传递在不同会话间保持上下文连贯性。开发者社区也逐渐形成了类似共识，例如 “拉尔夫・威格姆（Ralph Wiggum）” 方法就通过钩子函数或脚本让智能体保持持续迭代。
但仍有一些问题长期存在。面对更复杂的任务，智能体在长时间运行后容易 “偏离轨道”。通过拆解分析，我们发现智能体执行此类任务时存在两种常见失效模式：
其一，随着上下文窗口被占满，模型在长任务中容易失去连贯性（详见我们关于上下文工程的文章）。部分模型还会出现 “上下文焦虑” 现象 —— 当感知到接近自身上下文限制时，会过早结束工作。而 “上下文重置” 机制（完全清空上下文窗口并启动新智能体，同时通过结构化传递保留前序智能体的状态和后续步骤）能同时解决这两个问题。
这与 “压缩（compaction）” 机制不同：压缩是原地总结对话早期内容，让同一智能体在缩短的历史记录上继续工作。虽然压缩能保持连续性，但无法给智能体提供 “干净的起点”，因此 “上下文焦虑” 可能依然存在。重置机制虽能提供干净起点，但需要传递产物包含足够状态，确保新智能体无缝接手工作。在早期测试中，我们发现 Claude Sonnet 4.5 的 “上下文焦虑” 现象尤为明显，仅靠压缩不足以保障长任务性能，因此上下文重置成为 Harness 设计的核心要素。这一方案虽解决了核心问题，但也增加了每次 Harness 运行的编排复杂度、令牌开销和延迟。
其二，自我评估问题（这是我们此前未解决的痛点）。当要求智能体评估自己的产出时，它们往往会自信地给出正面评价 —— 即便在人类观察者看来，产出质量明显平庸。这一问题在设计等主观任务中尤为突出，这类任务不存在软件测试那样的二元验证标准。界面布局是否精致、是否平庸，本质是主观判断，而智能体在自我评分时总是倾向于给出正向反馈。
即便在有可验证结果的任务中，智能体有时也会因判断失误影响任务进度。将执行工作的智能体与评估工作的智能体分离，被证明是解决这一问题的有效手段。这种分离本身并不能立即消除评估的宽容性 —— 评估器本质仍是大语言模型，对同类模型生成的输出天然倾向于宽容。但将独立评估器调优为 “持怀疑态度”，远比让生成器自我批判容易得多；而一旦获得外部反馈，生成器就有了明确的迭代方向。
前端设计：让主观质量可量化评分
我首先从前端设计领域入手实验，因为自我评估问题在这里表现得最为明显。在无任何干预的情况下，Claude 通常会倾向于生成安全、可预测的布局 —— 技术上可用，但视觉上毫无亮点。
我为前端设计构建的 Harness 源于两个核心洞察：第一，虽然美学无法完全量化（个人审美始终存在差异），但可以通过编码设计原则和偏好的评分标准来提升质量。“这个设计是否美观？” 难以给出一致答案，但 “这个设计是否符合优质设计原则？” 能为 Claude 提供明确的评分依据。第二，将前端生成与前端评分分离，可构建驱动生成器产出更优结果的反馈循环。
基于这一思路，我制定了四项评分标准，并将其纳入生成器和评估器的提示词中：
- 设计质量：设计是否呈现出连贯的整体感，而非零散部分的堆砌？优秀的设计应让色彩、排版、布局、图像等细节融合统一，形成独特的氛围和辨识度。
- 原创性：设计中是否体现出定制化决策，还是仅使用模板布局、库默认样式和 AI 生成的通用模式？人类设计师应能识别出刻意的创意选择。未修改的现成组件（或带有紫色渐变叠加白色卡片等 AI 生成痕迹的设计）将被判定为不达标。
- 工艺水准：技术执行质量，包括排版层级、间距一致性、色彩协调性和对比度。这是对技术能力的检验，而非创意检验。大多数合理实现默认都能达标，未达标则意味着基础技术存在缺陷。
- 功能性：与美学无关的可用性。用户能否理解界面功能、找到核心操作，并无需猜测即可完成任务？
我将设计质量和原创性置于工艺水准和功能性之上。Claude 在工艺和功能方面的表现本就出色 —— 所需的技术能力对模型而言较为自然。但在设计和原创性上，Claude 生成的输出往往平庸乏味。该标准明确 penalizes 高度通用的 “AI 模板化产物”，通过加重设计和原创性的权重，推动模型在美学上承担更多风险、进行更多创新。
我通过少量带详细分数拆解的示例对评估器进行校准，确保其判断与我的偏好一致，并减少迭代过程中的评分偏差。
这一循环基于 Claude Agent SDK 构建，编排过程简洁高效：生成器智能体首先根据用户提示创建 HTML/CSS/JS 前端；评估器借助 Playwright MCP（模型控制协议）直接与运行中的页面交互，随后对每项标准评分并撰写详细评论。实际运行中，评估器会自主导航页面、截图分析，在深入研究实现细节后再给出评估结果。这些反馈会作为输入传递给生成器，用于下一轮迭代。每个生成任务通常运行 5 至 15 轮迭代，每轮迭代都会根据评估器的评论，推动生成器向更具独特性的方向优化。由于评估器需要主动导航页面而非仅对静态截图评分，每个循环都需要实际耗时，完整运行时间最长可达四小时。我还要求生成器在每次评估后做出策略决策：若分数呈上升趋势，则优化当前方向；若方案无效，则彻底转向全新美学风格。
在多轮运行中，评估器的评估质量会在迭代中逐步提升，随后趋于平稳，仍有进一步优化空间。部分生成结果会逐步细化，另一些则在迭代间出现显著的美学转向。
评分标准的措辞对生成器的引导效果超出了我的预期。例如，“最佳设计应具备博物馆级水准” 这样的表述，会推动设计向特定视觉风格收敛，这表明与标准相关的提示词会直接影响输出的核心特征。
虽然分数总体呈上升趋势，但并非严格线性。后期实现整体更优，但我经常发现中间某轮迭代的结果比最终版本更合预期。实现复杂度也会随轮次增加 —— 生成器为响应评估器的反馈，会尝试更具挑战性的解决方案。即便在第一轮迭代中，输出结果也明显优于无任何提示的基准版本，这表明在评估器反馈带来进一步优化前，标准本身及相关表述已引导模型摆脱了通用默认样式。
一个典型案例是，我要求模型为荷兰艺术博物馆创建网站。第九轮迭代时，模型生成了一个简洁的深色主题虚构博物馆首页，视觉精致但符合预期。而在第十轮，模型彻底抛弃原有方案，将网站重新构想为空间化体验：通过 CSS 透视效果渲染带方格地板的 3D 房间，艺术品以自由形式悬挂在墙上，用户通过 “门口” 而非滚动或点击在展厅间导航。这种创造性突破是单次生成无法实现的。
扩展至全栈编程
基于这些发现，我将这种受 GAN 启发的模式应用于全栈开发。生成器 - 评估器循环与软件工程生命周期天然契合 —— 代码审查和质量保障（QA）在结构上与设计评估器扮演着相同角色。
架构设计
在早期的长期运行型 Harness 中，我们通过初始化智能体、按功能模块工作的编码智能体，以及会话间的上下文重置，实现了连贯的多会话编程。上下文重置是关键突破：该 Harness 基于 Sonnet 4.5 构建，而该模型存在前文提到的 “上下文焦虑” 问题。构建能良好支持上下文重置的 Harness，是确保模型专注任务的核心。而 Opus 4.5 本身已大幅改善了这一行为，因此我在此次 Harness 中完全移除了上下文重置机制。智能体在整个构建过程中保持连续会话，Claude Agent SDK 的自动压缩功能会处理上下文增长问题。
本次工作在原有 Harness 基础上构建了三智能体系统，每个智能体针对我在前期运行中发现的特定缺口设计：
- 规划器（Planner）：早期的长期运行型 Harness 要求用户预先提供详细需求说明。为自动化这一步骤，我设计了规划器智能体 —— 它能将 1-4 句简短提示扩展为完整产品需求说明。我要求它在范围上大胆规划，重点关注产品背景和高层技术设计，而非具体技术实现。这是因为若规划器过早指定细粒度技术细节且出现错误，这些错误会在后续实现中逐级放大。更合理的做法是明确智能体的交付物，让它们在工作过程中自主规划实现路径。我还要求规划器在产品需求中融入 AI 功能（附录提供示例）。
- 生成器（Generator）：早期 Harness 中 “一次实现一个功能” 的模式在范围管理上效果良好，我在此沿用了类似思路 —— 要求生成器按迭代周期（sprint）工作，从需求说明中逐一选取功能实现。每个迭代周期都基于 React、Vite、FastAPI 和 SQLite（后期改为 PostgreSQL）技术栈构建应用，生成器需在每个迭代周期结束后自我评估，再移交至 QA 环节。此外，它还集成了 Git 版本控制功能。
- 评估器（Evaluator）：早期 Harness 生成的应用往往表面亮眼，但实际使用时存在大量漏洞。为解决这一问题，评估器借助 Playwright MCP 模拟用户操作 —— 点击运行中的应用，测试 UI 功能、API 端点和数据库状态。随后，它会根据发现的漏洞，以及一套基于前端实验改编的标准（涵盖产品深度、功能性、视觉设计和代码质量），对每个迭代周期进行评分。每项标准都设有硬性阈值，若任意一项未达标，迭代周期即判定失败，生成器会收到关于问题的详细反馈。
在每个迭代周期开始前，生成器和评估器会协商一份 “迭代契约”：在编写任何代码前，就该模块工作的 “完成标准” 达成一致。这一环节的必要性在于，产品需求故意设计为高层级，需要通过该步骤衔接用户故事与可测试的实现方案。生成器提出拟构建内容及验证成功的方式，评估器审核提案以确保生成器在构建正确的功能。双方会反复迭代直至达成共识。
智能体间通过文件通信：一个智能体写入文件，另一个智能体读取后，要么在该文件中回应，要么创建新文件供前一个智能体读取。生成器根据达成一致的契约构建产品，再将工作移交至 QA 环节。这种方式既能确保工作忠实于需求说明，又不会过早过度限定实现细节。
Harness 运行测试
我使用 Claude Opus 4.5 构建了首个版本的 Harness，并将用户提示同时在完整 Harness 和单智能体系统中运行以作对比 —— 选择该模型是因为实验启动时，它是我们最擅长编码的模型。
我编写了如下提示词生成复古视频游戏制作工具：
创建一款 2D 复古游戏制作工具，包含关卡编辑器、精灵编辑器、实体行为设置和可玩测试模式。
下表展示了不同 Harness 的运行时间和总成本：
表格
| Harness 类型 | 运行时长 | 成本 |
|---|---|---|
| 单智能体（Solo） | 20 分钟 | 9 美元 |
| 完整 Harness | 6 小时 | 200 美元 |
完整 Harness 的成本是单智能体的 20 倍以上，但输出质量的差异一目了然。
我原本期望得到一个这样的界面：用户可构建关卡及组件（精灵、实体、瓦片布局），点击 “播放” 即可实际体验关卡。打开单智能体生成的应用时，初始界面看似符合预期，但点击操作后问题逐渐暴露：布局浪费空间，固定高度的面板导致大部分视口闲置；工作流程僵化 —— 尝试填充关卡时，系统要求先创建精灵和实体，但界面未提供任何流程引导；更关键的是，游戏核心功能无法使用 —— 实体虽能显示在屏幕上，但完全不响应输入。深入查看代码后发现，实体定义与游戏运行时之间的关联逻辑存在缺陷，且界面无任何相关提示。
单智能体生成的应用：精灵编辑器界面、精灵创建过程、尝试游玩关卡失败的场景
评估完单智能体运行结果后，我转向了 Harness 运行产物。该运行基于相同的单句提示，但规划器环节将其扩展为包含 16 项功能、分 10 个迭代周期的需求说明，远超单智能体的尝试范围。除核心编辑器和测试模式外，需求说明还包含精灵动画系统、行为模板、音效和音乐、AI 辅助精灵生成与关卡设计，以及支持分享链接的游戏导出功能。我为规划器提供了前端设计能力文档，它在需求说明中融入了该文档的视觉设计语言。每个迭代周期中，生成器和评估器都会协商契约，明确该周期的具体实现细节和验证完成的可测试行为。
Harness 生成的应用立即展现出比单智能体产物更精致、流畅的体验：画布充分利用视口空间，面板尺寸合理，界面遵循需求说明中的设计方向，保持一致的视觉标识。单智能体产物中的部分缺陷依然存在 —— 工作流程仍未明确提示 “应先创建精灵和实体再填充关卡”，需用户自行摸索。这反映出基础模型在产品直觉上的不足，而非 Harness 设计的问题，但也表明可通过 Harness 内部的定向迭代进一步提升输出质量。
深入使用编辑器后，Harness 产物的优势更加明显：精灵编辑器功能更丰富完善，工具栏更简洁，颜色选择器更易用，缩放控制更便捷。
由于我要求规划器在需求中融入 AI 功能，该应用还内置了 Claude 集成 —— 用户可通过提示词生成游戏各部分内容，大幅提升工作流程效率。
Harness 生成的应用：初始界面（创建新游戏）、精灵编辑器（更简洁易用）、AI 辅助关卡生成过程、实际游玩场景
最大的差异体现在测试模式：我能够正常移动实体并游玩关卡。物理效果虽有瑕疵 —— 角色跳上平台后出现重叠现象，不符合直觉 —— 但核心功能可正常使用，这是单智能体产物未能实现的。游玩一段时间后，我发现 AI 生成的关卡存在局限性：有一堵高墙无法跳过，导致游戏陷入僵局。这表明 Harness 仍有改进空间，可通过优化处理此类常识性问题和边缘场景。
查看日志后发现，评估器始终确保实现与需求说明一致。每个迭代周期中，评估器都会对照契约中的测试标准，通过 Playwright 运行应用，对任何偏离预期行为的情况记录漏洞。契约粒度精细 —— 仅第三个迭代周期就包含 27 项关于关卡编辑器的标准，评估器的发现足够具体，无需额外调查即可直接采取行动。下表列出了评估器发现的部分问题：
表格
| 契约标准 | 评估器发现 | ||
|---|---|---|---|
| 矩形填充工具支持点击拖拽，用选中的瓦片填充矩形区域 | 失败—— 工具仅在拖拽起点 / 终点放置瓦片，未填充整个区域。fillRectangle 函数已存在，但未在鼠标抬起（mouseUp）时正确触发。 |
||
| 用户可选择并删除已放置的实体生成点 | 失败——LevelEditor.tsx:892 处的删除键处理器要求同时设置 selection 和 selectedEntityId，但点击实体仅设置 selectedEntityId。条件应修改为 `selection |
(selectedEntityId && activeLayer === 'entity')`。 | |
| 用户可通过 API 重新排序动画帧 | 失败——PUT /frames/reorder 路由定义在 /{frame_id} 路由之后。FastAPI 将 “reorder” 解析为帧 ID 整数，返回 422 错误：“无法将字符串解析为整数”。 |
让评估器达到这一性能水平需要大量调优。默认情况下，Claude 并非理想的 QA 智能体。早期运行中，我发现它会先识别出合理问题，随后又说服自己这些问题无关紧要并批准通过；同时，它倾向于表面测试而非探究边缘场景，导致更隐蔽的漏洞轻易逃脱。调优循环的核心是：读取评估器日志，找出其判断与我不一致的示例，更新 QA 提示词以解决这些问题。经过多轮开发循环，评估器的评分才达到我认可的合理水平。即便如此，Harness 输出仍暴露了模型 QA 能力的局限性：存在小型布局问题、部分交互不够直观，以及评估器未充分测试的深层嵌套功能中隐藏的漏洞。显然，通过进一步调优，仍有提升验证效果的空间。但与核心功能完全失效的单智能体产物相比，Harness 的优势极为显著。
Harness 迭代优化
首轮 Harness 结果令人鼓舞，但也存在体积庞大、速度缓慢、成本高昂的问题。合理的下一步是在不降低性能的前提下简化 Harness。这一优化既基于常识，也遵循一项更通用的原则：Harness 中的每个组件都隐含着对 “模型自身无法完成哪些工作” 的假设，而这些假设值得严格检验 —— 不仅因为它们可能不准确，还因为随着模型迭代，这些假设会迅速过时。我们的博客文章《构建高效智能体》（Building Effective Agents）将其核心思想概括为 “尽可能寻找最简单的解决方案，仅在必要时增加复杂度”，这一模式对所有维护智能体 Harness 的开发者都普遍适用。
我首次尝试大幅简化 Harness 并引入一些创新思路，但未能重现原始版本的性能；同时，也难以判断 Harness 设计中的哪些部分是真正 “承载核心功能” 的关键。基于这次经验，我转向更系统的方法：每次仅移除一个组件，观察其对最终结果的影响。
在迭代过程中，我们发布了 Opus 4.6，这进一步推动了 Harness 简化工作。有充分理由相信，4.6 版本所需的脚手架支持会少于 4.5 版本。正如我们在发布博客中所述：“[Opus 4.6] 规划更周密，能更长时间维持智能体任务，在大型代码库中操作更可靠，且具备更出色的代码审查和调试能力，可自行发现并修复错误。” 此外，它在长上下文检索方面也有显著提升 —— 这些都是 Harness 原本旨在补充的能力。
移除迭代周期（sprint）结构
我首先完全移除了迭代周期结构。该结构原本用于将工作分解为模块，帮助模型连贯工作。考虑到 Opus 4.6 的改进，有充分理由认为模型无需此类分解即可原生处理任务。
我保留了规划器和评估器，因为两者仍能带来明显价值。若没有规划器，生成器会出现 “范围不足” 问题：面对原始提示，它会直接开始构建而不预先制定需求说明，最终生成的应用功能远少于规划器驱动的产物。
移除迭代周期结构后，我将评估器调整为在运行结束时执行单次评估，而非逐迭代周期评分。由于模型能力大幅提升，评估器的 “核心作用” 因任务而异 —— 取决于任务相对于模型原生可靠能力的位置。在 4.5 版本中，这一边界较近：我们的构建任务处于生成器单独立能力的边缘，评估器能在整个构建过程中发现大量有价值的问题；而在 4.6 版本中，模型原生能力增强，边界向外扩展 —— 原本需要评估器校验才能连贯实现的任务，现在大多能被生成器独立完成，对于这些任务，评估器反而成为不必要的开销。但对于仍处于生成器能力边缘的构建任务部分，评估器仍能提供实质性帮助。
这一实践的核心启示是：评估器并非固定的 “非有即无” 选择。当任务超出当前模型独立可靠完成的范围时，引入评估器的成本是值得的。
在结构简化的同时，我还通过提示词优化，改进了 Harness 在应用中集成 AI 功能的方式 —— 具体而言，是让生成器构建能通过工具驱动应用自身功能的完整智能体。这一过程需要大量迭代，因为相关知识较新，Claude 的训练数据覆盖有限。但经过充分调优，生成器最终能够正确构建智能体。
优化后 Harness 的测试结果
为测试优化后的 Harness，我使用如下提示词生成数字音频工作站（DAW）—— 一款用于作曲、录音和混音的音乐制作程序：
使用 Web Audio API 在浏览器中构建功能完整的数字音频工作站（DAW）。
本次运行仍耗时较长且成本较高：约 4 小时，令牌成本 124 美元。
大部分时间用于构建环节，生成器连贯运行超过两小时，无需 Opus 4.5 版本所需的迭代周期分解。
表格
| 智能体及阶段 | 运行时长 | 成本 |
|---|---|---|
| 规划器 | 4.7 分钟 | 0.46 美元 |
| 构建（第一轮） | 2 小时 7 分钟 | 71.08 美元 |
| QA（第一轮） | 8.8 分钟 | 3.24 美元 |
| 构建（第二轮） | 1 小时 2 分钟 | 36.89 美元 |
| QA（第二轮） | 6.8 分钟 | 3.09 美元 |
| 构建（第三轮） | 10.9 分钟 | 5.88 美元 |
| QA（第三轮） | 9.6 分钟 | 4.06 美元 |
| 优化后 Harness 总计 | 3 小时 50 分钟 | 124.70 美元 |
与之前的 Harness 类似，规划器将单句提示扩展为完整需求说明。从日志中可以看到，生成器模型出色地完成了应用规划、智能体设计、集成和测试工作，随后才移交至 QA 环节。
尽管如此，QA 智能体仍发现了实际问题。在首轮反馈中，它指出：
“这是一款优秀的应用，具备出色的设计还原度、完善的 AI 智能体和可靠的后端。主要短板在于功能完整性 —— 虽然应用外观亮眼、AI 集成效果良好，但多项核心 DAW 功能仅为展示效果，无实际交互深度：时间轴上的片段无法拖拽移动，无乐器 UI 面板（合成器旋钮、鼓垫），也无视觉效果编辑器（均衡器曲线、压缩器仪表）。这些并非边缘场景，而是让 DAW 具备可用性的核心交互功能，且需求说明中明确要求实现这些功能。”
第二轮反馈中，它再次发现多个功能缺口：
“剩余问题：
- 音频录制仍为占位功能（按钮可切换状态，但无麦克风采集）
- 未实现通过拖拽片段边缘调整长度和片段分割功能
- 效果可视化仅为数字滑块，无图形化界面（无均衡器曲线）”
若完全放任生成器自主工作，它仍可能遗漏细节或仅实现占位功能，而 QA 环节在捕捉这些 “最后一公里” 问题并让生成器修复方面，仍具有重要价值。
基于提示词预期，我原本期望得到一款这样的程序：用户可创建旋律、和声和鼓点，将其编排为歌曲，并在集成智能体的协助下完成创作。最终应用虽远非专业音乐制作程序，且智能体的歌曲创作能力仍有很大提升空间；此外，Claude 无法实际 “聆听” 音频，这也导致 QA 反馈循环在音乐审美判断方面效果有限。
但最终应用包含了功能性音乐制作程序的所有核心组件：运行在浏览器中的工作编排视图、混音器和播放控制。更重要的是，我完全通过提示词完成了一段简短歌曲的创作：智能体设置速度和调号、编排旋律、构建鼓轨、调整混音电平，并添加混响效果。歌曲创作的核心原语已全部具备，智能体可通过工具自主驱动这些功能，从头到尾完成简单音乐制作。可以说，它虽尚未 “完美无瑕”，但已初具雏形。
未来展望
随着模型持续迭代，我们有理由期待它们能处理更长时间、更复杂的任务。在某些情况下，这意味着模型周围的脚手架支持将逐渐减少 —— 开发者可等待下一代模型，让部分问题自行解决。但另一方面，模型能力越强，构建能实现 “超出模型基准能力的复杂任务” 的 Harness 的空间就越大。
基于这项工作，有几条经验值得延续：始终针对正在使用的模型进行实验，在实际问题中分析其运行轨迹，通过调优实现预期结果；处理更复杂任务时，将任务分解并为每个环节配备专用智能体，往往能挖掘出更多潜力；当新版本模型发布时，通常需要重新审视 Harness—— 移除不再承载核心功能的组件，同时添加新组件以实现此前无法完成的更高级功能。
通过这项工作，我更加确信：随着模型迭代，有趣的 Harness 组合空间并不会缩小，而是会不断演变。对 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）在文章撰写过程中提供的帮助。
附录：规划器智能体生成的需求示例
plaintext
RetroForge - 2D 复古游戏制作工具
概述
RetroForge 是一款基于网页的创意工作室，专为设计和制作 2D 复古风格视频游戏打造。它将经典 8 位和 16 位游戏美学的怀旧魅力与现代直观的编辑工具相结合——让从爱好者到独立开发者的各类用户，无需编写传统代码即可将游戏创意变为现实。
该平台包含四个集成创意模块：用于设计游戏世界的瓦片式关卡编辑器、用于制作视觉资源的像素艺术精灵编辑器、用于定义游戏逻辑的可视化实体行为系统，以及用于实时游戏测试的可玩测试模式。通过在全流程中融入 Claude 驱动的 AI 辅助功能，RetroForge 加速了创作过程——帮助用户通过自然语言交互生成精灵、设计关卡和配置行为。
RetroForge 面向热爱复古游戏美学但追求现代便捷性的创作者。无论是重现童年记忆中的平台游戏、角色扮演游戏（RPG）或动作游戏，还是在复古风格约束下打造全新体验，用户都能快速原型设计、可视化迭代，并与他人分享作品。
功能特性
1. 项目仪表盘与管理
项目仪表盘是 RetroForge 中所有创意工作的核心枢纽。用户需要一种清晰、有序的方式管理游戏项目——创建新项目、继续未完成的工作，并快速了解每个项目的核心内容。
用户故事：作为用户，我希望：
- 创建带有名称和描述的新游戏项目，以便开始设计游戏
- 以视觉卡片形式查看所有现有项目，卡片显示项目名称、最后修改日期和缩略图预览，以便快速找到并继续工作
- 打开任意项目进入完整游戏编辑器工作区，以便开展游戏开发
- 删除不再需要的项目（含确认对话框防止误操作），以便保持工作区整洁
- 复制现有项目作为新项目的起点，以便复用之前的工作成果
项目数据模型：每个项目包含：
- 项目元数据（名称、描述、创建/修改时间戳）
- 画布设置（分辨率：如 256x224、320x240 或 160x144）
- 瓦片尺寸配置（8x8、16x16 或 32x32 像素）
- 调色板选择
- 所有关联的精灵、瓦片集、关卡和实体定义
...
文章评论