不微调、不标数据，让设计智能体自己攒"经验手册"：Designer-RSI 的程序性记忆演化

你有没有遇到过这种智能体：刚上线的时候还行，用着用着就开始反复犯同一种错误？你明明知道"下次碰到双重曝光需求应该先抠主体再建蒙版"，但模型不知道——它的权重是冻结的，prompt 里塞下的经验教训第二天就忘了。

这篇来自 Adobe 和 Brown University 的论文（arXiv:2609.22086）就是冲着这个问题来的。说实话我第一反应是"又一个 memory agent"，但读完之后发现它最值钱的不是"给智能体加记忆"这个老想法，而是它处理了一个真正棘手的问题：在反馈噪声大、没有可靠验证器的场景下，怎么保证记忆库越改越好而不是越改越烂。

核心摘要

专业平面设计是典型的长时程智能体任务：几十步相互依赖的操作，产出一张海报或一份排版，但"好不好"没有程序化的判定标准——代码有单元测试，设计没有。Designer-RSI 的思路是让冻结的前沿大模型（Claude、Qwen）操作 230+ 个设计工具，模型本身一个参数都不动，学习的对象全部放在外部——一个叫 SKILL.md 的自然语言技能库。技能库沿两个方向演化：widening（从反复没覆盖到的子任务里铸造新技能）和 deepening（拿成功/失败对比案例修订老技能），所有变更必须过一道"匹配回放门"才能上线。五轮演化、1406 条真实用户简报、1869 条自动打分轨迹，零人工标注，技能库从 76 个涨到 139 个，Claude-Sonnet-4 在 GenEval2 上的执行成功率从 72.7% 拉到 99.3%，生成质量涨了 11.99 个点。这不是底层模型突破，是一套很扎实的工程机制——但它的消融实验（单独 widening 或 deepening 都不行，组合才显著）做得比大多数同类工作诚实。

论文信息

• 标题：Designer-RSI: Evolving Procedural Memory from User Traffic for Agentic Graphic Design
• 作者：Hongyang Du, Lan Yan, Christian Flores, Asim Kadav
• 机构：Adobe / Brown University
• 发表：arXiv:2609.22086v1 [cs.AI]，2026 年 9 月 18 日
• 链接：https://arxiv.org/abs/2609.22086

问题动机：设计这个任务，难就难在"没法判对错"

先说清楚这篇论文在解决什么问题，因为这个问题定义本身就值得聊。

训练智能体通常有两条路：监督学习需要专家示范轨迹，贵；强化学习需要奖励信号，而奖励信号要么来自可验证的结果（代码能不能跑通、数学题答案对不对），要么来自奖励模型。平面设计两头都不占：

• 长时程信用分配：一张海报可能要几十步操作——选素材、抠图、调字间距、建图层、调色——终端那个"好/不好"的反馈，很难告诉你到底是第 7 步的蒙版没建好，还是第 23 步的字体选错了。
• 没有成功预言机：设计简报里混着硬性需求（文字内容、颜色、位置）和主观标准（层级感、构图、风格）。VLM 评委能抓住一部分，但抓不住全部。论文里那句对比挺扎心的：代码有可执行测试，设计没有 success oracle。
• 模型不能动：前沿模型是外部托管的，权重更新不切实际。

那怎么办？作者的答案是：既然模型动不了，那就让模型周围的东西去学。具体来说，是一个自然语言写成的"程序性记忆"——每条技能是一段操作指南，比如"双重曝光：提取主体 → 构建蒙版 → 混合素材 → 精修"。它介于"单次工具调用"和"完整轨迹"之间：具体到能指导执行，又抽象到能迁移到别的任务。

这个定位我觉得挺准的。技能不是宏录制（那太脆），也不是泛泛的"要做好设计"（那没用），而是可复用的程序。

方法核心：一个冻结模型 + 四个角色 + 两个演化轴

图1：系统总览。左半边是正常运行循环——用户简报进来，检索匹配技能，冻结模型驱动设计软件执行，多模态评委按 Graphic-Eval 量规打分；右半边是演化循环——分数低的轨迹触发技能修订，没被任何技能覆盖的子任务攒够证据后铸造新技能。注意中间那个大大的 "Frozen Models"：从头到尾没有一次权重更新。

整个系统围绕四个角色转：

只有 SKILL.md 文件在变。演化沿两个轴进行，这是整篇论文的骨架。

Widening：没被覆盖的子任务，攒够 3 次就铸成新技能

先看拓宽这条轴，它回答"技能库里没有的能力从哪来"。

