CS146S 第九周笔记总结：Agents Post-Deployment
Stanford University · Fall 2025 · 讲师：Mihail Eric 课程网站：themodernsoftware.dev
📅 课程安排
| 日期 | 主题 | 内容 |
|---|---|---|
| Mon 11/17 | AI DevOps — Incident Response | SRE 基础→四大黄金信号→事故响应 Playbook→AI SRE 特征→局限性（19 slides） |
| Fri 11/21 | 🎤 Guest: Mayank Agarwal & Milind Ganjoo (Resolve AI) | AI Agents for Production Systems |
嘉宾背景：
- Mayank Agarwal： Resolve AI CTO，OpenTelemetry 共同创建者，DeepMind Staff MLE
- Milind Ganjoo： Resolve AI Member of Technical Staff
第一讲：AI DevOps — Incident Response（Mon 11/17，19 slides）
开场定位（Slides 3-4）
Slide 3: "AI DevOps"
为什么这个话题重要（Slide 4 "Why"）：
- 编码仅占工程时间的 30%
- 更难的 70% 是在生产环境中运行代码——复杂性、工具孤岛、知识差距、相互依赖在这里碰撞
- 管理生产通常需要由 SRE 进行繁琐的软件分诊
📚 课程关联： "编码只占 30%"直接呼应 Resolve AI 博客的核心论点——"Software engineering has embraced code generation, but the real bottleneck is production." W1-W8 关注如何用 AI 写代码，W9 关注代码写完之后怎么办。
第一部分：The Old World — 传统 SRE（Slide 6）
SRE 的传统职责：
- 运营监控（on-call、故障排查、基础设施管理和安全）
- 事故解决需要从多个不同来源和团队拼凑信息
- 维护经常过时的 Runbook
- 向云原生架构（容器化 + Kubernetes）迁移引入了更多数据、依赖和跨系统复杂性
- SRE 经常因 on-call 轮班而倦怠
关键数据： 停机和服务降级每年给 Global 2000 造成约 $400 billion 损失。
📚 课程关联： Resolve AI 创始人 Spiros 的亲身经历——"当我领导 Splunk 的 Observability 业务时，90% 的 SRE 团队在六个月内因 on-call 职责的倦怠而辞职。"
第二部分：Principles of Infrastructure and DevOps（Slide 7）
监控的四大黄金信号（Four Golden Signals）
| 信号 | 含义 | 监控要点 |
|---|---|---|
| Latency（延迟） | 请求服务时间 | 分别追踪成功和失败请求；缓慢的错误尤其需要关注 |
| Traffic（流量） | 系统需求（requests/sec） | 流媒体用会话数，数据库用事务数 |
| Errors（错误） | 失败请求率 | 显式（HTTP 500s）、隐式（200 OK 但内容错误）、基于策略的（超过响应时间承诺） |
| Saturation（饱和度） | 系统"满"的程度 | 追踪 CPU、内存、I/O；系统在 100% 前就开始变慢，需定义安全阈值 |
追踪的关键指标（Slide 11）
| 指标 | 说明 |
|---|---|
| MTTR（Mean Time To Repair） | 从事故发生到修复的平均时间 |
| 拉入事故的工程师数量 | 衡量事故的影响范围和协调成本 |
| 客户报告的 SLA | 注：Mihail 指出这并非显式追踪的 |
第三部分：现场互动——凌晨 3:12 的告警（Slides 8-9，核心！）
场景： 凌晨 3:12，你收到 PagerDuty 的 ping，发现数据库查询出现 500 错误激增。怎么办？
Mihail 先让同学们讨论（"Ask for thoughts from the audience"），再展示完整 Playbook：
事故响应 Playbook（8 步）
Step 1: Acknowledge & Assess（确认和评估）
- 在 PagerDuty 中确认
- 确认严重性：检查应用和数据库仪表盘
- 识别影响：部分中断 or 完全中断
Step 2: Check the Golden Signals — DB First（检查黄金信号）
- Connections：是否达到上限？卡住？突然下降？
- Latency：P95 是否飙升？慢查询？
- Errors：超时？拒绝连接？中止的事务？
- Saturation：CPU、IOPS、锁、内存、复制延迟
Step 3: Look for What Changed（查找变更）
- 最近的部署？数据库迁移？配置/功能标志变更？自动扩展事件？
- → 如果与变更相关，立即回滚/恢复
Step 4: Localize the Failure（定位故障）
- 所有查询还是特定查询？读 vs 写？
- 主库 vs 副本？单个分片还是全部？
- 应用端（连接池/超时）vs 数据库端（负载/锁）？
Step 5: Apply Fast Mitigations（快速缓解）
- 连接问题：重启应用 Pod，降低并发
- 数据库饱和：禁用重量级 Job，限流，将读请求路由到副本
- 坏/慢查询：禁用功能/端点，启用缓存/降级模式
- 副本延迟：将读请求路由到主库，重启副本
- 不健康节点：只重启副本；主库问题需要升级处理
Step 6: Stabilize & Monitor（稳定和监控）
- 观察 500 率、数据库延迟和流量恢复正常
- 确保没有重试风暴或级联故障
- 验证应用健康检查恢复
Step 7: Communicate（沟通）
- 简报更新：问题 → 行动 → 当前状态
- 活跃事故期间每 10-15 分钟更新一次
Step 8: Close Out（收尾）
- 记录时间线，确定根因驱动因素
- 记录后续行动：查询修复、索引优化、扩展、重试调优、容量评审
📚 课程关联： 这个 8 步 Playbook 本质上是一个手动的 Agent 工作流——感知（Step 1-2）→ 推理（Step 3-4）→ 行动（Step 5-6）→ 沟通（Step 7-8）。第二周讲的 Agent 架构（Perception → Reasoning → Action）在这里有了最具体的人工版对照。AI SRE 的目标就是自动化这 8 步。
第四部分：The New AI World（Slides 12-15）
新一代 AI 运维工具（Slide 12）
| 工具 | 定位 |
|---|---|
| Resolve AI | 本周客座嘉宾——AI Production Engineer |
| DataDog Bits AI Agent | 集成在 Datadog 可观测性平台中的 AI Agent |
| Splunk Observability Assistant | Splunk 的 AI 运维助手 |
AI SRE 的四大特征（Slide 13，核心！）
| 特征 | 详细说明 |
|---|---|
| Dynamic Knowledge Graph | 动态映射整个生产环境的知识图谱 |
| Agentic System | 跨可观测性堆栈和云的 Agent 系统 |
| Real-time Narratives | 生成实时叙述——正在发生什么、可能的根因（附证据）、规范性修复步骤 |
| Explainability & Auditability | 重点强调预测/推理的可解释性和可审计性 |
📚 课程关联： "Explainability & Auditability"是本课程首次明确提出的要求——在编码领域（W1-W8）我们关注 AI 是否生成了正确的代码；在运维领域（W9），由于事关生产安全，我们还必须理解 AI 为什么做出这个判断。这与第六周安全课的精神一致——信任必须可验证。
What Has Changed（Slides 15-16）
Slide 15（关键转变）：
- AI 承诺扩展组织和服务级知识
- 信息不再被局限于"唯一知道未记录依赖关系、脆弱遗留服务和只在高风险事故期间才浮现的问题"的少数工程师
Slide 16（AI 代码审查的延续——呼应 W7）：
- 自动化减少审查时间，更早发现问题
- 开发者通过 AI 建议学习最佳实践
- AI 在所有代码审查中应用相同标准
- AI 处理常规检查，让人类专注复杂逻辑
- AI 系统随着更多数据持续改进
- 现代 AI 代码审查工具提供更深入的上下文分析和模式识别
第五部分：AI SRE in Action（Slide 17）
Slide 17: "Let's See AI SRE in Action"
Mihail 现场演示 AI SRE 工具，指出四个关键能力：
- Observability + Working theories（工作假设）
- Span information（跨度信息）
- Heavily evidence-based（大量证据支撑）
- Chat for more dynamic querying of information（聊天式动态查询）
第六部分：Limitations（Slide 18，核心！）
| 局限性 | 说明 |
|---|---|
| 事故复杂性 | 能解决的事故复杂度有限 |
| 现代生产堆栈的异质性 | 不同公司的技术栈差异巨大 |
| 代码修复能力 | 能检测根因，但实际修复代码的能力有限——所有供应商都从 RCA（根因分析）开始 |
| Good RCA requires good monitoring gardening | 好的根因分析需要良好的监控"园艺"——数据质量是基础 |
| 安全可能成为新攻击向量 | AI SRE 本身可能引入新的安全风险 |
📚 课程关联：
- "安全可能成为新攻击向量"= 第六周 Copilot RCE（CVE-2025-53773）在运维领域的翻版——AI 工具在解决问题的同时可能引入新风险
- "Good RCA requires good monitoring gardening"= 经典的 GIGO（Garbage In, Garbage Out），与第四周 Context Engineering 的核心洞见一致——AI 的输出质量取决于输入的上下文质量
- "代码修复能力有限"= 当前 AI SRE 的核心瓶颈——从"发现问题"到"修复问题"还有巨大鸿沟
第二讲：Guest — Resolve AI: AI Agents for Production Systems（Fri 11/21）
演讲者： Mayank Agarwal (CTO) & Milind Ganjoo (Technical Staff) 演示文件： [RESOLVE AI] Stanford CS146S AI Agents for Production Systems.pdf
以下内容综合 Resolve AI 演讲和全部四篇配套阅读材料
第一部分：Resolve AI 公司背景
创始团队：
- Spiros Xanthos（CEO）： OpenTelemetry 共同创建者，前 Splunk Observability 业务 SVP/GM，创建了 Log Insight（被 VMware 收购）和 Omnition（被 Splunk 收购）
- Mayank Agarwal（CTO）： 与 Spiros 20 年前在 UIUC 研究生院相识，自 2012 年起合作，DeepMind Staff MLE
融资： $35M Seed 轮，Greylock 领投，天使投资人包括来自 AWS、Google、GitHub、Replit、OpenAI、Snowflake、Stanford 的技术先驱（Jeff Dean、Reid Hoffman、Fei-Fei Li 等）
客户： Coinbase、Zscaler、Toast、DoorDash、Blueground 等
核心指标： MTTR 减少 70%+，on-call 生产力提升 75%，每位工程师每周节省 20 小时
第二部分：核心问题 — 生产环境的瓶颈
关键论点： "Software engineering has embraced code generation, but the real bottleneck is production."
Spiros 的亲身经历（from Splunk）：
- 90% 的 SRE 团队在六个月内因 on-call 倦怠辞职
- 大多数客户升级是因为可靠性问题
- 有时生产环境被冻结数月以避免宕机——创新完全停滞
核心矛盾： AI 编码助手在加速功能开发，但这也会让运维复杂性更糟——代码写得越快，部署到生产的变更越多，出问题的机会也越多。
"We can't go faster until we solve these operational bottlenecks."
第三部分：AI Production Engineer 产品架构
3.1 Knowledge Graph（知识图谱）
从集成 Resolve AI 的那一刻起，它开始全面映射你的环境：
- 构建一个动态知识图谱——覆盖整个系统和工具
- 实时更新： 新部署、系统事件、配置变更、代码变更时持续更新
- 使 Agent 能够快速遍历所有依赖关系、Pod 和部署
3.2 告警触发时的工作流
告警触发
→ AI 像值班工程师一样立即开始调查
→ 自主创建和执行即时 runbook（just-in-time）
→ 审查：metrics, dashboards, code changes, deployments, logs
→ 不到一分钟 → 根因理论 + 修复建议
3.3 集成生态
| 类别 | 工具 |
|---|---|
| Observability | Datadog, Splunk, New Relic, Grafana |
| Infrastructure & Cloud | AWS, GCP, Azure, Kubernetes |
| Code & CI/CD | GitHub, GitLab, Jenkins |
| Communication & Incident Management | Slack, PagerDuty, Jira |
使用 APIs、Webhooks 和 MCP（Model Context Protocol） 连接和编排这些系统。
📚 课程关联： 第二周学的 MCP 协议在这里以生产级应用出现——Resolve AI 用 MCP 连接可观测性工具，正如 Claude Code 用 MCP 连接开发工具。
第四部分："Vibe Debugging"（氛围调试）
Resolve AI 提出的新概念： 用 AI Agent 调查任何软件问题的过程——从理解代码到排查日常生产事故。
与传统调试的核心区别：
| 维度 | 传统调试 | Vibe Debugging |
|---|---|---|
| 假设生成 | 一次一个，顺序追踪 | 并行探索所有相关假设 |
| 数据收集 | 手动从多个系统收集 | Agent 自动跨系统收集 |
| 证据验证 | 工程师手动交叉验证 | Agent 自主交叉验证 |
| 主动性 | 等待工程师指令 | 主动驱动对话，提供建议、高亮关联、发现你没想到的洞见 |
真实案例：svc-entity-graph 内存问题
工程师说："Investigate the memory issue in svc-entity-graph." AI Agent 的行为：
- 自我定位： 识别正确的资源（svc-entity-graph 作为 prod 中的 kube_deployment），设定调查时间范围
- 并行调查——同时查询完全不同的系统：
- 查询 Git 仓库找到时间窗口内的 1 个最近提交
- 搜索 Grafana，从数百个仪表盘中找到正确的那个，分析 13 个不同图表，定位出与内存问题最相关的 2 个
- 拉取上游服务（svc-entity-graph-ingest）的网络流量遥测数据
- 交叉验证 Kubernetes API 的 Pod 配置以排除基础设施错误
- 确认理论： 通过 CI/CD 管道中同一变更的回滚来确认整个理论，并将其与系统的恢复时间对齐
真实案例：svc-analysis 部署失败
- AI 分析遥测数据（logs），综合结果，定位 node-canvas 错误为根因
- 当问"how to fix"→ 分析上下文，建议安装系统依赖
- 当问"where"→ 分析代码库，指向精确文件（
.github/src/base/node-prod/Dockerfile）和行号
📚 课程关联：
- "Vibe Debugging" 与 W8 "Vibe Coding"（Karpathy）形成平行对照：自然语言→代码 vs 自然语言→调查结论
- 并行假设探索 = 第四周 Claude Code subagent 的生产环境版本——Claude Code 用多个 subagent 并行处理编码子任务，Resolve AI 用多个 Agent 并行调查不同假设
第五部分：AI-Assisted vs AI-Native Engineering
| 维度 | AI-Assisted | AI-Native |
|---|---|---|
| 界面 | 工程师仍然直接操作系统和工具，用 AI 加速个别步骤 | 工程师主要通过 AI来编排工作 |
| 工作流 | 工程师→工具→AI 辅助→结果 | 工程师→自然语言请求→AI 系统→响应/行动 |
| 事件响应 | 你仍在生成假设、决定哪些证据重要、手动关联信号 | AI Agent 自动分类调查优先级、并行生成竞争假设、迭代优化理论 |
| 示例 | "你能分析这些日志吗？" | "解决这个 checkout 失败" |
"AI-Native Engineering is where engineers primarily interface with AI to orchestrate their work."
第六部分：为什么需要 Multi-Agent Systems
核心论点： 单一 LLM 或单一 Agent 在复杂生产环境中会失败。
原因：
- 生产环境涉及多个异构系统（observability, infra, code, CI/CD, communication）
- 不同类型的问题需要不同的专业知识
- 需要同时从多个角度并行调查
Resolve AI 的多 Agent 架构：
- 一个 Agent 专注系统日志
- 另一个 Agent 关注应用指标
- 第三个 Agent 审查代码变更
- 第四个 Agent 检查基础设施配置
- 它们协作得出综合结论
📚 课程关联： Multi-Agent 模式贯穿整个课程：
场景 Multi-Agent 实现 W4 Claude Code Main agent + subagents（不同编码任务） W7 Graphite AI reviewer（不同检查维度） W8 v0 Composite model family（不同生成任务） W9 Resolve AI 多个 investigation agents（日志/指标/代码/K8s）
第七部分：Agentic AI On-call 的五大收益
| # | 收益 | 详细说明 |
|---|---|---|
| 1 | 即时调查 | 告警触发时立即行动——动态生成实时 runbook，不到一分钟定位根因。24/7 不需要睡觉 |
| 2 | 持续学习 | 从每次事故学习，动态更新知识。关键人员离开时知识不会丢失——保留并进化机构知识 |
| 3 | 一致性 | 消除人类工程师对类似问题采取不同方法的变异性——遵循一致工作流，同时适应每个事故的独特上下文 |
| 4 | 多 Agent 协作 | 不同 Agent 专注不同领域，并行工作——既处理常规问题，也适应新颖问题 |
| 5 | 从被动到主动 | 从"救火"转向"战略创新"——AI 处理常规任务，工程师专注架构改进 |
"Agentic AI isn't just the next step in automation—it's a paradigm shift in incident management."
🔗 两讲融合：交叉分析
主题 1：手动 Playbook → AI 自动化的映射
Mihail 的 8 步 Playbook 与 Resolve AI 的自动化形成精确对应：
| Mihail 的手动步骤 | Resolve AI 的自动化 |
|---|---|
| Step 1: Acknowledge & Assess | Agent 自动接收告警，自我定位 |
| Step 2: Check Golden Signals | 自动查询 metrics, dashboards（Grafana 搜索） |
| Step 3: Look for What Changed | 自动查询 Git 仓库、CI/CD 管道 |
| Step 4: Localize the Failure | 并行调查多个假设，交叉验证 |
| Step 5: Apply Fast Mitigations | 建议修复步骤（自动执行能力 "just around the corner"） |
| Step 6: Stabilize & Monitor | 持续监控恢复 |
| Step 7: Communicate | 在 Slack 中生成实时叙述和更新 |
| Step 8: Close Out | 自动生成 Post-mortem |
关键观察： Mihail 的手动 Playbook 用了 8 步、可能需要数小时。Resolve AI 将同样的流程压缩到不到一分钟。但 Slide 18 的局限性提醒我们：复杂事故仍然需要人类判断。
主题 2：可观测性是一切的基础
Google SRE Book → 定义 SRE 原则和 Error Budget
↓
Last9 (Traces & Spans) → 提供可观测性的技术基础
↓
Mihail 的 Four Golden Signals → 定义监控什么
↓
Resolve AI → 在此基础上构建 AI Agent
关键洞见（Slide 18）： "Good root cause analysis requires good monitoring gardening." 没有良好的可观测性，AI 运维就是空中楼阁。
主题 3：Vibe Coding（W8）→ Vibe Debugging（W9）
| Vibe Coding（W8） | Vibe Debugging（W9） |
|---|---|
| 自然语言 → 代码 | 自然语言 → 调查结论 |
| Andrej Karpathy 提出 | Resolve AI 提出 |
| 工具：v0, Bolt, Lovable | 工具：Resolve AI |
| 风险：安全漏洞（CVE-2025-48757） | 风险：误判根因、安全攻击向量（Slide 18） |
| "Anyone can build an app" | "Anyone can debug production" |
主题 4：知识保留——组织的核心挑战
| 传统方式 | AI 方式 |
|---|---|
| 专家离职 → 知识丢失 | Knowledge Graph 持续积累 |
| Runbook 很快过时（Slide 6） | Agent 从每次事故动态学习 |
| 信息孤岛——只有少数人知道（Slide 15） | AI 扩展组织和服务级知识 |
Slide 15 的核心洞见："AI promises to scale out organizational and service level knowledge — Information is not siloed to the only engineers who know the undocumented dependencies, brittle legacy services, and quirks that only surface during high-stakes incidents."
主题 5：安全——贯穿课程的隐忧
| 周次 | 安全问题 |
|---|---|
| W6 | Copilot RCE (CVE-2025-53773)——AI 编码工具的安全漏洞 |
| W8 | Lovable CVE-2025-48757——AI 构建工具的安全漏洞 |
| W9 Slide 18 | "Security could be a new attack vector"——AI 运维工具的安全隐忧 |
每当 AI 获得更多系统权限（从编写代码→构建应用→运维生产），安全风险也在同步升级。AI SRE 拥有对整个生产环境的访问权限——这既是其强大之处，也是潜在的最大风险。
📖 阅读材料总览
| # | 标题 | 来源 | 核心要点 |
|---|---|---|---|
| 1 | Introduction to Site Reliability Engineering | Google SRE Book | SRE 定义、Error Budget 框架、无指责 Postmortem |
| 2 | Observability Basics You Should Know | Last9 | Traces & Spans、M.E.L.T. 三支柱、OpenTelemetry |
| 3 | Kubernetes Troubleshooting with AI | Resolve AI | AI Agent 自动排查 K8s 的四大能力 |
| 4 | Your New Autonomous Teammate | Resolve AI | Knowledge Graph + 即时 Runbook + Vibe Debugging |
| 5 | Multi Agent Systems for AI-native Engineering | Resolve AI | AI-Assisted vs AI-Native、多 Agent 架构 |
| 6 | Benefits of Agentic AI in On-call | Resolve AI | 即时调查、持续学习、一致性、协作、主动转型 |
阅读材料 1：Google SRE Book — Introduction
SRE 定义： "当你让软件工程师来设计运维功能时，就会产生 SRE。"
Error Budget 框架： 将开发速度 vs 系统稳定性的冲突量化——99.99% 可用性 = 允许每季度 13 分钟宕机。预算用完→停止发布；预算有余→加速发布。
Postmortem 文化： 无指责→目标是暴露缺陷并用工程手段修复。没有触发 Page 的 Postmortem 更有价值——指向监控盲区。
阅读材料 2：Last9 — Traces & Spans
Traces = 请求在分布式系统中的完整旅程。Spans = 构建块（每个代表一个工作单元）。
采样策略： Head-based（请求开始时决定）、Tail-based（完成后决定，更适合捕获错误）、Priority（重要操作总是追踪）。
M.E.L.T.： Metrics（系统趋势）+ Events + Logs（调试）+ Traces（请求路径）。OpenTelemetry = 标准框架。
阅读材料 3-6：Resolve AI 四篇博客
K8s 排查： Always-On Expertise → Correlate Across Cluster → Automated Investigations → Provide Resolutions
Product Deep Dive： Knowledge Graph（实时映射）+ 即时 Runbook（<1 分钟）+ 集成生态（Datadog/Grafana/AWS/GitHub/Slack）
Multi-Agent Systems： AI-Assisted（加速步骤）vs AI-Native（AI 成为主界面）。单一 Agent 不够，需要多 Agent 协作。
On-call 五大收益： 即时调查、持续学习、一致性、多 Agent 协作、从被动到主动。
📚 第 1-9 周课程脉络
W1: LLM + Prompt Engineering（基础能力）
↓
W2: Agent + MCP Protocol（自主能力）
↓
W3: AI IDE + Specs-Driven（开发环境）
↓
W4: Agent Manager + Context Engineering（管理架构）
↓
W5: Product Design + Terminal ADE（产品思维）
↓
W6: Security + Testing（防护体系）
↓
W7: Code Review（质量保障——合并前的最后检查点）
↓
W8: Automated UI + App Building（极致应用——AI 替代开发）
↓
W9: Agents Post-Deployment（部署后——AI 运维、监控、事件响应）
第九周完成了 AI 软件开发的完整生命周期：
| 阶段 | 周次 | 内容 |
|---|---|---|
| Build | W1-W5 | 从想法到代码（LLM→Agent→IDE→管理→产品设计） |
| Verify | W6-W7 | 测试和审查（安全→代码审查） |
| Deploy | W8 | 生成和部署应用（自动化 UI） |
| Operate | W9 | 监控和维护生产系统（AI DevOps） |
下一周（W10）：展望未来——Software Development in 10 Years + a16z Martin Casado 客座讲座。
⚡ 第九周核心金句
Mihail: "Coding represents just 30 percent of engineering time. The harder 70 percent is running that code in production."
Mihail Slide 18: "Good root cause analysis requires good monitoring gardening."
Mihail Slide 18: "Security could be a new attack vector."
Resolve AI: "Software engineering has embraced code generation, but the real bottleneck is production."
Resolve AI: "AI-Native Engineering is where engineers primarily interface with AI to orchestrate their work."
Resolve AI: "Agentic AI isn't just the next step in automation—it's a paradigm shift in incident management."
Spiros (Resolve AI CEO): "We can't go faster until we solve these operational bottlenecks."
Spiros: "Agents will perform all the engineering tasks like coding and debugging systems. Humans will operate at a higher level of abstraction overseeing the AI."