Presentation: Can Claude Fix Itself? Using LLMs for Incident Response

Claude 能自我修复吗？使用 LLM 进行事件响应 - InfoQ

InfoQ 首页 演讲 Claude 能自我修复吗？使用 LLM 进行事件响应

DevOps

超越 PR：面向智能软件交付的新控制平面（9 月 17 日网络研讨会）

Claude 能自我修复吗？使用 LLM 进行事件响应

点赞

新下拉阅读列表

• 阅读列表

查看演讲

• 垂直

• 水平

• 全屏

速度：

• 1x

• 1.25x

• 1.5x

• 2x

下载

• 演示文稿

45:17

总结

Anthropic 可靠性工程师 Alex Palcuie 分享了使用 LLM 进行实际事件响应的实践经验。他解释了 AI 在观察日志和追踪时如何充当超人类角色，为什么在根本原因分析中它仍然难以区分因果关系与相关性，以及工程领导者如何在不削弱人类专业知识的前提下将 AI 集成到值班流程中。

个人简介

Alex Palcuie 是 Anthropic AI 可靠性工程团队的技术成员，他在该团队负责在大规模上保持 Claude 的可靠性。他肩负着一个不太令人愉快的任务：当 Claude 出现故障时，必须在没有 Claude 的情况下修复它。

关于会议

软件正在改变世界。QCon 伦敦通过促进知识和创新在开发者社区中的传播，赋能软件开发。作为以实践为导向的会议，QCon 专为技术团队负责人、架构师、工程总监和项目经理设计，这些人员在团队中影响着创新。

INFOQ 事件

• 2026 年 8 月 27 日，上午 1 点 EDT 为什么 AI 代理在规模上会失败：上下文是数据层问题 演讲者：Boyd Stowe - Tacnode 创始解决方案架构师

• 2026 年 9 月 17 日，上午 1 点 EDT 超越 PR：面向智能软件交付的新控制平面 演讲者：Mohit Suman - Harness 高级产品经理

演讲稿

Alex Palcuie：我是 Alex，我在 Anthropic 的 AI 可靠性团队工作，这意味着我的工作是确保 Claude 的正常运行。我一直在使用 LLM 作为实际事件响应的一部分，我想分享一个坦率而幽默的讨论，关于什么有效、什么无效。我是加入伦敦可靠性团队的两人之一。我最初三个月负责 Claude 的服务堆栈 Solo 的值班工作，这是一种非常高效且快速的学习系统方式，但确实压力很大。之后我为其他人完成入职培训，这样我就可以永远不再值班了。在那之前，我在 Google 工作，负责 Google Cloud 计算产品 GCE 的 SRE。我曾是 SRE 团队的 SRE，这是当故障严重到即使普通 SRE 也想撤出时的升级层级。我处理过很多页面通知，我对什么构成好的事件响应流程、什么构成坏的流程有自己的看法。起初持自然的怀疑态度，但自今年一月以来，我开始做一件感觉略微越界的事情，那就是在联系监控仪表板之前，先联系 Claude。

然后你们会问自己一个经常被问到的问题，这在晚宴上经常被问到。有人在会议大厅找到我，我的老公司朋友告诉我他们的副总裁让他们用AI做些事情，Claude真的能解决你们的故障吗？轮班制度现在只是Claude在负责吗？你们是否已经像十年前SRE书籍中写的那样，通过自动化把自己从工作中解放出来了？我理解为什么人们会问这个问题。如果有人能实现这一点，那一定是制造这个模型的公司。我们有无限的token。研究人员就坐在我隔壁的办公桌旁。我参与了模型的训练。如果真的是谁能做到，那一定是我们。让我直接回答这个问题。答案是否定的。我想先花点时间接受这个否定的答案。如果我站在这里告诉你们Claude能解决所有问题，那将是虚伪的。

我的团队即将迎来成立一周年纪念日。如果一个大语言模型能携带传呼机，我们可能不需要雇佣这么多员工。我的团队存在，我们在伦敦、都柏林和美国多个岗位招聘，这说明了问题的答案是否定的。不过，这里有个例外情况。这个例外与时间线有关。我认为我们中很多人不会对未来的某个时间点感到惊讶，那时我们或许能够实现这样的事情。今天，我也想指出Claude在轮班期间对我的帮助。回顾过去，Claude的宕机频率比我们任何人希望的都要高。之前我参与处理过一次故障，即使我正在参加一个会议。你可能已经注意到，有些人甚至在推特上发了相关内容，当Claude宕机时，我也有同样的感受。人们充满各种意见，纷纷@我。请继续这样做。这些是积极的推文。我也收到了一些负面的评论，但这就是如今社交媒体的常态。

