智能运维 Agent 的架构可以抽象为三个紧密耦合的层次，这是 2026 年多家企业和开源项目实践的共同范式。
感知层：可观测性数据即 Agent 的"感官"
感知层将分散的 Observability 数据转化为 Agent 可理解的结构化上下文，包含三个数据通路：
- 实时 Metrics 流：通过 Prometheus、OpenTelemetry Collector 等将系统指标以标准化格式推送给 Agent。
- 结构化 Logs 与事件：利用 OpenTelemetry Logs 或 Fluent Bit 统一汇聚服务日志、K8s 事件和云厂商变更通知，向 Agent 提供"相关日志片段"而非"全部日志"，通常依赖 RAG 向量检索。
- 拓扑与依赖关系：通过 eBPF、Service Mesh 或 APM 探针维护实时服务调用拓扑，使 Agent 知道告警服务 A 依赖数据库 B 和缓存 C。
感知层的可观测性密度直接决定了 Agent 的"视力"。
推理层：LLM 与推理引擎的协同
推理层是 Agent 的"大脑"，通常包含：
- 规划模块：将复杂任务拆解为子任务序列（如排查延迟高 → 查 P99 → 检查依赖 → 检索变更 → 决策回滚）。
- 推理引擎：管理多轮 LLM 调用的状态机，处理 Tool Call 循环（Observation → Thought → Action）。
- 记忆管理：短期记忆（当前任务上下文）和长期记忆（历史故障案例、修复方案），常用向量数据库存储。
- 安全与对齐层：在输出转化为行动前进行权限校验、策略匹配和风险评估。
行动层：API / 工具调用与效果验证
行动层是 Agent 的"手脚"，工具集包括：只读诊断工具（kubectl、SQL 查询）、变更操作工具（扩缩容、配置推送、回滚）、协同通知工具（工单、IM 告警）和验证工具（健康检查、回归验证）。
关键设计原则是任何变更操作都必须附带自动化的效果验证。Agent 扩容后应持续观测 Metrics，确认延迟下降至目标范围；验证失败则进入回滚或人工升级路径。
三者的闭环机制为：感知层提供高密度数据 → 推理层多轮自主决策 → 行动层调用工具并自动验证 → 验证结果反馈至感知层进入下一轮循环。在 Elasticsearch 故障等受控实验中，该闭环已将 MTTR 降低高达 70%。
