IncidentBrain：构建一个能从生产事故中学习的 SRE 智能体

持续运营记忆如何帮助 AI 事故响应智能体从以往的事故中学习，而不是每次都从零开始。

生产事故很少是完全全新的。

支付 API 今天可能因为 Redis 连接问题开始返回 503 错误，而非常类似的事故可能在数周或数月后再次发生。

处理过先前事故的工程师可能记得什么方案有效。

但如果该工程师不在场呢？

如果这些知识埋藏在旧的事故工单、事后分析报告、仪表板或某人的记忆中呢？

这就是 IncidentBrain 背后的想法起源。

IncidentBrain 是一个由 AI 驱动的 SRE 事故响应智能体，围绕一个简单的理念设计：

AI 智能体应该能够从以往的生产事故中学习，并在调查未来事故时运用这些经验。

IncidentBrain 没有将每个事故视为一个全新问题，而是使用 Hindsight 维护持久化的运营记忆。

当一个事故被解决后，系统会记住三件事：

• 采取了什么行动
• 观察到的结果是什么

之后，当类似的事故发生时，IncidentBrain 可以检索那些先前的经验，并在调查期间将其作为历史上下文提供。

这创建了一个持续学习循环：

调查 → 解决 → 记忆 → 召回 → 再次调查

目标不是取代 SRE。

目标是让 SRE 的先前经验在下次事故发生时更容易被检索到。

问题：无状态的 AI 是不够的

传统的 AI 助手可以分析事故报告并建议可能的原因或修复步骤。

然而，除非明确提供相关的历史信息，否则每次交互实际上都可能从零开始。

对于 SRE 来说，这会在 AI 推理与组织经验之间产生鸿沟。

考虑一个简单的场景。

支付 API 返回 HTTP 503 错误，Redis 连接正接近配置的连接限制。

工程师以前可能遇到过完全相同的模式。

也许先前的事故揭示了 Redis 连接池耗尽是罪魁祸首，增加连接池大小就解决了问题。

但无状态的助手不会自动知道这一点。

这正是 IncidentBrain 旨在解决的问题。

IncidentBrain 不是将每个事故视为孤立的对话，而是为智能体提供了一种从先前事故中检索相关经验的方法。

目标不仅仅是生成另一个 AI 建议。

目标是让建议能够访问之前发生的运营经验。

核心思路：持久化运营记忆

IncidentBrain 使用 Hindsight 作为其持久化记忆层。

当事故被解决后，智能体会存储一个包含三条重要信息的经验：

• 采取了什么行动
• 观察到的结果是什么

例如，一个事故经验可能如下所示：

Incident: Payment API returned HTTP 503 errors.
Action: The Redis connection pool was increased from 100 to 250.
Outcome: The HTTP 503 error rate returned to normal.

这不是简单的对话记录。

它成为了可在未来事故与先前事故相似时被检索的运营经验。

工作流程很简单：

事故 → 记忆 → 未来事故 → 召回先前经验 → 调查

这创建了一个重要的反馈循环。

智能体不只是生成一个答案然后忘记它。

事故的结果成为其未来上下文的一部分。

从事故调查到事故学习

IncidentBrain 的工作流程有两个主要阶段：

当提交新的事故时，IncidentBrain 首先在 Hindsight 中搜索相关的先前经验。

例如，智能体可以使用以下方式召回先前的事故知识：

memory_result = self.memory.recall(
    bank_id=self.bank_id,
    query=incident
)

memories = []

for result in memory_result.results:
    memories.append(result.text)

检索到的经验随后作为历史上下文提供给 LLM，用于当前调查。当前事故与检索到的记忆在模型生成建议之前会被合并。模型被指示区分四类信息：

• 未知信息

这种区分在生产环境中很重要。历史配置值不应自动被视为当前配置。例如，假设先前的事故涉及 Redis 连接池大小为 100。当下一次事故发生时，该值可能不再有效。相反，历史值可以被视为证据，而工程师在做出更改之前验证当前系统状态。这有助于 IncidentBrain 使用先前经验而不会盲目地将其应用到当前事故。

调查事故只是学习过程的一半。

在工程师调查并解决事故之后，IncidentBrain 提供了一种记录两条重要信息的方式：

• 采取的行动
• 结果

例如，智能体可以将已解决的事故存储到 Hindsight 中：

