Olivares AI 会位于我 agent 的请求路径上吗？

不会。发现与访问地图都是基于遥测数据和源生审计，在带外（out of band）构建的，因此 Olivares 的故障不会拖垮您的 agent。唯一位于路径内的，是您显式接入的可选、默认拒绝（deny-closed）的执行闸门——而那里一旦停止状态不可读，也会以拒绝（fail closed）告终，绝不放行。

它能在气隙（air-gapped）环境中运行吗？

Olivares 控制平面可以。您的治理与观测数据始终留在您的边界之内。需要诚实说明的一点是模型推理：像 Claude 这样的托管模型仍会访问其提供方的 API；只有真正可自托管的模型（vLLM、Ollama）才能完全离线运行。

急停开关到底会停下什么？

全集群急停会拒绝该租户下所有受治理的执行面；agent 范围的急停只拒绝单个 agent。它在设计上是读优先（read-first）的——它无法触及您尚未为其接入闸门的执行面。启用代价极低、一键即可；而重新启用则需要双人控制（dual-control）并强制进行事后复核。

面向您基础设施上 AI agent 的驾驶舱

您已经为集群上的其他一切运行着各类仪表盘：主机、队列、数据存储、请求路径。然后，十几个 AI agent 出现了——副驾驶、MCP 服务器、定时任务、某人接到生产环境上的一个 Claude Code 实例—— 而您却没有一个统一的地方来回答运维人员最关心的第一个问题：有什么正在运行，每个东西又究竟能触及什么？

这与无人管理的影子基础设施如出一辙，只不过这些工作负载握有凭据，还能自主行动。在遭遇过 AI 相关数据泄露的组织中，约 97% 缺乏适当的 AI 访问控制（IBM Cost of a Data Breach 2025, Ponemon）。如今业界已经给这个成因起了名字——agent 蔓延（agent sprawl）—— Gartner 预计到 2027 年底将有超过 40% 的 agentic AI 项目被取消（Gartner），原因往往是当 agent 大量增殖后，没有人能够安全地运维它们。

运维人员能获得什么

Olivares AI 是一个开放、可自托管的平台，运行在您 agent 所在之处。它会发现这些 agent，为每个 agent 触及的对象构建一张读/写访问地图，并为您提供治理和审计这些访问的控制能力。对一名 SRE 或系统管理员而言，有五项特性比功能清单本身更重要。

被动式——不在请求路径上

发现是基于遥测数据和源生审计在**带外（out of band）**构建的。健康与可靠性视图是事件总线的消费者，而不是向您的基础设施开启套接字的探测器——存活性由观测到的活动推断得出，而一个停止发出事件的 agent，其本身就是一个信号。由于 Olivares 不是位于您 agent 之前的代理或边车（sidecar），Olivares 的故障无法将它们拖垮。唯一可能位于路径内的执行面，是您选择接入的可选执行闸门，而它们都以拒绝告终（fail closed）。

单一自托管静态二进制文件

它以单一静态二进制文件的形式部署，内嵌 Web 控制台——无需推送 agent 机群，也没有需要照看的控制平面 Kubernetes operator。存储采用纯 Go 实现的 SQLite（多租户场景下使用 Postgres），因此无需与 C 工具链搏斗。您只需安装一个文件，以专用服务用户身份运行它，便拥有了这个驾驶舱。参见安装与自托管。

控制平面运行在您的边界之内，并可在气隙（air-gapped）环境中运行——您的治理与观测数据永不外流。运维人员应牢记一个注意事项：这并不是离线 AI。像 Claude 这样的托管模型仍会访问提供方的 API；气隙意味着您的集群数据留在本地，而非模型在本地运行。只有真正可自托管的模型（vLLM、Ollama）才能完全离线运行。更多内容见安全与架构。

OTel 原生接入

