做了十次PPT还是不记得我喜欢什么？这篇论文给Agent装上了"分层记忆"
论文标题：MemSlides: A Hierarchical Memory Driven Agent Framework for Personalized Slide Generation with Multi-turn Local Revision 作者：Ye Jin、Yangyang Xu、Jun Zhu、Yibo Yang arXiv：2606.17162（cs.CL / cs.HC / cs.MA，2026年6月15日提交） 代码 / 项目页 / 视频：论文中均有链接
先说个让我有共鸣的场景
你有没有用过那种"一句话生成PPT"的AI工具？
第一次用，惊艳。一句"帮我做一份关于Transformer的技术分享"，几秒钟出来十几页，配色版式都像模像样。
但用第二次、第三次你就会发现一个让人烦躁的事情——它根本不记得你是谁。
你上次明明跟它说过："正文别堆字，多用图示""标题用衬线体""每页留白多一点"。这次换个主题，它又给你来一份密密麻麻的文字墙。你只能再说一遍、再改一遍。改到第四轮的时候，你提了个新要求："把第三页的副标题改成蓝色"，结果它把整个deck重新生成了一遍，连你前面辛辛苦苦调好的页面也一起给冲了。
这就是当下幻灯片生成Agent的两个老大难：记不住偏好，以及改个局部却伤筋动骨。
MemSlides 这篇论文（arXiv:2606.17162）就是冲着这两个痛点来的。它的核心主张很直接：个性化不该是prompt里顺手带一句的副产品，而应该由一套专门设计的记忆系统来驱动。
核心摘要
MemSlides 给个性化演示Agent设计了一套分层记忆框架：把长期记忆和工作记忆拆开，又把长期记忆进一步切成"用户画像记忆"和"工具记忆"。用户画像记忆管的是跨任务的稳定偏好（你一贯喜欢什么风格），工作记忆管的是当前会话里临时引入的约束（这次特别要求什么），工具记忆攒的是怎么改才不会出错的执行经验。
配套还有一个我觉得挺关键的设计——作用域局部修订（scoped slide-local revision）：改一处只动最小受影响的区域，而不是把整份deck重读重写一遍。
效果上，在GLM-5和Gemini 3.1 Pro两个模型上，persona对齐的各项指标基本全面领先；工具记忆注入后，闭环修改完成率从0.815提升到0.963，首次正确编辑的耗时从609.5秒压到242.5秒。
一句话评价：这篇论文不是在拼生成质量的天花板，而是在补"Agent的记忆"这块一直被忽视的短板——思路扎实，工程味很浓，但实验更像是受控的诊断性验证，离真实用户部署还有距离。
为什么"记不住"是个真问题
先得说清楚，现有的工具到底卡在哪。
像 PPTAgent、DeepPresenter、SlideTailor 这些 agentic 系统，单看生成质量其实已经相当能打了——完整、视觉精美，该有的都有。问题在于它们没有持久化的个性化能力。
你想想看，一个做学术报告的人和一个做商业路演的人，对版式、模板、信息密度的偏好天差地别。同一个人，今天做技术分享、明天做季度汇报，需求也完全不同。现有系统的做法是：每次你都得重新把偏好说一遍。它不积累，不沉淀。
SlideTailor 算是沾了点个性化的边，但论文指出它的个性化是靠你提供的示例或模板撑起来的，而不是从你过往的交互里攒出一份"用户画像"。本质上还是"你给什么我用什么"，而不是"我懂你"。
作者把根源归结为两点，我觉得抓得挺准：
第一，个性化往往是在修订过程中暴露出来的，而不是生成前一次性说清的。你很少能在第一句prompt里把所有偏好讲全，更多是边看边改、边改边提。可现有系统处理编辑的方式是重新上下文化、重新生成大部分内容，这就导致一个小改动得跟整个deck的状态、跟一长串反馈历史去抢那点有限的上下文窗口。多轮改下来，越改越脆。
第二，现有系统把个性化当成prompting的隐性副产品，而不是用记忆设计去正面解决它。
这两点放在一起，结论就很自然了：要做好个性化，得有专门的记忆架构。
方法核心：把记忆分层，各管各的
MemSlides 的整体设计，一张图就能看明白。
图1（Figure 1）：MemSlides 总览。框架由长期记忆与工作记忆两部分构成。第 t 轮中，会话状态 \(s_t\) 和用户反馈 \(f_t\) 经过 Modify Exec 模块处理后，得到更新后的状态 \(s_{t+1}\)。长期记忆又分为用户画像记忆和工具记忆两块。
整个框架其实就回答一个问题：不同生命周期的个性化信号，该用不同的记忆去装。
论文把信号分成三种，我觉得这个划分是全文最值钱的洞察：
| 信号类型 | 生命周期 | 装在哪 | 例子 |
|---|---|---|---|
| 用户画像记忆 \(P_u\) | 跨任务、长期循环 | 长期记忆 | "我一贯喜欢留白多、少堆字" |
| 任务时模板 \(\tau\) | 当前任务局部 | 任务级约束 | "这份deck用公司统一模板" |
| 会话状态 \(z_t\) | 临时、轮次特定 | 工作记忆 | "这次特别把第三页改成蓝色" |
这三者的形式化也很清爽。初始生成是 \(S_0 = G_{\mathrm{init}}(x, P_u, \tau)\)，其中 \(x\) 是源材料；之后每一轮修订 \(S_t = G_{\mathrm{edit}}(S_{t-1}, x, P_u, \tau, z_t)\)，会话状态自己也在迭代 \(z_t = U(z_{t-1}, f_t; S_{t-1})\)。
说到这个"把不同时间尺度的东西分开存"，其实跟操作系统里寄存器/缓存/内存/磁盘的分层是一个味道——快的东西放近处、频繁变的单独管、稳定的沉到底层。只不过这里管的是"用户喜好"而不是数据。
用户画像记忆：意图感知的偏好沉淀
这块负责的是"我一贯是什么风格"。
它有两个关键特性：user-specific（针对每个用户）和 intent-aware（区分意图）。后者我觉得是点睛之笔——同一个人做学术报告和做商业路演，偏好是两套，不能混。所以画像不是一锅烩，而是按意图分桶存。
每个桶内的偏好又按六个维度组织：主题（theme）、内容（content）、视觉（visual）、版式（layout）、模板（template）、通用（general）。
它的生命周期是怎么转的，看这张图：
图3（Figure 3）：用户画像记忆生命周期。任务开始时，匹配意图的画像被路由进活跃临时记忆；兼容的偏好共存，发生显式冲突时旧偏好被取代；任务结束时，稳定的信号才被整合回长期画像记忆。
拆开看就是三步：
任务开始前的路由（round-0）。先用检索算子 \(\mathcal{S}(P_u, i_0)\) 把跟当前意图 \(i_0\) 匹配的画像桶捞出来，记作 \(\tilde{P}_u\)；再用 \(\mathcal{E}(q_0)\) 从当前请求里抽出约束 \(C_0\)；最后用调和算子 \(A_0 = \mathcal{R}(\tilde{P}_u, C_0)\) 把两者捏合成本轮的活跃临时记忆。
修订中的演化。每来一轮反馈 \(r_t\)，就用更新算子 \(A_t = \mathcal{U}(A_{t-1}, r_t)\) 去更新——追加新偏好、覆盖真正冲突的旧项、保留不冲突的。
任务结束的整合。\(P_u^+ = \mathcal{C}(P_u, H)\)，把这一任务里的用户消息 \(H\) 做意图感知的整合，回写进长期画像。这里有个细节我很欣赏：整合是"意图感知"的，专门防止那些一次性的临时请求被误存成持久偏好。你这次随口说"这页背景调成红色"，它不会就此认定你以后都爱红色。
冲突怎么排序？论文给了明确优先级：显式会话反馈 > 任务时模板 > 用户画像记忆。越当下、越显式的，优先级越高。这个顺序符合直觉。
工具记忆：攒的是"怎么改才不出错"
这是我觉得最有工程味的一块。
用户画像记忆管"deck该长什么样"，而工具记忆压根不碰这个——它只管"怎么把目标可靠地执行出来，少犯重复错误、少回溯、本地验证更靠谱"。
它分两个尺度：
图4（Figure 4）：工具记忆流。Round-scope 任务经验在修改任务开始时即可用，并跨轮缓冲在工作记忆中；Operation-scope 工具链经验则把原始的"推理-工具调用-观察"链记录为紧凑可复用的片段。
- Round-scope 任务经验 \(E_t^{\mathrm{round}}\)：粗粒度，modify任务一开始就能用，跨轮缓冲。每轮结束后用agent的经验教训、工具报错摘要、自动提取的模式来更新。
- Operation-scope 工具链经验 \(E_{t,k}^{\mathrm{op}}\)：细粒度，把原始的 reasoning–tool–observation 链切成可复用片段，按操作上下文建索引，下次遇到类似的工具调用前先检索出来参考。
合起来就是 \(\mathcal{M}^{\mathrm{tool}}_{t,k} = (E_t^{\mathrm{round}}, E_{t,k}^{\mathrm{op}})\)。
说白了……（打住，这个词不用）——直白点讲，这就是给Agent建了个"踩坑笔记本"：上次这么调工具报错了/绕远了，记下来，下次别再犯。
工作记忆：让流程从"单次"变"多轮"
工作记忆是会话级的那层。它存活跃临时偏好、carryover指令（延迟生效的偏好）、编辑状态记录（已解析的目标、覆盖状态、快照重绑定提示），还缓冲round级的工具记忆信号。
论文一句话点明了它的作用：它是让 Plan–Act–Guard 流程从"单次"变成"多轮"的那层会话作用域状态。没有它，每一轮都是断片的。
关键设计：改一处，别动全局
如果说分层记忆解决的是"记得住"，那作用域局部修订解决的就是"改得稳"。
核心思想一句话：把请求投影到最小受影响的幻灯片区域，在一个有界的"修复表面"上操作，而不是为每条反馈把整个deck重读重写。
具体怎么做：
- 读取时，只读局部表面的结构化快照——局部版式结构、可用的选择器（selectors）、暴露出来的样式规则。
- 写入时，只写回限定在显式selector或样式规则上的补丁（patches）。
读和写都"局部化构造"，上下文压力小了，意外漂移（drift）也少了。这张定性对比图很能说明问题：
图5（Figure 5）：局部修改执行的定性说明。面对同一个编辑请求，DeepPresenter 会连带改动非目标区域，而 MemSlides 只对目标元素打补丁，其余部分原封不动。
Plan–Act–Guard：把"改对"拆成三步
具体执行落在一条 Plan–Act–Guard 流水线上。看这张图：
图6（Figure 2）：MemSlides 中的局部修改执行。工作记忆向 Plan–Act–Guard 流水线供给活跃临时偏好、carryover 指令、当前编辑状态和缓冲的工具记忆信号。
Plan（规划）：把每个修订请求转成一份显式的"执行契约"——记录推断出的scope、目标幻灯片路径、活跃规则标识符、selector提示、是否需要目标覆盖。本地请求绑到已解析的那一页；deck级规则铺到全部页；混合请求则全局规则和局部例外同时保留。有个细节挺巧：插入请求创建的"仅对未来生效"的规则，不会被错误地强加到已有页面上。
Act（执行）：根据契约挑编辑工具—— - 目标页共享显式selector → 批量CSS更新 - 跨结构不同页的共同语义（标题、正文、页脚）→ 语义批量样式 - 单页要改内容/局部结构 → 读layout-first修复表面，打非空补丁 - 插页/删页 → 显式页级操作 - 整页重写 → 只限新页或损坏状态后的受控恢复
Guard（守卫）：这步我最喜欢。它把"完成"当成一个被检查的状态，而不是模型自己说停就停。Patch调用绑定到快照的内容哈希，快照过期了就触发重绑定提示，而不是直接全量重写；需要覆盖时，过早的finalize调用会被拦住，直到所有目标页都改完或显式确认合规为止。
这个设计直击痛点——LLM最爱干的事就是"差不多了我就说完成了"，Guard等于给它套了个紧箍咒。
实验：数据说话，但要看清楚怎么测的
实验跨了三个模型家族：GPT-5、GLM-5、Gemini 3.1 Pro；基线是 DeepPresenter 和 SlideTailor。测试用了一个受控的多persona、多意图画像库，共30个persona-intent条目（10个persona × 3种角色意图）。
这里我要先泼盆冷水：全程都是推理时的agent评估，没有训练/微调，而且作者自己也承认画像库和编辑请求是"代理"（proxy）而非真实用户的部署研究。所以下面这些数据，更适合理解为"受控诊断"，而不是"真实战场战绩"。
主实验一：persona对齐（首轮生成）
四个0–10的维度：Content（内容是否匹配目标persona）、Structure（页序/版式是否反映persona组织）、Visual（信息密度/留白/视觉层次/基调）、Specificity（用干扰persona测deck是否仍能认出是目标persona）。
| 框架 | 模型 | Content↑ | Structure↑ | Visual↑ | Specificity↑ |
|---|---|---|---|---|---|
| DeepPresenter | GPT-5 | 6.22 | 7.56 | 5.76 | 5.89 |
| GLM-5 | 6.67 | 7.61 | 5.28 | 7.22 | |
| Gemini 3.1 Pro | 6.89 | 8.00 | 6.78 | 7.44 | |
| SlideTailor | GPT-5 | 6.78 | 6.00 | 6.39 | 6.33 |
| GLM-5 | 4.44 | 4.89 | 4.00 | 3.89 | |
| Gemini 3.1 Pro | 4.48 | 5.00 | 4.03 | 4.67 | |
| MemSlides | GPT-5 | 7.11 | 7.33 | 6.00 | 6.67 |
| GLM-5 | 9.00 | 8.78 | 8.56 | 8.89 | |
| Gemini 3.1 Pro | 7.77 | 8.64 | 8.24 | 8.56 |
读这张表，有几个点值得说：
MemSlides 在 GLM-5 和 Gemini 3.1 Pro 上几乎全列碾压，GLM-5上的9.00、8.78这些数确实很能打。跨模型平均下来，相比DeepPresenter分别提升 Content 1.37、Structure 0.53、Visual 1.66、Specificity 1.19；相比SlideTailor更夸张，四项分别 2.73、2.95、2.79、3.08。
但有意思的是GPT-5上没赢透——Structure这一项DeepPresenter的7.56还比MemSlides的7.33高一点。作者很坦诚地把这个写出来了，没有藏。这种诚实我给个好评。
不过我也得多嘴一句：SlideTailor在GLM-5和Gemini上的分数低得有点离谱（4分上下），这让MemSlides的"提升幅度"看起来格外大。baseline在某些模型上表现这么差，对比的说服力是要打个折扣的。
主实验二：通用质量没有被牺牲
个性化做上去了，普通质量会不会塌？这是必须回答的问题。
| 框架 | 模型 | Constraint↑ | Content↑ | Style↑ | Avg.↑ | Diversity↑ |
|---|---|---|---|---|---|---|
| DeepPresenter | GPT-5 | 4.83 | 3.50 | 3.63 | 3.99 | 0.387 |
| Gemini 3.1 Pro | 4.17 | 3.33 | 4.00 | 3.83 | 0.370 | |
| GLM-5 | 4.00 | 3.57 | 4.00 | 3.86 | 0.366 | |
| SlideTailor | GPT-5 | 3.83 | 2.93 | 4.03 | 3.60 | 0.399 |
| Gemini 3.1 Pro | 3.83 | 3.20 | 4.00 | 3.68 | 0.364 | |
| GLM-5 | 3.83 | 2.97 | 4.00 | 3.60 | 0.348 | |
| MemSlides | GPT-5 | 5.00 | 3.60 | 3.90 | 4.17 | 0.380 |
| Gemini 3.1 Pro | 3.33 | 3.37 | 4.10 | 3.60 | 0.463 | |
| GLM-5 | 3.83 | 3.34 | 4.03 | 3.74 | 0.391 |
结论是：个性化的提升没有以牺牲通用质量为代价。GPT-5上MemSlides拿到最佳Avg. 4.17，Gemini上Style 4.10和Diversity 0.463最佳——不过Gemini上的Constraint掉到了3.33，这是个明显的弱点，作者没回避。
消融实验：工具记忆到底值不值
这是全文我觉得最干净利落的一个实验——诊断性匹配对（diagnostic matched-pair）：9对modify任务，每对只改变一个变量——要不要注入工具记忆，其余全控住。这种设计排除干扰的能力很强。
| 模型 | 注入记忆 | 闭环完成率↑ | 严格验证↑ | 首次正确编辑(秒)↓ | 核心工具耗时比↓ |
|---|---|---|---|---|---|
| GPT-5 | ✓ | 1.000 | 0.646 | 211.3 | 0.740× |
| ✗ | 0.667 | 0.294 | 234.2 | 1.000× | |
| GLM-5 | ✓ | 1.000 | 0.488 | 195.9 | 0.344× |
| ✗ | 0.889 | 0.434 | 500.9 | 1.000× | |
| Gemini 3.1 Pro | ✓ | 0.889 | 0.469 | 309.9 | 0.137× |
| ✗ | 0.889 | 0.201 | 968.2 | 1.000× | |
| 总体 | ✓ | 0.963 | 0.534 | 242.5 | 0.327× |
| ✗ | 0.815 | 0.310 | 609.5 | 1.000× |
四个指标全线改善：
- 闭环完成率：0.815 → 0.963
- 严格验证（改完后短窗口内本地验证）：0.310 → 0.534，几乎翻倍
- 首次正确编辑耗时：609.5秒 → 242.5秒，砍掉一大半
- 核心工具耗时比的几何均值：降到 0.327×
最戏剧化的是Gemini那一行——首次正确编辑从968.2秒压到309.9秒，核心工具耗时比降到0.137×。这说明工具记忆对"原本爱绕远路"的模型帮助最大。
作者也老实交代了异质性：有一个Gemini的hard-modify对在闭环完成率上失败了，两个对在首次编辑延迟上没改善，还有一个GPT-5对反而用了更多核心工具时间。不是所有case都灵，这种把"不灵的"也摊开说的态度，比那种"全面碾压"的论文可信多了。
顺手补两个背景
关于工具记忆这个思路，其实跟近来很火的 agent memory / experience replay 是一脉相承的。让Agent把成功和失败的执行轨迹存下来、检索复用，Reflexion、Voyager那一批工作早就在做。MemSlides的特色是把它细分成round和operation两个尺度，并且专门服务于"局部编辑的可靠性"这个具体场景，而不是泛泛地存经验。
关于Guard那个"完成是被检查的状态"的设计，这其实是在对抗LLM Agent一个臭名昭著的毛病——premature termination（过早收手）。模型经常改了一半就宣布大功告成。用快照哈希+覆盖检查把finalize卡住，是个朴素但有效的工程手段。
跨任务沉淀的定性证据
最后看一张定性图，它展示了画像记忆怎么在多次任务间"长出来"：
图7（Figure 6）：跨任务画像整合的定性图。在6个重复任务中，原本零散的局部反馈线索（如证据边界护栏、owner/timeline 闭合表、模块输入输出责任模式、实现清单）逐渐沉淀为可复用的画像偏好。
这张图回答了一个朴素的问题：你前几次随口提的那些要求，第七次做PPT时它还记得吗？图里的答案是——记得，而且是自动从交互里"长"出来的，不需要你显式去配置。
附录里还有Table 7的一个数据可以佐证：在GPT的十persona画像记忆实验里，平均Overall对齐提升了2.42分（Content +3.30、Structure +2.30、Visual +3.17、Specificity +2.43）。
我的判断
先说亮点。
信号分层这个抽象是真的漂亮。 把"跨任务的稳定偏好""当前会话的临时约束""可复用的执行经验"三者拆开，各用一套记忆去管——这个划分既符合直觉，又能落到工程上。我觉得它的价值不限于PPT生成，任何需要多轮交互+个性化的Agent都能借鉴这套记忆分层。
Guard和作用域局部修订，是冲着真实痛点去的。 "改一处冲掉全局""模型过早收手"这两个坑，凡是做过Agent产品的人都踩过。这篇用很务实的方式去补，不花哨但管用。
再说我皱眉的地方。
实验的"诊断性"太重，"真实性"太轻。 全程没有真实用户，画像库是构造出来的proxy，编辑请求也是设计好的。匹配对消融虽然干净，但9对的样本量实在偏小，异质性已经能看到（好几个case不灵）。作者自己在局限性里也承认了这点——需要更广泛的人类研究、随机化的编辑集。所以现在这些数字，我会理解成"机制是有效的证据"，而不是"产品级的战绩"。
部分baseline的弱势放大了提升幅度。 SlideTailor在GLM-5和Gemini上4分上下的表现，让MemSlides的对比显得格外亮眼。这种情况下,看绝对值比看"提升了多少"更靠谱。
隐私这块是个隐患。 一个会自动沉淀你偏好的系统，意味着它在持续记录你。论文也提到未来要加记忆的同意/删除/敏感偏好保护——这不是锦上添花，是产品化的必答题。
总的来说，MemSlides补的是"Agent记忆"这块一直被忽视的短板，而不是去卷生成质量的天花板。如果你正在做任何带多轮修订的个性化生成Agent——不管是PPT、文档还是网页——这套"信号分层 + 作用域局部编辑 + 完成态守卫"的组合拳，非常值得拆开来借鉴。它不是那种让人惊掉下巴的突破，但是那种你看完会默默存下来、下次写代码时真的会用到的工作。
觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我