企业级 AI Agent 网关：从“三层防御“到“可证明的安全“ **——一名架构师的工程实践与反思**

企业级 AI Agent 网关：从"三层防御"到"可证明的安全"

——一名架构师的工程实践与反思

时间：2026 年 7 月
背景：当 GPT-5 .5可以写代码、Copilot 能操作生产环境时，你的安全架构还停留在 API Key 层面吗？

写在前面

这篇文章不讲概念。它来自于我过去一年多以来在 AI Agent 安全网关上的工程实践——作为架构师，设计和构建了一个三层的 AI 智能体治理网关体系。

我说"三层"不是架构图上的漂亮分层，而是每一层都经历过真实压测、真实攻击样本、真实的"这里设计错了，重来"的循环。

到 2026 年 7 月，这套体系已经完成了：

• G0-G4 全门禁验收通过（项目立项、许可证审核、技术 Spike、证据链、发布门禁）
• Red Queen 验收委员会审查通过
• 全链路交付包自动化产出（含 release receipt、hash 验证、运行时溯源）
• Redis L2 多副本门禁通过 1/2/3 副本压测
• Mythos 红队样本库达到 5794 条，覆盖 OWASP LLM Top 10 全部 10 个轴

但更重要的是，这篇文章会坦诚地分享哪些走对了、哪些还不够，以及一个架构师独立完成这件事的真实边界。

如果你正在评估 AI Agent 安全方案，这篇文章希望能帮你省掉一些弯路。

一、问题空间：AI Agent 给安全带来了什么新东西？

2025 年到 2026 年，做 AI 安全的团队普遍在回答三个问题：

1. Prompt Injection 怎么防？——这是 LLM 自身的安全问题
2. 敏感数据怎么不外泄？——这是数据安全问题
3. Rate Limit 怎么设？——这是容量问题

但 Agent 不再只是"对话"，它开始真正操作生产环境。

当一个 Agent 可以：

• 执行 SQL 查询
• 调用内部 API 修改配置
• 自动部署代码到生产环境
• 跨系统申请访问敏感数据

原本的三个问题就变成了一个新问题：

你怎么证明——不是因为相信模型不会犯错，而是因为架构上就不允许它越权？

这个问题的本质，是把安全从"检测"推向了"证明"。客户要的不是一个号称能防住的系统，而是一套可以复现、可以审计、可以验证的安全证据链。

二、架构决策：三层分离，而非一个大网关

2.1 为什么不是单一网关？

最常见的做法是一个统一的 API Gateway，把安全策略、路由、限流全部放在一层。Kong、APISIX、自定义 Envoy Filter 都是这个路线。

但我选择拆成三层。原因来自对实际攻击模式的观察：

单一网关的问题： 一次绕过 = 全盘突破 策略膨胀 = 性能退化 攻击面汇聚 = 单点失守连锁反应

这不是理论推演。在 Mythos 红队样本库（5794 条用例）中，我观察到针对单一网关的"渐进式绕过"攻击路径——攻击者先用低危请求探测策略边界，摸清规则后再构造绕过 payload。单一网关没有纵深，被摸清就等于被突破。

另一个更务实的理由是：三层可以独立演进，独立压测，独立失效。这在后面压测数据中会被验证。

2.2 三层架构及各自的决策逻辑

第一层：协议网关（Shield）

职责：在协议层做准入控制。

端口：8804（gateway），8805（PMF seal）

设计原则很明确——不分析语义，不解析意图：

请求到达 → 检查 Inflight 水位 → 低于阈值 → 放行（签发 JWT Evidence Token 给下一层） 高于阈值 → 429（带 Retry-After 头部） 请求含已知恶意关键字（rm -rf / cat .env）→ 403

核心取舍是：不做语义分析，所以延迟低且稳定；但因此也拦不住语义层面的攻击。

这不是缺陷，是设计。第一层的目标不是"完美防御"，而是：

• 挡住自动化扫描和低水平攻击
• 在流量风暴时保护下游（admission control）
• 为上层提供可信的准入证据链

生产化迭代：到 2026 年 6 月，Shield 已经完成了 owner path guard（防止误改非 live 配置）、control-plane bridge（向治理面推送遥测事件）、PMF/metrics补齐。每次压测后还会自动验证所有端口是否恢复在线——这也是从一次事故中学到的教训。

第二层：认知网关（Cognitive Gateway）

职责：语义分析和 RAG 注入。

端口：8799

这一层我在早期犯过一个设计错误，值得专门分享。

早期的错误设计：把 RAG 注入和安全检测耦合在同一个路径里。结果是一个复杂请求的 p99 延迟从 200ms 飙升到了 3.8s，而且一旦 RAG 数据库响应慢，安全检测也跟着阻塞。

