第 10 周 · 部署、压测、故障演练与毕业答辩
证明系统可以上线，而不只是本地演示，并完成 30 分钟技术答辩
本周产出：生产部署、压测报告、简化 API / CLI Demo、技术答辩 · 预计投入：15 到 20 小时 · 对应原 24 周编号：第 24 周
分档说明
自定义 AG-UI 流式前端在程序员进阶版模块 A8，本周毕业项目用简化 API / CLI 演示替代，展示 steering、follow-up、cancel、approval 基本流程。
学前自测
1. SLI、SLO 和 Error Budget 分别是什么？三者什么关系？
SLI 是你实际测量的指标（比如 Agent Run 成功率）；SLO 是你承诺的目标值（比如 99%）；Error Budget 是 SLO 允许的失败额度（1%）。关系是：Error Budget 没烧完就可以继续发新功能，烧完了就必须停下来修稳定性。它把可靠性变成了可以量化决策的东西。
2. Agent 系统的压测和普通 API 压测有什么不同？
三点不同：单请求耗时是秒到分钟级不是毫秒级；成本随并发线性增长而且很贵；上游 Provider 有 Rate Limit，你打不满自己的系统就先被限流了。所以 Agent 压测的瓶颈往往不在你的代码，而在 Provider 配额和成本预算。
3. RPO 和 RTO 是什么？对 Agent 系统意味着什么？
RPO 是能容忍丢失多少数据（恢复点），RTO 是能容忍停机多久（恢复时间）。对 Agent 系统的特殊之处在于：Session 和事件流丢了，正在跑的长任务就无法恢复，用户会看到任务凭空消失。这决定了事件持久化的频率。
4. 灰度发布一个新的 Agent 版本，你按什么维度切流量？
按租户或用户维度，不能按请求维度。原因是同一个用户的多轮对话必须落在同一个版本上，否则上下文格式可能不兼容，用户会看到 Agent 中途变了个人。这是 Agent 灰度和普通 API 灰度的关键差别。
学习目标
证明系统可以上线，而不只是本地演示。
这一周还有一个同等重要的目标：把十周的工作组织成一场能打动面试官的 30 分钟讲述。技术做完了但讲不清楚，在求职上等于没做。
课程内容
- Docker Image、Multi-stage Build、Environment
- Migration、Horizontal Scaling、Load Balancing
- Stateless API、Worker Scaling、Rate Limit、Cache
- Load Test、Chaos Test
- Backup / Restore、Release / Rollback
- SLI / SLO / Error Budget
- Capacity Model 与 Provider Quota
- RPO / RTO、灾备与区域故障
- Session / Event 数据迁移
- Incident Response 与 Runbook
- 简化 API / CLI Demo：steering、follow-up、cancel、approval 基本流程演示
生产拓扑与故障注入点
实施任务
- Docker Compose 生产模拟部署
- GitHub Actions 自动发布
- 数据库迁移、多实例 Runtime、Redis 共享状态、Worker 水平扩展
- 100 并发压测
- 模型 API 故障注入
- Redis / PostgreSQL / Worker 重启演练
- Prompt 版本回滚、Agent 版本灰度发布
- Session / Event 备份、恢复
- Provider 限流、区域不可用和成本异常演练
- 实现简化 API / CLI Demo，演示 steering、follow-up、cancel、approval 基本流程
动手挑战
给自己开一场事故复盘会，事故由你亲手制造。
选一个你觉得最脆弱的环节（通常是 Provider 限流或者 Worker 崩溃），在压测过程中注入这个故障，然后按真实事故流程走一遍：
- 发现：从故障注入到你的监控告警，隔了多久？如果是靠肉眼看日志发现的，说明可观测性不合格
- 止血：你的第一个动作是什么？有没有一键降级或者熔断开关？
- 定位：用 Trace Explorer 找到根因花了多久？
- 恢复：故障排除后，中断的任务能不能自动恢复？丢了几个？
- 复盘：写一份 Postmortem，包含时间线、影响面、根因、改进项
这份 Postmortem 是你作品集里最特别的一份文档。绝大多数求职者的项目从没经历过故障，能拿出真实故障复盘的候选人会被立刻记住。
最终验收
十三条全部满足才算程序员基础版通关：
- Agent Run 成功率达到既定目标
- 服务重启后长任务可恢复
- 高风险操作均有审批记录
- 所有回答可追踪模型、Prompt、工具和知识来源
- Eval Gate 可阻断低质量版本
- 具备多租户隔离
- 成本、延迟和 Token 可视化
- 关键 API 有压测报告
- 完整 README、架构文档和运行手册
- 完成 30 分钟技术答辩
- 核心 SLI、SLO、Error Budget 有基本证据
- Native / Mastra 双 Runtime 基线可运行
- 简化 API / CLI Demo 可演示 steering、follow-up、cancel、approval 基本流程
自定义 AG-UI 前端、五框架选型与退出策略报告为程序员进阶版验收，见程序员进阶版模块 A8 与附录 B。
学后自测
1. 100 并发压测下，你的瓶颈在哪一层？数字是多少？
要能报出具体瓶颈和数字：是 Provider 限流（每分钟多少请求）、还是数据库连接池、还是 Worker 数量。答不出瓶颈在哪，说明压测只跑了没看。
2. 一次典型 Agent Run 的成本是多少？100 并发跑一小时要花多少钱？
这个数字必须能张口就来，因为面试官会问，而且商业决策依赖它。算法是单次 Run 的平均 Token 乘单价，再乘吞吐。答不出来说明第 2 周的成本追踪没真正用起来。
3. 你的 Runbook 里有几个场景？新人照着能不能独立处理故障？
最小集：Provider 故障、数据库连接耗尽、Worker 堆积、成本异常、Eval 门禁误报。每个场景要有判断依据、处理步骤和升级路径。写完自己按着走一遍，走不通的就是没写清楚。
本周作业
这一周的作业就是作品集本身，交付六件：
- 生产部署配置 + GitHub Actions 发布流水线
docs/load-test-report.md：100 并发压测报告，含瓶颈分析和成本核算docs/postmortem-001.md：动手挑战的事故复盘docs/runbook.md：至少五个故障场景的处理手册- 简化 API / CLI Demo，可现场演示四个流程
README.md：项目主文档，架构图 + 快速上手 + 核心设计取舍
面试考点
这一周对应面试里的综合表达，也就是简历深挖和项目讲述环节。
30 分钟答辩的结构建议（同样适用于面试的项目介绍）：
| 时间 | 内容 | 目的 |
|---|---|---|
| 0 到 3 分钟 | 业务场景与要解决的问题 | 证明你是从需求出发不是从技术出发 |
| 3 到 8 分钟 | 整体架构图讲解，五层结构 | 建立全局认知 |
| 8 到 18 分钟 | 三个最难的技术决策，每个讲清备选方案和否决理由 | 这是核心得分段 |
| 18 到 25 分钟 | 现场 Demo：steering、follow-up、cancel、approval | 证明真的能跑 |
| 25 到 30 分钟 | 踩过的坑与故障复盘，以及下一步计划 | 展示成长性和诚实度 |
常见提问准备
- 「这个项目你花了多久？哪部分最难？」：诚实答十周。最难的部分要选一个真正有技术含量的（通常是第 4 周的 Harness 或第 7 周的幂等性），不要答我不熟悉 TypeScript 这种。
- 「如果重做一遍，你会改什么？」：必答题，而且必须有答案。答不上来说明没有反思。参考答案方向：事件协议应该更早版本化、评测集应该在第 5 周就开始建而不是第 9 周。
- 「这个系统能撑多大规模？」：拿压测报告答，报瓶颈和数字。同时诚实说明当前架构的上限在哪，以及要突破需要改什么。
- 「你觉得自己还缺什么？」：这题不要谦虚过头也不要虚张声势。可以答目前的多 Agent 协作和更深的框架源码理解还在补，正在学程序员进阶版的内容。展示明确的成长路径比假装全会更可信。
简历怎么写这个项目
用结果导向的三句话结构：做了什么系统、解决了什么具体问题、量化结果是什么。例如：设计并实现框架无关的 Agent 平台，支持 Native / Mastra 双 Runtime 热切换，通过统一 Policy 与 Eval 门禁将高风险操作拦截率提升到 100%、线上回归缺陷下降 X%。数字来自你的压测报告和评测报告，不要编。
复习与延伸
官方文档
恭喜通关
十周走完，你手上有一个可部署、可观测、可评测、有安全边界的 Agent 平台，以及一整套证明过程的文档。
接下来两个方向：
- 直接开始投简历：程序员基础版的目标就是上岗，现在就够了。按上面的简历写法整理，把答辩结构练熟
- 继续建立差异化竞争力：程序员进阶版有 Pi 源码精读、LangGraph 状态编排、多框架配对与 exit drill、Multi-Agent、A2A、AG-UI 深度版，目标是 Senior / Staff 级