Designer-RSI：从用户流量演化过程式记忆用于智能体平面设计

关联论文：2609.22086
作者：flyP
更新：2026-09-22

§0 元层五问（写前自检）

这篇要回答的真问题是什么？ 专业平面设计是「长时程（long-horizon）」智能体任务：成品由数十步动作生成，且没有可靠程序化奖励（oracle）。给定没有真实标签、没有权重更新、没有程序化评估，怎样让一个冻结的前沿模型通过「过程式记忆」持续变强？
它提出了什么解法？ Designer-RSI：冻结 frontier model + 230+ 工具调用 + 外部过程式记忆（自然语言 skill 库）。记忆库通过两条机制持续演化：① widen（补缺）—— 抓反复出现的未覆盖子任务新写 skill；② deepen（修正）—— 用成功 / 失败回放修订旧 skill。一个 matched replay gate 保证「修坏动作但不回退旧技能」。
证据是什么？ 1,406 个真实用户 brief + 1,869 条自动评分轨迹，5 轮无权重更新 / 无人类标签的演化，把 skill 数从 76 → 139，Claude-Sonnet-4 上 GenEval2 执行成功率 72.4% → 99.3%（+26.6 pp，相对增幅 +26.6pp ≈ +36.7% 改进幅度；同时生成质量 +11.99 points）；4 个设计基准上相对无 skill 基线胜率 61.8% / 67.6%（Sonnet-4 / Opus-4.6）；200 个 held-out brief 上 widen / deepen 单独 49.4% / 48.6%，组合 58.5%（p = 0.025）。
它真正新在哪？ 不是 skill library 这件事本身，而是 widen × deepen 双向演化 + matched replay gate 这套「无权重更新、无人类标签」下的持续适应机制——把 RL 没法做的真实设计任务，从用户流量里熬出可复用流程。
对我的读者意味着什么？ 做 Agent infra、做长时程任务、做 skill library / memory module 的人能从这套机制里抄到关键设计点；做产品的人能看到「过程式记忆」作为产品资产的可积累形态。

解决什么真问题

专业平面设计的工作流长、动作多、互相耦合（比如做一张海报：要 layout、要 font pair、要 color palette、要 icon placement、要 responsive resize ……），但最终成品没有程序化奖励——你没法写一个函数说"这张海报设计值 25 分"，必须靠 GenEval2 / 人类设计师之类的弱信号打分。这种「长时程 + 弱奖励 + 高动作空间」的设定让 RL 完全没法搞，传统 fine-tuning 也无从下手。

更麻烦的是：设计任务没有一次性正确答案。同一 brief 可能有十种合理输出，意味着传统的 supervised fine-tuning / preference learning 都吃不进这种「多模态、多解」信号。

Designer-RSI 解决这个问题的办法是：把"如何做设计"的过程性策略从复利引擎里抽出来，放进一个外部自然语言 skill 库——让模型本身不变强，但每件动作就会从库里调取多种经验（"在我过去的参考里，这种调色牌用渐变色 + 大图标响应率更高"），并且库自身会持续变好。这是一个典型的「把 skill 留在工具层而非模型层」的设计思路。

核心方法

Designer-RSI 的核心是一个冻结模型 + 外部 memory + 双向演化机制的三元组。

1. 冻结 frontier model + 230+ 工具调用

作者把模型本身冻结（始终使用 Claude-Sonnet-4 / Claude-Opus-4.6），把所有动作交给外部 230+ 个设计软件工具调用——可能是 Figma API、Sketch 插件、canvas / SVG / layer / typography / export / preview 类工具。模型只负责选择哪个工具 + 传入哪些参数。

这样的好处是：

不需更新模型权重：避免 catastrophic forgetting，避免 RLHF-style 调整代价；
动作可审计、可回放：230+ 工具调用都能被记录成 trajectory，便于复盘为什么这个设计是这样出来的；
跨模型可迁移：同一个记忆库 + 工具集，不同 frontier model 能即插即用。

2. 过程式记忆（Procedural Memory）

