LINEヤフー实习生：AI告警调查拆分确定性与探索性任务
法政大学学生霍永豪在LINEヤフー实习期间开发了AI Alert Watcher。文章详述了初期让LLM全权负责Kafka告警调查导致的连锁失败（如超时、幻觉、格式错误），以及后期将“每次必查的4项核心指标”交由Watcher固定查询、“灵活线索挖掘”留给LLM的架构重构过程。这一设计确保了即使AI部分失败，基础事实仍能送达Slack，为LLM在运维场景的落地提供了具体的职责分离范例。
重要性实质性证据E3 可检验写法快讯
在利用大语言模型（LLM）辅助系统运维时，一个常见的陷阱是让模型同时承担“确定性数据获取”和“不确定性逻辑推理”的任务。法政大学信息科学部三年级学生霍永豪在LINEヤフー为期四周的实习中，通过开发名为「AI Alert Watcher」的工具，亲历了这一陷阱及其解决方案。该工具旨在接收Grafana发出的Kafka告警，自动进行初步调查并将结果推送至Slack。
Watcher的初始版本采用了典型的Agent模式：LLM通过Grafana MCP（Model Context Protocol）自主决定查询哪些数据源、编写PromQL语句、解读日志并生成最终报告。然而，在实际联调中，这种“全权委托”暴露了严重的脆弱性。当LLM猜测错误的数据源ID、搞错MCP工具参数或陷入漫长的元数据搜索时，整个HTTP请求会因超时而失败。更糟糕的是，如果LLM返回的JSON格式稍有偏差，解析器就会报错，导致Slack中没有任何通知发出——运维人员甚至不知道调查已经启动过。此外，LLM有时会将“No Data”（无数据）误读为“Normal”（正常），或者声称自己“已调查”但在执行历史中找不到实际的数据获取记录。
面对剩余仅5天的开发时间，霍永豪与导师重新审视了运维人员的真实需求：无论告警类型如何，有四项核心指标是每次都必须确认的——Traffic（流入量）、HOST（服务器响应状态）、Critical Cluster Issues（集群关键异常，如Offline Partitions等）和Consumer Lag（消费滞后）。既然这些信息是固定的，就不需要LLM去“思考”如何获取。
因此，Watcher进行了关键的架构重构，将调查分为两个独立阶段。第一阶段由Watcher代码本身执行，使用预定义的PromQL查询固定获取上述四项指标。这一过程不经过LLM，因此不受模型幻觉、格式错误或API超时影响。第二阶段才交给LLM，它基于第一阶段获取的事实，利用Grafana MCP读取Loki日志、关联其他指标或寻找OOM/GC等具体原因线索。
这种“确定性+探索性”的分离带来了显著的鲁棒性提升。首先，即使第二阶段的LLM调用完全失败，第一阶段获取的四项核心事实依然会被格式化并发送到Slack，确保运维人员至少能看到基础状态。其次，故障排查变得清晰：如果没收到通知，是Webhook接收问题；如果只有基础数据没有AI分析，是LLM环节问题；如果数据缺失，则是Prometheus查询问题。
在实现细节上，霍永豪还引入了几个关键改进。例如，将Webhook处理改为异步（立即返回HTTP 202），避免同步等待LLM导致网关超时；严格区分Prometheus返回值的四种状态：observed（有值）、no data（无数据）、failed（查询失败）和conflicting（冲突），防止将监控盲区误报为健康；以及不再信任LLM的自然语言描述，而是检查OpenCode的执行历史日志，确认是否真的成功调用了Grafana工具并获取了非空结果。
关于成本与效率，霍永豪基于20个告警样本的平均Token消耗进行了估算。假设每天10个告警，每个告警调查约消耗2.1万输入Token和7.8万缓存Token，每月工作20天，年成本可控。更重要的是，他引用团队反馈指出，人工完成同样的初动调查通常需要5-7分钟。虽然Watcher不能替代所有决策，但它消除了重复查找固定指标的时间，并允许运维人员在会议等非紧急状态下先浏览摘要，再决定是否需要立即中断手头工作深入调查。
这篇实习报告的真正价值不在于展示了一个完美的AI Agent，而在于诚实地记录了从“过度依赖LLM灵活性”到“回归工程确定性”的转变。对于正在构建运维Copilot的团队来说，这是一个明确的信号：不要让LLM去做数据库连接和固定字段提取的工作，把它的算力留给那些真正需要跨模态关联和语义理解的模糊线索。