Kronos 如何自动化生产事件响应

“其他模型在我们修复之后，仍然一遍又一遍地指向同一个问题。当我们尝试使用 Enter Pro 时，它找出了真正的根本原因。”

WhyVenv 为 Quackathon 开发了 Kronos，一个自主的事件响应智能体，旨在帮助工程师更快地从生产环境错误定位到根本原因。

---

警报只是开始

当生产环境崩溃时，发出警报很少是最困难的部分。

Grafana 可以告诉你某些东西宕机了。日志可以告诉你某些东西失败了。仪表盘可以闪烁红光，声音大到足以在凌晨 2 点吵醒某人。

但在这之后，真正的工作才刚刚开始。

工程师仍然需要打开日志，理解错误，在代码库中搜索，猜测哪个函数起作用，决定问题是否紧急，并弄清楚下一步正确的操作是提交一个 GitHub issue、打一个补丁，还是进行全面升级。

在知道某些东西损坏与理解什么东西损坏之间的这段差距，正是事件响应变得痛苦的地方。

这也是 Dawood Khan 想到 Kronos 创意的地方。

Dawood 学习的是 AI，但大学毕业后他转向了系统工程。他的兴趣并非抽象。他亲眼目睹了生产系统是如何失败的、团队是如何响应的，以及在警报和修复之间仍然存在着多少手动调查工作。

在海得拉巴举行的一次 Grafana 活动中，这个问题变得更加清晰。工程师们描述了相同的模式：系统宕机，有人接到电话，然后团队开始熟悉的手动追踪故障的工作。

Quackathon 成为了构建不同解决方案的契机。由 WhyVenv 构建的 Kronos 最终获得了 Quackathon 第二名，在“赛道 01：软件 - 感知工作空间”挑战中脱颖而出，因为它将生产环境事件响应转化为了一种智能体工作流。

---

WhyVenv 构建了什么

WhyVenv 的项目是 Kronos，这是一个专为 Quackathon 的“感知工作空间”赛道构建的自主事件响应智能体。

这个想法很直接，但很有野心：

Kronos 接收生产环境错误，读取日志，检索相关代码，请求 AI 模型诊断可能的根本原因，然后决定下一步应该发生什么。

有时这意味着提交一个 GitHub issue。

有时，根据问题的严重程度，这意味着尝试进行修复。

其目的不仅是通知工程师生产环境损坏了。其目的是让工程师在警报发出后通常需要进行的工作中占得先机。

正如 Dawood 在采访中所说，Grafana 警报让人们很容易知道什么时候出了问题。问题在于之后的一切：找出导致问题的原因、Bug 存在于何处，以及团队应该采取什么行动。

Kronos 就是为了自动化这个中间层而构建的。

---

Kronos 背后的工程洞察

“我最自豪的部分是检索阶段。我们没有仅仅使用 AST 或嵌入，而是从追踪日志开始工作，因为这正是工程师通常寻找问题的方式。”

Dawood 最自豪的部分不是仪表盘、GitHub 集成，甚至不是 AI 诊断。

而是检索阶段。

许多 AI 编码系统试图通过嵌入、AST 解析或广泛的上下文加载来理解代码库。Kronos 采用了更符合工程师直觉的方式：从追踪日志开始，并使用它们来缩小搜索范围。

这个选择至关重要。

当工程师调试生产环境故障时，他们很少会先让 AI 模型阅读整个仓库。他们会看错误。他们会追踪堆栈信息。他们会在代码中进行 grep。他们从症状走向源头。

Kronos 就是围绕这种相同的直觉设计的。

该系统将日志作为入口点，检索最相关的代码，然后才将 AI 模型引入工作流。这使得模型不再是一个无所不知的预言家，而更像是一个根据集中证据包工作的审查者。

Dawood 很清楚，这种方法在大规模应用并获得信任之前仍需要改进。但对于演示来说，它起作用了。更重要的是，它反映了一种严肃的产品直觉：最好的 AI 系统不会盲目地取代工程工作流。它们会向工程师现有的解决问题的方式学习。

---

使用 Enter Pro 构建可观测性技术栈

Kronos 必须跨越团队以前没有深入使用过的工具来工作。

