论文: MemSlides: A Hierarchical Memory Driven Agent Framework for Personalized Slide Generation with Multi-turn Local Revision
单位: 北京邮电大学、清华大学、上海交通大学
arXiv: https://arxiv.org/abs/2606.17162
项目主页: https://memslides.github.io/
Demo: https://memslides.com/
代码: https://github.com/huohua325/Memslides
核心命题：PPT Agent 的难点不只是“能否产出一套 slides”，而是进入真实改稿流程后，系统能否记住偏好、延续当前约束，并把修改限制在目标区域。
一、Slides 生成的“平均分陷阱”
现在让大模型生成一套 PPT，已经不是最难的部分。
给它一篇论文、一份产品说明，或者一个项目主题，系统往往可以很快给出一套完整 deck：有标题页，有方法页，有实验页，也有结论页。单看第一版，它可能已经足够“像一份 PPT”。
但这类系统容易掉进一个“平均分陷阱”：第一版看起来还不错，并不代表它经得起后续修改。
想象一个常见场景：用户已经基本接受一套 20 页 slides，只要求“把第 8 页右侧模块改得更像流程图”。如果系统完成了第 8 页的目标修改，却顺手改动了第 3 页的配色、第 12 页的标题层级，甚至让前面已经满意的内容重新漂移，那么从用户角度看，这次修改并不成功。
传统的一键生成式评价很难发现这类问题。它更关心“有没有生成”和“整体质量如何”，但真实使用更关心另一组问题：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
这正是 MemSlides 想处理的“记忆盲区”。近期，这项由北京邮电大学、清华大学、上海交通大学合作完成的工作在 Hugging Face Papers 获得较高关注，项目 GitHub 已获 400+ stars，Demo website 上线一周已有 80+ verified users。不过在这篇文章里，我们更关注它提出的机制问题：如何把 PPT Agent 从生成器，推进到可持续修改的协作者。
二、从“生成结果”到“修改过程审计”
MemSlides 没有把幻灯片生成看成一次性的 source-to-slides 转换。它采用的是更接近真实写作的设定：先生成初始 deck，再在用户反馈中持续更新状态，并围绕当前 deck 做局部编辑。
这个设定改变了问题的重心。
过去我们问：模型能不能根据输入生成 PPT？
现在还要问：它在第 3 轮、第 5 轮、第 8 轮修改时，是否仍然知道用户之前说过什么？是否知道哪些内容已经对齐、不能随便动？是否能把一个模糊的自然语言修改请求，落到明确的 slide region 上？
因此，MemSlides 并不把“记忆”理解为更长的聊天记录。它更像是在做一次信息分流：用户长期形成的写作习惯走一条通道，当前 deck 的临时要求走另一条通道，工具执行中踩过的坑则进入第三条执行经验通道。
三、第一张检查表：偏好到底该怎么写入？
个性化 PPT 生成经常被简化成“给模型一个角色 prompt”。比如告诉系统“用户是金融分析师”或“用户要做学术汇报”，再让模型生成 slides。
问题在于，角色不是偏好。
同样是金融分析师，有人喜欢高密度表格，有人更依赖趋势图；同样是学术汇报，有人希望每页只讲一个结论，有人会保留更多公式和实验细节。真正能影响 slides 形态的，往往是跨任务反复出现的具体习惯。
MemSlides 用用户画像记忆来保存这类信号。它不是把 profile 整块贴进 prompt，而是在任务开始时根据当前 intent 取出相关偏好，再和当前请求做一次 reconcile：兼容的偏好进入当前会话，冲突的部分由用户本轮明确指令覆盖。
任务结束后，系统也不会把所有临时要求都写回长期记忆。只有稳定、可迁移的交互信号才会被 consolidation 到用户画像中。这个设计避免了一个常见风险：用户今天临时要求“这一套 slides 用蓝色标题”，系统却把“永远喜欢蓝色标题”误存成长期偏好。
四、第二张检查表：会话约束有没有跨轮延续？
多轮修改里最容易丢的，不一定是长篇背景信息，而是短小但延迟触发的规则。
例如用户说：“后面新增的页面标题都用蓝色。”当下没有新增页面，这条规则暂时没有执行对象。几轮之后，用户要求插入新 slides，这条规则才真正变得可执行。
如果系统只盯着当前轮输入，它很可能忘记早先的约束。MemSlides 的工作记忆正是为这类情况准备的：它保存当前 deck 内仍然有效的 temporary preferences、carryover instructions、resolved targets 和 coverage status。
这让多轮修改不再是彼此孤立的一次次生成，而是一个带状态的编辑过程。模型不是每轮重新猜用户，而是在同一份会话状态上继续工作。
五、第三张检查表：工具调用有没有吸取经验？
Slides 编辑不是纯文本改写。
一个局部修改可能涉及页面结构、选择器、样式规则、布局快照和验证逻辑。即使模型理解了目标，也可能在工具执行阶段反复试错：读错区域、改错 selector、扩大修改范围，或者在验证不足时提前结束。
因此，MemSlides 引入工具记忆。它记录的不是“用户喜欢什么”，而是“过去类似编辑任务中，哪些执行路径有效，哪些错误应该避免”。
论文中将工具记忆分成两层：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
换句话说，偏好记忆解决“要改成什么”，工具记忆解决“怎么改更可靠”。这两个问题如果混在一起，系统就很难同时保证个性化和执行稳定性。
六、局部修改也需要一套“审计流程”
在真实 PPT 编辑中，“只改这一处”是一条很强的约束。
为避免这种越界修改，MemSlides 将每次反馈先收束到一个可操作的局部范围，再交给 Plan-Act-Guard 执行闭环：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
这套流程的价值在于，它把局部修改从“模型觉得自己完成了”，变成一个可以检查的状态转换过程。尤其在多轮修改中，Guard 的作用很关键：目标没覆盖时不能草率结束，snapshot 过期时需要重新绑定，局部请求也不应被扩展成整套 deck 的重写。
七、评估不能只问“有没有改对”
如果一个系统改对了目标元素，却破坏了其他页面，它到底算不算成功？
论文没有只给一个总分，而是把三个环节分开验证：初始生成看用户画像是否提升 persona alignment，多轮会话看早先提出的 delayed preference 是否被后续触发，局部编辑则用 diagnostic matched-pair modify setting 隔离工具记忆的作用。
在工具记忆的配对诊断中，变化集中体现在三个过程指标上：
|
|
|
|
|---|---|---|
|
|
|
0.963 |
|
|
|
0.534 |
|
|
|
242.5s |
更重要的是，论文没有把结果包装成“所有场景全面胜出”。pair-level 结果仍然保留了任务难度和模型差异带来的波动。这个表述反而更有价值：它说明 MemSlides 关注的是一个可诊断的编辑过程，而不是单纯报一个平均生成分数。
八、从 PPT 生成器到改稿型 Agent
MemSlides 的启示是：PPT Agent 的下一步，不只是生成更漂亮的第一页，而是进入用户真实的修改循环。
在这个循环里，系统要回答三类问题：
-
哪些偏好属于长期用户画像？ -
哪些约束只在当前 deck 中生效？ -
当前修改是否被限制在目标区域，并且经过了验证？
当这三类问题被拆开处理，Slides Agent 才更像一个可协作的编辑伙伴，而不是一次性内容生成器。
论文信息
-
标题: MemSlides: A Hierarchical Memory Driven Agent Framework for Personalized Slide Generation with Multi-turn Local Revision -
arXiv: https://arxiv.org/abs/2606.17162 -
项目主页: https://memslides.github.io/ -
Demo: https://memslides.com/ -
代码: https://github.com/huohua325/Memslides -
Hugging Face Papers: https://huggingface.co/papers/2606.17162
核心启示：PPT Agent 的评估对象正在从“生成结果”扩展到“修改过程”。只有记忆、局部性和验证机制同时成立，AI 才更接近真实改稿流程中的协作者。
进技术交流群请添加AINLP小助手微信（id: ainlp2)
请备注具体方向+所用到的相关技术点 
关于AINLP
AINLP 是一个有趣有AI的自然语言处理社区，专注于 AI、NLP、机器学习、深度学习、推荐算法等相关技术的分享，主题包括LLM、预训练模型、自动生成、文本摘要、智能问答、聊天机器人、机器翻译、知识图谱、推荐系统、计算广告、招聘信息、求职经验分享等，欢迎关注！加技术交流群请添加AINLP小助手微信(id：ainlp2)，备注工作/研究方向+加群目的。