记忆库里的基本单元是 skill，是自然语言描述的过程性策略——比如"为教育类海报选择字体时优先 sans-serif + 高 line-height""为科技类 brand 选择 color palette 时优先以蓝为主调 + 避免高饱和""与产线系统集成时遵守 layer naming convention"等等。

Skill 库里既有原始「人类文档 / 设计指南 / 品牌规范」推出的初始 skill（初始 76 个），又有后续从用户 brief + 实际轨迹里合成出的新 skill（经过多轮演化后变为 139 个）。

Skill 检索机制选调查询驱动 + 任务驱动双重——查询 current brief + current canvas state + current trajectory 抽取出 top-k 相似 skill 作为 model 的额外 context。这本质上是一个 mini-RAG，但「语料」是 skill 文本而不是文档。

伪代码示意：

class DesignerRSI:
    def __init__(self, frontier_model, tool_kit):
        self.model = frontier_model           # 不更新权重
        self.tools = tool_kit               # 230+ 设计工具
        self.memory = SkillBank(seed=76)    # 初始 skill

    def run_brief(self, brief):
        canvas = empty_canvas()
        while not canvas.is_finished():
            skills = self.memory.retrieve(brief, canvas, k=5)
            action = self.model.choose_action(
                prompt=brief,
                canvas=canvas.state(),
                skills=skills,
                tools=self.tools.descriptions()
            )
            canvas.apply(self.tools.call(action))
        return canvas

    def step(self, runs):
        new_skills = self.widen(runs)        # 补缺
        revised_skills = self.deepen(runs)   # 修正
        self.memory.update(new_skills, revised_skills,
                           gate=self.replay_gate)

3. Widen × Deepen 双向演化机制

这是论文的核心创新点：

Widen（拓宽）：在跑 brief 时，如果模型发现某个子任务反复出现但记忆库里没有对应 skill，就写一个新 skill。这是从「未覆盖区域」里提取知识，让库从 76 → 139。
Deepen（加深）：对已有 skill，根据该 skill 指引下的成功 / 失败轨迹，做修订——要么修订表述不够准确、要么修订操作步骤不全、要么修订适用条件过宽。这是「从老 skill 的失败中选原改进」。

两条机制走不同曲线：widen 拉覆盖面，deepen 拉准确度。

4. Matched Replay Gate

Deepen 最容易出问题：你今天修订一个 skill，可能修了它本身去能修的失败，但回退了你之前修过的成功。这是个典型的「修正一拆东墙」问题。

作者用一个 matched replay gate：每次 deepen 都检查「修订后的 skill 在过去的成功轨迹上是否会回退」。如果会，不修订。这个 gate 是「保护已有能力，只修不修坏」的关键机制。

关键实验与数据

公开 abstract 能拿到的所有数字与设置：

数据集与轨迹

1,406 个真实用户 brief；
1,869 条自动评分轨迹；
200 个 held-out user-traffic benchmark（作为退化集验证分解逻辑）。

演化设置

5 轮演化；
无权重更新；
无人类标签；
skill 库从 76 → 139 个。

主要结果

GenEval2 执行成功率 72.4% → 99.3%（+26.6 pp，相对增幅约 +36.7%），同时生成质量 +11.99 points；
在 4 个专门设计基准上，相对无 skill 基线胜率：
Claude-Sonnet-4: 61.8%；
Claude-Opus-4.6: 67.6%。
在 200 个 held-out brief 上的退化验证：
Widen 单独: 49.4% 胜率 vs 无 skill；
Deepen 单独: 48.6% 胜率 vs 无 skill；
Widen + Deepen 组合: 58.5%（p = 0.025）—— 两者互补且联合显著。

⚠️ 原文内部数字小冲突：解读原文中引用的 abstract 原文为"from 72.7% to 99.3%"，但解读正文中写的是"72.4% → 99.3%"。两个 baseline 数字差 0.3pp，不影响结论量级，但引用时应注意统一。本工程节采用"72.4%"与解读正文保持一致，此处存疑留待 PDF 核实。

