AIOps AI Agent是什么？

先说结论。AIOps AI Agent 可以理解为运行在 AIOps 数据和运维工具之上的智能体。 它接收告警、指标、日志、链路和变更记录，围绕一个运维目标拆解步骤，调用监控、工单、知识库和脚本等工具，给出有证据支撑的判断与处置建议。在企业设定的权限内，它也可以执行动作，并验证结果。

目前没有一个被标准组织统一认定的 AIOps AI Agent 定义。本文采用一个工作定义，依据来自两处。Gartner 把 AIOps 概括为用大数据和机器学习自动化 IT 运维流程，包括事件关联、异常检测和因果判断。IEEE 对 agentic AI 的描述是，围绕多步目标进行规划，调用外部工具，保留状态，并根据工具返回的结果修改计划。把这两层能力放在一起，才接近企业今天所说的 AIOps 智能体。

这个方向正在从试验走向生产。Gartner 在 2025 年 12 月发布的《Predicts 2026》中预计，到 2029 年，70% 的企业会部署 agentic AI 来运营 IT 基础设施，2025 年这一比例不足 5%。报告同时判断，基础设施与运维团队的角色会从亲自处理问题，转向监督和编排智能体。

AIOps AI Agent 的四层能力

可以把它的能力拆成四层来看。

目标层

它接到的是一段运维任务，例如把一条反复触发的告警处理到可验证的状态，或者解释一次发布后延迟升高的原因。单轮问答通常不足以构成一段完整的 Agent 工作，任务需要能拆成步骤，也需要有完成条件。

感知层

它要能读取指标、日志、链路、事件、工单、变更记录和拓扑关系。数据越分散，感知层越重要。AIOps 平台在这里提供事件关联、异常检测和因果分析的基础，让 Agent 拿到的不只是原始数据，还有经过整理的时间线和上下文。

决策层

它根据目标形成假设，决定下一步查什么，比较哪些证据，什么时候需要升级给人。IEEE 在解释 agentic AI 时提到，规划、工具调用和记忆是这类系统的三项关键能力。放到运维场景，记忆不只是记住对话，还包括记住这次事件已经查过哪些数据、哪些假设已经被排除。

行动层

它可以把结论写回工单，生成复盘初稿，调用脚本或运维接口，也可以只给出建议。行动权限由企业设定，可能停在只读调查，也可能走到人工审批后执行。执行之后还要验证结果，确认服务是否恢复，变更是否需要回滚。

这四层里，感知层决定它能不能看见问题，决策层决定它能不能形成可检验的判断，行动层决定它能走多远。 缺一层，它的输出就容易停留在摘要或建议，难以成为可用的运维闭环。

它和 AIOps 平台、通用 Agent 是什么关系？

Gartner 对 AIOps 的定义是，把大数据和机器学习结合起来，自动化 IT 运维流程，包括事件关联、异常检测和因果判断。Cisco DevNet 在解释 AIOps 时把核心组件拆成数据、AI 和机器学习引擎、动态基线、上下文信息和流程自动化。这个定义落在平台能力上，重点在把多源运维数据变成可判断的信息。

通用 AI Agent 的重点在行动方式。它围绕目标规划步骤，调用外部工具，保留状态，再根据工具返回的结果调整计划。AIOps 平台提供数据和判断依据，Agent 提供目标拆解和多步执行，运维工具提供可调用的动作，权限与审计提供边界。四者合在一起，才构成一个可用的 AIOps 智能体。

可以用一张表区分三个层次。

这张表是本文的归纳，用来区分能力层次，不代表某家厂商的产品分层。不同厂商也会用 Agentic AIOps、SRE Agent、Observability Agent 等名字描述相近能力。判断一个产品是否属于这类能力，可以看三件事，能不能跨数据源取证，能不能调用运维工具，能不能验证结果。名字只能作为线索。

它通常怎么工作？

把一次典型任务拆开，AIOps 智能体通常会走五步。

第一步，接住信号

信号可能是一条告警、一次发布后的错误率上升，也可能是值班人员在工单里写下的问题。Agent 先确认任务范围，例如影响哪个服务、从什么时候开始、涉及哪些环境。范围不清楚时，它需要先问，或者先从数据里补齐上下文。

第二步，把证据串起来

