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 后将补充完整的讲座笔记。