从三维生成到游戏世界自生长的智能体实践

一、真正值得关注的变化：从生成答案到操作环境

让模型生成一段场景描述，与让模型真正创建一个可编辑、可运行的三维世界，是两类不同的问题。

前者主要考验语言组织与知识关联能力；后者则要求系统理解目标、规划步骤、调用工具、观察结果，并在发现错误后继续修正。例如，“创建一座带庭院的住宅”看似只有一句话，实际至少包含建筑布局、空间尺度、几何建模、材质配置、光照设置和结果检查等多个环节。

如果还要求人物能够进入住宅、沿道路行走，并与室内物品交互，就必须进一步处理碰撞体、导航区域、交互逻辑和运行时状态。

因此，技术重点并不是模型一次生成了多少细节，而是它是否具备一套可靠的“规划—执行—观察—验证—修复”闭环。

对于各类演示中出现的快速建模、整屋重建和城市生成，也应保持工程判断：视觉效果能够说明部分生成能力，但不能直接证明资产拓扑合理、空间比例准确、交互逻辑完整，更不能据此推断生产环境中的稳定性。

二、先明确三种不同的技术任务

三维内容生成、图像辅助重建与游戏世界自生长经常被放在一起讨论，但它们的目标和验收标准并不相同。

1. 三维内容生成：创造满足约束的新场景

这类任务从文字、草图或结构化要求出发，生成原本不存在的空间与资产。

例如，开发者要求“创建一个围绕广场分布的小型街区”，系统需要确定道路走向、建筑分布、公共空间和装饰物位置。它的核心目标是合理性与可用性，而不是还原某个真实地点。

验收重点包括建筑是否穿插、道路是否连通、比例是否协调、资产是否可以继续编辑，以及场景能否在目标设备上稳定运行。

2. 图像辅助重建：估计现实空间的结构

这类任务以照片或视频为输入，尝试恢复场景中的几何关系、材质外观与相机位置。

它的困难在于输入通常不完整。照片看不到的区域、被家具遮挡的墙面，以及缺少参照物的空间尺度，都存在不确定性。

因此，系统应区分“从输入中观察到的内容”“依据约束推断的内容”和“为补齐场景而生成的内容”。如果把推测部分当成测量结果，就可能误导后续设计、展示或施工决策。

3. 游戏世界自生长：维护持续变化的运行状态

游戏世界自生长并不等于不断往地图里添加建筑。

一个能够持续演化的世界，需要在玩家行为、资源变化和任务事件的影响下，按照规则改变自身状态。例如，玩家修复交通设施后，商队开始进入聚落；物资增加后，集市扩张；新的商业活动又触发角色关系和任务变化。

这里的核心是因果一致性：每一次变化都应有触发条件、状态依据与可追踪的执行结果，而不是模型临时编写一段缺乏系统支撑的剧情。

三、构建工具闭环：让模型提出计划，让系统约束执行

一个实用架构可以划分为目标解析、任务规划、工具执行、环境观察、质量验证和状态存储六个部分。

1. 将自然语言目标转成可检查的约束

“做得精致一些”难以验收，“主入口连接公共道路，所有可进入房间均有可达路径”则可以检查。

开发者应尽量把需求分成四类：

• 内容约束：需要哪些建筑、物体、角色和交互。
• 空间约束：尺寸、距离、朝向、连接关系与禁止占用区域。
• 运行约束：目标设备、资源预算、加载方式和响应要求。
• 交付约束：是否需要可编辑资产、预览图、说明文件和版本记录。

模型负责帮助补全需求，但不能擅自把未明确的假设当成已确认条件。对影响较大的设计选择，应记录假设，必要时交由用户确认。

2. 把复杂任务拆成短链路

直接要求系统“一次生成完整城市”，容易导致错误在长任务中累积。更稳妥的顺序是：

先生成地形与道路骨架，再确定地块用途，随后放置建筑体块，最后补充门窗、材质、植被和室内物件。

