LingBot 世界的回访记忆

一个世界可以持续生成，镜头前的画面也始终自然。但你沿原路返回时，先前打开的门、停放的车和墙上的标记，仍在原位吗？

LingBot-World-Infinity 的论文报告了超过一小时的单次连续 session；同一论文的限制部分又承认：区域离开上下文后再访问，可能被重新生成，而不是按原样取回。两句话并不矛盾。持续输出、响应当前控制、保存可回访的世界状态，是三个不同的验收问题。

本文依据截至 2026 年 9 月 26 日的论文与官方仓库，给出一种能失败、也能复核的回访实验。文中没有本机生成或实时系统测试结果。

一小时演示到底证明了什么

自回归视频模型会把已生成帧继续作为条件，误差有机会一块块累积。纹理、几何和角色如果在长时间滚动生成中没有明显塌陷，就是一项有价值的结果。论文第 5 节用超过一小时的连续运行展示这一点，并在第 3、4 节说明因果预训练、蒸馏与实时系统优化。论文全文

但单向前进时，模型未必需要重新找到一个已离开视野很久的具体对象。因此三类问题要分开观察：

论文第 6 节把第三项限制说得很清楚：模型尚未真正记住已生成世界；区域离开上下文后，重访时可能重新生成，角色身份、风格和物理交互也仍可能失真。这限定了第一项结果的解释范围，并不抹去长时生成的进展。

把“还在生成”和“仍是同一个地方”拆开看

假设镜头从一条街持续向前走，每次转弯都看到新的建筑。观看者可以评估街景是否自然、转弯是否连贯，却很难判断十分钟前的街角有没有被保存。因为旧街角没有重新出现在镜头里，缺少一次要求找回旧事实的机会。反过来，若镜头在几十秒后回到同一个路口，视频虽然更短，却对状态保持提出了更具体的要求：门的位置、招牌内容、停放物体的朝向，应与先前记录对应。两种演示难度不能只按时长排序。

回访还需要证明镜头真的回来。若控制文件让相机大致向后移动，但角度和高度已经变化，两个画面中的对象比例会不同；直接逐像素相减会把正常视角变化算作记忆错误。因而先记录回访路径和预期视点，再确认地形和多个锚点关系能够支持“这是同一处”。如果地点本身无法识别，本次结果应该写成定位不确定，暂不评判具体门牌是否保存。

风格相似尤其容易制造误判。假设第一次出现的是蓝门、红招牌和面向右侧的白车，第二次仍是一条同风格街道，但门变绿、招牌字符不同、车朝向相反。整体观感可能依旧漂亮，三项可检验的旧事实却已经变化。把这些差异逐项列出，比给“连续性很好”一个总分更有解释力。这里的街景是实验设计示意，不是对论文演示内容或模型实际表现的描述。

为什么动态 KV Cache 不等于世界存档

模型生成下一帧或下一块时，会利用前面的画面、相机姿态与文字条件。论文描述的底层控制主要是相机姿态和分块提示；更复杂的对象操作与事件由上层 Agentic Harness 组织。相机路径不是机器人电机命令，也不是游戏引擎的完整状态变更。论文第 3.2、4.2 节

KV Cache 留下部分历史特征，让下一块视频利用先前内容。实时系统中的动态缓存调度会依据当前输入选择较有用的历史，并丢弃部分条目，以控制计算成本和干扰。论文第 4.3.2 节

缓存的作用是为当前生成提供有限上下文。它并不是一个按地点索引、可精确查询的世界数据库。某个房间离开上下文后，再出现的房间可以在风格上相似，却未必保留那扇门的颜色、车辆的方向或先前事件的结果。若应用要求“回来时仍是同一件物体”，持久状态或独立回访校验就必须另做；公开论文没有交付一个已验证的持久世界状态接口。

有限缓存与显式状态各自承担什么

若要为应用补持久状态，可以先提出一个最小的状态对象：地点标识、对象标识、已发生事件、记录时间，以及状态来自哪一次可观察输出。它描述应用想保存什么，而不是说明模型已经具备这些接口。模型内部特征可能帮助下一段生成，但应用未必能从这些特征中可靠取出“这扇门现在开着”这样的事实；应用侧状态也不能凭空保证生成器会服从它。

因此，保存和使用应分成两项待验证工作。第一项是旧状态能否被明确记录并找回；第二项是找回的信息能否作为模型实际支持的条件进入新一轮生成，并在画面中保持。只把旧帧存到磁盘解决的是留证据，不等于下一次生成自动读到了它。只把“门仍然开着”加到文字里解决的是表达意图，也不等于事件状态已经可靠执行。

