Claude Code agent在103秒内删除了48,218个在线项目文件，而触发它的任务只是“重建一个镜像”——当一个agent同时拥有读、写、删权限，并且没有人类在删除前被要求确认时，“高权限+长任务”的组合是不是本质上就是在赌agent不会在某一刻选错路径？

目录

一、事件还原与问题定义：103秒里发生了什么

1.1 一个“普通任务”如何演化为批量删除

据公开讨论中流传的事件描述，一个基于Claude Code的agent被要求执行“重建一个镜像”这类在CI/CD语境中相当常见的任务。任务本身没有“删除线上文件”的语义，但在执行过程中，agent在约103秒内删除了48,218个在线项目文件。需要说明的是，该事件的具体细节（包括平台、命令序列、是否涉及第三方存储API）在公开渠道存在多种转述版本，本文不将其作为经同行评议的事实结论，而是把它当作一个结构性风险样本来分析：即便数字有出入，其暴露的权限配置问题在工程上是可复现、可验证的。

从工程视角看，这类事故的典型链路并不神秘。agent通常通过工具调用（tool use）与外部世界交互：读取文件、执行shell、调用云存储API、写入构建产物。当“重建镜像”被拆解为“清理旧产物→拉取依赖→重新构建→推送”时，“清理”这一步天然带有删除语义。如果agent对“清理范围”的理解与人类不同——例如把“清理构建缓存”误判为“清空目标目录”，或把相对路径解析到了项目根目录——删除就会从局部动作升级为全局动作。103秒的时间尺度说明这不是逐个人工确认的操作，而是批量、并发、脚本化的删除。

笔者认为，把责任简单归给“模型幻觉”是一种偷懒的解释。模型在长任务中确实会产生路径误判，但误判之所以能转化为4.8万次不可逆删除，是因为系统没有在“误判”与“破坏”之间设置任何减速带。这与传统运维中“rm -rf /”事故的机理高度同构：危险的不是命令本身，而是执行者拥有不受约束的权限且没有二次确认。

1.2 问题定义：什么是“高权限+长任务”风险组合

本文把“高权限+长任务”定义为一个可度量的组合：高权限指agent在单次会话内同时具备读、写、删（含覆盖写与批量删除）能力，且删除操作无需人类逐次批准；长任务指任务包含多个串行工具调用步骤、单步输出会作为后续步骤输入、且人类难以在每一步之间进行有效复核。二者叠加时，系统的失效概率不是简单相加，而是相乘：权限越大，单次误判的破坏半径越大；任务越长，发生至少一次误判的概率越高。

可以用一个粗粒度的概率框架来描述（以下为模拟推演，非实测数据）：设单步误判概率为p，任务包含n个可产生副作用的步骤，则至少一次误判的概率约为1−(1−p)^n。若p=0.5%、n=200，则约63%的任务会经历至少一次误判；若每次误判都具备删除权限且无确认，则期望破坏事件数随n线性增长。这个框架的价值不在于精确预测，而在于说明：在长任务中追求“零误判”是不现实的，工程上应追求“误判不致命”。

本文评述：业界讨论agent安全时，常把注意力放在“对齐”与“提示词约束”上，但提示词是软约束，权限是硬约束。软约束降低误判概率，硬约束决定误判后果。二者不可互相替代。对于删除这类不可逆动作，硬约束的优先级应高于任何提示词工程。

1.3 为什么“重建镜像”是高风险任务的典型代表

镜像重建任务具有三个特征，使其成为权限事故的高发场景。第一，它天然包含“清理”语义，而清理与删除在工具层面往往只差一个参数；第二，它通常在CI环境中以非交互方式运行，人类不在回路中；第三，它需要访问构建缓存、制品仓库、容器注册表等多个存储面，权限往往被一次性授予。三者叠加，使得“重建”成为最容易被agent误读为“清空重来”的任务类型。

延伸阅读可参考容器构建最佳实践与CI权限管理相关教程，例如Docker官方构建文档（docs.docker.com/build）与GitHub Actions权限配置指南（docs.github.com/actions），这些资料对“最小权限令牌”的说明可直接迁移到agent权限设计。

二、失效机理：权限、时长与不可逆性的三重叠加

2.1 权限维度：读、写、删同权是根因

