小红书 AI Agent 开发岗面经合集：接口幂等、缓存鉴权与 Agent 评测

《面试题目》

面经 01 · 小红书 AI Agent开发岗（2026-09-17）

1. 实习期间主要负责了哪些工作？
2. 客户端请求创建 AI 摘要任务时发生超时，但服务端实际上已经完成入库。客户端重试后，如何避免重复创建任务或重复扣费？
3. 「先删除再创建」的处理方式是否合理？为什么不先查询任务是否已经存在？
4. 同一个 JVM 中，Agent 类的两个实例同时对共享计数器执行加一操作，并更新同一个共享集合，最终出现计数丢失，可能是什么原因？
5. 创建两个独立的 Agent 对象执行上述问题，能否解决计数丢失的问题？为什么？
6. 在线文档的正文会缓存十分钟。如果管理员在缓存有效期内取消了某个用户的访问权限，该用户再次访问并命中缓存时，系统能否直接返回正文？怎么设计这个功能？
7. 正文缓存与权限校验在系统设计中应该如何分工？
8. 权限被取消时，是否应该立即让正文缓存失效？还可以采用哪些方案保证权限及时生效？
9. 设计一个 Coding Agent 时，需要考虑哪些问题？它应该具备哪些核心能力？
10. 你如何定义「一个好的 Coding Agent」？
11. 开始开发前，做过哪些产品调研和技术调研？
12. 如何完成技术方案、架构设计以及项目开发规划？
13. 主 Agent 与 Sub-agent 的通信、上下文管理和任务拆分方式，会对最终结果产生什么影响？
14. 为什么需要使用 Sub-agent？不使用 Sub-agent 是否也能完成任务？
15. 如何衡量不同 Coding Agent 或不同 Agent 调度方案的好坏？
16. 评价 Agent 时，应该关注中间过程，还是最终任务结果？
17. Coding Agent 的评价指标有哪些？例如准确性、完成质量、执行速度和指令遵循度等。
18. 你平时主要使用 Agent 完成哪些类型的任务？
19. 对于编程任务，如何评估 Agent 生成代码的质量？
20. 除了编译成功和测试通过，还应该使用哪些标准评价代码结果？
21. 你的项目是否建立过比较系统的评测集或评测体系？
22. 就算你做了 Sub-agent 的改进，有什么作用？做了哪些评测？主 Agent 能完成的话，用 Sub-agent 是什么作用？优化的指标是什么？
23. 当发现自己存在技术短板，或者不了解某项技术时，通常会如何补齐？
24. 你会如何制定学习计划？
25. 目前的知识体系是经过系统学习的，还是以零散学习为主？
26. 在 AI 编程时代，是否还会针对性地提升自己的代码基础能力？
27. 除了写代码，你还会使用 AI 完成哪些自动化工作？
28. 最早什么时候可以到岗？
29. 能够实习多长时间？
30. PE（Product Engineer，产品工程师）岗位中的「产品」和「全栈」具体如何体现？研发与产品之间如何协作？
31. AI Coding 生成的代码在公司内部如何进行 Code Review？
32. 当前的面试流程以及后续环节是什么？

面经 02 · 小红书 AI Agent开发岗（2026-09-14）

