Ontox 正式发布：新一代企业级 Agentic Ops 运维平台

前言

今天，Ontox 正式发布啦～

Ontox 是一个面向多人协作的企业级 Agentic Ops SaaS 运维产品，注册即可体验。5 分钟接入，20 分钟给出系统的扫描报告。让你可以放心把证据收集、依赖追踪、根因分析和修复建议交给 Agent，人类在这个闭环里面只需要做一件事：审核决策。

那 Ontox 具体可以做到什么？Ontox 不是在大模型上面套了个对话窗口，然后每次回答你一段段看起来头头是道、却毫无根据的分析。也不是让你在收到告警后，把事件描述、服务架构、指标趋势、错误日志、Trace记录手动爬回来粘贴给大模型。

即使你把所有手上的运维工具封装成 Skill 给 Agent 调用，但你也无法确保：

• Agent 看到的数据是全面的吗？会不会越界看到不该看到的敏感数据？如何防止Agent执行了不该执行的命令？

• 当告警发生时，Agent 怎么知道如何发起调查直达故障现场？Agent 能不能找到类似的历史故障参考？排障经验如何吸纳到知识库而不会造成知识坟墓？

• 每一次和Agent开展运维活动时可能需要的 CMDB元数据、指标、事件、日志、Trace、系统架构图、企业知识、代码等等多源异构数据源如何进入上下文？

• Agent执行工具时是在本地还是云端？权限如何控制？

• 每时每刻都盯着Agent执行任务以确保Agent按自己预期开展工作吗？

• 人机协作时，Agent 的每一次工作时的任务过程、执行的命令和工具、输出的结果和谁发起的需求、谁审批授权的这些记录都可查可溯源吗？

Ontox 想做的是AI时代的生产系统智能入口，我们采用零侵入工作流的设计理念，无缝兼容你现有的稳健Devops工具链。在你开展日常运维工作时，AI 在Ontox里像一支有经验的 SRE 团队在你身边协助你。

这个AI SRE团队可以在不同的运维场景下：自发的完成需求探索与调研、做运维任务的拆解与规划、实时数据收集、数据分析推理、交叉审核任务执行质量、需求交付汇报等等。

以一个告警排查为例。

• 当人类工程师在对话中用自然语言发起一个排障需求。
• AI SRE团队的协调者Agent会先快速了解告警事件的现况，然后拆解并分派任务。
• 收到委派的采集者Agent会实时获取相关的系统地图，这个地图是通过安装轻量级的Ontox daemon将连接你的k8s容器集群、云平台资源或传统VM和物理机，将你现有的工具平台数据绘成基于本体论建设的语义网络。这个语义网络将过去散落在各个工具平台的资源元数据、指标、日志、链路、代码、变更发布、Kubernetes、云资源、历史故障等多源异构数据翻译成AI直接可读的系统地图。
• 然后负责分析的Agent会结合系统地图的数据链，精准重构故障发生的时间线与上下文现场。它不仅融合了运维专家的经验假设，更结合历史故障进行智能推演，最终自动输出一份时序清晰、证据链完整的根因分析报告。
• 紧接着负责审核的Agent会做证据链推敲、验证、审核。
• 审核通过后协调者Agent才会向人类工程师做最终的根因分析结果汇报与修复建议。
• 最后在人类工程师的审核授权下才执行相关修复动作。

那 Ontox 具体如何做到的呢？

Ontox 解法：基于本体论建设的语义网络

本体论建模：画一张 AI 能直接读的地图

Ontox 用什么画这张关系地图？用本体论建模。

CMDB 和本体论的建模思路完全不同：

CMDB 把 IT 系统当成清单来管，每类资产一张表，关系虽然也存，但藏在关联字段和外键里。AI 要做一次影响分析，得先理解 Schema，再构造 JOIN 查询，每多跳一层就多一层翻译误差。

本体论建模把 IT 系统当成图谱来画，实体和关系同等重要，一条边就是一个事实。关系不需要从表结构里推断，图谱上直接写着「订单服务跑在这台服务器上，调用库存服务，依赖这个 RDS 实例」。Agent 顺着边走一遍，就知道这个挂了会影响什么。

同时图谱上的关系路径天然支持跨域推理。基础设施、应用、配置、人员、告警全在一张图上，Agent 沿着边就能走通整条链路。从告警追溯到服务，从服务追溯到部署，从部署追溯到变更记录，不需要 Agent 再从多个数据源中自己提取推理。