接入路径锚定OpenTelemetry GenAI 语义约定，并与 OCSF、各类 SIEM 格式以及 W3C Trace Context 协同——因此您已经在发出的遥测数据，正是它所读取的遥测数据。一个诚实的边界：Olivares 通过 W3C trace_id 关联您受治理事件的账本（ledger）；它不会存储完整的 OTel span。trace 视图上的持续时间与状态是账本事件的时间窗口，而非重构出的 span 数据。完整的 span 仍留在您自己的 OTLP collector 中，那才是它们该待的地方。Olivares 告诉您谁触及了什么、以及该行为是否被许可——它并不是您 tracing 后端的替代品。（关于它与 LiteLLM/Langfuse 的定位差异，参见对比页面。）

探针与健康，与您运行的任何服务一样

该二进制文件暴露您的编排器早已期待的端点：

GET /livez     liveness  — is the process up
GET /readyz    readiness — is it serving (and not a cold standby)
GET /healthz   setup-exempt liveness for scrapers
GET /metrics   Prometheus exposition

当后端存储不可达时，/readyz 会返回 503 而不是一直挂起，这样负载均衡器会把该节点排空（drain），而不是让它变成黑洞。在此之上，模块 XXII 还会追踪agent 和 MCP 服务器自身的健康状况、SLA 与正常运行时间——什么是健康的、什么已降级、什么又依赖什么——并向您现有的通道（Slack、PagerDuty、SIEM）发出宕机/降级/恢复/SLA 违约的发现项（finding）。它产出信号；但不试图充当您的通知器。

读优先，配备真正的全集群急停

Olivares 在设计上默认侦测（detective）且默认拒绝（deny-closed）。它广泛地观测和治理；但不会广泛地执行。然而，当某个 agent 在凌晨三点出问题时，运维人员需要一个无需繁文缛节就能起效的开关——因此急停开关是真实存在、为实战而生的：

启用代价极低。 管理员级别、一个强制填写的原因、一键即可。在启用时没有审批闸门、也没有二次升级（step-up）——一个要等待法定多数才生效的紧急停止根本不是停止。全集群范围会拒绝该租户下所有受治理的执行面； agent 范围则会在所有可指名该 agent 的执行面上将其停下。
重新启用则不然。 解除急停需要双人控制（dual-control）（两个不同的人），且随后必须进行强制事后复核，并由第三位未参与其中的人员签署。 “集群保持停止”才是安全状态。
它以拒绝告终（fail closed）。 每个执行闸门在每次调用时都会查询实时的急停状态，并在读取出错时拒绝——一个不可读的急停绝不意味着“放行”。

请对范围有诚实的认识：急停的覆盖范围仅限于您已接入闸门的执行面。它无法冻结 Olivares 没有接缝（seam）可以介入的执行面。这是读优先系统刻意做出的取舍——也正是为什么发现与地图要先行。

它是什么——以及它不是什么

它是一个被动式、自托管的驾驶舱：发现 agent、绘制它们的读/写访问、监视它们的健康，并将全集群急停始终保持在一键之遥。
它不是一个路径内代理、一个 tracing 后端，也不是一个会悄悄重连您 agent 的系统。执行是按需选择启用（opt-in）、默认拒绝的——每一处接缝都由您刻意接入。
它是1.0 之前的版本，采用开放核心（open-core）模式。目录中列出了 23 个能力模块；其中约二十个目前已接入，其余处于设计阶段或将在 v1 之后推出。模块参考标明了哪些已上线。
它不是已认证的。Olivares 是朝着 SOC 2、ISO/IEC 42001 和欧盟 AI 法案（EU AI Act）的方向设计的——它并不持有这些认证，也不会声称持有。详见安全了解诚实的现状。
保真度是分级的，并会如实呈现。 在具备源生审计的存储上，读/写覆盖为 clean，在部分文档/向量存储上为 lossy，在无法被动重构的场景下则为 unknown（Redis、SQLite、D1）；按 agent 归因仅在信号支持时为 firm，在共享账户背后则为 approximate。没有任何内容是猜测得来的。参见保真度。

从何处开始

把它跑起来：自托管，然后用快速上手体验一个合成集群。
接入您的第一个信号：连接数据源。
理解模型：已许可 vs 已观测与访问地图。
运维人员相邻的角色：平台工程与安全负责人。