自动化让 AI SRE 不用你开口就开始干活，而且不挑钟点：你设的 9 点，它 9 点零三分开始；凌晨三点来一条 Critical，它也照接。
一条自动化就是一条规则：一段任务提示词，加上至少一种启动方式。启动方式有三种：按周期执行，每小时、每天、每周，或者自己写一段 cron 表达式；通过 API 调用，拿到一个地址和一个 Token，从任何地方 POST 过来都行；On-call incident，选好要监听的协作空间和严重程度，匹配到的故障会拉起一次运行。一条规则可以同时挂三种，提示词不变，变的只是把它叫醒的那件事。
规则跑起来的时候会在后台开一个会话，这个会话不出现在你平时的会话列表里，但 Agent 用的还是它在普通会话里的那套工具。跑完之后你可以点进去看全过程：它跑了哪些命令、调了哪些工具、最后产出了什么。
下面介绍五种用法。前三个是产品自带的，提示词已经写好，可以原样用；后两个是例子，你复制过去改改就行。五种用法的结果去向，先看总览：
| 场景 | 结果去哪儿 |
|---|---|
| 1 · 每周洞察 | 留在运行会话里；让它发布，可长期留存为产物 |
| 2 · 告警治理 | 同上 |
| 3 · 故障自动分析 | 作为评论写回故障，借故障的通知到值班的人 |
| 4 · 发版后巡检 | 调用立即返回 session_url，贴到发版群或流水线 |
| 5 · 变更风险预检 | 调用立即返回 session_url，贴回变更单 |
1. 每周到底发生了什么
解决什么。 每周一总得有人花两个小时把上周捋一遍：出了哪些故障、来了多少告警、谁在扛、期间改了什么。每周捋的都是同一批东西。
怎么启动。 按周期执行，每周一次。挑周一上午的某个点，人到工位报告就在那儿了。
任务提示词（产品自带，模板名「每周洞察」）：
生成一份每周洞察报告。分析过去一周的事故、告警、响应情况、通知负载和相关变更。重点说明
本周发生了什么、哪些信号值得关注、哪些改进动作最有价值。不要修改任何 Flashduty 业务状态。最后那句不是客套。Agent 是真能改 Flashduty 里的东西的，所以一条只负责出报告的自动化，应该把这件事明说。
结果去哪儿。 留在这次运行的会话里，点进去看。想长期留存，在提示词里让它把报告发布成产物。
2. 常设的告警治理清单
解决什么。 每个团队都知道自己有一批告警没价值。但几乎没有团队手上有一份排好序的名单，写清楚哪几条最该治、治完能少收多少条通知。
怎么启动。 按周期执行。每月一次就够，这个数字不会天天变。
任务提示词（产品自带，模板名「告警治理」）：
/alert-governance
生成近 30 天该范围的告警治理报告。重点说明最值得治理的告警，以及预期的通知量降幅。
仅生成报告——不要修改任何 Flashduty 配置。第一行是一个技能。自动化可以像你在聊天里那样调用技能。方法论因此不用写进提示词。技能里已经有了，提示词只负责说清楚「对准哪一块」。
结果去哪儿。 同每周洞察：留在会话里，或让它发布成产物。
要知道的。 它只出报告，不动手改。把报告变成配置变更，仍然是人的决定，这是有意的。
3. 在有人打开故障之前，先做一轮
解决什么。 凌晨来一条 Critical，值班的人过了一阵才看到，接下来的十五分钟基本都花在翻东西上：翻关联告警、翻时间线、翻最近发了什么版。这第一轮翻找，不需要人来做。
怎么启动。 选「On-call incident」，挑要监听的协作空间，勾上你在意的严重程度。新故障一匹配上就开始跑，不用谁去点一下。
任务提示词（产品自带，模板名「故障自动分析」）：
请分析本次触发该自动化的故障。使用 Flashduty CLI 获取故障详情、关联告警和时间线，再结合
最近变更、告警上下文和已有处理记录判断可能原因。证据不足时，请说明不确定性和建议下一步
排查方向。
如果形成了有价值的调查结论，请给故障添加一条总结性 comment。尽量写一次完整的调查总结，
不要频繁分多次评论。结果去哪儿。 注意第二段：调查结论会作为一条评论写回故障本身。故障有了新评论，会跟着故障的分派策略通知到值班的人，所以接手的人是被正常通知到的，他甚至不需要知道背后有一条自动化跑过。
「证据不足时说明不确定性」这句是特意加的。一份把话说满的分析，比一份老老实实讲「证据还不够，接下来该查这两处」的分析更糟。
要知道的三件事。 只有新建的故障会拉起运行，认领、解决、重开都不会；筛选条件目前只有协作空间和严重程度两项，还不能按标签匹配；同一个故障只会拉起一次运行，内部消息重复投递也不会变成三份并行的调查。
4. 每次发版之后自动过一遍
前三个是产品自带的。后面两个不是。它们是例子，提示词得自己写。
解决什么。 发完版，盯十分钟看板，看看有没有把什么弄坏。大多数时候什么也没发生。
怎么启动。 通过 API 调用。加上这个触发方式、保存规则，系统会给你一个地址和一个 Token。Token 只显示一次，当场复制走，离开页面就无法再次查看。之后只能重置，重置会立刻让当前 Token 失效，并生成一个新的。
在流水线最后一步调它：
curl -X POST 'https://<触发地址>' \
-H 'Authorization: Bearer <token>' \
-H 'Content-Type: application/json' \
-d '{"text":"payment-service v2.14.0 已发布到生产。改动：结算回调的重试策略，t_order.created_at 新增索引。"}'text 里的内容会追加到规则的提示词后面，只对这一次运行生效。这是唯一一条能把外部信息送进提示词的通道。定时运行没有调用方给它传参，故障触发的运行则从故障本身拿上下文。
可以从这段提示词起步：
本消息末尾是一次刚完成的发版信息。针对其中提到的服务，对比发版后 30 分钟与发版前同长度
窗口的告警量、故障数和报错模式。只报告发生了变化的部分，并判断是否可能与本次发版有关。
如果没有变化，用一句话说明。不要修改任何 Flashduty 状态。结果去哪儿。 调用会立刻返回，不会等 Agent 跑完：
{
"data": {
"type": "routine_fire",
"session_id": "<session-id>",
"session_url": "https://<console>/ai-sre/chat?session_id=<session-id>"
}
}把这个 session_url 贴到发版的群消息里，或者挂在流水线记录上。谁想看细节，点进去就是完整的排查现场。
要知道的。 每条规则每分钟最多接受一次 API 调用。这个额度属于规则，所以同一条规则上挂两个 API 触发，是共用它的。它是为事件设计的，不是给轮询用的。
5. 变更落地之前先看一眼风险
解决什么。 变更审批常常是唯一一个有人会问「这类改动以前出过事吗」的时刻，而通常没人有空真去查。
怎么启动。 通过 API 调用，在变更单流转到「已批准」时由变更系统调用，把变更内容本身放进 text。
可以从这段提示词起步：
本消息末尾描述了一次待执行的变更。查找近 90 天内涉及相同服务、或同类改动的故障，逐条说明
当时坏在哪里、最后怎么解决的。然后列出这次变更落地前后具体值得盯的检查项。如果没有找到
相关历史，请直接说明，不要泛泛而谈。不要修改任何 Flashduty 状态。结果去哪儿。 和发版巡检一样：调用会当场返回一个 session_url，把这个链接贴回变更单。审批的人不用离开自己本来在用的系统，就能读到完整的调查过程。
如果你想接的那些系统本来就在往 Flashduty 送数据，可以先在集成列表里看看已经连了哪些。
跑完了，怎么通知到人
自动化自己不绑定通知渠道，但结果到人手里有两条路。
故障触发的运行，借故障的通知。 就像上面说的，结论写成故障评论，评论跟着故障的分派策略通知到值班的人。这条路你不用配任何东西，故障本来怎么通知人，评论就怎么到人手里。
其他运行，让 Agent 自己发。 定时和 API 触发的运行默认不打扰任何人，结果就留在会话里。想推到群里，在提示词里放一个 IM 机器人的 webhook 地址就行。飞书、钉钉、企业微信的自定义机器人都是一条 URL，Agent 跑完自己把摘要 POST 过去：
任务完成后，把结论压缩成 5 行以内的中文摘要，用 curl 以 JSON POST 到这个机器人地址：
https://oapi.dingtalk.com/robot/send?access_token=<你的 token>。
发送失败就在结果里说明，不要重试超过两次。我们自己就是这么用的。这条是每天一次的文档审计跑完之后，Agent 自己发到钉钉群里的消息：
审了什么、发现几条、改了几条、PR 在哪，一条消息说完，群里的人点链接去看细节。webhook 地址写在提示词里，意味着能看到这条规则的人也能看到它，不过这种机器人能做的只有往这一个群里发消息，权限本身就小。
为什么故障触发那个不一样
上面五个跑的是同一个 Agent、同一套工具。它们真正的区别不在「用什么方式叫醒它」，而在它睁眼那一刻手里有什么。
定时启动的运行，手里只有你写的提示词，外加一条信息：上次成功跑完是什么时候。这足够让它做增量的活，但要查什么、从哪儿下手，还得它自己摸。API 调用启动的运行，手里多了调用方写进 text 的那段话。故障触发的运行不一样，故障已经在它手里了：故障 ID、所属协作空间、严重程度，在它做第一个动作之前就在上下文里，同时还有一句明确的交代：不要去翻故障列表，试图搞清楚自己该看哪一个。
这一点听起来小，其实不小。列出来、筛一遍、确认哪个是目标，这是好几轮工具调用，而且每一轮都有挑错的机会。直接把目标递给它，这一步整个消失了。
这也正是定时够不着的地方。一条设在 9 点的规则，会在 9 点告诉你昨晚的那次故障。
几件我们替你定了的事
你设的 9 点，可能 9 点零三分才开始。 这是故意的。如果平台上所有定时任务都卡在 9:00:00 同时启动，谁都快不了。所以把它当「每天早上」用，别当秒表用。
上一次还没跑完，下一次就不启动。 到点时如果上一轮还在跑，这一次直接跳过，而不是排队等着。不然一个慢任务会把自己堆起来。
错过太久就作废，不补跑。 如果一次运行迟了超过一天，就丢掉。故障恢复之后一口气涌出四十份报告，对谁都没好处。
重启不会丢，也不会重复。 服务重启时正在跑的运行不会丢失，也不会被记成两次。
别的团队的故障，仍然按你这条规则的权限跑。 如果故障归属的团队和规则不是同一个，运行照常执行，但 Agent 一开始就被告知：这个故障属于别的团队，对方团队的知识这次没有加载。它不会悄悄越过边界去读，也不会一声不吭地跳过。
从哪儿开始
入口在控制台的 AI SRE → 自动化。自带模板就在创建页上，这篇讲的是其中三个。挑一个，把提示词改成你们团队实际的做法，设个时间。
如果只想迈最小的一步：把「故障自动分析」这个模板打开，只选一个协作空间、只勾 Critical。结论会写在你本来就要看的地方，而且它的价值兑现在凌晨三点，不是上午九点。我们写过一条这样的链路，从一个用户侧的报错一直到合并的修复。
Agent 用来操作 Flashduty 的那个命令行，以及我们为什么选了命令行，写在另一篇里。自动化的完整字段说明，包括 cron 的书写规则和各触发方式的请求格式，在文档里。AI SRE 目前全量公测，公测期间免费。
最后说一句关于那三个自带模板的话：它们是我们写给自己用的，里面藏着我们自己的习惯：周报周一读、告警治理一个月过一遍、故障来了第一件事是留一条评论而不是叫醒谁。你们的值班不是我们的值班。把这些提示词当成要改写的文字，别当成可以直接接受的配置。