它会把指标、日志、链路、事件、变更记录和拓扑关系放在同一条时间线上。这里的关键是跨系统取证。单看一条错误日志，通常无法判断是代码问题、配置问题还是依赖服务问题。把发布时间、实例变化、流量变化和错误分布放在一起，才更容易找到可检验的方向。

微软在 Azure Monitor 的 agentic operations 文档里，把这类能力和传统异常检测做了区分。传统机器学习更擅长发现异常、做预测和识别模式，agentic operations 还会解释发生了什么变化、有哪些证据支持这个结论、下一步可以做什么。这个区分很重要，因为运维人员需要的往往不只是一条异常提示。

第三步，形成可检验的判断

Agent 会根据证据形成几个假设，再决定查什么来排除。例如接口延迟升高，可能是最近一次发布引入的问题，也可能是下游依赖变慢，或者流量结构发生变化。一个可用的判断需要能指向原始数据，也需要说明不确定性。它可以说目前更像发布相关问题，但还没有排除数据库连接池，不必急着给出确定结论。

第四步，在权限内行动

行动可以很轻，例如把调查结果写回工单、在群里同步时间线、生成复盘初稿。行动也可以更重，例如重启实例、切换流量、回滚发布。不同动作的风险差别很大，权限设计要跟着动作走。高风险动作适合停留在建议或审批，低风险、可回滚、结果可验证的动作才适合自动执行。

AWS 的 DevOps Agent 文档展示了一种产品化路径。它会关联指标、日志和最近的代码发布，识别可能的根因，给出有针对性的缓解建议，并在 Slack 里维护调查时间线和事件协同。值班人员可以追问它查了哪些日志，也可以补充上下文，让它重新分析。这个例子说明，Agent 的价值不只在给出答案，还在把调查过程变得可追踪。

第五步，验证并留下记录

动作执行后，要确认服务是否恢复，错误率是否回落，延迟是否回到基线，是否需要回滚。无论结果如何，这次调查的证据、判断、动作和结果都应该留下来。下一次遇到相似问题时，这些记录可以变成可复用的知识。对运维团队来说，能回放的调查过程，比一段看起来很专业的结论更有价值。

哪些事能交给它，哪些必须留给人？

AIOps 智能体适合处理信息密集、步骤相对固定、结果可以验证的任务。可以用一张表把边界说清楚。

边界不是固定的。它取决于数据覆盖、工具权限、动作风险和企业的审计要求。可以把自治程度分成四级，逐级放开。

• 只读调查。 Agent 可以查询数据、整理证据、给出判断，不能改变任何系统状态。适合第一次试点。
• 给出建议。 Agent 输出处置方案、影响范围和回滚条件，由人决定是否执行。
• 审批后执行。 Agent 准备好动作，经过指定角色审批后调用工具执行，执行过程留痕。
• 低风险自动执行。 只对范围明确、可回滚、结果可验证的动作开放，并配合实时监控和事后审计。

从实践角度看，大多数企业适合从第一级或第二级开始。先用真实事件积累证据，确认它的判断质量和证据可追溯性，再考虑放开执行权限。Gartner 在《Predicts 2026》的报告摘要里提醒，IT 负责人需要为生产环境中的 AI Agent 建立治理、护栏和性能 SLA。IEEE 在讨论 agentic AI 安全时也提到，沙箱、最小权限凭证、动作确认检查点和运行时监控是常见的缓解手段。这些要求听起来偏工程，实际决定了 Agent 能不能被放心地放在生产环境里。

企业什么时候值得引入？

先看四个信号

以下情况出现得越多，AIOps 智能体越可能带来实际价值。

• 告警量已经超过值班人员能稳定处理的范围，关联和去重长期靠人工完成。
• 定位一次问题要在监控、日志、链路、工单和变更系统之间反复切换，证据很难拼成一条完整时间线。
• 一线和二线有大量重复调查，步骤相对固定，处理结果可以验证。
• 企业已经有服务等级目标 SLO、runbook 这类操作手册、变更记录和审计要求，能定义什么算处理成功。

反过来，以下情况更适合先补基础。

• 关键系统缺少指标、日志或链路覆盖，Agent 拿不到足够证据。
• 拓扑关系、服务负责人和变更记录长期失准，调查容易指向错误对象。
• 上线目标只是减少人力，没有明确场景、成功标准和责任人。

试点不要从最危险的场景开始

