假设你是电商系统的运维负责人。凌晨两点，告警响起：订单服务出现大量失败，用户无法下单。

你强撑着打开观测云错误中心，看到满屏的 Redis command timed out 和 inventory-service 异常。接下来你要做的是在 Trace 链路中逐层下钻，再去查 K8s 状态、Pod 日志、指标曲线；定位根因后，手动执行恢复命令；恢复之后心里没底，不知道系统是不是真的好了；整个过程散落在各个平台，没有记录，第二天早会上说不清到底做了什么。

这个流程里的痛点，其实非常典型：人工操作容易误判，缺乏系统性的验证手段，更谈不上形成审计闭环。说白了，就是又累又容易出错，还留不下什么痕迹。

一条自然语言指令，开启自主调查

不需要写复杂的 DQL，也不需要在这几个仪表盘之间来回切换、反复比对。

你只需打开 Guance AI Agent Teams，在 Agent 工作台输入一段话：

"请调查'观测云优选系统'当前出现的订单失败。分析最近30分钟的错误日志、链路和指标；使用只读工具检查 K8s 工作负载、Pod 日志和发布状态；定位异常服务、调用链路、根因和影响范围；给出关键观测证据和建议的恢复方案。"

然后，按下回车。

Agent 便开始自主调查：它会读取真实的日志、Trace、指标，同时调用受控的 MCP 去检查 K8s 工作负载状态、Pod 日志和发布状态。整个过程，就像你身边多了一个不知疲倦的运维老手，立刻开始分头排查。

受控 MCP：有边界，才有安全

这里的 MCP 可不是随便开放权限的。它只暴露白名单里的查询和恢复动作，权限边界非常清晰。

每一次敏感操作，都会弹出审批请求，你需要明确点击"批准本次"，Agent 才能继续执行。所以，Agent 可以帮你做调查、出方案，但绝不能绕过你的审批去随意操作系统。这是安全底线，也是设计上的一个关键考量。

结构化 RCA，而非原始日志

分析完成后，Agent 不会简单粗暴地丢给你一堆原始日志，让你自己去翻。它会直接给出结构化的根因分析、影响范围和恢复计划：

• 故障结论：inventory-service 执行 Redis 命令超时，库存预扣失败
• 故障时间线：精确到秒的事件序列，从请求进入到异常抛出
• 根因与证据：具体代码位置、异常堆栈、K8s 状态、Pod 日志
• 影响范围：哪些业务流程受影响，哪些用户受影响
• 建议恢复动作：调用 restore_fault_injection 清除故障注入
• 恢复后验证方法：从 K8s 状态到业务下单的全链路验证

同时，它会告诉你，如果要恢复，需要执行哪一个具体的受控动作。

人工确认：受控写操作的最后一道闸门

在真正执行恢复之前，页面会要求人工确认或审批。这可不是走过场。

恢复计划摘要会清晰地列出：操作目标、执行动作、影响范围、风险等级、回滚方式、验证方式，以及是否需要审批。所有信息一目了然。

用户明确回复"确认执行"后，Agent 才会调用写操作工具。这就像给系统恢复上了一道保险，确保每个改动都是经过深思熟虑的。

执行不止于"运行命令"，而是验证闭环

执行完成以后，Agent 并不会马上结束。它会继续调用验证工具，检查关键接口是否已经恢复。

如果恢复有效，它会把验证结果一起返回给你：恢复前后的关键指标对比、端到端链路验证、业务下单验证。从 Redis 超时状态到订单确认成功，每一项都有明确的 ✅ 标记。整个过程，就是一个完整的闭环，而不是一个单点操作。

可审计闭环：从发现到验证，全程留痕

最后，Agent 还会生成一份审计摘要：谁在什么时间触发了什么操作，做了什么，结果如何。所有步骤都有记录。

你还可以让 Agent 生成一份完整的 RCA 报告文档（PDF），包含故障概述、调用链路分析、关键证据、根因结论、影响范围评估和恢复操作记录。这份报告可以直接下载存档，或者上传至工单系统，方便后续复盘和追溯。

AI 时代人与智能体共同消费的可观测数据基础设施

在这个场景里，观测云通过 Guance AI Agent Teams，为业务调查与恢复提供了一个完整的解决方案：

• 统一的数据基座：日志、指标、Trace、事件，全部统一采集、统一标签、统一存储，数据不再散落各处
• 受控的执行边界：白名单权限 + 人工审批，Agent 可见、可主动恢复，但不可越权，安全与效率兼顾
• 结构化的证据输出：经过 RCA Agent 推理后的结构化结论与审计报告，一目了然，方便决策

让数据说话，AI 感知，人决策，Agent 行动。这才是智能运维该有的样子。