字节跳动 AI应用开发实习 一面：Agent Loop 的失败恢复与长期记忆

《面试题目》

1. 简单做个自我介绍，你平常都是怎么学习的？
2. 假设你做的是一个短视频创作 Agent，这几个模块里你觉得哪个对你挑战最大？
3. 你们团队如何做的技术选型？
4. 如果 Agent Loop 中某个工具超时或者执行到一半失败，怎么保证整个任务不会失控？
5. 怎么定义短期和长期记忆？
6. Memory 和工具调用，你觉得这两个哪个比较难做？展开说一下。
7. 长期记忆应该在什么时机写入？是不是每轮对话结束都总结一次？
8. 你们是怎么评估你们的记忆是否正确、有效的？
9. 你说的是经典的 Agent Loop 实现吧，它其实也有很多开源实现，你们觉得你们实现的和这些有什么特殊点吗？
10. 如果长期记忆已经有上百万条，召回链路你会怎么设计？

《参考解析》

短视频创作 Agent 最难的模块通常不是「生成」，而是「一致性 + 可编辑」。 一条视频要经过脚本、分镜、素材检索、画面生成、配音配乐、剪辑合成多个环节，任何一环的风格漂移都会让成片不可用：同一个角色在不同镜头里长相变了、字幕和口播对不上、背景音乐压过人声。生成模型只能保证单帧或单段的质量，工程上要靠角色设定、参考图、种子、风格提示词和统一的素材库来约束一致性；剪辑侧则要把每一步做成可回滚的时间线操作，让用户能改一句台词而不必整条重生成。判断哪个模块挑战最大，要看你衡量的失败成本：生成失败可以重试，一致性崩了和不可编辑会让整个产品无法交付。

技术选型要按约束排序，而不是按榜单选模型。 先列清楚延迟、成本、可控性、合规、团队维护能力这几条硬约束，再决定哪些环节自研、哪些用现成框架。通用执行骨架可以用开源方案，真正要自己做的是业务状态机、工具 schema、权限与审计、以及评测集；模型侧可以按任务分流，简单分类走小模型，生成和规划走大模型，失败再升级，不要把全部请求压在最贵的模型上。选型还要留出可观测性和回滚能力，否则上线后连「哪一步变差了」都说不清。

Agent Loop 不能写成无限 while，核心是预算、错误分类和可恢复状态。 每次任务要有最大步数、token 预算和墙钟超时，工具执行器再单独设超时与重试；网络抖动这类瞬时错误可以指数退避，参数非法、权限不足这类确定性错误不该重试，而是把结构化错误回给 Planner 让它改计划。有副作用的工具必须幂等，例如创建任务时由客户端生成幂等键，服务端按 key 去重，避免「第一次成功但响应超时」导致重复创建。长链路要把状态持久化，记录当前步骤、待执行的工具、已完成的结果和失败原因，恢复时从状态继续，而不是把整段对话再丢给模型让它猜「刚刚做到哪」。

短期记忆和长期记忆应按生命周期、作用域和任务耦合度划分，而不是按保存时长。 短期记忆更像工作内存，服务当前会话或当前任务：用户刚改的风格、当前脚本版本、正在等待哪个工具返回，任务结束就可以丢。长期记忆要跨会话复用：稳定的语言偏好、品牌规范、项目背景、历史决策和验证过的操作经验，这类信息应该脱离上下文窗口持久化。还有一类容易被混淆的是情景记忆，比如「上次用户最终选了第二版脚本」，它是历史事件，不应该直接变成永久偏好；长期记忆系统的重要一步是从事件里提取稳定事实，而不是把聊天记录原样塞进向量库。

工具调用和记忆的难点不在一个维度：前者是可靠性工程，后者是长期数据治理。 工具调用直接连接真实系统，涉及参数校验、权限、超时、重试、幂等和副作用，一次错误可能真的创建资源、删除数据或产生费用，但成功与否通常可判定。记忆的难点是「值不值得存、三个月后还能不能用、召回出来有没有帮助」没有天然标准答案，而且错误会累积：一条错误的用户偏好被保存后，可能在后续几十次对话里持续影响模型，模型还会把它当成可信上下文。所以记忆系统要同时解决写入准确性、冲突处理、版本管理、召回质量、遗忘机制和在线效果评测。

记忆写入要经过候选、过滤、去重与冲突消解，不能每轮总结一次就落库。 每轮都写很快会把记忆库变成垃圾场。比较合理的流水线是：先从对话里抽取候选事实，再判断稳定性、未来复用价值、置信度和敏感程度，例如「今天有点累」没有长期价值，「这个项目统一用 pnpm」对 Coding Agent 就值得保存；然后做去重和冲突检测，如果已有「项目使用 Python 3.10」，后来又得到「已升级到 3.12」，正确做法不是保存两条同权重事实，而是记录版本、生效时间和来源，把旧事实标记为已失效。LLM 可以参与抽取，但最终写入策略最好由确定性规则和元数据共同约束。写入之后还要评估，而且要把「正确」和「有效」分开：正确性看保存内容是否忠实于原始信息，比如用户说「不吃辣」，记忆却总结成「喜欢清淡饮食」，语义已经扩张；可以用人工标注或 LLM Judge 评事实一致性、作用域和时效性。有效性看这条记忆有没有改善最终任务，最直接的是做消融：同一批任务分别开启和关闭记忆，比较任务完成率、人工修改次数、模型调用次数和输出质量。还要看负收益，记忆不是召回越多越好，错误或不相关的记忆会污染上下文，线上要同时观察记忆命中率、使用率、任务成功率变化、坏记忆率和 token 开销；命中率高但成功率没涨，说明只是「找到了很多东西」。

开源 ReAct Loop 本身没有壁垒，壁垒在约束、可靠性和可评估性。 LangChain、LangGraph、AutoGen 这类框架提供的是通用执行骨架，业务真正要解决的是：哪些步骤可以重新规划、哪些完成后不能重复执行、工具参数如何做 schema 校验、高风险操作何时必须人工确认。把 Planning 和 Execution 分离，Planner 可以改后续计划，Executor 只能执行经过校验的动作；再配一条完整的 Trace，把用户请求、规划决策、记忆召回、提示词、模型输出、工具参数、工具结果和状态迁移串起来，才能回答一次失败到底是模型规划错了、记忆召回错了，还是工具本身失败。

百万级记忆召回不能只做一次 Embedding Top-K。 查询进来先做 query understanding，抽取用户、项目、实体、时间和意图，再用 metadata 缩小搜索空间；召回层同时跑稠密向量和稀疏检索，各自取 Top-K 后融合去重，然后按时间、来源可信度、使用频率和任务相关性重排。对超长历史可以做分层摘要，原始事件留在冷存储，稳定事实进热索引；高频查询走缓存，冷门查询走完整链路。评测既看召回层（正确记忆是否进 Top-K），也看端到端（任务成功率、引用正确率、token 开销），否则召回指标好看但答案没用。