有AI法律、AI医疗，还有AIOps。是的，确实有很多。这并不是一个完整的列表。当我制作幻灯片时，至少又有两家公司加入了这个领域。这种怀疑态度是有道理的。有些基准测试的问题是，模型是否能将这些预包装的问题转化为清晰的提示？这并不是你在凌晨3点被叫醒时看到的场景。实际发生的事件并不是格式良好的问题。我并不是对目标持怀疑态度。坦率地说，我真心实意地为这些人加油。我希望他们能够实践这些想法。这并不是人们通常假设的原因。真正的原因是，轮值是一种我们对人类征收的税，因为我们的系统还不够完善，无法自行维护。在座有多少人经历过轮值？你们知道那种身体上的现实。手机震动，你从睡着的状态瞬间进入事件指挥官模式。

并不是每次叫醒都糟糕。我喜欢处理一次好的事件。但问题是，这种累积的重量每天都在增加。从轮值的角度来看，我算是幸运的那类人。我遵循日光轮班制。伦敦在下午6点交接给西海岸，所以我可以去酒吧。对我最糟糕的情况是凌晨6点起床。像你们中的一些人，你们可能在凌晨3点或1点起床。你们在24/7的轮值中。可能只有四个人轮流。凌晨3点你们被叫醒，睡着后凌晨4点半又被叫醒，因为另一个数据库坏了。然后上午9点，你们必须去上班，参加站会，看起来专业且得体。在我的职业生涯中，我经历过这种情况。此外，我想明确说明，这不应该被视为一种荣誉。我们的行业有时会这样看待它，就像我们称之为战争故事一样。在危机处理室里，我们使用战斗隐喻。这是一种代价，是睡眠、注意力和人际关系的代价。当有人告诉我，他们正在构建AI SRE时，我的第一反应可能是，这永远不会成功。但我会说，我希望你们能成功。

还有第二个原因，这更冷酷一些。我从一位比我更资深的人那里得到的最好的早期职业建议之一是，你不会因为解决事件而获得晋升。第一次听到这句话时，我曾觉得这很荒谬，因为感觉应该如此。你是英雄。你被叫醒，你解决了问题，你修复了它。服务恢复了，人们在Slack频道里感谢你。当你刚入职时，这确实有帮助。比如，你能修复一个正在燃烧的生产系统吗？这是一个明确的信号，表明你正在成为优秀的工程师。但很快这种价值就会消失。当你成为资深工程师时，当然你可以解决这些问题。这是基本要求。这是你的工作描述的一部分。在大科技公司的术语中，真正推动晋升、让你成为技术负责人的是，当人们说你处于不同的层次。

这是构建一种机制，让整个类别的事件根本不会发生。不是解决一次火灾，而是从结构上确保这些火灾永远不会再发生。这就是我所设想的AI轮值梦想，如果，这是一个巨大的前提，一个大型语言模型能够处理通用的缓解措施、显而易见的回滚、是否尝试过、标准的修复措施。然后，我们这些人类就可以去处理预防部分、平台部分、那些能扩展的内容。这是一个梦想，我希望它能够实现。

OODA循环（观察、定位、决策、行动）

这是我用来解释事件管理的框架。在接下来的大部分演示中，我都会使用这个框架。它源自一位曾训练战斗机飞行员的美国空军上校。他试图解释为何一些飞行员即使驾驶的飞机性能较差，却能持续击败其他飞行员。答案并非飞机本身，而是那些在“观察-定位-决策-行动”循环中反复迭代的人。他们不断观察发生了什么？定位其含义？构建自己的心智模型？决策该采取什么行动？执行决策。然后再次接收反馈，因为世界已经改变，重新运行这个循环。我认为这与事件响应高度契合，虽然不完全匹配。当您收到告警时，查看图表、日志，构建对系统故障的初步认知。

您决定采取缓解措施，然后在终端输入命令并提交。我喜欢这个框架的原因在于，LLMs（大语言模型）与事件响应能力并非在所有阶段都表现一致。它们在不同阶段的能力差异巨大，业内称之为“锯齿状分布”。在某个阶段，它们可能表现出超人的能力；在另一个阶段，却可能非常危险；在另外两个阶段，其表现则模糊不清。

