用AI调试AI：Incident.io的三大实战模式详解

文章正文

当AI系统变得足够复杂，人类已经无法独自理解和调试它们时，该怎么办？Incident.io的创始工程师Lawrence在AI Engineer大会上分享了他们的答案：用AI来调试AI。

这家为Netflix、Etsy、Skyscanner等公司提供事件响应管理平台的公司，正在构建一个能够全自动化生产环境调查的AI SRE产品。在这个过程中，他们发现传统的人工调试方式已经完全跟不上系统的复杂度，于是摸索出了三套行之有效的内部工具模式。

什么是AI SRE？ SRE（Site Reliability Engineering，站点可靠性工程）是由Google在2003年首创的工程实践，核心理念是将软件工程方法应用于运维问题。传统SRE工程师需要手动响应生产事故、分析根因、协调修复，而随着微服务架构的普及，现代系统的可观测性数据量已呈指数级增长——一次生产事故可能涉及数千条日志、数百个指标时序和跨越数十个服务的调用链路，人工处理的瓶颈日益凸显。AI SRE正是将这一高度重复且需要大量上下文关联的工作交由AI系统自动完成的尝试。

问题的本质：复杂度已超越人类认知极限

Incident.io的AI调查系统在每次事件发生时，会自动执行数百个遥测查询，检查日志、指标、链路追踪和历史事件数据，然后交叉引用代码库，最终给出根因分析和修复建议。

可观测性三支柱 现代云原生系统的可观测性建立在三大支柱之上：日志（Logs） 记录系统运行时的离散事件；指标（Metrics） 反映系统状态的时序数值数据，如CPU使用率、请求延迟；链路追踪（Traces） 则记录一次请求在多个微服务间的完整调用链路，帮助定位分布式系统中的性能瓶颈和故障点。Incident.io的AI调查系统需要同时处理这三类数据并与代码库上下文交叉引用，这正是其复杂度超越人类认知极限的根本原因。

这听起来很酷，但问题随之而来：你怎么知道这份报告是对的还是错的？

要验证一份调查报告的质量，工程师通常需要花一个小时左右深入了解整个事件的来龙去脉，才能判断AI的分析是否准确。而这个系统背后是成百上千个prompt的协同工作——光是聊天机器人就涉及十多个不同的agent和五十多个工具。更不用说调查系统中每个步骤都可能展开成数百个不同的prompt调用和工具调用。

多智能体系统的调试困境 现代AI Agent系统通常基于ReAct（Reasoning + Acting）或类似框架构建，允许LLM在推理过程中动态调用外部工具。当多个Agent协同工作时，系统形成多智能体网络，每个Agent负责特定子任务，通过消息传递或共享状态协调。这种架构极大提升了系统能力上限，但也带来了调试难度的指数级增长——一个Agent的轻微偏差会通过链式调用被逐级放大，最终导致完全错误的输出，而错误的传播路径在数百次工具调用中几乎无法人工追溯。

任何一个环节出现微妙的错误，都可能导致最终的根因分析完全偏离方向，而你几乎无法人工追溯错误的源头。

模式一：让编码Agent掌控Eval工作流

对Lawrence来说，Eval就是AI的单元测试。每个Eval接收输入数据，运行prompt，获取输出，然后根据评分标准判断是否通过。在Incident.io，这些Eval以YAML文件的形式存放在Go代码的prompt旁边。

Eval的本质与挑战 Eval（Evaluation，评估）在LLM工程中相当于传统软件的单元测试，但其复杂度远超后者。由于LLM输出具有概率性和非确定性，Eval通常需要定义多维度的评分标准，包括准确性、相关性、格式合规性等。更复杂的场景下，甚至需要另一个LLM来担任评判者（即LLM-as-Judge模式），由一个模型评估另一个模型的输出质量。这种"用AI评估AI"的嵌套结构，正是Eval维护成本极高的根本原因——测试数据、评分标准和被测prompt三者都可能随时间演化，任何一方的变化都可能使整个测试套件失效。

但Eval有一个致命问题：它们极其难以维护。真实的生产环境Eval可能包含一整个事件报告的数据，YAML文件动辄几兆字节。当这些文件膨胀到一定程度时，编码Agent因为上下文窗口限制而无法有效处理它们。

他们的解决方案是构建了一个轻量级的CLI工具——eval tool，专门为Agent设计。这个工具提供了简洁的接口：查询测试用例、编辑、替换、新增，让Agent无需将整个巨大的YAML文件加载到上下文中。

在此基础上，他们编写了一套专门给编码Agent使用的runbook（操作手册），定义了一个完整的红绿循环：

1. 创建失败的Eval：证明当前prompt存在问题
2. 修改prompt：让新Eval通过
3. 回归验证：确保修改没有破坏其他Eval
4. 精简prompt：防止反复修改导致prompt臃肿失控

在实际使用中，工程师只需在Claude Code中指向一个Eval，描述期望的行为，Agent就会自动完成整个修复流程。Lawrence展示了一个将人类查询转换为Loki日志查询的真实prompt优化过程，Agent自动添加Eval、多次验证通过率，整个过程流畅高效。

模式二：将调试UI转化为可下载的文件系统

Lawrence认为这是他们最大的突破。

他们之前为人类构建了精美的调试UI，可以查看trace、查看每个Agent的决策路径。但问题是：Agent无法使用这些UI。他们曾考虑过MCP或其他方案，但最终发现了一个更简单、更强大的方法——把所有UI内容下载为文件系统。

为什么文件系统优于MCP？ MCP（Model Context Protocol，模型上下文协议）是Anthropic于2024年底发布的开放标准，旨在为LLM提供统一的工具和数据源接入方式，类似于AI领域的"USB接口"，允许AI模型通过标准化协议实时连接数据库、API、文件系统等外部资源。然而Lawrence的工程实践揭示了一个反直觉的结论：对于调试场景，MCP的实时连接模式反而不如批量文件下载高效。原因在于，调试本质上是一个需要大量上下文关联的探索性任务——Agent需要在数百个prompt调用记录中自由搜索、交叉引用，而批量下载的文件系统让Agent拥有完整的离线上下文，可以利用自身的语义理解能力自主导航，无需频繁的网络往返和工具调用开销。

具体做法是：对于每个AI交互（调查、聊天等），系统可以将所有相关信息导出为结构化的文件目录。这些文件包含了所有prompt的输入输出、工具调用的结果、完整的trace信息。甚至复杂的trace可视化也能被精确地转换为ASCII文本格式，LLM对此的理解效果出奇地好。

这彻底改变了他们的调试工作流：

1. 收到用户反馈某次AI体验不佳
2. 下载该交互的完整文件系统到沙箱环境
3. 在Claude Code中打开，让Agent分析问题所在
4. Agent结合代码库定位需要修改的具体位置
5. 直接在同一个会话中完成修复，并用Eval验证

Lawrence特别强调：文件系统是极其优秀的Agent上下文载体。相比MCP或其他复杂的集成方式，批量下载所有信息让编码Agent自行搜索和分析，效果要好得多。

模式三：构建可重复的AI分析流水线

单个调查的调试解决了，但Incident.io每天要在数百个客户账户上运行数千次调查。他们有一个叫做"back test"的系统，每天批量运行调查并汇总出一个整体质量分数（比如86%的调查质量达标）。

但当分数下降时，你需要理解为什么。手动逐个分析显然不现实。

他们创建了一个名为"scrapbook