AI Agent 使用场景

用 DuMate 整理百度网盘 10TB+ 全盘

一个人不会去做的事，AI Agent 做了：扫描 33 万文件、识别删除 1,092 GB 重复目录、归档 10 万手机照片

333K
扫描文件
1,092 GB
重复目录清除
103K
手机照片归档
7 阶段
完整流程

1 建立能力 OAuth

Agent 发现没有现成的百度网盘操作技能，于是先创建了一个技能，通过 OAuth 设备码授权获取 API 凭据。
  • 封装 API 凭据和调用方法为可复用技能
  • 支持文件列表、删除、移动、创建目录等操作
  • 为后续所有操作奠定基础
关键决策：把 API 凭据封装成可复用技能，而不是写一次性脚本。

2 整理手机备份 103,486 文件

/来自：iPhone 里 103,486 个照片视频全部散落在根目录，没有任何分类。
  • 读取每个文件的创建/修改时间
  • 按年月自动创建 89 个月份目录
  • 将 103,486 个文件逐一移动到对应年月目录
  • 最终根目录 0 个散落文件
挑战：百度网盘移动接口格式特殊，含 & 的路径需 URL 编码，中文路径需逐个执行。

3 整理电子书 24,158 文件 1.02 TB

/Book 目录来源混杂，大量重复。不是自动删除，而是生成交互式 HTML 让用户选择。
  • MD5 去重：165 组重复，6.29 GB
  • 生成交互式去重 HTML（checkbox 多选）
  • 用户选择后删除 147 个文件
  • 合并 /Book_Sale、/Book_New 到 /Book
  • 生成 book_index.html 导航页面
用户反馈"我就是要多选保留"→ 从 radio 改为 checkbox。AI 不替用户做保留/删除的决定。

4 整理软件和工作备份 434 GB

跨目录 MD5 去重，按文件大小分 4 级生成去重 HTML。
  • /Soft：7,360 文件，365 GB
  • /工作备份：15,601 文件，69 GB
  • 257 组重复，可回收 37.92 GB
  • 4 级分层：Tier1 >1GB / Tier2 100MB-1GB / Tier3 10-100MB / Tier4 <10MB
  • Tier1+Tier2 已删除 57 个文件，释放 32.91 GB
踩坑：扫描超时重跑导致同文件多次记录（6,527 组假重复）→ 修复：扫描数据必须去重后再分析。

5 全盘扫描摸底 9.64 TB

41 个根目录逐个深度扫描，每个文件记录路径、大小、MD5、fs_id、时间。大目录需多轮断点续跑。
目录文件数大小
/Video60,6534.90 TB
/我的资源37,8061.49 TB
/Book24,1581.02 TB
/来自：iPhone111,264635 GB
/Soft7,360365 GB
/Games30,706324 GB
其余 35 个目录61,031~905 GB
合计333,0789.64 TB
差值分析：扫描 9.64TB vs quota 10.655TB，差 1.014TB → 文件历史版本（API 不可达）。

6 全盘去重方案 1,092 GB

从"逐文件去重"到"目录级去重"——用户洞察驱动算法升级。
  • 初步：12,172 个 MD5 重复组，1.38 TB（97% 属有意重复）
  • 分类：A 类同目录 / B 类同内容包 / C 类同根目录 / D 类跨根目录
  • 目录级子集分析：961 个完全子集目录，1,086 GB
  • 精确到"完全相同目录"：663 组，1,092 GB
  • 生成交息式 HTML：勾选=保留 / 不勾选=删除
用户洞察："如果一个文件重复了，连带这个文件所在目录的其他文件都全部是重复的，那就不是有意重复。"

7 执行删除 10,680 文件

1,138 个目录、10,680 个文件全部删除，0 失败。
  • 批量删除 + 逐个删除 + 进度文件断点续跑
  • 逻辑释放 1,092 GB，实际配额释放 ~342 GB
意外发现：百度服务端去重——相同 MD5 共享存储块，删除副本不释放空间。只有删掉某 MD5 的最后一个副本才释放。

全程关键数据

网盘总容量
18.0 TB
整理前已用
10.66 TB
整理后已用
9.59 TB
实际释放
~342 GB
重复目录清除
1,092 GB
方法论：如何用 AI Agent 管理海量数据
🔧

1. 先建能力，再干活

不要一上来就让 AI 做事。先确认有没有工具、权限、API，没有就先创建。OAuth 授权、技能封装是后续一切的基础。

📊

2. 先摸底，再行动

不要凭印象判断。全盘扫描 333,078 个文件、9.64TB，拿到精确数字后再做决策。扫描结果保存为本地 JSON，可反复分析。

🔄

3. 断点续跑是必须的

10 分钟 bash 超时、API 限速、网络波动——大数据量操作不可能一次完成。每个长任务都要有进度文件，支持中断后继续。

🖐️

4. AI 不替用户做决定

去重不是自动删除，而是生成 HTML 让用户选择。从 radio 改 checkbox，从单页改分级——每次都根据用户反馈调整。

📐

5. 分级分批执行

257 组重复太多？拆成 4 级。1,092 GB 太大？按大小分层。先处理高价值的，低价值可以以后再说。

💡

6. 用户洞察比算法更重要

"目录级完整性判断"把去重从"逐文件"提升到"逐目录"，大幅提高准确性和可操作性。这个洞察来自用户，不是 AI。

✅

7. 验证每一步

扫描数据去重后再分析、删除前后核对 quota、确认分页无遗漏、交叉验证 HTML 选择与实际删除——每步都校验。

🏗️

8. 理解平台底层机制

百度网盘服务端去重：相同 MD5 共享存储块，删除副本不释放空间。不知道这一点会困惑于"删了 1TB 为什么只释放 342GB"。

⚡

9. API > 浏览器 > 手动

文件列表和删除用 API；去重选择用 HTML 交互页面；文件历史版本 API 不可达，需网页操作——工具选择影响效率。

🎯

10. 做完 ≠ 做好

删了 1,092 GB 但发现实际释放为 0，工作没有停止——继续分析原因，找到真正能释放空间的途径，为下一步提供方向。

📌 下一步可做的事

  1. 清理文件历史版本 ~1,014 GB — 需通过百度网盘网页版操作，API 不可达
  2. /Soft 过时软件清理 ~50-100 GB — Adobe 旧版等已识别
  3. /Soft Tier3+Tier4 去重 — 1.58 GB + 0.11 GB，待用户处理
  4. 剩余 12,172 个 MD5 仍有 2+ 副本 — 逻辑 1.4 TB，可在需要时进一步精简