Slack生产问题调试代理

要解决的问题

生产事故的通知往往先出现在 Slack 里：一条异常告警、一句“线上接口挂了”、一段排查到一半的讨论。工程师的第一反应通常是打开监控面板、翻文档、找运行手册，再手工把多路信息拼起来。当事故并发或跨团队流转时，这个流程会变得重复且容易遗漏——尤其监控数据分散在多个 MCP 服务器后面的时候。

核心能力与工作流程

这个技能把 Slack 消息作为事故入口，而不是等人工开单：

• 捕获 Slack 告警与调试请求：直接从聊天流中提取事故信号。
• 查询监控 MCP 服务器：把告警对应的指标、日志、拓扑数据拉进来，现场取证。
• 运行手册引导：按预写的 runbook 或 prompt 一步步推进，每一步都有明确动作和检查点。
• 多种自动化模式：可以是纯规则驱动的自动化，也可以挂接不同的 AI 模型做半自动调查，按团队现状选择。

典型流程：Slack 收到问题 → 解析意图 → 调用对应监控 MCP 拉数据 → 对照 runbook 执行检查项 → 汇总当前结论，交由人继续决策。

适用边界与注意点

• 它假设你已有可用的监控 MCP 连接、Slack app 和 Python 运行时，不替代数据采集本身的搭建。
• AI 路径依赖 OpenAI key，非 AI 自动化则不依赖，选择取决于团队的自动化程度。
• 本地示例用 ngrok 做端口隧道，适合开发验证；生产环境要按自身网络策略调整。
• 它给出调查路径和中间结论，但事故处置与发布决策仍需工程师确认。