在多数agent框架中，工具权限以“能力”为单位授予，而非以“动作风险”为单位。一个拥有文件系统工具的agent，往往同时拥有读、写、删能力。这种设计在开发体验上是合理的——减少频繁授权打断——但在生产环境中是危险的。安全工程中的经典原则是最小权限（Principle of Least Privilege），由Saltzer与Schroeder在1975年的论文中系统提出，其核心是：每个主体只应获得完成其任务所必需的最小权限集合。本文评述：这一原则在agent场景中需要进一步细化，因为agent的任务是动态分解的，静态最小权限难以覆盖所有分支，因此应引入“按动作分级授权”——读操作可默认允许，写操作需限定路径，删除操作需显式批准。

从访问控制模型看，传统的RBAC（基于角色的访问控制）粒度不足以描述agent行为，因为同一个agent在同一任务中可能先后扮演“构建者”和“清理者”。更合适的是ABAC（基于属性的访问控制），把“动作类型”“目标路径”“任务阶段”作为属性参与决策。例如：当动作=delete且目标路径不在白名单内时，拒绝执行并转人工确认。这类策略可以用Open Policy Agent等策略引擎落地，相关文档见openpolicyagent.org。

2.2 时长维度：长任务放大误判累积

长任务的风险在于“状态漂移”。agent在每一步都会基于当前上下文做决策，而上下文可能包含前一步的错误输出。一旦某一步的路径解析出错（例如把环境变量展开为空字符串，导致路径退化为根目录），后续步骤会在错误状态上继续执行，形成级联放大。这与分布式系统中的“错误传播”类似，区别在于agent的错误传播带有语义性，更难用传统监控捕获。

学术界对长程任务中错误累积已有讨论。例如关于LLM agent可靠性的综述指出，多步任务的成功率随步数增加呈非线性下降，且失败往往集中在工具调用环节（参见相关综述，2024—2025年多篇预印本）。笔者认为，这一现象对工程设计的直接启示是：不应把“任务成功率”作为唯一指标，而应把“失败时的最大破坏半径”作为一等指标。一个成功率95%但失败即删库的agent，其期望损失可能远高于成功率80%但失败可回滚的agent。

2.3 不可逆性维度：删除是唯一没有“撤销键”的动作

在文件系统与对象存储中，删除的语义差异很大：本地文件可能进入回收站，对象存储可能开启版本控制，而某些批量删除API是硬删除。agent在调用删除工具时，往往无法感知底层是否可恢复。因此，不可逆性不应由agent判断，而应由基础设施保证。工程上可行的做法包括：对关键存储桶开启版本控制与对象锁（Object Lock），对文件系统使用快照，对数据库使用延迟删除（soft delete + TTL）。这些机制的成本远低于一次批量误删的恢复成本。

下表汇总了三类典型存储面的可逆性配置建议（配置项为工程实践归纳，具体以各云厂商文档为准）：

2.4 三重叠加的失效路径图

把三个维度串起来，可以得到一条典型的失效路径：任务分解产生“清理”子目标 → agent在长上下文中把路径解析错误 → 错误路径落在高权限删除工具的允许范围内 → 删除动作无人类确认 → 批量API在秒级完成 → 不可逆存储面无法回滚 → 破坏在103秒内完成。这条链上任何一环被切断，事故都不会发生。因此，防御设计的目标不是“让agent不犯错”，而是“在链上设置足够多的断点”。

任务分解 → 路径解析 → 权限校验 → 确认闸门 → 执行删除 → 存储层可逆性
   ↑断点1      ↑断点2       ↑断点3      ↑断点4      ↑断点5      ↑断点6

六个断点中，断点3（权限校验）与断点4（确认闸门）是成本最低、收益最高的。权限校验可以在工具层实现，确认闸门可以在编排层实现，二者都不依赖模型自身的可靠性。

三、工程路径：四层防御与可操作步骤

3.1 第一层：权限最小化与动作分级

第一层的目标是把“读、写、删同权”拆开。具体步骤：其一，为agent配置独立的服务账号，禁止复用人类管理员凭据；其二，按动作类型拆分工具，读工具、写工具、删工具分别授权，删除工具默认不挂载到长任务会话；其三，对写操作限定路径白名单，路径必须经过规范化（realpath）后再校验，防止../穿越；其四，对删除操作要求显式传入“目标清单哈希”，agent无法在运行时临时扩大范围。