图2：新技能的铸造流水线。关键在最右边那道 Replay Performance Gate——候选技能不是"看起来合理"就能上线的。

机制拆开看：

1. 每条轨迹跑完，冻结 LLM 从简报和工具调用序列里提取实际执行的子任务，做规范化；
2. 如果检索到的技能没覆盖某个子任务（或者覆盖的是任务的其他部分），记为 uncovered。还有个细节：如果某个技能被评委"背锅"（关联了不良结果），相关子任务也计为未覆盖——这个设计挺聪明，烂技能不等于有覆盖；
3. 未覆盖子任务按规范标签累积到一个持久的覆盖池里，同一标签出现满 \(k_{min} = 3\) 次，LLM 就把这些案例蒸馏成候选技能；
4. 候选技能必须过回放门（对阵无技能基线）才能进库。被拒绝了也不丢记录，池子里的证据还在，后面轮次可以继续攒。

Deepening：失败次数够多的老技能，拉出来修

另一条轴回答"已有的技能不靠谱怎么办"。

图3：技能修订的完整回路。注意右上角的 "One Loop Max"——额外探索最多跑一圈，防止无限修一个修不好的技能。

这里有个刻意的不对称设计，我觉得是全文最工程化的细节：选择哪些技能要修，用的是廉价宽松的启发式；但真正决定改完的版本上不上线，是那道门。也就是说，宁可多修、不可漏修，反正门会兜底。

具体流程：

• 得分低于阈值（\(s_j \lt \tau, \tau = 0.6\)）的轨迹，给它检索到的每个技能都记一次失败；
• 失败计数达到 \(m = 2\) 的技能进入修订队列，失败最多的优先；
• Reflector 收到的输入很有意思：除了简报、逐条需求的失败理由、当前 SKILL.md 之外，还有同一技能在相似任务上的成功调用对比集——成功运行的实际工具调用序列、中间 waypoint 结果、thinking tokens。成功案例是"不许退化"的基线，失败理由指出要修哪里，Reflector 基于这种"成功↔失败分歧"来写修改；
• 输出是定向编辑（指明改哪个章节、怎么改）。同一个技能的定向重写反复被门拒绝？升级为整体重写。再不行？进一次性探索循环——带着技能和不带技能各跑一遍它的失败提示，往成功的那一侧蒸馏，最终裁定这个技能是 update、delete 还是 keep（keep 的会被重新路由回 widening 的覆盖池，等于承认"这个技能描述的场景根本不该由它管"）。

Replay Gate：全文真正的核心

好了，到我最想聊的部分了。

回放门要对付两个混杂源，这两个问题在真实部署里都非常要命：

1. 评委漂移：VLM 评委对同一张图的绝对分数跨次运行会漂。如果你用"平均分涨了就算改进"这种判据，你测到的可能只是评委心情好。所以门从不使用绝对分数。
2. 上游状态泄漏：结果不只取决于技能——素材检索、上下文状态都影响输出。候选技能可能只是因为运气好用到了更好的素材才赢的。

门的做法是把这两个混杂源都冻住：采样能触发这个技能的提示，每个提示生成若干上下文（各自有不同的检索素材和上游状态），然后每个上下文冻结住，在同一批次里两臂回放——重写场景是"候选技能 vs 现任技能"，铸造场景是"候选技能 vs 无技能智能体"。输出在顺序随机化下做成对评判。每个上下文里唯一的变量就是技能条件。

上线的充要条件：

翻译成人话：一条提示只要输了任何一个上下文多数，整个变更就枪毙；必须至少赢一条提示、且一条都不输，才能上线。而且一个提示只有在候选赢下其多数上下文时才算"赢"——防止单一上下文的大胜掩盖其他上下文的亏损。

等等，这个判据是不是太保守了？确实保守。但注意回放集同时覆盖成功和失败历史，所以这个判据的实际含义是"修好了失败，且没把已有的成功搞砸"——这对应生产环境里回归成本远高于改进收益的非对称性。作者也明说了灵感来自安全策略改进（safe policy improvement）那条线。

说实话，这是我近期看到的 agent memory 工作里，对"怎么防止记忆库退化"这个问题处理得最认真的一个。很多同期工作（比如各种经验池、技能库方案）的隐假设是"反射出来的经验大概率是好的"，这篇论文的假设是"反射出来的变更大概率是噪声，默认拒绝，拿出证据才放行"。这两种假设导出的系统行为完全不同。

技能的存储与检索

附录里还有个值得一提的工程决策。每条技能就是一个 Markdown 文件加 YAML front matter，按 app_mode 分三个子库（raster / vector / page_layout）。front matter 里最关键的是 description——200 到 600 字符的触发短语，唯一的检索信号。

