Andrew Norrish：AI 时代的故障响应需要代码上下文

我是 Sourcegraph 现场工程总监 Andrew Norrish。我们与管理大型复杂代码库的工程师合作。过去主要服务于人的代码搜索、导航和代码图谱，如今越来越多地成为智能体的上下文引擎。我想讨论 AI 加快开发后，负责生产服务支持的团队面临什么变化。

我们反复从客户那里听到类似的故事：团队采用编程智能体，产出更多代码和拉取请求，同时面临将这些成果转化为发布的压力。在我的观察中，瓶颈从写代码转向人能多快审查代码。我还注意到，最近的一次客户顾问会议没有像过去的一些 AI 讨论那样聚焦节省多少人力。

我认为，AI 编写的变更越来越多，可能让故障更难预防和解决，尤其是在代码缺少充分审查或组织上下文就被合并时。响应人员可能面对陌生的变更，也没有运行手册。这些是我称从客户处听到的现象，并不是适用于所有组织的已证实发生率。

第一种现象是审查：随着智能体产出更多代码，开发者可能需要花更多时间确认它是否符合要求和监管规定。智能体仍会产生幻觉，在拥有遗留系统的大型组织中也可能缺少上下文。如果无法在本地检查完整代码库，智能体就可能根据局部视图作判断。

跨服务故障对工程师和智能体都可能难以追踪，团队只能回到缓慢的人工提交记录搜索。即使找到修复方法，如果需要不同团队分别在数百或数千个仓库中实施，推广修复也会成为瓶颈。在金融服务行业，合规要求进一步提高了风险。

我引用了一些行业估计，认为拉取请求的数量和规模、审查时间都在增加，而开发者对 AI 代码的信任程度与实际验证频率之间存在差距。这些是演讲中展示的估计，不应当作适用于所有团队的测量结果，也不能证明每次故障都由 AI 导致。

我认为，当 AI 在边界清晰的领域工作，并获得满足组织和合规要求所需的上下文时，更有可能取得成果。例子包括漏洞修复、安全扫描、迁移和原型开发。SRE 与平台团队本来就使用半自动化流程，因此既能观察 AI 对运营的影响，也能把 AI 用于现有工作流。

Sourcegraph 的商业产品以跨组织仓库的代码图谱、搜索和导航为核心。我把这些能力的组合称为上下文引擎，人和智能体都可以用它理解代码。我们团队也建议把这些能力用于故障调查，而不仅限于开发。

我将 SRE 工作分成调查、预防和修复。调查时，确定性搜索可以查询仓库、分支和提交记录，智能体搜索则可以提供附有引用的回答。这些是我介绍的产品能力，并非每个根因都能在特定时间内找到的独立证据。

在预防方面，我介绍了可以标记高风险或可能不合规代码模式的监控；在修复方面，代码搜索可以定位受影响位置，批量变更可以把修复推广到多个仓库。目标是缩短发现广泛问题与跨团队修复之间的延迟。

一个内部例子是安全分诊。Sourcegraph 收到 HackerOne 报告后，通过 webhook 调用智能体搜索。工作流帮助判断报告需要安全团队深入审查、提出变更，还是无需进一步行动。这是我们团队的实现，并不保证自动分诊不会漏掉报告。

另一家拥有 5000 多名开发者的客户，在服务停机或错误率飙升时使用内部根因分析智能体，把日志和追踪信息关联到代码。它先确定生产环境部署的分支或标签，再搜索历史记录寻找可能触发故障的提交。客户可以让智能体发起回滚和重新部署，或把调查结果交给 SRE。

另一家客户为大型单体仓库维护代码审查智能体，并用数百个历史分支评估它。我说，该客户使用只读代码查找智能体大规模搜索这些分支；评估通过后触发其发布流程。共同点是：让边界清晰的自动化能够获取相关代码上下文。