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