当前软件工程领域的许多AI工作流，尽管能在代码编写、堆栈追踪解释或PR总结等方面提供辅助，但在故障管理的核心操作循环中，人类仍然扮演着中心角色。这意味着开发者需要手动发现问题、进行优先级排序、深入调查并最终决定问题的严重性。
作者最近在发布一个新功能时，就亲身体验到了这一局限。尽管新功能经过了充分测试，但一个相当严重的崩溃却悄无声息地溜了过去，因为它未能触发Firebase Crashlytics的通知阈值。这次经历让作者意识到一个关键的空白：如果仅仅依赖被动告警，那么在没有手动检查的情况下，许多重要问题可能会被遗漏，这激发了他构建一个更主动、更自动化解决方案的构想。
作者利用内部MCP工具已有的Crashlytics访问权限，开始尝试自动化整个崩溃问题的发现和调查流程。由此构建的名为Hermes的系统，目前已实现了高度自动化。
该工作流大致如下运行：Hermes每四小时检查一次Crashlytics以发现新问题。一旦检测到问题，系统会自动进行文档记录和优先级排序。随后，它会将一个问题一次性委托给专门的AI智能体工作流。这个智能体将利用MCP收集额外的上下文信息，尝试复现崩溃，编写或更新相关测试，构建对应的平台包，并努力寻找解决方案。如果成功，它会打开一个拉取请求（PR），并在整个过程中动态更新问题文档。
一旦PR成功合并，Hermes会自动关闭Crashlytics中相应的故障报告。值得一提的是，CodeRabbit甚至会在人工开发者介入之前，对PR进行初步审查。整个端到端流程实现了大约90%的自动化，人工参与主要集中在对建议修复方案的最终审查和验证环节。
这个项目的一个关键发现是，最大的突破并非源于AI模型原始的智能水平，而是来自其与现有操作流程的完美契合。尽管底层模型至关重要，但它们能否无缝集成并在实际操作环境中高效运行，才是更为关键的因素。
一个擅长博客写作的模型可能不适用于复杂的代码库，而一个在基准测试中表现良好但成本低廉的模型，如果其调查质量低下或修复方案薄弱，最终可能会浪费大量时间。最终目的并非为了减少AI的投入，而是为了更快、更可靠地解决问题。
工作流的不同阶段需要不同的AI能力。例如，故障分诊相对轻量化；Crashlytics本身已经提供了严重性评级、受影响用户数量、堆栈追踪和环境信息。在这种情况下，较小、更高效的模型通常就能有效地完成优先级排序。
然而，调查阶段则对推理质量有更高的要求。在这个阶段，系统需要理解平台局限性、验证假设、阅读文档，并且如果最终无法解决问题，还要能合理解释原因。
这个工作流在发现意料之外的边界情况方面也展现了其价值。例如，一个生产问题是由于用户在Android设备上尝试上传一个200MB的文件而引发的。该功能本身没有缺陷，测试也并非不足；问题在于，对于Android设备上大文件上传的特定限制（iOS对此有不同的处理方式）未被考虑在内。这个场景突显了系统发现被忽视的设计考量，并推动自动化问题检测边界的能力。