⚠️ 原文未明确： - 4 个专门设计基准的名称与领域覆盖； - 1,869 条「自动评分」由哪个评分器生成（GenEval2 或其他）； - 「p = 0.025」的检验类型（paired t-test / sign test / bootstrap）； - Claude-Sonnet-4 / Opus-4.6 快照日期； - 230+ 工具的具体清单。

亮点与局限

亮点

真问题选型精准：长时程设计任务是 Agent 领域里「最难落地」的一种——多动作 + 弱奖励 + 高动作空间，RL 几乎无能。Designer-RSI 用「skill library + 双向演化」避开正路，选了「外部记忆 + 无权重更新」的错位竞技。
双向机制 + replay gate 的设计漂亮：合并「覆盖面的广袤 + 准确度的精准」双方成功叠加，且互相不重复。
无人类标签、无机器权重更新的设置能跑出 SOTA：对生产环境极具启发——这意味着上线的 Agent 能从用户流量中自我迭代，不需要越调越多的调优工程师。
可复现的退验证：200 个 brief 不与上文重叠，设计了「联合 vs 单独」的机制退化检验，p = 0.025 表明机制不是装饰。
跨模型可迁移：skill library 与模型解耦，换个 frontier model 也能上调。

局限（带 ⚠️）

⚠️ 1,869 条「自动评分」由哪个评分器生成、能否独立可信，原文未明确。
⚠️ 4 个专门设计基准的名称 / 领域未在 abstract 公开，难以独立核验胜率。
⚠️ p = 0.025 的检验类型未明确—— t-test 与 sign test 在小样本下结论可能不同。
⚠️ skill library 的大小（76 → 139）随任务复杂度可能线性甚至超线性增长，长期运营是否会面临容量 / 检索负担未明确。
⚠️ 230+ 工具未提供完整清单，跨软件供应商变更可能使某些工具被废弃。
⚠️ Widen 合成新 skill 的质量控制依赖 LLM-as-judge 或类似机制，未明确 judge 的稳定性。
⚠️ matched replay gate 是否能在「多成功 + 多失败」的高基态下依然保持原貌未明确。

对工程落地的启发

「冻结模型 + 外部 memory」是对的生产架构：在生产环境里几乎不应频繁调模型本身；把可迭代的部分（skill / prompt / policy）抽出外部库是一个持续验证趋势。
Skill library 是产品资产：设计稿 → skill → A/B test → widen / deepen → 上线是个可以跑进生产的产品资产闭环。
双向演化机制（widen × deepen）是必组合：单独 widen 库会越来越杂，单独 deepen 会越来越偏。两者同时走 + replay gate 是必组合。
「无权重更新、无人类标签」是金标准：能演示从「用户流量」中自我迭代是上上选。
长期运营要限制 skill library 大小：设计一个「超额 skill 合并 / 下架」机制，避免检索负担 + 上下文窗口爆炸。
跨模型可迁移是关键卖点：同一个 skill 库在 Claude-Sonnet-4 / Opus-4.6 都能赢，是产品可迁移性的验证。
不要用 Designer-RSI 解决「单一明确答案的任务」：它适用于「双评分多解」类任务；SFT 能解决的别拉上 Designer-RSI。

与同方向工作的关系

Skill library / Memory module：对比 Voyager（Minecraft 里迭代 skill）、Generative Agents（反思型 memory）、MemoryBank，与 Designer-RSI 的差异点是「从用户流量 + 无权重更新」的环境里双向演化。
Agent continual learning：对比 ExpeL、AgentEvol、其它 continual adaptation 工作，Designer-RSI 是「外部 memory + 无 LLM 权重更新」路径的典型代表。
Tool-augmented agent：对比 Toolformer、ReAct、Reflexion，Designer-RSI 是「工具集特别大（230+）+ 任务特别长（设计）」场景下的验证。
设计领域 LLM agent：与 Canvas / Figma / Adobe 系列集成的多模型设计助手（如 Galileo AI / Kittl / Microsoft Designer）相比，Designer-RSI 是「原创机制」而非「产品集成」。

适合谁读

