接入这些工具，让 AI Agent自动做故障调查、根因分析和证据化报告
- 公众号：GitHubStore
- 发布时间：2026-07-29T08:05:46+08:00
- 微信链接：https://mp.weixin.qq.com/s/0uj-vNBWPVQqoNNz2aZvZA
- RSS ID：3916483328-2247495905_1
- Feed ID：MP_WXS_3916483328
- Glance 当前首页可见：是
项目简介
当生产环境出现故障时，证据分散在日志、指标、追踪、运维手册（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)
关键技术分析
- 严格分层的架构设计
代码被拆成四个依赖层级，CI 强制检查导入方向（make check-imports），只能向下依赖：
层级
包
职责
顶层
surfaces、gateway
人机入口（CLI、交互式 REPL）和消息网关（Slack/Telegram 等）
中上层
tools、integrations
智能体可调用的工具 + 各厂商客户端与凭证
中下层
core、platform
Agent 运行时、状态、工具框架、掩码、沙箱、可观测性（两者可互相引用）
底层
config纯配置与常量
其核心设计理念是让 integrations 保持可复用（不依赖 tools），表面层只负责 I/O，核心逻辑和外部系统边界清晰分离。这是工程上比一堆脚本 + LangChain更成熟的地方。
- 自研 ReAct 调查流水线
分为 6 阶段流水线，每阶段是纯函数，状态统一用 AgentState 管理：
resolve_integrations — 确定当前组织可用的集成与工具集
extract_alert — LLM 对原始告警做结构化提取，同时过滤噪声（聊天、问候等直接停）
plan_actions — 根据告警来源和工具元数据打分，选出预算内的候选工具（默认 top 10）
gather_evidence（ReAct 循环） — 最核心的证据收集
diagnose — 把最终文本输出解析成结构化根因、因果链、验证/未验证声明、修复建议
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/tap brew 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 setup opensre agents scan opensre update opensre 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 会自动：
获取 告警上下文以及相关的日志、指标、追踪和最近的部署
掩码 敏感标识符（可选），在调用外部 LLM 之前处理
推理 在你连接的系统中测试假设，进入工具调用循环
生成 结构化的调查报告，包含可能的根因和关联证据
建议 下一步操作，并可选择执行修复动作
发布 摘要直接到 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
预览时标签不可点