还要考虑冲突。旧记录说门是蓝色，当前画面显示绿色，系统应保留差异并标为待确认，而不是用新画面覆盖历史后再宣称没有变化。若应用确实允许世界随事件演化，就记录哪条事件授权了颜色变化；没有事件记录的差异与合法变化分开。这个要求使回访检查能区分“世界发生了变化”与“模型忘记了旧世界”，避免把所有不一致都归到同一个原因。

这种显式状态设计会增加存储、检索与输入拼装成本，并且仍需要生成侧的服从性验证。若产品只做一次性视觉漫游，不要求再次访问同一对象，可能没有必要先搭完整状态服务。若关卡解谜依赖先前门锁已打开，状态保持就是任务正确性的组成部分，不能靠画面连贯替代。取舍取决于用户会不会真的追问过去发生了什么。

公开代码能测到哪一层

项目官方 README给出 14B causal-fast 的 480P、8 GPU 示例，以及 1.3B causal-fast 的 480P、4 GPU 示例。1.3B 包只含 DiT 权重，T5、VAE 和 tokenizer 还要取自 14B 发布资产。公开的 generate.py 使用初始图片、文字与 --action_path 生成有限帧数的视频文件；脚本把 action_path 解释为 camera path。

论文另报告一条部署系统链：编译与并行、异步 VAE 解码、逐帧流式传输、时空增强和动态缓存调度，共同支撑作者展示的 720p、60 fps 实时交互。运行 README 的离线 480P 命令，不会自动复现这一链路。README 也明确说不计划开放其部署代码。论文第 4 节、仓库说明

论文摘要的“1.3B 单 GPU 可部署”与当前 README 的四 GPU 公开示例，描述的是不同实现条件；不能把前者写成当前 CLI 的单卡复现命令。本文不据此估算 A6000 显存，也不把 camera path 脚本当成已开放的 Director/Pilot 事件控制系统。

设计一次能失败的回访实验

实验要把三个能力分开留下证据。先固定仓库 commit、权重 revision、推理后端、设备、分辨率、帧数、seed、初始图像和控制文件。公开 CLI 只能先测其支持的离线输入；实时热键、Agent 事件与服务延迟需要另记完整系统版本。

1. 旧地点：锚点是否仍是同一组

在初始场景选三个可识别锚点，例如左右不同颜色的门、带编号的招牌、固定位置的车辆。让镜头离开、经过多个视频块，再沿明确路径返回。保存离开前、最远点与返回时的关键帧，逐项记录门的方位与颜色、招牌编号、车辆身份及位置。不要只给整体“像不像”的印象分。

把离开到回访的间隔与缓存参数一并记录，逐步增加路径长度或间隔。短距离回访成功，只说明那一组条件下历史可能仍足够；失配也不能在没有缓存内部证据时直接归因于某条 KV 被淘汰。可报告的是“锚点随间隔变化的现象”。

2. 事件：发生过的事有没有保留

如果系统确实提供可执行的对象事件，让门打开或物体移动，然后离开并回访。分别检查动作是否发生、结果是否保持、回访时是否退回未执行前的版本。

论文的 Agentic Harness 通过 VLM 和视频生成器联动处理对象与事件。单独给 generate.py 一条 camera path 并不能复现这条事件链。只有公开 CLI 时，事件保持应标为“当前入口不可测”；文字提示生成一段开门视频，不能替代状态更新和回访。

3. 控制：同一起点能否按动作分叉

固定初始图像、prompt 和 seed，仅改变一个控制变量，例如左转与右转的相机路径。比较早期响应方向、响应延迟、场景分叉及各自的回访结果。它可以测控制是否被使用；即使分叉清楚，也不能推出长期记忆成立。

每次实验至少保留：模型和权重 revision、仓库 commit、后端与设备；输入图、提示词和控制文件的 SHA；分辨率、帧数、seed、chunk 与缓存参数；关键帧和时间戳；预先指定的锚点；期望和实际控制响应；回访逐项结果及失败位置。没有实际生成与逐帧目检，不填写“通过”。

让回访结果可比较，而不是只挑最好的一次

正式运行前先写判定规则。例如门的位置和颜色分别记，招牌的可读编号单独记，车辆身份与位置分别记；对象被完全遮挡时记为不可判断，不算失败，也不算通过。不要生成之后才挑容易认出的锚点，否则本来消失的对象已经被排除在验收之外。锚点也应有足够辨识度：无文字、无特征的墙面很难检验对象身份，过小的编号则可能在初始分辨率下就不可读。

