是否记录了执行进度与中断恢复点

1️⃣ 考察意图

面试官想考察你对长任务 Agent 的工程化落地能力，而非单纯背概念。刁钻点在于：多数候选人只提“用数据库存状态”，但无法说清中断恢复的粒度（是步骤级还是函数级？）、幂等性如何保证（重放时副作用怎么处理？）、以及恢复点与上下文窗口的冲突（恢复时历史太长导致 token 溢出）。答好了能展示你设计过生产级 Agent 系统，熟悉状态机、checkpoint 与容错模式。

2️⃣ 标准答

执行进度与中断恢复是 Agent 从 demo 走向生产的核心能力。我从三个层面展开：记录粒度、恢复机制、工程陷阱。

1. 记录粒度：从日志到状态机

粗粒度（步骤级）：用 JSON 或数据库记录当前步骤 ID（如 step_3_of_5）和输入输出。适合简单链式 Agent（如 LangGraph 的 StateGraph）。
细粒度（函数级）：对每个工具调用、LLM 推理、条件分支都记录。用状态机（如 transitions 库或自定义 FSM）管理状态转换。例如：IDLE → TOOL_CALLING → WAITING_RESULT → CONDITION_CHECK → FINISHED。
中间结果缓存：对工具调用结果（如 API 返回的 JSON）做 key-value 存储，key 为 {session_id}_{step_id}，value 为序列化结果。避免恢复时重复调用外部服务。

2. 恢复机制：Checkpoint + 幂等性

Checkpoint 设计：在每个“不可逆操作”前保存快照。不可逆操作包括：发送邮件、扣费、写入数据库。快照内容：当前状态机状态、已执行步骤列表、所有中间结果、LLM 对话历史（截断到最近 N 轮）。存储选型：Redis（低延迟，适合高频 checkpoint）或 PostgreSQL（强一致性，适合金融场景）。
幂等性保证：恢复时可能重放步骤。每个工具调用需有唯一 request_id（UUID），服务端去重。例如：调用支付 API 时传入 idempotency_key，若 key 已处理则返回原结果。对 LLM 调用，用 seed + temperature=0 保证相同输入输出一致（但非绝对，需配合结果校验）。
恢复流程：检测到中断 → 加载最新 checkpoint → 从断点步骤开始重放（跳过已缓存结果的步骤）→ 恢复上下文窗口（截断历史但保留关键状态）。

3. 实际落地的坑与解法

坑 1：上下文窗口溢出。恢复时加载了全部历史，导致 LLM 输入超长。解法：用滑动窗口 + 摘要压缩。只保留最近 5 轮对话，更早的历史用 LLM 生成摘要（如“用户已确认订单信息，等待支付”）。
坑 2：状态不一致。Redis 中 checkpoint 写了一半进程崩溃。解法：用 Redis 的 MULTI/EXEC 事务或 WATCH 乐观锁，保证原子性。或改用 PostgreSQL 的 BEGIN/COMMIT。
坑 3：重放副作用。恢复时重新调用了“发送通知”API，用户收到重复短信。解法：将“副作用操作”标记为 EXTERNAL 类型，恢复时跳过，仅重放纯计算步骤。或使用事件溯源（Event Sourcing），记录事件日志而非状态快照，恢复时重放事件但过滤掉已提交的外部操作。

工程取舍：细粒度 checkpoint 增加 I/O 开销（每次 LLM 调用都写 Redis 会拖慢 20-30ms），粗粒度则恢复时可能丢失上下文。折中方案：每 3 个步骤或每 30 秒写一次 checkpoint，同时用 WAL（Write-Ahead Log）记录增量变更。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从记录粒度、恢复机制、工程陷阱三个层面回答。记录粒度上，我区分步骤级和函数级，用状态机管理转换，并缓存中间结果。恢复机制上，我在不可逆操作前设 checkpoint，用幂等性 key 保证重放安全。工程陷阱上，我处理了上下文溢出（滑动窗口+摘要）、状态不一致（事务写入）、重放副作用（跳过外部操作）。总结一句：没有 checkpoint 的 Agent 是玩具，生产级系统必须做到步骤级可恢复。”

