如果你也带着一个小团队管基础设施，可能经历过这种别扭：工程部门的人数蹭蹭涨，但运维编制纹丝不动。尤其是“氛围编程”盛行之后，产品经理们都想拥有自己的迷你应用，我们工作室的研发团队在几个月里几乎膨胀了1.5倍。雪上加霜的是，某些区域开始频繁冒出可用性问题，连带着Slack支持频道里的消息狂涌而来，以至于工程师一整天有不少时间都耗在初步诊判这些消息上。最烦人的是什么？很多请求根本不该归运维管，但每一条都得至少跑一圈浅层诊断才能搞清楚。

于是，把第一线甩给AI代理的想法就这么冒出来了。那时我们已用自动化手段处理告警驱动的故障分析，效果不错，把同样的模式延伸到人工聊天请求，就是顺理成章的下一步。这篇文章是系列的上半部分，我会拆解几件事：先给过去一年的请求流量做了分类，挑出值得自动化的类别；然后在n8n里搭了一个分类器，利用MCP接入了Slack；接着把CI/CD事故助手做成了第一个跑通生产的分支；还加上了附件解析功能，不管是报错截图还是日志文件都能嚼得动；最后给工作流本身配上了正经的错误上报机制。

打开网易新闻 查看精彩图片

动手之前，得先摸清家里有什么垃圾要分类。我把过去一整年Slack频道里的请求记录倒出来，归进几个桶：基础设施变更，比如给现有基建设施打补丁、加一些标准化资源；全新安装，也就是部署以前没搞过的系统或集成；故障类，当前基础设施里哪块突然趴窝了；CI/CD类，构建失败、测试崩了、部署卡壳；问询类，关于基础设施的通用疑问；公告类，像计划性维护这样的纯通知信息；最后剩下一个“其他”兜底。一眼扫过去，第3到第5类是大头，也是自动化最该先啃的骨头。前两类需要审批，基本离不了工程师全程盯着，没有自动化的必要；公告类根本不需要代理插手，能准确识别、不把待命人员呼起来就行。

但在搭建任何处理分支之前，我们得先可靠地分辨一条新请求到底掉进哪个桶——这个分类器本身就是一切的前提。分类器建在n8n里，通过MCP串联Slack，把识别出来的请求顺着不同分支分发。第一条进入生产的分支就盯住了CI/CD事故：一旦流水线变红，代理自动介入诊断，把关键日志、失败步骤甚至相关报错截图都拎出来，省去人工逐条翻找的苦工。同时我要求工作流本身要有自省能力，出了岔子得立刻报出来，而不是闷声烂在管道里。

目前呈现的还是一个“有点粗糙”的版本：它能卸掉大量重复性的分流和初诊杂活，但在边界模糊的请求上偶尔还是会犯愣，需要人工兜底。下篇会接着聊剩下的几个分支——基础设施事故助手、常问问答式的知识助手，以及处理基础设施变更请求的流程。所有工作流和系统提示已单独发布，文末有链接。