该项目的论文编号为 arXiv:2608.05248，8 月 5 日提交，属于计算机科学人工智能分类，作者为 Guo Chunchao、Li Jinpeng、Li Yang、Huang Zilong。同一天建立的 GitHub 仓库 Tencent-Hunyuan/Hunyuan3D-WorldClaw 于 8 月 7 日随项目页与论文一并公开，目前已累积 501 个星标和 26 次分叉，并在 Hacker News 上被推上讨论列表。

由粗到精，把世界搭建拆成流水线

WorldClaw 被定义为一个完全由智能体驱动的、由粗到精的开放世界三维场景生成框架。第一步由规划智能体负责，把一段文字提示翻译成结构化规格，明确区域划分、地形、资产、材质以及彼此的空间关系。

拿到规格之后，系统先搭全局地形底座，输入包括语义布局图、可复用资产、生成式或程序化材质，以及一张区域感知的高度场。对那些需要细节的重点区域，框架会在地形条件约束下生成区域构图，把其中的物体重建为可编辑的带贴图网格，再还原它们在地形上的准确摆放。最后由基于渲染的智能体做二次精修，逐项调整地形、物体、外观表现以及物体与地面的接触关系。

论文特别强调，全局地形与区域物体在最终成果里始终是各自独立、可单独管理的带贴图网格。对游戏和影视流程而言，这一点比画面观感更关键——能拆开改的场景才有工业价值。

底座模型清单与运行环境

WorldClaw 本身不是一个从头训练的大模型，而是一套调度体系，其能力边界由所调用的基础模型决定。论文的实现细节一节列出了完整清单：

• 底层智能体模型为 Claude Opus 4.8，团队为其开发了一组任务专用技能，用于接入外部基础模型和三维工具链
• 语义布局图与区域物体构图由 GPT-Image-2 生成
• 二维实例分割采用文本引导的 SAM3，除全图推理外还叠加重叠滑窗推理，以提升不同尺度物体的召回率
• 三维相关环节由 SAM3D 与 Hunyuan3D 承担，大物体输出 2048×2048 的 PBR 贴图，小物体为 1024×1024
• 全部实验运行在一台配备 4 张 NVIDIA H20 显卡的服务器上，地形生成、物体生成与摆放、场景精修与图像渲染均在 Blender 5.1.1 中完成
• 地形精修智能体由 BlenderMCP 驱动，从预设视角重新渲染场景，检查几何、材质、散布结果与渲染配置，再按检测到的问题做局部修正

与同类方案的差异

论文将 WorldClaw 与 SynCity、Marble、MajutsuCity、WorldGen、GPT-5.6 Sol 做了定性对比，每种方法都展示了覆盖世界不同部分的四个沉浸式漫游视角。对比结论集中在地形几何表达力和区域空间组织两点上：SynCity 靠分块三维隐变量支持场景级合成，但生成区域的长程组织较弱，不同地形类型之间的过渡不够清晰；Marble 在单个视角内视觉丰富度很高，展示出的地形却缺少显式的区域级组织；MajutsuCity 的建筑与资产排布结构化程度不错，但其面向城市的设计偏重实例排列而非大尺度地貌构建，地面几何相对规整；WorldGen 生成的村落环境连贯且可通行，视野内地形则偏平坦均质。

局限被写得很清楚

论文第五节没有回避问题。首先是对底座模型的高度依赖：WorldClaw 把世界构建拆给多个异质模型协同，分阶段可控性提升了，但对底层模型的泛化能力要求极高。实验中，当前的开源语言模型经常难以生成既可执行又符合用户要求的程序化地形与材质；开源图像生成模型则频繁做不出可用的语义布局图，或者在物体图像生成与提取过程中丢失外观与姿态。最终场景的视觉质量还直接受三维生成骨干的上限约束，几何与贴图保真度不足会明显削弱沉浸感。结论是现阶段要完整验证这套解耦流水线，仍然离不开 Claude Opus 4.8、GPT-Image-2、Hunyuan3D 这类能力较强的模型。