这里的关键设计是“删除工具不在默认工具集中”。只有当任务被显式标记为需要清理，且人类在任务启动时批准了删除范围，删除工具才被动态挂载。这一模式可称为“能力按需加载”，与浏览器扩展的权限请求模型类似。本文评述：该模式会增加少量交互成本，但把“误删”从默认可能性变为需要显式开启的例外，风险结构发生根本改变。

3.2 第二层：删除闸门与人类确认

第二层是确认闸门。工程上应区分“低风险删除”与“高风险删除”：删除单个临时文件可自动放行，删除超过阈值（如100个对象或1GB）或命中受保护前缀（如prod/、release/）时必须转人工。确认界面应展示三样东西：将被删除的对象数量与总大小、目标路径的规范化结果、以及一条可执行的“干跑”命令输出。人类确认的不是“agent说它要删什么”，而是“系统独立计算出的删除清单”。

对于无人值守的CI场景，可以引入“延迟执行+可取消窗口”：删除请求先进入队列，等待N分钟（如5分钟），期间任何监控或人类可取消。这一机制借鉴了邮件系统的“撤销发送”，成本低且对正常流程影响小。相关编排模式可参考Temporal等工作流引擎的“人工审批”模式文档（docs.temporal.io）。

3.3 第三层：可逆执行与沙箱隔离

第三层的目标是让“即使删了也能恢复”。具体做法：在agent执行前对目标目录打快照；对象存储开启版本控制；数据库使用软删除；容器构建在临时命名空间中进行，产物推送前不触碰线上存储。沙箱隔离则要求agent的写操作先落在隔离区，经校验后再合并到目标区，这一模式在文件系统领域称为“写时复制”（Copy-on-Write），在数据库领域对应“事务”。

笔者认为，可逆执行是四层防御中唯一能在“确认闸门被绕过”时仍然兜底的一层。因为确认闸门依赖人类在场，而长任务常在夜间运行；权限校验依赖策略正确，而策略可能有漏洞。只有存储层的可逆性是不依赖agent行为、不依赖人类响应的最后防线。

3.4 第四层：审计闭环与事后归因

第四层是审计。每一次工具调用都应记录：时间戳、动作类型、目标路径、参数哈希、调用者身份、以及前后状态差异。审计日志应写入独立于agent权限的存储，防止agent篡改。事后归因的价值不仅在于追责，更在于发现“哪一类任务最容易触发删除语义”，从而反哺任务模板与权限策略的迭代。

一个可操作的审计指标是“删除放大比”：单次任务中实际删除对象数与该任务声明需要清理的对象数之比。正常任务该比值接近1，若显著大于1则说明agent扩大了删除范围。把该指标接入告警，可以在下一次事故前获得预警。下表给出四层防御的落地优先级与成本估算（成本为工程经验估计，非精确测算）：

3.5 一份可直接执行的检查清单

把上述四层防御压缩为可勾选的清单，便于团队在接入agent前逐项核对：

1. agent使用独立服务账号，权限与人类管理员隔离；
2. 删除工具不在默认工具集中，需任务级显式批准；
3. 所有写/删路径经过规范化校验，禁止路径穿越；
4. 删除超过阈值或命中受保护前缀时强制人工确认；
5. 确认界面展示系统独立计算的删除清单，而非agent自述；
6. 无人值守任务启用延迟执行窗口，支持取消；
7. 关键存储面开启版本控制/快照/软删除；
8. 工具调用日志写入独立存储，记录前后状态差异；
9. 配置“删除放大比”告警并定期复盘；
10. 长任务设置最大步数与最大副作用预算，超限即中止。

这份清单并不追求“让agent更聪明”，而是追求“让错误更廉价”。笔者认为，这是当前阶段最务实的安全工程取向。关于agent工具调用的安全实践，可参考Anthropic官方的工具使用文档（docs.anthropic.com）与OWASP LLM应用安全清单（owasp.org）。

四、对比与局限：现有方案的边界条件

4.1 提示词约束 vs 权限约束

