课程PPT笔记
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."
阅读材料笔记
CS146S 第九周阅读材料笔记：Agents Post-Deployment
Stanford University · Fall 2025 · 讲师：Mihail Eric 课程网站：themodernsoftware.dev
📖 阅读材料总览
| # | 标题 | 来源 | 核心主题 |
|---|---|---|---|
| 1 | Introduction to Site Reliability Engineering | Google SRE Book, Ch.1 | SRE 基础理论：定义、原则、Error Budget |
| 2 | Observability Basics You Should Know | Last9 Blog | Traces & Spans：分布式追踪基础 |
| 3 | Kubernetes Troubleshooting with AI | Resolve AI Blog | AI Agent 自动排查 K8s 问题 |
| 4 | Your New Autonomous Teammate (Product Deep Dive) | Resolve AI Blog | AI Production Engineer 产品架构 |
| 5 | Role of Multi Agent Systems in Making Software Engineers AI-native | Resolve AI Blog | 多 Agent 系统 + AI-native 工程 |
| 6 | Benefits of Agentic AI in On-call Engineering | Resolve AI Blog | Agentic AI 改造 On-call 的五大收益 |
阅读材料 1：Introduction to Site Reliability Engineering
来源： Google SRE Book, Chapter 1（Ben Treynor Sloss，Google SRE 创始人）
核心内容
SRE 的定义： "当你让软件工程师来设计运维功能时，就会产生 SRE。" Ben Treynor Sloss 是 Google 负责技术运营的高级副总裁，也是 SRE 一词的创造者。
SRE 团队构成：
- 50-60% 是标准 Google 软件工程师
- 40-50% 是接近 Google SWE 标准（85-99% 的技能），但额外拥有 UNIX 系统内核和网络（L1-L3）专业知识
- 两个轨道的工程师在实际表现上没有实际差异——多元背景反而产生更高质量的系统
核心原则：Error Budget（错误预算）
SRE 的关键创新是将开发速度 vs 系统稳定性的隐性冲突变成一个可量化的框架：
- 产品开发团队想要快速发布新功能
- 运维团队想要系统永远不出问题
- SRE 的解决方案：设定一个错误预算（比如 99.99% 可用性 = 允许每季度 13 分钟宕机）
- 如果错误预算用完了→停止发布新功能，直到下一个周期
- 如果错误预算还有余量→可以加速发布
Postmortem 文化：
- 所有重大事故都应写 Postmortem，无论是否触发了 Page
- 没有触发 Page 的 Postmortem 更有价值——因为它们指向监控盲区
- Google 实行无指责文化——目标是暴露缺陷并用工程手段修复，而非追究个人责任
📚 课程关联： SRE 的"无指责 Postmortem"与第七周 code review 的核心理念一致——Blake Smith 说 code review 最重要的功能是"保持团队心智模型对齐"，Postmortem 最重要的功能是"暴露系统缺陷"。两者都是团队学习机制，而非惩罚机制。
阅读材料 2：Traces & Spans: Observability Basics You Should Know
来源： Last9 Blog
核心概念
Traces（追踪）： 捕获一个请求在分布式系统中从头到尾的完整旅程。
Spans（跨度）： Traces 的构建块。每个 Span 代表旅程中的一个工作单元——如数据库查询、API 调用、函数执行。
Trace
├── Span (API Gateway)
│ ├── Span (Auth Service)
│ └── Span (User Service)
│ └── Span (Database Query)
└── Span (Response Formatting)
Span 包含的数据：
- 时间戳（开始和结束）
- Status（成功、错误等）
- Attributes（自定义键值对，如 user_id, cart_size）
- 父子关系（嵌套结构）
采样策略（Sampling）——追踪所有请求会产生海量数据：
- Head-based sampling： 在请求开始时决定是否采样
- Tail-based sampling： 在请求完成后决定（更适合捕获错误）
- Priority sampling： 总是追踪重要操作，对常规操作采样
可观测性三大支柱（M.E.L.T.）：
- Metrics： 系统级趋势（请求率、错误率、平均延迟）——"每分钟有多少 checkout 请求失败？"
- Logs： 详细的文本记录——用于调试
- Traces： 个别请求的完整路径——"这个请求经过了哪些服务，每步花了多长时间？"
OpenTelemetry 已成为实现 traces 和 spans 的标准框架——开源、厂商中立、跨语言。
最佳实践：
- 有意义的 span 命名（如
service_name/operation） - 正确的粒度（为重要操作创建 span，而非每个函数）
- 正确的 context propagation（确保追踪上下文在所有通信通道中流转）
- 有用的 attributes（添加有助于排查的属性，如 user_id, feature_flag）
常见错误：
- Over-instrumentation：创建太多 span 导致性能问题
- Missing context：未能跨服务传播上下文
- Inconsistent naming：不同的命名标准导致追踪难以解读
📚 课程关联： 可观测性是第六周安全/测试的"运行时"对应——第六周关注"代码中有什么漏洞"（SAST/DAST），第九周关注"运行中发生了什么"（Traces/Metrics/Logs）。
阅读材料 3：Kubernetes Troubleshooting with AI
来源： Resolve AI Blog
核心问题
Kubernetes 虽然自动化了很多运维，但其动态和临时性的本质带来新挑战：
- Noisy Alerts That Cry Wolf： K8s 控制平面不断调整工作负载以匹配期望状态，期间产生大量虚假告警
- Noisy Neighbors： 相邻 Pod 资源竞争
- Misbehaving Add-ons： 插件行为异常
- Resource Starvation： 资源匮乏
- Subtle Memory Leaks： 细微的内存泄漏——"潜伏在表面之下"
Resolve AI 的 K8s 排查方式
传统排查： 凌晨 2 点收到告警 → kubectl → 发现问题"神秘自愈" → 但根因仍在
AI 排查（Agentic AI）：
- Always-On Expertise： AI 不需要睡觉——告警触发时立即进入集群，在你打开电脑之前就提供可操作的洞见
- Correlates Issues Across Cluster： 利用知识图谱检查 Pod、Node、Namespace 之间的类似异常
- Runs Automated Investigations： 自动测试假设（"是 OOM 错误吗？" "Pod 失败是因为启动命令配置错误吗？"）——自动执行 runbook
- Provides Resolutions： 如果找到解决方案就建议执行，否则列出明确的下一步
📚 课程关联： "Correlates Issues Across Cluster" = 第二周的 Agent 跨工具协调能力。传统工程师需要在多个仪表盘之间手动关联信号，AI Agent 可以自动完成这个过程——这正是 Agent 架构的核心价值。
阅读材料 4：Your New Autonomous Teammate（Product Deep Dive）
来源： Resolve AI Blog
AI Production Engineer 产品架构
Knowledge Graph（知识图谱）：
- 从集成 Resolve AI 的那一刻起，它开始全面映射你的环境
- 构建一个动态知识图谱——覆盖整个系统和工具
- 实时更新：新部署、系统事件、配置变更、代码变更时持续更新
- 使 Resolve AI 能够快速遍历所有依赖关系、Pod 和部署
告警触发时的工作流：
- 像值班工程师一样立即开始调查
- 自主创建和执行即时 runbook
- 审查：metrics、dashboards、code changes、deployments、logs
- 不到一分钟就已定位根因理论并建议修复步骤
"Vibe Debugging"（氛围调试）：
- Resolve AI 提出的新概念
- 工程师用自然语言描述问题 → AI Agent 自动执行整个调查循环
- AI 不是一次追踪一个假设，而是并行探索所有相关假设
- 同时从多个系统收集证据：Git 仓库、Grafana 仪表盘、K8s API、CI/CD 管道
真实案例： 调查 svc-entity-graph 服务的内存问题
- Agent 自动查询 Git 仓库找到时间窗口内的 1 个最近提交
- 同时搜索 Grafana，从数百个仪表盘中找到正确的那个，分析 13 个不同图表，定位出与内存问题最相关的 2 个
- 同时从上游服务拉取网络流量遥测数据
- 交叉验证 K8s API 的 Pod 配置以排除基础设施错误
- 最后通过 CI/CD 管道中同一变更的回滚来确认整个理论
公司背景：
- $35M Seed 轮，Greylock 领投
- 创始人 Spiros 共同创建了 OpenTelemetry（可观测性标准）
- 客户：Coinbase, Zscaler, Toast 等
- 客户反馈：MTTR 减少 70%+，on-call 生产力提升 75%，每位工程师每周节省 20 小时
📚 课程关联：
- "Vibe Debugging" 与第八周 "Vibe Coding" 形成平行对照——Karpathy 提出 Vibe Coding（用自然语言描述代码），Resolve AI 提出 Vibe Debugging（用自然语言描述问题）
- Knowledge Graph = 第四周 Context Engineering 的生产环境版本——CLAUDE.md 给 Agent 提供项目上下文，Knowledge Graph 给 Agent 提供整个生产系统的上下文
阅读材料 5：Role of Multi Agent Systems in Making Software Engineers AI-native
来源： Resolve AI Blog（基于 Stanford 研究生 AI 课程的演讲）
AI-Assisted vs AI-Native
| 维度 | AI-Assisted | AI-Native |
|---|---|---|
| 界面 | 工程师仍然直接操作系统和工具，用 AI 加速个别步骤 | 工程师主要通过 AI 来编排工作 |
| 工作流 | 工程师→工具→AI 辅助→结果 | 工程师→自然语言请求→AI 系统→响应/行动 |
| 事件响应 | 你仍在生成假设、决定哪些证据重要、手动关联信号 | AI Agent 自动分类调查优先级、并行生成竞争假设、迭代基于跨系统证据优化理论 |
| 示例 | "你能分析这些日志吗？" | "解决这个 checkout 失败" |
为什么单一 Agent 不够？
复杂的生产环境需要多 Agent 系统：
- 单一 LLM 或单一 Agent 在复杂生产环境中失败
- 需要不同 Agent 专注不同领域：一个检查系统日志，另一个关注应用指标，第三个审查代码变更
- 多 Agent 协作能够处理常规和新颖问题
从 AI-Assisted 到 AI-Native 的转变：
- AI-Assisted：工程师用 AI 加速编码（Copilot, Cursor）
- AI-Native：AI 成为工程师操作生产系统的主要界面
- 目标：工程师在更高抽象层次运作，监督运行生产系统的 AI
📚 课程关联：
- "AI-Assisted vs AI-Native" 完美对应课程从第一周到第九周的演进：W1-W3 是 AI-Assisted（LLM 辅助编码），W4-W8 越来越接近 AI-Native（Agent 管理整个开发流程）
- "Multi Agent Systems" = 第四周 Claude Code 的 subagent 架构在生产环境的扩展——Claude Code 用多个 subagent 处理不同编码任务，Resolve AI 用多个 Agent 处理不同运维任务
- 第二周的 MCP 协议在这里再次出现：Resolve AI 使用 MCP 来连接和编排不同系统
阅读材料 6：Top 5 Benefits of Agentic AI in On-call Engineering
来源： Resolve AI Blog
五大收益
| # | 收益 | 详细说明 |
|---|---|---|
| 1 | 即时调查 | 告警触发时，Agentic AI 立即行动——动态生成和执行实时 runbook，分析 metrics/dashboards/code changes/deployments/logs，不到一分钟定位根因。不会累、不需要睡觉、24/7 精确工作 |
| 2 | 持续学习 | 每次事故后动态更新知识——不像静态 runbook 很快过时。关键人员离开时，其专业知识不会丢失——Agentic AI 保留并进化机构知识 |
| 3 | 一致性 | 人类工程师对类似问题采取不同方法→不一致的结果。Agentic AI 遵循一致的工作流，同时适应每个事故的独特上下文 |
| 4 | 多 Agent 协作 | 一个 Agent 专注系统日志，另一个关注应用指标——并行工作。既能处理常规问题，也能适应新颖问题 |
| 5 | 从被动到主动 | 从"救火"转向"战略创新"——Agentic AI 处理常规任务，工程师专注架构改进 |
关键转变
"Agentic AI isn't just the next step in automation—it's a paradigm shift in incident management."
传统自动化：预定义脚本 → 触发条件 → 执行固定步骤 Agentic AI：理解上下文 → 生成假设 → 并行调查 → 自主决策 → 持续学习
📚 课程关联：
- "持续学习"对应第七周 Graphite 的 acceptance rate/upvote rate——两者都是通过反馈循环持续改进
- "从被动到主动"呼应第五周产品设计原则——工具应该让人专注高价值工作（设计/架构），而非低价值重复性工作（排查/调试）
🔗 六篇阅读材料的交叉主题
主题 1：可观测性是 AI 运维的基础
Google SRE Book（阅读材料 1）定义了运维的基本原则 → Last9（阅读材料 2）提供了可观测性的技术基础（Traces/Spans/Metrics） → Resolve AI（阅读材料 3-6）在此基础上构建 AI Agent。
关键洞见：没有良好的可观测性，AI 运维就是空中楼阁。 AI Agent 的"智能"完全依赖于它能获取的数据质量。
主题 2：从手动 → 自动化 → Agentic
手动运维（传统 SRE）
→ 收到告警 → 打开仪表盘 → 手动检查日志 → 生成假设 → 逐一验证
自动化（Runbook/脚本）
→ 收到告警 → 执行预定义脚本 → 如果匹配已知模式则修复
Agentic AI（Resolve AI）
→ 收到告警 → AI 自动理解上下文 → 并行生成多个假设 → 跨系统收集证据 → 自主判断 → 建议或执行修复
这个演进链条与课程从 W1 到 W9 的脉络完全一致：
- W1-W3：手动编码 → AI 辅助编码
- W4-W8：AI 辅助 → AI 驱动
- W9：AI 驱动 → AI 自主（在生产运维领域）
主题 3：知识保留 vs 知识流失
| 传统方式 | AI 方式 |
|---|---|
| 专家离职 → 知识丢失 | Knowledge Graph 持续积累 |
| Runbook 很快过时 | Agent 从每次事故学习 |
| 文档总是不完整 | AI 自动构建系统全景 |
这与第七周 Blake Smith 的"心智模型对齐"深度相关——code review 让团队的心智模型保持同步，Knowledge Graph 让整个组织的运维知识保持同步。
主题 4：Vibe Coding → Vibe Debugging（课程新对称性）
| Vibe Coding（W8） | Vibe Debugging（W9） |
|---|---|
| 自然语言 → 代码 | 自然语言 → 调查结论 |
| Andrej Karpathy 提出 | Resolve AI 提出 |
| 工具：v0, Bolt, Lovable | 工具：Resolve AI |
| 风险：安全漏洞（CVE-2025-48757） | 风险：误判根因、自动执行错误修复 |
| "Anyone can build an app" | "Anyone can debug production" |
主题 5：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） |
共同架构模式： 将复杂任务分解为专业化子任务，每个子任务由专门的 Agent/Model 处理。
📚 第 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 辅助开发"到"AI 替代开发"）
↓
W9: Agents Post-Deployment（部署后——AI 运维、监控、事件响应）
第九周完成了 AI 软件开发的完整生命周期：
- W1-W5：Build（从想法到代码）
- W6-W7：Verify（测试和审查）
- W8：Deploy（生成和部署应用）
- W9：Operate（监控和维护生产系统）
下一周（W10）将是展望未来——软件开发的下一个十年。
⚠️ 注意
本周 Slides 尚未获取（Monday 11/17 Mihail 讲座 + Friday 11/21 Resolve AI 嘉宾讲座）。获取 Slides 后将补充完整的讲座笔记。
思维导图
本周暂未提供思维导图。
知识图谱
本周暂未提供知识图谱。