第二个风险来自代码生成的稳定性。地形构建、程序化材质生成、资产摆放和局部精修等多个阶段都依赖大模型直接产出的程序，而把高层自然语言要求稳定翻译成具体程序始终不容易，尺度估计、数值参数或节点连接上的差错都会传导到最终结果。

来源：arXiv（论文编号 2608.05248）、GitHub Tencent-Hunyuan/Hunyuan3D-WorldClaw、Hacker News

要让一个 AI Agent 在长对话里保持连贯，它必须记住之前说过什么、做过什么。但传统做法往往依赖大模型本身来整理记忆：把对话压缩成摘要、提取实体关系、判断该记住什么、该忘掉什么。每一步都要调用 LLM，每一调用都要消耗 token 和时间。

arXiv 上一篇刚提交的论文提出了一个反直觉的思路：记忆操作能不能完全不消耗 LLM token？ 这篇名为 *Zero-Mem: Zero-Token Memory Operations for LLM Agents* 的研究给出的答案是：可以。

02 Zero-Mem 的核心思路：别让大模型干“图书馆管理员”的活

研究团队认为，过去的方法之所以昂贵，是因为它们在记忆读取、写入和检索阶段都调用了 LLM。Zero-Mem 的设计原则很直接：除了最终回答问题那一次，记忆相关操作不再调用任何 LLM，也不消耗任何输入或输出 token。

具体怎么做？它把原始交互记录保留下来，并用两种互补的方式组织这些记录。

第一种是实体—上下文图。它用非生成式的命名实体识别，从对话里抽出实体，再基于共现关系构建图。查询时，先对齐实体，再通过 Personalized PageRank 传播相关度，找到与问题相关的上下文片段。整个过程不需要 LLM 生成摘要或关系三元组。

第二种是时间层次结构。它把对话按粒度分成多个层级：原子轮次、短窗口、事件段、局部上下文。检索时从粗到细定位，既保留了会话的时序局部性，也能快速锁定关键片段。

对于一个查询，Zero-Mem 会综合这两个视图，从图结构和时序结构中分别检索，再把结果喂给最终的问答模型。只有最后这一步才调用 LLM。

03 实验结果：性能不降，速度更快

研究在 LoCoMo 和 HotpotQA 两个基准上做了测试。LoCoMo 是专门评估长期会话记忆的基准，包含单跳、多跳、时间推理和开放域四类任务；HotpotQA 则被改造成了 56K、224K、448K 三种上下文长度设置。

在 LoCoMo 上，Zero-Mem 在 GPT-4o-mini 后端取得平均 F1 59.15，BLEU-1 52.96；相比最强基线 GAM 分别高出 5.40 和 5.46。在 Qwen2.5-14B 后端同样领先。

在 HotpotQA 上，三种长度设置中 Zero-Mem 均取得最高 F1，平均领先最强基线 5.52。

更令人意外的是效率。由于记忆操作零 LLM token，对比当前最快的基线 LightMem，Zero-Mem 把记忆操作的总时间从 788.76 秒压到 334.77 秒，延迟降低 57.6%；每查询耗时从 0.51 秒降到 0.22 秒。

04 为什么这值得关注

当前很多 Agent 框架把“记忆”做成了又一个需要反复调用大模型的环节，成本随交互轮数线性上涨。Zero-Mem 提供了一条不同的路径：用结构化索引替代生成式压缩，在保留原始证据的同时，把昂贵的大模型调用留到真正需要推理的地方。

如果这条路径被后续研究和产品验证，未来长记忆 Agent 的部署成本可能会出现明显下降。

研究团队表示，论文经过同行评审后，代码将在 GitHub 上的 Zero-Mem 仓库公开。

来源：arXiv:2607.29377 / *Zero-Mem: Zero-Token Memory Operations for LLM Agents*