每一步都形成中间产物，并通过检查后再继续。这样即使局部失败，也不必重做整个场景。

任务拆分还应考虑依赖关系。道路尚未确定，就不宜精细生成临街店铺入口；建筑尺寸仍在变化，就不宜提前固定室内家具位置。

3. 为工具提供明确的输入输出契约

模型不应直接获得无限制的系统操作权限。工具适配层应限定可执行操作，并验证对象标识、数值范围、资源路径与输出类型。

例如，一项“创建建筑体块”的操作，应明确输入位置、尺寸和用途，输出新对象标识、实际边界范围以及执行状态。操作失败时，应返回可解释的错误信息，而不是仅返回空结果。

这里描述的是通用设计原则，并非某个现成产品的接口。具体实现可以不同，但必须让每一步执行都有依据、有反馈、可追踪。

四、三维场景生成：先保证结构成立，再追求视觉丰富

三维生成最容易出现的误区，是把画面细节数量当成场景质量。

一间摆满家具的房间，可能存在门打不开、桌椅互相穿插、楼梯无法通行等问题。它适合截图，却未必适合交互。

1. 先搭建灰盒场景

灰盒阶段只保留基础几何形状，用来验证空间组织、尺度与通行关系。

这一阶段应重点检查：

• 建筑是否落在合理区域，是否与地形异常相交。
• 道路、入口、楼梯与主要功能空间是否连通。
• 玩家或角色的通行空间是否足够。
• 相机是否容易被遮挡或卡入物体。
• 关键交互点是否能够到达。

只有这些条件成立，才值得投入更精细的视觉生成。

2. 分离视觉资产与交互资产

渲染模型、碰撞体和导航表示服务于不同目标，不应默认使用同一份复杂几何数据。

视觉模型关注外观；碰撞体关注稳定、简洁的物理接触；导航表示关注角色可以经过哪些区域。三者适当分离，通常更便于优化与调试。

同时，资产应包含清晰的单位、轴向、原点和命名约定。否则，即使单个物体看起来正确，组合后也可能出现比例不一致、旋转异常或落点错误。

3. 把性能预算纳入生成过程

如果只在最后检查性能，系统可能已经生成大量需要返工的内容。

更合理的做法，是在生成阶段就约束几何复杂度、材质数量、纹理占用、动态对象数量和可见范围，并根据实测结果决定是否使用细节层级、实例复用、分区加载或资源压缩。

这些策略是否有效，取决于具体场景和目标设备，不能脱离测试直接承诺固定性能提升。

五、图像辅助重建：必须管理看不见的部分

根据多张照片重建住宅或街区，是很有价值的应用方向，但需要明确“视觉近似”与“准确测绘”的边界。

1. 输入质量决定可恢复信息的上限

照片之间是否有足够重叠、拍摄位置是否多样、画面是否模糊，以及场景中是否存在大面积玻璃或重复纹理，都会影响重建。

缺少真实尺寸参照时，系统通常难以仅凭普通图片确定绝对尺度。此时应引入已知尺寸或人工确认，而不是把估计值包装成精确结果。

2. 为推测结果保留不确定性标记

对于缺少观察证据的区域，可以生成合理补全，但需要保留来源说明。

例如，客厅正面墙来自照片观察，背面墙体布局来自空间约束推断，某件装饰物则是为了完整展示而生成。三者在交付数据中应有区别。

如果没有经过专门标定和误差验证，重建结果不应直接作为施工、测绘或安全决策依据。

3. 展示视频不能替代模型验收

一段流畅的镜头运动可能避开模型缺陷，因此应增加固定视角检查、局部近景检查、几何交叉检查和尺寸核验。

展示效果用于传达观感，结构化检查用于证明可用性，两者缺一不可。

六、实现世界自生长：用受控状态变化替代自由改写

持续演化的游戏世界，需要一个明确的权威状态来源。模型可以理解事件、提出变化方案，但不宜直接自由改写全部世界数据。

