diff --git a/en/ai-sre/automations.mdx b/en/ai-sre/automations.mdx
index 26cacf4a..a046354c 100644
--- a/en/ai-sre/automations.mdx
+++ b/en/ai-sre/automations.mdx
@@ -40,7 +40,7 @@ The page header offers two creation entry points: an outline-style **Create via
     Choose **Start from scratch** to open a blank form and manually fill in the name, task prompt, and triggers. This suits cases where you already know what you want the agent to do and want a fully custom prompt.
   </Step>
   <Step title="From a preset template">
-    Below, a set of **preset template** cards is listed (delivered by the backend per UI language: `zh-CN` for Chinese, `en-US` for English). Common ones include **Alert Noise Analysis**, **Incident Response Review**, **Weekly On-call Insights**, and **Escalation and On-call Load Analysis**. Click any template card to prefill the form with the template's name and task prompt; tweak from there.
+    Below, a set of **preset template** cards is listed (delivered by the backend per UI language: `zh-CN` for Chinese, `en-US` for English). Common ones include **Weekly Insights**, **Alert Governance**, **On-call Incident Analysis**, and **On-call Load Analysis**. Click any template card to prefill the form with the template's name and task prompt; tweak from there.
   </Step>
 </Steps>
 
@@ -170,6 +170,8 @@ If you create or update a rule through the API, use these fields:
 
 When a matching event arrives, the system creates a run with `trigger_kind: "oncall_incident"` and passes event context such as `incident_id`, `channel_id`, and `severity` into the session. The same trigger and the same `incident_id` reuse the same run, avoiding duplicate hidden sessions for one incident.
 
+When the run finishes, AI SRE writes one summary comment back to the incident that triggered it: conclusion first, body kept concise, with a link to the full session at the end. The comment travels through the incident's existing notification chain (for example, incident card refreshes and thread replies in IM), so whoever is watching the incident sees the analysis without opening the console. This applies to every rule with the On-call incident trigger enabled — including rules with custom prompts — with no extra configuration.
+
 ## Run History
 
 ---
diff --git a/en/ai-sre/quickstart.mdx b/en/ai-sre/quickstart.mdx
index 285647e7..9f3b8c9f 100644
--- a/en/ai-sre/quickstart.mdx
+++ b/en/ai-sre/quickstart.mdx
@@ -1,7 +1,7 @@
 ---
 title: Complete Your First AI SRE Investigation in 15 Minutes
-description: Start with a real incident and get your first AI SRE investigation — grounded in context, backed by evidence, and open to follow-up questions — then build team knowledge and connect real data sources as needed.
-keywords: ["AI SRE", "Quickstart", "incident investigation", "/init", "knowledge base", "MCP", "BYOC Runner"]
+description: Start with a real incident and get your first AI SRE investigation — grounded in context, backed by evidence, and open to follow-up questions — then get every new incident analyzed automatically, build team knowledge, and deploy a BYOC Runner to reach real data sources.
+keywords: ["AI SRE", "Quickstart", "incident investigation", "automatic incident analysis", "/init", "knowledge base", "MCP", "BYOC Runner"]
 sidebarTitle: Quick Start
 ---
 
@@ -34,7 +34,7 @@ For actively investigating an issue, digging deeper, or building up knowledge. G
 
 ### Automations
 
-For work that shouldn't need a human watching it — scheduled inspections, weekly insight reports, alert-noise cleanup. Go to **AI SRE → Automations** and create one from a built-in template (Alert Noise Analysis, Incident Response Review, Weekly On-call Insights, and more) or build one from scratch. Each run happens in a hidden session in the background, and the result lands in the run history where you can open the full trail any time. → See [Automations](/en/ai-sre/automations)
+For work that shouldn't need a human watching it — scheduled inspections, weekly insight reports, alert-noise cleanup. Go to **AI SRE → Automations** and create one from a built-in template (On-call Incident Analysis, Alert Governance, Weekly Insights, and more) or build one from scratch. Each run happens in a hidden session in the background, and the result lands in the run history where you can open the full trail any time. → See [Automations](/en/ai-sre/automations)
 
 ### IM (@ Mentions + Automatic War Room Diagnosis)
 
@@ -84,7 +84,13 @@ If you don't have an incident on hand right now, skip ahead to "Growing It Into
 
 ---
 
