如今公司交付的代码比以往任何时候都多， 这得益于代理式编码工具。对于产品团队而言，这种加速的开发节奏是福音。但对于站点可靠性工程师（SRE）而言，新机器编写代码的涌入却不是。

为什么？因为当系统出现故障时，没有人完全理解底层系统的工作原理。梳理出出了什么问题、如何修复以及如何在未来避免该问题，既困难又耗时。同时，时间约束依然固定，因为停机在今天并不比过去更受欢迎。

让人类去梳理如何修复代理构建的内容，容易导致人力耗尽；这是本末倒置。

如果代理在编写代码，而人类难以跟上，那么解决办法是否是用火攻火——部署 AI 代理在异常系统中找出根本问题？是的。好消息是，随着 AI 模型的改进，执行根本原因分析的能力正在提升，尽管 OpenRCA 基准仍远未饱和。

得益于这些性能提升，Sam Farid 和 Nate Heinrich 来自 Chronosphere（Palo Alto Networks 旗下公司）表示，代理是前进的方向。他们认为贵公司应该尝试在内部构建 AI SRE——在探索供应商方案之前。

Chronosphere 提供 AI SRE 产品，那么为什么其前线播客还在倡导自建替代方案？Heinrich 在《The New Stack》播客的最新一期中表示，他试图说服人们构建自己的代理，因为这样做是收集和组织公司系统工作方式信息的有用方式。

该练习的结果是一个 Markdown 文件，代理在嗅探根本原因时可将其用作关键上下文；对于愿意投入工作的公司而言，收集信息的过程既是旅程也是目的地。

自然地，Chronosphere 认为，当一家公司尝试构建自己的内部 SRE 代理后，会发现需要一个遥测服务来收集日志和跟踪，以及一个可观测性工具来存储和关联这些信息。而这正是它所提供的，同时还提供现成的 AI SRE。但我真的很欣赏与两位技术专家的对话，他们并没有试图告诉我他们的产品——且仅他们的产品——是前进的方向。

播放并享受吧。你可能会找到勇气，开始映射你的内部系统以供最终的代理式消费。毕竟，当凌晨时分某些东西崩溃，而你并没有编写刚刚宕机的代码时，你难道不想要帮助吗？

YOUTUBE.COM/THENEWSTACK

技术发展迅速，不要错过任何一集。订阅我们的 YouTube 频道以收看我们所有的播客、采访、演示等更多内容。

Group Created with Sketch.