第一次试点适合选高频、低风险、结果可验证的任务，例如告警摘要、跨系统取证、事件时间线整理，或者复盘初稿。直接让 Agent 自动重启核心数据库，既难以验证，也会把团队注意力引向风险控制，能力评估反而被放到后面。

试点时可以保留一条人工基线。记录试点前的平均定位时间、告警转工单比例、误报率、升级率、变更失败率和证据可追溯率，再和试点后对比。指标不需要多，但要能回答两个问题，它是否减少了跨系统找证据的时间，它的判断是否更容易被验证。只看回答像不像专家，无法判断它是否真的减少了运维负担。

验收看结果，不看演示

一个可用的 AIOps 智能体，至少应该做到三件事。它能说清结论来自哪些数据，它能在权限内调用正确的工具，它能在动作之后验证结果。演示环境里，这三件事都容易做到。生产环境里，数据缺失、权限冲突、工具超时和异常分支才会暴露真实水平。试点验收时，把这些情况放进测试集，比多看几个成功案例更有意义。

如果企业正在建设企业级 Agent 平台，可以把运维智能体放进同一套治理体系。ThinkingAI 的企业级 AI Agent 平台 Agentic Engine 支持 Agent 的创建、管理和多 Agent 协作，也支持私有化部署。ThinkingAI 已服务全球超 1500 家企业，接入产品超 8000 款。放到 AIOps 场景，平台能力需要和运维数据、工具权限、知识库一起设计。任何一项薄弱，都会限制 Agent 的判断质量。

常见问题

AIOps AI Agent 和 AIOps 平台有什么区别？

AIOps 平台负责把多源运维数据变成可判断的信息，典型能力包括事件关联、异常检测和因果分析。AIOps AI Agent 在这些能力之上增加目标拆解、工具调用和结果验证。两者是配合关系，平台提供证据，Agent 推进调查和处置。

AIOps 智能体会自动修改生产环境吗？

取决于权限设计。常见做法是只读调查、给出建议、人工审批后执行。只有低风险、可回滚、结果可验证的动作才适合自动执行。高风险变更、权限调整和安全例外仍然需要人负责。

SRE Agent、Observability Agent 和 AIOps AI Agent 是同一类东西吗？

它们经常指向相近的能力，命名的口径不同。判断时可以看三件事，能不能跨数据源取证，能不能调用运维工具，能不能验证结果。名字只能作为线索，能力边界要看实际产品和权限设计。

数据基础不完整，能不能先上 Agent？

可以先做只读调查、告警摘要和证据整理，但要把数据缺口当成项目范围的一部分。关键指标、日志、链路和变更记录缺失时，Agent 容易给出看起来完整、实际无法验证的结论。先把关键系统的可观测性补齐，再扩大它的任务范围。

大模型变强后，AIOps 平台会被替代吗？

更可能的分工是，模型和 Agent 负责推理与编排，AIOps 平台负责数据治理、基线、证据和工具连接。没有可靠的运维数据，模型能力再强也很难稳定定位问题。两者需要一起建设，单靠模型解决不了数据孤岛和权限问题。

怎么判断一次试点是否有效？

先定义成功标准，再对比试点前后的定位时间、误报率、升级率、变更失败率和证据可追溯率。还要看团队是否愿意继续使用。一个试点如果只能演示，不能进入真实值班流程，就很难说明它有效。

参考资料

• Gartner 对 AIOps 的定义，经 Cisco DevNet 的 AIOps 解释引用：https://developer.cisco.com/articles/what-is-aiops/what-is-aiops/
• IEEE Technology Navigator，Agentic AI：https://technav.ieee.org/topic/agentic-ai/
• Microsoft Learn，Agentic operations in Azure Monitor：https://learn.microsoft.com/en-us/azure/azure-monitor/aiops/aiops-and-agentic-operations
• AWS，AWS DevOps Agent helps you accelerate incident response and improve system reliability：https://aws.amazon.com/blogs/aws/aws-devops-agent-helps-you-accelerate-incident-response-and-improve-system-reliability-preview/
• Gartner，Predicts 2026: AI Agents Will Transform IT Infrastructure and Operations，2025 年 12 月 4 日，经 PagerDuty 页面引用：https://www.pagerduty.com/resources/itops/analyst-report/gartner-predicts-report-2026-ai-agents-transform-it-infrastructure-operations/