简单说：本体模型是原始数据和 AI 之间的翻译层。 一边把数据库表、监控指标、配置文件翻译成带语义的实体和关系，另一边把这些实体关系直接喂给 Agent 做推理。Agent 拿到的不是散落各处的原始数据，而是一张能直接读的关系地图。

Ontox 带你开箱即用：内置建模和数据采集维护逻辑

内置建模

Ontox 将优维十多年运维产品经验直接内置为 40 多种实体类型，多维度覆盖运维全景。和传统 CMDB 不同的是，Ontox 的建模不是从基础设施出发，而是从业务出发。模型的最顶层是应用系统——它把应用系统部署在各个环境下的负载均衡、服务、数据库、基础设施聚合在一起。从业务出发的模型设计回答的不是这机器跑什么进程，是这些资源在支撑哪块业务。

但从业务角度出发的应用系统聚类只是开头，因为 Agent 真正要排查问题时，还需要沿多条关系路径交叉定位：

• 部署路径：应用系统 → 环境 → 服务 → 部署实例 → 操作系统 → 云主机。这个典型的南北向的部署架构回答的是"应用系统有什么核心服务、这个服务跑在哪台机器上"
• 调用路径：服务 → 调用 → 服务。回答的是"这个服务调了哪些下游、被哪些上游调用"，比如排查"订单服务慢了"，除了看它自身和它依赖的数据库，还要看它调用的下游服务（库存服务、支付服务）是否有延迟放大
• 流量路径：域名 → 负载均衡 → 服务。回答的是"用户请求从哪个域名进来、经过哪个负载均衡落到哪个服务"。这条路看起来简单，但线上排查时经常是突破口，因为可以从入口就能先锁定影响范围
• 依赖路径：服务 → 云数据库 / 云缓存 / 安全组。回答了"这个服务依赖了哪些数据库、缓存、安全策略"

以应用系统为中心，多条路径交叉贯通了系统地图的东西南北向，Agent 才能做有依据的推理——比如"订单服务响应慢了"，先沿流量路径确认是哪个入口进来的请求受影响，再沿调用路径排查上下游服务是否正常，沿部署路径追溯到具体云主机，最后沿依赖路径检查关联的云数据库是否有慢查询。

Ontox内置模型的覆盖范围涵盖了当前主流的部署形态：

• 传统 VM 和物理机
• K8s 容器集群
• 云平台资源

运维团队接入 Ontox 时就不需要从零设计每种资源的建模方式，直接基于这套预定义类型即可表达自己的基础设施。

还有一个容易忽略的设计：本体论里每种实体类型都关联了可执行的操作能力。比如云主机关联了"远程执行命令""拉取监控指标"等操作；K8s 工作负载关联了"查看 Pod 状态""伸缩副本数"等操作。而且这些关联不是写在文档里的静态说明——类型定义里就绑定了实体能调用哪类工具，Agent 在排查过程中看到一个云主机实体，就知道能对它做什么、应该对它做什么。

这在根因分析场景下尤其关键：Agent 沿着关系路径从服务追溯到云主机之后，可以立刻对目标机器执行诊断命令，整个推理-操作链条是连续的、自动的，不需要人在中间接力。

你的环境，多久能被 AI 认识？

与其他 AIOps 产品不同，Ontox 的设计理念是对你现有的工作流完全无侵入，因为迁移这些工具链的成本太高而且没有必要。

我们不会要求用户替换现有 DevOps 工具链，而是连接你已有工具：各大公有云、Ansible、Prometheus、Kubernetes、GitHub、邮件、飞书、钉钉。由于我们的边缘节点Ontox Daemon的存在（下一章节会详细介绍），我们甚至可以对接各种内部系统（如GitLab）。

你需要做的只是选择连接器，伸进你的环境：

Ontox Daemon：AI 的手和眼怎么伸进你的环境

Ontox 的所有连接器背后是同一个机制：在你环境里运行一个轻量的 Ontox Daemon（一个可执行文件，零外部依赖）。

它的主要作用是安全地代理查询本地系统，比如使用SSH、K8S、内部域名、云资源和私有数据源，用户的密钥永远保存在自己的环境里面。

Daemon 不等待云端来连你的服务器。它启动后，主动向 Ontox Gateway 发起一条出站加密长连接。后续所有的数据采集、命令执行、文件拉取，都走这条通道双向传输。

