如果您已经投资了 AI 网关或超大规模云服务商的 Guardrails，最诚实的第一句话是：请保留它们，Olivares AI 并非要取代它们。 网关的职责是处理模型调用——路由、缓存、负载均衡、预算管控。Guardrails 的职责是该调用上的内容安全。两者都是真实存在的，都擅长各自的工作，而它们都不是 Olivares 所做的事。
TL;DR：Olivares AI 不是通用 AI 网关：它不缓存、不对模型流量做负载均衡，也不主张任何通用的提供方、模型或路由矩阵。它将路由策略解析为有序的回退链，并具备一条已测量的执行路径——deny-closed，仅通过你所配置的、兼容 Claude Messages 的客户端进行调用，可直接调用或将你自己的网关端点作为 Messages 的基础 URL。在该路径之外，它是治理与证据平面：智能体运行时内的进程内强制、防篡改账本、非人类身份生命周期，以及针对活跃会话的 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）。
如果您的问题是*“为我的应用提供一个连接多个模型的统一端点，附带预算、缓存和内容过滤”*，那个技术栈就能解决，您不需要控制平面来实现这一点。我们与该模式集成；我们不重新实现它。
各产品当前文档记录的内容
于 2026-09-12 在各厂商自己的页面上阅读。以下是所读页面的边界，并非对整个产品的论断，也不是任何排名。
| 产品 | 已记录的智能体相关能力面 | 该页面未涵盖的范围 |
|---|---|---|
| LiteLLM | 代理文档包含以下章节： “Agent & MCP Gateway”, 以及 Guardrails, Policies, Authentication, Budgets + Rate Limits; “Scoped per user and team, with built-in access control” (LiteLLM) | 所读页面记录的是代理（proxy）能力面；不经过该代理的智能体运行时内部强制不在其范围内 |
| Portkey | 其产品列表包含： Agents, MCP Gateway, Guardrails, Security & Compliance; “records real-time API requests, including cost and guardrail violations” (Portkey) | 所读页面是功能概览；未描述覆盖整个资产的“已授权对比已观测”访问地图 |
| Cloudflare AI Gateway | ”An intelligent control plane for your AI applications” — “Connect to any model, dynamically route requests, and manage usage, billing, and logs”, “fallback routing, rate limiting, and safety guardrails” (Cloudflare) | 所读页面是产品概览；未描述该平面的自托管或气隙隔离运行方式 |
| Bedrock Guardrails | ”configurable safeguards” — “detect and filter undesirable content and protect sensitive information”, 可内联使用，或 “directly through the ApplyGuardrail API without invoking the foundation models” (AWS, AWS) | 这些是内容安全页面；智能体身份生命周期、会话中干预与审批不是其主题，页面上没有记录 |
因此旧的表述是错误的。“网关从不了解智能体”在上述页面面前站不住脚：LiteLLM 与 Portkey 都记录了智能体与 MCP 能力面，Cloudflare 称自己的网关为控制平面。仍然不同的是在哪里执行强制以及产生何种记录，这是架构比较，而不是缺失论断。
架构上仍然不同的地方
这是有条件的而非普遍的——每一行仅在左侧条件成立时适用：
| 如果你的智能体… | 那么请求路径类产品 | 那么 Olivares AI |
|---|---|---|
| …只通过代理访问模型 | 在请求处治理它所看到的每一次调用 | 在请求路径本身上增益有限 |
| …也在本地运行并直接访问数据库、对象存储、MCP 或文件 | 看不到不经过它的调用 | 在工具运行之前，于智能体进程内以 deny-closed 方式强制 |
| …需要审计人员可在系统外验证的记录 | 输出请求日志，属于可变记录 | 仅追加、哈希链接、Ed25519 签名的账本，可在系统外验证 |
| …必须在会话进行中被中止 | 并非中止活跃会话的位置 | HITL 审批、break-glass，以及需双人控制才能重新启用的 kill switch |
| …必须在整个生命周期内被识别 | virtual key 是一个预算额度 | 非人类身份生命周期：过期阻断、离职级联、双人控制轮换 |
| …必须留在你的边界之内 | SaaS 平面在其自有云中处理该流量 | 自托管或气隙隔离；数据平面不离开你的边界 |
Olivares 执行路径及其实际边界
Olivares 确实会触及推理，但仅在一个已测量的位置，诚实的描述就是其当前测量本身所记载的：
- 路由
POST /routing-policies/{id}/execute在构造上即 deny-closed，且仅通过兼容 Claude Messages 的客户端进行调用，可直接调用，也可将解析出的网关端点作为 Messages 的基础 URL —— 因此你现有的网关可以充当该端点。 - 策略解析产生有序的回退链。该模块始终解析路由，并且仅通过 executor 端口执行；默认 executor 未接线，因此在运维人员完成组合之前，路由解析不会产生任何提供方调用。
- 两个 deny-closed 范围门与 kill-switch 停止门在 FinOps 预算门之前执行，而预算门在 executor 之前执行。
以及同一记录明确不成立的内容：
- 没有通用的提供方或模型矩阵 —— Claude Messages 协议确立的是一条已配置的路由，而非矩阵；
- 没有集中式密钥托管 —— 提供方密钥字段是引用；
- 没有从控制台发起的执行 —— 控制台解析并测试策略，没有执行调用。
这是对当前源代码的测量，而不是能力验收：现行 claims 记录将本项及其他所有能力保持为已实现且未验收，背后没有任何执行凭据。请将其理解为该路径的形态，而不是已认证的功能。
关于 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-09-12 验证）。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 可观测性。