可先设计两个对照，而不是立即拉长到一小时。第一组是在很短间隔内离开并返回，用来检查路径与锚点是否可观察。第二组只增加离开时间或经过的视频块数，其他输入保持一致。若第一组都无法判定，先调整实验可观察性；若短间隔可判、长间隔失配，再记录差异发生的条件。这里并不预设必然出现一个缓存阈值，模型随机性、遮挡和路径偏移都可能影响结果。

同一条件应保留多次运行，既保留成功也保留失败，不能只发布一条最好看的回访视频。可以把每次的对象结果并排展示，再说明观察次数很少，只构成局部证据。没有足够样本时，不把几次成功换算成长期稳定概率。若之后换了模型、权重或缓存策略，就建立新组，避免把不同系统的结果混成平均数。

评价过程也需要固定。可以让评阅者先看离开前的锚点记录，再看返回帧；或者隐藏配置标签让其判断对象是否相同。对于不能清楚读出的编号，保持“不确定”，不要由大模型补出看起来合理的字。自动相似度可以帮助筛帧，但其分数不应覆盖人工发现的状态反例：背景相似而门锁状态相反，对依赖门锁的任务仍是失败。

事件实验还有一个独立陷阱：最初的动作可能根本没有完成。若门没有确实打开，回访时看到关门并不是“已打开状态丢失”。必须先保存动作前、动作后和回访三处证据。对于仅有相机路径的入口，明确跳过这一项。跳过原因是入口不支持所需控制，不表示模型事件保持成功，也不表示已经证明失败。

控制分叉则关注另一个问题：输入动作是否真正影响输出。固定起点后，左转与右转要对应可检查的相机方向，不能只比较两条视频是否不同；随机生成本就可能造成差异。若两路都朝同一个方向运动，先核输入被解析与条件被使用的情况。即使动作方向符合预期，也继续把回访结果单列，因为响应当前动作和找回旧事实需要不同证据。

最后，给每条录像留下三句结论即可：本次是否完整生成、控制是否符合这一路输入、锚点回访是否保持。三句允许各自成立、失败或不可判断。假设完整生成通过、左转控制通过、车牌回访失配，结论就是局部视觉与控制可用，但不能用于依赖车牌恒定的任务。这样的结论比笼统“世界模型测试通过”更容易被下一次实验推翻，也更能指导产品范围。

回访录像还能暴露一类更隐蔽的问题：画面中的对象被保留了，但对象之间的关系改变。例如仍有三扇门，却从左右关系变成另一种排列。对于视觉漫游，观众可能暂时接受；对于导航，选择左门还是右门就是决策依据。锚点记录不只写对象名，还应写它与邻近对象的相对关系，以及何种变化会影响后续任务。这样便能避免用“对象都还在”掩盖空间关系失配。

若产品计划在生成世界中记任务进度，也要区分外部任务记录与画面记录。系统可以保存“用户已取得钥匙”的进度，而生成器回访时仍把钥匙画在桌上。任务记录正确，画面仍与之冲突；反过来画面显示钥匙消失，也不能证明任务数据库已完成更新。把两个来源的事实并列，才知道失败应修在应用状态、条件注入，还是生成输出检查。这里没有提出已经实现的解决方案，而是在说明应用验收必须保留这种交叉核对。

如果只能选一个起步实验，优先选择用户真实会依赖的锚点。例如探索原型先验证路口关系，解谜原型先验证门的开关结果，而不追求覆盖所有物理现象。实验的价值来自它能直接否定一种产品承诺：一旦必要状态回访失败，就能收窄当前可交付范围。这比把所有视频指标合成一个高分更能避免误用。

回到应用判断

互动原型可能只要求画面连续和即时响应；需要稳定对象身份、可查询场景或可验证动作结果的 Agent 与机器人工作流，则必须单独验收世界持久性。视频回访成功本身，也不证明真实机器人的闭环控制安全。

现在的公开证据支持提出回访问题、设计离线锚点试验，并清楚划出哪些事件链尚不能由公开入口测试。“能连续生成一小时”是一项结果；“回来时仍是同一个世界”仍须另交证据。

资料：官方论文（第 3–6 节）；官方仓库（权重、离线示例和部署边界）；公开推理脚本（camera path 与帧数参数）。论文性能为作者报告，本文未运行模型。