# Final Capstone：从 AIOps 到 Autonomous Operations——把 21 篇焊成一个系统

这是 ITOps Agent Platform 系列的最终篇。前 20 篇，我们分别构建了告警聚合、上下文构建、RCA、Planner、Policy、执行网关、可观测性、成本、容量、混沌验证等能力。但能力点散落在各处，充其量只是一堆“AI 运维工具”。今天，我们要把这些模块焊成一个**可演示、可测试、可审计的完整 AIOps Agent 平台**，并落地自主权分级与统一 Scorecard。

如果你一直在追这个系列，你应该已经感受到一个清晰的演进脉络：从“故障后自动修复”到“故障前优化”，再到“用混沌工程验证自治能力”。现在，是时候把这些拼图组装起来，让它成为一个真正的 **Agentic Operations Platform**，而非又一个 LLM 调用封装。

---
![image.png](https://developer.qcloudimg.com/http-save/yehe-1750537/74d8bf302e7777fe41d21f27162001a5.png)
## 为什么“焊成系统”是最后也是最难的一步？

因为单点能力容易，端到端闭环难。你可能有很棒的异常检测模型、很聪明的诊断 Agent，但如果告警没有标准化、上下文没有拓扑关联、修复动作没有经过策略校验、执行后没有验证、事后没有复盘，那这一切都是孤立的花架子。

真正的 Autonomous Operations，不是“Agent 能修故障”，而是**从故障注入到知识沉淀，每一步都有迹可循、有据可查、有分可评**。这需要打通以下链路：

```
故障注入 → 告警 → 自动聚合 → AI 调查 → 根因+证据
→ 修复计划 → 风险判断 → 审批 → 执行 → 验证
→ 回滚(如失败) → 报告 → Evaluation → 知识沉淀
```

前 20 篇的模块正是为了支撑这条链路。而第 21 篇，我们要把它们整合成一个**毕业项目：Autonomous Incident Response Lab**，并用它来回答三个根本问题：

1. 我的平台现在处于 L0-L5 的哪一级？
2. 升级到下一级的评估门槛是什么？
3. 去掉“AI”两个字，我的系统还剩下多少可靠的确定性底座？

---

## 前沿趋势：行业正在向 Agentic Operations 靠拢

在开始架构之前，先看清行业的三个关键转变：

1. **从“异常检测 + 降噪”演进到 Agentic Operations**。过去几年，AIOps 主要集中在用机器学习做异常检测和告警降噪。现在，大家开始让 Agent 自主完成调查、诊断、修复。但随之而来的要求是：Agent 必须有独立的遥测与评估体系，不能是黑盒。

2. **自治是受控的（Controlled Autonomy）**。没有人真的敢一步跳到全自动。L4/L5 的自治需要建立在 error budget、HITL、策略引擎的基础上。连 Google SRE 都强调，自动化程度必须与信任度匹配。

3. **平台同时服务 human 与 AI agent**。这意味着我们需要 agent identity、permission、quota、audit——就像管理人类工程师一样管理 Agent。Agent 不是特殊公民，而是受治理的参与者。

这些趋势决定了我们的最终架构必须具备：**确定性底座 + 智能推理层 + 统一评估**。

---

## 核心架构：Autonomous Incident Response Lab

毕业项目的完整架构如下：

```text
Prometheus/Zabbix/OTel → Incident Engine → Context Builder
       → Log/Metric/Trace Agent → RCA/Planner
       → Runbook/Specialist Agents → Reviewer
       → Policy Engine → Execution Gateway → SSH/K8s/Docker
       → Verifier → Resolved/Rollback → Incident Report
       → Knowledge/RAG → Evaluation
```

这个架构包含了 15 个关键步骤，对应我们之前构建的模块：

1. **Prometheus/OTel 产生信号**：统一遥测来源，结构化指标、日志、trace。
2. **Alert Engine 标准化**：将不同来源的告警转换为统一的 incident 事件。
3. **Correlator 聚合**：把相关告警合并为一个 incident，避免告警风暴。
4. **Topology 上下文**：注入服务依赖、部署拓扑、变更历史等上下文。
5. **RCA**：根因分析 Agent，输出根因假设和证据链。
6. **RAG**：检索历史相似 incident、runbook、知识库。
7. **Planner**：制定修复计划，包含步骤、风险、回滚方案。
8. **Policy**：策略引擎评估计划的风险与权限。
9. **HITL**：高风险动作转人工审批。
10. **Execution Gateway**：受控执行修复动作（SSH/K8s/Docker）。
11. **Verifier**：验证系统是否真正恢复。
12. **Rollback**：如果验证失败，自动回滚并升级。
13. **Report**：生成 incident 报告，包含根因、动作、时间线、成本。
14. **知识回写**：将本次经验写入知识库和 RAG。
15. **Evaluation 打分**：用统一 Scorecard 评估本次处理质量。

这个闭环不是顺序的瀑布流，而是有反馈回路的。比如，Verifier 发现未恢复，会触发 Planner 重新规划或 Rollback；Evaluation 发现诊断错误，会提示更新 RAG 中的 runbook。

---

## 自主权分级：L0 到 L5

很多人一上来就想做 L5 全自主，结果在生产环境翻车。我们需要一个清晰的自主权分级，让平台可以逐步演进：

- **L0 Read only**：Agent 只能读取数据，不能做任何修改。相当于一个观察员。
- **L1 Recommend**：Agent 可以给出建议，但所有动作由人类执行。
- **L2 Human approve**：Agent 可以自动执行低风险动作，高风险动作必须人类审批。
- **L3 Low-risk auto**：低风险动作（如重启无状态 Pod、清理缓存）自动执行，高风险仍需审批。
- **L4 Conditional autonomous**：在 error budget 充足、影响范围可控的条件下，大部分动作自动执行，仅极端情况需要人工。
- **L5 Autonomous**：完全自治，极少人工介入（通常仅限年度审计或极端黑天鹅事件）。

每一个级别的升级都有明确的评估门槛，这些门槛通过 Chaos Lab 的 AIOps Score 和 production 的真实表现来验证。**不要跳级**。如果一个平台连 L2 的审批流程都做不好，直接上 L3 只会带来灾难。

---

## 统一 Scorecard：让每次处理都可量化

在第 20 篇中，我们引入了 AIOps Score 来评估混沌实验中的表现。现在，我们把它扩展为**生产环境中的统一 Scorecard**，不仅用于混沌实验，也用于真实 incident 的复盘。

Scorecard 的权重设计如下：

| 维度 | 权重 | 说明 |
|------|------|------|
| Detection | 15% | 从故障发生到告警触达的时间与准确率 |
| RCA | 20% | 根因定位准确度，证据链是否充分 |
| Plan | 10% | 修复计划的合理性、完整性、风险考虑 |
| Action | 15% | 执行动作的有效性与影响面控制 |
| Verification | 15% | 是否真正验证了恢复，有无残留 |
| Safety | 15% | 有无越权、危险操作、未授权变更 |
| Cost | 5% | token、工具调用、执行成本 |
| Latency | 5% | 总处理时长是否在 SLO 内 |

除了这些加权分，还有**四类硬门槛，一旦触发，本次处理直接判为 FAIL**：

1. **CRITICAL 违规**：例如在生产高峰期执行了未授权的破坏性操作。
2. **验证失败却报成功**：Verifier 未通过，但 Agent 却上报“已解决”。
3. **越权**：执行了超出其权限范围的动作。
4. **无证据决策**：RCA 或 Planner 给出的结论缺乏任何证据支持（纯猜测）。

这些硬门槛的存在，就是为了防止 Agent “作弊”——表面分数高，实际却埋下隐患。

---

## 代码示例：端到端 autonomous_response 函数

以下是一个简化但完整的 Python 函数，展示了如何编排一次自动响应：

```python
def autonomous_response(incident):
    # 1. 构建上下文
    ctx = build_context(incident)
    
    # 2. 根因分析
    root_cause, evidence = rca_agent.analyze(ctx)
    
    # 3. 制定修复计划
    plan = planner.plan(root_cause, evidence)
    
    # 4. 策略评估
    decision = policy.assess(plan)
    
    # 5. 如果需要人工审批
    if decision.requires_approval:
        plan = human_approve(plan)
    
    # 6. 执行
    result = execution_gateway.run(plan)
    
    # 7. 验证
    state = verifier.verify(result)
    
    # 8. 如果验证失败，回滚并升级
    if not state.ok:
        rollback(plan)
        escalate()
    
    # 9. 生成报告
    report = report_agent.generate(root_cause, evidence, state)
    
    # 10. 知识沉淀
    knowledge.write(report)
    
    # 11. 评估打分
    return evaluation.score(incident, report, state)
```

实际生产实现远比这复杂，但这个骨架体现了关键原则：**每一步都有明确的模块、可观测的输出，并且有反馈机制**。特别注意 `policy.assess` 和 `verifier.verify`，它们是确定性组件，不依赖 LLM，这是安全底线。

---

## 生产环境最佳实践

1. **每个模块都先有确定性实现，再叠加 LLM 推理**。RBAC、状态机、Schema、策略引擎、验证逻辑——这些必须是确定性的代码，不能让 LLM 来决定“是否允许执行”。LLM 只负责理解、推理和建议，最终决策由规则引擎把关。

2. **用 OTel 作为统一 telemetry contract**。`incident_id`、`trace_id`、`session_id`、`agent_id`、`tool_call_id` 必须全程串联。没有统一的 trace，就无法回答“这次故障 Agent 到底做了什么、花了多少钱、卡在哪里”。

3. **所有自动化可验证、所有生产 Agent 可追踪、所有关键 Agent 可评估**。这三点是 Autonomous Operations 的验收标准。如果做不到，就退回到 L1/L2。

---

## 常见错误

1. **把“调用一个 LLM API”当 AIOps**。缺遥测、状态机、策略、验证，这只能算一个 chatbot，不能算运维平台。LLM 是大脑，但还需要手脚（执行）、免疫系统（策略）、体检（验证）。

2. **Agent 数量越加越多，却没有统一抽象**。很多人一上来就建了五个专用 Agent，但没有 Agent Runtime、Registry、Policy、Evaluation 的统一管理。结果就是一片混乱，无法治理。正确的做法是先有底座，再扩展 Agent。

3. **一步跳到 L5 全自主**。跳过 HITL 和 error budget 控制，直接在生产环境全自动执行，结果大概率是灾难。自治是逐步赢得的，不是授予的。

---

## 安全注意事项

LLM 永远不能同时充当 Policy Engine、Executor、Source of Truth。这三个角色必须分离：

- **Policy Engine**：确定性规则引擎，检查权限、风险、变更窗口。
- **Executor**：受控执行网关，记录所有操作，支持撤销。
- **Source of Truth**：配置、拓扑、资产数据来自权威系统，LLM 不能直接修改。

高风险动作强制 HITL，所有执行可审计，secret 走 Secret Manager。Agent 的身份、权限、配额必须像人类用户一样管理。

---

## 可观测性：全链路 trace 覆盖每个环节

我们之前在第 12 篇和 19 篇已经强调了可观测性。在最终平台中，全链路 trace 必须覆盖：

- agent session（一次 incident 处理的完整会话）
- llm_call（每次模型调用，包括 prompt、token、延迟、成本）
- tool_call（每次工具调用，包括参数、返回、耗时）
- policy decision（策略判断结果、依据）
- execution（执行动作、结果、影响）
- verify（验证结果、证据）

这些 trace 数据不仅用于排错，也是 Evaluation 和 FinOps 的数据源。成本与 token 全维度可见，每次 incident 都是一本清晰的账。

---

## Evaluation：统一 Scorecard 与硬门槛

如前所述，统一 Scorecard 用于所有 incident 的复盘和混沌实验。它不仅给出分数，还记录证据，方便回溯。每个维度都有具体的度量方法和数据来源。硬门槛确保安全底线不可逾越。

通过持续积累 Scorecard 数据，我们可以：

- 横向对比不同 Agent 版本（prompt、模型、策略）
- 识别薄弱环节（比如 RCA 一直低分，说明诊断能力不足）
- 决定是否升级自主权等级（例如连续 50 个 incident Scorecard 平均 85 分以上且无硬门槛违规，可以考虑从 L2 升到 L3）

---

## 验收标准

作为系列最终篇，毕业项目的验收标准很明确：

**一次故障注入到知识沉淀的完整闭环可演示、可重放，且产出带分数与证据的评估报告。**

这意味着你需要：

1. 在环境中注入一个故障（可以用 Chaos Lab）。
2. 观察告警、聚合、Agent 调查、诊断、规划、审批、执行、验证、报告、知识回写的全过程。
3. 重放整个过程（通过 trace 和日志），确认可复现。
4. 产出一份评估报告，包含 Scorecard 分数、每个维度的得分依据、硬门槛是否触发。

如果达到这个标准，你的平台就真正从“AI 运维工具”进化成了“Agentic Operations Platform”。

---

## 思考：去掉“AI”，你还剩下什么？

最后，留两个思考题：

- **你的平台现在处于 L0-L5 的哪一级？向上晋升的评估门槛是什么？** 如果答不上来，说明你还没有建立评估体系。
- **去掉“AI”两个字，你的系统还剩下多少可靠的确定性底座？** 如果答案是“几乎没有”，那你的平台只是一堆 LLM 调用的堆砌，风一吹就倒。

Autonomous Operations 的终极目标，不是让 AI 取代人类，而是让人类和 AI 在一个受控、可观测、可评估的平台上协同工作。前 20 篇我们种下了一颗颗种子，第 21 篇是把它们培育成一片森林。但这片森林还需要持续的养护——混沌实验、成本审计、知识更新、策略优化。自治不是终点，而是一个不断演进的旅程。

**延伸阅读**：
- [OpenTelemetry AI Agent Observability](https://opentelemetry.io/blog/2025/ai-agent-observability/)
- [CNCF: Cloud Native Agentic Standards](https://www.cncf.io/blog/2026/03/23/cloud-native-agentic-standards/)
- [ITOps Agent Platform](https://github.com/qinshihu/itops-agent-platform)

系列至此完结，但你的自治运维实践才刚刚开始。

这是 ITOps Agent Platform 系列的最终篇。前 20 篇，我们分别构建了告警聚合、上下文构建、RCA、Planner、Policy、执行网关、可观测性、成本、容量、混沌验证等能力。但能力点散落在各处，充其量只是一堆“AI 运维工具”。今天，我们要把这些模块焊成一个可演示、可测试、可审计的完整 AIOps Agent 平台，并落地自主权分级与统一 Scorecard。

【21｜Final Capstone：从 AIOps 到 Autonomous Operations】

人工智能

运维

架构设计

从AIOps到AutonomousOperations，将告警聚合、RCA、策略引擎等21个模块焊成完整Agent平台。核心架构打通故障注入到知识沉淀闭环，支持L0-L5自主权分级与统一Scorecard评估，强调确定性底座+LLM推理分离，实现受控、可观测、可审计的Agentic运维。

代码解释

机器学习

Docker

FinOps

Python

AIOps

Agent

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【21｜Final Capstone：从 AIOps 到 Autonomous Operations】-腾讯云开发者社区-腾讯云

【21｜Final Capstone：从 AIOps 到 Autonomous Operations】

【21｜Final Capstone：从 AIOps 到 Autonomous Operations】

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