-Your first investigation is just the starting point. How well AI SRE diagnoses depends on how much it knows about your systems and how much real data it can reach — both are things you build up over time, not all at once.
+Your first investigation is just the starting point. From here you can make analysis automatic, and keep sharpening its diagnoses — the latter depends on how much it knows about your systems and how much real data it can reach. All of this builds up over time, not all at once.
+
+### Get every new incident analyzed automatically
+
+Once manual investigations feel routine, make them the default: go to **AI SRE → Automations**, create a rule from the built-in **On-call Incident Analysis** template, enable the **On-call incident** trigger card, and pick the channels and severities to watch. From then on, every matching new incident gets an automatic investigation, and AI SRE writes one summary comment back to the incident — conclusion first, full session link at the end — delivered through the incident's existing notification channels, so responders see the first analysis right in IM. Configuration details: [Automations · On-call Incident Trigger](/en/ai-sre/automations#on-call-incident-trigger).
+
+This is independent of war room auto-diagnosis: this path fires for every matching new incident and writes back to the incident itself; war room diagnosis runs when you open a war room for an incident and posts into the war room group (see [IM](/en/ai-sre/im)).
 
 ### Build a team knowledge base
 
@@ -92,7 +98,26 @@ If the agent has to guess "what service is this," "who owns it," and "how was th
 
 ### Connect real data sources
 
