Agent 可靠性与恢复要如何设计？

面试官：Agent 长任务最常见的可靠性问题是什么？第二层追问：为什么不能只靠 retry？

我：我第一反应不会是加 retry。Agent 长任务的可靠性问题包括 process crash、provider timeout、tool half-executed、context compaction missing facts、permission wait、external state change。比如 Agent 正在发邮件、写文件、创建 ticket，retry 可能会重复发、重复写、重复创建。真正要先保证 durable facts、checkpoint、effect ledger、idempotency 和 recovery gate：事实能不能落账，副作用有没有完成，恢复时还能不能安全继续。只有这些判断清楚了，才决定要不要 retry。

面试官：哪些状态必须 durable？第二层追问：哪些可以重算？

我：我会把事实源和派生视图区分开。必须 durable 的是 session metadata、event log、tool intent/result、permission decisions、artifact refs、pending effects、plan state、context decisions、verification results 和 usage。可以重算的是 UI projection、部分 summary、token estimate、cache 和 model input view。可重算不等于随便算，必须从 durable facts 重新生成。比如恢复后重新投影 context 可以，但不能靠旧 messages 猜工具到底有没有执行。

面试官：工具执行中途崩溃怎么办？第二层追问：怎么判断有没有副作用？

我：工具执行中途崩溃，最怕的是系统不知道副作用到底执行到哪了。所以执行前要写 effect_started，执行后写 effect_completed；只有 started 没 completed，就是 pending effect。恢复时按 effect 类型检查：文件写看 temp file、diff、worktree；API 写查 idempotency key、external request id 或外部状态；shell 看进程、输出和 changed files。能确认就 commit 或 rollback，不能确认就 ask human 或 mark inconsistent。不能靠 retry 硬重跑，因为可能把真实世界副作用重复一遍。

面试官：Replay 是不是重新执行一遍？第二层追问：LangGraph replay 和你的 replay 有什么区别？

我：Replay 不是让事故再发生一次，而是看行车记录仪。我会分三种：diagnostic replay 只从 durable facts 重建模型输入、工具时间线和审计视图，不重跑 provider 或 tool；simulation replay 用 mock tool 或 frozen provider 生成新轨迹，适合测策略变化；live retry 才是真实重试，必须重新走权限、幂等、沙箱和 pending effect 检查。比如复盘一次错误转账，只能看历史流水和当时 observation，不能为了复盘再真转一次钱。

面试官：恢复时如何保证 tool call/result 配对合法？第二层追问：如果只记录了 tool call 没记录 result 呢？

我：恢复不是把旧 messages 拼回来就完了，很多 provider 要求 tool_call 和 tool_result 成对合法。恢复 conversation view 前要跑 pairing safety：已完成 tool call 必须有对应 result；如果只有 call 没有 result，不能直接塞回 provider。我的处理是把 run 转成 interrupted state，合成受控 error observation，或者交给 host 决策要 retry、rollback 还是问用户。这样模型看到的是合法、可解释的状态，不会因为一半工具轮次把 provider 协议打坏。

面试官：Checkpoint 频率怎么定？第二层追问：每个 token 都写是不是太重？

我：不用每个 token 都同步写，那会把性能拖死；但关键边界必须写。我要持久化 run/turn start、model response、tool intent、permission decision、副作用前后、artifact commit、verification 和 compact boundary。低风险 streaming token 可以批量或异步，因为丢一点展示文本影响有限；但工具副作用前后必须同步，因为这决定能不能恢复、能不能避免重复执行。checkpoint 频率取决于恢复损失和性能成本，不是越密越好。

面试官：外部 API 写操作怎么保证幂等？第二层追问：对方系统不支持幂等键怎么办？

我：外部 API 写操作要优先用 idempotency key、external request id、transaction 和 read-after-write。但现实是，不是所有系统都支持幂等键。如果不支持，我会提高风险等级：执行前人工审批，记录自然键，比如目标 ticket、收件人、金额或资源 id；执行后立即查询确认；无法确认的操作标记为不可自动重试，需要人工恢复或补偿流程。比如创建 ticket 失败时，不能盲目再创建一次，否则可能出现两个重复 ticket。