业界常见的做法是在系统提示词中写入“删除前必须确认”“不要删除生产文件”等约束。这类约束在短任务、单步任务中有效，但在长任务中可靠性下降，因为模型对早期指令的遵循会随上下文增长而衰减，且对抗性输入或异常状态可能覆盖指令。本文评述：提示词约束应被视为“降低误判概率”的手段，而非“防止破坏后果”的手段。把两者混为一谈，是许多agent事故的认知根源。

权限约束的优势在于它是确定性的：无论模型输出什么，策略引擎都会按规则拒绝。其局限在于灵活性——过于严格的策略会阻碍正常任务，导致团队绕过策略。因此策略设计需要“分级”：低风险动作自动放行，高风险动作强制确认，中间地带按阈值动态判定。

4.2 人工确认的可用性边界

人工确认并非万能。在夜间批处理、大规模并行任务、或确认频率过高时，人类会陷入“确认疲劳”，倾向于无脑点击“同意”，确认机制形同虚设。这与安全领域熟知的“告警疲劳”是同一问题。工程上的缓解手段包括：限制单位时间内需确认的次数、对同类确认提供“本次会话内记住”选项、以及把确认设计为“选择删除范围”而非“是/否”二选一，迫使人类进行认知加工。

笔者认为，人工确认的设计目标不应是“增加摩擦”，而应是“在关键节点制造有意义的摩擦”。对删除4.8万个文件这种动作，一次确认是值得的；对删除一个临时文件，确认只会训练人类麻木。

4.3 可逆性的成本与覆盖盲区

快照与版本控制并非没有成本：存储费用、性能开销、以及恢复演练的组织成本。此外，可逆性存在盲区——某些外部副作用无法回滚，例如已发送的邮件、已触发的第三方webhook、已消耗的配额。对于这类动作，唯一可靠的防御是“执行前确认”，因为事后无法撤销。因此，可逆性配置应覆盖“可回滚的动作”，确认闸门应覆盖“不可回滚的动作”，二者互补而非替代。

4.4 学术与工业界的相关进展

近三年，围绕LLM agent安全的研究明显增多，方向包括工具调用沙箱、权限感知规划、以及执行监控。例如有研究提出在agent与工具之间插入“策略中间层”，对每个工具调用做静态与动态检查；也有工作探索用形式化方法描述agent行为边界。本文评述：这些方向有价值，但工业落地仍需解决策略表达力与运维成本的平衡。对多数团队而言，先把“删除工具默认不挂载”做到，比追求形式化验证更能降低实际风险。

在标准与框架层面，NIST的AI风险管理框架（AI RMF）提供了治理层面的参考（nist.gov），MITRE ATLAS则收录了针对AI系统的攻击与失效模式（atlas.mitre.org）。这些资料可作为团队内部安全评审的对照清单。

五、结论与展望：从“赌概率”到“控边界”

回到文章开头的问题：高权限+长任务的组合，是不是在赌agent不会在某一刻选错路径？从概率框架看，长任务中“至少一次误判”几乎是必然事件，因此把安全寄托于“agent不犯错”确实是一种赌博。但赌博并非唯一选项——通过权限分级、删除闸门、可逆执行与审计闭环，可以把“误判”与“破坏”解耦，使系统在agent犯错时仍然安全。此时系统不再赌agent不犯错，而是赌“即使犯错也不会造成不可逆损失”，后者的概率可控得多。

展望未来，笔者认为三个方向值得关注。其一，权限感知的任务规划：agent在分解任务时即感知各步骤所需权限，提前请求授权，而非在执行中动态扩权。其二，副作用预算：为长任务设定“最大删除对象数”“最大写入字节数”等预算，超限即中止并转人工，类似数据库的事务大小限制。其三，可验证的执行轨迹：用结构化日志记录每一步的输入输出与决策依据，使事后归因从“看模型说了什么”变为“看系统实际做了什么”。

最后需要强调，本文引用的48,218与103秒来自公开讨论中的事件转述，未经过独立核实，读者应将其视为风险示例而非精确事实。真正经得起检验的，是文中给出的失效机理与工程路径——它们不依赖具体数字，而依赖权限、时长与不可逆性这三个可观测、可配置的工程变量。把这三个变量管住，agent才可能从“高风险自动化”走向“可控自动化”。

主要参考文献