1. 让世界状态结构化

建筑、角色、资源、任务和区域权限，都应有稳定标识和明确属性。

角色“搬到新家”不只是生成一句描述，还意味着居住关系改变、旧地点占用释放、新地点占用更新，以及相关任务条件重新计算。

如果这些变化仅存在于对话上下文中，随着运行时间增长，系统容易出现角色重复、物品丢失和任务矛盾。

2. 把生成结果作为候选变更提交

一个可靠的处理流程是：

世界事件发生 → 读取相关状态 → 模型提出候选变更 → 规则检查与冲突检测 → 试运行 → 正式提交 → 记录版本。

假设某聚落准备扩建市场，系统应先检查资金是否充足、地块是否可用、道路是否连接，以及区域内是否存在受保护对象。全部通过后，才能创建建筑并更新相关状态。

若中途失败，应撤销本次未完成变更，而不是留下“资源已扣除、建筑未生成”的半完成状态。

3. 限制生成范围与频率

并非每个变化都需要调用模型。资源计数、昼夜交替和常规移动，更适合由确定性规则处理；剧情分支、任务草案和新区域设计，才更适合使用生成能力。

持续扩张还需要容量边界，包括活跃区域数量、任务数量、资产存储和后台计算预算。超出边界时，可以冻结远处区域、降低更新频率，或将细节生成推迟到玩家接近时。

这不是削弱世界的丰富度，而是避免系统因无约束增长而失控。

七、建立可验证的质量体系

评价这类系统，不能只看一张截图，也不能只记录首次成功案例。

建议从五个维度建立测试：

1. 任务完成度：需求是否真正满足，关键对象和交互是否齐全。
2. 结构正确性：几何、连接关系、碰撞和状态约束是否成立。
3. 运行稳定性：长时间运行后是否出现资源泄漏、状态漂移或重复执行。
4. 交互可用性：玩家能否理解并完成主要操作，失败反馈是否清楚。
5. 成本可控性：工具调用、渲染、存储和人工修正的消耗是否在预算内。

测试应保留输入条件、资产版本、工具版本、执行轨迹和人工修改记录。对包含随机生成的流程，还应记录相关随机性配置，以支持问题复现。

同时，要分别统计完整自动完成、人工介入后完成和最终失败的情况，避免用少数成功样例代替整体可靠性。

八、安全与治理是执行能力的前提

当模型能够读取文件、运行脚本和修改资产时，安全问题会从“回答是否准确”扩展为“操作是否可控”。

首先，应采用最小权限原则，将执行范围限制在专用工作区，对覆盖文件、删除资产和外部发布等高风险操作增加确认。

其次，网页文字、图片说明和资产备注都应被视为外部数据，而非可信指令。它们不能改变系统规则，也不能要求工具绕过权限检查。

再次，需要记录资产来源、授权范围和生成过程。可访问的素材不等于可以任意复制、再分发或商业使用；输入涉及真实住宅、个人信息或内部资料时，还应实施脱敏、访问控制和必要的保留期限管理。

最后，长任务必须设置停止条件。重复失败、预算不足或关键校验不通过时，应暂停并请求人工介入，而不是无限重试。

九、落地路线：先做一个能验收的最小闭环

对大多数团队而言，合理起点不是自动生成整座城市，而是完成一个范围清楚的小场景。

第一阶段，选择单房间或小型街区，验证需求解析、工具调用、结果检查与人工修正。

第二阶段，补齐交互、状态存储、版本管理和失败回滚，使生成内容真正可运行、可维护。

第三阶段，再加入事件驱动的局部扩张，并通过长时间测试评估状态一致性与资源消耗。

从三维生成走向游戏世界自生长，真正的门槛不是生成更多物体，而是让每次变化都遵守约束、保持一致、接受验证，并能够在出错后恢复。只有把生成能力纳入可靠的工程闭环，视觉上的惊艳才可能转化为持续可用的生产能力。