去年年终总结里写过一句话：AI 不会替代后端，但会把工具链改造得面目全非。
当时说得挺虚的，因为那会儿我也只是刚摸了一点皮毛。后来自己折腾了一个 AIOps 的小项目，才算对这句话有了点实感。这篇算是记录一下，为什么最后走到了多 Agent 这条路上。
起因
实习的时候接触到了运维监控这块。公司用的是 FlashDuty 聚合告警，夜莺管规则，Prometheus + Grafana 看指标，还有日志平台和 CMDB。
一开始觉得工具挺全的，但观察下来发现，真正费劲的不是某个工具不好用，而是出了问题的时候需要把好几个平台的信息串起来看。比如收到一条 CPU 高的告警，得先看指标趋势，再去翻日志有没有异常，还得查一下这台机器跑的是什么服务。每一步都不复杂，但串在一起就很累，尤其是信息散在不同系统里的时候。
那时候刚好 LLM 很火，我就想：能不能让大模型帮忙把这些信息串起来？
先试了单 Agent
最开始的想法很朴素——搞一个 Agent，给它挂上所有工具，让它自己去查指标、查日志、查告警，最后汇总一下。
结果发现不太行。
运维涉及的数据源比我想的多。指标查询要写 PromQL，日志分析要解析堆栈，告警系统有自己的 API，CMDB 又是另一套。全塞进一个 Agent 之后，工具列表变得很长，光描述就占掉一大堆 token。
直接的后果是模型变”笨”了——该调的工具经常不调，不该调的反而调了。你问它”CPU 高了帮我看看”，有时候它会去查 CMDB 而不是先看指标，感觉它自己也不知道该先干嘛。
我在 prompt 上花了不少时间调，加路由规则、加优先级，但效果一直不稳定。工具一多，prompt 就很难把每种情况都覆盖到。
后来怎么想通的
有一次跟同事聊，他说了一句话：运维团队本来就是分工的，看指标的和看日志的不是同一个人。
这句话点了一下我。
想想也是，没有哪个运维会同时精通所有系统。出了问题，是不同方向的人各查各的，最后碰头汇总。既然人是这么干的，Agent 为什么要一个人全包？
那不如拆开。指标相关的交给一个 Agent，日志和资产相关的交给另一个，再搞一个协调层来分发请求和汇总结果。
拆了之后的感受
实际做下来，确实比单 Agent 好了不少。
每个 Agent 的 prompt 短了很多，工具也少了，模型的准确率明显上来了。指标 Agent 只需要知道 PromQL 怎么写、异常检测怎么做，不需要关心日志长什么样。专注一件事的时候，模型靠谱很多。
另一个意外的好处是可以并行。两个 Agent 同时查，总时间等于慢的那个，而不是加在一起。排查问题的时候少等几秒，体验差很多。
还有就是兜底。指标 Agent 查不到的时候，协调层可以自动转给日志 Agent 试一下。这个在单 Agent 里面很难做，但在多 Agent 架构里就是一个 if-else 的事。
代价也有
多 Agent 多了一层协调的复杂度。Agent 之间怎么通信、协调层怎么判断该发给谁、上下文怎么传递——这些都是额外的活。
调试也更麻烦了。出了问题不是看一条链路就行，得搞清楚是哪个 Agent 的锅，还是协调层路由错了。
说不上这是最优解，但至少比一个 Agent 硬扛要靠谱。对我这种刚开始摸索的人来说，先跑起来，能用，比追求完美更重要。
这是 AIOps 探索系列的第一篇，主要聊动机和思路。下一篇打算写具体的架构——怎么拆的 Agent，协调层怎么做的。