1. 从游戏机到游戏造物主这个标题到底在说什么第一次看到Recursive Game Creator这个说法我脑子里蹦出来的不是某个具体产品而是一种很朴素的冲动能不能让程序自己生成游戏而且生成出来的游戏还能继续生成游戏这听起来像是套娃但仔细琢磨标题里的几个关键词——Agentic、Product-Level、Experience-Oriented、Harness——会发现它其实描述的是一个相当具体的工程目标而不是一句空泛的口号。先把这几个词拆开看。Agentic意味着系统里有自主决策的智能体在驱动不是那种点一下按钮跑一次脚本的死板流程而是智能体会根据当前状态判断下一步该做什么。Product-Level说明这东西不是实验室里的玩具 Demo它得能扛住真实用户的使用有完整的交互闭环、有稳定的输出质量。Experience-Oriented把重心放在了体验上也就是说生成出来的游戏得好玩、能玩、有反馈而不是一堆能跑但没人愿意碰的代码。Harness这个词在工程语境里通常指脚手架或约束框架它负责把智能体的能力框在一个可控、可复现、可迭代的范围里。把这四个词串起来这个项目的本质就清楚了它是一套让智能体递归地创造游戏、并且保证创造出来的东西达到产品级体验的约束与驱动框架。递归体现在哪里我理解有两层。第一层是生成过程的递归——智能体生成一个游戏玩这个游戏产生的反馈又成为下一轮生成的输入。第二层是结构上的递归——游戏本身可能包含可以继续生成子关卡、子规则的机制形成一种自相似的结构。为什么这个方向值得认真对待因为过去几年我们见到的AI 生成游戏大多停留在两个极端。一个极端是纯技术演示比如用大模型吐出一段能跑的贪吃蛇代码跑起来就完事没人关心它好不好玩。另一个极端是纯内容填充比如给现成的游戏自动生成贴图、关卡布局但游戏的核心机制还是人写的。这个标题指向的是第三条路让智能体从机制层面参与创造同时用一套工程化的框架保证结果不是垃圾。这中间的难度恰恰是Product-Level和Harness这两个词在扛的。我打算按这个思路往下拆先讲清楚递归生成这件事在架构上到底怎么落地再讲智能体在这个循环里扮演什么角色、它的决策边界在哪然后是产品级体验这个目标怎么被量化成可执行的约束接着是 Harness 作为约束框架的具体设计最后聊聊这类系统在实测中最容易翻车的地方。每一块我都会尽量给出可复现的思路和参数级的细节而不是停在概念层面。2. 递归生成架构循环在哪里闭合状态在哪里沉淀2.1 递归不等于无限套娃关键是找到收敛点很多人一听递归生成就担心死循环——A 生成 BB 生成 CC 又生成 A最后系统崩掉。这个担心是对的但解法不是禁止递归而是给递归设计一个收敛条件。我在设计这类系统时习惯把递归分成纵向递归和横向递归两种它们的收敛逻辑完全不同。纵向递归指的是同一局游戏内的层级嵌套。比如智能体生成一个主关卡主关卡里有一个传送门机制进入传送门后触发一次新的生成产生一个子关卡。子关卡还可以再有传送门。这种递归的收敛靠的是深度上限加资源预算。我一般会设两个硬约束最大嵌套深度max_depth实测 3 到 4 层是比较舒服的再深玩家会迷失以及每一层的生成预算budget_per_level比如允许调用多少次模型、生成多少个实体。当深度触顶或者预算耗尽传送门就退化成普通的出口递归自然终止。横向递归指的是跨局游戏的迭代。玩家玩完一局系统收集这局的体验数据然后生成下一局。这种递归没有天然的终止点所以收敛靠的是质量阈值加多样性衰减。具体说如果连续 N 局的质量评分都没有提升或者生成结果的多样性指标掉到某个阈值以下就停止迭代回退到历史最优版本。这个 N 我通常设成 5多样性用生成结果的机制组合熵来衡量熵值低于 0.3 就认为开始重复了。提示递归的收敛条件一定要在系统设计的第一天就定下来而不是等跑出问题再补。我见过太多项目因为没定收敛点跑着跑着要么卡死要么生成出一堆高度雷同的东西。2.2 状态沉淀递归系统里最容易被忽视的一环递归生成要能持续变好靠的不是每一轮从零开始而是把上一轮的经验沉淀成可复用的状态。这里的状态分三类我建议分开存储、分开管理混在一起会非常难调试。第一类是结构状态记录已经生成过的游戏机制、关卡拓扑、实体关系。它的作用是避免重复生成相同的东西。存储上用一个带版本号的图结构就行节点是机制或实体边是它们之间的依赖关系。每次生成新内容前先在这个图里做一次相似度查询相似度超过 0.85 的就直接复用或做变异而不是重新生成。第二类是体验状态记录玩家在每一局里的行为数据——停留时长、失败次数、主动探索的比例、放弃的节点。这些数据是Experience-Oriented这个目标的燃料。我习惯把它压缩成一组特征向量每个维度对应一个体验指标比如挑战感探索欲成就感。生成下一局时智能体的目标就是让这些特征向量往理想区间靠。第三类是生成状态记录智能体每一轮的决策轨迹——它为什么选了 A 机制而不是 B当时的上下文是什么。这类状态主要用于调试和复盘。实测下来没有这层记录一旦生成质量下滑你根本不知道是哪一步决策出了问题。三类状态的更新频率也不一样。结构状态是低频的一局结束更新一次体验状态是中频的玩家每完成一个关键节点就更新生成状态是高频的智能体每做一次决策就追加一条。分开管理之后系统的可观测性会好很多。2.3 一个可落地的最小递归循环把上面这些拼起来一个最小可用的递归循环大概长这样def recursive_generate(seed, depth, budget, state): if depth MAX_DEPTH or budget 0: return fallback_content(seed) # 智能体基于当前状态和种子做决策 plan agent.plan(seed, state.structure, state.experience) # 生成这一层的内容 content generate_from_plan(plan, budget) # 如果内容里包含可递归的锚点继续往下生成 for anchor in content.recursive_anchors: sub_budget budget * SPLIT_RATIO # 预算按比例分配 sub_content recursive_generate( anchor.seed, depth 1, sub_budget, state ) content.attach(anchor, sub_content) # 沉淀状态 state.structure.update(content) return content这段伪代码里有几个参数值得说。MAX_DEPTH我前面说了设 3 到 4。SPLIT_RATIO是预算分配比例我一般设 0.5也就是父层和子层各拿一半这样能保证父层内容不会因为子层生成而被饿死。fallback_content是兜底逻辑当递归终止时返回一个预置的简单内容保证玩家不会遇到空白。实测下来这个循环最容易出问题的地方是预算分配。如果SPLIT_RATIO设得太高子层内容会很单薄设得太低父层又不够丰富。0.5 是个比较稳的起点具体项目可以根据内容类型微调。另外recursive_anchors的识别也很关键不是所有内容都适合作为递归锚点我一般只把那些天然具有封闭性的结构比如房间、关卡、独立小游戏作为锚点。3. 智能体在循环里的角色它到底该决策什么不该决策什么3.1 智能体的决策边界把创意和工程分开Agentic 这个词很容易被滥用好像只要系统里有个大模型在调用就算智能体了。但在递归游戏生成这个场景里智能体的价值不在于它能写代码而在于它能在约束下做取舍。这就引出一个关键问题哪些决策交给智能体哪些必须由框架硬编码我的经验是涉及好不好玩的判断交给智能体涉及能不能跑的判断交给框架。具体来说智能体负责决定这一局的核心机制是什么、难度曲线怎么走、奖励放在哪里、视觉风格偏向哪种。框架负责决定生成的内容是否符合语法、资源消耗是否超预算、递归深度是否触顶、输出是否满足产品级的最低质量标准。这个边界划清楚之后智能体的 prompt 设计就有了明确方向。它不需要知道底层怎么渲染、怎么存储它只需要在一个机制空间里做选择。我通常会给智能体一个机制清单里面列出所有可用的基础机制移动、碰撞、收集、计时、状态切换等以及它们的组合规则。智能体的任务就是从这个清单里挑出合适的组合并给出参数。注意千万不要让智能体直接生成可执行代码然后跑起来。这条路看起来酷实际上不可控——生成的代码可能有安全漏洞、可能性能极差、可能根本跑不通。让智能体在受限的机制空间里做组合框架负责把组合翻译成可执行内容这才是产品级系统该有的样子。3.2 决策的粒度太粗会失控太细会僵化智能体决策的粒度是个需要反复调的参数。粒度太粗比如让智能体一次性决定整局游戏的所有内容它会顾此失彼生成的东西往往头重脚轻。粒度太细比如每一步移动都问一次智能体延迟高得没法玩而且智能体也缺乏全局视野。我实测下来比较舒服的粒度是**关卡级决策加事件级微调**。关卡级决策就是智能体一次性规划一个关卡的核心机制、难度、奖励分布这部分调用频率低可以慢一点。事件级微调是在玩家触发特定事件时比如连续失败三次、或者主动探索了隐藏区域智能体做一次小范围的调整比如降低一点难度、或者投放一个额外奖励。这部分调用频率高但每次决策的范围很小响应快。这个粒度设计还有个好处它天然对应了递归结构。关卡级决策对应纵向递归的一层事件级微调对应横向递归的一次迭代。两者用同一套智能体但 prompt 和上下文不同实现上可以复用大部分逻辑。3.3 智能体的记忆短期上下文和长期偏好要分开智能体要做出一致的决策记忆管理是绕不开的。我一般把记忆分成两层。短期记忆是当前这一局的上下文包括玩家刚做了什么、当前关卡的状态、最近几次决策的结果。这部分用滑动窗口管理窗口大小我设成最近 10 次决策太老的直接丢弃。长期记忆是跨局的偏好比如这个玩家整体上喜欢高难度还是低难度、喜欢探索还是喜欢速通。这部分用一组累积的统计量表示每局结束更新一次。两层记忆的读取时机也不同。短期记忆在每次决策时都要读长期记忆只在关卡级决策时读。这样设计的好处是事件级微调不会被长期偏好过度干扰保持对当前局势的敏感而关卡级决策又能利用长期偏好让整体体验有连贯性。实测中我发现一个坑长期记忆的更新不能太激进。如果一局的数据就大幅改变长期偏好玩家会感觉游戏风格飘忽不定。我一般用指数移动平均来更新平滑系数设 0.2 左右也就是新数据只占 20% 的权重。这样既能让偏好慢慢适应玩家又不会因为单局异常数据而剧烈波动。4. 产品级体验怎么落地把玄学的好玩变成可测的指标4.1 体验指标的选取少而准别贪多Experience-Oriented听起来很虚但落到工程上它必须变成一组可测量、可优化的指标。我见过一些项目列了二三十个体验指标结果每个都测不准最后哪个都没优化好。我的建议是控制在 5 到 7 个核心指标每个指标都要有明确的计算方式和目标区间。下面这张表是我在多个项目里沉淀下来的一套指标可以直接参考指标名计算方式理想区间说明挑战感失败次数 / 尝试次数0.3 - 0.5太低无聊太高挫败探索欲主动探索节点数 / 总节点数0.4 - 0.7反映内容吸引力成就感完成关键目标的平均耗时与预期时长偏差 20%太快没感觉太慢会烦节奏感高强度段与低强度段的交替频率每 2-3 分钟一次切换避免长时间单一强度新鲜感相邻两局机制组合的差异度 0.4防止重复感留存意愿主动重开的比例 0.5最直接的体验信号这几个指标里挑战感和成就感是最核心的其他指标可以看作它们的调节器。实测下来只要这两个指标落在理想区间玩家的整体满意度就不会差。新鲜感和留存意愿是长期指标用来判断系统是不是在持续产出有价值的内容。4.2 指标怎么驱动生成从测到调的闭环指标测出来只是第一步关键是让它反过来驱动生成。我的做法是给每个指标设一个目标区间和一个调节动作。当某个指标偏离区间时触发对应的调节动作而不是让智能体自由发挥。比如挑战感偏低失败率低于 0.3调节动作是提升难度——具体可以是增加敌人数量、缩短反应时间、减少补给。挑战感偏高失败率高于 0.5调节动作是降低难度——增加提示、放宽判定、提供额外生命。这些调节动作都是预定义的、参数化的智能体只负责选择用哪个动作、调多少幅度不负责发明新动作。这样做的好处是可控。如果让智能体自由决定怎么调难度它可能想出一个你完全没测试过的机制结果把游戏搞崩。预定义动作加智能体选择既保留了灵活性又保证了安全性。调节幅度也需要控制。我一般设一个单次调节上限比如难度参数每次最多变动 15%。这样即使连续触发调节也不会出现难度骤变。实测中玩家对渐进式调整的接受度远高于突变。4.3 体验数据的采集别打扰玩家也别漏掉关键信号体验数据的采集要平衡两件事数据的完整性和对玩家的干扰。我的原则是能隐式采集的绝不显式询问。玩家点了哪里、停留了多久、重试了几次这些都是隐式信号采集成本低、不打扰。只有在隐式信号不足以判断时才用轻量的显式反馈比如关卡结束后的一个表情选择而不是长篇问卷。隐式信号里我最看重三个首次操作延迟玩家进入新场景后多久做出第一个操作反映理解成本、放弃点分布玩家在哪些节点退出反映挫败点、重复行为模式玩家是否反复做同一件事反映内容枯竭。这三个信号采集成本极低但信息量很大。数据采集还有个容易被忽视的点采样率。不是所有数据都需要全量采集。高频操作比如移动可以采样低频关键事件比如通关、失败必须全量。我一般对高频数据做 1/10 采样对关键事件做全量记录。这样既控制了存储成本又不会漏掉重要信号。5. Harness 作为约束框架让智能体戴着镣铐跳舞5.1 Harness 的三层约束语法、语义、体验Harness 这个词直译是马具引申为约束和引导。在这个系统里它的作用就是给智能体的创造力套上三层约束从下到上分别是语法层、语义层、体验层。语法层是最底层的约束保证生成的内容在形式上合法。比如生成的关卡拓扑必须是一张连通图不能有孤立的节点生成的机制组合必须满足依赖关系不能出现用了某个道具但道具没定义这种情况。这一层的检查是纯机械的用规则引擎就能做不需要智能体参与。语义层保证生成的内容在逻辑上说得通。比如一个关卡的主题是冰雪那生成的机制和视觉元素就应该和冰雪相关不能突然冒出一个沙漠场景。这一层需要一定的语义理解我通常用一个轻量的分类器或者关键词匹配来做成本不高但效果明显。体验层是最上层的约束保证生成的内容符合前面说的体验指标。这一层的检查是异步的不需要在生成时实时完成而是在玩家实际游玩后根据数据反馈。如果体验指标偏离就触发下一轮的调节。三层约束的关系是逐层过滤语法层不过的直接丢弃语义层不过的打回重做体验层不过的进入调节队列。这样设计的好处是大部分问题在最底层就被拦住了不会浪费上层资源。5.2 约束的松紧度太紧没创意太松会失控约束的松紧度是 Harness 设计里最微妙的部分。约束太紧智能体只能在很小的空间里打转生成的东西千篇一律约束太松智能体容易跑偏生成出无法使用的内容。我的经验是分层设置松紧度。语法层要严几乎不留余地因为形式错误是硬伤。语义层可以适度放宽允许一定比例的意外组合因为有时候跨界的组合反而有惊喜。体验层要动态调整初期可以松一点让智能体多探索后期收紧把资源集中在已经被验证有效的方向上。具体参数上我一般设语法层通过率要求 100%不过的直接丢语义层通过率要求 80%允许 20% 的意外体验层用滑动窗口评估最近 20 局的指标均值落在区间内即可。这些数字不是绝对的但提供了一个可调的起点。提示约束松紧度一定要做成可配置的而不是硬编码。因为不同游戏类型、不同玩家群体对约束的容忍度完全不同。做成配置项之后调优会方便很多。5.3 约束失败时的降级策略再好的约束也会遇到失败的时候。关键是失败之后怎么办。我的原则是永远给玩家一个可用的结果哪怕这个结果不是最优的。降级策略分三级。一级降级是回退到上一个通过约束的版本玩家感知不到明显变化。二级降级是回退到预置的模板内容虽然不够个性化但保证能玩。三级降级是显示一个友好的提示引导玩家重新开始同时后台记录这次失败用于后续分析。三级降级里一级是常态二级是兜底三级是最后手段。实测中一级降级能覆盖 90% 以上的失败情况二级覆盖 9%三级几乎用不到。但三级必须存在因为它是系统可信度的最后一道防线。降级策略还要考虑恢复机制。降级之后系统应该在后台继续尝试生成一旦成功就无缝切换回来。这个恢复过程对玩家应该是透明的不能让他感觉到刚才卡了一下。6. 实测中最容易翻车的几个地方6.1 递归深度和生成质量的权衡前面说递归深度设 3 到 4 层但实际项目里这个数字需要根据内容类型反复调。我踩过的一个坑是盲目追求深度结果子层内容质量断崖式下跌。原因是预算被层层瓜分到了第三、第四层剩下的预算已经不足以生成有质量的内容了。后来我改成了动态深度不是固定生成到第几层而是根据当前层的生成质量决定要不要继续往下。如果当前层的内容质量评分高于阈值就继续递归低于阈值就停止把剩余预算留给当前层的丰富度。这样虽然深度不固定但整体质量更稳定。质量评分怎么算我用的是内容完整度加体验预测分。内容完整度看这一层是否包含了必要的元素目标、反馈、挑战体验预测分用一个轻量模型根据历史数据预测。两个分数加权求和权重我设成 0.6 和 0.4。6.2 智能体的创意疲劳智能体跑久了会出现一种现象生成的东西越来越像。这不是模型坏了而是上下文里积累的历史内容太多把智能体的思路带偏了。我称之为创意疲劳。解法有两个。一个是定期清理上下文不要让历史内容无限累积。我一般每 20 局清一次短期记忆只保留长期偏好。另一个是主动注入随机性在智能体的决策里加入一定比例的随机探索比如 10% 的概率选择一个平时不常选的机制。这个比例不能太高否则体验会不稳定也不能太低否则起不到打破惯性的作用。实测下来这两个方法结合使用效果最好。清理上下文解决被历史带偏的问题随机注入解决路径依赖的问题。两者配合能让系统在长时间运行后依然保持一定的多样性。6.3 体验指标的指标作弊这是最隐蔽的坑。当系统以某个指标为优化目标时它可能会找到一种表面上满足指标、实际上体验很差的方式。比如为了提升探索欲指标系统生成大量无意义的可探索节点玩家确实点了很多但每个节点都没什么内容探索变成了机械点击。防作弊的办法是给每个指标配一个反向指标。探索欲的反向指标是探索收益也就是每次探索获得的实际价值。如果探索欲高但探索收益低说明是在刷指标需要干预。类似的挑战感的反向指标是挫败感连续失败后的退出率成就感的反向指标是重复感。反向指标不需要很多每个核心指标配一个就够。关键是在评估时同时看正向和反向只有两者都健康才算真正达标。这个思路和推荐系统里防点击诱饵的逻辑是一样的。6.4 冷启动阶段的数据饥渴系统刚上线时没有玩家数据体验指标无从计算智能体也没有历史可以参考。这个阶段最容易生成出平庸的内容。我的做法是用预置的种子内容度过冷启动。具体说准备 10 到 20 个手工设计的种子关卡覆盖不同的机制组合和难度区间。冷启动阶段系统主要基于这些种子做变异而不是从零生成。同时采集玩家在这些种子上的行为数据快速积累第一批体验数据。等数据量够了我一般设 200 局为门槛再逐步切换到完全由智能体驱动的生成。种子内容的设计也有讲究。它们不需要多精美但必须覆盖足够宽的机制空间这样变异出来的内容才不会局限在某个角落。我一般会确保种子内容在挑战感、探索欲这两个核心指标上覆盖从低到高的完整区间。7. 我对这类系统的一点个人判断做了一段时间这类递归生成系统我最大的体会是难点从来不在生成而在约束和评估。生成这件事现在的模型能力已经足够强给它一个机制清单它能组合出成千上万种玩法。但怎么保证这些玩法里有一部分是真正好玩的怎么在生成过程中就把明显不行的那部分过滤掉怎么在玩家玩过之后准确地知道哪里好哪里不好——这些才是决定系统成败的地方。Harness 的价值就在这里。它不是一个限制创造力的枷锁而是一个让创造力能够被规模化利用的框架。没有 Harness智能体生成的东西再多也只是随机噪声有了 Harness同样的智能体就能稳定产出可用的内容。这个道理其实和工业生产里的标准化是一回事——标准化不是扼杀个性而是让个性能够在可控的前提下被批量复制。如果让我给正在做类似项目的朋友一个建议我会说先把评估体系建起来再去做生成。很多人一上来就想着怎么让智能体生成更花哨的内容结果生成出来一堆东西却不知道怎么判断好坏最后只能靠人肉一个个试。正确的顺序是反过来的——先定义清楚什么叫好再让智能体朝着这个方向去生成。评估体系是地基生成能力是楼地基没打好楼盖得越高越危险。另外一个小技巧把每一次生成决策都记录下来包括当时的上下文和结果。这些日志在系统运行初期看起来没什么用但当你需要复盘为什么最近生成质量下降了的时候它们就是唯一的线索。我吃过没有日志的亏后来补上之后排查问题的效率至少提升了一倍。