用途
Alert investigation 是一个用于调查特定已触发告警的技能。告警会携带结构化上下文，包括告警 ID、名称、阈值、越界值以及时间范围。该技能的目标是解释告警为何触发、评估影响范围，并给出建议操作。
主要能力
该技能依赖以下 LaunchDarkly 可观测性 MCP 工具：
- query-logs：查询日志记录
- query-traces：查询分布式链路
- query-error-groups：查询错误分组
- query-sessions：查询会话
- query-aggregations：查询聚合/按时间分桶的指标
- get-keys：在过滤前发现可用的属性键
使用方式
工作流程如下：
-
解析告警上下文。对话第一轮会携带告警变量：alertID、alertName、alertValue、group、groupValue、query、thresholdWindow、timeRange，以及一个产品特定链接。直接使用这些变量，不要重新推导。
-
加载对应产品的配套文档。根据告警的产品类型，加载匹配的配套文件：logs.md、traces.md、errors.md、sessions.md 或 metrics.md。每个文件描述该产品类型的调查形态。
-
使用 investigate 技能中的方法执行调查（交叉引用日志/链路/错误/会话/指标；引用标识符；先聚合再分页）。调查范围限定在告警的时间范围和过滤条件内。
-
生成结构化诊断，见下方输出模板。
输出模板：
## What triggered
<1-2 sentences naming the alert, the threshold, and the value that crossed it.>
## Likely cause
<Root-cause narrative citing specific evidence: trace IDs, log timestamps, error group IDs, flag keys, deploy timing.>
## Scope
<Who or what is affected. Number of users, services, sessions, error groups. Time window of impact.>
## Next steps
<1-3 concrete actions the on-call or owner should take. Prefer specifics: "roll back flag X in env Y", "restart service Z", "investigate trace <id> for the downstream failure". Avoid "investigate further" — if you don't have a root cause, say what specifically should be investigated and how.>
何时加载哪个配套文档：
- logs.md — 日志告警、日志模式告警
- traces.md — 延迟告警、链路错误率告警、特定 span 告警
- errors.md — 错误率告警、新错误分组告警、崩溃率告警
- sessions.md — 会话健康告警、面向用户的错误率告警
- metrics.md — 自定义指标阈值、聚合指标告警、复合告警
如果告警跨越产品边界（例如由错误数据驱动的指标告警），则同时加载两个配套文档。
适用场景
适用于已触发告警的根因调查，尤其是需要快速给出可操作诊断并推送到通知渠道或仪表盘的场景。
限制与准则
- 保持紧凑。告警调查会进入通知，输出应结构化且便于扫读。不要写前言（如“以下是我的分析……”），不要重复框架。
- 引用标识符。诊断中的每个结论都应引用具体的 trace ID、错误分组 ID、会话 ID 或日志时间戳。
- 如果告警看起来是噪声，应明确说明——“该告警因……触发，但底层行为处于正常波动范围内，因为……”。噪声是合法结果，不要编造根因。
- 不要重复刚刚完成的调查。诊断输出应让值班人员无需重新查询即可采取行动。