蹲了一个偏冷门的 OpenSRE：让 LLM 别再"建议"，直接吐工单
上一期：[给 SRE agent 加"长记忆"：我自己写一套，对比 Headroom 的 SharedContext 和 Learn]
这一期主角：[Tracer-Cloud/opensre]，3.3k stars，Apache 2.0
一句话：把"调查事故"这件事从一段 LLM 自由文本，硬掰成一份带证据链、带下一步动作的结构化工单。
一、为啥会盯上这个项目
我那个 SRE agent 走到第三步——crusher-lite 压输出、incident-kb 存案例都搞定了，但还有一个根本性的问题没解决：
LLM 给出的判断永远是一段散文。
像这样："根据日志显示，pod 在 14:23 出现 OOMKilled，建议重启服务并关注后续内存使用"。
这种话乍一看挺像样，落到 SRE 流程里就废一半——它不是工单，是读后感。我们排班那边的同事拿到这玩意儿也得自己再翻一遍：哪个 pod？OOMKilled 是 137 还是 9？建议重启的依据是啥？要不要降级流量？回滚到哪个版本？
每次都要把"读后感"再翻译成"工单"，这一步本身就把前面省下的时间又花回去了。
直到上周我在 GitHub Trending 边缘看到了 Tracer-Cloud/opensre——3.3k stars，不算热门，但 README 第一段就写了一行让我坐直身子的话：
"AI SRE Agent that investigates production incidents and emits a structured incident report with linked evidence."
Structured + Linked Evidence——这两个词正好戳中我前面说的痛。我把它当成"我自己第四步"的预研，蹲了它两天。
声明一下：所有命令、字段结构、对比数字都是我对着源码、官方站和实测博客复盘整理的，没在本机真跑。LangGraph 那一坨依赖加 Postgres + Redis，沙箱搭起来不是两小时的事。
二、它干的事，跟我以为的不一样
我一开始以为 OpenSRE 是个"PagerDuty 替代品"。蹲完才发现完全不是。
它不抢 PagerDuty / incident.io 的活——排班、通告、事件流程那一套它不碰。它专门干那两个平台不擅长的：告警来了之后，谁去把现场捋清楚。
注意右下角那个"可选执行"——这就是我说的"工单"那层意思。它不止给你一段文字，它给的是一个机器能直接消费的对象。
三、技术栈：选得很"不潮"，但很务实
我列一下它的核心栈：
| 层 | 技术 |
|---|---|
| 语言 | Python 3.13 |
| Agent 编排 | LangGraph（不是裸 LangChain，是带状态图的那个） |
| 数据库 | PostgreSQL |
| 缓存 / 队列 | Redis |
| 部署 | Railway / Docker |
| 协议 | MCP、OpenClaw |
我看到 LangGraph 的瞬间就理解了作者的取舍——SRE 调查是天然的多步过程：先抓告警、再拉指标、不够再拉日志、还不够再拉 trace、最后做关联。每一步的输入是上一步的产出，每一步都可能失败重试或者补抓。这种东西用裸 LangChain 写一坨链式调用会很难看，用 LangGraph 把它建成有状态的图就刚刚好。
不潮的地方是 Postgres + Redis 这种"老干部组合"。但 SRE 系统就该用这种东西——可观测、可备份、出问题运维知道怎么修。换 vector DB 那一票新东西在生产里要给你添堵。
四、它输出的"工单"长啥样
这是这个项目最值得抄的部分。一份 RCA report 的结构化字段：
| 字段 | 内容 |
|---|---|
| 告警上下文 | 触发告警的元信息 + 关联资源 |
| 关联信号 | 日志 / 指标 / trace / runbook 摘录 |
| 最可能根因 | 跨系统推理出来的 root cause |
| 证据链 | 每条结论都链回原始可观测性数据 |
| 建议行动 | next-step，可选触发执行 |
| 摘要 | 推 Slack / PagerDuty 用的简版 |
整份对象都是 JSON，可以直接喂给下游系统。
我专门停下来想了一下"证据链"这个字段的含金量——它强制每条结论挂一个回链。这一招把 LLM 最容易翻车的"看似有理但没出处"问题直接堵死了。没证据就别下结论，这条纪律在 SRE 场景里跟空气一样必要。
五、上手这事看起来不难，但有几道坎
文档给的快速启动是这几条：
git clone https://github.com/Tracer-Cloud/opensre
cd opensre
make install
opensre onboard # 配置 LLM provider 和各类集成
opensre investigate -i tests/e2e/kubernetes/fixtures/datadog_k8s_alert.json
opensre investigate -i alert.json 这条是核心——输入一份告警 JSON，输出一份结构化工单。从 fixture 跑通到接生产告警，中间隔着这几道：
- Postgres + Redis 得自己起。本地 Docker compose 能解决，生产要规划。
- LLM provider 鉴权。它支持 Anthropic / OpenAI / Ollama / Gemini / OpenRouter / NVIDIA NIM / AWS Bedrock，挑一个配 key。
- 集成那 60+ 个工具不是装上就能用，要按需开。我们公司用 Grafana + Sentry + Slack + Jira，这四个就够，不要贪。
- 官方那个一键 install 脚本（
curl ... | bash）我个人不推荐——SRE 平台从公网拉脚本直接执行，安全风评太低。git clone+make install是更老实的路。
我那个场景估算下来，真要接到生产，工作量大概一周——其中半天搭依赖，半天对接两个集成，剩下时间全花在调"它给的建议要不要给执行权"那道审批流。
六、跟 OpenSRE 比，我自己那套差在哪 / 强在哪
这才是我蹲它的真正目的。
| 维度 | 我的 SRE agent + crusher-lite + incident-kb | OpenSRE |
|---|---|---|
| 输出形态 | 自由文本 + 引用 incident-kb 命中卡片 | 结构化 JSON 工单 + 证据链 |
| 集成数 | 我们自家四件套（Grafana/Sentry/Slack/Jira） | 开箱 60+ |
| 多步编排 | 自己拼的状态机，糙 | LangGraph，规整 |
| 长记忆 | incident-kb 案例 + Headroom Learn 规则 | episodic memory + Neo4j 知识图（社区版） |
| 自动执行 | 完全没做 | 有 next-action 字段，可选触发 |
| 框架成熟度 | 业务定制，迁移性差 | 通用框架，迁移性好 |
| 上手成本 | 现成 | 一周左右 |
我的诚实判断：
- 它的"结构化输出 + 证据链"我必抄——下个版本 SRE agent 直接复刻这套字段表，告别散文式回复。
- LangGraph 编排我也得抄——我那拼出来的状态机维护起来已经开始难受。
- 它那 60+ 集成跟我没关系。我们公司四件套就够，多余的是噪声。
- 它的 episodic memory 我跟 incident-kb 是同一思路，没必要切。
- 自动执行那块我会保守：先把 next-action 字段做出来，但不接执行。多接一道人工 review，跟我 incident-kb 同样的纪律。
换句话说，OpenSRE 给了我一份"成熟项目长啥样"的参照系。我不会整体替换我的 agent，但我会把它的协议抄过来。
七、值不值得用？分两种人
直接用整套 OpenSRE 的：
- 中小团队、SRE 工具链没历史包袱、对接的就是它支持的那些主流工具——直接装。一周回本。
- 不要想着"先 PoC 一下"，PoC 跑 fixture 是一回事，接生产又是另一回事。要试就直奔生产灰度。
只抄它思路的（像我）：
- 老团队、SRE 工具链是自家攒的、流程是公司特有的——别整体替换，只抄结构化输出协议 + LangGraph 编排。
- 千万别为了"用上 OpenSRE"去重写自己跑得好好的接入层。这是新框架最容易让人犯的错。
八、总结：从"AI 副驾"到"AI 工单生成器"
蹲完 OpenSRE，我对 AI SRE 这条赛道的判断又清楚了一档。
去年大家做的还是"AI 副驾"——给我一段建议，我自己处理。今年明显在往"AI 工单生成器"走——给我一份可机器消费的对象，下游系统自己消化。这是个挺关键的语义转变：
- 副驾要解决"看不懂日志"的问题
- 工单生成器要解决"上下游接不上"的问题
第二个问题才是 SRE 团队真正的痛。日志看得懂的人多得是，工单写得规范、能直接喂给 PagerDuty / Jira / 自动化脚本的，少得多。
OpenSRE 不是技术上最炫的项目——LangGraph 是别人的、数据库是 Postgres、模型是各家厂商的——它的价值在于把"agent 输出"这件事做成了协议。这个比技术本身重要得多，也是我接下来要在自己 agent 里复刻的方向。