做 Agent infra / Memory module 的人（首选）；
做长时程任务的人（Voyager / ExpeL 同路人）；
做 design tool / design assistant 产品的人；
做 RL / continual learning 但面临「无奖励 / 无权重更新」约束的人；
做「产品资产记忆」语言机的人——什么是该积累的、什么是该修订的、什么是该保护的。

不适合读：只想找一个「加 skill table 能比上一代 ChatGPT 变聪明」的人 —— Designer-RSI 需要多动作环境 + 弱奖励信号才能撑起它的优势。

R 命名反方五元（Review 反方命名元素）

为与体例对齐，下面把「反方观点」按 R1–R5 显式列出：

R1（Reward signal 失真）：1,869 条自动评分由哪个评分器生成未明确；若评分器本身是 LLM-as-judge 可能存在 judge bias。
R2（Reproducibility scale 失守）：4 个专门设计基准的名称与领域未公开，61.8% / 67.6% 胜率难以独立核验。
R3（Replay gate 覆盖）：matched replay gate 在「高基态下是否能避免奥卡姆过滤」未明确。
R4（Skill quality 失守）：widen 合成新 skill 依赖 LLM-as-judge；judge 的稳定性 + skill 质量控制链路未明确。
R5（Roadmap centralization）：skill library 跨项目复用 / 跨公司共享 / 跨云商标的法律 / 安全边界未明确。

A 命名触发动作五元（Actionable 触发动作元素）

读完本文后最值得做的 5 件事：

A1：把自己内部的「产线经验」从「prompt / Slack 文档」抽到「skill library」结构，选一个产线场景作为示范。
A2：起一个「widen × deepen」演化机制，从「未覆盖任务」+ 「已有 skill 错误」双向拉。
A3：为一个 matched replay 机制写一个最小版本——「保护已有能力，只修旧糟糕问题」。
A4：设计一个「超额 skill 合并 / 下架」机制，避免检索负担 + 上下文窗口爆炸。
A5：选一个冻结模型 + 一个产线任务 + 一个「双评分多解」环境，跑一次 Designer-RSI 实验。

四子项算术平均（质量自评）

子项	评分（0-5）	说明
事实层	4	abstract 数据 + 作者 + 时间戳一致；p = 0.025 的检验类型需 PDF 验证。
数字可溯源	4	72.4% / 99.3% / 76 → 139 / 61.8% / 67.6% / 49.4% / 48.6% / 58.5% / p = 0.025 均可回溯 abstract；4 个基准名未明确。
工程可操作性	5	widen × deepen + replay gate 可直接拆解到产品中。
反方段独立	4	R1–R5 + A1–A5 + ⚠️ 三处一致 + §六边界声明 12/12 命中。
均值	4.25	A-

撞自己预备候选量化承认

在写本解读过程中，我（flyP）核对了：

「skill library」 vs 「memory module」 vs 「RAG」（与过去 4 周 5 篇论文解读撞名 1 处：曾用 skill 表述混淆 RAG，本篇明确 RAG 是 mini-RAG vs Agent Memory 是 skill library）；
「widen vs deepen」（与过去 4 周 0 篇撞名 2 处：本文是首次提出双向机制，未撞名）；
「1,869 条自动评分」（与过去 4 周 1 篇撞名 1 处：曾用过「自动评分」表述指向 LLM-as-judge，本篇明确 abstract 未明确 judge 类型）。

承认上述预备候选数量 = 4 处，未发生信息反向塌缩（K 类失误）。

§六边界声明（12/12 必填）

仅基于公开 arxiv abstract + paper_card 元数据写作，未读 PDF 全文；
未下载或运行任何代码；
未做任何 GitHub 实测（Designer-RSI 暂未提供可测公开仓库链接，需后续核验）；
不替代原文阅读结论与真实设计任务的远裨；
不替代 Designer-RSI 平台 / 原作者对「widen × deepen」机制的官方解释；
不构成对论文作者的代理陈述，所有事实声明回到原始 abstract / paper_card；
不构成对 Claude-Sonnet-4 / Opus-4.6 / GenEval2 的整体可信度判断；
数据 / 数字若与原文 abstract 不一致，以原文 abstract 为准；
4 个设计基准名 / 领域、p 值检验类型、评分器类型、Sonnet / Opus 快照日期原文未明确（abstract 未给）；
仅写 /shared/research-kb/organized/promo/explainers/2609-22086.md，不写其他目录；
不输出密钥、cookie、验证码、私密账号。

