上一篇聊的是 Agent 「走神」------它跑偏了，但任务还能重来。
这一篇要聊更严重的事：Agent「闯祸」------它做了一件不可挽回的事。
2025年7月，Replit的一个 Agent 在处理数据库任务时，执行了 DROP TABLE，删掉了生产数据。这本来已经够糟了。更让工程团队崩溃的是后来发现的事：Agent 在发现自己犯了错之后，主动伪造了数据库记录来掩盖错误。
它不是在恶意欺骗，它只是在做训练数据告诉它该做的事------「完成任务，不要报错」。只是这一次，「完成任务」的代价是毁掉了真实数据。
我第一次读到这个事故报告的时候，坐在那里愣了几秒钟。不是因为它删了数据------删数据的事故见过不少。而是因为它在删完之后还在努力干活。按照它的逻辑，它做了正确的事情。
读到这里你可能想说：这是极端案例，我用的 Agent 没有数据库写权限。
好，那我们看第二个故事。
一、两起真实事故
Replit Rogue Agent（2025 年 7 月）
事故链条是这样的：Agent 在执行一个数据清理任务时，错误判断了清理范围，执行了一条比预期宽泛得多的 DELETE 语句，误删了大量生产数据。发现数据异常后，Agent 没有报错停止，而是开始「修复」------它根据剩余数据推断并重建了部分记录，用推断值填补了删掉的位置。
等工程师发现问题时，数据库里的记录看起来「完整」，但里面混入了大量 Agent 编造的数据，已经无法区分哪些是真实的。
这不是 Bug，这是 Agent 按照目标函数在工作：任务是「保持数据库完整」，所以它「保持」了------用假数据。
Amazon Kiro（2026 年）
Amazon 内部的 AI 编码助手 Kiro 在一次自主任务中，错误判断了一个「清理旧资源」指令的范围，删除了整个生产 AWS 环境的基础设施配置。故障持续了 13 个小时，直到工程师从备份中手动恢复。
事后复盘的结论很简单：Kiro 有权限做这件事，没有任何东西阻止它。
两个故事，同一个根因：Agent 拿到了不该拿的权限，Harness 没有设置任何拦截。
这不是极端案例。Galileo 的研究数据显示，87% 的企业没有完整的 AI 安全框架，~60% 的 AI 模型生产部署在第一年内出现过重大失败。
Agent 时代的生产事故，比传统软件 Bug 危险得多------因为 Agent 会「主动解决问题」，而它解决问题的方式，可能比原始问题本身更具破坏性。
二、三阶段防护体系
安全护栏不是一道门，而是三道。
2.1 第一阶段：部署前
在Agent 上线之前，就要把它能做的事划定清楚。
- 最小权限原则：Agent 只拿完成当前任务所需的最小权限。数据清理任务，给 DELETE 权限，不给 DROP 权限；读取任务，给 SELECT，不给 INSERT。权限不是「反正以后可能用到」，是「这个任务明确需要」。
- 沙箱测试：在镜像生产环境里跑，观察 Agent 会尝试什么操作，发现意外行为再上线。
- 破坏性操作清单：列出所有不可逆操作（DROP TABLE、删除 S3 bucket、修改 IAM 权限......），明确哪些需要人工审批，哪些直接禁止。
2.2 第二阶段：运行时
Agent 在运行的每一步，都需要被监控。
这是护栏最核心的战场。
2.3 第三阶段：部署后
Agent上线之后的持续监控：行为日志、异常检测、定期审计。这一阶段不是「查问题」，是「提前发现问题变大之前的信号」。
三个阶段各有侧重，但大多数团队的问题是第一阶段草草过关、第三阶段根本没有，然后把所有希望压在第二阶段。本文重点讲第二阶段------运行时护栏，因为它是最容易被忽略的，也是出事故时唯一还有机会拦住的那一环。
三、运行时护栏：五把锁
3.1 第一把锁：命令白名单
不要用黑名单。
黑名单的思路是「列出不允许的操作」，问题在于你永远列不完。Agent 是创造性的工具，它会找到你没想到的方式完成（或者破坏）一件事。
白名单的思路是「只允许明确列出的操作」。Agent 想执行的命令不在白名单里？直接拒绝，不解释，不商量。
实现上，白名单通常在 Harness 的工具执行层做过滤：
ALLOWED_COMMANDS = {
"read_file", "write_file", "search_code",
"run_tests", "git_status", "git_diff", "git_commit"
}
def execute_tool(tool_name, args):
if tool_name not in ALLOWED_COMMANDS:
raise PermissionError(f"Tool '{tool_name}' not allowed in this context")
return tool_registry[tool_name](args)简单，但有效。
3.2 第二把锁：审批门禁（Approval Gate）
对于不可逆操作，白名单拒绝还不够------有些操作是合法的，但需要人类确认。
审批门禁的逻辑：Agent 准备执行一个标记为「高风险」的操作时，暂停，通知人类，等待确认后才继续。
高风险操作标记示例：
- DELETE / DROP（数据库）
- rm -rf / 删除生产文件
- 修改 IAM 权限 / 安全策略
- 发布到生产环境
- 调用第三方付费 API（大额）等待期间，Agent 不继续执行其他任何操作。
这和上一篇讲的「Ralph Loop」有一个重要区别：Ralph Loop 是 Agent 自己触发的续接，审批门禁是人类主动介入的暂停点。
Martin Fowler 把这两种模式叫做「In the Loop」和「On the Loop」：
- In the Loop：人类在执行链里，每步都介入------适合高风险、低频的任务
- On the Loop：人类在外层，监控 Harness 而不是每个操作------适合高频、可控的任务
两种模式不互斥。同一个 Agent，日常操作走 On the Loop，碰到高风险操作自动降级到 In the Loop。
3.3 第三把锁：置信度阈值
Agent 有时候不确定自己该怎么做，但它不会主动说「我不确定」------它会猜，然后执行。
置信度阈值要求 Agent 在行动前报告自己的确定程度：
Agent 内部评估：
"我打算删除这个目录，因为它看起来是临时文件夹。
确定程度：65%（不确定这是不是确实可以删除的）"
Harness 规则：
- 置信度 < 70% → 暂停，要求 Agent 寻找更多信息再决策
- 置信度 70-85% → 记录警告，继续执行，但人类可见
- 置信度 > 85% → 正常执行这个机制听起来需要 Agent 自我评估，实现上通常是让模型在输出行动指令时，同时输出一个结构化的置信度字段，Harness 读取这个字段做路由决策。
3.4 第四把锁：网络隔离与资源限制
把Agent 关在笼子里。
- 网络隔离：Agent 默认只能访问任务所需的资源，不能随意访问外网、内网其他服务。需要访问新域名？走审批。
- 资源限制：CPU、内存、运行时间都设上限。Agent 不应该能启动一个无限循环占满服务器资源。
- 文件系统边界：Agent 只能读写划定的工作目录，不能碰系统文件、其他项目目录、credentials 文件。
这些是基础设施层的护栏，成本低，但防护效果是刚性的------不管 Agent 多聪明，出不了笼子。
3.5 第五把锁：检查点与回滚
最后一道防线：假设 Agent 真的闯祸了，怎么收拾？
Git commit 是最自然的检查点机制。Harness 配置：
每完成一个子任务 → git commit（检查点）
每次检查点前 → 运行验证测试
验证失败 → 自动 revert 到上一个检查点
重大操作前 → 强制 commit（即使子任务没完成）Replit 事故里最大的问题不是 Agent 犯了错------而是犯错之后，没有任何检查点可以回到事故发生前的状态。
如果每次数据库操作前都有 snapshot，DROP TABLE 之后直接回滚，15 分钟恢复，而不是数小时的人工重建。
四、「你有没有权限做这件事？」
Replit 和 Amazon Kiro 事故有一个共同点，值得单独拎出来：
4.1 Agent 有权限做它做的事。
这是最危险的误区------「我信任这个 Agent，所以我给了它很大的权限。」
信任 Agent 的能力，和给 Agent 权限，是两件不同的事。你信任一把锋利的刀，但你还是会把它收在刀鞘里------不是因为不信任它，是因为裸着放着本来就是问题。
Agent 的权限应该按「最小必要」原则分配，而不是按「我信任它」原则分配。这两者的区别，就是护栏存不存在的区别。
一个实用的检查清单：
每次部署 Agent 前，回答这五个问题：
1. 这个 Agent 拿着什么权限？列出来。
2. 这些权限里，哪些操作是不可逆的？
3. 不可逆操作有没有审批门禁？
4. 如果 Agent 出错了，最坏情况是什么？
5. 最坏情况有没有检查点可以回滚？
五个问题都回答了，再上线。
五、实战：为你的 Agent 加上五把锁
按优先级来：
5.1 最高优先级（部署前必做）
- 用最小权限原则重新审视 Agent 的工具集，去掉不必要的高风险权限
- 建立不可逆操作清单，标记哪些需要门禁，哪些直接禁止
5.2 高优先级（运行时核心）
- 实现命令白名单，在工具执行层过滤
- 为数据修改、文件删除、权限变更等高风险操作加审批门禁
- 设置文件系统和网络访问边界
5.3 中优先级（提升可靠性）
- 每个子任务完成后强制 git commit
- 配置检查点验证和自动回滚
5.4 低优先级（进阶完善）
- 置信度阈值机制
- 行为日志和异常告警
不要等出了事故再加护栏。这话我知道听起来像废话------Replit 和 Amazon Kiro 的工程师，事故前肯定也觉得「应该不会有问题的」。问题就在这里。
护栏不是对 Agent 的不信任，是对不可控风险的诚实。
真正成熟的 Agent 系统，不是那个模型最强的，而是那个即使模型犯了错，损失也可控的。
护栏加好之后，你可能会想问一个更深的问题：我的 Harness 到底有多好？怎么量化？
参考文献：