不管是 SSH 到一台物理机、调 K8s API 看 Pod 状态，还是通过云助手在 ECS 上跑诊断命令，都是同一条连接。你的环境不需要开放任何入站端口，不需要在防火墙上加白名单。

Ontox Gateway（云端）
│
│ 通过 Agent ID 定位目标 Daemon
▼
出站加密长连接
▲
│ Daemon 主动外联（断线自动重连）
│
你的跳板机 / K8s 集群：不新增入站端口

这条通道的核心设计是 三方信任分离，把「决策」「审批」「执行」拆在三个地方：

具体到一次 SSH 数据采集或命令执行：

1. Agent 决定需要查看某台服务器的进程列表，发出请求
2. Gateway 校验策略后，通过长连接向对应 Daemon 下发消息（目标 IP、SSH 用户名、命令）
3. Daemon 用本机存储的 SSH 私钥连接目标服务器，执行命令，将结果沿同一条通道返回
4. Agent 拿到执行结果后继续推理——根据上一条结果，自动决定下一步去哪台机器、调哪个工具

工程师不需要登录服务器、复制结果再贴回对话。Agent 直接拿着上一条证据推进下一条调查，整条「决策 → 执行 → 反馈」链路是连续的。

云资源也一样。你通过 Daemon 命令行配进去的云平台密钥，存在 Daemon 本地的加密数据库里；每次 Agent 需要通过云助手调一台 ECS 时，Daemon 先拿一个临时授权令牌去干活，活干完令牌就过期了。

连接器就是这样通过 Daemon 把 Agent 的「想法」变成对目标环境的采配置、读日志、查进程、调 API等等的操作。采回来的结果经过内置模型再自动翻译成实体和关系，喂进语义网络。

采集完成后，Agent 能得到什么？

一套连接器跑完之后，Agent 的语义网络里就有了：

Domain "api.example.com"
→ ROUTES_TO → LoadBalancer "order_backend"
→ ROUTES_TO → ArtifactInst "order-api-v2.3"
→ RUNS_ON → OS "172.30.0.41"
→ HOSTS → CloudVM "aws-i-0abc123"

Service "order-api"
→ CALLS → Service "inventory-api"
→ CALLS → Service "payment-api"
→ DEPENDS_ON → CloudRDS "rds-order-mysql"

你跟 Agent 说"订单服务慢了"，Agent 直接在图谱上走关系路径：

1. 流量路径：哪个域名进来的 → 经过哪个 LB → 落到哪个服务
2. 调用路径：这个服务还调了谁 → 下游有没有异常
3. 部署路径：这个服务跑在哪台机器上
4. 依赖路径：关联的数据库/缓存有没有问题

这些信息Agent可以通过连接器自动采、图谱自己建。你说一句『订单服务慢了』，剩下的 Agent 自己查。

认识了系统，然后呢？

有了IT资源的语义网络这张地图，AI 能做的事就多了。

自动巡检、自动发现变更、自动定位关联影响、故障排查与修复……

但这里出现第二个问题：你敢让它做吗？

你知道 KILL 一个数据库查询可能影响什么吗？ 如果 AI 判断错了呢？ 如果 prompt injection 让它执行了危险操作呢？

这些都是合理的不信任，因为 AI 会幻觉、会误判。而运维操作的后果是生产事故，但写复盘报告给 VP 的时候，你没法写 AI 判断失误导致。

所以不是盲目等待大模型升级等 AI 更聪明以赢得信任，目前更优雅的方案是 「默认不信任 AI，设计多层防线」。

Ontox 解法：安全护栏体系

刚才看到 Agent 的命令是通过 Ontox Daemon 到达目标机器的，那 Ontox 怎么保证这条链路上的每一步都是安全的？

Ontox对这个的解法是三层安全体系：不存密钥、默认只读、完整审计。

Q：AI 有我的密钥吗？

A：没有。

【沙箱隔离】AI Agent 跑在隔离沙箱里，不持有任何凭证，它只有「想法」没有「手脚」。

【凭证不离本地】SSH 密钥、云 AK/SK、Kubeconfig 全在你的 Ontox Daemon 机器本地加密存储，云端系统架构上就看不到。

【单向通讯】Ontox Daemon 主动向外连 Gateway，Gateway 不主动连你。你不需要开放任何入站端口，不需要在防火墙加白名单。因为隧道是单向的，从你的环境指向外面，外面的连接进不来。