检索是两阶段的：先把用户请求蒸馏成至多 6 个核心操作关键词（忽略主体、形容词、颜色值），然后做 token 重叠打分：

为什么不用 embedding 检索？作者给的理由很实在：冷启动播种和运行时检索要用同一个分词器，保证写进 description 的触发短语必然能被同一个程序检索到。用 embedding 的话，铸造技能时写的描述和检索时的向量空间之间没有这种保证。这个理由我第一次见有人明说出来，仔细想想确实是很多技能库系统的暗坑。

注入方式是渐进式披露：系统提示里只放紧凑目录（名称 + app 标签 + 一行描述），模型自己调 load_skill(name) 才读正文。控制 context 开销的标准做法。

实验结果

演化动态：76 → 139，门拒掉了将近一半的提案

图4：这张堆叠柱状图是理解整个系统的钥匙。R1 以修复为主（59 个重写提案过了 39 个），R2–R3 是铸造高峰（22/46、26/40 被接纳），R5 又反转回以重写为主（21 个重写 vs 4 个铸造）。五轮合计：门拒绝了 100/231 个重写提案、67/136 个铸造候选。

这组数字本身就说明回放门不是摆设——拒绝率接近 45%。如果门什么都放行，技能库会膨胀得更快，但质量就没法保证了。

还有一个证据：新铸造的技能跟冷启动库的最近邻距离是 0.215 vs 0.158（中位数，Mann–Whitney \(p \lt 10^{-8}\)，Cliff's \(\delta = 0.58\)）——widening 铸出来的技能确实覆盖了种子库没覆盖的意图，不是在复述已有技能。

图5：技能空间的投影可视化。铸造技能（实心）没有均匀混在种子技能里，而是在某些区域形成了新的簇——直观上印证了"覆盖缺口"的说法。

内部基准：非单调，但高质量尾部持续变强

论文里有个让我挺意外的诚实之处：演化曲线不是单调上升的。

200 条人工撰写简报上，完整性留存率（得分 ≥ τ 的轨迹百分比，Claude-Sonnet-4）：

最大的提升在高分段：τ ≥ 0.9 处从 43% 涨到 56%，+13 个点；满分轨迹从 24% 到 32%。但注意 R4：在 ≥0.3 这种低阈值上它甚至低于无技能基线（90% vs 94%），高端却还保持 +7 个点。作者的解释是 R3、R4 分别铸造了 26 和 13 个技能，R4 囤积了最多没修订过的 v1 技能，低端被这些新技能的粗糙版本拖累了；R5 把配比反转过来（21 个重写、只铸 4 个），就成了所有阈值上最强的一轮。

这个细节很重要，因为它说明演化系统的中间状态可以是局部退化的，门只能保证单步不回放集上的回归，不能保证全局单调——作者在局限性里也承认了这点。比那些只画一条平滑上升曲线的工作可信多了。

通用 T2I 基准：三个骨干全涨，弱模型涨得最多

括号里是执行成功率百分比。平均质量提升：Opus +3.83、Sonnet +7.70、Qwen +9.67。

最炸的数字是 Sonnet 在 GenEval2 上的成功率 72.7% → 99.3%，质量分 +11.99。我的解读是：技能主要修的是执行层面的失败——工具不会用、步骤漏了、参数错了——这类问题在弱模型身上占比更高，所以弱模型获益更大。Opus 本来就强，GenEval2 上甚至小幅回落（-3.32），DPG-Bench 成功率也掉了 4.6 个点，说明技能不是免费午餐，强模型身上偶尔还会帮倒忙。

另外要泼一盆冷水：Qwen 的平均质量分涨得最猛（+9.67），但它的成功率只有 50% 上下，而质量分只对成功输出评估——幸存者偏差会让这个数字偏乐观。论文自己点明了这一点，算厚道。

延迟开销只有 3.4%–6.2%，个别情况还更快（Sonnet 在 DPG-Bench 上 113 秒降到 82 秒）——技能把执行路径变直了，纠正性重试少了。

专业设计基准：成对胜率 61.8%–67.6%

四个专业设计基准（OpenCOLE、GraphicBench、CreatiDesign、BannerRequest400），GPT-5.4 盲评双顺序成对比较：

整体胜率六成出头，算得上扎实但不惊艳。注意 Qwen 在 GraphicBench 上 49.0%——低于平局线。跨基准的波动也说明技能收益是任务依赖的，不是普适buff。

消融：单独 widening 或 deepening 都不够，组合是超加性的

这是全文最关键的一张表（200 条留存简报）：

三个值得停一秒的数字：