修正后的设计：分离慢路径（RAG 注入）和快路径（安全检测），用 bulkhead 隔离：

重型 RAG 请求 → 独立 entry limit（默认 2） 超出 → 直接返回 429 而不是排队 不降级 → 只关 RAG 注入，不关安全检测

修正后，安全检测路径的 p99 延迟回到了 200ms 以内。

2026 年 6 月的 further 迭代中，我又加了两层保护：

• 免疫预算系统：当处理能力逼近上限时，主动进入 self-healing 状态（例如暂时关闭重型 RAG 注入）而不是默默降级
• 容量 Episode 资产：每次容量治理事件都物化为本地可追溯文件（episode.json + seal.json），形成证据链

状态语义也做了明确分层：

第三层：治理网关（Gateway Pro）

职责：不做检测，做审批与审计。

这一层是三层中最容易被低估的——因为它看起来只是"加了个审批流"。但在实际攻防中，这一层解决了一个关键问题：模型可以犯错，但审批流不会。

核心机制是 Capability Token——对于高风险操作，Agent 不能直接执行，必须申请短期凭证：

Agent 请求执行写操作 → 创建审批工单 → 人工/策略审批 → 批准 → 签发 60 秒有效期的一次性 Capability Token（nonce 防重放） 拒绝 → 记录审计，返回拒绝原因 未响应 → Token 到期自动失效

关键设计细节：

• Nonce 防重放：每个 Token 有唯一 jti，消费后立即作废，同一个 Token 不能使用两次
• Scope 缩减：批准时可以缩小 Token 的权限范围，而不是批准 Agent 请求的全部权限
• 静默降级：Gateway Pro 不可达时，控制面不会崩溃，而是降级为本地决策
• 审计链：所有审批动作写入可追溯记录，含签名 key ID、actor email、risk level

到 2026 年 6 月，Gateway Pro 还新增了policy adapter机制——允许外部策略引擎（如 OPA）通过 preview-commit 双段接口参与决策，而不必直接写入核心审批流。

2.3 关键架构数据

这是一次完整的三链路压测表现（2026 年 6 月，Prompt3 双风暴联动）：

死循环攻击专项数据（max_inflight=1）：

总攻击 27 次，保护性限流 27/27，模型调用 0 次。

关键观察：三层各有各的失效方式，不会同时被同一流量打垮。Shield 在过载时返回 429，Cognitive 在压力下限流慢路径，Gateway Pro 则根本不受流量冲击影响（它是审批面，不在请求路径上）。

三、真正的挑战不是"写代码"，而是"积累证据"

这是我在这个项目里最深的一个体会。

代码层面，每一层的核心逻辑其实都不复杂，任何中级工程师都能理解。但让系统"可证明安全"所需的证据链，才是真正的工程投入。

3.1 证据体系长什么样

到 2026 年 7 月，交付包中包含的证据层次：

发布门禁证据链： 1. daemon-live 运行检查 → pass 2. p0_7 身份一致性验证 → pass 3. Matrix advisory 扫描 → 通过 4. 全量交付包打包 → 完成 5. release receipt + SHA-256 hash → 归档 每次压测证据： 1. 运行时间戳 + 环境快照 2. 每轮请求的 status 分布 3. 延迟百分位（p50/p95/p99） 4. 主机的 CPU/FD/backlog 时序数据 5. 运行时版本审计 6. 压测后端口健康复验（确认没有遗留问题） 红队证据库： 1. 5794 条 Mythos case（promptfoo/garak/PyRIT） 2. OWASP LLM Top 10 全部 10 轴 strong 覆盖 3. 25 条 detector mapping（0 missed，0 false positive） 4. RAG evidence schema（字段覆盖率 100%）

这不像"功能代码"——它像工程纪律。

3.2 一个具体的例子：max_inflight 的调参

死循环攻击测试中，我设置了max_inflight=1。三轮攻击，每轮 9 次尝试，全部返回 429，模型调用数为 0。

但当初试过max_inflight=3——

max_inflight=1 → 27 次全部 429，0 次模型调用 max_inflight=3 → 6 次 429，3 次模型调用成功

两个数字的差异，是跑出来的经验，不是推导出来的。

max_inflight=1 → 保护更强，但正常用户的慢路径请求也可能被误杀 max_inflight=3 → 正常用户更流畅，但在攻击下会有 3 次真实验证

最终选 1，不是因为 3 不对——而是因为我先测试了 1 和 3，看到了差异，然后根据业务场景决定：这个系统的第一优先级是保护上游模型不受攻击消耗，而不是优化正常用户的慢路径体验。

这个取舍记录在压测报告里，而不是在代码注释里。这就是证据的价值：它记录了当时的场景、假设、数据和决策理由。

四、我不满意的地方——以及我没有解决的问题

坦诚地说出不足，我认为同样重要。