所以钥匙既不在别人手上，别人也进不了你的门。

Q：AI 乱下命令怎么办？比如 AI 被注入恶意命令

A：Ontox 有三道独立防线，第一道 AST (Abstract Syntax Tree，抽象语法树) 可语法解析识别命令的结构风险，当攻击者在字符串层面做各种变形、拼接、嵌套时，AST可以解析识别这条命令是否包含危险意图。简单来说，AST做的不是通过关键字匹配发现高危命令，而是通过语法理解读懂命令意图再做判断。

第二道是策略引擎分级处置。AI Agent 在开展运维任务时，会发出大量命令。如果每条命令都要人审批，你不如自己手动操作。但是如果全部自动放行，又等于裸奔。 所以 Ontox 需要一个可以根据命令的风险等级，决定是自动放行、记录后放行、还是拦下来等人批的分级判断机制。直观来看：

故 Agent 能自己干的事和必须等你批的事，Ontox 已经替你分好了。你不需要逐条配置哪些命令能跑哪些不能，你只需要在真正需要人做决定的时候收到通知、点一下确认。

第三道是 Daemon 硬编码黑名单。假设 Gateway 出了 bug 或策略配置被人误改了，又或者攻击者攻破了 Gateway 时，在你机器上的 Ontox Daemon 仍然会拒绝执行 rm、reboot、格式化磁盘这类破坏性操作，因为这些规则写在二进制里，不可配置、不可绕过。

任何一条命令要到达你的服务器，必须连续通过三道独立检查：语法结构审查、策略分级判断、本地硬编码兜底。

Q：出了事能追溯到谁？

A：AI Agent 执行的每个操作绑定到具体用户，不是绑定到 AI。完整审计日志可覆盖谁、何时、哪台机器、什么命令、执行结果的各个维度信息。

所以 AI 是增强运维的工具，决策在人，责任也在人。

多人协作：一个团队怎么用 Ontox

Ontox 是一个面向多人协作的 Agentic Ops 产品。它不是一个人的工具，团队里的成员都可以在同一个房间内跟 SRE Agent 对话，共享同一个语义网络。

凌晨三点，值班 SRE 小王收到告警，在群聊里问 AI Agent Captain：「api-service 延迟高了」。Captain 调度 Collector 去采集数据、Architect 分析定位，5 分钟后给了诊断结论和修复建议。小王审批了修复操作，问题解决。

早上九点，团队负责人老李打开同一个群聊，看到的不只是小王的对话记录，而是结构化的排障过程。Agent 采集了哪些数据、分析了哪条链路、定位到什么根因、执行了什么操作、操作结果是什么，这些都不需要小王写复盘报告，排障过程本身就是一份完整的记录。

知识沉淀也不需要人来做，因为 Agent 自动把这次排障的根因、修复步骤、验证结果沉淀为一条知识，其他团队的工作空间下次遇到类似问题时可以命中。从「一个人的经验」变成「团队的资产」。

Agent 团队

有了基于本体论建设的语义网络（地图）和安全护栏（围栏）后，AI SRE 团队就可以在上面稳健地跑起来了。不是一个人跟一个 AI 聊天的对话窗，而是你的工作空间里住着多个 Agent，各有各的职责。

Captain 负责理解你的意图和调度，Collector 负责安全地采集数据，Architect 负责分析推理，Supervisor 负责审批高危操作。

Captain 收到「api-service 慢了」→ 从运维本体查到关联 mysql-prod-02 → 派 Collector 去采集 → Architect 分析定位根因 → Supervisor 审批操作 → Captain 回复你。

知识库：越用越聪明

前面讲了 Ontox 怎么理解你的系统、怎么安全地帮你干活。

但还有一个问题：每次新来一个排障任务，Agent 都是从零开始。上周排过的故障、写过的 Runbook、确认过的根因，下次碰到类似症状的时候，Agent 不记得了。

这也是当前所有 AI 工具的通病：会话结束，记忆清零。

Ontox 的回答：排障的过程本身就产知识，不需要另外写文档。

每次排障，Agent 在工作中自动维护一份结构化的排障记录——当前排查到哪了、关键发现是什么、下一步要做什么。这份记录不是让你停下来写文档，是 Agent 边干活边产生的。

