根据 OpsWorker（代理 AI 同事即服务）的博文，企业的站点可靠性工程实践正在悄然发生转变。团队不再是简单地将故障告警发送给一台机器，而是设计出能与值班工程师协同工作的多智能体 AI 系统。它能缩小搜索范围，自动处理事件调查中的繁琐步骤，并将判断决策权留给人类，实现了人机协作的新模式。
在一篇深入探讨多智能体事件响应的博文中，OpsWorker联合创始人Ar Hakboian认为，在事件管理中，AI 真正的价值在于协调。Hakboian 描述了一个模式，其中包含多个专用的智能体：一个用于日志，一个用于指标，一个用于运行手册，诸如此类。有一个监督层负责协调，决定谁做什么以及按什么顺序进行。文章作者解释说，他们的目标是通过提出假设、起草查询以及策划相关上下文来减轻工程师的认知负担，而不是完全取代人类。
该文简洁地概括了这种方法，指出 AI 智能体应该提出假设、查询和补救选项，而人类则负责判断和审批。这种框架与Zefang Liu最近在arXiv上发表的一篇学术论文非常接近，该论文使用桌面推演框架 Backdoors 和 Breaches 研究了大语言模型智能体团队在模拟网络事件中如何进行协调。
Liu 在实验中比较了集中式、非集中式和混合式团队结构。他发现，同质集中式混合结构成功率最高。相比之下，没有领导者的非集中式领域专家团队更难以达成共识。Liu 的发现表明，让自主智能体一起工作不仅不能加快问题的解决，反而会导致更多的混乱。就对 SRE 的影响来说，最好是有一个监督者或协调者。不过，混合式领域专家团队有时比同质的通才团队更难推进工作，即使有监督者也是如此，这似乎是因为专家容易在优先级上产生分歧，无法就单一行动方案达成共识。
根据 OpsWorker 的博文，他们通过明确的角色设计和结构化交接间接地解决了这个问题。为了避免陷入僵局，每个智能体都有一套清晰的工具和责任。
虽然实验验证了技术可行性，但距离生产应用还有很大的差距。智能体是出色的技术调查员，但缺乏生产事件响应所需的安全控制、可靠性工程设计和运维成熟度。
—— Ar Hakboian
最近，云咨询公司 EverOps 写了一篇关于LLM如何转变SRE工作而不取代工程师的文章。该文也支持这一假设。按照该公司的说法，在受访的 SRE 专业人士中，只有少数受人认为 AI 将在两年内取代他们的工作，而绝大多数人只是将其视为简化工作的工具。文章指出，实际的应用场景集中在日志摄取和异常检测、分类自动化、告警聚合和基于检索的内部知识库访问。EverOps 还揭示了承诺与实际表现之间的差距，在他们提到的 ClickHouse 实验中，研究人员在真实的根因分析场景中测试了多个先进的语言模型，结果显示，自主分析的效果远不及人工引导下的调查。
OpsWorker 的博文通过强调评估和安全措施来传递了这种谨慎态度。文中提出了一系列的建议，如用真实事件测试多智能体设置，并授予智能体最低限度的必要权限。Hakboian 建议逐步上线应用这些智能体技术，开始只允许只读访问，然后在验证它们的工作没有问题后才允许进行受控的智能体操作。作者还建议，在事件处理场景中，与其费时费力地设计提示，不如使用护栏并谨慎地整合工具。Hakboian 一直呼吁人类进行监督，并强调智能体与工具交互时存在出现幻觉的风险。
亚马逊云科技发布了一个基于其 Bedrock 平台构建的多智能体SRE助手的详细示例。其架构几乎是直接反映了 OpsWorker 的博文内容：一个监督者协调四个专门的智能体，分别用于指标、日志、拓扑和运行手册，然后它们全部连接到一个综合的 Kubernetes 后端。亚马逊云科技的文章侧重于供应商视角，与 Bedrock 和 LangGraph 等特定服务相关，但与 OpsWorker 博文中工作流优先的理念一致。
总的来说，这些信息源表明，智能体 SRE 正在迅速成熟，而组织正在使用它们来增强员工的能力而不是取代他们。对于希望在事件工作流中引入 AI 智能体，同时又希望保留人类工程师控制权的团队，OpsWorker 的博文提供了一个周全而详尽的方法论。
原文链接：
