如果您已经投资了 AI 网关或超大规模云服务商的 Guardrails，最诚实的第一句话是：请保留它们，Olivares AI 并非要取代它们。 网关的职责是处理模型调用——路由、缓存、负载均衡、预算管控。Guardrails 的职责是该调用上的内容安全。两者都是真实存在的，都擅长各自的工作，而它们都不是 Olivares 所做的事。
TL;DR: Olivares AI 不是 AI 网关。 它不路由、缓存、负载均衡，也不位于您模型流量的热路径上，永远不会。它与您的网关并行且位于其后方，作为治理与证据平面：代理运行时内的进程内执行、防篡改证据账本、非人类身份生命周期，以及对活跃会话的 human-in-the-loop / break-glass / kill-switch 控制。您的网关治理请求；Olivares 治理代理及其接触的一切，并向审计方证明这一点。
网关和 Guardrails 的优势所在（请将它们用于以下场景）
这些是成熟且广泛理解的能力，各厂商也清晰地描述了它们：
- AI 网关是模型调用的请求路径管理器。LiteLLM 是一个 “OpenAI Proxy Server (LLM Gateway) to call 100+ LLMs in a unified interface & track spend, set budgets per virtual key/user”（LiteLLM）；Cloudflare AI Gateway 让您 “Connect to any model, dynamically route requests, and manage usage, billing, and logs from one unified gateway”（Cloudflare）；Portkey “records real-time API requests, including cost”（Portkey）。路由、故障转移、缓存、虚拟密钥、按密钥预算、请求日志——这就是它们的领域。
- 超大规模云服务商的 Guardrails 是内容安全过滤器。Bedrock Guardrails “provides configurable safeguards to help you build safe generative AI applications”，能够 “detect and filter undesirable content and protect sensitive information that might be present in user inputs or model responses”——内容过滤器、拒绝主题、词语过滤器、PII 脱敏、上下文验证和自动推理检查（AWS）。
如果您的问题是*“为我的应用提供一个连接多个模型的统一端点，附带预算、缓存和内容过滤”*，那个技术栈就能解决，您不需要控制平面来实现这一点。我们与该模式集成；我们不重新实现它。
它们留下的治理空白
网关看到的是请求。Guardrails 看到的是内容。两者都看不到代理——代理随时间推移的身份、代理在您的数据平面上访问了什么、谁批准了高风险操作，以及这一切是否能在事后被证明。这就是 Olivares 填补的空白。
| 网关 / Guardrails 留下的空白 | 为什么重要 | Olivares AI 提供什么 |
|---|---|---|
| 代理运行时的执行控制 | 网关在请求边界执行控制；它无法阻止一个从未经过它的本地 Claude Code tool-call | 代理内的 deny-closed 进程内 PEP：坚实身份门控、策略处置、实时策略叠加，均在工具运行之前生效 |
| 防篡改证据 | 网关和 Guardrails 产生的是日志——可变的请求记录；审计方需要的是不可变的证明 | 仅追加、哈希链式、Ed25519 签名的账本，可离线验证，可导出为 OSCAL 证据 |
| 非人类身份生命周期 | 网关的”虚拟密钥”是一个预算桶，不是一个经过配置、归属、轮换和注销的身份 | NHI 生命周期：过期→阻断、注销级联、轮换双人控制，绑定到访问地图 |
| 活跃会话干预 | 日志和预算是事后行为；上述评估的工具中，没有任何一个能在会话进行中将其停止 | HITL 审批、break-glass，以及一个紧急停止开关，在双人控制重新启用之前拒绝所有受治理的操作 |
| 全基础设施的基准真相 | 网关只能看到通过它的调用；代理还直接访问数据库、对象存储、MCP 和文件 | 读优先的 R/RW 访问地图和 Permitted-vs-Observed 偏差检测，与原生审计进行交叉验证 |
| 主权 | SaaS 网关和云端 Guardrails 在其云中处理该流量 | 自托管 / 气隙隔离；数据平面永远不会离开您的边界 |
以上这些都不是路由功能。这正是要点：空白不在于更好的路由，而在于请求路径从未设计用于提供的治理能力。
关于 Guardrails 的具体说明：内容安全是一个钩子，不是竞争对手
Bedrock Guardrails 可以通过两种方式应用——在 Bedrock 推理调用期间内联应用，或 “directly through the ApplyGuardrail API without invoking the foundation models”，这适用于 “with any foundation model whether hosted on Amazon Bedrock or self-hosted models”（AWS）。这确实非常有用，而 Olivares 将内容安全视为一个可插拔的检测器，绝不是一道要求您取代 Guardrails 的壁垒。两个诚实且独立的事实：
- 内联推理代理暴露了一个内容检查接缝——一个可插拔的节点，内容/DLP 检测器在此返回裁决，由 deny-closed 决策器据此行动。内容安全属于那里，在管道中，而不是被重新实现为一个竞争性过滤器。
- Olivares 以读优先模式读取 Guardrails 的自身决策。AWS 连接器从 CloudWatch / S3 日志中摄取 Bedrock guardrail 决策，作为安全态势和证据；它刻意不自行调用付费的
ApplyGuardrail运行时。您的内容裁决成为防篡改记录的一部分。
因此，内容安全与您已有的方案形成组合。Guardrails 不记录的——且治理空白仍然存在的——是代理生命的其余部分：Bedrock 文档页面未记录代理身份、会话管理、人工审批和成本治理（在相关页面上未记录，2026-06-21 验证）。Olivares 正是这个补充：它承载身份、会话控制、审批和证据；内容过滤器留在它原本所在的位置。
如何组合
健康的架构让每个工具各守其位：
- 保留您的网关（LiteLLM / Portkey / Kong / Cloudflare）作为模型调用平面——路由、缓存、虚拟密钥、请求级预算。
- 保留您的 Guardrails（Bedrock / Azure Content Safety）作为内容安全检测器——Olivares PEP 在其内容检查接缝处运行可插拔检测器，并以读优先模式读取 Guardrails 自身的决策作为证据；它本身不调用
ApplyGuardrail。 - 在它们旁边添加 Olivares 作为治理与证据平面：针对那些从不经过您网关的代理的进程内 PEP、全基础设施的访问地图、防篡改账本，以及实时 HITL/break-glass/kill 控制。
Olivares 唯一触及推理的地方是狭窄且明确的——一条仅限 API key 的网关路径，用于原始 SDK/curl 调用者，详见治理基于订阅认证的代理。它的存在是为了治理您的其他工具无法覆盖的流量，绝不是为了在路由上与它们竞争，且绝不承载订阅凭证。
何时您的网关就足够了
诚实是双向的。如果您的代理仅通过您的网关调用模型，您的内容安全需求已被 Guardrails 满足，您没有自托管或笔记本电脑上的代理直接访问数据库/对象存储/MCP，且没有主权或防篡改证据要求——那么您的网关加上其日志和 Guardrails 可能就是您所需的全部，您不应该为了拥有而添加控制平面。
Olivares 在问题变得全基础设施化且对抗性时展现其价值：哪些代理存在，每个代理实际访问了什么，我能否在代理处 deny-closed 地阻止错误操作，谁批准了那个高风险操作，以及我能否向审计方交付不可变的证明——所有这些都无需将信息发送到他人的云中。如需深入了解两个相邻的对比，请参阅 vs AI 控制塔和 vs LLM 可观测性。