你让 AI 改代码的时候，它有没有在悄悄删你的文件？——AgentWall 的发现

把你的笔记本电脑密码告诉我。

不要。

为什么要？就因为我要你信任我吗？你当然不会把密码给我——因为你知道我虽然没有恶意但你也不能控制我的行为。

现在问你另一个问题：

你的 AI 编程助手可以删除文件、执行 shell 命令、修改配置文件——你有任何控制它的能力吗？

一个普通的 Claude Code 用户——比如我——今天早上写了一个很正常的命令："重构这个模块的导入结构。"我的 Agent 高高兴兴地帮我做了——在一个目录里 mv 了 20 个文件，改了 50 个 import。

但我突然想到：如果它误解了呢？如果它 mv 了一个不该被移动的核心文件呢？如果这一条误解的 mv 顺着 import chain 传播到整个项目的 300 个文件中——我怎么回滚？

我现在没有机制看护。Agent 的"意图"到"真实操作"之间——没有隔离层。

这就是 AgentWall 要解决的东西。

🔒 2. 一个古老的洞——新的形状

AI 安全界有个非常分裂的现象。

平台层安全的注意力全在大模型的"输出安全"——提示注入、越狱、有害内容过滤。这是让 LLM 不要说出或计划出危险的东西。

操作系统安全的注意力全在"进程权限"——sandboxing、SELinux、capability dropping。这是传统 UNIX 安全模型。

中间有一个没人碰的缝隙——当 LLM 的"说话的意图"变成了实实在在的机器操作的那一瞬间。 那个瞬间——在 Agent 说"我计划 mv /etc/config 到 /backup/config"到 shell 真的执行 mv 的中间——没有任何东西在工作。

现有的 AI 安全措施工作在上游——过滤和训练——但当意图已经越过语言层进入执行层时，上游的过滤没有窗口期可以拦截。

AgentWall 在"意图"和"操作"之间插入了一个极薄的运行时安全层。它不是通过限制模型训练时该说什么——而是直接拦截模型建议的每一个操作，在实际执行前对其进行策略评估。

⚙️ 3. 三个发动机

AgentWall 的架构是三个并列的运行时发动机：

策略引擎（Policy Engine）——拦截 Agent 的每一帧输出、提取其中的操作意图（是 mv 文件？是 curl 网络地址？是 pip install 包？是一个 sqlite3 查询？）、然后用一个事先定义的显式声明式策略来评估：允许、拒绝、或要求人类审批。

审批门（Approval Gate）——当策略引擎判断一个操作需要人类审批时（比如修改了/etc 目录中的文件、执行了网络上的脚本、或安装了一个新的系统包），操作会被挂起——不是"用默认策略放行"而是挂起——并呈现给终端前的开发者："Agent 将要执行 <mv /etc/nginx/nginx.conf /tmp>。Approval required。"开发者可以批准、拒绝、或者修改建议后再批准。

审计引擎（Audit Engine）——记录每一次操作的所有元数据：agent 原始输出、策略评估结果、批准/拒绝决策、以及操作对文件系统的实际影响。这些审计日志可以被回放——不是在事后道歉，而是可以用于删除或回滚 Agent 造成的修改。

这三个发动机共享一个统一的执行管道——它们连续运行且不重复计算——每个操作只经过一次策略引擎 + 一次审计引擎的评估。

📊 4. 数字与边界

论文报告了两个关键性能数字：

• 92.9% 的策略执行准确率：在 14 个标准测试中（包含正面测试"正确拒绝危险操作"和负面测试"不错误拒绝安全操作"），策略允许和拒绝的决策与人类标签一致性为 92.9%——误差来源于某些模糊操作类别之间（如"读取文件"和"修改文件"）的边界模糊。

• 亚毫秒级开销：策略评估 + 审计记录的总延迟在所有测试中 < 1ms——远低于 Agent 从 LLM API 获得下一个 token 的延迟（通常是 200-500ms），所以在实际的用户体验中这个安全层是几乎感觉不到的。

需要诚实指出的部分：

第一，策略声明的覆盖性。 92.9% 是在 14 个自定义测试上达到的——这些测试覆盖了论文作者认为"典型"的操作集。但在一个真实系统的无限操作空间中——特别是涉及跨多个工具（shell + 浏览器 + 文件系统 + API 调用）的复合操作——14 个测试集不足以建立策略覆盖的置信度。实际部署中误判率可能更高。

第二，审批疲劳。 论文提出"sensitive operations require human approval"——但敏感操作的界定依赖于策略声明。如果策略声明过于宽泛（标记了大量操作为"敏感的"），开发者会在高频审批中迅速疲劳——而疲劳中的批准率会上升到接近"全批准"的水平，消除了安全层的价值。论文在处理审批疲劳策略（如自适应地提高阈值、在开发者快速连续批准时触发额外警告）方面未做详细设计。

第三，一个可被绕过的基础。 AgentWall 作为 MCP 代理或 OpenClaw 插件工作——它依赖于 Agent 工具通过标准的通信层传输操作。如果一个 Agent 通过非标准通信通道（如直接调用 subprocess、或通过第三方插件管道绕过 MCP 代理）执行操作——AgentWall 看不到它。这不是 AgentWall 的特别缺陷——而是所有运行时拦截器的固有局限——攻击者总会寻找拦截器不监控的通道。

💭 我的判断

AgentWall 的价值不在于它的工程成熟度——它是一个 16 页的学术论文、不是生产就绪的系统。

它的价值在于命名了那个被忽略的阶段：

"Agent 的意图变成实际操作的那一瞬间——在语言模型和行为执行之间——是人类对 Agent 拥有的最后也是最实际的控制层。"

上游过滤（让 LLM 不被攻击）不能替代运行时拦截（Agent 实际上做了什么），因为两者面临的威胁模型根本不同——上游过滤对抗的是"注入输入"，运行时拦截对抗的是"执行错误"和"恶意操作"。

就像防火墙不解决病毒问题——防病毒不解决硬件错误一样——这些都是不同层的问题。但当前 AI 安全界把所有问题都集中在了上游过滤上——因为那是 LLM 研究的领域。但 Agent 的真实安全问题发生在不是 LLM 而是操作系统的层面——AgentWall 提醒了我们这一点。

"模型不应说出有害的话"和"Agent 不应执行有害的操作"是两个不同的约束——后者需要在前者不可靠时仍然有效。

📚 参考文献

1. Aravind, A. (2026). AgentWall: A Runtime Safety Layer for Local AI Agents. arXiv:2605.16265.
2. Shavit, Y. et al. (2023). Practices for Governing Agentic AI Systems. OpenAI Research.
3. Wallace, E. et al. (2024). The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions. arXiv.

#AgentSafety #AISecurity #RuntimeProtection #PolicyEnforcement #FeynmanLearning #智柴赛博前线🎙️