错误答案 vs 正确答案：Agent failure recovery
一句话总结
Agent failure recovery 不是写一段 try-catch 然后发告警，而是让系统在无人值守时自己回到正确轨道。面试官问这道题，考的不是你会不会恢复，而是你敢不敢在故障场景下做取舍、能不能证明你的取舍是对的。
真正区分 strong hire 和 borderline 的，是你有没有在系统设计里埋入"可控崩溃"的机制——不是让每个组件都活着，而是让每个组件死得其所。
适合谁看
这篇文章写给正在面硅谷大型科技公司（Google、Meta、Amazon、Netflix、OpenAI、Anthropic）Staff+ 级别或 Senior 以上分布式系统岗位的工程师。你也可能是准备晋升 Staff Engineer 的 Senior，正在经历 system design 面试升级；
或者是从传统后端转 AI infra、第一次面对 agent-based architecture 设计的候选人。
你的背景大概是这样：写过 service mesh，调过 Kubernetes 的 liveness probe，知道什么是 circuit breaker，但面对"agent 挂了怎么恢复"时，还是会本能地从"重启"开始讲起，然后被面试官追问到"如果重启本身也失败呢"时卡壳。你需要的是一套经过真实生产环境验证的判断框架，不是另一篇照搬微服务设计模式的博客。
薪资参考范围（2024-2025 硅谷大型科技，Staff Engineer 级别）：Base $180K-$250K，RSU $120K-$400K/年，Bonus target 15%-20%。总包 $350K-$700K。
这个级别的人，面试官期待你能独立设计一套 region 级别的 failure recovery 策略，而不是背出"用 etcd 做 leader election"这种教科书答案。
为什么这道题会在 Staff 面试里反复出现
Agent-based architecture 正在吞噬所有大型系统的核心路径。不是"可能用"，而是"不得不用"——LLM 推理需要 coordinator agent 调度 GPU 集群，自动驾驶需要 perception agent 持续上报状态，金融风控需要决策 agent 在毫秒级完成规则计算。
这些 agent 不是无状态的 HTTP worker，它们有本地缓存、有未持久化的决策上下文、有和其他 agent 的隐式契约。
面试官问 failure recovery，真正的陷阱在于：agent 的故障不是独立事件，而是级联崩塌的起点。
我见过一个真实的 debrief 场景。候选人在 Google Cloud 的面试里花了二十分钟讲如何用 Kubernetes 自动重启 crashed agent。面试官点头，然后问："这个 agent 正在处理一个 payment reconciliation 任务，已经扣款但还没通知商户。重启后这个任务怎么办？
"候选人愣住了，开始讲 idempotency key。面试官打断他："idempotency key 谁生成的？存在哪里？如果生成 key 的 agent 就是挂掉的那个呢？"
这个候选人最终评级是 no hire，不是因为他不懂 recovery，而是他把 recovery 理解成了 infra 层的操作，不是业务层的语义保证。
不是 infra 负责重启就叫 recovery，而是业务状态最终正确才叫 recovery。不是 agent 活着就好，而是 agent 承诺的工作被完成或可被安全地重新分配。不是故障发生后才想怎么办，而是系统设计时就为故障预留了恢复路径。
> 📖 延伸阅读：Netflix软件工程师面试怎么准备
面试官真正想听的四个层次
第一层：识别 failure 的类型
面试官期待你首先区分 agent failure 的 taxonomy。
不是笼统说"挂了就重启"，而是能拆解成：crash failure（进程崩溃）、omission failure（网络分区导致心跳丢失）、arbitrary failure（Byzantine，比如 agent 日志写满磁盘后行为异常）、以及 performance failure（agent 活着但 RT 飙升拖累整体 SLO）。
一个真实的 hiring manager 对话发生在 Amazon 的 Alexa AI 团队。HM 描述了他们某个 production incident：一个 NLP agent 因为模型加载变慢，从"慢"变成了"不可用"——但健康检查只看进程存活，没看 inference latency。
上游 timeout 后重试，结果这个 agent 的队列越积越长，最终拖垮了整个 cluster。HM 的原话是："我们面试的时候，想听的是候选人能不能说出'health check 应该分层'，而不是背出三种探针的名字。"
第二层：local recovery vs global recovery
第二层判断是单个 agent 自救还是系统层面调度。local recovery 包括：agent 自身的 checkpoint/restore、 WAL（write-ahead log） replay、以及向 coordinator 的主动 lease renewal 失败时的 graceful degradation。
global recovery 包括：coordinator 重新分配任务、standby agent 接管、以及跨 cell 的 failover。
Netflix 的一个经典 debrief 案例：候选人花了大量时间讲 S3 的 multi-region replication，但被追问"RTO 要求 30 秒，你的 replication lag 是分钟级，这 30 秒里用户看到什么"时，候选人没能给出"degraded experience with explicit user communication"的答案。
面试官的 note 写的是："candidate conflates data durability with service availability." 数据没丢，但服务不可用了——这不是 recovery，这是另一种 failure。
第三层：exactly-once vs at-least-once 的业务选择
第三层是 Staff 级别区别于 Senior 的分水岭。不是每个任务都需要 exactly-once，但你需要能论证什么场景下可以承受 at-least-once 的重复，什么场景下必须 exactly-once 以及代价是什么。
Google Spanner 的一位 Staff Engineer 在面试候选人时喜欢问："如果你的 agent 在处理一个'给用户发优惠券'的任务时挂了，恢复后你发现这个任务可能被另一个 agent 也执行了，你怎么办？" 错误的答案是"用分布式事务保证 exactly-once"——面试官马上会追问 Paxos 的 latency 和你的 SLO 冲突怎么办。
正确的路径是：先定义业务对重复的容忍度（用户领到两张优惠券是否可以接受？），再选择技术方案（幂等去重表 + 异步对账，而不是两阶段提交）。
第四层：observability 驱动的 recovery 验证
第四层很少被候选人主动提及，却是 strong hire 的关键标志：你怎么证明 recovery 成功了？不是"看日志没报错"，而是有明确的 recovery SLO、有 chaos engineering 的定期验证、有从 failure injection 到 service level objective 的完整闭环。
一位 Meta 的 Principal Engineer 在 HC（hiring committee）讨论中支持一个候选人的理由是："他提到了 recovery drill 的概念——不是等故障发生才验证，而是每周随机 kill 一个 production agent 并度量 MTTR。这比那些讲了一通理论但没提怎么验证的人高一个层次。"
不是"设计一个完美的系统"，而是"在约束下做最优的坏选择"
这是这道题的元结构。面试官会给你加压：
"你的 coordinator 也是单点，怎么办？"
"你加了 consensus，latency 翻倍，accept 吗？"
"agent 状态太大，checkpoint 太慢，怎么 trade-off？"
一个 Anthropic 的面试场景：候选人设计了 elegant 的 Raft-based coordinator，然后面试官说"你的 leader election 需要 5 秒，但下游 timeout 是 3 秒"。
候选人最初想优化 election 速度，后来在和面试官的反复拉锯中意识到：这个约束下，consensus 根本不是正确答案，应该接受 coordinator 的脑裂风险，用更轻的 gossip + conflict resolution 来换取可用性。
不是每个问题都有好答案，但每个答案都需要被论证。这是 Staff 面试的核心逻辑。
> 📖 延伸阅读：Rippling PMrejection recovery指南2026
准备清单
- 画过至少三个生产系统的 failure mode 分析图，不是组件图，是"这个组件挂了，哪些路径会断"的因果图。PM 面试手册里有完整的 distributed system failure analysis 实战复盘可以参考，特别是怎么把"组件挂了"翻译成"用户看到什么"的推导过程。
- 准备两个自己经历过的真实 incident，能讲清楚：故障现象、你的诊断路径、最终根因、以及如果重来你会在设计上做什么不同。面试官对"我学到了"的兴趣远低于"我会怎么改"。
- 熟背一个系统的 recovery SLO 数字：RTO、RPO、MTTR、MTBF，以及这些数字是怎么推导出来的。不是背定义，是能解释"为什么是 30 秒而不是 5 秒"。
- 读过至少一篇你目标公司的公开故障复盘（Google 的 SRE book、Meta 的 production engineering blog、Netflix 的 tech blog），能在面试中引用具体细节。"Netflix 在 2019 年的 Chaos Kong 演练中发现..."比"我认为应该做 chaos engineering"有力一百倍。
- 练习过"故意说我不确定"的场景。Staff 面试不是答题比赛，是展示你在信息不完备时如何做判断。准备一个你确实不知道答案的问题，练习说"我没有直接经验，但基于 X 原理，我的判断是 Y，验证方式是 Z"。
- 用白板或纸笔限时 45 分钟完整走一遍 agent failure recovery 的设计，然后录下来自己回看。注意你花在"正常运行"上的时间——超过 10 分钟就是 red flag，面试官想听的是故障场景。
- 找到你设计中的三个"如果这样就完蛋了"的点，准备好被追问时的辩护或退让策略。不是每个设计点都需要捍卫，关键是展示你能权衡。
常见错误
错误一：把 agent 当成无状态服务来设计 recovery
BAD： "Agent 挂了？Kubernetes 会自动重启，liveness probe 是 10 秒间隔。"
GOOD： "这个 agent 持有三个关键状态：正在处理的 task context、本地模型缓存的 warm-up 状态、以及和 peer agent 建立的 session 协商结果。我会在 task context 层面用 WAL 保证可恢复，模型缓存接受冷启动的 latency penalty，session 设计为可重新协商。
重启策略是分层的：process crash 自动重启，host failure 迁移到新机，zone failure 触发跨 region standby。"
区别：后者让面试官看到你对"状态"的敏感，而不是把 agent 当成黑盒。
错误二：追求 theoretical correctness，忽视 production constraint
BAD： 在面试官提到 latency 要求后，仍然坚持用 full 2PC + Paxos 来保证 exactly-once，理由是"正确性优先"。
GOOD： "这个场景下，我会在设计文档里明确标注'accept temporary inconsistency in coupon issuance, detect and reconcile within 24 hours'。技术方案是：at-least-once delivery + 业务层幂等 key + 每日对账 job。
如果面试官坚持问极端场景，我会给出升级路径：当欺诈率超过 X% 时，切换到 stronger consistency model，代价是 Y ms latency increase。"
区别：后者展示的是 engineering judgment，不是教条。
错误三：recovery 设计里没有 observability
BAD： "恢复之后，我会检查日志确认正常。"
GOOD： "我会在三个层面验证 recovery：agent 层面，恢复后的 first task 成功率；coordinator 层面，reassignment 的 latency 和成功率；业务层面，用 shadow traffic 比对恢复前后的输出一致性。
每周的 chaos drill 会随机 kill agent，MTTR 的 p99 是我的核心告警指标。如果 p99 超过 2 分钟，触发 oncall 并启动 incident response。"
区别：后者是可操作的系统，前者是 wishful thinking。
FAQ
被追问"你的 coordinator 挂了怎么办"时，怎么回答才能不陷入无限递归？
这是一个经典的 pressure test。面试官不是真的想让你设计完美的无限容错，而是看你什么时候能明确地划定边界。
正确的判断是：承认 coordinator 是剩余故障域，然后用 engineering 的方式管理这个风险，而不是假装它能自愈。
具体做法：首先，明确区分 coordinator 的两种状态——配置中心状态（哪些 agent 活着、任务分配映射）和运行时协调状态（当前的 lease、in-flight task）。配置中心状态用外部 strongly consistent store（如 etcd/ZooKeeper）持久化，接受其作为 trust anchor。运行时协调状态允许在 coordinator 故障时丢失，因为 agent 会在 lease 过期后进入 self-governing mode（按预设策略继续或安全暂停）。然后，设计 coordinator 自身的 cold standby：不是 hot failover（那又引入另一个 consensus 问题），而是明确的 failure detection（通过外部 monitor）+ 分钟级恢复 + 恢复后 agent 重新注册。
最后，也是最被忽略的点：在 coordinator 宕机期间，系统的"degraded"行为是什么？是排队等待、是拒绝新请求、还是允许 agent 自治？你必须给出一个明确的业务决策，并用 SLO 定义这个 degraded 状态的接受标准。一位 Google SRE Director 在面试中的原话是："I don't care if your coordinator is down. I care what the user sees when it's down."
怎么在 45 分钟面试里把时间花在刀刃上？
时间分配的错误范式是：10 分钟讲 normal path，20 分钟讲 happy case 的 scaling，最后 15 分钟被面试官赶着讲 failure。
正确的结构是反过来的：用 5耗的第一分钟明确 scope——"这个系统里，agent 故障包括 crash、network partition 和 performance degradation，我的 recovery 策略会分别处理这三种情况，重点讲后两种因为更复杂"。
然后，用 10 分钟画出 agent-coordinator 的交互协议，特别强调 heartbeat/lease 的语义——不是"agent 定期 ping"，而是"agent 必须在 lease 到期前完成 X，否则 coordinator 会 Y"。这是 interviewer 会深入追问的点。
接下来的 25 分钟全部给 failure scenarios：agent 在 task 执行到 80% 时 crash、agent 网络分区但进程还在（split brain）、agent 慢但heartbeat 正常（需要业务级 health check）。最后 10 分钟留给 recovery 的验证和监控，以及主动提及"这个设计的 trade-off 是..."
一个来自 Meta 的 HC 观察：strong hire 的候选人通常会在 20 分钟左右主动说"我想 pause 一下，确认一下我们要深入哪个方向"，而 borderline 的候选人会被面试官推着走。掌控节奏本身就是在展示 Staff 级别的判断力。
没有大规模 agent 系统的经验，怎么回答这道题？
这是多数候选人的真实情况，也是面试官预料之中的。关键不是假装有经验，而是展示你能把相关经验迁移到这个问题上。
具体的迁移路径：如果你有 Kubernetes operator 的开发经验，把 operator 的 reconcile loop 类比为 coordinator 的 recovery logic——operator 发现 pod 实际状态和 desired state 不一致时的处理方式，就是你讨论 agent recovery 的入口。如果你有流式系统的经验，把 exactly-once processing 的语义直接映射过来：Flink 的 checkpoint 机制如何在 agent 场景下变形？
如果你有游戏服务器或实时通信的经验，把 session migration 的技术拿出来：玩家断线重连时如何恢复状态，这和 agent 故障恢复是同一类问题。
一个成功的 Amazon 面试案例：候选人来自 AWS Lambda 团队，没有 agent 经验，但把 Lambda 的 placement 和 capacity management 类比为 agent 的调度，把 Lambda 的 cold start 优化类比为 agent 的模型缓存恢复。
面试官的 feedback 是："demonstrates strong first-principles thinking, able to map across domains."
但有一个致命错误：把完全不相关的经验硬套。比如把传统 CRUD 服务的 "read replica failover" 直接说成 agent recovery，却不解释 agent 的状态有 local context 这个关键差异。面试官会立刻识别出这是 superficial 的套用，而不是 deep understanding。
Agent failure recovery 这道题，本质是在问：你能不能设计一个会自己照顾自己的系统，同时诚实地承认它的边界在哪里。正确的判断是：recovery 不是系统的附加功能，而是系统设计的核心约束——从你画第一条线开始，就要假设这条线的任何一点都可能断裂。不是悲观，而是专业。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。