Grafana。Prometheus。Loki。仪表盘。日志。指标。警报。

对于一个黑客马拉松团队来说，在实际产品甚至开始运行之前，需要理解如此多的基础设施。

这就是 Enter Pro 对 WhyVenv 变得有用的地方。

团队在整个项目中都使用 Enter Pro 进行研究、想法完善和调试。Dawood 和他的队友使用它来理解可观测性技术栈，弄清楚各个组件是如何组合在一起的，并在系统表现不符合预期时解决集成问题。

有一个时刻脱颖而出。

团队卡在了为什么他们的数据警报没有正确发出的问题上。他们尝试过其他 AI 模型，但 Dawood 觉得其中一些模型在团队已经修复问题后，仍然在同一个点上打转。

当他们尝试使用 Enter Pro 时，它更直接地帮助他们识别出了真正的根本原因。

这就是在构建冲刺中至关重要的时刻。不是一个润色过的演示答案。不是一个通用的建议。而是切实地突破一个真正的阻碍。

对于 WhyVenv 来说，Enter Pro 不仅仅是一个生成代码的地方。它是一种快速理清陌生系统思路以继续构建的方式。

---

两天的专注

在团队开始认真开发之前，Dawood 就已经规划好了这个项目。

他知道他们想构建什么。他已经思考过了基本架构。他对工作应该如何分配有了大致的想法。

然后，真正的黑客马拉松节奏接管了一切。

第一天并不全是代码。团队成员聚在一起，聊天、开玩笑，并找到了默契。真正的构建在这之后到来：一次集中的冲刺，他们分工合作，研究陌生的部分，实现核心流程，并不断完善产品，直到它能够整合在一起。

架构开始时很简单：

崩溃报告 -> 相关代码 -> LLM 诊断 -> issue 或修复。

然后，随着团队的构建，每个部分都变得更加清晰。

这种简单性正是 Kronos 令人瞩目的部分原因。它并不是从一个复杂的智能体软件理论开始的。它始于每个值班工程师都理解的工作流：某些东西坏了，找出原因，决定下一步做什么。

---

Kronos 对 AI 智能体的启示

Kronos 不是一个坐在代码库旁边的聊天机器人。

它更像是一个工作流智能体：一个接收来自现实世界的信号、收集正确的证据、仅在推理有用时才请求推理，然后将结果路由到工程师已经使用的工具中的系统。

这种区别至关重要。

Dawood 对 AI 系统的成本和控制问题非常敏感。在采访中，他谈到了 Token 的使用、昂贵的模型调用，以及当确定性的后端逻辑可以更高效地完成部分工作时，不让智能体处理一切的重要性。

对于在 2026 年使用 AI 进行构建的人来说，这是一种成熟的直觉。

AI 智能体的未来不仅在于使用更强大的模型。它还在于知道什么时候不使用它们。哪些部分应该是代码？哪些部分应该是检索？哪些部分应该是模型推理？哪些部分应该保持人工审核？

Kronos，即使作为一个黑客马拉松项目，也指向了这个问题。

---

下一步是什么

在准备好投入生产环境之前，该项目仍有需要回答的问题：

• 检索方法在更大的代码库中扩展得如何？

• 应该如何校准严重程度和自主性？

• 智能体什么时候应该提交 issue 而不是尝试修复？

• 多少上下文才足以让模型诊断真实的事件？

• 在任何内容到达生产环境之前，人类应该批准什么？

这些都不是小问题。它们正是让 Kronos 值得关注的问题。

因为生产环境事件不会消失。唯一的问题是，每一次响应是否都必须以手忙脚乱的恐慌开始。

Kronos 设想了一个不同的第一步：看到故障的系统也可以开始理解它。

这就是 Enter 存在所要支持的。

不仅是更快的代码。还有从真实的痛点到可用产品的更快转化。

对于 WhyVenv 来说，这种转化足以将一个痛苦的工程模式变成 Quackathon 的获奖项目之一。

---

探索 Kronos。

这个故事是我们 Quackathon 开发者系列的一部分，在该系列中，我们一次深入一个项目，以了解开发者使用 Enter Pro 制作了什么、他们为什么要构建它，以及他们的工作告诉了我们关于 AI 驱动的软件创造的未来。敬请关注。