各类大模型厂商都有自己的通用 AI Agent，比如 Codex、Claude Code、Cursor、Kimi 等等。这些通用 AI Agent 可以写代码、写文章、做设计、排查问题，已经非常强大，为啥还需要 SRE Agent？
SRE 名词解释：是 Site Reliability Engineering 的缩写，中文通常翻译为“站点可靠性工程”。代码上线之后的稳定性工作都是 SRE 的范畴。
这是一个很尖锐的问题。
我们在 Flashduty 里做了 AI SRE（一款 SRE Agent），如果事实上根本不需要一款 SRE Agent，那这个商业逻辑就坍塌了。不只是我们的商业逻辑坍塌了，各位读者的公司是否也上马了自己的 SRE Agent？通常是运维团队提供的，抱歉，一并坍塌。
通用 AI Agent 能否解决 SRE 问题
坦白讲，很多问题都可以解决了。尤其是问题已经定位到某个具体模块之后，研发人员让 Cursor、Claude Code 读取本地代码和生产日志、指标，常见问题都可以解决。
如果问题没有解决，需要反思的是：
- 模型智力不够，需要换更好的模型
- 给的信息不够，需要更精确的上下文
事实上，如果你仔细观察会发现，团队里不同的人使用相同的 AI 模型，其效果差别很大。可能有些人没法把问题描述清楚，有些数据忘了给模型，可能本地的 Skill 写得不好，Knowledge 不完整等等。导致有了 Agent 也没用好。
这里其实暴露了一个关键问题，是：知识共享。当然，“共享”和“协作”不分家，Codex、Cursor 这类个人助理式的 AI Agent 天然也会缺少一些团队协作的能力。通常是人和人之间做信息传递，人再把信息传递给自己的 Codex，这个链路容易缺失信息，而且依赖人的效率。
说到知识共享和协作，不得不提到 Claude Tag 产品。
Claude Tag 介绍
Anthropic 除了 Claude Code 之外，还有一个产品很多人可能没有关注，叫 Claude Tag。下面是 Claude Tag 介绍，介绍信息由 Claude Code 总结整理而成 :)
Claude Tag 是 Anthropic 在 2026-06-23 推出的 Slack 产品，替代了原来的 Claude in Slack 应用。它的定位就是常驻在 Slack 里的 AI teammate，和你理解的一样。
主要特点：
- 常驻、有记忆：它会长期保留上下文和记忆。拿到读取其他频道的权限后，还能用上组织里其他地方的信息。
- 能自己干活：接到任务后会拆成几个阶段，调用它能访问的工具去做，做完把结果发回 Slack 线程。
- Ambient 模式：可以主动加入对话，同步进展，提醒其他地方值得注意的事，跟进被遗忘的线程或任务。
- 全公司共用一个 Claude 身份：同事之间可以互相交接做到一半的任务。频道里产生的用量记在组织账上，不算到个人头上。
- 隐私：官方说不会把私有频道的内容透露出去。
- Anthropic 称它是 Claude Code 演进的开端，以后会扩展到其他平台，但还没给出时间表。
Claude Tag 启发
既然 Anthropic 把 Claude Code 和 Claude Tag 区分对待为两个产品，说明 Anthropic 也认为 Claude Tag 有其独特的产品定位和价值。
而 SRE Agent，我感觉基本等同于：Claude Tag + Incident Responder。
- Claude Tag：侧重在知识共享、协作、尤其是 IM 协作
- Incident Responder：侧重在故障响应，要集成各类数据读取能力、故障分析能力、复盘能力，高阶用户还会涉及 Status Page 能力
SRE Agent 特点
SRE Agent 有下面这些典型的职能和特点。看完之后，你可能会有一些体感。
7x24 运行
本地的 Codex、Cursor 可能会因为电脑关机临时不能运行，但是 SRE Agent 是 7x24 运行的。
自动接入 Incident，做第一轮诊断
当凌晨 3 点被故障吵醒的时候，我们希望起床就可以看到 AI 的初步分析结论，而非把各种上下文信息塞给 AI 等它半天。
但是告警分散在不同的平台，比如 Prometheus、Zabbix、各类云监控、各类商业软件自带的监控，让 SRE Agent 挨个对接各个平台？坦白讲有点费劲。
而且偶尔还会有告警风暴，如果每个告警都去分析一遍，也不合适，需要先把告警做降噪处理，通常相关的告警要收敛为一条 incident，然后对有限的 incident 做 AI RCA。
巧了，把分散在各个监控系统里的告警收拢到一个地方，并做告警降噪收敛，恰恰就是 Flashduty、PagerDuty 这类 On-call 产品的职能。所以我们在 Flashduty 里做了 SRE Agent，就非常丝滑。
对接各类数据
通用的 AI Agent 当然也可以对接各类数据，因为很多数据源都提供了 MCP。但是也有很多数据源没有提供 MCP，即便提供了 MCP 有时也不好用。SRE Agent 就需要把数据源对接做到开箱即用。
举几个例子：
- 我们提供 自托管 Runner 可以打通内网，让 SaaS 里的 AI 可以读取某个网络分区里的特定的数据源的数据
- 我们还提供 monitedge 组件，对接各类可观测性数据源，提供内置的结构化的 Tool，这些 Tool 会处理安全防护、数据分析处理。比如指标数据全部喂给 AI 会撑爆其上下文，monitedge 就会提供指标趋势分析的工具，把分析结果给 AI，比如日志原文量很大，monitedge 会提供 log pattern 的 tool，把 log pattern 分析结果给 AI
- 对于 GitHub、GitLab 等代码仓库，我们提供对应的 GitHub App，可以做统一的授权访问。即便 AI Agent 没有读取你本地电脑上的代码目录也可以通过 GitHub App 读取到代码，加速故障定位
- 对于 Kubernetes，我们提供了 Kubernetes 专属 App，方便打通网络和缩紧授权，方便 AI 读取 K8s 的数据
- 对于阿里云这种巨型 MCP 我们不会把 MCP 里的所有 tool 信息都给 AI，而是在外层包装 Search 工具，避免把大模型上下文撑爆
- 等等等等
SRE Agent 从 Demo 走到生产级，实际是有很长的路要走。
帮助 Incident 协作和响应
SRE Agent 需要进驻 IM，需要提供飞书、企微、钉钉、Slack、Teams 等各类专属 App，因为普通的 IM Bot 做不到协同类的操作。需要支持在 Incident 到来时创建作战室（一个专属的 IM 群），把 Incident timeline 的信息同步到作战室，方便大家协作。
故障处理完成之后，SRE Agent 需要读取作战室的对话记录，以及 Incident 生命周期排查记录，建立 Postmortem 草稿，大幅释放人力。
如果公司有对外的 Status Page，比如 DeepSeek 就有 status.deepseek.com。有严重故障的时候需要对外部公众透明沟通，就要通过 Status Page 来更新故障处理状态。这也是 SRE Agent 的活。
结语
这么看来，SRE Agent 和个人助理式的通用 AI Agent 相比，还是有不少差别的，当然了，我们做 Flashduty AI SRE，自然有立场问题，请各位读者明辨是非。如果对 Flashduty On-call 和 SRE Agent 感兴趣，欢迎了解和试用：Flashduty
