我们为每条区块链都配备了专属的值班智能体

Alchemy 如何使用 230 多个智能体对节点集群的告警进行分诊和修复

Alchemy 为 230 多个区块链网络运行基础设施，运营着数千台服务器，每年支撑超过 1 万亿美元的交易。我们的业务就是让每个节点保持健康和同步，使依赖它的应用持续正常运行。

在过去四个月里，我们构建了一个智能体工厂，管理 230 多个独立的智能体，每个区块链网络一个，用于调查和解决事故。现在，告警解决时间的中位数为 8 分钟，而由人工处理时为 30 分钟。约 73% 的告警由智能体在无人参与的情况下解决，每月约 120 个工程小时不再用于诊断和修复问题，而是转向更有价值的工作。

问题：多样化基础设施每周产生 500 条告警

我们的节点集群每周为 Node Ops 团队产生 500 多条告警。和任何软件工程团队一样，值班工程师会对每条告警进行同样的五问调查：

1. 是哪个网络？
2. 客户是否受到影响？
3. 问题出在我们的集群，还是上游的网络本身？会不会是某次部署？
4. 以前发生过吗？
5. 下一步该做什么？

这些答案分散在仪表板、请求日志、告警系统、部署历史和过去的事后复盘中。乘以 500 条告警，再加上每个网络各自的特殊情况，大量时间被用于重建上下文和修复问题，而不是消除根源。

设计原则：为决策而优化

一个能访问所有工具的智能体会把所有工具都读一遍。结果是一份冗长的报告，工程师仍需从中翻找。工程师需要的不是更多数据，而是一个决策：这条告警是否需要人工处理，紧急程度如何？

因此我们只有一条原则：为决策而优化。

工作原理

1. 先确认影响，再打扰人工

我们的告警系统已经在检测问题，每周 500 多次。智能体无需重复检测。它们的任务是判断是否有人需要关注。

触发的告警不自动等于事故。 只有当智能体找到真实损害的证据时，告警才会成为事故，例如面向客户的服务器错误、延迟显著上升，或集群中所有节点宕机。

如果智能体没有发现损害，它会把调查结果发布到单独的“FYI”频道。只有真正的事故才会进入值班频道。

2. 有结论的调查

智能体发布三到五条要点，并以两种结果之一结束。如果不需要人工，智能体会自行解决告警。如果需要人工，它会把更深入的调查结果发布到值班频道。

五个真实示例：

工程师先读结果，再看证据，甚至可以不看证据。

3. 在代码强制执行的限制内行动

如上所述，解决告警通常无需人工参与。我们赋予智能体重启不健康节点以恢复服务的能力，以及在节点配置与预期不符时标记配置漂移的能力。

每个操作的范围都很窄，并由服务器代码强制执行。智能体可以：

• 每次只为一个网络重启一个节点，因此不会一次移除过多容量。
• 为自己负责的网络暂停自动重启系统，最长 24 小时，以避免数据损坏。
• 请求人工介入。风险较高的变更，例如维护标记或重复重启，需要先预览，再由人工重新确认。

除这些路径外，智能体只从其限定范围内的知识库和操作手册中读取数据。让智能体与线上生产基础设施交互时，限定智能体的访问范围是关键。

4. 让“问题在上游”成为最难得出的结论

运行区块链节点的乐趣（至少我们认为是乐趣）在于，它们本质上就不可靠。客户端可能出问题，不同网络在不同工作负载下的表现并不一致，上游网络运营方（验证者、排序器等）也可能导致我们的基础设施停滞或故障。因此，每个智能体都需要针对特定网络的记忆和指令，用来回答一个问题：“是我们的问题，还是他们的问题？”

智能体必须满足四个条件，才能判定为“上游”问题：

1. 从错误率和延迟来看，我们的节点必须是健康的。
2. 上游错误（例如网络“停滞”）在我们运行的每个区域中必须表现一致。
3. 必须有独立的服务商确认，并且客户请求在其他方面看起来正常。
4. 仅出现在部分区域的停滞永远不是上游问题。

这条规则双向适用。在一条告警中，有六个节点不健康，但网络仍在产生新区块。智能体判定这是我们的服务问题，而不是上游停滞。

成果：更高的可靠性，更快的解决速度

得益于这些投入，工程时间用在了有意义的工作上，客户在其构建的任何网络上遇到的问题都能更快得到解决。

• 告警解决速度提升近四倍。 解决时间中位数从 30 分钟降至 8 分钟。
• 大多数告警无需工程师处理。 智能体自行解决约 73% 的告警，而 6 月时这一比例为 0%。
• 团队每月节省约 120 小时。 处理告警的工程时间从每月约 150 小时降至约 30 小时，减少 80%。这相当于每月约三个工程师周，现在用于消除根源，而不是重建上下文。
• 智能体首次判断即准确。 在过去一个月的 200 多次调查中，首次根因判断准确率约为 98%。

给构建自有值班智能体的团队的建议

1. 衡量结果。 用解决时间、准确率和节省的工程小时来评估值班智能体。
2. 要求给出结论。 一个交回一页调查结果的智能体只是转移了工作，并没有消除工作。要求它先给出决策：自行解决，或呼叫人工并说明紧急程度。
3. 授予命名明确、范围固定的操作。 有 24 小时上限的单节点重启比原始 shell 访问更安全。
4. 给每个智能体划定窄范围的职责和长期记忆。 每个网络一个智能体，并配有该网络的运行手册、特殊情况和事故历史，就不必在每条告警上重新了解你的系统。它已经知道这是今天的第七次停滞。

但最重要的是：不要止步于问题调查。 能够预防问题到达人工的智能体，会放大你投入在客户价值上的工程努力。

喜欢这类应用 AI 与基础设施的交叉内容吗？

• 关注 @onewaysidewalks，了解 Alchemy 在 AI 方面的最新动态。
• 加入我们的团队。我们正在招聘！