AI Agent 要替你干活，得先读得懂你的环境。

AIOps 的第一步

后台看到有些同学在留言：做 AIOps 我们应该怎么开始？今天我们就聊聊这个。

数百家企业的 DevOps 运维系统落地经验告诉我们：先做标准化，再谈智能化。

要让 AI Agent 替你干活，得让它们先读得懂你的环境。

所以我们的 Agentic Ops 产品思路上来不是直接让你做故障根因分析、成本分析这些高级的能力，而是先辅助大家做好标准化建设，打好基座，画出你们生产环境的一个拓扑图。

这个基座就是我们的语义网络。

构建好语义网络以后，AI Agent 就可以顺着这个图回答这两个问题了：

• 环境里有什么？
• 它们之间怎么连接？

变更/故障影响评估、故障快速定位，全都站在这两个答案上的。

过去为了维护这个网的准确性，我们需要人工配置大量的映射规则，在 LLM 时代可以通过 Agent 的方式来去解决这个问题。

就像人类一样的，LLM 能规模化读懂异构的配置文件、理解半结构化的文本、非结构化的日志，还能把它们和运行时的连接实况互相印证。同样是回答"环境里有什么、怎么连"，出现了一条比维护一大堆映射规则更轻、更准、不需要专人养护的路。

这篇文章讲三件事：

• 为什么 AI Agent 开始参与运维之前，必须先读懂企业的真实环境？
• Ontox 如何从应用配置和运行状态中提取环境事实，并通过证据、置信度和人工确认，把它们组织成一张可信的环境地图？
• 企业需要做哪些准备，多久能够完成第一次摸底，以及最终会拿到一份怎样的环境报告？

一、AI Agent 工作之前，必须先读懂环境

AI Agent 要参与变更、排障和日常运维，首先要回答两个基础问题：

环境里有什么？它们之间怎么连接？

这两个答案决定了后续所有推理的质量。环境理解得准，Agent 才能评估一次变更会影响哪些系统、从一个异常节点追踪可能的上下游；环境理解得不准，后面的推理越复杂，结果反而越容易偏离现实。

但企业通常并不缺少环境数据。

云平台记录了主机、网络和存储资源，Kubernetes 保存了工作负载和编排信息，CMDB 管理着配置项、模型和责任信息，监控系统采集运行指标，应用配置则声明了数据库、消息队列和下游服务。

真正的困难是：这些信息分散在不同系统里，使用不同的格式，描述的也是环境的不同侧面。

一台机器上运行着哪些进程，可以通过系统命令获取；但这些进程共同组成了什么业务系统，未必能从机器属性里直接得到。

一个服务正在连接哪个 IP 和端口，可以从运行状态中观察；但这个目标是数据库、缓存还是另一个业务服务，为什么会产生这条连接，还需要结合应用配置和业务信息才能判断。

因此，AI Agent 需要的不能只是一份资源清单，而应该是一张包含实体、关系、业务语义和证据来源的环境地图。

环境真相来自两个侧面

Ontox 主要从两个侧面理解环境。

第一个侧面是应用声明自己准备做什么。

数据库连接串、Nginx 转发规则、消息队列地址、注册中心配置和服务启动参数，都可能包含应用的依赖信息。这些信息分散在 YAML、JSON、properties、INI、启动脚本等不同格式中，过去通常需要工程师逐份阅读，或者针对不同技术栈编写解析规则。

LLM 可以读取这些异构配置，从中识别服务名称、连接目标、环境标识和引用关系，把不同格式表达的信息转换成统一的依赖线索。

配置的价值在于，它记录的是应用的意图。即使某个低频任务在采集期间没有执行，或者某个备用连接尚未被触发，只要依赖明确写在配置里，就仍然有机会被发现。

第二个侧面是系统运行时实际发生了什么。

Ontox 会采集当前的进程、监听端口和网络连接、应用访问日志，用来观察服务当时正在与哪些目标通信。运行连接可以帮助验证配置中的声明，也可以发现配置文件中没有直接出现的实际通信。

两类证据放在一起，可以得到更完整的视角：

• 配置里声明了，运行时也观察到了，这条依赖有两个来源相互印证；
• 配置里声明了，但采集时没有观察到连接，它可能是低频、备用或者已经失效的依赖，需要保留来源并进一步判断；
• 运行时观察到了，但配置里没有找到对应声明，则需要继续结合进程、端口、注册信息和资源身份确认目标。

这里也需要说明边界。

Ontox 当前采集的是连接快照，不是持续保存全部流量。持续运行的 eBPF 或 Trace 可以更完整地捕获短连接和实际调用，但通常需要额外部署观测组件、申请运行权限，并建设相应的数据处理链路。

