★ FEATURED ARTICLE 1. 从标题拆解这个项目到底在做什么第一次看到 Recursive Game Creator: An Agentic Product-Level Experience-Oriented Game Harness 这个标题我脑子里蹦出来的第一个念头是这不就是把做游戏这件事本身当成一个可以被智能体反复迭代、自我进化的产品来对待吗拆开来看Recursive 是递归意味着系统会自己调用自己、层层递进Game Creator 是游戏创作Agentic 说明它由智能体驱动而不是靠人一步步手动操作Product-Level 强调它追求的是能拿得出手的产品级质量不是玩具 DemoExperience-Oriented 则点明了它的评判标准是体验而不是功能有没有跑通最后的 Harness 是个很关键的词它指的是一个约束框架/驾驭装置把智能体的能力框在一个可控、可复现、可评估的轨道里。把这几个词串起来这个项目的本质就清楚了它想构建一套由智能体驱动的游戏创作框架让智能体在一个受约束的马具里递归地生成、评估、改进游戏直到产出的东西达到产品级、以玩家体验为导向的水准。这跟市面上那种输入一句话生成一个小游戏的一次性工具完全不是一个思路。一次性工具是生成即结束而这个项目是生成—评估—再生成的闭环核心价值在于那个递归循环和体验评估机制。我为什么对这个方向感兴趣因为过去两年我陆陆续续试过不少 AI 辅助做游戏的路子踩过的坑基本都集中在同一个地方AI 能很快给你一个能跑的东西但那个东西离好玩差着十万八千里。功能跑通和体验达标之间隔着一整个产品化的鸿沟。而这个标题里的 Harness 和 Experience-Oriented恰恰是冲着填这条鸿沟去的。所以这篇内容我想把它当成一个真实项目来拆讲清楚它的设计思路、核心机制、实操落地方式以及我在类似实践里总结出来的避坑经验。适合谁看适合对智能体编排、游戏原型快速迭代、AI 产品化流程感兴趣的朋友不管你是刚入门想搞明白智能体做游戏到底怎么回事还是已经动手做过几个 Demo 想往产品级推进都能从里面找到能直接抄作业的东西。2. 整体架构设计与核心思路拆解2.1 为什么是递归而不是一次性生成要理解这个项目先得理解为什么它把递归放在标题最前面。一次性生成的问题在于智能体在单次调用里能承载的思考深度是有限的。你让它一步到位产出一个完整游戏它只能凭第一直觉拼凑出来的东西往往是各种元素的机械堆叠——有角色、有场景、有得分但彼此之间没有咬合感玩起来像在操作一堆互不相干的零件。递归的思路是把做游戏拆成多个可以自我审视的层级。第一轮智能体先产出一个粗糙的骨架然后系统把它当成输入让智能体以评审者的身份去看这个骨架哪里不对再以改进者的身份去修修完再评审如此循环。这就像人类做设计没有人能一稿过好作品都是改出来的。递归的价值不在于多跑几轮而在于每一轮都有明确的评估信号来指导下一轮的方向否则就是无意义的重复。这里有个关键设计点递归必须有终止条件否则智能体会陷入无限自我修改。常见的做法是设定体验评分阈值加最大迭代轮数双保险——评分达标就停或者轮数到顶就停取先到者。这个设计背后是工程上的务实考量递归是有成本的每一轮都要消耗算力和时间必须有个止损线。2.2 Agentic 驱动意味着什么Agentic 这个词现在被用得很泛但在这个项目里它有具体含义系统不是一个模型回答一个问题而是多个具备不同职责的智能体协同完成一个任务链。典型的角色划分包括策划智能体负责把模糊的需求翻译成具体的游戏机制描述实现智能体负责把机制描述转成可运行的逻辑评审智能体负责以玩家视角挑毛病调优智能体负责根据评审意见做针对性修改。为什么要拆成多个智能体而不是一个大模型全包因为职责单一能让每个智能体的注意力更集中输出质量更稳定。一个既要想创意又要写逻辑还要自我批评的智能体很容易顾此失彼。拆开之后每个环节的提示词可以高度定制评审智能体甚至可以专门喂一批差评样本来训练它的挑剔程度。这跟软件工程里单一职责原则是一个道理只不过这里职责的载体从函数变成了智能体。2.3 Product-Level 与 Experience-Oriented 的评判标准这两个词决定了整个系统的验收线画在哪里。Product-Level 意味着产出物要经得起真实玩家的检验不能有崩溃、卡死、逻辑死循环这类硬伤操作手感、反馈节奏、难度曲线这些软性指标也要在线。Experience-Oriented 则进一步把体验提到了最高优先级——功能齐全但不好玩在这个标准下就是不合格。我特别认同这个取向因为见过太多功能清单很漂亮、玩起来索然无味的 AI 生成游戏。把体验作为核心指标意味着评审环节不能只看有没有报错还要看玩家会不会想再玩一局。这就要求评审智能体具备一定的玩家共情能力能识别出这个关卡太简单了没挑战或者这个反馈延迟让人烦躁这类主观但关键的问题。2.4 Harness 框架的约束价值Harness 这个词是整个标题里最容易被忽略、但工程价值最高的部分。它是一套约束装置规定了智能体能做什么、不能做什么、按什么格式做、做完怎么被检验。没有 Harness智能体就是脱缰的野马输出格式五花八门评估无从下手递归也无从收敛。一个典型的 Harness 会包含几层约束接口约束规定智能体之间传递数据的格式比如游戏状态必须用固定的数据结构描述资源约束规定可用的素材、引擎能力边界防止智能体天马行空地要求不存在的东西评估约束规定体验评分的维度和打分方式让好不好玩这件事变得可量化、可比较。约束看似限制了自由实际上是把智能体的创造力引导到了能落地、能评估的轨道上这是从 Demo 走向产品的必经之路。3. 核心机制细节与实操要点3.1 递归循环的具体运转方式把递归循环拆开看它其实是一个标准的生成—评估—反馈—再生成闭环但每一环都有讲究。我用一个模拟项目的流程来说明假设目标是做一个简单的平台跳跃类小游戏。第一轮策划智能体根据初始需求产出一份机制描述比如玩家控制角色左右移动和跳跃收集金币避开尖刺到达终点。实现智能体据此产出一个可运行版本。评审智能体试玩后给出反馈跳跃手感偏重落地有延迟金币收集没有音效反馈第三段难度陡增不合理。调优智能体针对这三条分别修改物理参数、补充反馈、调整关卡布局。第二轮评审再看可能又发现新问题继续修。这个循环跑到体验评分达标为止。关键在于每一轮的反馈必须是具体、可执行的不能是感觉不太好这种模糊表述。所以评审智能体的提示词设计里我会强制它按问题定位 严重程度 修改建议三段式输出。这样调优智能体拿到反馈就能直接动手不用再去猜。3.2 体验评分体系怎么搭体验评分是整个系统的指挥棒它设计得好不好直接决定递归会往哪个方向收敛。我的经验是评分维度不要贪多四到六个核心维度足够每个维度用一到五分打分最后加权汇总。常见的维度包括操作响应性输入到反馈的延迟、手感、挑战平衡难度曲线是否合理、反馈丰富度视觉音效等即时反馈、目标清晰度玩家是否知道该干什么、重玩意愿玩完一局还想不想再来。这里有个实操心得权重要根据游戏类型调整。动作类游戏里操作响应性权重应该最高解谜类游戏里目标清晰度和挑战平衡更重要。一刀切的权重会让评审结果失真。另外评分最好由多个评审智能体独立打再取平均或去掉极值避免单个智能体的偏见主导整个递归方向。评分维度权重动作类权重解谜类打分要点操作响应性30%15%输入延迟、动画衔接、手感挑战平衡20%30%难度曲线、卡关点分布反馈丰富度20%15%视听反馈、状态提示目标清晰度15%25%引导、提示、目标可见性重玩意愿15%15%整体吸引力、变化性3.3 智能体之间的数据契约多个智能体协同最大的坑就是各说各话。策划智能体用自然语言描述机制实现智能体理解偏了产出的东西跟策划想的不是一回事评审再基于错误的东西挑毛病整个递归就在错误的方向上狂奔。解决办法是定义严格的数据契约也就是 Harness 里的接口约束。我的做法是让所有智能体之间的关键信息都用结构化格式传递。比如游戏机制用一份固定的 JSON schema 描述包含角色属性、关卡结构、胜负条件等字段评审反馈也用固定结构包含问题类型、位置、严重度、建议。自然语言只用在解释性内容上核心数据一律结构化。这样即使某个智能体的自然语言表达有歧义结构化数据也能兜底保证信息不失真。提示数据契约一旦定下来就不要在递归中途随意改。中途改契约会导致前面几轮的产出全部作废递归得从头再来非常浪费。契约的迭代应该放在项目级别而不是单次递归级别。3.4 素材与资源的边界管理智能体做游戏有个天然短板它没法凭空变出美术和音效资源。如果不加约束它可能会描述出一个拥有精细骨骼动画的巨龙角色这种根本无法实现的需求。Harness 的资源约束就是来解决这个问题的——提前把可用的素材库、引擎能力、性能预算列清楚让智能体在这个范围内做设计。实操上我会准备一份能力清单喂给策划智能体明确告诉它可用的是几何图形拼贴风格、可用音效是这二十个、单场景对象数量上限是五十个。策划智能体在这个约束下做设计产出的方案就一定是可落地的。这比让它先天马行空再被实现智能体打回要高效得多。资源约束不是限制创意而是让创意落在能实现的地基上。4. 完整实操流程与关键环节实现4.1 环境与框架的初始化动手之前先把 Harness 的骨架搭起来。这一步的核心是定义好三样东西智能体角色清单、数据契约、评估维度。我一般会用一个配置文件把这些都固化下来方便后续调整和复现。# harness_config.yaml 模拟配置 agents: - name: planner role: 将需求翻译为结构化游戏机制 output_schema: game_mechanism_schema - name: implementer role: 将机制转为可运行逻辑 output_schema: runnable_game_schema - name: reviewer role: 以玩家视角评估体验 output_schema: review_schema - name: tuner role: 根据评审意见做针对性修改 output_schema: runnable_game_schema recursion: max_rounds: 8 score_threshold: 4.0 stop_on_threshold: true evaluation: dimensions: [responsiveness, balance, feedback, clarity, replay] weights: [0.30, 0.20, 0.20, 0.15, 0.15]这份配置是整个递归的宪法所有智能体的行为都受它约束。max_rounds 和 score_threshold 就是前面说的双保险终止条件。weights 数组对应五个评分维度的权重顺序要和 dimensions 一一对应这个细节很容易搞错一旦错位整个评分就乱了。4.2 第一轮生成的实操记录初始化完成后跑第一轮。我拿一个模拟的收集类小游戏需求来演示。给策划智能体的输入是做一个玩家在场景中收集物品、限时完成的小游戏风格轻快。策划智能体输出的结构化机制大致是这样{ genre: collection, core_loop: 移动角色收集散落物品限时内集齐目标数量, player_abilities: [move_4dir, sprint], win_condition: collect_count target within time_limit, lose_condition: time_limit reached and collect_count target, difficulty_params: { target_count: 10, time_limit_sec: 60, item_spawn_density: medium } }这份机制描述就是实现智能体的输入。注意 difficulty_params 里的数值第一轮通常是智能体凭经验给的初始值大概率不准这正是后续递归要修的地方。实现智能体据此产出一个可运行版本然后交给评审智能体。4.3 评审与调优的迭代过程评审智能体试玩后按三段式输出反馈。第一轮它可能给出这样的结果问题定位严重程度修改建议冲刺无冷却可无限加速高增加冲刺冷却或体力条物品生成过于集中中提高生成点分散度时间耗尽无明确提示中增加倒计时视觉警示收集反馈仅有数字变化低补充收集音效与粒子效果调优智能体拿到这张表逐条处理。高严重度的问题优先修低严重度的可以放到后面轮次。这里有个经验不要指望一轮修完所有问题因为修改本身可能引入新问题。比如给冲刺加了冷却可能导致某些关卡变得无法通过这就是下一轮评审要抓的。递归的意义就在于让这些连锁反应在循环里被逐步消化。4.4 收敛判断与产出固化递归跑到什么时候停两个信号一是加权体验评分达到阈值比如 4.0/5.0二是达到最大轮数。实测下来一个简单小游戏通常三到五轮就能收敛复杂一点的机制可能要六到八轮。如果跑到最大轮数还没达标说明要么初始需求太复杂要么评分标准定得太苛刻需要回头调整配置而不是硬跑。收敛后把最终的可运行版本、完整的迭代日志、每轮的评分变化都固化下来。迭代日志特别有价值它能告诉你这个游戏是怎么一步步变好的哪些修改真正提升了体验哪些是无效折腾。我习惯把每轮的评分画成一条曲线看着它从 2.8 爬到 4.2那种感觉比单纯拿到一个成品更有成就感因为你知道每一步是怎么走过来的。注意收敛不等于完美。达到阈值就停不要追求满分。追求满分会让递归陷入无休止的微调边际收益极低。产品级的标准是足够好不是无可挑剔。5. 常见问题与排查技巧实录5.1 递归不收敛怎么办这是最常见的问题表现为评分在某个区间反复横跳就是上不去。排查思路分三层。第一层看评分标准是不是自相矛盾比如挑战平衡要求难度高重玩意愿又因为太难而降低两个维度打架智能体怎么改都顾此失彼。第二层看修改建议是不是互相冲突评审智能体这轮说加快节奏下轮说放慢节奏说明评审标准不稳定。第三层看是不是卡在了某个硬约束上比如资源清单里没有合适的音效导致反馈丰富度永远上不去。对应的解决办法评分维度冲突就调整权重或合并维度评审不稳定就固定评审智能体的随机性、增加评审样本数取平均硬约束卡死就回头扩充资源清单。我踩过最深的坑就是没意识到评分维度会打架白白跑了十几轮才发现问题出在标准本身。5.2 智能体输出格式跑偏结构化数据契约虽然能兜底但智能体偶尔还是会输出不符合 schema 的内容比如该填数字的地方填了文字该用数组的地方用了对象。这会导致下游智能体解析失败整个递归中断。排查时先看是哪一环出的问题然后检查那一环的提示词里 schema 描述是否足够清晰。我的经验是schema 描述里一定要给正例和反例。光说这里填数字不够要给出正确60错误六十秒这样的对照。另外在解析环节加一层校验和自动修复遇到轻微格式问题比如数字被引号包住自动纠正遇到严重问题才中断并报错。这层容错能大幅提升递归的稳定性。5.3 体验评分与实际感受脱节有时候评分明明很高但你自己试玩一下觉得也就那样。这说明评分体系没有真正捕捉到体验的关键。常见原因是评分维度太工程化只关注了可量化的指标忽略了那些难以量化但很重要的东西比如惊喜感节奏感情绪起伏。补救办法是引入人工抽检环节每隔几轮由真人试玩一次把主观感受反馈给系统作为评分体系的校准信号。也可以让评审智能体在打分之外额外写一段玩家日记用第一人称描述玩的过程和感受这段文字往往能暴露出评分数字掩盖的问题。5.4 常见问题速查表问题现象可能原因排查方向解决手段评分反复横跳不收敛评分维度冲突检查维度间是否互相矛盾调整权重或合并维度递归中途中断输出格式不符 schema定位出错环节补充正反例、加校验层评分高但体验一般评分维度太工程化对比人工试玩感受引入人工抽检校准修改引入新问题修改缺乏全局视角检查调优是否只看局部增加全局回归检查迭代多轮无提升卡在硬约束上检查资源清单边界扩充可用资源5.5 几个独家避坑技巧第一个技巧给递归设一个冷却期。连续多轮修改容易让系统陷入局部最优改来改去都在小圈子里打转。我的做法是每跑三轮强制让调优智能体做一次大改跳出当前方案重新审视往往能发现之前忽略的结构性问题。第二个技巧保留每一轮的快照。不要只保留最新版本每一轮的产出都存下来。有时候跑到第五轮发现还不如第三轮这时候能直接回滚不用从头再来。快照还能帮你分析哪一轮的改动贡献最大为后续项目积累经验。第三个技巧评审智能体的提示词要定期换血。同一个评审提示词用久了它的挑剔点会固化总是盯着同样几类问题。定期调整它的关注重点比如这轮重点看手感下轮重点看难度能让评审更全面。6. 这个框架还能怎么扩展跑通基础递归之后这个 Harness 的扩展空间其实很大。我试过几个方向效果不错。一个是多游戏类型模板把平台跳跃、收集、解谜等不同类型的最佳实践固化成模板策划智能体基于模板起步能少走很多弯路。另一个是玩家画像注入让评审智能体模拟不同类型的玩家新手、硬核、休闲从多个视角评估体验产出的游戏受众覆盖面会更广。还有一个我觉得很有潜力的方向是跨轮次的知识沉淀。把每个项目里哪类修改提升了哪类评分的经验积累下来形成一份经验库下一个项目启动时直接调用。这样递归就不只是单个项目内的自我改进而是跨项目的持续进化。这个思路跟标题里的 Recursive 其实是一脉相承的——递归不只发生在一次创作内部也发生在创作与创作之间。我个人在实际操作中的体会是这套框架最值钱的地方不是它能自动生成游戏而是它把如何判断一个游戏好不好玩这件事给结构化了。哪怕你最后不用它做游戏这套生成—评估—反馈—迭代的闭环思路拿去做任何需要反复打磨的产品都适用。踩过几次坑之后我越来越确信AI 做产品的瓶颈从来不在生成能力而在评估能力——能不能准确地知道自己做的东西差在哪才是决定最终质量的关键。这个 Harness 的价值恰恰就在于它把评估这件事认认真真地工程化了。
阅读完成 · 觉得有帮助？
