接入这些工具，让 AI Agent自动做故障调查、根因分析和证据化报告

项目简介

当生产环境出现故障时，证据分散在日志、指标、追踪、运维手册（runbook）和 Slack 线程中。

分布式故障比本地代码任务更慢、更嘈杂，也更难模拟和评估，这就是为什么 AI SRE（以及更广泛的生产调试 AI）至今仍未解决。

OpenSRE 是一个开源的 AI SRE 智能体框架，用于解决生产事故，并可在你自己的基础设施上运行。

• 构建易于部署、可自定义的 AI SRE 智能体，用于生产事故调查与响应
• 运行评分的合成 RCA（根因分析）套件，检查根因准确性、所需证据和对抗性误导信息 (tests/synthetic)
• 在包括 Kubernetes、EC2、CloudWatch、Lambda、ECS Fargate 和 Flink 的云端场景中运行真实世界端到端测试 (tests/e2e)
• 保持语义化的测试目录命名，使端到端 vs 合成、本地 vs 云端的边界保持清晰 (tests/README.md)

关键技术分析

1. 严格分层的架构设计

代码被拆成四个依赖层级，CI 强制检查导入方向（  make check-imports  ），只能向下依赖：

层级	包	职责
顶层	surfaces 、  gateway	人机入口（CLI、交互式 REPL）和消息网关（Slack/Telegram 等）
中上层	tools 、  integrations	智能体可调用的工具 + 各厂商客户端与凭证
中下层	core 、  platform	Agent 运行时、状态、工具框架、掩码、沙箱、可观测性（两者可互相引用）
底层	config	纯配置与常量

其核心设计理念是让 integrations 保持可复用 （不依赖 tools），表面层只负责 I/O，核心逻辑和外部系统边界清晰分离。这是工程上比一堆脚本 + LangChain更成熟的地方。

2. 自研 ReAct 调查流水线

分为 6 阶段流水线 ，每阶段是纯函数，状态统一用  AgentState  管理：

1. resolve_integrations — 确定当前组织可用的集成与工具集
2. extract_alert — LLM 对原始告警做结构化提取，同时过滤噪声（聊天、问候等直接停）
3. plan_actions — 根据告警来源和工具元数据打分，选出预算内的候选工具（默认 top 10）
4. gather_evidence（ReAct 循环） — 最核心的证据收集
5. diagnose — 把最终文本输出解析成结构化根因、因果链、验证/未验证声明、修复建议
6. deliver — 输出到 Slack / 文件 / 其他渠道

ReAct 循环 的关键控制点：

• 工具 schema 上限 32 个（避免上下文爆炸）
• 最大循环 20 次
• 停滞检测：连续 2 轮没有新证据就强制收尾
• 工具调用缓存：相同 name + args 直接复用，防止重复查询
• 上下文预算管理：每轮调用前根据模型窗口动态驱逐低价值证据
• 部分“显而易见”的工具可做 seed 调用（先跑一轮再让 LLM 思考）

安装

macOS / Linux：

curl -fsSL https://install.opensre.com | bash

macOS/Linux 安装程序不需要 sudo。如果 PATH 中没有可写的 bin 目录，它会安装到  ~/.local/bin  ，并打印应用 PATH 更新的 shell 命令。

或者直接采用显式 main 通道：

curl -fsSL https://install.opensre.com | bash -s -- --main

Homebrew：

brew tap tracer-cloud/tapbrew install tracer-cloud/tap/opensre

Windows (PowerShell)：

irm https://install.opensre.com | iex

---

快速开始

opensre onboard

交互式 shell — 无子命令时，  opensre  会启动 REPL（需要 TTY）。用自然语言描述事故、流式查看调查过程，并使用斜杠命令控制会话（  /help  、  /status  、  /cost  、  /sessions  、  /resume  、  /compact  、  /new  、  /exit  ）、集成（  /integrations list  、  /integrations verify  ）、本地智能体舰队监控（  /agents  ）以及推理深度（  /effort  ，适用于 OpenAI 和 Codex — 从  low  到  max  ）。Ctrl+C 可取消正在进行的调查而不会丢失会话状态。完整参考见 交互式 shell 命令 。

opensre

一次性调查 — 针对告警文件运行一次智能体：

opensre investigate -i tests/e2e/kubernetes/fixtures/datadog_k8s_alert.json

远程运行时调查 — 按名称调查已部署的服务（实时健康状态、日志和部署状态）：

opensre investigate --service api-backend

Hermes 日志监控 — 跟踪 Hermes 的  errors.log  ，分类事故，并可选择通过 Telegram 告警：

opensre hermes watch

其他有用命令：

opensre integrations setupopensre agents scanopensre updateopensre uninstall   # 移除 opensre 及所有本地数据

---

部署

两种主要的 AWS EC2 路径以及通用托管选项：

• EC2 (Docker/ECR)：  make build-image  然后  make deploy  — 在一个实例上运行  opensre-web  和  opensre-gateway  容器。
• Gateway (AMI + systemd)：  make bake-gateway  然后  make deploy-gateway  — 仅 Telegram 网关，无 Docker，烘焙到自定义 AMI 中。
• 托管 (Railway / ECS / Vercel)： 使用仓库中的  Dockerfile  部署；设置  LLM_PROVIDER  和对应的 API 密钥（见  .env.example  ），如需持久化还需设置  DATABASE_URI  和  REDIS_URI  。

---

OpenSRE 工作原理

当告警触发时，OpenSRE 会自动：

1. 获取 告警上下文以及相关的日志、指标、追踪和最近的部署
2. 掩码 敏感标识符（可选），在调用外部 LLM 之前处理
3. 推理 在你连接的系统中测试假设，进入工具调用循环
4. 生成 结构化的调查报告，包含可能的根因和关联证据
5. 建议 下一步操作，并可选择执行修复动作
6. 发布 摘要直接到 Slack、PagerDuty 或 Telegram — 无需切换上下文

能力与集成

🔍 结构化事故调查	跨日志、指标、追踪、部署和配置的关联根因分析
📋 运维手册感知推理	OpenSRE 会读取你的运维手册并自动应用
🔗 有证据支撑的根因	每个结论都链接到背后的数据
🛡️ 可逆标识符掩码	在调用外部 LLM 前对 pod、集群和账户 ID 进行脱敏；输出时还原
📊 会话成本与历史	每会话 token 跟踪（  /cost  ）和可恢复的 REPL 会话（  /sessions  ）
👥 本地智能体舰队	监控你机器上的 Claude Code、Cursor、Codex 等编码智能体
🌐 远程运行时 RCA	按名称调查已部署服务，包含实时健康探测和最近日志
📡 Hermes 日志监控	跟踪 Hermes 错误日志，分类事故，并发送 Telegram 告警
🤖 完整 LLM 灵活性	自带模型 — Anthropic、OpenAI、Codex、Ollama、Gemini、OpenRouter、NVIDIA NIM、Bedrock

OpenSRE 连接 60+ 工具，覆盖 LLM、可观测性、云基础设施、数据平台、事故管理和 MCP。完整矩阵（含路线图链接）见 产品文档 ；仓库内也会随着项目发展维护详细目录。

项目地址

https://github.com/Tracer-Cloud/opensre