33. 具体 system prompt 有多长？里面包含哪些场景类型？单轮工具调用大概涉及多少条工具选择？
34. 你提到「模型底子不足影响参数填充准确率」，具体卡在参数传递、上下文推导还是数值记忆？目前是谁在测、怎么测的？
35. 用户体感上有什么影响？有没有真实用户数据，还是只用线程数模拟不同手机性能？
36. schema 是怎么设计的？是否包含名称、描述、参数定义、类型、枚举值、使用示例？参数约束为什么偏宽松？
37. 参数类型或枚举值错误怎么解决？是否考虑通过函数内部调用做兼容？
38. Agent 任务规划是怎么做的？生产场景是不是先识别意图，再推导工具依赖？函数执行报错后如何做多步推理和重新规划？主流模式了解吗？
39. 你说的「IG」具体指什么？应用场景是什么？
40. 检索为什么用父子索引？父块 10、子块 256 的设计逻辑是什么？
41. 口语化 query 的改写、扩写、分解怎么做？如何避免重复生成？HyDE 具体怎么用？
42. 重排模型为什么选 BGE / bge-rank 这一路？有没有做过准确率对比测试？
43. TOP K 截断依据是什么？相关性分数和上下文长度怎么权衡？低分文档怎么处理？
44. 上下文太长怎么压？预设文档数限制和模型压缩分别怎么做？压缩模型为什么强调 encoder-decoder、强理解能力？
45. RAG 提升到底是多少？HIT@K、Recall@20 各提升多少？
46. 为什么不用传统 token-based / BPE 模型？字节流相比 BPE 解决了什么？
47. 高分样本怎么筛？评价指标为什么是 BLEU 和 chrF1 的几何平均？
48. 伪标签噪声怎么控制？冠军方案用 10 个模型集成、110 个答案筛最优，你们有没有类似验证？模型集成和伪标签自蒸馏的验证边界是什么？
49. 分数从 30 到 32，有没有做消融实验？提升来自随机掩码、双向互译还是随机编码？
50. 为什么随机编码对效果重要？
51. SFT 数据量怎么判断？风格对齐、高难度任务分别要多少数据？「数据质量比数量重要」怎么落地？
52. 怎么判断过拟合？看测试集 loss 还是任务指标？任务指标停滞或下降说明什么？
53. 全参数微调和 LoRA 怎么选？全参数适合什么场景，代价是什么？
54. 为什么从地理信息／智慧城市转向 AI？
55. 目前有没有其他 offer 流程？是否只有个人项目、缺业务实习？
56. 对小红书场景怎么看？购物领域为什么适合接入大模型？端侧模型能怎么切入？
57. 端侧模型核心价值除了降本，还有什么？隐私和低延迟分别对应什么场景？
58. 为什么关注苹果 Foundation Models、阿里 MNN 这类端侧框架？你评价的「60 多分」具体指什么指标？

面经 03 · 小红书 AI Agent开发岗（2026-09-11）

59. HTTP、SSE、WebSocket 比较起来有什么区别？你在项目中怎么使用的？各自适用的场景是什么？
60. ES 和 MySQL 的索引区别是什么？
61. 算法：给定一棵二叉搜索树，如何返回任意两个不同节点值之间的最小绝对差？
62. 团队主要做什么？

面经 04 · 小红书 AI Agent开发岗（2026-09-08）

63. 团队人数有多少？
64. 现在能否正常去实习？
65. SSE 和 Streamable HTTP 的区别是什么？
66. 如何适配 stdio、HTTP、SSE、Streamable HTTP？
67. 如何处理 MCP 版本兼容问题？
68. 场景题：对于像 ChatGPT 这种对话 Agent，你会怎么设计会话表和消息表的字段？
69. 手撕：最长递增子序列

面经 05 · 小红书 AI Agent开发岗（2026-08-26）

70. 讲一条业务的调用链路是怎样的？
71. 业务指标关注哪些？
72. 算法服务的工程化了解吗？
73. 基础服务使用了哪些技术？如何选择开源框架或自行实现？
74. 如何保证多个服务的稳定性，包括监控告警机制、自监控方式等？
75. 工程和大模型如何交互？你们有自己的算法工程化框架，它是如何实现的？
76. 大模型的耗时情况如何？对于高时效场景是否会使用大模型？
77. 你在现在的职级是多少？这次出来看的原因是什么？
78. 你之前在实习和工作的经历中，遇到的比较大的问题是什么？是如何解决的？
79. 你目前在团队中的工作内容和职责是什么？遇到的挑战有哪些？
80. 你在团队中如何与同事合作，解决团队中的问题？
81. 你如何看待团队的发展和变化，如组织架构调整、招聘等对你工作的影响？
82. 你在工作中如何提升自己的能力和技能？有哪些学习计划和方法？
83. 你如何平衡工作任务和职业发展？是否有过相关的经历和经验？
84. 你对未来的职业发展有什么目标？如何实现这些目标？
85. 你在工作中遇到的最大挫折是什么？是如何克服的？
86. 如何实现智能体管理和共享？

