故障诊断 Agent 的上下文管理如何在有限 Context 窗口内高效组装指标、日志与事件在将大语言模型引入生产环境可观测性链路构建自动化故障诊断 Agent 时绝大多数团队遭遇的第一道硬伤并不是模型的推理能力不足而是上下文窗口Context Window的无序膨胀与信噪比崩溃。一次真实的线上微服务故障排查往往伴随着数十个关键指标Metrics的每秒时序离散点、上万条混杂在业务普通输出中的错误日志Logs以及 Kubernetes 集群内部滚雪球般产生的 Pod 重启与驱逐事件Events。如果采取无脑拼接的方式将这些原始监控数据塞入 Prompt不仅会瞬间击穿百万 Token 预算导致推理成本激增还会触发大模型的“迷失在中间”Lost in the Middle效应导致真正致命的致命异常被海量无关上下文淹没最终得出南辕北辙的诊断结论。在这套面向高并发金融级基础设施的诊断 Agent 落地实践中我们确立了一条核心法则Context 组装不是数据的无脑倾倒而是有目的的特征分层提纯。诊断上下文组装的三层漏斗模型面对异构可观测性数据我们设计了三层过滤与提纯漏斗时序指标降采样与语义摘要化拒绝直接传入原始浮点数数组。将 PromQL 查询出的时序数据通过统计特征提取器转化为“基线偏离度、突变拐点、持续时间、P99 分位数”等结构化自然语言描述。日志语义指纹聚合与代表性采样利用 Drain 或语义聚类算法将 10,000 条错误日志提炼为不超过 5 个核心 Log Template。每类模板仅保留首次发生时间、最后发生时间、总触发频次以及包含关键变量的 1 条代表性样本。拓扑感知与事件关联Topological Pruning通过微服务依赖图谱过滤掉非故障传播链上的宿主机系统事件仅保留故障微服务实例及其直接下游的核心 Lifecycle 与 Warning 事件。原始观测数据源 (Metrics/Logs/Events) │ ▼ ┌───────────────────────────────────────┐ │ 第一层时序指标特征提取器 │ 原始时序 - 趋势/偏离度/拐点描述 └───────────────────────────────────────┘ │ ▼ ┌───────────────────────────────────────┐ │ 第二层Drain 日志模板聚类器 │ 10,000 日志 - Top 5 核心特征模板 └───────────────────────────────────────┘ │ ▼ ┌───────────────────────────────────────┐ │ 第三层拓扑剪枝与事件归并器 │ 滤除非关联服务按调用链组装 └───────────────────────────────────────┘ │ ▼ 结构化紧凑诊断上下文 (Token 压缩率 95%) - 送入 Agent 推理核心组装器实现代码Go 语言生产级实现下面是负责在 Agent 触发后组装结构化上下文的核心代码实现。通过对指标、日志和集群事件的显式预算分配严格将最终生成的 Prompt Token 数量控制在预设区间内。package contextmanager import ( context fmt sort strings time ) // MetricSummary 指标特征摘要 type MetricSummary struct { MetricName string Baseline float64 PeakValue float64 DeviationPct float64 ChangePoint time.Time } // LogCluster 聚类后的日志指纹 type LogCluster struct { Template string Occurrences int FirstSeen time.Time LastSeen time.Time SampleLine string } // K8sEvent 关联的集群核心事件 type K8sEvent struct { Reason string Message string Count int32 Component string } // IncidentContext 最终组装的紧凑诊断上下文 type IncidentContext struct { ServiceID string AlertName string TriggerTime time.Time Metrics []MetricSummary TopLogs []LogCluster Events []K8sEvent MaxTokenSize int } // FormatToPrompt 将上下文转换为面向 Agent 的紧凑自然语言与 YAML 混排格式 func (c *IncidentContext) FormatToPrompt() string { var builder strings.Builder builder.WriteString(fmt.Sprintf( 故障排查上下文: 服务 [%s] 触发告警 [%s] \n, c.ServiceID, c.AlertName)) builder.WriteString(fmt.Sprintf(触发基准时间: %s\n\n, c.TriggerTime.Format(time.RFC3339))) // 1. 组装指标摘要 builder.WriteString(### [关键指标偏离度分析]\n) for _, m : range c.Metrics { builder.WriteString(fmt.Sprintf(- 指标: %s | 历史基线: %.2f | 异常峰值: %.2f | 偏离幅度: %.1f%% | 拐点时刻: %s\n, m.MetricName, m.Baseline, m.PeakValue, m.DeviationPct, m.ChangePoint.Format(15:04:05))) } // 2. 组装高频聚合日志模板 builder.WriteString(\n### [核心错误日志模式 (Drain 聚合)]\n) // 按发生次数降序排序仅展示最具代表性的前 3 种 sort.Slice(c.TopLogs, func(i, j int) bool { return c.TopLogs[i].Occurrences c.TopLogs[j].Occurrences }) for idx, log : range c.TopLogs { if idx 3 { break } builder.WriteString(fmt.Sprintf(- 模板 [%d] (触发 %d 次, 区间 %s ~ %s):\n, idx1, log.Occurrences, log.FirstSeen.Format(15:04:05), log.LastSeen.Format(15:04:05))) builder.WriteString(fmt.Sprintf( 模式格式: %s\n, log.Template)) builder.WriteString(fmt.Sprintf( 代表样本: %s\n, log.SampleLine)) } // 3. 组装集群系统事件 builder.WriteString(\n### [拓扑关联 Kubernetes 异常事件]\n) if len(c.Events) 0 { builder.WriteString(- 无关联 Warning 事件\n) } else { for _, evt : range c.Events { builder.WriteString(fmt.Sprintf(- 原因: %s (重复 %d 次) | 组件: %s | 详情: %s\n, evt.Reason, evt.Count, evt.Component, evt.Message)) } } return builder.String() }生产诊断 Prompt 模板设计与注入当 Context 组装器完成特征提炼后需要将其注入到高度收敛的 System Prompt 与 User Prompt 体系中。切忌给 Agent 自由发散的空间必须使用确定性的输出格式如 JSON Schema约束其推理链条。[SYSTEM PROMPT] 你是一名拥有十年以上一线经验的大厂 SRE 专家架构师。 你的职责是根据精简后的微服务异常指标特征、日志模板指纹和 Kubernetes 关联事件 推导故障的根本诱因Root Cause并输出修复行动建议。 【推理纪律】 1. 严禁臆测未在上下文中出现的网络分区或硬件故障。 2. 当指标偏离度与日志报错时间点不匹配时以最先发生拐点的维度作为证据原点。 3. 结论必须保持精准并直接以标准 JSON 格式输出字段包含: root_cause_service, root_cause_type, confidence, action_plan。[USER PROMPT] 请分析以下经过特征降采样与日志模式提取的故障上下文给出根因诊断 故障排查上下文: 服务 [pay-gateway] 触发告警 [P99_Latency_High] 触发基准时间: 2026-10-06T14:32:00Z ### [关键指标偏离度分析] - 指标: http_request_duration_p99 | 历史基线: 42.10ms | 异常峰值: 2840.50ms | 偏离幅度: 6647.0% | 拐点时刻: 14:30:15 - 指标: jvm_gc_pause_seconds_total | 历史基线: 0.12s | 异常峰值: 4.85s | 偏离幅度: 3941.7% | 拐点时刻: 14:30:10 - 指标: node_cpu_utilization | 历史基线: 32.50% | 异常峰值: 35.10% | 偏离幅度: 8.0% | 拐点时刻: 14:30:00 ### [核心错误日志模式 (Drain 聚合)] - 模板 [1] (触发 8421 次, 区间 14:30:18 ~ 14:31:55): 模式格式: java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after *ms 代表样本: java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 3000ms - 模板 [2] (触发 1205 次, 区间 14:30:12 ~ 14:31:40): 模式格式: org.apache.dubbo.remoting.TimeoutException: Waiting server-side response timeout by provider *IP* 代表样本: org.apache.dubbo.remoting.TimeoutException: Waiting server-side response timeout by provider 10.244.12.85:20880 ### [拓扑关联 Kubernetes 异常事件] - 原因: Unhealthy (重复 4 次) | 组件: kubelet | 详情: Readiness probe failed: Get http://10.244.12.85:8080/actuator/health: context deadline exceeded落地效果对比与实践经验在生产实践中我们对 50 起真实注入的线上中大型故障进行了上下文管理前后对比指标项原始数据直接注入三层提纯上下文管理提升幅度单次诊断 Token 消耗平均 128,400 Tokens平均 5,820 Tokens降低 95.4%Agent 推理端到端延迟18.6 秒2.3 秒提速 87.6%根因定位准确率 (Top-1)62.0%88.5%提升 26.5%API 调用超时失败率14.0%0.0%完全清零生产避坑指南绝对禁止保留原始多行堆栈的所有行异常堆栈中通常 80% 都是基础类库与框架反射代码如 Spring/Tomcat 内部调用。组装器必须通过正则仅保留业务首行与引起异常的Caused by首行将其余框架行直接折叠为... 42 more lines。严防“幽灵上下文”污染如果被调用的下游服务在 10 分钟前有一条偶发的非致命 Warning拓扑关联模块若未加入时间窗口滑动衰减逻辑极易误导 Agent 将其判定为根因。必须强制要求所有进入上下文的特征事件时间戳与告警触发点的绝对差值不能超过配置阈值例如 300 秒。指标时间线对齐Clock AlignmentPrometheus 时序抓取周期间隔通常为 15 秒而业务日志是毫秒级输出。在将两者转换为统一格式放入 Prompt 时必须由组装器统一对齐为相对时间如“告警触发前 45 秒”帮助大模型建立正确的因果时序逻辑链。