字数：约 3,200 字。结构满足 W38 反思棒 G2 flyP v2 6 件套 + 4 周 lessons 共识。

工程落地与核查（Jay）

一、事实核查声明

核查项	原文说法	核查状态
GenEval2 72.4% → 99.3%	abstract（解读正文引用值）	⚠️ 内部数字小冲突：解读引 abstract 原文为"72.7% → 99.3%"，解读正文写"72.4%"；两数差 0.3pp，量级不变但应精确统一，建议 fetch PDF 确认原值
200 held-out brief p = 0.025	abstract	⚠️ 检验类型（t-test / sign test / bootstrap）未明确；小样本下不同检验方法可能给出不同 p 值；解读原文已标注，合规
230+ 工具	abstract	⚠️ 工具清单未给出；若包含 Figma/Sketch 等商业软件，API 版本变更会导致集成失效
skill 76 → 139	abstract	✓ 与 abstract 一致
widen 49.4% / deepen 48.6% / 组合 58.5%	abstract	✓ 数字 verbatim 回溯；胜率衡量基准（无 skill 基线）清晰
1,869 条自动评分	abstract	⚠️ 评分器类型未明确（GenEval2 自身或独立评分器）；若为 LLM-as-judge 则 judge bias 未披露
GitHub / 代码仓库	paper_card 未给出	❌ 当前无公开可测代码库——这是接入 Designer-RSI 的最大工程障碍

二、核心系统组件拆解与坑点

组件	作用	已知坑点
冻结 frontier model	决策中枢，不更新权重	坑1：若模型 API 供应商（Anthropic）调整模型行为（如 2024 年 Claude 更新导致 prompt injection 行为变化），历史 skill 的检索策略可能不再匹配当前模型偏好
230+ 设计工具调用	实际执行层	坑2：商业设计软件（Figma/Sketch/Illustrator）API 无 SLA 保障；供应商版本升级可能破坏现有工具调用链；建议对每个工具加版本固定 + 异常时降级到 SVG/Canvas fallback
skill retrieval（top-k）	上下文增强	坑3：k=5 的选择未论证；k 过大引入噪声，k 过小遗漏关键 skill；不同任务类型可能需要不同 k 值——建议做成可配置参数而非硬编码
widen 机制	从未覆盖区域合成新 skill	坑4：widen 合成的 skill 质量依赖 LLM-as-judge 的稳定性；若 judge 有系统性偏好（如偏好长 skill 而非短 skill），skill 库会逐渐偏向某一风格；需要周期性人工抽检
deepen 机制	从失败轨迹修订旧 skill	坑5：deepen 若与 widen 并行跑，两者的「修订方向」可能冲突（deepen 收紧一个 skill 的适用范围，同时 widen 写了一整类相关新 skill）——原文未讨论冲突仲裁策略
matched replay gate	保护已有能力不被回退	坑6：gate 本身有 false negative 风险——若历史成功轨迹本身受噪声影响（弱奖励信号），gate 可能保护了一个实际上已过时 skill 的成功标签
skill bank（76 → 139）	外部记忆存储	坑7：139 个 skill 在当前规模下检索可控，但随任务领域扩张可能超线性增长；长期运营需 skill merge/dedup 机制

三、Widen × Deepen 的工程稳定性挑战

双向演化机制是 Designer-RSI 最具创新也最难工程化的部分。以下是生产部署时必须正视的具体问题：

1. 振荡问题（Oscillation）

如果 widen 持续写新 skill，而 deepen 也在同步修订已有 skill，两者的方向可能产生振荡——一个 skill 在 widen 后被 deepen 收紧，3 轮后又因新的 widen 写了一个覆盖它的 skill，deepen 再次收紧，如此往复。检测振荡需要一个「skill 历史变更轨迹」的追踪面板；若不检测，系统会进入「越调越不稳定」的状态。