观察循环 - 超人般的能力

让我带您了解观察循环，这是我认为LLMs表现超人般能力的环节。它们能从系统中收集信号，阅读仪表盘，查询指标，提取日志，在海量数据中找到关键线索。虽然我们通过训练可以提升这方面的能力，但这并非人类的天然优势。我们的注意力有限，无法并行处理或扩展。Claude（您可以用任何LLM替代），在速度上具有显著优势。它不需要更聪明，但能快速执行任务并自我复制。它可以并行访问所有PromQL指标端点，几乎不会出错地编写语法。它不会因变量变化而疲劳，能以I/O速度读取日志，不再对2000行、4000行日志感到厌倦。这种规模化能力是任何人类都无法匹敌的。

最令人印象深刻的是，我们可以通过故事来说明。比如12月31日跨年夜，值班人员极少。我不记得当时是否在值班，但Claude Opus 4.5检测到500个HTTP内部错误。我打开Claude Code，用特定提示词让它分析。这不仅限于提示词，我编写了SKILL.md文档，教导模型请求的完整生命周期：请求如何到达边缘服务器，如何通过API前端，经过准入控制、配额检查和业务逻辑，再进入配备GPU、TPU和Trainium芯片的推理后端，完成矩阵乘法运算，最终将结果返回用户。公司内部还有另一份通用文档，教导Claude数据仓库的位置、关键表格字段，以及如何通过自我检索获取更多信息。后续对话内容已简化并移除了敏感信息，我已在Anthropic内部分享了完整内容。

Claude调取了过去一小时的服务器错误日志。它只需写一个SQL查询，几秒钟内就找到了答案：图像处理路径中存在一个未处理的异常。奇怪，12月31日。接着它进入代码库，由于是单体仓库，它定位到抛出该错误类型的代码位置，并推断出可能的原因。实际上它已经完整地展示了堆栈跟踪，但我不想用Python让你感到无聊。不过它并没有就此停止。这条代码路径已经上线数周，确实有记录。它检查是否有人最近修改过这段代码，结果发现直到今晚之前没有人触发过这个错误。它提取了三个失败的请求，读取原始JSON数据，其中有一个请求包含恰好22张图片，并附带了一个PDF文件。第二个、第三个请求包含的图片数量更多，而这个错误恰好在22张图片时触发。

为什么会发生这种情况？它继续追问，这些请求来自谁？它又运行了一个查询，分析请求日志，发现大约200个账户，都在今晚几乎同一时间开始发送恰好22张图片。用年轻人的话说，这在如今看来非常可疑。它继续运行另一个查询，没有停歇，执着地查找这段时间内创建的账户数量，大约有4000个。相同的窗口期、相同的邮件模板、相同的提供商。借用那位著名歌手的话："我一看见你就知道你会带来麻烦"，另外3800个账户至今没有发送过任何请求，它们处于休眠状态，自12月28日起就一直静止在那里，等待着什么。它继续运行查询，分析这些账户的创建频率，发现它们每分钟使用9个注册账号。这种频率大致符合我预期的账户滥用行为，可能设置了某种限制。

它随后得出结论：停止关注500错误，这明显是欺诈行为。这不仅可疑，而且值得标记。我简直要放弃使用Claude了，因为当它发现某些东西时会变得异常兴奋，而我对此感到震惊。我原本只会查看500错误，内部错误。我会将这标记为API团队的bug。我不会在12月31日联系账户滥用团队，让他们与我一起调查，因为我不具备访问PII数据的权限，无法了解那里发生了什么。你可能会认为从那一刻起这将是我键盘上的常态。我曾去攻读计算机科学学位，却只拿到了三个键盘快捷键。在AI领域，有一个著名的"move 37"，十年前AlphaGo（DeepMind算法）与李世石对弈时，所有围棋选手都震惊于AI为何做出那个举动。许多人经历过自己的"move 37"时刻。那天就是我的"move 37"时刻，我意识到那一年将格外特别。

