字节抖音研发一面：Agent 执行范式与缓存恢复
本场面试题
- ReAct 与 Plan-Execute-Replan 有什么区别？
- 更新数据时缓存刷新失败，应该如何恢复？
面经与参考答法
字节抖音研发一面：Agent 执行范式与缓存恢复
字节抖音研发方向的一面记录；具体岗位名称和面试年月未注明。反问中的业务描述与内部资金安全有关，以下选录执行范式与缓存故障两组。
以下短答、详解和示例均为编辑教学补充，不代表候选人现场回答、实际项目实现或企业标准答案。
（1）ReAct 与 Plan-Execute-Replan 有什么区别？
ReAct 每次结合工具观察决定下一步；Plan-Execute-Replan 显式保存一份分步计划，执行后根据结果更新剩余计划。前者适合路径需要探索的任务，后者便于管理较长的依赖链；两者都要有结果校验、进度状态和停止条件，也可以组合使用。
详解
两种方案的区别在决策节奏。ReAct 的一次循环可以概括为“选择行动→执行工具→读取观察→继续或结束”。计划模式则把目标拆为有依赖的子任务，执行器完成其中一步或一组，再由重规划器判断哪些目标已经完成、哪些需要补做。重规划不应无条件清空已经验证过的成果。ReAct 论文与LangChain 的规划架构示例分别说明了这两种组织方式。
以“比较两个产品的当前保修政策”为教学例子：可以先规划“读取两份官方政策、统一适用地区、比较条款”；如果其中一个页面显示地区不匹配，就调整这个子任务。执行某一步时，也可以用一个小的 ReAct 循环寻找合适页面，因此两种范式并不互斥。
显式计划有利于检查依赖和未完成项，却增加了计划维护及重规划开销；每步动态决策更灵活，却可能反复试同一动作。可用相同任务、模型和总预算比较成功率、重复工具次数、时延与成本，不能仅凭范式名称判断谁更省。运行时保留行动、观察和安全处理后的状态即可，不把输出详细隐藏思维链当作协议要求。
（2）更新数据时缓存刷新失败，应该如何恢复？
假设数据库保存权威数据、缓存采用旁路模式，可在提交数据后失效缓存，并把失效失败留在可恢复的补偿记录中重试。TTL 能限制某个缓存副本的寿命，但无法独自解决晚回填或跨系统写入窗口；要求读取最新事实的操作应走权威数据校验。
详解
先看一次具体失败：数据库已从 v1 提交为 v2，删除缓存的请求却超时。此时“业务写入失败”和“缓存失效未确认”是两个状态，不能因为删缓存报错，就直接重做已经提交的业务操作。旁路缓存的基本写路径是更新数据源后失效缓存，但它本身没有跨数据库与缓存的一致性保证。Microsoft 的 Cache-Aside 说明明确保留了这个窗口。
一种可恢复设计是在同一数据库事务里写业务变更和 outbox 失效事件，提交后由消费者按键删除缓存；消费者成功后记账，失败就按退避策略继续，超过期限告警。删除同一缓存键可以安全重复，事件仍要带业务 ID 和版本，避免乱序更新把较新的缓存覆盖成旧值。outbox 解决的是“变更已提交但通知丢失”的可恢复性，不能让两个存储瞬间同步。AWS outbox 模式也要求处理重复投递。
还要检查读路径：一个慢请求先读到 v1，等 v2 提交并失效缓存后才回填，就可能重新写入旧值。可按业务使用版本化键、受控回填或版本校验，并监控补偿积压、旧值年龄与缓存重建压力。TTL 应按允许的旧值窗口选择；若旧请求迟到回填重新获得 TTL，它并不能给“从数据库更新时刻起”的旧值时长作绝对保证。