考察点
这道题出自腾讯后台一面（2026 年牛客面经，候选人项目是一个 Oncall 排障 agent），是后台工程师视角的典型问题：一次线上告警关联的日志动辄几十万行，模型上下文窗口装不下零头，怎么办。面试官想看的是后台老兵的工程直觉——第一反应不该是"用模型摘要"，而应该是从源头减少信息进入：过滤、聚合、采样，这些确定性手段永远优先于模型压缩。第二问"压缩会不会丢重要信息"是在考你对有损处理的敬畏心，标准答案是：会，所以压缩必须可控、可回溯。追问常往"错误日志特征怎么做白名单""怎么验证压缩后还能定位问题"上走。
参考答案
第一反应不是压缩，是少读
排障场景的特点是信噪比极低：几十万行日志里真正指向根因的可能就几行。让模型读全部再压缩是最差路径，正确顺序是先用确定性手段把候选集砍小，模型只看砍完剩下的。
源头过滤是第一道。日志查询工具不该接受"给我全部日志"这种请求，而是强制带条件：时间窗（告警触发前后各 N 分钟）、级别（ERROR/WARN 优先）、关键字（trace ID、接口名、异常类名）。一个告警进来，agent 先按告警元数据组装过滤条件，拿到的就是百行级而不是十万行的结果。这一步是纯工程，零模型成本，效果也最显著。
分层加载是第二道，思路类似地图的缩放。工具默认返回统计视图：按错误类型聚类后的分布（"NullPointerException 出现 847 次，集中在 order-service，首次出现于 14:32:05"）加每种错误的少量样例行。agent 基于统计判断方向后，再针对它认定可疑的那一类发起 drill-down 查询，拿该类错误的完整堆栈和上下文日志。绝大多数情况下两三层 drill-down 就到根因了，进上下文的日志总量始终可控。
外置存储是兜底。确实需要大范围扫读时（比如分析一个时间窗内的模式），全文落临时文件，上下文里只放文件路径、行数统计和关键行号。agent 需要回看时用 grep 类工具按行号区间精确取，日志本体永不进上下文。
必须用模型压缩时，怎么保证不丢关键信息
有些环节绕不开模型压缩——比如要把"已排查路径"从上下文里清出去腾空间。我的原则是有损但可控，具体三条。
白名单原文保留。 定义排障场景的"关键信息原语"：异常类名、堆栈首行与根因帧（cause by 链的最底层）、trace ID、错误码、时间戳、用户原话描述的告警现象。这些内容要么原文留在上下文，要么外置留指针，绝不交给模型自由摘要——模型摘要把 Connection refused 概括成"网络问题"，排障方向就直接跑偏了。
压缩结构化而非散文式。 中间状态压缩成固定字段的快照：已排除的假设、待验证的假设、每个假设的证据指针。结构化格式抗变形，模型二次引用时不会自由发挥。
原文可回溯。 压缩只删上下文里的副本，原始日志和完整历史都在文件里。压缩动作本身是"冷热分层"而不是"删除"，这一条是心理底线也是工程底线：任何压缩决策都可以事后推翻。
怎么知道压缩没坏事
两个手段。一是压缩后自检：触发压缩后让 agent 用几句话复述当前排查状态——告警现象是什么、已确认什么、怀疑什么、下一步查什么，复述不出关键事实说明白名单漏了，当场补。二是离线回放验证：收集历史故障案例做成评测集（输入告警，标准答案是根因），不同压缩策略跑对比，看根因定位成功率掉不掉。排障是少见的"有标准答案"的 agent 场景，这个评测优势要利用起来。
可能的追问
白名单特征怎么维护，新错误类型漏了怎么办？ 初始集合从 SRE 排障手册和历史故障复盘里提炼，上线后靠评测集暴露漏网之鱼——某个案例压缩后定位失败，回看发现是哪类信息被摘要掉了，补进白名单。这是个运营活，不是一次设计。
多服务串联的故障，trace 跨系统怎么追？ 以 trace ID 为主键把各服务的过滤结果关联，统计视图里就体现调用链上每个节点的错误分布；agent 沿链逐跳 drill-down。这依赖全链路 trace 埋点质量，agent 救不了没埋点的系统。
这套东西和传统 AIOps 的关系？ 互补。确定性规则和传统异常检测负责"发现问题、圈定范围"，agent 负责"多步推理、跨系统关联、生成处置建议"。纯规则搞不定的长链推理是 agent 的增量价值，但千万别让 agent 去替代那些一条规则就能解决的事。