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 生成 B，B 生成 C，C 又生成 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 个核心指标，每个指标都要有明确的计算方式和目标区间。

下面这张表是我在多个项目里沉淀下来的一套指标，可以直接参考：

这几个指标里，挑战感和成就感是最核心的，其他指标可以看作它们的调节器。实测下来，只要这两个指标落在理想区间，玩家的整体满意度就不会差。新鲜感和留存意愿是长期指标，用来判断系统是不是在持续产出有价值的内容。

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，同样的智能体就能稳定产出可用的内容。这个道理，其实和工业生产里的"标准化"是一回事——标准化不是扼杀个性，而是让个性能够在可控的前提下被批量复制。

如果让我给正在做类似项目的朋友一个建议，我会说：先把评估体系建起来，再去做生成。很多人一上来就想着怎么让智能体生成更花哨的内容，结果生成出来一堆东西，却不知道怎么判断好坏，最后只能靠人肉一个个试。正确的顺序是反过来的——先定义清楚什么叫"好"，再让智能体朝着这个方向去生成。评估体系是地基，生成能力是楼，地基没打好，楼盖得越高越危险。

另外一个小技巧：把每一次生成决策都记录下来，包括当时的上下文和结果。这些日志在系统运行初期看起来没什么用，但当你需要复盘"为什么最近生成质量下降了"的时候，它们就是唯一的线索。我吃过没有日志的亏，后来补上之后，排查问题的效率至少提升了一倍。