1. 冷启动技能库不如没有技能：68.62 vs 69.08，胜率 46.4%。从文档里扒出来的技能直接塞进库，效果是负的。这个发现挺反直觉的——很多人（包括我）会默认"文档衍生的技能再差也比没有强"。不是。未经实战检验的技能会带偏模型。
2. 单轴都不够：只重写 48.6%、只铸造 49.4%，都围绕 50% 平局线打转。
3. 组合是超加性的：完整性 74.04，比冷启动 +5.42；胜率 58.5%（p = 0.025）。超加性增益 +3.85，作者的解释是两条轴有循环耦合——铸造的技能需要精修过的检索描述才能被正确触发，而重写流程会把修不好的失败重新路由给铸造流程。拆开都是半成品，合起来才是系统。

还有个成本细节：技能检索让 prompt tokens 比 Base 多了约 28%，但演化本身不增加边际成本——Evolve 的 prompt/output tokens（436.6k / 5167）反而低于冷启动（445.2k / 5298），因为执行更直接、返工更少。

定性对比：同一工作流的迁移

图6：无技能基线的产出。鹰的素材图带着白色背景直接糊在右上角，合成感极强。

图7：演化后的产出。差别不是"模型突然会合成了"——模型一直是冻结的——而是技能库里多了一条"如何把素材自然融入场景"的程序。

论文里另一个双重曝光的案例更能说明问题：Base 在字母形状上做过双重曝光，但换到人物剪影就失败了；Evolve 把同一个工作流迁移了过来。作者那句话点得准——"suggesting a missing procedure rather than a missing capability"。缺的不是能力，是程序。这大概是程序性记忆这个范式最成立的论据。

我的判断

先说亮点。

这篇论文最值钱的地方是回放门，不是技能库。"给智能体外挂经验库"这个想法 2024 年以来已经被做了无数遍—— Voyager 的技能库、各种 reflection memory、经验回放——但绝大多数工作对"经验库会被噪声反射污染"这个问题要么回避，要么用一个脆弱的启发式过滤。Designer-RSI 把问题摆正了：评委是漂的、上游状态是混的、反射是噪的，所以默认拒绝一切变更，让候选在冻结上下文的成对回放里自证。这个"保守演化"的姿态，加上接近 45% 的真实拒绝率，是它跟同期工作拉开差距的地方。

批判性地说几点：

• 评估闭环的自洽性存疑。Grader 是 VLM、专业基准的评委是 GPT-5.4、回放门里的裁判也是模型——整条链路没有一个环节有人工核验。1406 条简报、1869 条轨迹全自动打分，"无人工标签"是卖点也是风险点：如果评委系统性地偏好某种风格，技能库会向评委的口味演化，而不是向用户的口味演化。论文没有做人评校验实验，这是个缺口。
• "真实用户流量"的成色存疑。1406 条简报是"用户流量 + LLM 增强变体"的混合物，比例没交代清楚。评估集只有 200 条人工简报。样本量对统计结论（p = 0.025 那场）够用，但"从真实流量中学习"的叙事强度要打个折扣。
• 胜率提升集中在 completeness，aesthetics 几乎没动（65.92 → 66.53）。你想想看，这说明技能解决的是"把需求做全"，不是"把设计做美"。这符合机制预期（程序性知识擅长步骤、不擅长品味），但也划定了这套方法的天花板。
• 依从性问题作者自己承认了：模型有强默认策略时，检索到的技能不一定被遵循。自然语言程序对模型的约束力是软的，这在长程序上会更明显（作者也承认长程序保真度衰减）。

跟同期工作的位置：它没有 Voyager 那种开放式探索的浪漫，也没有 RL 方法的性能上限，但它给出了一条在今天就能落地的路——模型是别人的、权重动不了、反馈是脏的、错误很贵，这就是绝大多数企业部署的真实约束。在这些约束下，一个"冻结模型 + 可演化 SKILL.md + 保守回放门"的架构，可能是目前最实用的持续适应方案。

工程启发很直接：如果你在维护一个上线了的智能体，别急着把所有反射出来的"经验"灌进系统提示。给每条经验建一个回放集，让它在自己声称能修好的失败案例上、跟现状做受控对比，赢了才上线。这个模式跟模型无关、跟领域无关，照搬到代码智能体、数据分析智能体上都成立。

但还有一个更本质的问题没解决：当技能库涨到几百上千条，检索的 precision 和技能之间的相互干扰会变成新的瓶颈。论文里 139 条时 token 重叠检索还够用，再翻十倍呢？这可能是下一篇论文的事了。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新AI前沿，关注我