experience = f"""
HISTORICAL SRE INCIDENT EXPERIENCE
Incident:
{incident.strip()}

Action that was taken:
{action_taken.strip()}

Observed outcome:
{outcome.strip()}
"""

result = self.memory.retain(
    bank_id=self.bank_id,
    content=experience
)

事故、行动和观察到的结果现在被存储为可重用的经验。这将一个事故的解决转化为可在未来调查中检索的运营知识。下次发生类似事故时，IncidentBrain 可以从 Hindsight 中召回此经验并将其作为历史上下文提供。这创建了完整的学习周期：

IncidentBrain 学习循环

完整工作流程可以可视化为：

事故 → 召回 → 建议 → 解决 → 学习

调查 → 解决 → 记忆 → 召回 → 再次调查

重要的是，这个学习过程不需要重新训练底层语言模型。相反，智能体通过积累相关的运营经验来改善其未来上下文。

让我们通过一个真实的事故来了解 IncidentBrain 的记忆循环是如何工作的。

假设支付 API 开始返回 HTTP 503 错误。

同时，Redis 连接已大幅增加，正接近配置的连接限制。

工程团队调查了该事故，确定 Redis 连接池耗尽是可能的原因。

他们将 Redis 连接池从 100 增加到 250。

更改之后，HTTP 503 错误率恢复正常。

IncidentBrain 然后存储该经验：

Incident: Payment API returned HTTP 503 errors because Redis connections were approaching the configured limit.
Action: Increased the Redis connection pool from 100 to 250.
Outcome: The HTTP 503 error rate returned to normal.

此经验被保留在 Hindsight 中。

类似的事故再次发生

现在假设数周后，支付 API 再次开始返回 HTTP 503 错误。

Redis 连接再次接近配置的连接限制。

工程师无需手动搜索旧的事故报告来找到先前的解决方案。

IncidentBrain 可以从 Hindsight 中召回先前的经验。

带历史记忆的事故调查

当类似事故发生时，IncidentBrain 从 Hindsight 中检索相关先前事故经验，而不是从空的上下文开始。

检索到的经验成为新调查的历史证据。

LLM 然后可以考虑：

• 现在发生了什么？
• 先前事故期间发生了什么？
• 先前什么行动有效？
• 当前情况与先前情况是否足够相似，可以考虑先前的解决方案？
• 仍需要验证哪些信息？

AI 建议

检索到的历史经验被用作证据，而 LLM 分析当前事故并生成建议。

这是第一次调查与第二次调查之间的关键区别。

第一次调查创建了运营知识。

第二次调查可以从中受益。

智能体不再是从空的上下文开始。

IncidentBrain 采用围绕四个主要组件构建的相对聚焦的架构：

• React — 提供事故调查仪表板
• FastAPI — 暴露调查和解决的后端 API
• IncidentBrain Agent — 协调记忆检索、LLM 推理以及存储事故结果

Hindsight + Groq — Hindsight 提供持久化运维记忆，Groq 提供 LLM 推理层。

整体流程如下：

React Dashboard
       │
       ▼
FastAPI Backend
       │
       ▼
IncidentBrain Agent
       │
       ├──────────────► Hindsight Memory
       │                    │
       │                    ▼
       │              Previous Incidents
       │
       ▼
Groq LLM
       │
       ▼
AI Recommendation
       │
       ▼
Engineer Resolution
       │
       ▼
Action + Outcome
       │
       └──────────────► Hindsight Memory

React 前端提供了工程师提交和调查事件的界面。FastAPI 后端暴露了连接前端与 IncidentBrain 智能体的 API。智能体充当协调者角色。它从 Hindsight 检索相关的历史经验，将当前事件与历史经验结合后发送给 LLM，并生成建议。事件解决后，智能体将采取的行动和观察到的结果存回 Hindsight。这就形成了反馈循环，使后续调查能够受益于之前的事件。

该系统将事件仪表盘、后端 API、IncidentBrain 智能体、持久化的 Hindsight 记忆和 Groq LLM 连接成一个持续的事件学习工作流。

将 IncidentBrain 连接到 LLM

当 IncidentBrain 从 Hindsight 检索到相关的历史经验后，当前事件和历史上下文被传递给 LLM。

当前实现中，使用 Groq 作为 LLM 推理层。

集成的简化版本如下：

response = self.groq.chat.completions.create(
    model="openai/gpt-oss-120b",
    messages=[
        {
            "role": "system",
            "content": "You are an experienced SRE incident response assistant."
        },
        {
            "role": "user",
            "content": prompt
        }
    ]
)

