你有没有发现：装了 AI 编码助手之后，C 盘像被悄悄吸走了一块？某天一查，C:\ProgramData\WorkBuddy 加用户级 .workbuddy 居然吃了 10 GB 以上。删又不敢删，留着又发慌。
这篇文章不灌鸡汤，直接用一台实测机的脱敏数据，把 AI 助手的"内存占用构造"拆给你看：哪些是值得留的资产与 workspace，哪些是可以随时间清理的记录；再给出一套可执行的 C 盘优化步骤，以及删除 traces / logs 之前必须做的"先筛后炼"。最后用 6 篇 arXiv 前沿论文，给这些"清理直觉"找个理论依据。
提示： 本文所有体积数字均来自 2026-08 在一台 Windows 11 实测机（百 GB 级系统盘）的只读扫描，未删任何文件。数值已做脱敏，统一用"范围 / 定性"描述；不同机器的具体数值会有差异，但结构比例与分类逻辑通用。
一、智能体的内存占用构造（实测拆解）
AI 助手的数据分散在三处，很多人只看到其中一个就以为"它在吃我的盘"：
| 位置 | 角色 | 实测体积（脱敏） | 性质 |
|---|---|---|---|
ProgramData\WorkBuddy\users\<id>\.workbuddy | 运行时 + 技能库 + 记忆 | 约 5–6 GB | 核心资产 |
ProgramData\WorkBuddy\users\<id>\AppData | agent 自己的 SDK 缓存 | 约 3 GB | 混合 |
C:\Users\<你的用户名>\.workbuddy | 用户级技能/记忆/第二套运行时 | 约 5 GB | 核心资产 + 运行时 |
| 小计 | — | 约 13 GB 级 | — |
把 13 GB 级再往下一钻，真相浮现：
| 子项 | 体积（脱敏） | 是什么 |
|---|---|---|
.workbuddy\binaries（python + node 运行时） | 约 1.4 GB | 受管运行时，所有 Python/Node 类技能都靠它 |
.workbuddy\traces | 各 1–1.5 GB | 每次会话的执行轨迹（排障用） |
.workbuddy\logs | 各 1–1.2 GB | 运行日志（启动/调试/连接器鉴权） |
.workbuddy\app 等 | 约 1.7 GB | 应用本体 |
agentAppData（Tencent/Microsoft/更新器/pip） | 约 2.8 GB | 多为可清缓存 |
用户级binaries | 约 2.9 GB | 第二套受管运行时（随更新带入） |
用户级logs + traces | 约 1 GB | 排障日志 |
用户级projects / blobs 等 | 约 1.1 GB | 工作产物 |
关键发现：真正"虚胖"的是 traces + logs，合计约 3–4 GB——它们纯属排障记录，清了不影响任何技能与记忆。
智能体内存占用三层构造（实测约 13 GB 级）：
- ① 资产层（必留）：skills 技能库 · memory 长期记忆 · binaries 受管运行时（两套共约 4.4 GB）· app 应用本体 ≈ 8.7 GB
- ② 工作空间层（视情况留）：projects 项目产物 · workspace 工作区 · blobs 文件块 ≈ 1.1 GB
- ③ 记录层（可随时间的清理）：traces 执行轨迹 · logs 运行日志 · 更新器缓存 · AppData SDK 缓存 ≈ 3–4 GB 可清
资产层是"硬盘上的长期记忆"；记录层是"用过的草稿纸"，可定期清空。
二、哪些该留，哪些该清：用"记忆层级"理论做判据
清理的第一原则其实一句话：**删了会不会让 AI 失忆、会不会让技能消失？**会，就是资产，留；不会，就是记录，可清。
- 🔴 红线（资产）：
.workbuddy\skills、.workbuddy\memory、binaries 运行时 - 🟢 可清（记录）：
traces/logs/@*updater/AppData下的Cache·GPUCache·pip - 🟡 看情况：Tencent 等应用缓存子目录（清
Cache，留FileStorage\File聊天文件）
这套"留资产、清记录"的二分法，和 2023 年以来 Agent 记忆系统的研究高度同构：
| 智能体现实 | 论文里的对应概念 | 论文 |
|---|---|---|
| 资产层（skills/memory/binaries） | 持久记忆 / 归档记忆，长期保留、结构化 | MemGPT、Mem0 |
| 记录层（traces/logs/缓存） | 主上下文 / 暂存上下文，可驱逐、可压缩 | MemGPT、H2O |
| 越用越大 | 记忆若无驱逐/压缩策略，只增不减 | A-MEM、LLMLingua |
一句话打通： 智能体的
.workbuddy就是 AI 的"长期记忆硬盘"，traces / logs 是它写过的"草稿纸"。草稿纸可以定期扔，但记忆硬盘不能动。
三、为什么 traces/logs 会膨胀到数 GB？论文怎么说
实测里 traces 最早的文件停在数月前，从没自动清过。膨胀来自四个叠加因素，而每一层都能在论文里找到"反例解法"：
3.1 没有驱逐策略 → H2O 的启示
Transformer 推理时要把 KV cache 留在显存里，序列越长越爆。H2O 发现：一小撮"重令牌"（heavy hitters）贡献了绝大部分注意力价值，于是只保留它们 + 最近窗口，其余全部驱逐，论文报告最高可提升数十倍吞吐。映射过来：智能体里真正"重"的是 skills 和 memory（必须留），而 traces / logs 是"轻令牌"，理应被定期驱逐。
3.2 不分层 → MemGPT 的虚拟内存
MemGPT 直接把操作系统"虚拟内存"搬进 LLM：快的是主上下文，慢的是外部/归档存储，靠分页在两层间搬数据。智能体把"慢存储"（磁盘上的 .workbuddy + traces）和"快上下文"（运行时内存）混在一起、且从不分页清退，于是慢存储无限膨胀。正确做法正是 MemGPT 的分层：资产放归档层（留），记录放可驱逐层（清）。
3.3 不压缩 → LLMLingua / LLM in a flash
LLMLingua 证明自然语言提示冗余度极高，压缩约 20 倍几乎不掉性能；Apple 的 LLM in a flash 更把"闪存当扩展内存"，用窗口化和行列捆绑减少搬运。两者共同指向一个朴素真理：磁盘是慢速但海量的扩展内存，记录应当按需压缩、分层存放，而不是无脑堆在 C 盘根目录。
3.4 不演化 → A-MEM 的教训
A-MEM 用"卡片盒（Zettelkasten）“法让记忆能动态链接、随新经验演化，而不是只读不写、越堆越旧。反过来想：traces / logs 若从不演化清理，就成了"只写不丢的死记忆”——占空间却无价值。定期清理，本质就是让记录层"演化"。
四篇论文 → 四条清理原则：留重弃轻 · 分层存放 · 定期压缩 · 随新演化。
四、C 盘优化策略与可执行步骤
按"风险从低到高、收益从稳到猛"排序，下面每一步都给出可执行操作。注意：涉及个人目录删除，最终请在资源管理器手动 Shift+Delete，Agent 不会替你真删。
| 策略 | 对象 | 实测可省（脱敏） | 风险 | 操作 |
|---|---|---|---|---|
| ① 回收站 | 已删文件 | ~0.6 GB | 无 | 桌面右键"清空回收站" |
| ② WB 日志 | traces + logs | ~3–4 GB | 无（不影响技能） | 删.workbuddy\traces、.workbuddy\logs（两处） |
| ③ 应用缓存 | Tencent/Microsoft/kingsoft 的Cache 子目录 | 数 GB | 低 | 只删Cache/GPUCache/Code Cache，勿动聊天 File |
| ④ 更新器缓存 | @genieworkbuddy-desktop-updater 等 | ~1 GB | 无 | 资源管理器Shift+Delete |
| ⑤ WinSxS | 被取代的系统组件 | 1–3 GB | 需管理员 | 管理员 PowerShell：DISM /Online /Cleanup-Image /StartComponentCleanup |
| ⑥ 系统还原 | 旧还原点/卷影副本 | 数 GB | 需管理员 | 系统保护 → 删除旧还原点 |
| ⑦ 自查大文件 | Downloads / Videos | 视情况 | 无 | 移动或归档到非系统盘 |
红线提醒：
ProgramData\WorkBuddy\users\<id>\.workbuddy\binaries（约 1.4 GB）和C:\Users\<你的用户名>\.workbuddy\binaries（约 2.9 GB）是受管运行时，不是缓存！看着也"大"，但删了所有 Python/Node 类技能立刻失效，必须留。
管理员 PowerShell 跑 WinSxS 清理（最省心的一步系统级瘦身）：
# 先看能回收多少
DISM /Online /Cleanup-Image /AnalyzeComponentStore
# 删除被取代的旧版本（保留回滚能力）
DISM /Online /Cleanup-Image /StartComponentCleanup
# 更狠：放弃回滚，省最多（谨慎）
DISM /Online /Cleanup-Image /StartComponentCleanup /ResetBase
五、删前必做：traces + logs 的「先筛后炼」（从执行轨迹里捞资产）
很多人删 traces / logs 是"全量删"——但这是浪费。数 GB 里 99% 是成功路径的噪声（每任务记完整执行树），价值密度极低；真正值得留的，是里面筛出的几十条"失败教训 + 高频任务框架"。正确姿势是先筛后炼，捞完再删。
5.1 两判据（定义"精华"的两条规则）
- 失败记录 → 教训（避免重复）：负样本比成功样本珍贵——成功路径千篇一律、失败各有各的坑。把失败原因回灌到长期记忆的"失败"区，下次自动绕开。
- 高频任务 → 框架（SOP/骨架）：高频任务每次从头探索 = 重复造轮子，应提炼成可复用"大概框架"，回灌到技能 / SOP。
5.2 精确信号（避坑）
- 真失败 =
"status":"error"（trace 的 span 层）。千万别 greperror/failed—— 噪声极大，几乎所有 trace 都含"error"字段名，会把数千文件全判成失败。 - logs 无 status 字段：仅作体积 + 近似错误行数参考，不按"失败"自动归类。
5.3 零 token 预筛（关键）
规则层只做 grep / 统计，绝不把数 GB 喂模型；仅把 <10KB 的小失败文件列为下钻候选，下钻时才可能需要模型。
预筛脚本的核心思路（通用示意，不含任何机器路径）：
# 预筛：精确失败信号 + 高频任务统计，绝不把数GB喂模型
import os, re
STATUS_ERROR = '"status":"error"' # 真失败，非 grep error（噪声极大）
SKILL_TOKENS = ["pdf", "ima", "skill-creator", "novel", "tencent-docs"] # 高频词启发式
# 1) 精确失败：命中 status:error 即计数
# 2) 高频：对小文件统计技能名提及频次
# 3) 仅把 <10KB 的小失败文件列为下钻候选，下钻才进模型
实测：一台机器 traces 数千文件里，真正失败轨迹仅数百个；高频任务信号清晰显示某技能被单机高频调用（上千次），正是值得提炼成 SOP 的候选。
5.4 与论文同构
- 先筛后炼 = A-MEM「从原始经验提炼可演化记忆」的工程最小实现；
- 只留失败教训 / 高频框架 = H2O「保留重令牌、驱逐轻令牌」；
- 记录层压缩清理 = LLMLingua「压缩冗余」+ LLM in a flash「磁盘即扩展内存」；
- 结构化回灌 = Mem0「生产级持久记忆」。
一句话判据： 删了它，AI 下次还会不会重新需要它？会 = 精华 = 进记忆；不会 = 记录 = 该清。
六、智能体怎么帮你清理：cdisk-health-scan 实战
智能体自带一个只读诊断技能 cdisk-health-scan：说一句"扫描 C 盘"，它跑只读脚本、同轮对话内给出分档报告（🟢可清 / 🟡看情况 / 🔴别动）+ 每个可删项的完整路径，全程不删任何文件。
它已内置：自动统计 traces / logs 并标为可清，WinSxS 走 DISM 轻量分析而非全量递归卡死；并提供**"删前自动捞"可选子流程**——跑上面的预筛脚本（只读、零 token），先捞失败教训 / 高频框架，再让你手动删原始日志。
一次扫描的输出片段（脱敏节选）：
C: 系统盘长期低于 15% 警戒线
WorkBuddy traces+logs: TOTAL ~3-4 GB [GREEN] safe to delete
===== 分档报告 =====
🟢 可立即清理: traces/logs + 更新器缓存 + Temp
🟡 看情况: 应用 Cache 子目录
🔴 千万别动: binaries 运行时 + skills/memory
把可删路径整理成纯文本清单，Ctrl+A 全选复制到资源管理器地址栏即可精准定位（路径已脱敏，用占位符代替真实 id / 用户名）：
C:\ProgramData\WorkBuddy\users\<id>\.workbuddy\traces
C:\ProgramData\WorkBuddy\users\<id>\.workbuddy\logs
C:\Users\<你的用户名>\.workbuddy\traces
C:\Users\<你的用户名>\.workbuddy\logs
C:\Users\<你的用户名>\AppData\Local\@genieworkbuddy-desktop-updater
七、参考论文（arXiv 前沿）
| 论文 | 作者 | arXiv | 年份/会议 | 与本文关系 | 链接 |
|---|---|---|---|---|---|
| MemGPT: Towards LLMs as Operating Systems | Charles Packer et al. | 2310.08560 | 2023 | 层级虚拟内存/记忆分层；支撑"资产层 vs 记录层"划分 | 链接 |
| Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory | Prateek Chhikara et al. | 2504.19413 | 2025 | 生产级持久记忆，省上下文 token；支撑"记忆是资产，应结构化保留" | 链接 |
| A-MEM: Agentic Memory for LLM Agents | Wujiang Xu et al. | 2502.12110 | NeurIPS 2025 | 动态演化记忆（Zettelkasten）；支撑"记录应随新经验演化、先筛后炼" | 链接 |
| H2O: Heavy-Hitter Oracle for Efficient Generative Inference of Large Language Models | Zhenyu Zhang et al. | 2306.14048 | 2023 | KV cache 驱逐：保留重令牌、驱逐其余；类比"只留核心资产，清记录" | 链接 |
| LLM in a flash: Efficient Large Language Model Inference with Limited Memory | Keivan Alizadeh et al. | 2312.11514 | 2023 | 闪存当扩展内存 + 窗口化/捆绑；支撑"磁盘分层 = 慢速扩展内存" | 链接 |
| LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models | Huiqiang Jiang et al. | 2310.05736 | EMNLP 2023 | 提示压缩约 20 倍；支撑"上下文压缩 = 定期清理冗余记录" | 链接 |
留给你思考的三个问题
- 如果给智能体加一个"自动驱逐"策略（类似 H2O 只留 heavy hitters、MemGPT 分页），它的 traces / logs 该按时间清、按大小清，还是按访问热度清？哪种最不伤排障能力？
- 你手机/电脑上还有哪些"AI 产物的草稿纸"（聊天导出的临时文件、模型缓存、日志）在悄悄吃盘？能不能也用"资产 vs 记录"二分法统一治理？
- 当 AI 的"长期记忆"越存越多，会不会像人类一样出现记忆过载？A-MEM 的"动态演化"是不是比"无限保留"更接近理想状态？你怎么看"该忘的忘掉"这件事？
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/Helen_Liang_1989/article/details/163856005
