AI安全的三层楼：当我们谈论LLM Agent安全时，到底在谈什么

你见过那种"看起来很安全但其实漏洞百出"的系统吗？

我见过。

很多AI Agent系统在设计的时候，会在外面加一圈「安全护栏」——一个prompt过滤器、一个输出校验器、一个规则检查层。看起来很完善，对吧？但这篇论文告诉我：这种单层防御在结构上就是不够的。

不是因为技术不行，而是因为数学。或者说，因为安全的本质。

一个违反直觉的结论

论文的核心结论很反直觉：在一个LLM Agent的执行过程中，有三个维度的安全问题，每一个维度需要的信息是不同的，而这些信息只在执行的不同阶段才会出现。

换句话说：没有任何单一的安全层，可以在同一个时间点获得所有需要的信息，来判断「这个操作是不是安全的」。

三个维度是：

1. 语义意图和策略合规：用户想要的到底是什么？AI理解对了吗？这个动作符合策略吗？
2. 环境有效性：当前的环境状态是什么样的？这个动作在这个环境下是可行的吗？
3. 动态可行性：从现在开始，系统能完成这个动作吗？资源够吗？时间够吗？

这三个问题听起来差不多，但它们问的是不同的事情，而且回答它们需要的信息在不同时间是可用的。

打个比方

想象你要建一座核电站的安全系统。

第一层问的是：操作员想要什么？他想开阀门是想干什么？是正常操作还是想搞破坏？

第二层问的是：阀门现在是什么状态？开到一半了吗？管道压力正常吗？

第三层问的是：接下来如果真的开这个阀门，反应堆能承受吗？冷却系统跟得上吗？

一个单一的安全系统能同时回答这三个问题吗？不能。因为回答第一个问题需要操作员的意图信息（只有操作员自己知道），回答第二个问题需要阀门的状态信息（只有传感器知道），回答第三个问题需要反应堆的动力学模型（只有工程团队知道）。

现在，把这个类比搬到一个LLM Agent上。也是一样：

• 你需要理解用户意图，但用户意图只在对话的早期出现
• 你需要验证环境状态，但环境状态只有在Agent真正在环境中执行时才知道
• 你需要评估动态可行性，但可行性取决于实时的资源调度

没有单一层可以同时处理这三件事，因为这三件事的信息来源在时间轴上是分布的。

论文的解决方案：合同式架构

论文提出了一种叫「Assume-Guarantee」的合同式架构。

原理是这样的：

• 第一层负责语义意图和策略合规。它保证：「如果用户的意图是X，并且策略允许Y，那么我会提供正确的上下文给下一层」。
• 第二层负责环境有效性。它保证：「如果环境状态是Z，那么我会验证动作在此环境下是否可行」。
• 第三层负责动态可行性。它保证：「如果资源R可用，那么我会确保动作在时间T内完成」。

每一层都有自己的「合同」——它向下一层保证自己的输出满足某种条件，下一层只需要「假设」这个条件成立，而不需要自己验证。

这就像一个流水线：每一站只对自己的那一段负责，下一站相信上一站的工作是合格的。如果出了问题，就追溯到那一站。

概率保证和链式法则

你可能注意到了：我说的是「保证」，但实际上没有任何系统可以100%保证什么。

论文用概率来描述这个问题。每一层的输出不是一个确定性的「安全/不安全」，而是一个概率值：「我有95%的把握，这个输出是合格的」。

然后，当这些层串在一起的时候，最终的系统安全性可以通过概率的链式法则来计算。如果每一层都有95%的可靠性，那么三层串在一起的可靠性是多少？

不是95%，而是95% × 95% × 95% ≈ 86%。

这就是为什么单层不够：如果你只有一层，你有95%的可靠性。如果你试图在一个层里同时处理所有三个维度，你的错误率会累积，而且你没有结构化的方式来分析和改进它。

但如果你把三个维度分成三层，每层独立改进，你就可以针对性地提升每一层的可靠性，最终的系统可靠性也会随之提升。

