百度

Go 后端开发工程师(Agent)一面面经

完整信息

48 条问法 · 48 道题

本篇目录
Q1:请先做一下自我介绍。 Q2:你们的自动化红队 Agent 主要是做什么的? Q3:这个 Agent 的核心架构是什么样的?有没有记忆、上下文管理、压缩之类的设计? Q4:SessionMessage 具体会保存哪些内容? Q5:SessionMessage 会持久化吗? Q6:如果 Session 中断,重新启动之后,怎么恢复上下文? Q7:Transcript 中会不会只保存原始消息,而不保存压缩后的摘要?如果恢复时重新加载全部原始消息,不还是会遇到上下文过长的问题吗? Q8:所以 SessionMessage 本质上只是“当前模型可见的上下文窗口”,所有完整内容都保存在 Transcript,对吗? Q9:TodoStore 是做什么的? Q10:如果 Agent 忘记更新 TodoStore 怎么办? Q11:TodoStore 的提醒机制一般设置多少轮触发? Q12:为什么设置为 5 轮?你们有统计过一个任务平均会调用多少轮工具吗? Q13:如果让你重新负责这个参数,你会怎么确定这个轮数,而不是拍脑袋设置? Q14:为什么你会选择中位数,而不是平均数或者其他指标? Q15:LongTermMemory 是做什么的? Q16:长期记忆是怎么匹配的?用了向量数据库吗? Q17:如果用户之前说“我喜欢简短回答”,后来又说“我喜欢详细回答”,两条长期记忆发生冲突怎么办? Q18:你们这个系统是单 Agent 还是多 Agent? Q19:什么情况下应该设计成一个独立 Agent,什么情况下应该只是普通工具调用? Q20:Reason Agent 本身会调用哪些工具? Q21:Graph 是一个 Agent 吗? Q22:为什么“场上有没有未领取的 Intent、有没有新 Fact”这种事情不用 Agent 判断,而是由后端判断? Q23:你们这里的 Intent 本质上是传统意义上的“用户意图识别”吗? Q24:Reason 和 Worker 两个 Agent 之间怎么传递信息? Q25:所以整个流程其实是:Agent 执行完成后把结果写回后端,后端根据状态再调用下一个 Agent,对吗? Q26:Agent 的输出格式有要求吗?后端会不会做校验? Q27:如果 Agent 输出格式校验失败,会让 Agent 把整个任务重新执行一遍吗? Q28:你们做上下文压缩了吗?具体是怎么做的? Q29:进行全量摘要压缩时,最近保留的 8 条消息也会参与摘要吗? Q30:如果最近保留的 8 条消息本身就已经超过上下文窗口怎么办? Q31:你们对 Agent 做权限控制了吗?具体怎么做? Q32:SessionMessage 存在内存中。如果以后部署成多个 Pod,怎么保证同一个用户一直访问到保存了自己 Session 的那台机器? Q33:如果根据用户 ID 对实例数量取模,但服务需要动态扩缩容,实例数量发生变化后,不就会导致大量用户重新映射到其他机器吗? Q34:一致性哈希具体是怎么实现的? Q35:Agent 每次迭代之后,怎么证明新版本真的比旧版本更好? Q36:靶场得分、任务成功率这些都是结果指标,那过程指标怎么评价?例如 Token 消耗、工具调用是否合理、Skill 是否正确调用、执行路径有没有跑偏。 Q37:谁来判断 Agent 的执行路径有没有问题?如果有一万条 Case,总不能全部由人工评估吧? Q38:如果使用另一个 Agent / LLM Judge 来评测,那么评测 Agent 的 Prompt 应该怎么设计? Q39:如果有一万个不同 Case,总不能人工为每个 Case 单独写一个 Prompt,评测 Prompt 怎么做通用化? Q40:最开始怎么自动发现 Agent 执行过程中存在的问题?如果是 ToC 产品,每天有上万甚至几万条任务,不可能全部再跑一次大模型分析,否则成本会翻倍。 Q41:你现在大几? Q42:你是什么时候开始这段实习的? Q43:简历上为什么只写了大约三个月的实习经历? Q44:开学之后还能继续实习吗?最长能实习多久? Q45:你现在在哪个城市?学校在哪里? Q46:现在设计一个点赞功能。先从数据库开始,你觉得需要设计哪些表?每张表有什么作用?有哪些字段? Q47:如果一次点赞需要同时更新“点赞关系表”和“直播点赞数量”,两个表中一个更新失败怎么办? Q48:如果是一个特别火的直播,上万人同时点赞,所有事务都竞争同一条直播记录的行锁,会出现什么问题?怎么解决? Q49:如果平台有上万个直播间,即使批量更新,每秒仍然可能产生大量数据库写请求,怎么办? Q50:点赞关系中间表数据量会非常大,需要分表。你准备按照什么字段进行分表? Q51:为什么选择按照直播 ID 分表? Q52:如果现在增加一个功能:“查看某个用户给哪些直播点过赞”,但你之前是按照 live_id 分表的,这个查询要怎么做? Q53:你平时更喜欢后端,还是更喜欢 Agent? ps:无敌了,答的不怎么好,追问一问就傻,但是秒约二面了,真得给面试官磕一个了
本篇目录
  1. 01
  2. 02
  3. 03
  4. 04
  5. 05
  6. 06
    追问
    Transcript 中会不会只保存原始消息,而不保存压缩后的摘要?如果恢复时重新加载全部原始消息,不还是会遇到上下文过长的问题吗?
    上一问 ↑
  7. 07
    追问
    所以 SessionMessage 本质上只是“当前模型可见的上下文窗口”,所有完整内容都保存在 Transcript,对吗?
    上一问 ↑
  8. 08
  9. 09
  10. 10
    追问
    TodoStore 的提醒机制一般设置多少轮触发? > Q12:为什么设置为 5 轮?你们有统计过一个任务平均会调用多少轮工具吗? > Q13:如果让你重新负责这个参数,你会怎么确定这个轮数,而不是拍脑袋设置?
    上一问 ↑
  11. 11
  12. 12
  13. 13
  14. 14
    追问
    如果用户之前说“我喜欢简短回答”,后来又说“我喜欢详细回答”,两条长期记忆发生冲突怎么办?
    上一问 ↑
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
    项目追问
    为什么“场上有没有未领取的 Intent、有没有新 Fact”这种事情不用 Agent 判断,而是由后端判断?
    上一问 ↑
  20. 20
  21. 21
  22. 22
    追问
    所以整个流程其实是:Agent 执行完成后把结果写回后端,后端根据状态再调用下一个 Agent,对吗?
    上一问 ↑
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
    SessionMessage 存在内存中。如果以后部署成多个 Pod,怎么保证同一个用户一直访问到保存了自己 Session 的那台机器?
  30. 30
    追问
    如果根据用户 ID 对实例数量取模,但服务需要动态扩缩容,实例数量发生变化后,不就会导致大量用户重新映射到其他机器吗?
    上一问 ↑
  31. 31
  32. 32
  33. 33
    追问
    靶场得分、任务成功率这些都是结果指标,那过程指标怎么评价?例如 Token 消耗、工具调用是否合理、Skill 是否正确调用、执行路径有没有跑偏。
    上一问 ↑
  34. 34
  35. 35
  36. 36
    追问
    如果有一万个不同 Case,总不能人工为每个 Case 单独写一个 Prompt,评测 Prompt 怎么做通用化?
    上一问 ↑
  37. 37
    追问
    最开始怎么自动发现 Agent 执行过程中存在的问题?如果是 ToC 产品,每天有上万甚至几万条任务,不可能全部再跑一次大模型分析,否则成本会翻倍。
    上一问 ↑
  38. 38
  39. 39
    你是什么时候开始这段实习的? > Q43:简历上为什么只写了大约三个月的实习经历?
  40. 40
  41. 41
  42. 42
    现在设计一个点赞功能。先从数据库开始,你觉得需要设计哪些表?每张表有什么作用?有哪些字段?
  43. 43
    追问
    如果一次点赞需要同时更新“点赞关系表”和“直播点赞数量”,两个表中一个更新失败怎么办?
    上一问 ↑
  44. 44
    追问
    如果是一个特别火的直播,上万人同时点赞,所有事务都竞争同一条直播记录的行锁,会出现什么问题?怎么解决?
    上一问 ↑
  45. 45
  46. 46
    追问
    点赞关系中间表数据量会非常大,需要分表。你准备按照什么字段进行分表? > Q51:为什么选择按照直播 ID 分表?
    上一问 ↑
  47. 47
    追问
    如果现在增加一个功能:“查看某个用户给哪些直播点过赞”,但你之前是按照 live_id 分表的,这个查询要怎么做?
    上一问 ↑
  48. 48

相关公司