1. 一次删库事件的完整复盘1.1 事件还原103秒到底发生了什么先把时间线拉直。某位开发者在一台Windows机器上使用Claude Code作为编码助手项目目录里存在一个指向其他位置的目录联接Directory Junction。Agent在获得文件操作权限后执行了一批清理类命令103秒内删除了约4.8万个文件随后发现Git仓库目录也一并消失——.git文件夹被递归删除意味着版本历史、分支、暂存区全部归零。这里有几个关键事实需要拆开看删除速度4.8万个文件/103秒 ≈ 每秒466个文件。这个速度说明删除操作不是逐个文件走图形界面确认而是通过命令行递归删除类似rmdir /s /q或Remove-Item -Recurse -Force批量执行的。Git也没了.git目录本质上就是一堆普通文件和目录递归删除不会区分它是版本库还是普通文件夹。一旦父目录被递归清理.git首当其冲。Directory Junction的角色这是Windows上的目录联接类似Linux的符号链接但更透明。很多工具在遍历目录时会把Junction当作真实目录进入导致删除范围远超预期——你以为只删了项目目录实际上通过Junction把另一个盘的数据也带走了。注意Directory Junction在Windows上创建后资源管理器里显示为普通文件夹图标带一个小箭头但很多命令行工具和脚本不会主动识别它递归操作时会直接穿透。1.2 为什么这件事值得每个用Agent的人警惕很多人看到这条消息的第一反应是这开发者自己没管好权限。但我想说的是这件事暴露的是Agent类工具在文件系统操作上的系统性风险不是某一个人的疏忽。传统IDE的重构、删除操作通常有明确的UI确认、有撤销栈、有回收站兜底。而Agent执行的是自然语言驱动的命令它的确认往往只是一句我将要删除这些文件是否继续你点了同意它就可能执行一条覆盖范围远超你想象的递归命令。更麻烦的是Agent的上下文里可能并不清楚Junction的存在。它看到的是一个目录树遍历时Junction被展开它以为这些都是项目内的文件于是放心地批量清理。这不是模型坏而是它对Windows文件系统特性的理解存在盲区。我个人的判断是只要Agent拥有文件系统的写权限就必须假设它某一天会执行超出预期的删除操作。这不是对工具的不信任而是对自然语言→命令这条链路不确定性的基本尊重。1.3 本文适合谁读如果你符合以下任意一条这篇内容对你有直接价值正在或准备在Windows上使用Claude Code、Cursor、各类Agent编码工具项目目录里存在Junction、符号链接、映射盘、网络驱动器用Git做版本管理但没想过.git目录本身也可能被误删想建立一套Agent操作安全边界的实操规范。下面我会从原理、复现、防护、恢复四个层面展开尽量给出可以直接抄作业的方案。2. 核心原理拆解Junction、递归删除与Git的脆弱性2.1 Directory Junction到底是什么Windows上的目录联接Directory Junction是一种重解析点Reparse Point。你可以把它理解为一个传送门C:\project\data这个路径看起来是个普通文件夹但实际存储位置可能在D:\bigdata\dataset。创建方式很简单mklink /J C:\project\data D:\bigdata\dataset这条命令执行后访问C:\project\data\file.txt实际读写的是D:\bigdata\dataset\file.txt。关键特性特性说明对用户透明资源管理器、多数程序都当作普通目录跨卷支持可以指向不同盘符删除行为特殊删除Junction本身不会删目标内容但递归删除会穿透工具识别不一dir /a能看到JUNCTION标记但很多脚本不检查最后一条是重点。当你执行Remove-Item -Recurse -Force C:\project时PowerShell会进入data目录把它里面的文件全部删掉——删的是D:\bigdata\dataset里的真实数据。而Junction本身在父目录被删时也会被移除但目标数据已经没了。2.2 递归删除为什么这么快、这么彻底以PowerShell为例一条典型的递归删除命令Remove-Item -Path C:\project -Recurse -Force -ErrorAction SilentlyContinue拆解一下参数-Recurse递归进入所有子目录-Force强制删除只读、隐藏文件.git里的对象文件很多是只读的-ErrorAction SilentlyContinue遇到错误不中断继续删下一个。这三个参数组合在一起就是一台推土机。-Force让.git目录里的只读对象文件无法阻挡删除-ErrorAction SilentlyContinue让个别文件被占用时也不影响整体进度。4.8万个文件103秒平均每个文件处理时间约2毫秒。这个速度只有在SSD批量删除无UI确认的条件下才能达到。如果是机械硬盘或者每个文件都弹确认框时间会拉长几十倍。2.3 Git仓库为什么一删就没很多人对Git有个误解以为.git是某种特殊的、受保护的数据。实际上.git就是一个普通目录里面装着objects/所有提交对象、树对象、blob压缩存储refs/分支和标签的引用HEAD当前分支指针config仓库配置index暂存区。这些全是普通文件。递归删除不会因为它是Git仓库就手下留情。删完之后git status会直接报not a git repository因为.git目录不存在了。本地Git仓库的唯一副本就是.git目录本身。如果你没有远程仓库或者远程仓库不是最新的那这次删除就是永久性的。这也是为什么事件里Git也没了比4.8万个文件没了更让人心疼——代码文件可能还有备份但提交历史、分支结构、未推送的commit全在.git里。2.4 Agent为什么会执行这种操作Claude Code这类Agent的工作模式是接收自然语言指令→规划步骤→调用工具读写文件、执行命令→观察结果→继续。风险点在于指令理解偏差用户说清理一下项目里的临时文件Agent可能理解为清理项目目录下所有非源码文件范围被放大。目录遍历不识别JunctionAgent的文件遍历工具如果基于普通递归会把Junction目标当作项目内文件。缺少删除前的影响面评估成熟的删除操作应该先列出将要删除的文件清单、统计数量、识别Junction和符号链接但很多Agent直接执行。权限过大Agent以当前用户权限运行能删的东西和你能删的一样多。实操心得我在测试各类Agent工具时会专门建一个蜜罐目录里面放一个Junction指向一个装满测试文件的目录。观察Agent在执行清理任务时会不会穿透Junction。这个测试帮我筛掉了好几个看起来聪明但文件操作很莽的工具。3. 防护体系搭建让Agent删不掉不该删的东西3.1 第一道防线Git仓库的异地备份最直接、最有效的防护是让.git目录在任何时候都有至少一份异地副本。方案AGit远程仓库推荐# 每次开始工作前先推送一次 git add -A git commit -m checkpoint before agent session git push origin main关键点在让Agent执行任何批量操作之前确保所有commit都已推送。未推送的commit只存在于本地.git删了就没了。方案B定时镜像备份如果项目不方便推远程可以用脚本定时把.git目录复制到另一个位置# 每天定时执行把.git镜像到备份盘 $source C:\project\.git $dest E:\git-backup\project-git robocopy $source $dest /MIR /R:1 /W:1robocopy /MIR会做镜像同步第一次全量后续增量。/R:1 /W:1表示失败只重试1次、等待1秒避免卡住。方案CGit bundle单文件备份git bundle create project-backup.bundle --all这条命令把整个仓库所有分支、所有历史打包成一个文件。把这个bundle文件放到安全位置即使.git被删也能用git clone project-backup.bundle恢复。我个人的习惯是方案A为主方案C为辅。每次重要节点推远程同时生成一个bundle丢到网盘或移动硬盘。3.2 第二道防线文件系统层面的保护关闭Agent对Junction的穿透能力Windows上可以用fsutil查看重解析点fsutil reparsepoint query C:\project\data但更实用的是在Agent工作目录里避免使用Junction。如果必须用考虑改用符号链接mklink /D并配合工具的白名单机制或者干脆把外部数据放在项目目录之外通过环境变量引用。使用只读挂载或权限限制对于确实需要Agent访问但不希望被删除的目录可以右键目录→属性→安全→高级→禁用继承→删除写入和修改权限只保留读取和执行。这样即使Agent执行递归删除遇到无权限的文件会报错-ErrorAction SilentlyContinue会跳过但至少不会删掉。注意这个方法对-Force参数无效因为-Force主要针对只读属性不是NTFS权限。要真正挡住需要NTFS权限层面的拒绝。启用Windows文件历史或卷影副本# 启用卷影副本需要管理员权限 vssadmin add shadowstorage /forC: /onD: /maxsize10% vssadmin create shadow /forC:卷影副本可以让你在文件被删后从之前的快照里恢复。但配置相对复杂且需要额外磁盘空间。3.3 第三道防线Agent操作前的影响面评估这是最容易被忽略、但最重要的一环。在让Agent执行任何删除、移动、重命名类操作之前要求它先输出影响面报告请先不要执行删除。列出你计划删除的所有文件路径统计数量 并标记出其中哪些是目录联接、符号链接、Git仓库文件。 等我确认后再执行。一个合格的Agent应该能输出类似计划删除 - C:\project\temp\ (234个文件) - C:\project\cache\ (1203个文件) - C:\project\data\ - 检测到Junction指向 D:\bigdata\dataset (45678个文件) - C:\project\.git\ (890个文件Git仓库) 警告data目录是Junction删除将影响D:\bigdata\dataset。 警告.git目录包含版本历史删除后无法恢复。如果Agent不能输出这种报告说明它的文件操作模块缺少安全检查你应该考虑换工具或加一层包装脚本。3.4 第四道防线用包装脚本拦截危险命令如果你无法修改Agent本身可以在它和系统之间加一层命令拦截器。思路是Agent不直接执行命令而是把命令写到一个队列文件由一个守护脚本检查后执行。简化版实现PowerShell# 危险命令拦截器 $dangerousPatterns ( Remove-Item.*-Recurse, rmdir.*/s, del.*/f.*/s, rd.*/s, git.*clean.*-fdx ) $command $args -join foreach ($pattern in $dangerousPatterns) { if ($command -match $pattern) { Write-Host 拦截危险命令: $command Write-Host 请手动确认后执行。 exit 1 } } Invoke-Expression $command这个脚本很粗糙但思路是对的在递归删除类命令到达系统之前先拦一道。你可以根据自己项目的实际情况扩充危险模式列表。3.5 防护方案对比方案防护对象实施难度恢复速度推荐指数Git远程推送.git目录低快五星Git bundle备份整个仓库低中四星NTFS权限限制指定目录中不适用防删三星卷影副本整个卷高中三星影响面评估所有操作低不适用防删五星命令拦截器危险命令中不适用防删四星我的建议是Git远程推送影响面评估作为基础配置两者都是低成本高收益。其他方案根据项目敏感度叠加。4. 误删后的恢复实操从绝望到找回数据4.1 第一时间要做的三件事发现文件被误删后立刻停止对该磁盘的所有写入操作。原因很简单被删除的文件数据块在未被覆盖之前是有可能恢复的。任何新文件的写入都可能覆盖这些数据块。具体操作停止Agent关闭Claude Code或任何正在运行的Agent进程。停止IDE和编辑器VS Code、Cursor等可能还在后台写缓存、日志。不要往该盘保存任何东西包括恢复工具本身也要装到另一个盘。实操心得我见过有人发现文件被删后第一反应是赶紧装个恢复软件结果恢复软件默认装到C盘安装过程写入了大量临时文件把刚删的数据块覆盖了。正确做法是把恢复工具装到U盘或另一个物理磁盘。4.2 Git仓库的恢复路径情况一有远程仓库且已推送# 最简单的情况重新克隆 git clone remote-url project-restored如果本地还有其他未推送的commit但.git已删那就找不回来了。所以再次强调Agent操作前先推送。情况二有bundle备份git clone project-backup.bundle project-restored cd project-restored git remote set-url origin remote-url git push origin --all情况三.git被删但工作区文件还在如果只是.git没了但源码文件还在可以重新初始化cd project git init git add -A git commit -m reinitialize after .git loss但这会丢失所有历史。如果之前有远程仓库可以尝试git init git remote add origin remote-url git fetch origin git reset --soft origin/main这样能把远程的历史拉回来工作区文件保持不变然后重新提交差异。情况四什么都没有只能走文件恢复工具的路子。Windows上常用的有Recuva、R-Studio、DiskGenius等。但要注意恢复成功率取决于删除后是否有写入.git/objects里的文件是压缩的恢复后可能损坏恢复出来的文件需要重新git init并提交历史无法找回。4.3 普通文件的恢复如果删除的是普通项目文件非Git仓库恢复思路类似用恢复工具扫描磁盘按文件类型、删除时间过滤恢复到另一个磁盘校验文件完整性。但4.8万个文件的量级恢复工具扫描和恢复都会很慢。而且如果删除后系统有大量写入比如Windows更新、日志、缓存很多数据块已经被覆盖。4.4 恢复工具选择对比工具适用场景优点缺点Recuva普通文件恢复免费、简单深度扫描慢R-Studio复杂恢复功能强、支持RAID收费DiskGenius分区/文件恢复中文、功能全免费版有限制PhotoRec按文件签名恢复免费、开源无文件名Windows文件历史有开启历史记录系统集成需提前开启我的经验是如果文件重要不要自己反复尝试恢复直接找专业数据恢复服务。自己操作越多覆盖越严重专业恢复的成功率越低。4.5 恢复后的复盘清单数据找回来后别急着继续干活。花30分钟做一次复盘[ ] 这次删除是谁触发的Agent还是手动命令[ ] 删除命令的具体内容是什么有没有-Recurse、/s这类参数[ ] 项目目录里有没有Junction、符号链接分别指向哪里[ ].git目录有没有异地备份最后一次推送是什么时候[ ] Agent的文件操作权限是否可以收窄[ ] 是否需要加一层命令拦截或影响面评估流程这份清单看起来简单但能帮你把偶然事故变成系统性改进。5. 常见问题与排查技巧实录5.1 Agent相关高频问题问题一Agent执行删除时没有确认提示这是最危险的信号。说明Agent的删除操作被配置为自动执行或低风险操作。排查方向检查Agent的权限配置文件看是否有autoApprove、dangerouslySkipPermissions之类的设置检查是否有全局的信任此目录配置如果是Claude Code查看其设置里关于文件操作的权限级别。问题二Agent不认识Junction遍历时穿透排查方法# 列出目录下所有重解析点 dir /a /s | findstr JUNCTION或者在PowerShell里Get-ChildItem -Recurse -Force | Where-Object { $_.Attributes -match ReparsePoint }如果Agent的工作目录里有Junction要么移除要么在Agent配置里明确排除。问题三Agent执行git clean -fdx导致未跟踪文件全删git clean -fdx会删除所有未跟踪文件和目录包括.env、node_modules、构建产物等。如果Agent把它当作清理项目的手段后果很严重。防护在.gitignore里把重要文件排除但-x参数会忽略.gitignore。所以更可靠的是在Agent配置里禁止git clean命令。5.2 Git相关高频问题问题一git status报not a git repository说明当前目录或父目录没有.git。排查# 向上查找.git目录 cd C:\project git rev-parse --show-toplevel如果报错说明.git确实没了。检查回收站、备份、远程仓库。问题二.git目录被部分删除仓库损坏git fsck --full这条命令会检查仓库完整性。如果报missing blob或broken link说明对象文件缺失。尝试从远程重新拉取git fetch origin git reset --hard origin/main问题三Git安装后命令不可用Windows上安装Git后如果git命令提示找不到检查安装时是否勾选了Add to PATH环境变量Path里是否有C:\Program Files\Git\cmd重启终端后再试。5.3 Windows文件系统相关问题一删除Junction时误删目标内容Junction的删除行为rmdir C:\project\data只删除Junction本身目标内容保留rmdir /s C:\project\data递归删除会穿透到目标内容Remove-Item -Recurse C:\project\data同样穿透。所以删除Junction时不要加递归参数。问题二如何安全地删除一个Junction# 正确方式不加/s rmdir C:\project\data或者用PowerShell# 只删除链接本身 (Get-Item C:\project\data).Delete()问题三如何识别一个目录是不是Junctionfsutil reparsepoint query C:\project\data如果输出包含Tag value: 0xA0000003就是JunctionMount Point。5.4 问题速查表现象可能原因排查命令解决方向文件批量消失Agent递归删除查Agent日志停止Agent走恢复流程.git目录消失递归删除穿透git rev-parse从远程/bundle恢复删除速度异常快命令行批量删除查命令历史检查是否有-RecurseJunction目标被删递归操作穿透fsutil reparsepoint避免递归删除JunctionAgent无确认执行权限配置过宽查Agent配置收紧权限加确认恢复工具扫不到数据块被覆盖停止写入换专业恢复服务5.5 几个我踩过的坑坑一以为回收站能兜底命令行删除Remove-Item、del、rmdir默认不进回收站。回收站只对资源管理器的删除操作生效。所以别指望删完去回收站找。坑二以为Git有自动备份Git本身不做备份。.git目录就是唯一副本。没有远程、没有bundle删了就是删了。坑三以为Junction是快捷方式快捷方式.lnk是文件删除它不影响目标。Junction是目录递归删除会穿透。两者行为完全不同。坑四以为Agent应该知道Agent不知道你的目录结构、不知道哪些是重要数据、不知道Junction指向哪里。它只知道你给的指令和它能看到的文件树。安全边界必须由你来划。6. 给Agent使用者的实操建议6.1 建立Agent工作区隔离我的做法是给Agent单独划一个工作目录比如C:\agent-workspace\里面只放当前任务需要的文件。项目主目录、数据目录、Git仓库都放在工作区之外通过复制或只读挂载的方式让Agent访问。这样即使Agent执行了递归删除影响范围也被限制在工作区内。工作区里的文件可以从主目录重新复制损失可控。6.2 用Git分支隔离Agent的修改让Agent在独立分支上工作git checkout -b agent/task-001 # Agent在这里操作 # 完成后审查 git diff main..agent/task-001 git checkout main git merge agent/task-001这样即使Agent删了文件主分支不受影响。审查diff后再决定是否合并。6.3 定期做恢复演练备份的价值只有在恢复时才能验证。我建议每个月做一次恢复演练随便找一个测试仓库模拟.git被删用bundle或远程仓库恢复记录恢复耗时和遇到的问题。这个习惯帮我发现了好几个备份配置的漏洞比如bundle文件权限不对、远程仓库地址过期等。6.4 关注Agent的危险操作日志大多数Agent工具会记录操作日志。定期检查日志里的删除、移动、重命名类操作看看有没有异常。如果工具不提供日志考虑用系统层面的审计# 启用文件系统审计需要管理员权限 auditpol /set /subcategory:File System /success:enable /failure:enable然后在事件查看器里筛选相关事件。6.5 最后分享一个小技巧如果你不确定某个Agent的删除行为是否安全可以先用一个替身目录测试mkdir C:\test-safety cd C:\test-safety mkdir real-data echo important real-data\file.txt mklink /J link-to-data real-data然后让Agent执行清理C:\test-safety的任务观察real-data\file.txt是否还在。如果被删了说明这个Agent会穿透Junction你在正式项目里就要格外小心。这个测试花不了5分钟但能帮你避开一次可能的数据灾难。我自己在换用任何新的Agent工具时都会先跑一遍这个测试。 
长河君 · 2026/10/4 6:39:54 · 阅读 1.2k Agent误删4.8万文件：Junction穿透与Git仓库防护实战
1. 一次删库事件的完整复盘1.1 事件还原103秒到底发生了什么先把时间线拉直。某位开发者在一台Windows机器上使用Claude Code作为编码助手项目目录里存在一个指向其他位置的目录联接Directory Junction。Agent在获得文件操作权限后执行了一批清理类命令103秒内删除了约4.8万个文件随后发现Git仓库目录也一并消失——.git文件夹被递归删除意味着版本历史、分支、暂存区全部归零。这里有几个关键事实需要拆开看删除速度4.8万个文件/103秒 ≈ 每秒466个文件。这个速度说明删除操作不是逐个文件走图形界面确认而是通过命令行递归删除类似rmdir /s /q或Remove-Item -Recurse -Force批量执行的。Git也没了.git目录本质上就是一堆普通文件和目录递归删除不会区分它是版本库还是普通文件夹。一旦父目录被递归清理.git首当其冲。Directory Junction的角色这是Windows上的目录联接类似Linux的符号链接但更透明。很多工具在遍历目录时会把Junction当作真实目录进入导致删除范围远超预期——你以为只删了项目目录实际上通过Junction把另一个盘的数据也带走了。注意Directory Junction在Windows上创建后资源管理器里显示为普通文件夹图标带一个小箭头但很多命令行工具和脚本不会主动识别它递归操作时会直接穿透。1.2 为什么这件事值得每个用Agent的人警惕很多人看到这条消息的第一反应是这开发者自己没管好权限。但我想说的是这件事暴露的是Agent类工具在文件系统操作上的系统性风险不是某一个人的疏忽。传统IDE的重构、删除操作通常有明确的UI确认、有撤销栈、有回收站兜底。而Agent执行的是自然语言驱动的命令它的确认往往只是一句我将要删除这些文件是否继续你点了同意它就可能执行一条覆盖范围远超你想象的递归命令。更麻烦的是Agent的上下文里可能并不清楚Junction的存在。它看到的是一个目录树遍历时Junction被展开它以为这些都是项目内的文件于是放心地批量清理。这不是模型坏而是它对Windows文件系统特性的理解存在盲区。我个人的判断是只要Agent拥有文件系统的写权限就必须假设它某一天会执行超出预期的删除操作。这不是对工具的不信任而是对自然语言→命令这条链路不确定性的基本尊重。1.3 本文适合谁读如果你符合以下任意一条这篇内容对你有直接价值正在或准备在Windows上使用Claude Code、Cursor、各类Agent编码工具项目目录里存在Junction、符号链接、映射盘、网络驱动器用Git做版本管理但没想过.git目录本身也可能被误删想建立一套Agent操作安全边界的实操规范。下面我会从原理、复现、防护、恢复四个层面展开尽量给出可以直接抄作业的方案。2. 核心原理拆解Junction、递归删除与Git的脆弱性2.1 Directory Junction到底是什么Windows上的目录联接Directory Junction是一种重解析点Reparse Point。你可以把它理解为一个传送门C:\project\data这个路径看起来是个普通文件夹但实际存储位置可能在D:\bigdata\dataset。创建方式很简单mklink /J C:\project\data D:\bigdata\dataset这条命令执行后访问C:\project\data\file.txt实际读写的是D:\bigdata\dataset\file.txt。关键特性特性说明对用户透明资源管理器、多数程序都当作普通目录跨卷支持可以指向不同盘符删除行为特殊删除Junction本身不会删目标内容但递归删除会穿透工具识别不一dir /a能看到JUNCTION标记但很多脚本不检查最后一条是重点。当你执行Remove-Item -Recurse -Force C:\project时PowerShell会进入data目录把它里面的文件全部删掉——删的是D:\bigdata\dataset里的真实数据。而Junction本身在父目录被删时也会被移除但目标数据已经没了。2.2 递归删除为什么这么快、这么彻底以PowerShell为例一条典型的递归删除命令Remove-Item -Path C:\project -Recurse -Force -ErrorAction SilentlyContinue拆解一下参数-Recurse递归进入所有子目录-Force强制删除只读、隐藏文件.git里的对象文件很多是只读的-ErrorAction SilentlyContinue遇到错误不中断继续删下一个。这三个参数组合在一起就是一台推土机。-Force让.git目录里的只读对象文件无法阻挡删除-ErrorAction SilentlyContinue让个别文件被占用时也不影响整体进度。4.8万个文件103秒平均每个文件处理时间约2毫秒。这个速度只有在SSD批量删除无UI确认的条件下才能达到。如果是机械硬盘或者每个文件都弹确认框时间会拉长几十倍。2.3 Git仓库为什么一删就没很多人对Git有个误解以为.git是某种特殊的、受保护的数据。实际上.git就是一个普通目录里面装着objects/所有提交对象、树对象、blob压缩存储refs/分支和标签的引用HEAD当前分支指针config仓库配置index暂存区。这些全是普通文件。递归删除不会因为它是Git仓库就手下留情。删完之后git status会直接报not a git repository因为.git目录不存在了。本地Git仓库的唯一副本就是.git目录本身。如果你没有远程仓库或者远程仓库不是最新的那这次删除就是永久性的。这也是为什么事件里Git也没了比4.8万个文件没了更让人心疼——代码文件可能还有备份但提交历史、分支结构、未推送的commit全在.git里。2.4 Agent为什么会执行这种操作Claude Code这类Agent的工作模式是接收自然语言指令→规划步骤→调用工具读写文件、执行命令→观察结果→继续。风险点在于指令理解偏差用户说清理一下项目里的临时文件Agent可能理解为清理项目目录下所有非源码文件范围被放大。目录遍历不识别JunctionAgent的文件遍历工具如果基于普通递归会把Junction目标当作项目内文件。缺少删除前的影响面评估成熟的删除操作应该先列出将要删除的文件清单、统计数量、识别Junction和符号链接但很多Agent直接执行。权限过大Agent以当前用户权限运行能删的东西和你能删的一样多。实操心得我在测试各类Agent工具时会专门建一个蜜罐目录里面放一个Junction指向一个装满测试文件的目录。观察Agent在执行清理任务时会不会穿透Junction。这个测试帮我筛掉了好几个看起来聪明但文件操作很莽的工具。3. 防护体系搭建让Agent删不掉不该删的东西3.1 第一道防线Git仓库的异地备份最直接、最有效的防护是让.git目录在任何时候都有至少一份异地副本。方案AGit远程仓库推荐# 每次开始工作前先推送一次 git add -A git commit -m checkpoint before agent session git push origin main关键点在让Agent执行任何批量操作之前确保所有commit都已推送。未推送的commit只存在于本地.git删了就没了。方案B定时镜像备份如果项目不方便推远程可以用脚本定时把.git目录复制到另一个位置# 每天定时执行把.git镜像到备份盘 $source C:\project\.git $dest E:\git-backup\project-git robocopy $source $dest /MIR /R:1 /W:1robocopy /MIR会做镜像同步第一次全量后续增量。/R:1 /W:1表示失败只重试1次、等待1秒避免卡住。方案CGit bundle单文件备份git bundle create project-backup.bundle --all这条命令把整个仓库所有分支、所有历史打包成一个文件。把这个bundle文件放到安全位置即使.git被删也能用git clone project-backup.bundle恢复。我个人的习惯是方案A为主方案C为辅。每次重要节点推远程同时生成一个bundle丢到网盘或移动硬盘。3.2 第二道防线文件系统层面的保护关闭Agent对Junction的穿透能力Windows上可以用fsutil查看重解析点fsutil reparsepoint query C:\project\data但更实用的是在Agent工作目录里避免使用Junction。如果必须用考虑改用符号链接mklink /D并配合工具的白名单机制或者干脆把外部数据放在项目目录之外通过环境变量引用。使用只读挂载或权限限制对于确实需要Agent访问但不希望被删除的目录可以右键目录→属性→安全→高级→禁用继承→删除写入和修改权限只保留读取和执行。这样即使Agent执行递归删除遇到无权限的文件会报错-ErrorAction SilentlyContinue会跳过但至少不会删掉。注意这个方法对-Force参数无效因为-Force主要针对只读属性不是NTFS权限。要真正挡住需要NTFS权限层面的拒绝。启用Windows文件历史或卷影副本# 启用卷影副本需要管理员权限 vssadmin add shadowstorage /forC: /onD: /maxsize10% vssadmin create shadow /forC:卷影副本可以让你在文件被删后从之前的快照里恢复。但配置相对复杂且需要额外磁盘空间。3.3 第三道防线Agent操作前的影响面评估这是最容易被忽略、但最重要的一环。在让Agent执行任何删除、移动、重命名类操作之前要求它先输出影响面报告请先不要执行删除。列出你计划删除的所有文件路径统计数量 并标记出其中哪些是目录联接、符号链接、Git仓库文件。 等我确认后再执行。一个合格的Agent应该能输出类似计划删除 - C:\project\temp\ (234个文件) - C:\project\cache\ (1203个文件) - C:\project\data\ - 检测到Junction指向 D:\bigdata\dataset (45678个文件) - C:\project\.git\ (890个文件Git仓库) 警告data目录是Junction删除将影响D:\bigdata\dataset。 警告.git目录包含版本历史删除后无法恢复。如果Agent不能输出这种报告说明它的文件操作模块缺少安全检查你应该考虑换工具或加一层包装脚本。3.4 第四道防线用包装脚本拦截危险命令如果你无法修改Agent本身可以在它和系统之间加一层命令拦截器。思路是Agent不直接执行命令而是把命令写到一个队列文件由一个守护脚本检查后执行。简化版实现PowerShell# 危险命令拦截器 $dangerousPatterns ( Remove-Item.*-Recurse, rmdir.*/s, del.*/f.*/s, rd.*/s, git.*clean.*-fdx ) $command $args -join foreach ($pattern in $dangerousPatterns) { if ($command -match $pattern) { Write-Host 拦截危险命令: $command Write-Host 请手动确认后执行。 exit 1 } } Invoke-Expression $command这个脚本很粗糙但思路是对的在递归删除类命令到达系统之前先拦一道。你可以根据自己项目的实际情况扩充危险模式列表。3.5 防护方案对比方案防护对象实施难度恢复速度推荐指数Git远程推送.git目录低快五星Git bundle备份整个仓库低中四星NTFS权限限制指定目录中不适用防删三星卷影副本整个卷高中三星影响面评估所有操作低不适用防删五星命令拦截器危险命令中不适用防删四星我的建议是Git远程推送影响面评估作为基础配置两者都是低成本高收益。其他方案根据项目敏感度叠加。4. 误删后的恢复实操从绝望到找回数据4.1 第一时间要做的三件事发现文件被误删后立刻停止对该磁盘的所有写入操作。原因很简单被删除的文件数据块在未被覆盖之前是有可能恢复的。任何新文件的写入都可能覆盖这些数据块。具体操作停止Agent关闭Claude Code或任何正在运行的Agent进程。停止IDE和编辑器VS Code、Cursor等可能还在后台写缓存、日志。不要往该盘保存任何东西包括恢复工具本身也要装到另一个盘。实操心得我见过有人发现文件被删后第一反应是赶紧装个恢复软件结果恢复软件默认装到C盘安装过程写入了大量临时文件把刚删的数据块覆盖了。正确做法是把恢复工具装到U盘或另一个物理磁盘。4.2 Git仓库的恢复路径情况一有远程仓库且已推送# 最简单的情况重新克隆 git clone remote-url project-restored如果本地还有其他未推送的commit但.git已删那就找不回来了。所以再次强调Agent操作前先推送。情况二有bundle备份git clone project-backup.bundle project-restored cd project-restored git remote set-url origin remote-url git push origin --all情况三.git被删但工作区文件还在如果只是.git没了但源码文件还在可以重新初始化cd project git init git add -A git commit -m reinitialize after .git loss但这会丢失所有历史。如果之前有远程仓库可以尝试git init git remote add origin remote-url git fetch origin git reset --soft origin/main这样能把远程的历史拉回来工作区文件保持不变然后重新提交差异。情况四什么都没有只能走文件恢复工具的路子。Windows上常用的有Recuva、R-Studio、DiskGenius等。但要注意恢复成功率取决于删除后是否有写入.git/objects里的文件是压缩的恢复后可能损坏恢复出来的文件需要重新git init并提交历史无法找回。4.3 普通文件的恢复如果删除的是普通项目文件非Git仓库恢复思路类似用恢复工具扫描磁盘按文件类型、删除时间过滤恢复到另一个磁盘校验文件完整性。但4.8万个文件的量级恢复工具扫描和恢复都会很慢。而且如果删除后系统有大量写入比如Windows更新、日志、缓存很多数据块已经被覆盖。4.4 恢复工具选择对比工具适用场景优点缺点Recuva普通文件恢复免费、简单深度扫描慢R-Studio复杂恢复功能强、支持RAID收费DiskGenius分区/文件恢复中文、功能全免费版有限制PhotoRec按文件签名恢复免费、开源无文件名Windows文件历史有开启历史记录系统集成需提前开启我的经验是如果文件重要不要自己反复尝试恢复直接找专业数据恢复服务。自己操作越多覆盖越严重专业恢复的成功率越低。4.5 恢复后的复盘清单数据找回来后别急着继续干活。花30分钟做一次复盘[ ] 这次删除是谁触发的Agent还是手动命令[ ] 删除命令的具体内容是什么有没有-Recurse、/s这类参数[ ] 项目目录里有没有Junction、符号链接分别指向哪里[ ].git目录有没有异地备份最后一次推送是什么时候[ ] Agent的文件操作权限是否可以收窄[ ] 是否需要加一层命令拦截或影响面评估流程这份清单看起来简单但能帮你把偶然事故变成系统性改进。5. 常见问题与排查技巧实录5.1 Agent相关高频问题问题一Agent执行删除时没有确认提示这是最危险的信号。说明Agent的删除操作被配置为自动执行或低风险操作。排查方向检查Agent的权限配置文件看是否有autoApprove、dangerouslySkipPermissions之类的设置检查是否有全局的信任此目录配置如果是Claude Code查看其设置里关于文件操作的权限级别。问题二Agent不认识Junction遍历时穿透排查方法# 列出目录下所有重解析点 dir /a /s | findstr JUNCTION或者在PowerShell里Get-ChildItem -Recurse -Force | Where-Object { $_.Attributes -match ReparsePoint }如果Agent的工作目录里有Junction要么移除要么在Agent配置里明确排除。问题三Agent执行git clean -fdx导致未跟踪文件全删git clean -fdx会删除所有未跟踪文件和目录包括.env、node_modules、构建产物等。如果Agent把它当作清理项目的手段后果很严重。防护在.gitignore里把重要文件排除但-x参数会忽略.gitignore。所以更可靠的是在Agent配置里禁止git clean命令。5.2 Git相关高频问题问题一git status报not a git repository说明当前目录或父目录没有.git。排查# 向上查找.git目录 cd C:\project git rev-parse --show-toplevel如果报错说明.git确实没了。检查回收站、备份、远程仓库。问题二.git目录被部分删除仓库损坏git fsck --full这条命令会检查仓库完整性。如果报missing blob或broken link说明对象文件缺失。尝试从远程重新拉取git fetch origin git reset --hard origin/main问题三Git安装后命令不可用Windows上安装Git后如果git命令提示找不到检查安装时是否勾选了Add to PATH环境变量Path里是否有C:\Program Files\Git\cmd重启终端后再试。5.3 Windows文件系统相关问题一删除Junction时误删目标内容Junction的删除行为rmdir C:\project\data只删除Junction本身目标内容保留rmdir /s C:\project\data递归删除会穿透到目标内容Remove-Item -Recurse C:\project\data同样穿透。所以删除Junction时不要加递归参数。问题二如何安全地删除一个Junction# 正确方式不加/s rmdir C:\project\data或者用PowerShell# 只删除链接本身 (Get-Item C:\project\data).Delete()问题三如何识别一个目录是不是Junctionfsutil reparsepoint query C:\project\data如果输出包含Tag value: 0xA0000003就是JunctionMount Point。5.4 问题速查表现象可能原因排查命令解决方向文件批量消失Agent递归删除查Agent日志停止Agent走恢复流程.git目录消失递归删除穿透git rev-parse从远程/bundle恢复删除速度异常快命令行批量删除查命令历史检查是否有-RecurseJunction目标被删递归操作穿透fsutil reparsepoint避免递归删除JunctionAgent无确认执行权限配置过宽查Agent配置收紧权限加确认恢复工具扫不到数据块被覆盖停止写入换专业恢复服务5.5 几个我踩过的坑坑一以为回收站能兜底命令行删除Remove-Item、del、rmdir默认不进回收站。回收站只对资源管理器的删除操作生效。所以别指望删完去回收站找。坑二以为Git有自动备份Git本身不做备份。.git目录就是唯一副本。没有远程、没有bundle删了就是删了。坑三以为Junction是快捷方式快捷方式.lnk是文件删除它不影响目标。Junction是目录递归删除会穿透。两者行为完全不同。坑四以为Agent应该知道Agent不知道你的目录结构、不知道哪些是重要数据、不知道Junction指向哪里。它只知道你给的指令和它能看到的文件树。安全边界必须由你来划。6. 给Agent使用者的实操建议6.1 建立Agent工作区隔离我的做法是给Agent单独划一个工作目录比如C:\agent-workspace\里面只放当前任务需要的文件。项目主目录、数据目录、Git仓库都放在工作区之外通过复制或只读挂载的方式让Agent访问。这样即使Agent执行了递归删除影响范围也被限制在工作区内。工作区里的文件可以从主目录重新复制损失可控。6.2 用Git分支隔离Agent的修改让Agent在独立分支上工作git checkout -b agent/task-001 # Agent在这里操作 # 完成后审查 git diff main..agent/task-001 git checkout main git merge agent/task-001这样即使Agent删了文件主分支不受影响。审查diff后再决定是否合并。6.3 定期做恢复演练备份的价值只有在恢复时才能验证。我建议每个月做一次恢复演练随便找一个测试仓库模拟.git被删用bundle或远程仓库恢复记录恢复耗时和遇到的问题。这个习惯帮我发现了好几个备份配置的漏洞比如bundle文件权限不对、远程仓库地址过期等。6.4 关注Agent的危险操作日志大多数Agent工具会记录操作日志。定期检查日志里的删除、移动、重命名类操作看看有没有异常。如果工具不提供日志考虑用系统层面的审计# 启用文件系统审计需要管理员权限 auditpol /set /subcategory:File System /success:enable /failure:enable然后在事件查看器里筛选相关事件。6.5 最后分享一个小技巧如果你不确定某个Agent的删除行为是否安全可以先用一个替身目录测试mkdir C:\test-safety cd C:\test-safety mkdir real-data echo important real-data\file.txt mklink /J link-to-data real-data然后让Agent执行清理C:\test-safety的任务观察real-data\file.txt是否还在。如果被删了说明这个Agent会穿透Junction你在正式项目里就要格外小心。这个测试花不了5分钟但能帮你避开一次可能的数据灾难。我自己在换用任何新的Agent工具时都会先跑一遍这个测试。