原文：https://mp.weixin.qq.com/s/tVgKGDzCVaaR9S0xQ-M1Cw
为什么安全是 Agent 架构的核心问题？
前四篇讲的------记忆、工具、执行循环、多 Agent 协作------都在回答一个问题：Agent 怎么变得更能干？
这篇要回答的问题是：Agent 变强之后，怎么防止它做它不该做的事？
这个问题比普通软件的安全问题更难，因为 Agent 有一个普通软件没有的特性：它的行为由语言模型决定，而语言模型会处理大量来自外部的文本------文件、网页、API 响应、用户消息......
任何进入模型上下文的文本，都可能包含恶意指令。攻击者不需要破解系统，只需要让模型读到一段精心设计的文字。
OWASP 在 2026 年发布的《Agent 应用十大安全风险》里，把这类攻击（Agent Goal Hijacking，Prompt Injection）列为第一位。
2026 年已经有大量真实案例：代码注释里藏着的恶意指令让 Agent 泄露了 SSH 密钥；恶意 Markdown 文件让 Agent 发送了未经授权的邮件；GitHub 仓库里的 README 劫持了 Agent 的操作权限......
安全不是可选项，是 Agent 架构的基础设施。
三个框架对这个问题，给出了截然不同的防御纵深设计。
Agent 安全的四个核心战场
在拆解三个框架之前，先明确 Agent 安全要防的四类攻击：
Prompt Injection（提示注入）：攻击者把恶意指令嵌入 Agent 会处理的内容里（文件、网页、工具返回值），让 Agent 把这些指令当作合法命令执行。
凭证泄漏：Agent 执行代码或访问外部服务时，意外把 API Key、SSH 密钥等凭证暴露给攻击者控制的服务器。
权限提升：利用 Agent 的工具访问权限，执行用户本没有授权的操作------比如读取工作目录之外的系统文件，或者执行删除命令。
供应链攻击：通过恶意的 Skills 插件、MCP 服务器、外部工具包，在 Agent 的执行环境里植入恶意代码。
三个框架的安全架构，本质上都是在这四个战场上构筑防线------只是深度和策略各不相同。
OpenClaw：最大开放，安全靠配置
设计哲学：信任用户，安全边界由用户定义
OpenClaw 的安全哲学是 Unix 式的：给 Agent 最大的能力，让用户自己决定边界在哪里。
这个哲学的代价，在 2026 年初暴露得非常清楚：
安全研究人员发现超过 13.5 万个暴露在公网的 OpenClaw 实例，其中 63% 完全没有身份认证。ClawHub 社区技能市场里，Snyk 找到了 1,467 个恶意 Skill，91% 同时包含 Prompt Injection 载荷和传统恶意代码。
这些不是 OpenClaw 的 bug，是"默认开放"这个设计哲学的必然结果。
权限模型：六层级联，但默认宽松
OpenClaw 有六层级联的权限策略（全局 → 模型提供商 → Agent → 群组 → 沙箱 → 子 Agent），设计本身是健全的。
问题是默认值：
默认没有 Shell 命令白名单，没有需要审批的操作清单，没有凭证访问限制。用户从零开始安装 OpenClaw，得到的是一个对本机拥有近乎完整权限的 AI Agent。
把安全配置的责任交给用户，意味着安全质量依赖于用户的安全意识。 在大多数用户不了解 Agent 安全风险的前提下，这产生了大规模的安全隐患。
供应链风险：ClawHub 是开放的
ClawHub 是 OpenClaw 的技能市场，任何人都可以上传 Skill。没有强制性的安全审核流程，用户安装 Skill 相当于执行未知第三方的代码，拥有主机的完整权限。
2026 年初的 ClawHavoc 事件让这个问题变得具体：数百个 Skill 里植入了 Atomic Stealer 载荷，偷走了 API Key，并把恶意内容写入了 MEMORY.md 和 SOUL.md，实现跨 Session 的持久化控制。
Claude Code：纵深防御，沙箱是核心
设计哲学：把安全编码进架构，不依赖用户配置
Claude Code 的安全设计出发点和 OpenClaw 完全不同：用户不应该需要成为安全专家，才能安全地使用 Agent。
这意味着安全控制必须内置在架构里，而不是留给用户去配置。
沙箱：OS 级隔离
Anthropic 在 2026 年发布了 Claude Code 的沙箱功能，这是安全架构里最重要的一层。
沙箱基于 OS 级原语（Linux bubblewrap / macOS Seatbelt）实现两种隔离：
文件系统隔离：Agent 只能读写当前工作目录，无法访问系统文件、用户家目录的其他部分、SSH 密钥等。这不只是 Claude Code 的限制，而是操作系统级别的限制------任何由 Claude Code 派生的子进程也受同样约束。
网络隔离：所有网络请求必须通过沙箱外的代理服务器，代理只放行预先批准的域名。Agent 无法直接建立到未知主机的连接。
这两层隔离的价值在于：即使 Prompt Injection 成功，攻击者能造成的损害也被限制在沙箱范围内。 被攻陷的 Agent 无法偷走 SSH 密钥（文件系统隔离），无法向攻击者服务器发送数据（网络隔离）。
Anthropic 内部测试：沙箱在保证安全的前提下，把需要权限确认的操作数量减少了 84%------更安全，干扰更少，这是反直觉但正确的结论。
Hermes Agent：保守默认值 + 多层扫描 + 容器隔离
设计哲学：从保守出发，主动发现风险
Hermes Agent 的安全设计哲学和 OpenClaw 形成了鲜明对比：默认保守，逐步开放，每个高风险能力都需要显式声明。
上下文文件扫描：在注入发生前拦截
Hermes Agent 有一个 OpenClaw 和 Claude Code 都没有的机制：在上下文文件加载进系统提示之前，对文件内容进行 Prompt Injection 扫描。
每次启动时，AGENTS.md、SOUL.md等文件在注入上下文之前，都要经过扫描器检查。
这是预防性防御------不是等 Prompt Injection 发生后尝试应对，而是在内容进入上下文之前就把可疑内容过滤掉。
同样，写入 MEMORY.md 和 USER.md 的内容也会经过相同的扫描。攻击者无法通过污染记忆文件来实现跨会话的持久化控制。
容器后端：把安全边界下推到基础设施
Hermes Agent 最彻底的安全设计，是把执行隔离下推到容器层：
Docker 后端的隔离配置：只读根文件系统（可选）、所有 Linux Capabilities 丢弃、PID 限制防止 fork bomb、命名空间隔离。
关键的架构决策：当运行在 Docker/Modal/Daytona 后端时，危险命令审批检查被跳过。 因为容器本身就是安全边界------容器内的破坏性命令无法影响宿主机。
这是一个值得学习的设计思路：把安全责任从应用层转移到基础设施层。 应用层的检查依赖模式匹配，可能被绕过；容器层的隔离是操作系统级别的约束，更难绕过。
Agent 安全设计的核心取舍
取舍一：默认开放还是默认保守
OpenClaw 选择默认开放，降低了入门门槛，代价是大规模安全事件。Hermes Agent 选择默认保守，每个高风险能力需要显式声明，代价是初始配置更复杂。
这不只是设计偏好，是对用户群体的判断------是假设用户有安全意识，还是假设用户没有？对于面向普通用户的产品，假设用户没有安全意识是更负责任的选择。
取舍二：应用层安全还是基础设施层安全
OpenClaw 的安全主要在应用层（提示词、配置）。Claude Code 把安全下推到 OS 层（bubblewrap/seatbelt）。Hermes Agent 把安全下推到容器层（Docker）。
基础设施层的安全比应用层更难绕过------Prompt Injection 可以欺骗 LLM 忽略应用层的指令，但无法让操作系统撤销文件系统隔离。
取舍三：安全与能力的张力
沙箱让 Agent 更安全，但也限制了某些能力------比如访问系统级工具、管理系统服务。
这是一个根本性的张力，没有完美解法。实践上的合理策略是：先在最严格的沙箱里运行，只有在遇到能力限制时才逐步放开，而不是从宽松开始逐步收紧。
五篇下来，这个系列完整覆盖了 Agent 架构的五个核心层次：
记忆系统 → 状态怎么存、取、管工具系统 → 能力怎么扩展、权限怎么约束执行循环 → 任务怎么规划、执行、从错误里恢复多 Agent → 多个 Agent 怎么分工、通信、避免互相添乱安全可控性 → 自主性和控制权怎么共存三个框架------OpenClaw、Claude Code、Hermes Agent------代表了三种不同的架构哲学和取舍方式。
没有哪一种是绝对最好的，选择哪种取决于你的场景：你的任务是什么、你的用户是谁、你能接受多少风险、你愿意投入多少维护成本。
但无论选择哪个框架，有一件事是不变的：
Agent 变强的速度，远快于我们理解如何安全使用它的速度。
建立安全意识，从理解架构开始。