可中断的 Agent 系统如何设计，怎样保存执行状态、恢复任务并处理用户打断？｜美团后端开发面经解析

60 秒回答模板

可中断 Agent 我会设计成任务状态机，而不是把整段执行放在一个不可恢复的内存协程里。每个任务有 task id、当前计划、步骤游标、上下文摘要、工具调用记录、用户约束、预算和版本号；每完成关键步骤就写 checkpoint。用户打断时先定义语义：暂停、取消、改目标、追加约束还是人工接管。暂停只冻结状态，取消要终止后续调度并处理正在运行的工具，改目标则基于现有状态重规划。恢复时从最近一致 checkpoint 读取状态，校验幂等键和工具副作用，跳过已完成步骤，必要时补偿或重新执行可重试步骤。

考点 先设计状态机

难度 真实面经题

回答目标 让面试官相信你能从后端任务系统角度设计可恢复、可取消、可审计的 Agent 执行引擎。

深入解析

状态模型

任务状态至少包含 pending、running、pausing、paused、resuming、canceling、canceled、completed、failed。状态迁移要由调度器统一控制，避免用户打断、工具回调和超时处理同时修改同一个任务造成乱序。

Checkpoint

Checkpoint 要保存计划、当前步骤、已完成工具调用、关键中间结果、上下文摘要、用户新增约束和执行预算。保存粒度不能太粗，否则恢复时要重跑很多副作用；也不能把全部上下文原样堆进去，否则成本高且容易污染。

打断语义

用户说停一下、换个目标、不要发了、补充一个条件，语义不同。系统要把打断分类为暂停、取消、修改计划、追加约束或审批拒绝。不同语义对应不同状态迁移，不能简单 kill 当前流程。

工具幂等

恢复设计最怕重复执行副作用工具。每次工具调用要有 idempotency key、调用状态和外部结果引用。读操作可重试，写操作要确认是否已生效，必要时通过查询、补偿或人工确认处理不确定状态。

恢复策略

恢复时先加载最近 checkpoint，校验任务版本和用户最新约束，再判断当前步骤是否已完成、可重试或需要重规划。对于长时间暂停后的任务，还要检查外部数据是否过期、权限是否变化、工具结果是否仍有效。

并发与观测

后端需要任务锁、乐观版本号、队列重试、超时扫描和 dead-letter 处理。观测上记录状态迁移、checkpoint 写入、恢复耗时、重复执行拦截、取消成功率和用户打断后的任务完成率。

易错点

把中断理解成前端停止展示，后端任务仍继续跑。
只保存对话文本，不保存计划、步骤游标、工具结果和版本号。
恢复时重复执行副作用工具，没有幂等键和外部结果确认。
没有区分暂停、取消、改目标和追加约束，导致状态语义混乱。

面试官追问

Checkpoint 保存全量上下文还是增量？

通常保存结构化状态和必要摘要，全量原始 trace 可以放日志或对象存储。恢复路径需要的是可执行状态，不是每个 token。关键字段要结构化，便于校验、迁移和调试。

用户取消时正在执行的工具怎么办？

如果工具支持取消，发送取消请求并记录结果；不支持取消时要标记任务 canceling，等回调返回后决定忽略、补偿或提示已生效。副作用工具尤其要有查询和补偿方案。

如何处理恢复后的上下文变化？

恢复时要重新校验权限、外部资源版本、时间敏感数据和用户新增约束。如果变化影响计划，应触发重规划，而不是盲目从旧步骤继续。

任务锁用 Redis 还是数据库？

可以组合使用：Redis 适合短期执行锁和心跳，数据库适合持久状态、版本号和审计。核心是保证状态更新原子性，并能在 worker 崩溃后由扫描器恢复。