4.1 分布式性能基线缺失

当前所有压测都是在单机上完成的。4096 请求在单机上表现良好，数据清晰。但我无法给出分布式 10 节点下的性能预测。

2026 年 6 月完成了 Redis L2 多副本门禁（验证了 1/2/3 副本场景），这算是一个进步。但离"多节点弹性伸缩"还有距离。

4.2 稳态运行的长时间数据不够

Burst 测试做了，4000+ 请求跑通了。但这些都是分钟级的脉冲测试。系统在 24/7 生产环境下运行一周的延迟漂移、内存泄漏、fd 泄漏情况，我还没有充分的数据。

Shield 的 steady-state soak profile 已经在 2026 年 6 月的 action board 中被列为 P1 项，计划固化 10/30/60 分钟三档 soak profile。但截至本文写作时，这个还处于计划阶段，没有完成。

4.3 特定攻击面的证据不足

在 2026 年 5 月的三网关尽调评估中，10 项演练项评分分布为：

E0 的 4 项不是"没想过"，而是"在当前资源下还没排到"。特别是 AI Agent 横向移动和 sandbox escape，需要模拟完整的内部网络拓扑和隔离环境，单机的投入产出比不够高。

4.4 Gateway Pro 的常驻运行面仍未固化

Gateway Pro 的恢复目录可以识别，daemon-live 和 p0_7 identity consistency 都通过了。但它现在的定位是"可重复补测入口"——还不是默认常驻生产实例。这意味着每次完整交付都需要先拉起 Gateway Pro，跑完验证，再关掉。

这不是一个产品级的部署状态，而是一个 PoC 级的验证流程。要把 Gateway Pro 变成"开机自启、持续在线"的状态，还需要解决配置持久化、健康检查和冷启动恢复的问题。

五、架构师的边界——以及我的选择

做这个项目让我清楚认识到了独立架构师做安全产品的边界。

我能做好的

• 架构设计与快速原型 ✔️
• 攻防场景的工程闭环 ✔️
• 性能压测与基于数据的调参 ✔️
• 端到端交付链的自动化 ✔️

一个人做不了的

• 7×24 生产运维 ❌
• 企业级 SLA 承诺 ❌
• SOC2/ISO27001 等合规审计 ❌
• 企业采购决策中的信任背书 ❌
• 大规模分布式环境下的性能验证 ❌

这不是能力问题，是组织形态的问题。我选择正视这个边界，而不是假装不存在。

基于这个认知的选择

1. 核心技术产出保持闭源：架构决策记录、压测数据、工程取舍笔记——这些是最有价值的资产，不在代码里，在决策记录里
2. 部分能力选择性开源：特定安全检测接口规范、测试工具、以及这篇讨论的架构思路——这些可以开放出来，建立社区认知
3. 从"卖产品"转向"卖经验"：不做全家桶式网关产品，而是做 AI Agent 安全体检和能力评估——帮客户理解自己的 Agent 有什么风险，而不是替他们运维一套网关

六、给同行的话

如果你现在要做 AI Agent 安全，我建议按这个顺序来：

第一步：先做安全体检，再上网关

不了解 Agent 的真实行为模式就上网关，大概率会过度设计或漏掉关键风险点。先扫描：Agent 在调什么 API？执行什么操作？有没有未被审批的高危路径？

第二步：三层可以按需引入

• L1 协议网关挡自动化攻击和流量风暴，大多数团队可以先用起来
• L2 认知网关取决于你是否有 RAG 和语义分析需求
• L3 治理网关等高危操作出现再上，不要提前堆叠

第三步：聚焦证据而非方案

所有 AI 安全网关的代码都在变得越来越像。核心差异在于：

• 你有多少攻击样本？
• 你的测试覆盖了什么场景？
• 你在什么压力下验证过？
• 你的失败模式是否可预测？

这些才是客户真正应该关心的东西，而不是用了什么技术栈。

写在最后

我仍然相信一个人可以做出有深度的安全系统——前提是清楚边界在哪里。

代码能写出来，方案能跑通，压测能出数据。但生产环境需要的信任、合规、持续响应，不是一个开发者能独立解决的问题。这没什么丢人的，反而是诚实的工程判断。

这套三层体系，在单机验证层面已经跑通了从"检测"到"证明"的闭环。下一步——无论是分布式验证、稳态测试、还是特定攻击面的补全——需要的已经不只是代码，而是更多资源和更系统的工程投入。

如果你对这个方向感兴趣，欢迎交流。我的核心价值不是提供一个"完美"的网关产品，而是帮你理解你的 Agent 在实际操作中面临什么样的风险，以及如何分层落地防御。

本文发布于 2026 年 7 月。文中所引用的压测数据、架构数据均来自实际工程记录，部分敏感数字已做模糊化处理，部分名词是内部专用代号。