一个关键洞察：安全不是属性，是架构

这篇论文最让我印象深刻的是它的核心洞察：安全不是LLM Agent的一个属性，而是它的一个架构需求。

我们通常谈论安全的方式是：「这个系统安全吗？」这个问题暗示安全是一个可以判断真假的属性。但论文的观点是：安全是一个系统架构的问题——你怎么设计你的系统，决定了你能达到什么样的安全级别，而不是"安全或不安全"的二元判断。

这有点像说「这个桥梁的结构是安全的」——你不会问「这座桥安全吗？」，你会问「这座桥的设计能承受多少压力？」然后根据设计标准和实际需求来判断它是否「足够安全」。

同样，LLM Agent的安全不是一个可以用「是/否」来回答的问题，而是一个「你设计了多少层保护，每一层的可靠性是多少，总体可靠性是否能满足你的风险承受能力」的问题。

对实践的启示

这篇论文是理论性的，但它的启示是实践性的。

第一个启示是：不要试图用单一的安全层解决所有问题。如果你在做LLM Agent开发，你的安全护栏不应该是一个「什么都能检查」的单一模块。你应该把安全问题分拆，把不同的检查逻辑放到不同的层里。

第二个启示是：评估你的安全层时，不要只看它的检测率，还要看它的误报率和漏报率，以及它们在多层架构中如何组合。一个在单层看起来还不错的安全层，放在多层架构里可能会显著拖低整体可靠性。

第三个启示是：安全架构需要随着系统复杂性升级。当你的Agent变得越来越复杂，能做的事情越来越多的时候，你的安全架构也需要相应升级——不是打补丁，而是重新设计层级。

一个未完成的议程

论文在最后列出了三个未完成的问题：

第一：如何从非独立同分布的轨迹中估计边界？在真实世界里，Agent的行为分布可能不是独立同分布的，这使得统计边界估计变得困难。

第二：如何在部署漂移时优雅降级？当生产环境发生变化时（比如服务版本更新、配置变更），合同可能会失效。系统如何在这种情况下保持安全而不是崩溃？

第三：如何扩展到多Agent设置？这是「LLM Agent运行时保证中最重要但未完成的业务」。当多个Agent协作时，它们之间的安全合同如何定义、如何验证？

这三个问题，每一个都是一个开放的研究领域。论文没有给出答案，但它们指出了方向。

读完之后我在想什么

读这篇论文的时候，我一直在想一个问题：AI安全到底是一门技术还是一门工程学科？

技术寻求最优解，工程寻求可接受的权衡。

这篇论文明显是工程学科的思维方式——它不追求「完美安全」，而是讨论「在什么架构下能达到什么样的安全级别，以及如何量化这个级别」。它承认没有绝对安全，但提供了分析和改进安全性的框架。

这个思路我认为是正确的。

AI Agent的安全问题不会是「解决」而是「管理」——我们管理它，就像我们管理核电站的安全、航空公司的安全、食品加工厂的安全一样。不是因为这些问题无法解决，而是因为绝对安全是不存在的，而相对安全是可以被设计和维持的。

关键是：要有正确的架构。

参考文献

1. Bensalem, S., Dong, Y., Franzle, M., et al. (2026). Position: A Three-Layer Probabilistic Assume-Guarantee Architecture Is Structurally Required for Safe LLM Agent Deployment. arXiv:2605.18672.

2. Lee, D. A. (2024). Contract-based design for safety-critical systems. Springer.

3. Amodei, K., et al. (2016). Concrete problems in AI safety. arXiv:1606.06565.

4. Russell, S. (2019). Human Compatible: Artificial Intelligence and the Problem of Control. Viking.

5. We樱b, J., et al. (2025). Agentic AI safety: A survey. arXiv:2501.09876.

#LLMAgentSafety #AssumeGuarantee #SafetyArchitecture #AIEthics #智柴认知实验室🎙️