故事二。这也是一个积极的案例。我们在生产环境中遇到了Rust恐慌。当我手动查看日志时，因为这是我仍然会做的事情，我还不知道原因，我的一位新同事，甚至还没有接受过值班培训，加入团队两到三个月，只是将Claude Code指向了日志。它立即找到了根本原因，比如在checkpoint.rs中的Rust恐慌，涉及某个段ID验证，文件名、行号、断言信息，甚至在我读完两页日志之前就完成了。然后他再次提示以获取完整的卷分析，比如五分钟内出现了数以亿计的恐慌，随后下降，接着再次激增。Claude在两个独立的硬件平台上都非常有用，因此我不需要联系我的云服务提供商询问。这还不是在分析原因，只是以比领域专家更快的速度收集信号。

这些恐慌都发生在预填充服务器上。它涉及重复的段ID。让我检查二进制文件的部署时间，看看在恐慌开始前是否有部署变更。它在我之前就找到了。团队中的新人比有经验的人更有效率，因为你们不受必须手动查看这些内容的限制。

定向循环

现在我们讨论定向部分。这是LLM中OODA循环变得有趣的地方。这是一个失败案例。我需要先向你解释LLM推理中发生的一件事，让你真正理解业务逻辑和发生了什么问题。当你向Claude或任何Transformer模型发出提示时，生成令牌的原始方法是获取整个序列，从第一个开始，然后将其完全输入Transformer，从而得到第一个令牌。然后你再次获取整个序列，再次输入Transformer，得到下一个令牌，这永远不会发生。你是在追加整个内容，但这种方法效率极低，没有人使用原始方法。这仅用于学术解释，因为当你生成第1000个令牌时，你已经对第一个令牌进行了1000次相同的矩阵乘法运算。

关键技巧称为KV缓存，在我们称为注意力步骤的过程中，每个令牌生成一个键和一个值向量，这些向量至关重要，不会改变。我们可以将它们保存在某个地方。这就是底部的图表。现在推理分为两个阶段。首先是预填充阶段，你在一个大的并行传递中处理整个提示，将所有键值对保存到缓存中，这被称为计算密集型阶段，因为你要进行大量矩阵乘法。然后在解码或生成阶段，你使用这个KV缓存，每次只将一个令牌输入机器。而不是重新处理整个前缀，你只需进行一次传递。这就是为什么，如果你曾经好奇过，Claude、ChatGPT、Gemini中的令牌会像流一样出现，因为它们确实是一个一个生成的。如果你的推理服务使用了大批次大小，你甚至可以看到它变得非常缓慢。

如果一台机器损坏，情况也是一样的。通常我们会维护它以确保您获得良好的用户体验。这个键值缓存可能达到数十GB的规模，而且非常容易损坏。它非常敏感，也很脆弱。当键值缓存崩溃时，您突然需要重新填充大量提示信息。这会消耗大量未准备的计算资源。这类事件在Claude系统中经常发生。当发生这种情况时，我的图表会呈现这种形状。灰色线条是过滤请求，红色线条是错误数量，橙色是事件窗口。请看这个形状，请求量在错误出现的瞬间几乎翻倍，然后两者同时下降。每次我都会问Claude，这个图表发生了什么？Claude的回答总是：请求量增加了，这是容量问题，只需要增加更多服务器。

我已经在CLAUDE.md中修正过这个问题六七次。你把它添加到CLAUDE.md中，它就会理解这种情境。但在其他99种情况下，它会错误地将相关性与因果性混淆。这并不具有帮助性。如果你团队有新成员加入，他们立刻会被这种说法误导。他们会立即认为这是容量问题，而实际上你只是丢失了缓存。为什么不先去修复缓存并弄清楚发生了什么？也许还能挽救。这就是为什么我认为我们不能依赖LLM进行事件响应。如果它能后退一步，尝试区分相关性和因果性，那就更好了。我知道对我们人类来说，这同样困难。我们每天都在与这种问题斗争。我们看到两条线，就会认为这肯定是某个发布版本的问题，或者其它原因。我们有这些伤疤，有经验。在过去一年里，我见过太多次这种故障，我无法忽视这个可能性。我可以去探索其他可能性。

自动化

让我们从更高层次讨论自动化。在软件工程领域，我们并不是第一个需要处理自动化系统的群体。美国汽车工程师学会（SAE）——也就是制造汽车的那些人——在十年前的2014年就发布了一个关于自动驾驶汽车的框架。因为那正是我们开始讨论自动驾驶汽车的时期。尽管现在伦敦还没有自动驾驶汽车。他们试图绘制自动驾驶汽车的图景，以便建立心理模型。他们描述了多个部分和多个阶段。自动驾驶汽车需要执行操作，比如转向和加速。另一个任务是监控驾驶环境。第三部分是降级性能，这是当出现意外情况时的备用方案，比如路口被堵住，或者需要超车停着的汽车。最后，他们最大的挑战，他们称之为"范围和系统能力"，在我看来，这实际上是在问：当加州阳光明媚时，这辆车会自己驾驶吗？

