一个常见且合理的自托管技术栈是将 LLM 网关（例如 LiteLLM）与 LLM 可观测性平台（例如 Langfuse）配对使用。如果您已有这样的技术栈，您可能会合理地问是否还需要控制平面。本页诚实地回答这个问题——包括答案为不需要的情况。
TL;DR: LiteLLM 和 Langfuse 关注的是您的应用发出的模型调用：路由、追踪、管理提示词、按调用追踪成本。Olivares AI 关注的是您基础设施中的每个代理及其读写的一切——数据库、对象存储、MCP 服务器、工具、文件——以及这是否与策略允许的相匹配。不同的抽象层级。它们可以组合；我们摄取它们发出的同一 OpenTelemetry gen-ai 信号。
该技术栈的优势所在（请将它用于以下场景）
- LiteLLM——一个统一的、兼容 OpenAI 的网关，位于多个提供商前方：路由、故障转移、重试、虚拟密钥、按密钥预算和速率限制，以及通过其的模型调用的成本核算。
- Langfuse——LLM 工程和可观测性：请求/响应追踪、提示词管理和版本控制、评估、数据集，以及面向开发者的调试链 UI。
如果您的问题是*“检测我的应用的 LLM 调用、调试提示词、并从一个端点管理模型访问”*，这个技术栈非常出色且可自托管。您不需要控制平面来做这些，我们不会假装并非如此。
Olivares AI 在结构上的不同之处
| 维度 | LLM 网关 + 可观测性 | Olivares AI |
|---|---|---|
| 关注单元 | 一次模型调用（提示词→完成） | 一个代理及其读写的每个资源——数据库、对象存储、MCP、工具、文件 |
| 视角 | 在请求路径中（代理/SDK）；看到应用发送的内容 | 带外、读优先；观察遥测、原生审计和内核后端——从不在数据路径中 |
| 真相来源 | 应用/代理报告的内容 | 自报遥测与系统自身账本交叉验证——pgAudit（读 vs 写）、CloudTrail（对象访问）、eBPF 后端 |
| 核心问题 | ”这个提示词做了什么，花了多少钱？" | "这个代理是否使用了未经授权的访问权限？“——Permitted-vs-Observed 偏差 |
| 执行控制 | 网关可以门控模型调用（密钥、预算） | 针对操作和资源访问的 deny-closed 门控：审批、Claude Code 钩子 PEP、MCP 工具门控、紧急停止开关 |
| 审计产物 | 用于调试的追踪/日志 | 仅追加、哈希链式、Ed25519 签名的账本，可离线验证，可导出为 OSCAL 证据包 |
| 部署姿态 | 可自托管 | 自托管或气隙隔离；数据平面永远不离开您的边界；AGPL，源代码可用 |
承重差异在于基准真相。一条可观测性追踪告诉您应用声称做了什么。它无法告诉您代理访问了一个追踪中从未提及的表。Olivares AI 将协作信号与数据平面进行交叉检查，因此”代理触及了什么”是一个经过验证的事实，而非自我报告。
是”和”，不是”或”——我们摄取您的遥测数据
Olivares AI 不是您的网关或追踪工具的替代品，也不想占据它们所在的请求路径。它消费相同的信号：控制平面摄取 OpenTelemetry GenAI 语义约定的 span，即这些工具发出和消费的同一 gen-ai 遥测。因此，健康的架构是：
- 保留 LiteLLM 作为您的模型网关，Langfuse 用于面向开发者的追踪和提示词工作。
- 将 OTel gen-ai 流指向 Olivares AI 作为一个交叉验证来源，让访问地图、偏差检测和账本在上层提供全基础设施的治理层。
何时您不应使用 Olivares AI
诚实是双向的。以下情况您可能不需要此控制平面：
- 您的唯一目标是在一两个应用中追踪和调试 LLM 调用，配一个提示词实验场——单独使用 Langfuse 更为合适。
- 您只需要一个带预算和故障转移的多提供商网关——那是 LiteLLM 的工作，我们与该模式集成而非重新实现。
- 您没有需要治理的基础设施资产：单个服务、单个模型、没有代理接触数据库/对象存储/MCP，也没有审计或监管义务。
Olivares AI 在问题变得全基础设施化且对抗性时展现其价值：哪些代理存在，每个代理实际能访问什么，访问权限在哪里偏离策略，我能否向审计方证明它，以及我能否以 deny-closed 方式阻止错误操作——所有这些都无需将信息发送到他人的云中。