Designer-RSI:让AI设计智能体从用户流量中进化记忆

一篇发表于arXiv的新论文《Designer-RSI: Evolving Procedural Memory from User Traffic for Agentic Graphic Design》(编号2609.22086),由Hongyang Du、Lan Yan、Christian Flores和Asim Kadav共同撰写,提出了一个让语言模型智能体在操作超过230种设计软件工具的同时,持续构建并优化一个可复用的"程序性记忆库"的框架。这个记忆库不是对话记录,也不是简单的历史日志,而是一套不断被验证、精炼、累积的可执行设计流程集合。

为什么是"程序性记忆"而不是对话记忆

目前大多数智能体系统依赖的是情景记忆或对话上下文:记住这次对话说了什么、上一步做了什么。但对一个需要反复操作设计软件、完成成百上千个相似又不完全相同的用户请求的智能体来说,单纯记住对话历史帮助有限——每一次任务结束,那些临场摸索出的操作序列就随对话窗口一起消失了。

Designer-RSI的核心洞察是:真正值得沉淀的不是“发生过什么”,而是“怎么做成的”——也就是可以被抽象、命名、复用的操作程序。这与人类专家积累经验的方式更接近:老练的设计师不会每次都从零摸索软件功能,而是有一套内化的工作流程可以直接调用并按情况微调。

防止"改进"变成"退化"的机制

论文中一个值得注意的设计是:当系统基于新的成功或失败案例去修正已有程序时,引入了一种防止改进引入退化的机制——确保新的修补不会悄悄破坏原本已经能正确工作的部分。

这一点在一个会持续自我修改技能库的系统里至关重要:如果每次“优化”都有可能连带破坏此前积累的能力,那么记忆库的规模增长反而会变成风险的累积,而不是能力的累积。这种“回归安全”的设计思路,某种程度上呼应了软件工程里持续集成测试防止代码退化的逻辑,只是这里被应用到了智能体自我更新的技能程序上。

设计任务为何是自我改进的高难度考题

论文特别指出,程序性记忆为智能体在反馈噪声大、难以验证正确性的场景下提供了一条实用的适应路径——而这恰恰点出了图形设计与数学、代码等任务的本质差异。数学题有唯一解,代码能否运行是二元判断,但一份设计稿“好不好”高度依赖主观判断、审美偏好和上下文语境,没有可以直接拿来打分的标准答案。

这意味着Designer-RSI式的自我改进系统必须在信号本身就模糊、有噪声的情况下,依然能分辨出哪些程序性调整是真正的进步。能在这样的领域里做到有效的自我优化,某种意义上比在有清晰对错标准的领域里做到同样的事更难。

数字说明了什么

研究团队在1406个真实用户设计请求和1869条自动化轨迹上进行了测试。结果显示,技能库从最初的76个程序扩展到139个,几乎翻倍;某项报告指标从72.7%提升到99.3%;相对基线模型的胜率在61.8%到67.6%之间。

分析同时确认,技能获取(学会处理此前无法应对的新任务)和程序优化(改进已有流程)两者都对整体提升做出了实质贡献,而非其中一项单独驱动了结果。这组数字合起来暗示的是:今天大多数工具调用型智能体在处理重复性任务时,并没有从“做过的事”里真正学到东西——每一次调用都像是第一次,而这中间被浪费掉的改进空间,可能比外界想象的要大得多。

对今天的智能体工程意味着什么

把这几个观察放在一起看,能读出一条更长的脉络。当前绝大多数生产环境中的工具调用型智能体,本质上是“无状态”的执行者:它们每次接到任务都要重新规划步骤、重新摸索软件界面的调用路径,即便前一天刚刚成功处理过几乎一模一样的请求。这不是因为底层模型不够聪明,而是因为系统层面缺少一个能把“这次是怎么做成的”沉淀下来、并在下一次可靠调用的结构。Designer-RSI提出的程序性记忆,本质上是在给智能体补上这一层缺失的基础设施——不是让模型变得更聪明,而是让它变得更“有经验”。这两者是不同的能力维度:前者依赖模型本身的推理能力提升,后者依赖系统能否把过去的成功经验转化为可复用、可信赖的资产。而回归安全机制的存在提醒我们,这层基础设施本身也需要被谨慎对待——一个会自我改写的记忆库,如果没有约束,进步和退步可能同时发生,而系统本身未必能分辨。对于设计这样反馈天然模糊的领域,这种谨慎尤其必要,因为没有一个简单的对错判断能在事后帮你纠错。从76到139个程序、从72.7%到99.3%的跃升,更像是在提示行业:在众多已经部署的工具调用型智能体身上,类似的“经验复利”可能大多还未被真正激活。

值得留意的是,论文给出的两个驱动因素——技能获取与程序优化——分别对应着智能体成长的两条不同路径。前者是“广度”的扩张:遇到此前技能库覆盖不到的新任务,就补上一条新程序,让技能库从76条长到139条;后者是“深度”的打磨:对已经存在的程序反复检验、根据新的成败案例做局部修正,而不是推倒重来。一个只会“广度扩张”而不做“深度打磨”的系统,技能库会越堆越臃肿,但单条程序的可靠性未必跟着提高;反过来,一个只做“深度打磨”却不“广度扩张”的系统,则会在面对新类型任务时无从下手。论文强调两者都对最终提升做出了实质贡献,说明这套框架没有偏废任何一边——这也是为什么最终的胜率提升(61.8%到67.6%)相对稳定,而不是集中在某一类任务上的局部突破。对于任何计划构建长期运行、需要处理海量重复性请求的工具调用型智能体的团队而言,这提供了一个可参考的设计原则:自我改进机制既要能吸纳新经验,也要能安全地修正旧经验,缺一不可。