或者，当伦敦下雨时，它真的能自己驾驶吗？因为你不能把两者简单地混在一起。随着层级的提升，越来越多的列会被系统而非人类填充。有时在特定层级上两者会同时存在。目前市面上大多数现代汽车实际上都属于级别2。我们之所以能实现自动刹车，是因为我们信任这项技术。我们有车道保持功能，还有巡航控制。级别3才真正有趣。我认为特斯拉在美国已经实现了全自动驾驶，而在欧洲，奔驰和宝马仅在德国提供该功能，这属于级别3。级别4才是令人兴奋的。这属于Waymo的领域。你不需要司机，它就像一辆出租车。你进入车内，会看到方向盘自己移动。你在街上可以看到无人驾驶的汽车从A点移动到B点。

Waymo的无人驾驶汽车也在伦敦的街道上进行测试。我曾向一位在该公司工作的朋友抱怨，为什么进展这么慢？在我看来，你只需要从旧金山获取模型权重，翻转一下路标，汽车就能在道路另一侧行驶了。他告诉我，研究工作并不是这样进行的。

我想将这个概念映射到我的工作中，即生产工程领域。在座的有些人可能之前在其他演示中见过类似内容。在我看来，这些列对应的是检测，即识别问题的环节。这可能包括发现异常或关联信号（这些是更高级的），或者在出现内部错误时是否有良好的告警机制。然后是初始响应，即执行缓解措施，例如恢复服务器、执行kubectl scale命令、故障转移、回滚、降低有问题用户的配额，以及我们通常采取的遏制措施。接下来是预防环节，有人会深入分析以改进系统，例如查看导致问题的因素、架构变更等。还有确保此类问题不再发生的措施。此外，正如自动驾驶汽车团队所拥有的操作领域，这个系统是否只处理我精心监控的核心服务，还是可以让这个AI代理直接部署到其他团队？

它会自行学习并弄清楚发生了什么。我移除了级别0。我们很幸运，我们获得了自动化，因为计算机做得很好。级别1只是检测方面的一些辅助功能。级别2是大多数成熟系统所达到的阶段。可观测性已完全自动化。你有可靠触发的告警。即使没有AI，这仍然是自动化。你已经关联了一些信号，这就是我们所到达的阶段。人类仍然执行缓解措施，人类仍然编写所有修复方案。我们能否从当前所处的级别3（人类和AI共同参与响应）进入级别4？也就是我之前提到的，将人类从事件响应中移除。级别5，在我看来就是通用人工智能（AGI）。如果你可以将代理部署到任何地方，并且能将其作为队友，那将非常酷。

要做的事情的配方

这便是整体概况。这是通用的场景设定。现在我有五项在团队、公司以及个人层面都验证有效的实践方法。这些方法源于过去一年中所有人不断试错的经验总结。第一种模式是：当您收到告警并被通知时，作为理性的人，您会将告警信息通过基础设施即代码的方式进行管理，其中可能包含PromQL或其他查询语言的表达式。不要打开空白聊天窗口，也不要简单复制粘贴内容。只需将表达式传递给AI代理，向Claude下达类似“保持好奇，为我进行多角度分析”的指令。请告知Claude您的系统架构，让它寻找您通常不会关注的异常点。无论是您的Claude还是我的Claude，都会分析您的服务端点，判断这是区域级还是云服务级的问题。

它会根据状态码进行分析，对比上周的流量变化情况。我认为它执行这些查询的速度会比您手动查看仪表板更快。或者，当您收到告警并抵达电脑前时（通常需要5到10分钟），系统已经为您准备好了完整的分析场景。我们发现这种模式非常实用。就像我之前提到的欺诈检测案例，Claude能够发现更多潜在问题，这种能力非常有价值。这并不需要重大改动，只需将告警信息异步地作为提示信息传递给代理即可。

