由北京邮电大学、清华大学、上海交通大学合作完成MemSlides 不是等到用户反复修改之后才开始「记住」而是在首轮生成时就会根据当前任务意图检索用户画像将兼容的长期偏好路由到当前工作记忆里用来影响页面组织和表达方式。最尴尬的一刻往往不是AI PPT生成失败。而是它明明已经生成了一套还不错的slides你只是说「把第 8 页右下角那块改得更像流程图。」下一秒第8页可能确实改了但第3页标题层级变了第12页配色也漂了前面反复调好的风格又被打散。这才是真实PPT工作流里更常见的痛点。第一版只是草稿改稿才是主战场。从「生成一套」到「生成得像这个用户」过去几年自动幻灯片生成进步很快。很多系统已经可以从论文、产品说明或一句主题出发生成结构完整、视觉上也不算粗糙的初稿。但在真实使用里第一版slides的关键不只是「有没有生成出来」而是它是不是已经贴近某个用户的表达习惯。同一篇Transformer论文可以被讲成基础教学课也可以被组织成组会汇报、论文精读或技术培训。不同用户关心的页面角色、内容密度、证据边界和机制展开方式都不一样。有人希望先给结论和takeaways有人更希望把定义、机制、边界条件拆清楚。这正是用户画像记忆在round-0阶段的作用。由北京邮电大学、清华大学、上海交通大学合作完成MemSlides 不是等到用户反复修改之后才开始「记住」而是在首轮生成时就会根据当前任务意图检索用户画像将兼容的长期偏好路由到当前工作记忆里用来影响页面组织和表达方式。论文链接: https://arxiv.org/abs/2606.17162项目主页: https://memslides.github.io/演示链接: https://memslides.com/代码链接: https://github.com/huohua325/MemslidesHF链接: https://huggingface.co/papers/2606.17162该工作登顶Hugging Face Daily Papers #1 Paper of the DayGitHub已获400 starsDemo website上线后也已吸引 100 verified users试用。图1展示的不是一个泛泛的「生成效果图」。它更像是在说明系统如何把论文材料拆成定义、核心机制、实验依据、常见误区和边界条件等页面。这些选择背后对应的就是用户画像中关于内容结构、信息密度和证据导向表达的偏好。图1首轮生成不仅体现完整性也体现用户画像记忆对页面组织、内容密度和证据边界的影响。项目也提供了在线Demo。用户可以上传材料、选择memory profile或模板生成初稿后继续进入revision并下载当前版本的PPTX、HTML或PDF。也就是说MemSlides面向的是从个性化初稿到后续持续修改的完整流程。而一旦第一版已经开始贴近用户后续问题就变得更尖锐系统能否在多轮修改中继续保留这些偏好当前会话里临时提出的要求会不会过几轮就失效用户只想改一个局部区域时系统能不能避免把已经对齐的页面重新打散让记忆分工很多人一听到「Agent memory」会自然想到那就把历史对话放进更长的上下文里。MemSlides 没这么做。原因很简单历史越长里面的冲突也越多。今天用户说「这套报告用蓝色标题」不代表他以后所有 PPT 都要蓝色标题用户在某次编辑里遇到的工具错误也不应该和「他喜欢什么风格」混在一起。因此MemSlides 把个性化幻灯片生成建模成一个有状态的 authoring process系统先根据源材料、用户画像记忆和可选模板生成 round-0 初稿之后每一轮反馈都会更新当前 session state再围绕当前 deck 做局部编辑。它的记忆组织有两个视角。从生命周期看有长期记忆和工作记忆。长期记忆保存跨任务稳定存在的信息工作记忆保存当前 deck 中仍然有效的临时约束、修改目标和执行状态。从功能角色看有用户画像记忆和工具记忆。前者回答「这套 slides 应该体现什么偏好」后者回答「Agent 应该怎么改得更稳」。换句话说MemSlides 不是让 Agent 记住更多废话而是让它知道哪些信息该长期保留哪些只在当前任务里生效哪些属于用户偏好哪些属于工具经验。图2MemSlides 将长期记忆、工作记忆、用户画像记忆和工具记忆组织到同一个多轮改稿流程中。用户画像真正的个性化通常不是一句 role prompt 能解决的。同样是学术汇报有人喜欢每页只放一个核心结论有人会保留公式和实验细节同样是商业路演有人偏好高密度表格有人更依赖趋势图和对比图。这些差异不是一次 prompt 里的标签而是用户在长期写作和修改中慢慢暴露出来的习惯。MemSlides 用用户画像记忆来保存这类跨任务偏好。它不是把 profile 整块贴到 prompt 前面而是在任务开始时根据当前 intent 检索相关偏好再与本轮请求做协调。如果长期偏好和当前明确指令兼容它们会一起进入工作记忆如果发生冲突当前这套 slides 的明确要求优先。这一步很重要。否则系统很容易把「这次临时想要蓝色标题」误当成「用户永远喜欢蓝色标题」。任务结束后MemSlides 也不会把每一句反馈都写回长期画像。它只沉淀稳定、可迁移的交互信号让下一次生成更贴近用户而不是更混乱。图3用户画像记忆会经历检索、路由、当前任务使用和任务结束后的稳定信号沉淀。工作记忆多轮改稿里还有一类信息更微妙。它不是长期偏好却必须在当前 deck 里持续有效。比如用户在第2轮说「后面如果新增 summary/tip box就用浅灰背景。」当时系统还没有新增这类元素所以这条要求没有立刻执行对象。几轮之后如果用户要求插入带 summary box 的页面这条规则就应该被触发。如果Agent只看当前轮输入就很容易把这类延迟生效的约束忘掉。MemSlides的工作记忆就是当前写作任务的状态板active temporary preferences、carryover instructions、resolved targets、coverage status 都放在这里。Plan 阶段读取这些状态来确定修改范围Act 阶段据此执行受限编辑Guard 阶段再更新检查结果。这让多轮修改不再是彼此孤立的一次次 prompt而是围绕同一套 slides 持续推进的编辑过程。图4工作记忆让早先提出、后续才触发的临时样式偏好继续生效。只改该改的地方对人类编辑来说「只改这一处」是一句很自然的话。对生成式系统来说这句话却很难。因为很多系统在处理反馈时会重新读取或重写大范围内容。结果就是目标区域改对了但非目标页面也发生变化。用户看上去只提了一个小要求系统却把整套 PPT 的状态重新打散。MemSlides用scoped slide-local revision来约束这个问题。每次反馈先被映射到最小有效修改区域然后进入Plan-Act-Guard流程。Plan阶段把自然语言请求转成execution contract明确目标slide、作用范围、selector hints 和覆盖要求。Act阶段根据页面结构选择编辑工具并在受限范围内执行最小有效操作。Guard 阶段把「完成」变成一个需要检查的状态目标没覆盖不能草率finalizesnapshot 过期需要重新绑定局部请求也不应被扩展成整套deck的重写。这一步把「模型觉得自己改完了」变成「系统能检查这次修改是否真的覆盖目标、是否越界」。图5Plan-Act-Guard 将局部修改拆成范围规划、受控执行和结果检查。工具记忆Slides编辑不是纯文本改写。一个局部修改可能涉及页面结构、选择器、样式规则、布局快照和验证逻辑。Agent 即使理解了用户想要什么也可能在工具调用时读错区域、重复试错、扩大修改范围或者在目标尚未覆盖时提前结束。所以MemSlides 还引入了工具记忆。工具记忆不记录「用户喜欢什么」而是记录「类似编辑任务里什么执行路径有效什么错误应该避免」。论文将其组织成两种粒度round-scope task experience 记录一轮修改中的经验、错误总结和可迁移模式operation-scope tool-chain experience 保存更细粒度的 reasoning-tool-observation 片段在相似工具调用前被检索出来作为参考。这种设计把目标和执行分开了。用户画像决定 slides 应该往什么方向变工具记忆则让 Agent 少走弯路减少无效探索和执行不确定性。图6工具记忆关注的是工具调用经验而不是用户审美偏好。实验结果MemSlides 的评估没有只给一个总体生成分数而是把不同记忆组件对应的能力拆开验证用户画像记忆对应 round-0 persona alignment工作记忆对应多轮会话中的 delayed preference carryover工具记忆则在 diagnostic matched-pair modify setting 中隔离验证。在个性化生成上用户画像记忆提升了多 persona、多 intent 设置下的 persona alignment。论文进一步指出这种提升不仅体现在「更像某个模板」也体现在内容重点、页面角色、证据组织和 persona 区分等规划层面的选择。在局部修改的配对诊断中工具记忆带来的变化更直接同时core tool time ratio降至0.327x。需要注意的是这些数字来自诊断性matched-pair modify setting不能被解读为所有场景下单调领先。更准确地说它们支持的是一个过程性结论当工具记忆提供可复用执行经验时Agent在闭环完成、严格验证和找到首次正确编辑路径上更容易收敛。图7局部编辑对比是论文中的定性案例用来展示工具记忆注入前后编辑过程的差异。PPT Agent的下一步是长期协作MemSlides讨论的是PPT但它背后的问题不只属于PPT。当 Agent 进入文档生成、代码修改、数据分析、企业知识系统等长周期任务时都会遇到类似挑战哪些信息应该长期保留哪些状态只属于当前任务哪些执行经验可以复用哪些内容在局部修改时必须保持不变。如果说一键生成解决的是从0到1那么多轮修改考验的是从1到可用。未来的Slides Agent不只要会生成更漂亮的第一页还要能在反复改稿中持续理解用户、保持编辑边界并让一套slides稳定地向用户真正想要的版本靠近。