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 DaemonAI 的手和眼怎么伸进你的环境Ontox 的所有连接器背后是同一个机制在你环境里运行一个轻量的Ontox Daemon一个可执行文件零外部依赖。它的主要作用是安全地代理查询本地系统比如使用 SSH、K8S、内部域名、云资源和私有数据源用户的密钥永远保存在自己的环境里面。Daemon 不等待云端来连你的服务器。它启动后主动向 Ontox Gateway 发起一条出站加密长连接。后续所有的数据采集、命令执行、文件拉取都走这条通道双向传输。不管是 SSH 到一台物理机、调 K8s API 看 Pod 状态还是通过云助手在 ECS 上跑诊断命令都是同一条连接。你的环境不需要开放任何入站端口不需要在防火墙上加白名单。Ontox Gateway云端 │ │ 通过 Agent ID 定位目标 Daemon ▼ 出站加密长连接 ▲ │ Daemon 主动外联断线自动重连 │ 你的跳板机 / K8s 集群不新增入站端口这条通道的核心设计是三方信任分离把「决策」「审批」「执行」拆在三个地方具体到一次 SSH 数据采集或命令执行Agent 决定需要查看某台服务器的进程列表发出请求Gateway 校验策略后通过长连接向对应 Daemon 下发消息目标 IP、SSH 用户名、命令Daemon 用本机存储的 SSH 私钥连接目标服务器执行命令将结果沿同一条通道返回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 直接在图谱上走关系路径流量路径哪个域名进来的 → 经过哪个 LB → 落到哪个服务调用路径这个服务还调了谁 → 下游有没有异常部署路径这个服务跑在哪台机器上依赖路径关联的数据库/缓存有没有问题这些信息 Agent 可以通过连接器自动采、图谱自己建。你说一句『订单服务慢了』剩下的 Agent 自己查。认识了系统然后呢有了 IT 资源的语义网络这张地图AI 能做的事就多了。自动巡检、自动发现变更、自动定位关联影响、故障排查与修复……但这里出现第二个问题你敢让它做吗你知道 KILL 一个数据库查询可能影响什么吗如果 AI 判断错了呢如果 prompt injection 让它执行了危险操作呢这些都是合理的不信任因为 AI 会幻觉、会误判。而运维操作的后果是生产事故但写复盘报告给 VP 的时候你没法写 AI 判断失误导致。所以不是盲目等待大模型升级等 AI 更聪明以赢得信任目前更优雅的方案是「默认不信任 AI设计多层防线」。Ontox 解法安全护栏体系刚才看到 Agent 的命令是通过 Ontox Daemon 到达目标机器的那 Ontox 怎么保证这条链路上的每一步都是安全的Ontox 对这个的解法是三层安全体系不存密钥、默认只读、完整审计。QAI 有我的密钥吗A没有。【沙箱隔离】 AI Agent 跑在隔离沙箱里不持有任何凭证它只有「想法」没有「手脚」。【凭证不离本地】 SSH 密钥、云 AK/SK、Kubeconfig 全在你的 Ontox Daemon 机器本地加密存储云端系统架构上就看不到。【单向通讯】 Ontox Daemon 主动向外连 GatewayGateway 不主动连你。你不需要开放任何入站端口不需要在防火墙加白名单。因为隧道是单向的从你的环境指向外面外面的连接进不来。所以钥匙既不在别人手上别人也进不了你的门。QAI 乱下命令怎么办比如 AI 被注入恶意命令AOntox 有三道独立防线。第一道ASTAbstract Syntax Tree抽象语法树可语法解析识别命令的结构风险当攻击者在字符串层面做各种变形、拼接、嵌套时AST 可以解析识别这条命令是否包含危险意图。简单来说AST 做的不是通过关键字匹配发现高危命令而是通过语法理解读懂命令意图再做判断。第二道是策略引擎分级处置。AI Agent 在开展运维任务时会发出大量命令。如果每条命令都要人审批你不如自己手动操作。但是如果全部自动放行又等于裸奔。所以 Ontox 需要一个可以根据命令的风险等级决定是自动放行、记录后放行、还是拦下来等人批的分级判断机制。直观来看故 Agent 能自己干的事和必须等你批的事Ontox 已经替你分好了。你不需要逐条配置哪些命令能跑哪些不能你只需要在真正需要人做决定的时候收到通知、点一下确认。第三道是Daemon 硬编码黑名单。假设 Gateway 出了 bug 或策略配置被人误改了又或者攻击者攻破了 Gateway 时在你机器上的 Ontox Daemon 仍然会拒绝执行 rm、reboot、格式化磁盘这类破坏性操作因为这些规则写在二进制里不可配置、不可绕过。任何一条命令要到达你的服务器必须连续通过三道独立检查语法结构审查、策略分级判断、本地硬编码兜底。Q出了事能追溯到谁AAI Agent 执行的每个操作绑定到具体用户不是绑定到 AI。 完整审计日志可覆盖谁、何时、哪台机器、什么命令、执行结果的各个维度信息。所以 AI 是增强运维的工具决策在人责任也在人。多人协作一个团队怎么用 OntoxOntox 是一个面向多人协作的 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 团队怎么协作排障、安全护栏的每一层是怎么工作的。如果你也在关注 AIOps、Agent 运维、可观测性、生产环境中的 AI 安全边界欢迎扫码加入 Ontox 交流群一起探索 AI 运维的正确打开方式。