4️⃣ 高频追问 & 应对

追问 1：如果 Agent 在调用外部 API 时超时了，你怎么区分是网络问题还是 API 本身挂了？

用重试策略 + 超时阈值区分。第一次超时后，等待 1 秒重试（指数退避，base=1s, max=10s）。若连续 3 次超时，记录为 API_UNAVAILABLE 状态，切换备用 API 或降级方案（如用缓存结果）。同时，在 checkpoint 中记录 last_api_call_status，恢复时跳过已超时的步骤，直接重试。关键：不要将超时视为永久失败，要留出重试窗口。

追问 2：你的 checkpoint 存储用 Redis，如果 Redis 宕机了怎么办？

采用主从 + 持久化双保险。Redis 开启 AOF（Append Only File）和 RDB 快照，主节点宕机时从节点自动切换。但更关键的是：checkpoint 数据不是唯一真相，它只是加速恢复。真正的“最终状态”应由下游系统（如数据库）保证。例如：Agent 执行“下单”后，订单状态已写入 MySQL，即使 Redis 丢失，恢复时从 MySQL 读取订单状态即可跳过该步骤。这叫“外部化状态”，避免单点依赖。

追问 3：你的恢复点保存了 LLM 对话历史，但恢复时历史太长导致 token 超限，怎么处理？

用分层压缩策略。第一层：保留最近 3 轮完整对话（原始格式）。第二层：更早的历史用 LLM 生成摘要（如“用户已确认商品信息”），摘要作为系统提示的一部分。第三层：如果摘要也超限，只保留关键状态（如 confirmed_items: [item1, item2]）和最后一条用户消息。恢复时，先尝试加载完整历史，若超限则回退到摘要模式。注意：摘要会丢失细节，所以对需要精确回溯的场景（如法律咨询），应优先扩展上下文窗口（如用 128K 模型）。

5️⃣ 避坑 · 常见错误答法

❌ “用数据库记录每一步的输入输出就行，恢复时重放所有步骤。” → ✅ 重放所有步骤会导致重复调用外部 API（如重复发邮件），必须设计幂等性 key 或跳过副作用步骤。同时，重放全部步骤可能超时，应只重放从断点开始的步骤。
❌ “我每步都写 checkpoint，保证不丢数据。” → ✅ 每步都写会引入大量 I/O 开销（尤其是 LLM 调用频繁时），应权衡粒度。推荐每 N 步或每 T 秒写一次，配合 WAL 记录增量变更。
❌ “恢复时直接加载全部历史，LLM 会自动处理。” → ✅ LLM 上下文窗口有限，历史过长会导致性能下降或截断。必须主动管理历史长度，用滑动窗口或摘要压缩。

6️⃣ 简历呼应

如果你有 RAG 项目：从“多轮对话 Agent 的上下文管理”切入，说明你如何用 checkpoint 保存检索结果缓存，避免恢复时重复检索。强调你处理过 token 超限问题（如用滑动窗口）。
如果你只做过传统后端：用“分布式事务的 Saga 模式”类比，说明 Agent 的 checkpoint 类似 Saga 的补偿操作。强调你对幂等性和状态一致性的理解（如用 idempotency_key）。
如果你是校招无项目：聚焦论文复现，如 ReAct 论文中的“轨迹记录”与 checkpoint 的相似性。或展示你实现过一个简单的状态机 demo（如用 Python enum 管理 Agent 状态），并讨论过恢复点设计。
《ReAct: Synergizing Reasoning and Acting in Language Models》（论文，提出轨迹记录与状态管理）
《LangGraph: Stateful Orchestration for LLM Agents》（框架，内置 checkpoint 机制）
《Building Production-Ready LLM Agents》（博客，讨论幂等性与重试策略）
《Redis Transactions and Checkpointing》（官方文档，事务与持久化）
《Event Sourcing Pattern》（Martin Fowler 博客，事件溯源用于状态恢复）

—— 本场面试完 ——