Ontox 选择的是更轻的起步方式：通过企业已有的管理通道读取配置和运行状态，不要求用户先部署完整的持续观测基础设施。配置可以补充一部分未出现在连接快照中的低频依赖，但如果一条调用既没有配置证据，又只在两次采集之间短暂发生，当前方案仍然可能遗漏。

这不是对全部历史流量的完整记录，而是一次面向环境理解的摸底：在较低接入门槛下，尽可能还原当前系统、资源和依赖关系，并保留每个结论的证据来源。

如果企业已经建设了 CMDB，其中的资源、模型和责任信息可以成为环境理解的重要输入；如果还没有完整的 CMDB，也可以从现有的 SSH、Kubernetes 和云管理通道开始，建立第一份面向 AI Agent 的环境地图。

业务视角：图是围绕"系统"建的，不是围绕机器

还有一个视角必须说清楚：这张图，是围绕什么建的？

运维的本质，是保障业务的可用性。故障发生时，我们需要回答的问题是「订单系统挂了影响什么」，而不是「某台机器挂了影响什么」。

Ontox 按业务单元建模。3 个互相构成主从或集群关系的 Redis 部署实例，被识别为 1 个缓存系统，再上溯到环境、到业务岛。归并靠的是集群、注册身份这类证据，不是靠跑的是同一个软件。同一套订单系统在 prod、qa、dev 三套环境，用一条链路串起来，一次查询就能拿到全部拓扑。

效果是：你在平台上看到的，是一张业务地图，不是一张资源清单。

二、怎么用上

怎么用上：门槛有多低

到这里，道理都讲通了。但读者心里真正的顾虑是：用起来，是不是要先搭一套语义网络、先建模型、先配一堆采集规则？中小企业哪有这个人。

Ontox 的回答是：不需要。

第一，接入用你本来就有的命令通道。 走 SSH、K8s、阿里云、AWS、腾讯云、火山引擎这些运维本来就在用的管理通道，不需要改造或者迁移你现有工具链，不改应用一行代码。

第二，不需要先会建图。 Ontox 把过去优维积累的运维语义网络建模方式直接内置到产品里面。用户不需要先学会设计 CI 类型。你要做的只是提供接入方式。

第三，节奏是：接入 5 分钟，20 分钟可出报告。 一次摸底，先出系统边界（业务地图），每个系统再深度扫描他们的服务以及依赖关系。

第四，连接器已覆盖场景。 SSH、Ansible、K8s、阿里云、腾讯云、火山引擎这些主流通道都已经支持，开箱即用。如果你的环境里有还没覆盖到的连接器类型，欢迎在评论区或交流群里告诉我们，我们优先排期支持。

实操：一次真实的摸底报告

这次摸底产出的环境地图，也正是变更影响、故障定位这类 Agent 推理时依赖的环境输入。

跑一次摸底报告（Discovery Report），你会依次看到：

第一步，看到业务聚类。 分散在不同机器上的实例，被归并成一个个业务系统，边界是识别加人工确认出来的，不是规则猜出来的。

上面这张截图，就是一次真实摸底后的报告首页。它显示的是系统边界识别结果：哪些机器被归到了一起、形成了什么业务系统、哪些机器跑着什么服务等。

第二步，深扫出依赖图。 每个系统深扫，产出服务依赖、中间件、存储绑定。每一条依赖都带来源：来自配置、来自连接、来自注册中心、来自人工确认。

连接器的具体配置过程，本文不展开，那是另一篇文章的完整教程我们是怎么让 AI Agent 安全进入运维生产环境的。想深入了解安全围栏的，可以回顾 Ontox 的发布文章，那里讲了完整的安全体系，本文不重复。

结尾

去体验一次摸底报告吧，5 分钟接入，20 分钟拿到你的第一份环境答卷。

如果你的环境要上 AI，但还不知道第一步从哪开始，可以在后台留言或私信，申请一次 30 分钟的 AI 运维适配诊断。我们拿你的真实环境走一遍，告诉你适配方案和切入顺序。

现在注册 Ontox，限时免费试用，注册即送 2000 积分。这个量级足够接管一个小规模集群，摸底报告、RCA 排障这些核心场景都能跑，产品核心能力都能过一遍。前往 Ontox控制台直达注册。

如果你也在关注 AIOps、Agent 运维、可观测性、生产环境里的 AI 安全边界，欢迎私聊我加入 Ontox 交流群，一起探索 AI 运维的正确打开方式。