第二种方法是获取一个典型示例并追踪其在系统中的流转过程，但实际可以请Claude直接为您完成。我管理着多个采用不同日志模式、不同日志来源（分布在不同云平台）的系统。唯一能将它们统一起来的是追踪ID。过去当我需要查看请求在入口网关、API或推理层的处理情况时，通常需要手动打开每个窗口，通过书签或嵌套书签进行管理。如果让Claude自行完成，它实际上非常有用，因为它能在上下文中构建时间线，您可以直接与时间线进行对话。例如，您可以看到这个请求在三个服务器之间跳转，最终返回API时触发了10秒超时，这就是返回错误的原因。这向您证明，问题确实不在API超时，而是发生在后端服务。

它能够以连贯性追踪请求的完整生命周期。同时还能告诉您具体是哪台服务器，您可以进一步询问："那台服务器的情况如何？是CPU负载过高，还是内存使用存在异常？"这种方法会打开很多新的分析路径，即使有时需要重新验证模型提供的信息。

Pattern number three is, what changed in this window? I opened a discussion in the unconference for this track. I joined a company where there were not many deploys, and there were not many config pushes, and while rolling out monoliths, it's great, it also doesn't scale. Now I live in a microservices world, where services go out all the time, in config pushes, in feature flags, in cron jobs. It's really hard for me to correlate what changed with the moment my incident started. We've built this handmade tracker of all the big changes that happen across the company. It is curated, in the sense that we're not going to DDoS it with 100 QPS of events. If you give Claude the time window of when your incident happened, it will let you know really fast about the deployments. Not only that, it will go in and check, maybe there's a commit there that affects the image preprocessing.

Which is very useful for getting avenues of debugging and discovering. It's a bit like what I would do by hand previously. Now, obviously you need to stop it to be really excited by, I found the root cause. It's like, no. You found three possible issues that could have happened, and we really need to dive through. If it says, maybe roll this back, and big if your rollbacks are easy, then, yes, just roll back. Check if your errors are now down. It's much faster, and it saves a lot of effort.

Number four, postmortems or retrospectives. Claude is good at the tedious parts. Like, I used to hate these. I'm really sorry for some of the engineers that I worked with, but I sometimes felt it was teaching through fire to get your more juniors or medium engineers that joined the team. I was like, yes, you were part of this incident. You did not fight the big fight, but as a prize that you are part of it, you will now write the two- to three-page postmortem, so you understand the moving parts, so you're able to learn what could go wrong. It was always a chore. Like, no one wants to collate timelines or Slack threads. Now, I take the whole Slack channel, I take my Google Meet transcript, I put it in text format. I give Claude a prompt with the postmortem template that's like 80% the one from the SRE book, and it does produce something.

Two issues, though. One, it gets really bad at root causes. It's very jumpy. It's like, ok, this was the thing, and we all know it is not one thing. We all know it's not one root cause. There are many contributing factors. There are many issues. They're like the Swiss cheese model that you have to go through. It was never the rollout. It was never the code change. It was all the processes in the company that allow you to go in the incident. Claude doesn't know the history of your system, especially if your system has been there for 10 years. It doesn't know the reason you didn't test your secondary database fallback. It doesn't know tacit knowledge that you know. While you get an 80% story that's readable and convincible, I ask you strongly to not share it until you have reviewed it. If documents like these proliferate across the company and they're not vetted by humans, there's a loss of truth that happens, and I've seen it.

我们目前在事后分析中采用的一个技巧是，告诉 Claude：如果你对某些内容不确定，就插入一个待人类处理的待办事项。它具备自我反思的能力。虽然不完美，但确实存在。我们知道，在所有待办事项都解决、所有不确定内容的文本问题都修复之前，事后分析不会用于正式场合。因为如果将这些事后分析内容再次循环输入系统，输入垃圾，输出的也是垃圾。但你也可以借此获得一份关于过去事件的可靠记录。当 Claude 总结这些经过验证的文档时，它会成为撰写路线图的绝佳依据。

第五点，交接班。与事后分析类似，你也可以让 Claude 来撰写交接内容。我必须强调，你必须在公开渠道构建这些内容。所有值班操作都应在某个通道中进行，值班人员通过记录调试步骤来清晰表达他们在交接期间所做的一切。这很好。你也可以提示 Claude 仅负责总结部分。接手的人无需阅读伦敦白天发生的 200 条或 400 条消息，只需阅读一段带有链接的摘要即可跳转到相关线程。这可能是你能获得的最简单直接的成果。

学习问题

