不是所有经验都该写进权重：GUI智能体的经验分流法则
假设你在训练一个手机操作智能体。它跑了一堆任务，攒下了一批操作轨迹——成功和失败的都有。现在你要让它从这些经验中学习，有两条路：
目录
不是所有经验都该写进权重：GUI 智能体的经验分流法则
一个反直觉的实验结果
假设你在训练一个手机操作智能体。它跑了一堆任务，攒下了一批操作轨迹——成功和失败的都有。现在你要让它从这些经验中学习，有两条路：
第一条路，微调——把经验写进模型权重，让它"内化"这些知识。 第二条路，检索——把经验存进一个笔记库，每次执行任务时把相关笔记塞进 prompt。
你会选哪条？
如果你关注过近两年的文献，会发现两条路都有人走，而且结论互相矛盾。有人说微调好，有人说检索好，还有人说同一个技能表示在这个任务上有用在那个任务上有害。
这篇论文（arXiv: 2610.01787）给出了一个让人拍案的答案：问题本身问错了。
因为"一条轨迹"不是一个不可分割的单位。一条轨迹里至少混着四种完全不同的东西，它们各自该去的地方也不一样。把整条轨迹塞进同一个目的地，就像把衣服、碗碟、书本、工具全扔进同一个柜子——能塞进去，但取出来的时候一团糟。
四种经验，四种命运
论文把智能体的经验拆成四个组件：
1. 定位器（Locators）——"某个按钮在屏幕的什么位置"
比如：在天气 App 的主页上，"城市管理"按钮的点击坐标是 (770, 84)。
这是一种静态映射：给一个应用+元素名，返回一个位置。它几乎不依赖于当前状态——"城市管理"按钮在天气 App 主页上的位置，不管你是在添加城市还是删除城市，它都在那里。
2. 流程（Procedures）——"做完 A 之后该做 B，再之后该做 C"
比如：在天气 App 里，点完"城市管理"→选"深圳"→下一步通常是"如：一般"。
这是一种操作序列：它高度依赖于你当前在哪个任务、哪个界面。换一个任务，同样的三步序列可能完全不对。
3. 状态事实（State Facts）——"执行某个操作前，某个条件必须满足"
比如：在提交答案之前，答案字段必须已经填了任务要求的值。
这是一种前置条件：它只在特定状态下有意义。如果当前状态不匹配，这个事实就是废话。
4. 教训（Lessons）——"在这个状态下，做 A 会失败，应该做 B"
比如：在答案页的某个状态下，别点"如：一般"，应该点"提交答案"。
这是一种偏好修正：它记录的是"在特定状态下，哪个动作更好"。
两个属性决定一切
论文的核心洞察是：每个组件该去哪里，由两个可以在训练前就测量的属性决定。
属性一：复现率（Recurrence）——这个组件的 key 在不相关任务中出现的频率有多高？
定位器的 key 是"应用+角色+元素名"。"天气 App 的城市管理按钮"这个 key，在添加城市、删除城市、查看天气等完全不相关的任务中都会出现。复现率高。
流程的 key 是"三个连续操作目标"。某段三步操作序列通常只在特定任务族中出现。复现率低。
属性二：状态条件性（State-conditionality）——这个组件的有用性有多依赖当前状态与来源状态的匹配？
定位器几乎不依赖状态——按钮位置不会因为你换了任务就变。状态条件性低。
流程高度依赖状态——同样的三步序列，换一个任务就完全不适用。状态条件性高。
把四个组件画在这两个属性构成的平面上，它们整整齐齐地分布在四个象限：
| 组件 | 复现率 | 状态条件性 | 最佳目的地 |
|---|---|---|---|
| 定位器 | 高（0.39） | 低（0.10） | 权重 |
| 教训 | 高（0.45） | 中（0.53） | 权重 |
| 状态事实 | 高（0.32） | 高（0.56） | 上下文 |
| 流程 | 低（0.05） | 高（0.66） | 上下文 |
为什么会这样？
用一个类比来理解。
想象你在一家新公司上班。你需要学习的东西有两类：
第一类是"公司常识"——茶水间在哪、打印机怎么用、Wi-Fi 密码是多少。这些东西天天用、到处用，而且不依赖于你当前在做什么项目。你应该把这些记在脑子里（写进权重），因为每次需要都去查笔记太慢了。
第二类是"项目特定流程"——某个项目的部署步骤、某个客户的特殊要求。这些东西只在特定场景下有用，换一个项目就完全不适用。你应该把这些写在便利贴上贴电脑屏幕上（留在上下文），因为它们太依赖具体场景了，记在脑子里反而会干扰判断。
这就是论文发现的核心机制：
权重擅长吸收高复现、低状态条件的信息——因为权重是全局的，不依赖于当前状态。一个按钮的位置不管在什么任务里都一样，写进权重后每次都能用。而且，高复现意味着同一个信息在训练中被反复强化，权重学得最牢。
上下文擅长携带高状态条件的信息——因为上下文可以按当前状态检索。你不需要把"在状态 A 下做 X，在状态 B 下做 Y"全记在脑子里，你只需要在遇到状态 A 时检索到对应的笔记。状态条件越强，越需要精确匹配，而检索可以做到精确匹配，权重做不到。
一个精妙的验证：笔记读取率
论文设计了一个巧妙的探针实验来验证这个机制。
在训练前，他们测量了"给智能体一条笔记，它有多大概率改变决策"。结果是 42%——笔记确实有用。
然后，他们把同样的组件写进权重，再测一次。结果：
- 定位器的笔记读取率从 48% 降到 16%——权重已经吸收了这些信息，笔记变得多余了
- 教训的读取率也大幅下降——同样被权重吸收
- 但流程的读取率只从 33% 降到 22%——权重没能完全吸收流程，笔记仍然有价值
这就像：你每天走同一条路回家，一个月后你不需要 GPS 了（高复现→权重吸收）；但你偶尔去一个陌生的地方，每次还是需要导航（低复现→上下文保留）。
谁产出经验，谁消费经验
论文还有一个重要发现：笔记可以跨模型传递，微调不能。
用 8B 模型产出的流程笔记给 32B 模型用，32B 模型仍然受益（+3.2 分）。但用 8B 模型的轨迹微调 32B 模型，反而有害（-1.4 分）。
为什么？因为笔记传递的是信息（"在这个状态下应该这样做"），而微调传递的是策略（"遇到类似情况时倾向于这样做"）。不同模型的策略不同，强行把一个模型的策略塞给另一个模型，会造成"策略失配"。
更精确地说，论文区分了两个差距：
- 信息差距：生产者知道但消费者不知道的东西。这个差距越大，上下文路线越有用——因为笔记填补了信息空白。
- 策略差距：两个模型在同一个状态下会做不同动作。这个差距越大，权重路线越有害——因为微调让消费者学了一个不属于它的策略。
实践含义：如果你想用一个更强的模型来帮助你的小模型，把强模型的笔记给小模型用（上下文路线），不要直接微调。如果你要微调，用小模型自己的成功轨迹——论文证明，"自己的练习"和"学习别人的经验"在权重路线中几乎等价（差距 <1.1 分）。
升级模型后怎么办？
这个发现还有一个推论：当你升级模型时，笔记库可以保留，权重需要从头来。
从 8B 升级到 32B，8B 产出的笔记仍然给 32B 带来 +3.2 分的提升，但 8B 的微调权重对 32B 是 -1.4 分。
因为笔记携带的是信息（与模型无关），权重携带的是策略（与模型强绑定）。换了模型，策略就失效了，但信息仍然有效。
这就像一个员工离职了，他写的文档可以留给下一个员工，但他练出来的肌肉记忆带不走。新员工需要重新练习，但不需要重新收集信息。
路由规则的实战表现
把上面的发现总结成一条规则——用复现率和状态条件性两个属性预测每个组件该去哪里——然后在未见过的骨干网络上测试：
24/24 个格子全部预测正确。
更实际的数据：
- 路由 vs 全部进上下文：平均 +4.4 分（MobileGym），+4.1 分（AndroidWorld）
- 路由 vs 全部进权重：平均 +7.8 分
- 路由 vs 最佳整条轨迹基线（三次重试）：+9.3 分
- 路由 vs 反向分配（故意把该进权重的塞进上下文、该进上下文的塞进权重）：+8.9 分
两个干预实验
论文还做了两个精巧的干预实验来验证因果性：
干预一：增加训练剂量。把流程组件复制 8 份再微调（模拟高复现的效果），流程的路由增益从 -4.2 升到 -0.8，确实向权重方向移动了。但 8 份还不够跨越边界——这验证了边界不是任意的，它对应着真实的复现率阈值。
干预二：去掉状态条件。把状态事实和流程的笔记改成"只按任务文本检索，不按状态匹配"，效果分别掉了 3.4 和 3.9 分。这证明上下文路线的优势恰恰来自状态匹配——不是笔记内容本身有多好，而是"在正确的状态下检索到正确的笔记"这个机制本身在起作用。
工程启示
这篇论文对 AI 从业者有几个直接的实践指导：
1. 不要把经验当作一个整体。在自改进循环中，把轨迹拆成组件再路由，比整条轨迹塞进同一个目的地好得多。论文的组件拆分是针对 GUI 智能体的，但思路可以推广：任何自改进系统都应该问自己——我的经验里哪些是"常识"（高复现、低状态依赖），哪些是"场景知识"（低复现、高状态依赖）？
2. 上下文和权重不是竞争关系，而是分工关系。过去的研究争论"微调好还是检索好"，这个争论的前提就是错的。正确的问法是："这个特定的信息该去哪里？"——答案取决于信息的复现率和状态条件性。
3. 跨模型协作时，传笔记不传权重。如果你想用大模型帮助小模型，把大模型的笔记给小模型用，不要直接微调。微调只在"自产自销"时有效，而且大部分收益来自练习效应，不是来自学习别人的经验。
4. 升级模型时保留笔记库。笔记是模型无关的，权重是模型绑定的。换模型时，笔记库可以直接迁移，权重需要从头训练。
5. 两个属性可以在训练前测量。你不需要先训练再判断——复现率和状态条件性都可以从经验池本身测量，在做出任何训练决策之前就能知道每个组件该去哪里。这意味着路由规则可以作为一个预训练决策工具，省掉大量的试错成本。
一个更深的思考
这篇论文让我想到一个更普遍的模式：很多争论之所以无法解决，是因为争论双方在错误的粒度上讨论问题。
"微调好还是检索好"这个问题无法回答，因为"一条轨迹"不是一个有意义的单位。只有把轨迹拆成组件，在每个组件上分别问这个问题，才能得到有意义的答案。
这和"判断-闸门解耦"的谱系是同构的：不要在聚合层面做判断，要在组件层面做判断。聚合层面的结论依赖于混合比例，组件层面的结论才是稳定的。
论文的标题说得好——Not All Experience Belongs in the Weights。这句话可以推广为一个更一般的原则：不是所有经验都属于同一个地方。经验的价值不在于它"好不好"，而在于它"是什么类型"——不同类型的经验有不同的最佳存储位置。
人类其实早就知道这个道理。我们不把电话号码和骑自行车的技能存在同一个地方——前者是声明性记忆（可以口头传授），后者是程序性记忆（只能自己练习）。我们不把"巴黎是法国首都"和"今天下午三点开会"存在同一个地方——前者是长期记忆，后者是工作记忆。
这篇论文做的，是把这个古老的认知科学洞察，在 AI 智能体上重新发现了一遍。
论文：Not All Experience Belongs in the Weights: Component Routing for Self-Improving GUI Agents arXiv：2610.01787 作者：Beining Wu, Zihao Ding, Jun Huang 代码：论文声明 will be released，目前尚未公开