recommendation = response.choices[0].message.content

重要的部分并非简单地调用 LLM。重要的是模型收到的上下文。提示词包含当前事件以及从 Hindsight 检索到的相关历史经验。这使得模型能够在推理当前情况的同时，也考虑过去类似事件中发生了什么。换言之：当前事件 + 历史经验 → LLM 推理 → 建议

Hindsight 提供持久化记忆，Groq 提供 LLM 推理层。因此这两个组件在系统中扮演不同的角色：

• Hindsight：记住之前的运维经验。
• Groq：对当前事件和检索到的上下文进行推理。

证据驱动的建议

在使用历史记忆进行生产运维时，有一个重要的设计考量。

过去的经验应该被视为证据，而非绝对真理。

之前的事件可能发生在不同的：

• 基础设施配置下

因此，IncidentBrain 被设计为避免盲目地将历史信息应用于当前事件。

智能体被指示：

• 避免捏造指标或配置值。
• 明确区分历史事实与当前观察。
• 在做出更改之前验证当前配置。
• 识别风险和不确定性。
• 当可用证据不足时，请求进一步调查。

例如，假设之前某个事件是通过将 Redis 连接池从 100 增加到 250 来解决的。

这并不意味着同样的更改应该自动应用到所有未来的 Redis 相关事件。

当前系统可能有不同的配置、流量模式或潜在问题。

相反，之前的解决方案成为工程师在调查当前状态时可以考虑的一条历史证据。

这种方法使持久化记忆变得有用，而不会将其视为无可置疑的真理来源。

为什么持久化记忆改变了 AI 智能体的角色

IncidentBrain 有趣的部分并非 LLM 能够分析 Redis 事件。

现代 LLM 已经能够解释技术问题并建议可能的解决方案。

更有趣的能力是经验积累。

当一个事件被解决时，经验可以存储在持久化记忆中。

之后，当类似事件再次发生时，可以检索并使用之前的经验作为上下文。

这就创建了一个持续学习循环：

事件 → 解决 → 记忆 → 回忆 → 更好的调查

1. 工程师调查一个生产事件。
2. 应用解决方案。
3. 记录观察到的结果。
4. 将经验存储在 Hindsight 中。
5. 之后发生类似事件。
6. IncidentBrain 检索之前的经验。
7. LLM 在推理新事件时使用该经验。

随着更多相关经验被存储，智能体可用的组织知识也越来越多。

这为 AI 系统开辟了一种可能性：它们不仅仅是回答问题，而是因为能够记住之前发生的事情而随着时间变得更有用。

IncidentBrain 目前展示了将 AI 推理与持久化运维记忆相结合的核心思想。

该架构可以通过将智能体连接到真实生产系统来进一步扩展。

可能的后续改进包括：

• 监控系统 — 自动收集当前指标和告警。
• 事件管理系统 — 将事件直接连接到智能体。
• 日志和链路追踪 — 使用应用日志和分布式链路追踪作为调查证据。
• Kubernetes — 允许智能体对工作负载、Pod、Deployment 和集群事件进行推理。
• 部署系统 — 将事件与最近的部署和配置更改相关联。
• 更丰富的事件摘要 — 自动生成结构化的事件报告。
• 相似性检测 — 识别与之前生产问题相似的的事件。
• 自动化验证 — 验证推荐的操作是否真正改善了系统。
• 团队知识 — 存储可在工程师和事件之间重用的运维知识。

长期目标是从一个独立的事件响应助手走向一个能够更深入地参与生产运维工作流的 AI 系统。

IncidentBrain 探索了一个简单的理念：

当 AI 事件响应系统能够记住之前的运维经验时，它会变得更加有用。

核心工作流是：

调查 → 解决 → 记忆 → 回忆 → 再次调查

IncidentBrain 没有将每个生产事件视为孤立的问题，而是创建了一个反馈循环，使之前的事件能够成为后续调查的有用证据。

Hindsight 提供持久化记忆层，而 LLM 提供对当前事件和检索到的历史上下文的推理能力。

目标不是取代 SRE 工程师。

目标是让之前的运维经验在下一个事件发生时更容易被检索和使用。

AI 推理与持久化运维记忆的结合，是 IncidentBrain 的基础。

Hindsight GitHub repository

Hindsight documentation

Vectorize — Agent Memory

IncidentBrain GitHub repository