作业帮 Golang 一二面：Agent 上下文、MiniCode 与 Feed 系统

《面试题目》

一面·实习

1. 实习中做的是对话 Agent 吗？上下文管理和上下文压缩是怎么实现的？
2. 长期记忆是自己实现的，还是调用外部接口？
3. 实习项目里哪些工作比较有挑战？
4. 用户输入敏感内容后，模型接口会报错、不返回回复吗？后来怎么解决的？
5. 自己搭建的安全护栏怎么实现？只是敏感词过滤，还是还有其他机制？
6. 大模型微调训练是你自己负责的吗？
7. 从 MySQL 迁移到 PostgreSQL，怎么保证服务一致性、不发生故障？
8. 服务还在运行时，怎么完成无缝迁移和切换？
9. 迁移过程中查询历史数据怎么处理？怎么知道哪些数据已迁移、哪些还没有？
10. 新旧数据库之间如何兼容？请求具体怎么路由？
11. 遇到过哪些线上故障？发生故障时怎么排查和定位？
12. 公司实际怎样使用 AI Coding？哪些开发环节由 AI 完成？
13. 从产品需求文档到技术文档，这一步如何借助 AI 完成？

一面·项目

14. MiniCode 是在 Claude Code 快照基础上加工的吗？你做了哪些实现和裁剪？
15. Agent Loop 怎么实现？怎么避免死循环和无限工具调用？
16. Agent 执行任务或调用工具失败后，如何恢复和重试？
17. 怎么判断哪些错误应该重试、哪些不应该？由程序判断还是交给模型？
18. 任务失败后有没有保存执行上下文？如何记录失败在哪一步和当时状态？
19. 五层权限拦截和路径沙箱怎么实现？
20. 规则引擎是把规则写进提示词，还是程序读取并执行？
21. 权限模式怎么设计？默认模式是否需要询问用户？
22. 五层权限检查的优先级是从左到右吗？命中一层拒绝后是否直接终止？
23. 双层跨会话记忆怎么实现？长期记忆在什么时机写入和更新？
24. 已存在的记忆怎么处理？新旧记忆冲突时怎么办？
25. 工具按需加载时只注册名称吗？是否包含工具描述？
26. 请介绍短视频 Feed 系统。
27. 怎么避免同一个用户反复刷到相同的视频？
28. Feed 流是提前准备好内容再按游标分页获取的吗？
29. 用户正在刷关注流时，关注的博主发布了新视频，这种情况怎么处理？

一面·基础

30. 反向传播主要做什么？
31. 热榜使用的 Redis ZSet 底层怎么实现？只有跳表吗？按 member 查 score 的时间复杂度是多少？
32. 进程、线程、协程有什么区别？Python 和 Go 的协程实现有什么不同？
33. Kafka 和 RabbitMQ 有什么区别？分别适合什么场景？
34. 手撕：把无序单链表中值为奇数的节点放到前面、偶数节点放到后面，保持各组内部相对顺序，O(n) 时间、O(1) 空间。

二面

35. 现场 AI 编程：用熟悉的 AI Coding 工具，在 30 到 40 分钟内完成优惠策略系统的设计与开发，并共享屏幕演示。
36. 刷新浏览器后策略和预算数据会不会丢？目前存在哪里？
37. 放到真实生产环境，存储应该怎样设计？如何同时考虑 B 端配置和 C 端浏览？
38. 双十一场景下数据量和高并发怎么处理？给出整体设计方案。
39. 评估系统压力应该看用户数还是请求数？同一用户一秒内多个请求怎么处理？
40. 按用户或 Request ID 限流，能不能真正限制系统总流量？
41. 浏览流量大、下单流量小时，统一限流会不会误伤下单？如何保障下单请求？
42. 了解哪些限流插件、中间件或现成方案？
43. 有大量店铺、商品和优惠策略时，如何快速找到某个商品能命中的策略？
44. 把策略交给前端维护具体是什么意思？策略很多时能否全部交给前端遍历？
45. 下单扣减优惠预算或库存时，Redis 和 MySQL 都有数据，完整更新流程怎么设计？
46. 引入消息队列具体解决了什么问题？
47. 系统怎么感知异常？消息处理失败后如何自动恢复和重试？
48. 手动 ACK 与自动 ACK 有什么区别？消息什么时候确认、什么时候重新入队？
49. Redis 已更新、MySQL 尚未更新时，再用 MySQL 回填 Redis 会不会出错？
50. 使用 AI 交付代码后，如何验证代码质量、功能正确性？

《参考解析》

上下文管理要同时管「窗口」和「成本」。短期上下文按轮次保留最近若干轮，超出后做摘要压缩（保留事实和结论、丢弃寒暄），并给系统提示、检索内容和工具结果分配固定预算；长期记忆按用户维度存事实和偏好，写入时机通常是对话结束或出现稳定偏好时，读取时按相关性召回。压缩最怕丢关键约束，所以摘要要保留数字、时间、否定条件。

Agent Loop 的终止条件要显式设计：最大轮次、最大工具调用次数、总 token 预算、连续无进展检测、以及「模型输出最终答案」信号。重试要区分错误类型：网络超时、限流可重试并退避；参数非法、权限拒绝、业务错误不重试，直接回灌给模型让它改。

权限拦截用「多层 + 短路」：路径沙箱、命令白名单、敏感操作确认、只读模式和审计日志分层检查，命中拒绝就直接终止并记录原因，不再往下走。规则要由程序读取执行，写进提示词只能算引导，不能被当成安全边界。

MySQL 迁 PostgreSQL 的无缝切换靠双写 + 影子读 + 灰度切流：先全量迁移历史数据并校验，再双写保证增量一致，读路径按比例灰度切到新库并比对结果，确认无差异后停旧库写。迁移进度靠位点或版本号记录，失败可回放。

Feed 系统的核心是「召回 → 排序 → 去重 → 分页」。去重靠曝光表或布隆过滤器记录已推内容；关注流的新内容用推拉结合——大 V 走拉模式、普通用户走推模式，避免写扩散。游标分页比 offset 稳，能避免内容插入导致的重复和漏读。

限流要分层：网关按 IP/用户限流防刷，服务按接口限流保容量，核心链路（下单）单独配额，不能被浏览流量挤占。只按 Request ID 限流防不住总量，因为 ID 可以随便生成。

扣减预算/库存的完整流程：Redis 预扣（Lua 保证原子）→ 发消息 → 消费端落 MySQL 并做幂等 → 失败回滚 Redis。Redis 与 MySQL 不一致时以 MySQL 为准对账修复，别用 MySQL 反向覆盖 Redis 的实时值，否则会把已扣的额度放大。