-By default the agent only sees Flashduty's own data. To let it query your actual systems — logs, metrics, code repositories, internal databases — connect an MCP server or deploy a BYOC Runner. Publicly reachable services (observability platforms, GitHub, and similar) install and authorize in one click from the MCP directory; VPCs, internal databases, or local commands need a Runner deployed on a machine that can reach them. See [MCP](/en/ai-sre/mcp) and [Environments](/en/ai-sre/environments).
+By default the agent only sees Flashduty's own data. To let it query your actual systems — logs, metrics, code repositories, internal databases — connect an MCP server or deploy a BYOC Runner. Publicly reachable services (observability platforms, GitHub, and similar) install and authorize in one click from the MCP directory — see [MCP](/en/ai-sre/mcp); VPCs, internal databases, or local commands need a Runner deployed on a machine that can reach them — about three minutes, below.
+
+### Deploy a BYOC Runner (~3 minutes)
+
+<Steps>
+  <Step title="Create a self-hosted Environment">
+    Go to **AI SRE → Environments** and click **Create** on the **Self-hosted** tab. The name is optional (the first heartbeat fills it in with the machine's hostname); pick account or team scope.
+  </Step>
+  <Step title="Run the install command on the target machine">
+    After creation, the **setup guide** opens with install commands that already include your Token — a Linux one-liner (needs sudo; registers a systemd service), plus Docker and macOS variants. Copy it onto a machine that can reach your target resources and run it.
+  </Step>
+  <Step title="Wait for the status to flip to Online">
+    Back in the list, the status goes from **Pending** to **Online** once connected. Heartbeats are evaluated on a ~90-second cycle, so give it a moment after installing; if it stays Pending, the machine almost certainly can't reach the connect URL shown in the guide (outbound traffic blocked by a firewall).
+  </Step>
+  <Step title="Use it in a session">
+    When starting a new chat, the environment picker at the bottom of the composer defaults to **Auto** — it prefers an online Runner when one is available; you can also select this self-hosted Environment explicitly. Note that the environment locks once the session starts and cannot be changed afterwards.
+  </Step>
+</Steps>
+
+Permission rules (limiting what the agent may do on that machine), upgrades, and uninstallation: see [Environments](/en/ai-sre/environments).
 
 ## What's Next
 
diff --git a/zh/ai-sre/automations.mdx b/zh/ai-sre/automations.mdx
index 04238bf5..c5cb0b48 100644
--- a/zh/ai-sre/automations.mdx
+++ b/zh/ai-sre/automations.mdx
@@ -40,7 +40,7 @@ sidebarTitle: 自动化
     选择 **从零开始**，进入空白表单，手动填写名称、任务提示词与触发方式。适合你已经清楚要让 Agent 做什么、想完全自定义提示词的场景。
   </Step>
   <Step title="基于预设模板">
-    下方列出一组 **预设模板** 卡片（由后端按界面语言下发，中文环境取 `zh-CN`、英文环境取 `en-US`），常见的有 **告警噪音分析**、**事故响应复盘**、**每周值班洞察**、**升级和值班负载分析** 等。点击任一模板卡片，会用模板预置的名称与任务提示词预填表单，你在此基础上微调即可。
+    下方列出一组 **预设模板** 卡片（由后端按界面语言下发，中文环境取 `zh-CN`、英文环境取 `en-US`），常见的有 **每周洞察**、**告警治理**、**故障自动分析**、**On-call 负载分析** 等。点击任一模板卡片，会用模板预置的名称与任务提示词预填表单，你在此基础上微调即可。
   </Step>
 </Steps>
 
@@ -54,7 +54,7 @@ sidebarTitle: 自动化
 
 | 字段 | 必填 | 说明 |
 |---|---|---|
-| 名称 | 是 | 规则名称，最长 255 字符。占位示例：`每周值班洞察`。 |
+| 名称 | 是 | 规则名称，最长 255 字符。占位示例：`每周洞察`。 |
 | 范围 | 是 | 通过 **范围选择器** 选 **个人**（`team_id=0`）或某个 **团队**（`team_id>0`）。范围既决定这条规则的归属与编辑权限，也限定 **执行 Environment** 里可选的自托管 Runner——只有账户全局的 Runner，以及与该范围同团队的 Runner 才可选。 |
 | 执行 Environment | 否 | 通过 **环境选择器** 选运行环境：**自动**（由后端挑选最优可用环境，默认值）、**云端沙箱**，或某个 **自托管（BYOC）Runner**。选了某个团队范围后，不属于该范围的团队 Runner 会被自动清除。 |
 | 任务提示词 | 是 | 描述要让 AI SRE 执行的任务，用富文本编辑器撰写。这段提示词就是每次运行时发给 Agent 的内容。占位提示：`描述 Flashduty AI SRE 要执行的任务。` |
@@ -170,6 +170,8 @@ curl -X POST 'https://<触发地址>' \
 
 匹配事件到达后，系统会以 `oncall_incident` 作为 `trigger_kind` 创建运行，并把 `incident_id`、`channel_id`、`severity` 等事件上下文传给会话。相同触发器与相同 `incident_id` 会复用同一次运行，避免同一故障重复拉起多个隐藏会话。
 
+运行结束时，AI SRE 会把一条总结评论写回触发它的故障：结论写在最前面、正文简明，末尾附本次运行的完整会话链接。评论沿故障现有的通知链路送达（例如 IM 里故障卡片的刷新与回帖），关注这条故障的人不用打开控制台就能看到分析结果。该行为对所有启用 On-call 故障触发的规则自动生效——包括自定义提示词的规则，无需额外配置。
+
 ## 运行历史
 
 ---
diff --git a/zh/ai-sre/quickstart.mdx b/zh/ai-sre/quickstart.mdx
index 1516dc04..4a39f127 100644
--- a/zh/ai-sre/quickstart.mdx
+++ b/zh/ai-sre/quickstart.mdx
@@ -1,7 +1,7 @@
 ---
 title: 15 分钟完成第一次 AI SRE 排障
-description: 从一个真实故障开始，完成第一次有上下文、有证据、可继续追问的 AI SRE 调查；随后按需建立团队知识并连接真实数据源。
-keywords: ["AI SRE", "快速开始", "Quickstart", "故障调查", "/init", "知识库", "MCP", "BYOC Runner"]
+description: 从一个真实故障开始，完成第一次有上下文、有证据、可继续追问的 AI SRE 调查；随后按需让新故障自动获得第一轮分析、建立团队知识、部署 BYOC Runner 接入真实数据源。
+keywords: ["AI SRE", "快速开始", "Quickstart", "故障调查", "故障自动分析", "/init", "知识库", "MCP", "BYOC Runner"]
 sidebarTitle: 快速开始
 ---
 
@@ -34,7 +34,7 @@ AI SRE 没有唯一入口，从你现在所在的场景开始就好：
 
 ### 自动化（Automations）
 
-适合不需要人守着的周期性 / 触发式任务——定时巡检、周报洞察、告警治理。进入 **AI SRE → 自动化**，可从内置模板一键创建（如告警噪音分析、事故响应复盘、每周值班洞察），也可以从零开始自定义任务提示词。它在后台跑一个隐藏会话，结果记录进运行历史，随时可以打开查看完整的调查过程。→ 详见[自动化](/zh/ai-sre/automations)
+适合不需要人守着的周期性 / 触发式任务——定时巡检、周报洞察、告警治理。进入 **AI SRE → 自动化**，可从内置模板一键创建（如故障自动分析、告警治理、每周洞察），也可以从零开始自定义任务提示词。它在后台跑一个隐藏会话，结果记录进运行历史，随时可以打开查看完整的调查过程。→ 详见[自动化](/zh/ai-sre/automations)
 
 ### IM（@ 召唤 + 作战室自动诊断）
 
@@ -84,7 +84,13 @@ AI SRE 没有唯一入口，从你现在所在的场景开始就好：
 
 ---
 
-跑完第一次排障只是起点。AI SRE 排查得准不准，取决于它对你系统的了解程度、以及能连到多少真实数据——这两件事都可以按需慢慢建设，不必一次做完。
+跑完第一次排障只是起点。接下来可以把分析变成自动动作，并持续提升它排查的准头——后者取决于它对你系统的了解程度、以及能连到多少真实数据。这些都可以按需慢慢建设，不必一次做完。
+
+### 让每条新故障自动得到第一轮分析
+
+手动排查顺了之后，把它变成默认动作：进入 **AI SRE → 自动化**，从内置模板 **故障自动分析** 创建规则，在「触发方式」里启用 **On-call incident** 卡片，选好要监听的协作空间和严重程度。之后每条匹配的新故障创建时，AI SRE 都会自动跑一轮排查，并把一条总结评论写回这条故障——结论在最前面，末尾附完整会话链接；评论沿故障现有的通知链路推送，响应人在 IM 里就能看到第一手分析。配置细节见[自动化 · On-call 故障触发](/zh/ai-sre/automations#on-call-故障触发)。
+
+它与作战室自动诊断是两条独立链路：这条对每一条匹配的新故障生效，结果写回故障评论；作战室自动诊断在你为故障开启 IM 作战室时运行，结果回贴到作战室群里（见 [IM 平台](/zh/ai-sre/im)）。
 
 ### 建一份团队知识库
 
@@ -92,7 +98,26 @@ Agent 每次排障都从零猜「这是什么服务」「谁负责」「以前
 
 ### 接入真实数据源
 
-默认情况下 Agent 只能看到 Flashduty 自身的数据。要让它查到你系统里的真实信息——日志、指标、代码仓库、内网数据库，需要接入 MCP 服务器或部署 BYOC Runner。公网可达的服务（如可观测平台、GitHub）从 MCP 市场一键安装并授权即可；VPC、内网数据库或本地命令，则需要在能访问目标资源的机器上部署 Runner。见 [MCP（外部工具）](/zh/ai-sre/mcp) 与[运行环境](/zh/ai-sre/environments)。
+默认情况下 Agent 只能看到 Flashduty 自身的数据。要让它查到你系统里的真实信息——日志、指标、代码仓库、内网数据库，需要接入 MCP 服务器或部署 BYOC Runner。公网可达的服务（如可观测平台、GitHub）从 MCP 市场一键安装并授权即可，见 [MCP（外部工具）](/zh/ai-sre/mcp)；VPC、内网数据库或本地命令，则需要在能访问目标资源的机器上部署 Runner——往下看，大约 3 分钟。
+
+### 部署一个 BYOC Runner（约 3 分钟）
+
+<Steps>
+  <Step title="创建自托管 Environment">
+    进入 **AI SRE → Environments**，在 **自托管** 标签页点击 **创建**。名称可以留空（Runner 首次连接后会自动用主机名命名），范围选账户或团队。
+  </Step>
+  <Step title="在目标机器上执行安装命令">
+    创建成功后弹出**接入指引**，里面是已带 Token 的安装命令——Linux 一条命令装完（需要 sudo，会注册为 systemd 服务），也提供 Docker 和 macOS 方式。复制到能访问目标资源的机器上执行。
+  </Step>
+  <Step title="等状态变为「在线」">
+    装完回到列表，状态从**等待中**变为**在线**即接入成功。心跳判定约 90 秒一轮，刚装完稍等再刷新；长时间停在「等待中」，几乎都是这台机器出网访问不到指引里的接入地址（被防火墙拦住）。
+  </Step>
+  <Step title="在会话里用上它">
+    新建对话时，输入框底部的环境选择器默认**自动**——有在线 Runner 时会优先用它；也可以手动选中这条自托管 Environment。注意环境对一条会话一次性锁定，会话开始后不能更换。
+  </Step>
+</Steps>
+
+权限规则（限制 Agent 在这台机器上能做什么）、升级与卸载见[运行环境](/zh/ai-sre/environments)。
 
 ## 下一步