论文针对远程站点/边缘环境的 Kubernetes 根因分析（RCA）痛点展开研究。当前运维场景中，故障证据分散在 Pod 日志、Kubernetes 事件与集群级对象里，跨源关联耗时且依赖人工经验；同时许多企业出于合规与数据主权要求，无法将生产日志发送给托管大模型，因此本地（on-premise）推理成为可行替代。但本地部署带来一个新问题：当单张工作站 GPU 同时约束了模型规模与上下文预算时，证据应当如何检索与取舍？此外，如果模型所参考的 runbook（运维手册）本身被投毒篡改，会发生什么？这两个问题此前未被真实集群基准测试覆盖。 为此作者提出 TriFleetRCA：一条完全运行在单张本地 GPU 上的端到端流水线。它按三种取证范围（pod、namespace、cluster）采集证据，先做日志模板去重，再以 BM25 排序，随后通过一个 ingest guard 对 runbook 进行摄入过滤，最终输出根因结论及其支撑证据行（可追溯引用）。 实验在真实运行的 Kubernetes 集群上进行，通过注入四种故障使 ground truth 天然已知，共执行 100 次分析，模型为 Qwen2.5-14B-Instruct，温度设为 0。结果显示：pod、namespace、cluster 三种范围的命中率分别为 0.85、0.90、0.95；置信区间存在重叠，整体范围收益几乎全部来自其中唯一一个根因为集群级对象的故障，而 cluster 范围要多消耗 55% 的 token。排序之前先做去重，在 token 成本不变的前提下把命中率从 0.75 提升到 0.90。安全性方面，一份指示模型删除整个 namespace 的投毒 runbook 在每一次运行中都被 guard 拦截；在关闭 guard 的对照下，模型在全部 20 次分析中也拒绝执行该指令，说明 guard 属于纵深防御而非唯一屏障。作者还指出将引用质量与诊断准确率分开度量很有价值：存在某类故障每次都诊断正确却引用错误，这是单看准确率会被掩盖的失败模式。性能上，2,200 prompt token 下的中位延迟为 1.6 秒。作者公开了流水线、故障注入器与全部实验记录。