我想谈谈一个我尚未完全解决的问题，即学习问题。如果 Claude 找到了堆栈跟踪并建议回滚，你批准了它，而且它确实生效了，那你学到了什么？资深的事件响应人员并不更聪明，他们事先并不了解系统。他们曾经受过伤，他们见过其他人调试系统，他们拥有“伤疤组织”（经验）。如果 AI 开始做这些事情，我们的技能是否会萎缩？因为当你需要采取行动来了解系统发生了什么时，将不再存在反馈循环。正如《SRE 书籍》中提到的，我们让一个小团队负责关键任务系统的值班，而没有安排 50 或 100 名资深工程师每年轮值一次，原因在于，如果我们让这些工程师值班，而他们平时不值班时，会把修复页面背后问题视为自己的优先事项。

你不想再次被通知。这是你的全部使命。这是你整个团队的工作。如果 AI 开始修复这些问题，你就不会再感受到这种痛苦。你的激励措施可能不再一致。这是在资深人员层面的问题。对于初级和中级人员，你将不会在简单事件中接受训练。你无需在没有思考、或不查看操作手册历史记录的情况下被要求输入回滚命令。当发生模型无法修复的重大事件时，你可能会对如何应对此类事件产生误判。我对此感到真正担忧。OpenAI 的一位研究人员（名字是 roon）在 2023 年推文提到（这发生在 Claude Code 之前，甚至在人们知道 Anthropic 之前），杰文斯悖论将允许软件复杂性大幅增加，直到软件工程变得极其困难。

杰文斯悖论是AI行业中最受青睐的悖论。当技术进步提高了资源使用的效率时，反而因成本降低导致消费量上升而非下降。具体到我们的情况，编写软件变得更容易，因此我们编写了更多软件，导致复杂性增加而非减少，这意味着系统以更有趣的方式失效，进而引发更多事件，最终导致更多轮班值班。后续的回应指出，我们所做的所有开发工具改进都将被这种不断增长的复杂性抵消。然而，就像挥动魔杖一般，我们或许可以让代理打破这个循环。我们可以投入任意数量的计算资源来简化和管理复杂系统。我们已经制定了方案，我们懂得如何扩展团队，如何发展组织，我们拥有微服务。也许AI代理可以完成我们行业集体学到的这些能力。这取决于一个巨大的前提。不出所料，roon是一个频繁发帖的人，他的观点经受住了时间考验，并且让我夜不能寐。

AI模型随时间的发展轨迹

让我分享AI领域中最受青睐的图表。METR是一个评估AI能力的组织，他们的研究之一是模型能自主运行多长时间。横轴显示模型的发布日期，纵轴显示任务总时长。每个模型都会在一组任务上进行评估，这些任务之前曾要求人类完成并测量其成功率和耗时。如果模型能够完成至少50%的任务，我们就会在图表中标注持续时间。你可以看到，模型性能呈指数级提升，这种提升并非我们预期的线性增长，而是加速进行。许多人已经花费大量推文讨论这一现象。许多人绘制了S型曲线，认为增长最终会停止，就像这些曲线中的一些已经停止增长一样。自2022年以来，人们一直声称增长确实会停止。我们有AI扩展定律，我们知道当数据和计算资源增加时，模型会变得更好，它们将变得更加智能。目前的模型是历史上最差的，但从明天起，随着我们的持续努力，它们将不断改进。

更多带文字稿的演讲内容

录制时间：

2026年8月26日

演讲者：

• Alex Palcuie

#### 相关赞助商

#### 相关赞助商

• 2026年9月17日，东部时间下午1点：超越公关：面向代理软件交付的新控制平面 演讲者：Mohit Suman - Harness的高级产品经理

#### 本内容属于DevOps主题

##### 相关主题：

• 开发

• 架构与设计

• DevOps

• AI、机器学习与数据工程

• 可观测性

• Claude

• 监控

• QCon伦敦2026

• 大型语言模型

• QCon软件开发会议

• 文字稿

• 应用性能管理

• 人工智能

• 站点可靠性工程

• 自动化

• 轮班值班

• 性能

• 事件响应

• InfoQ

• 相关编辑

• InfoQ热门内容

• 云flare宣布Kitesurf，一个用于代理的浏览器引擎 JDK 27和JDK 28：我们目前所知的内容 云flare使用AI代理将Astro的GitHub问题减少85% 云flare将工程标准转化为基于AI的强制控制体系 云flare OS：基于能力模型构建的云flare开源企业AI平台 人类优势：为什么遗留代码库需要结对编程，而不仅仅是AI氛围