排障结束后，你觉得这次结论有价值，那就手指点一下保存，经你确认后进入长期知识库。不会走全自动进知识库，避免垃圾知识堆积；不能走全手工记录，因为没人愿意写文档。Ontox更加有机的协作方式是：Agent 负责产生知识，你负责确认。

这些知识沉淀在哪里？和你的凭证一样——存在你环境里的 Ontox Daemon 本地，不上传云端。 你的排障经验、SOP 文档、架构信息，是你团队最核心的运维资产，我们没有理由、也没有路径看到它们。这和大多数 AI 工具把聊天记录和知识库存在云端的做法是两种完全不同的信任模型。

同时，你已有的 SOP 文档、架构文档、排障记录也可以直接上传，Agent 排障时直接引用。不是替代你现有的知识资产，而是让它们在排障场景里真正被用起来。

知识库功能开发中，即将上线，敬请期待。

实战预览

场景一：凌晨故障排查

痛点：凌晨三点告警响了，api-service 响应延迟飙升，你睡眼惺忪地打开电脑。

场景： 你在群聊里跟 Agent 说「api-service 慢了」。

Agent 沿着拓扑图自动走：从域名查到负载均衡器，从服务调用链查到下游依赖，从部署路径查到具体机器，10 分钟后告诉你「mysql-prod-02 连接池打满，两小时前有人改过 max_connections」。

修复建议弹出来，你点一下确认，问题解决。

早上九点，团队负责人打开群聊看到的是结构化的排障记录——Agent 采集了什么、分析了什么、定位了什么根因、执行了什么操作，一目了然。

故障排查实战

故障现场：Prometheus 监控显示 shipping-service 和 order-api 同时返回 HTTP 503，流量下降约三分之一，成功率骤降，数据库连接错误激增

初步发现：AI Agent 接手后迅速发现它们共享同一个数据库。

交叉验证： AI 自动交叉验证所有证据，形成完整故障时间线，检索已知方案，完成 RCA 后回传给你确认。

人工确认：你不确定，邀请团队的网络工程师加入群聊一起介入。新加入的网络工程师审查同一线程（指标、终端输出、诊断结果），无需交接会议。

修复执行：确认修复方案后，Ontox 拦截命令并发起人工审批。

结果汇报：你授权执行修复命令，Agent执行修复后汇报服务的修复状态

场景二：接手黑盒新环境

痛点：你刚加入一个团队，面对一堆服务器、K8s 集群、云账号，不知道系统长什么样。

场景： 当你配置好连接器后，你只需跟 Agent 说「帮我了解一下这个环境」。

Agent 调度连接器自动采集，半小时后你拿到一张拓扑图：这个系统有哪些服务、跑在哪台机器上、谁调用谁、依赖哪些数据库，全部自动映射，不需要你写一行脚本。

场景三：季度成本优化

痛点：季度末财务问你云资源花了多少钱，哪些可以省。你不知道从哪开始。

实战： 你跟 Agent 说「帮我看看哪些云资源是浪费的」。

Agent 扫描所有云资源，标出闲置机器和低利用率实例，给你一份候选清单。

你选了几台想试试看，Agent 自动进入隔离观察期——iptables 断开网络但不删除，观察 7 天确认没有影响。

确认安全后，你审批删除，Agent 自动清理资源、释放 EIP、更新 DNS。整个过程你做的只有一件事：选择哪些进入观察期，最后审批删除。

场景四：知识复用

痛点：上周排查过一次 DNS 解析慢的问题，这次又有类似症状，但上次的同事不在，没人记得细节。

实战： 你跟 Agent 描述症状，Agent 直接命中上次的排查记录：「上次是 CoreDNS 缓存配置问题，配置文件在 /etc/coredns/Corefile，建议直接检查同一个配置项」。

你不需要重头来，不需要翻聊天记录，不需要问同事。

运维本体是 AI 的地图，连接器是 AI 的手脚，安全护栏是 AI 的边界，知识库是 AI 的记忆。这四个东西不是独立的功能，是让 AI 在你的系统里安全地工作的夯实地基。

免费试用

Ontox 限时免费试用！注册即送 2000 积分，足够接管一个小规模集群，可以跑采集的摸底报告、RCA排障等核心场景，体验全部产品核心的能力。「你的系统，值得被 AI 理解。」 前往

立即体验 Ontox

预告

后续我们会继续分享 Ontox 的更多设计细节和使用案例，比如运维本体怎么自动构建、Agent 团队怎么协作排障、安全护栏的每一层是怎么工作的。