面经 06 · 小红书 AI Agent开发岗（2026-08-25）

87. 你在实习中为什么会经历两个部门？
88. 实习有真实经历过 Agent 内部流程编排吗？
89. 深入介绍一下实习中的具体细节？
90. 分析师 Agent 返回的结论怎么确保正确？
91. 结构化结论用的什么格式？
92. 介绍一下实习中那个 Agent 的整体架构。
93. 介绍它从输入到返回结果的完整流程。
94. 为什么用 OpenManus 这个框架？
95. 为什么不用 LangGraph 来实现这一套 Agent orchestration？
96. 多 Agent 同时执行具体争抢哪些资源？
97. 多 Agent 怎么做上下文和状态的隔离？
98. 介绍一下你说的这个项目。
99. Workflow 和你说的自治 Agent 的区别是什么？
100. 如果用户通过 Prompt Injection 诱导 Agent 泄露 System Prompt 或绕过既有指令，怎么防范？
101. Agent 对工具调用不作限制，会产生哪些风险？
102. 怎么做去避免这些风险？
103. 为什么项目里不考虑做多 Agent，或者说 Multi-Agent？
104. 假如你做了多 Agent 拆分，会有哪些风险？
105. 你对未来 AI 和写程序的趋势是怎么看待的？
106. 不打算考研吗？
107. 大概什么时候可以到岗？
108. 假设我们某些 Agent 将来要扩展到大量设备，同时覆盖本地 Agent 和云端 Agent，简单讲一下你的设计想法。

面经 07 · 小红书 AI Agent开发岗（2026-08-14）

109. 你的 Agent 项目记忆架构是什么？
110. 多少次更新一次长期记忆？
111. RAG 的数据哪里来？
112. 有没有遇见数据量大的问题？
113. 有没有做评测？
114. 你知道客户端面向盲人的一些入口吗？
115. 怎么用 AI 测试前端客户端？
116. ES 的查询流程是怎样的？
117. ES 有 12 个分片但 QPS 只有 1，查询特别慢，怎么排查？ES 应该怎么重建索引？
118. 设计模式有 23 个，根据用途分一下类。
119. 为什么要用设计模式？
120. DDD 跟 MVC 的区别是什么？
121. MVC 不能区分业务吗？
122. DDD 的分层是怎样的？为什么 DDD 的 domain 不依赖 infra 层？充血模型是什么？
123. MySQL 的索引、聚簇索引是什么？
124. 事务隔离级别有哪些？
125. MySQL 跟 ES 怎么同步？
126. 现在有订单场景需要同步，订单有状态流转，怎么保证状态不出错，完成态怎么不被未完成覆盖？
127. 顺序写太慢了，想想别的办法。
128. 每次都查太麻烦，再想想？

面经 08 · 小红书 AI Agent开发岗（2026-08-13）

129. 简单介绍一下自己的经历，以及之前参与过的 AI Agent 相关工作。
130. 你平时实习中主要关注哪些业务指标？这些指标是如何影响产品或技术优化方向的？

《参考解析》

接口幂等：超时重试下的「只做一次」

「客户端超时但服务端已经入库」是幂等设计的经典入口：超时只说明客户端没拿到响应，不代表服务端没执行，所以幂等必须由服务端承担。做法是调用方带业务幂等键（请求号或客户端生成的 UUID），服务端在同一个事务里「插入幂等记录 + 执行业务」，用唯一索引挡住重复插入，冲突时直接返回首次结果；扣费这类资金动作再叠一层状态机与流水表，任务状态单向流转、扣费记录与任务 ID 一一对应。题目里「先删除再创建」被质疑，是因为它的语义是覆盖而不是判断：并发重试会把别人刚建好的任务删掉，中间还有真空窗口，删除本身也要幂等；正确做法是先按幂等键查询（或直接尝试插入），存在就返回旧结果、不改变已发生的副作用。可以主动补一句幂等窗口的边界——键设有效期，过期重试视为新请求，避免表无限膨胀。