面试官：恢复后权限还有效吗？第二层追问：昨天用户批准的 shell 今天还能跑吗？

我：默认不能简单沿用昨天的权限。权限决定要带 scope、expiresAt、session id、workspace hash、command/resource pattern、tool version 和 permission mode。昨天用户批准跑一次 shell，不代表今天 workspace 已经变了以后还能继续跑同一个命令。Resume 时如果用户、时间、工具版本、权限模式、workspace hash 或资源范围变化，就要重新确认。长期 allow 必须是明确产品语义，有作用域和过期时间，而不是恢复时自动继承旧批准。

面试官：工作区变了怎么恢复？第二层追问：用户手动改了文件怎么办？

我：恢复时不能假设 Agent 仍然拥有旧事实。Session 要记录 workspace snapshot、base revision、dirty diff、active files 和最近修改范围。恢复时先扫描当前工作区是否和记录一致；如果用户手动改了 Agent 正在 patch 的文件，不重新读就很容易覆盖用户修改。处理方式可以是 re-read、rebase、merge、fork，或者暂停问用户。coding agent 可靠性很大一部分就在这里：模型记得的代码和磁盘上的代码不是一回事。

面试官：用户中断和系统崩溃有什么区别？第二层追问：取消会不会留下坏状态？

我：用户中断和系统崩溃不一样。用户中断是有意图的 lifecycle event，可以选择 drain 到当前安全边界；系统崩溃是非预期故障，只能从最后 durable facts 恢复。取消时要 abort provider stream，给工具 abort signal，写 cancelled marker，保存 partial artifact，并记录已经发生的副作用。不能因为用户点取消就删除历史，也不能伪装成 completed 或 failed。比如文件已经写了一半，取消只是停止继续做，不代表副作用自动消失。

面试官：可靠性怎么评测？第二层追问：怎么制造故障？

我：可靠性不是看 happy path，而是故意把系统打断。我要做 fault injection eval，在 model call、tool before/after、artifact write、permission wait、compact、verification、worker shutdown 这些点注入 timeout、crash、duplicate events、corrupted tail、permission delay。指标看 recovery success rate、duplicate side effect count、invalid tool pair count、manual rescue rate、data loss window 和 replay completeness。正常路径全过只能说明天气好时能开，不能证明系统可靠。

面试官：事件日志如果尾部损坏怎么办？第二层追问：append-only 也可能写一半，你怎么恢复？

我：append-only 不等于永远正确，尾部也可能写一半。每条事件要有 schemaVersion、sequence/revision、idempotency key、payload hash，最好还有 previous hash。读取时如果发现 JSONL 半行、hash 不连续、revision 缺口，我会先找最长合法前缀，把坏尾部隔离成 corruption artifact，并把 session 标为 degraded。接下来需要 host repair 或 human confirmation，不能静默跳过坏事件继续跑。否则所谓事实源自己都不可信，replay 就失去意义。

面试官：Hosted worker 重启或重复领取同一个 job 怎么办？第二层追问：怎么避免两个 worker 同时操作同一 workspace？

我：Hosted harness 不能假设只有一个进程在跑。Worker 领取 job 时要拿 job lease 和 fencing token，靠 heartbeat 续约；写 event、artifact、workspace 前都检查 token 是否仍有效，并带 expected revision。Workspace 也要有 session-level lock 或 isolated checkout。Lease 过期后新 worker 可以接管，但旧 worker 如果迟到继续写入，会被 fencing token 或 expected revision 拒绝。这样即使重启、网络抖动、重复领取 job，也不会出现两个 worker 同时改同一工作区。

面试官：模型流式输出到一半断了怎么办？第二层追问：半个 tool call 已经出来了，要执行吗？

