用途
Investigate 是一项跨产品调查技能，用于分析可观测性数据——日志、追踪、错误、会话和指标——以找到根因和可操作的证据。当用户报告 bug、异常或性能问题时使用。真实调查几乎总是涉及多个产品：一条日志错误会引向追踪，一条慢追踪会揭示失败的 span，一个失败的 span 会关联到特定会话。需要沿着证据链走，直到得出具体的根因。
前置条件
该技能要求在环境中配置远程托管的 LaunchDarkly MCP 服务器。
所需的 MCP 工具：
- query-logs — 获取分页日志条目
- query-traces — 获取分页追踪/span 条目
- query-error-groups — 获取带堆栈跟踪和频率的错误组
- query-sessions — 获取带用户详情的会话回放
- query-aggregations — 跨产品类型的分桶聚合，用于趋势和计数
- query-timeline-events — 拉取会话内按时间顺序的事件时间线
- get-keys — 发现产品类型的有效属性/分组键
工作流程
- 先做计划。在第一次工具调用之前，先给出一个简洁的编号计划，说明打算查询什么以及为什么。然后执行。仅在琐碎查找时可跳过。
- 从窄范围开始。选择一个聚焦的时间窗口（用户未指定时默认 24 小时）以及最具体的标识符——trace ID、session ID、error group ID、flag key。宽泛查询会返回噪声。
- 让每个结果指导下一步。不要依赖单次工具调用。多次运行 query-logs、query-aggregations、query-traces、query-error-groups 和 query-sessions，用每次的发现来锐化下一次查询。
- 遵守 50 条上限。query-logs、query-traces、query-error-groups 和 query-sessions 工具每次调用最多返回 50 条。对于更大的数据集，先运行 query-aggregations 查询进行聚合，再用有针对性的获取来缩小范围。
- 积极交叉引用。日志中的 trace ID、错误中的 session ID、会话回放中的错误消息——产品连接之处通常就是根因所在。
- 维护运行中的检查清单。定期总结已确认的内容与仍需测试的内容，防止调查偏离方向。
- 以可操作的输出结束。给出回答原始问题的清晰洞察、用户可点击的直接引用（日志摘录、trace ID、session ID、error group ID）、严重性评估，以及至少一项具体修复建议——配置变更、flag 切换、带文件和行号的代码级修复，或带确切查询语句的具体诊断步骤。
相关时加载配套文件
- logs.md — 当调查涉及日志（错误消息、level=error 过滤、服务日志模式）
- traces.md — 当分析请求流、延迟或 span 关系时
- errors.md — 当查看错误组、堆栈跟踪、异常频率时
- sessions.md — 当重建用户旅程或将前端行为与后端事件关联时
- metrics.md — 当跨大数据集聚合或构建图表时
通用指导
- 优先聚合而非分页。如果要列出唯一用户、统计不同值或做汇总，使用带 group_by 的 query-aggregations——不要逐条分页记录。先用 get-keys 发现正确的分组维度。
- 在属性过滤前调用 get-keys。属性名称在不同产品类型和服务间有差异（spanName 与 span_name、hasErrors 与 has_errors）。提前一次 get-keys 调用可避免因字段名错误而浪费查询。
- 引用具体标识符。每条建议都应引用从数据中提取的确切 flag key、服务名、session ID、trace ID 或文件路径。用户应能直接依据总结行动，而无需重做调查。
- 处理大型工具输出。当工具结果被持久化到文件时（会看到 "Output too large ... Full output saved to: "），不要使用 Read——它有相同的 token 限制。使用 Bash 配合 python3 或 jq 提取所需的具体片段。
- 工具失败时优雅降级。如果工具调用失败（缓冲区溢出、超时、服务器错误），不要静默结束。尝试替代工具或方法。如果都不行，交付已找到的内容以及用户可手动采取的下一步。
- 处理模糊请求。"Investigate this" 或 "what's going on" 是深入挖掘的邀请，而不是做总结。迭代工具调用，直到找到根因或耗尽可用数据。
- 如果环境中没有某个工具，对应的 MCP 服务器可能未连接——应指出这一点，而不是绕过它。