同一个 JVM 里的共享状态：为什么两个独立对象也救不了

两个 Agent 实例同时给共享计数器加一却丢更新，根因是「读-改-写」不是原子操作：两个线程都读到 5、各自写回 6，最终只加了一次；再往下追是 Java 内存模型的三件事——原子性（count++ 是三条字节码指令）、可见性、有序性（编译器与 CPU 可能重排）。共享集合的问题更直接：ArrayList、HashMap 并发写入会覆盖元素甚至结构损坏。第二问是陷阱：如果计数器是实例字段，各加各的当然不冲突，但业务上不再共享、统计值仍然是错的；如果共享的是静态字段或外部单例（Spring 默认单例 Bean 就是这种），换对象毫无作用。所以答案分两层：先确认共享的到底是什么，再用对的工具——AtomicLong 或 LongAdder 计数、ConcurrentHashMap 或加锁保护复合操作、把状态改成不可变或线程私有；跨进程则换 Redis 原子操作或数据库行锁。追问常在 LongAdder 与 AtomicLong 的取舍（分段累加高竞争下吞吐更好，读取不精确）以及 volatile 为什么不能用来做计数。

正文缓存与权限校验：缓存可以脏，权限不能脏

十分钟的正文缓存遇上「管理员刚撤销权限」，结论是不能直接返回缓存正文——缓存的是内容，鉴权是每次请求都必须重新做的判断，两者不能合并成一个「命中即返回」的快路径。分工是：鉴权层每次请求都执行（权限数据本身可以缓存，但缓存的必须是权限数据而不是判定结果，且要能主动失效），内容缓存层只负责正文读取加速，命中后仍要过鉴权才返回。权限撤销时是否立刻失效正文缓存是成本与时效的权衡：最省事的是把权限版本号拼进缓存键，权限一变版本号加一、旧键自然读不到；也可以主动清理该用户的条目，再用短 TTL 兜底。更好的方案是判定结果不进缓存、只缓存权限数据加版本号，并在网关层做统一的资源级鉴权，同时接受「安全敏感场景宁可牺牲命中率」这个取舍。

Coding Agent 的设计、Sub-agent 与评测

设计一个 Coding Agent 要覆盖四层：感知与上下文（代码库检索、文件读写、依赖与错误信息怎么进上下文）、决策（任务拆解、计划与执行循环、失败重试与回退）、行动（读写文件、跑命令与测试、查文档、提交差异，以及每个工具的权限边界）、质量与安全（沙箱、改动范围约束、关键节点人工确认）。核心能力按「能读懂现有代码、能做可验证的最小改动、能在失败后自我诊断、能解释自己的改动」组织，这也顺势回答了什么叫好的 Coding Agent：不是看一次生成多少代码，而是看任务通过率、一次通过率、平均交互轮数、引入回归的比例与单任务成本。用 Sub-agent 的理由讲成「上下文与并行的取舍」——把长任务的大上下文切成多个短上下文以降低污染与成本、让子任务并行试错、给每个子任务更聚焦的角色与工具集；代价是通信开销、子 Agent 看不到全局导致局部正确而整体冲突、结果不可复现；拆分的判据是「子任务的输入输出能不能独立定义、验收标准能不能独立写出来」。评测最容易被追问穿，所以要能给出对照实验：同一批任务跑单 Agent 基线与加 Sub-agent 的方案，比成功率、平均轮数、token 成本、端到端时延与回归率，并说明样本量与显著性；被问「主 Agent 能完成，用 Sub-agent 是什么作用、优化的指标是什么」，答不出数字就只能承认没做对照。

Agent 工程化细节：prompt、工具 schema、规划与压缩