我：半个 tool call 不能执行。Streaming delta 先进入 assembler，只有完整、schema 合法、finish reason 合法的 ToolIntent 才能进入 pipeline。中断时记录 model_request_started、partial_delta refs 和 interrupted marker，但 conversation view 不暴露半成品 tool call。恢复时可以重新请求模型、让用户选择 retry，或者把中断作为受控 error observation。不能把半截 JSON 当真实意图，就像电话里只听到“请转账给...”就断线了，不能自己补全收款人去执行。

面试官：Artifact 丢了或 hash 对不上怎么办？第二层追问：event 里只有 artifact ref，完整日志没了还能恢复吗？

我：如果 artifact 丢了或 hash 对不上，不能假装完整日志还在。artifact ref 必须带 hash、size、mime、createdAt 和 privacy tag。恢复时先校验 artifact 可读和 hash；如果丢失，session 进入 degraded replay，模型可见 view 只能用 event 里的 bounded preview。关键 artifact 要做复制、retention policy 和完整性扫描。丢失本身要写 incident event，并影响 eval 和恢复结果。否则 event 里写“详见附件”，但附件没了，系统还装作证据完整，这是很危险的。

面试官：Context compaction 过程中崩了怎么办？第二层追问：summary 写一半，会不会污染后续恢复？

我：Summary 没提交前不能成为事实。Compaction 要有事务边界：先写 compaction_started，生成 summary 和 source refs 后写 compaction_candidate，校验目标、约束、source refs、未闭合 tool round 都没丢，才写 compaction_committed。恢复时如果只看到 started 或 candidate，就不能使用这个 summary，要回到压缩前事件路径，或者重新 compaction。summary 是 projection，不是历史本身，所以 compaction 崩了不能覆盖原始事件。

面试官：恢复时 secret vault 不可用怎么办？第二层追问：任务要继续，但工具需要密钥，你怎么处理？

我：安全优先，不能为了恢复任务，从旧 trace 或旧 env 里把 secret 捞回来。Resume 时 secret capability 要重新向 vault 获取，runtime 校验用户、租户、工具和用途；获取失败就把相关工具标 unavailable，plan 进入 blocked 或 partial mode。可以继续做不需要 secret 的只读诊断，比如读本地日志、整理现有 artifact；涉及外部 API 的步骤要等待 vault、请求用户重新授权或切换替代路径。event log 只记录访问决策和脱敏状态，不记录 secret 原值。

面试官：任务卡在人工审批上怎么办？第二层追问：用户一天后才批准，原来的上下文还能用吗？

我：任务卡在人工审批上，也要当成 durable lifecycle state。pending approval event 要带 request id、scope、expiresAt、risk summary 和 current plan revision。用户一天后批准，不代表旧动作还能直接执行；批准只是新的恢复输入，不是绕过安全检查。执行前要重新跑 resume gate：检查 workspace、permissions、tool version、external state 和 plan validity。过期审批要重新发起。比如昨天批准改配置，今天生产环境已经变了，就不能按昨天的 proposal 直接执行。

面试官：事件 schema 升级后，旧 session 怎么恢复？第二层追问：你会迁移历史事件吗？

我：历史事件默认不改写，因为 event log 是审计事实。每个 event 带 schemaVersion，读取和 replay 时用 upcaster 转成 current view；破坏性变更走新 major version 和兼容期。必要时可以生成新的 projection 或 migration artifact，但原始 event log 保持不可变。Conformance tests 要覆盖旧 session fixture，确保升级后旧任务还能 replay。否则系统版本一升级，历史恢复就坏了，可靠性只在当前版本里成立，不算真正可靠。

面试官：可靠性 MVP 先做什么？第二层追问：哪些高级能力先不做？

我：可靠性 MVP 先保护事实和副作用。我要先做 append-only event store、artifact refs、tool lifecycle markers、resume gate、diagnostic replay、basic fork 和 fault injection tests。先不做跨设备同步、多人协作、复杂 workflow engine、自动补偿市场、全量搜索和 RL 数据飞轮。第一版目标很朴素：单 Agent 长任务能恢复、能解释、不会重复危险副作用。只要这个底座不稳，后面加 memory、多 Agent 或复杂调度，都会把恢复问题放大。