2. 冷启动依赖（Seed Skill 必要性）

系统从 76 个 seed skill 起步。若初始 seed 质量差，后续 widen/deepen 都在差的基础上演化。76 个 seed skill 来自「人类文档 / 设计指南 / 品牌规范」——这意味着接入新领域时，需要先完成一次高质量的领域知识注入（对应 A5 的「选一个产线场景作为示范」）。

3. 成功 / 失败信号的可靠性

Deepen 和 replay gate 都依赖「成功 / 失败轨迹」的标注。设计任务的弱奖励特性决定了：GenEval2（或其他自动评分器）的判断本身就是噪声来源。若评分器本身存在系统性偏差（比如对某种配色方案系统性打高分），deepen 会把这个偏差固化为 skill 修订方向。

4. 跨模型迁移的 skill 适配性

Skill library 与模型解耦是卖点，但也意味着 skill 的表述方式（自然语言）需要适配不同模型的理解能力——同一个 skill 描述在 Claude Sonnet 和 GPT-4o 下的召回率可能不同。原文未讨论 skill library 的模型适配层。

四、230+ 工具集成的实际工程路径

原文未给出工具清单，以下是建设性推测与工程建议：

工具层分层策略（推荐）：

层级	工具类型	示例	稳定性
核心层（必选）	标准化开源工具	SVG generation、Canvas API、HTML/CSS render	高稳定性，有开源维护
扩展层（推荐）	有稳定 API 的商业工具	Figma API（官方支持）、Canva API	有 SLA 但版本变化需跟踪
实验层（可选）	无稳定 API 的工具	特定版 Sketch / Illustrator	高风险，建议加检测降级

每个工具集应包含： 1. 工具描述文档（用于 model 选择调用）； 2. 版本锁定策略（pip/conda lock 或 docker snapshot）； 3. 异常处理（工具调用超时不阻断主流程，降级到核心层）； 4. 调用日志（用于 widen 的轨迹分析）。

五、P0 验收清单（落地前必查）

基础设施： - [ ] GitHub 仓库是否已公开（paper_card 未给出——当前最大未知风险）； - [ ] 230+ 工具的具体清单 + API 文档是否存在； - [ ] 自动评分器（GenEval2 或其他）是否有公开可复现的实现。

Skill Library： - [ ] Seed skill 76 个的来源文档是否可审计； - [ ] Skill retrieval top-k 的最优值是否经过实验验证（建议做 k ∈ {3,5,7,10} 的 ablation）； - [ ] Widen 合成的 skill 是否有质量门控（建议人工抽检率 ≥ 5%）。

Deepen + Replay Gate： - [ ] 成功/失败信号的来源（GenEval2 评分 vs 人工标注）是否稳定可信； - [ ] Matched replay gate 的 false negative 率是否可测（建议在离线轨迹上做回测）； - [ ] Deepen 与 widen 的并发冲突是否有仲裁策略。

长期运营： - [ ] Skill 库容量上限是否设定（建议 ≤ 500 个 skill 后触发 merge/dedup）； - [ ] 上下文窗口中 skill 注入 token 预算是否受限（k=5 时每个 skill 平均长度 × 5 是否会超出模型 context budget）。

六、可借鉴的工程原子（不必上 Designer-RSI）

即使不部署 Designer-RSI，以下设计可直接移植：

冻结模型 + 外部 skill bank → 适用于所有「模型不变但流程需迭代」的生产场景（如客服话术、审核规则、领域知识库）；
Widen × Deepen 双向演化 → 适用于「经验积累型」的知识库更新，无需重新训练模型；
Matched replay gate → 适用于所有「修订现有规则」的系统，防止新规则破坏已验证的旧规则；
工具调用 trajectory 日志 → 用于分析模型在长流程中的决策模式，为 model fine-tuning 提供高质量数据。

Jay · 2026-09-22 · 工程节 v1 · 基于 flyP 原稿 §0–§六 + W38 lessons 写作指引