system prompt 要把结构说清：角色与边界、工具使用规范、输出格式、领域规则、few-shot 示例各占多少 token，怎么做版本管理与评测；工具变多时靠分组、按场景裁剪可用集、把描述写得可区分来控制选择准确率。工具 schema 覆盖名称、描述、参数类型、枚举值与示例，并解释「约束偏宽松」的取舍：enum 太严会让模型频繁报错、太松会写错值，实务上先用宽松类型接收、再在函数内部规范化校验，把错误变成可纠正的提示回灌——但资金、删除这类危险动作必须严格校验。任务规划要包含「意图识别 → 工具依赖推导 → 执行 → 失败后重新规划」这条链，并说清失败处理差异：参数错误重试、工具超时换路、前置假设不成立则回计划层重规划，同时给循环轮数与预算上限。上下文压缩分两档：限制文档数与截断便宜但粗暴；用小模型做摘要压缩时之所以偏 encoder-decoder，是因为它能在压缩阶段完整读一遍长文再生成短表示，理解与改写比单向模型更稳；无论哪种都要有「压缩后关键信息还在不在」的校验与原文回溯入口。

RAG 检索优化与模型侧训练

父子索引的逻辑是「小块检索、大块生成」：小块语义聚焦、区分度高但信息不完整，命中后回溯到父块送进模型，兼顾精确率与可答性。query 侧三件事分清：改写补全口语化与指代、扩写生成多个等价问法提高召回（按结果去重融合）、分解把复合问题拆成子问题分别检索；避免重复生成靠去重聚类加数量上限。HyDE 是先让模型生成一个假想答案再拿它去检索，因为答案的用词分布更接近文档所以更容易命中，代价是多一次生成且假想答案跑偏会把检索带偏。重排的必要性在于向量相似度只是粗筛，交叉编码器逐对打分更准但算不动全量，所以两段式；选 BGE 一路通常是中文效果好、尺寸可选、可本地部署，但要能给出 Recall@K 与 NDCG@K 的前后对比。TOP K 的截断依据是分数分布加上下文预算双约束，低分文档宁可丢掉也不要塞进去稀释注意力。模型侧，字节流替代 BPE 解决词表外与多语言问题：BPE 词表固定，遇到没见过的字符组合就退化或拆碎，字节级把任何文本无损表示进统一词表、对拼写噪声更鲁棒，代价是序列变长。BLEU 与 chrF1 取几何平均是翻译类任务的常规组合，前者对同义改写苛刻、后者对形态变化与中文更友好。伪标签噪声靠多模型一致性筛选、分数阈值与保留干净锚点控制；消融实验是「分数从 30 涨到 32」必须配套的动作，逐个关掉随机掩码、双向互译、随机编码确认边际贡献。SFT 数据量按难度分层，「质量比数量重要」要落地成审核通过率与答案可验证性；全参与 LoRA 看「分布差多远、多少数据、多少卡」。端侧模型的价值除降本还有隐私与低延迟，评价框架要看内存占用、首 token 延迟与量化精度损失。

传输协议、MCP 适配与缓存鉴权的工程收尾

HTTP、SSE、WebSocket 按方向性与开销区分：HTTP 一问一答、短连接、无状态；SSE 基于 HTTP 长连接只做服务端到客户端的单向推送，纯文本、实现简单、兼容网关与鉴权，适合逐 token 吐流；WebSocket 全双工，适合高频双向交互，代价是要处理心跳、重连与背压。落地常见组合是 HTTP 做请求加 SSE 做流式返回。MCP 的适配问题是同一个服务端要以 stdio、HTTP、SSE、Streamable HTTP 几种方式暴露，方案是抽出「会话与消息传输」的接口层，让协议语义与传输实现分离；版本兼容靠版本协商、能力声明与向后兼容的字段扩展，不匹配时降级到最小能力集。会话表与消息表的关键字段：会话表放用户、标题、模型与参数、状态、最后消息时间；消息表放会话 ID、角色、内容块、token 数、模型、父消息 ID（支持重新生成与分支）、工具调用记录与耗时，索引按「会话 ID + 创建时间」建，长会话做分页与冷热分离。服务稳定性按「可观测 → 可定位 → 可自愈」三层答：指标、结构化日志与 trace id、跨服务链路追踪，告警分级与抑制、区分用户可感知故障；ES 慢查询先查分片数是否远超必要导致扇出（12 分片却只有 1 QPS 就是这个信号），再查排序字段是否走 doc_values、有没有深分页；重建索引走别名切换而不是原地 reindex 阻塞线上。