Matt Shumer 坐在电脑前，给他的 AI 代理下达了一个简单的指令：清理文件。他已经运行过这个程序数百次，从未出过任何问题。然而这一次，一个路径解析错误将一次普通的家务活变成了一场彻底的灾难。数年的代码、文档和照片在几秒钟内消失殆尽。

这并非假设性的风险。它真实地发生在一个开发者的真实机器上，而涉事代理的表现一直看起来万无一失，直到它失败的那一刻。能够编写文件、执行终端命令并生成子代理的 AI 代理现在已嵌入到 IDE、聊天界面和自动化流水线中。它们被赋予了直接访问操作系统的权限，而这种信任恰恰是危险所在。摧毁 Shumer 机器的那些失效模式，存在于每一个拥有工具访问权限的代理中。理解它们为何失败，以及如何妥善约束它们，现在已成为任何使用这些工具的人必备的生存技能。

当模式匹配遇上文件系统

AI 代理并不思考，它们进行的是模式匹配。当你输入“清理文件”时，模型会在其训练记忆中搜索成千上万个类似的交互，并生成一个在统计学上符合该模式的命令。如果指令是删除构建目录中的临时文件，它可能会生成类似 rm -rf /tmp/build-cache/* 的命令。这看起来很合理，因为它与模型见过的所有其他清理命令非常相似。

但当像 $HOME 这样的变量无法解析时，会发生什么？人类看到一个空字符串或一个意外的路径时，会停下来并提出疑问。而代理看到模式仍然匹配，就会按下回车键。在 Shumer 的案例中，一个本应修剪特定文件夹的命令，却瞄准了用户目录的根目录。代理没有停下来思考为什么路径看起来很奇怪，也没有验证目标。它执行了命令，因为执行动作符合“清理”的模式。

这就是大语言模型与系统管理之间的核心错位。真正的推理涉及理解上下文、验证假设和处理边缘情况。而模式匹配涉及生成在统计学上类似于正确答案的文本。当那个答案是一个带有递归删除标志的终端命令时，统计学上的相似性是不够的。

子代理的盲点

许多现代代理框架使用一个主编排器来向子代理委派任务。父代理可能拥有严格的指令：绝不触碰主目录、删除前务必询问、维护审计日志。然后，它会生成一个带有狭窄提示词的执行者，例如“清理旧日志”。

那个子代理通常是在孤岛中运行的。它继承了工具，却没有继承父代理的安全文化。在上下文窗口管理过程中，那些让主代理保持谨慎的约束条件可能会被压缩、总结，甚至被完全丢弃。子代理接收到了任务和工具包，但它并没有接收到那些建立起防护机制的、经过长时间精心设计的提示词。

其结果是一种“组织性失忆”。存在于父代理系统提示词中的安全规则，对于子代理来说可能根本不存在。这是极其危险的，因为子代理通常被分配那些重复性的、低价值的任务，而操作员往往会停止对其进行密切监控。没有人会盯着一个日志清理任务，直到它删除了生产数据库。

果断性的危险

AI 代理的设计趋势正朝着最大程度的自主性发展。在这种愿景下，理想的代理永远不会因为琐碎的问题去打扰用户。它行动果断，将工具调用串联起来，并在不间断的情况下完成多步骤工作流。

这种果断性恰恰是让这些系统变得不安全的原因。一个被程序设定为“果断行动”的模型不会复核自己的工作。当命令看起来具有破坏性时，它不会停顿。它将犹豫视为 Bug，而非特性。当模型正确时，这感觉像是魔法；当它出错时，这感觉像是无情的灾难。系统中不存在任何能够减缓错误命令执行速度的天然阻力。

Shumer 的智能体已经正确运行了数百次。这种过往记录营造了一种虚假的安全感。但如果第 101 次试验是一个模式发生断裂的统计离群值，那么前一百次试验的可靠性便毫无意义。在系统安全领域，只有当失效模式是渐进且可见的时，过往的表现才具有参考价值。AI 智能体的失效往往是突发的、无声的且彻底的。“它运行了数百次”并不是一份安全记录。它只是对运气的一种描述，而运气终究会耗尽。

如何构建真正的保护机制

如果模型本身不是安全层