跳至正文

对比

Olivares 的定位所在——我们做集成,而非替代

您的技术栈已经在追踪提示词、监控主机并清点资产。但没有任何一层能回答这个问题:究竟是哪个 agent——绑定哪个身份——真正读取或写入了哪项资源。这正是 Olivares 要填补的空白,而它依靠消费并丰富您现有的运行环境来做到这一点。

全景

每一层看到了什么——又止步于何处

这几类工具各司其职,表现出色。但没有任何一类能单凭自身,把基础设施上一次真实的读取或写入归因到具体的 AI agent。Olivares 正是位于它们之间、面向 agent 的关联层。

LLM 可观测性

例如 LiteLLM、Langfuse、Phoenix

看到
提示词、追踪、延迟与 token 成本——也就是模型在应用层的推理过程。
止步之处
看不到主机层:无法判断 agent 究竟读取或写入了哪个真实数据库、存储或 API。

主机与运行时

例如 eBPF 工具——Falco、Tetragon

看到
主机上的系统调用、进程与网络出站流量,实时呈现。
止步之处
缺乏面向 agent 的归因:只能看到进程和容器 ID,而非具名的 agent 与身份。

AI 控制塔

例如 Datadog AI Agents Console、Microsoft Agent 365、ServiceNow AI Control Tower

看到
覆盖您组织已在使用的各类工具的资产清单、安全态势与工作流。
止步之处
其价值取决于喂给它的清单质量——它们需要底层有一个真实数据源支撑。

Olivares 的定位所在

面向 agent 的读/写层

Olivares 回答了其他工具留白的那个问题,并把答案留在您的边界之内。

谁动了什么,是读还是写

它把您本已发出的各路信号关联成一条关系:这个 agent,绑定这个身份,读取或写入了这项资源——并在观测到的访问与您授予的权限出现偏离时,标记最小权限漂移。

由真实信号融合而成

原生数据库审计、云审计日志、OpenTelemetry、eBPF 与 MCP 内省被协调进同一张图谱——主机层的真实情况与工具调用语义相融合,并归因到具体的 agent。

自托管且厂商中立

访问关系与治理记录始终留在您的基础设施上。没有厂商锁定,也没有强制回传。

集成,而非竞争

它让您保留的工具更强

Olivares 的设计初衷是与您的技术栈并肩工作、让它更好用,而不是要求您拆除任何东西。

位于您的 LLM 代理与追踪之上

它消费 OpenTelemetry,并运行在 LLM 代理和您的追踪之上——补上它们从未被设计去生成的基础设施级读/写地图。

与主机真实情况相融合

它把 eBPF 与原生审计数据流当作信号,将原始主机活动与工具调用语义相关联,从而让一次访问能追溯到某个 agent,而不只是一个进程。

丰富您的控制塔

它以开放格式(如 OCSF)把只读清单、安全态势以及经签名、防篡改的发现结果推送到您的 SIEM、ITSM 和 AI 控制塔——为它们提供真实数据,而非取而代之。

Olivares 是什么——又不是什么

它是什么

  • 面向 agent 的真实数据:哪个 agent 与身份动了哪项资源,是读还是写,以及发生了什么漂移。
  • 自托管、厂商中立,并以 AGPL-3.0 开放核心——完整产品,部署在您的基础设施上。
  • 一个消费您现有信号、并反哺您现有系统的层。

它不是什么

  • 并非要替代您的 LLM 追踪、LLM 代理、eBPF 工具或控制塔——它消费这些信号,并反哺这些系统。
  • 并非护城河。面向 agent 的关联层是一道集成接缝,而非我们声称独占的品类。
  • 并非认证,也并非默认的内联拦截——Olivares 默认以读为先、以侦测为主;强制执行需主动开启并受治理。

定位所在——常见问题

Olivares 会替代 Langfuse 或我们的 LLM 追踪吗?

不会。LLM 可观测性捕捉的是模型在应用层的推理过程——提示词、追踪、token 成本。Olivares 工作在更下一层、即基础设施上:agent 究竟真正读取或写入了哪项资源。它消费 OpenTelemetry,因此是对您追踪的补充,而非竞争。

它会替代我们的 SIEM 或 AI 控制塔吗?

不会。控制塔和 SIEM 的价值取决于喂给它们的清单与发现结果。Olivares 是一个丰富它们的真实数据源——它以开放格式把只读清单、安全态势与经签名的发现结果推送到 Datadog、ServiceNow、Microsoft 以及您的 SIEM。

运行时/eBPF 工具不是已经能呈现这些了吗?

eBPF 工具能看到主机上的系统调用、进程与出站流量,但只能把它们归因到一个进程和一个容器——而非具名的 agent 与身份。Olivares 把主机层的真实情况与工具调用语义、以及每个 agent 的身份相融合,从而让一次访问能追溯到具体的 agent。

它为什么需要自托管?

因为访问关系与治理记录都很敏感。以自托管方式运行,它们就留在您的边界之内;Olivares 不做任何强制回传,并可完全在气隙环境中运行。气隙覆盖的是 Olivares 本身——它的访问地图与治理记录;使用托管模型的 agent 仍会访问其各自提供商的 API。

补上您技术栈缺失的那一层

在您自己的基础设施上部署 Olivares,让它对准您本已发出的信号,即可获得面向 agent 的读/写地图——无需替换任何东西。