小红书二手面经实录（XHS Interview Reports）

所属：02-interview / questions
采集日期：2026-10-13（三轮）
来源：小红书（已登录）。第一轮搜索 大模型 面经 / 大模型算法 面试 真题 / AI Agent 面试 面经；第二轮加 Agentic RL 面经 / 大模型 系统设计 面试 / 大模型 评测 面试 面经 / 大模型推理 面经 面试，并首次把图文笔记的图片采下来读（见 §2）；第三轮（同日）把采图铺开 —— 采了 3 篇纯图文帖共 30 张图（517 / 1474 / 919 赞），产出 §4.10 与 §4.11
面试权重：★★（校准提问颗粒度用，不用来定权重、更不用来定答案）
性质：⚠️ 这些不是你的面经，是别人的。 本文件只回答一个问题：真实的面试到底问到什么颗粒度。

1. 为什么要单独存一份，而不是并进 interview-signals.md#

两者性质不同：

颗粒度差异是本文件唯一的价值。 标题告诉你该复习「Agent」，问题告诉你面试官会在哪一层戳你。

2. 小红书特有的采集限制#

B站那份的局限（自选择、平台偏差、时间快照）在这里同样成立，另有四条：

3. 可信度分层（本文件的读法）#

三级，用的时候必须区分：

A 级要特别重视：「挂经」比「offer 经」更值得读 —— 成功帖倾向只写答得好的部分，挂经会写「这里我说错了，应该说滑动窗口」。

4. 采到的真实问题（按主题）#

⚠️ 以下逐字来自笔记正文，未做一手考证。层级标注见 §3。

4.1 Attention 与模型内部（A/B）—— 《腾讯大模型算法面经》一面#

• 缩放点积注意力的原理？
• Q、K、V 投影并分头后，transpose(1, 2) 的作用是什么？
• 多头拼接后，为什么通常要调用 contiguous()？
• 手撕：多头注意力（Multi-Head Attention）（笔记原话：「腾讯很喜欢考这个呀，多次常考」）

→ 对应 01-fundamentals/01-llm-core/transformer-attention.md。注意 contiguous() 这类工程细节是本仓库当前自测题里没有的问法。

4.2 Agent 架构与工具调用（A/B）—— 《分享一下我面试 Agent 岗位时被问到的问题》《百度 agent 面经 9.6》《小绿书 agent 一面》#

• 你们用的 Agent 框架是什么？ReAct 还是 Plan-and-Execute？两者各自适合什么任务？
• 怎么让模型老老实实调用工具，不瞎编参数？
• Tool 的参数 Schema 应该如何设计，才能降低模型生成错误参数的概率？
• 工具调用失败 / 超时了怎么办？重试机制怎么设计？怎么防重复调用或死循环？
• MCP 相比直接用 Function Calling 主要解决了什么问题？
• 如果不用 LLM，怎么做上下文压缩（例如工具输出截断）？
• 已有开源 Agent 框架，为什么还要自己实现 Agent loop / Harness？
• 多 Agent 系统中，主 Agent 与子 Agent 如何分工？子 Agent 职责如何划分？
• 多 Agent 怎么协作（一个写代码一个审查）？遇到意见冲突怎么办？

→ 对应 04-agent-architecture/。「设计 Schema 降低参数错误率」和「不用 LLM 做压缩」是仓库当前没有的角度。

4.3 记忆（A/B）#

• 长期 Memory 应该在什么条件下写入？
• 短期记忆是怎么淘汰的？LRU 会打乱对话顺序吗？（该篇自述失分：「不应该说 LRU，应该说滑动窗口」）
• 长期记忆在向量数据库里怎么分类存储？怎么不让 B 用户访问 A 用户的长期记忆？
• RAG 如何识别偏好信息？是写到系统提示词还是按需加载？按需加载的时机是什么？
• 为什么要设计长短期记忆？

→ 对应 04-agent-architecture/memory.md。权限隔离（user_id 元数据过滤）是仓库当前没覆盖的角度。

4.4 RAG（A/B）—— 《小绿书 agent 一面》《百度 agent 面经》#

• 父子文档混合分块解决什么问题？三级文档查二级时，一、三级会一起参与检索吗？
• RAG 中递归字符切分相比固定长度切分有什么优势？
• RAG 中为什么常将 BM25 与向量检索结合使用？
• 召回结果不理想时，通常优先排查哪些环节？
• Rerank 后的 TopK 通常应该如何确定？
• 如何评估「微调 reranker 或 LLM」带来的收益？（该篇自述答案：消融实验，指标与步骤要讲清）

→ 对应 03-rag/。「父子分块」和「TopK 怎么定」是仓库当前缺的。

4.5 训练与 RL ★ 深度最高的一块（B）—— 《腾讯大模型算法面经》一二面#

• 多轮工具调用的 RL loss 如何设计？
• loss 是每轮模型调用后计算，还是整个 rollout 完成后计算？
• 一条完整 rollout 的最终奖励如何获得？
• 从 loss 角度看，GRPO 的设计有什么问题？
• GSPO 相比 GRPO 做了什么改进？
• 什么是 OPD？OPD 使用什么 loss？为什么用 reverse KL 而不是 forward KL？
• Agentic RL 与普通单轮 LLM RL 有什么区别？
• 多工具 Agent 在 SFT 阶段通常做哪些工作？
• Agentic RL 训练中，工具返回等待与 batch 组织做过哪些优化？

→ 对应 02-post-training/（grpo.md、rlhf-ppo.md）。

⚠️ 诚实标注：OPD、Qwen3.5-9B 等名词超出我能核实的范围，此处按原文记录，不做解释。GSPO（Group Sequence Policy Optimization）可核实存在。准备时请自行确认定义，不要照抄本文件的转述。

4.6 评测与线上（A/B）#

• Agent 的评估与普通 LLM 评估有什么区别？
• LLM Judge 打分时，是否需要看到工具返回的 Observation？
• 工具调用 / 参数出错时，如何评估最终回答和过程？
• 如何从海量线上 Agent 日志中构建有限规模的离线评测集？
• 如何分析「模型、知识库、工具、路由」分别对系统结果的贡献？
• 某个版本效果不佳时，如何定位问题出现在哪个环节？
• 如何判断端到端时延主要来自工具 / 数据库，还是模型推理？要不要做耗时埋点？
• Agent 系统交付后，如何维护和监控线上问题？

→ 对应 05-agent-evaluation/ 与 02-interview/design/06-agent-observability.md。「归因到环节」这一组几乎逐题命中 06-agent-observability.md。

4.7 工程基础（B）—— 《百度 agent 面经 9.6》#

• Python 中 CPU 密集型任务为什么通常更适合多进程而不是多线程？
• Redis 出现热点 Key 时通常有哪些解决方案？
• MySQL 中覆盖索引为什么能够减少回表？

→ 本仓库完全没有覆盖。这几题出现在「Agent 岗」面经里，说明应用岗会问通用后端。

4.8 Agentic RL 的观念层（B，第二轮补到，13 张图）—— 《为什么 Agentic RL 中 GRPO 反而不好用？》#

面试官的追问形态（该篇原文）：「Agentic RL 里可以继续用 GRPO，因为不训练 critic，省显存。」→ 追问：「最终 reward 是 1，前面二三十次 tool call，到底该奖励哪一步？」

GRPO 成立的前提（该篇总结）：短 horizon、强 verifier、组内 reward 有方差、一条 response 可作为主要优化单元。

Agentic RL 把四条全破坏，四个问题同时出现：

1. credit 太粗 —— 整条 trajectory 共享同一个 advantage。搜索 Agent 最终答对，中间的无效搜索、重复调用、错误判断一起被鼓励；反过来，前二十步都做对、最后因格式错误或工具超时失败，前面的有效动作一起被惩罚。「GRPO 知道整条轨迹好不好，却不知道到底是哪一步做对了。」
2. 组内 advantage 常归零 —— 太难则同组全失败，太简单则同组全成功；两种情况下组内 reward 方差都接近零，advantage 随之消失。「采样了几条昂贵的长轨迹，最后却没有多少有效梯度。」
3. 组内比较掺入环境噪声 —— 不同轨迹在第一次调用工具后看到的状态就可能不同；搜索结果、网页内容、API 返回值、执行报错与超时都有随机性。两条轨迹 reward 不同，未必来自模型策略的差异。 组均值只能当初始任务的 baseline，回答不了「某个中间状态下当前 action 比别人好多少」。
4. rollout 成本与 policy lag —— 每条 trajectory 几十次工具调用再乘 group size，rollout 很快成为瓶颈，省掉 critic 的显存优势覆盖不了环境交互成本。为提高吞吐用异步 rollout，等轨迹进入训练时 policy 已更新多次，数据越来越 off-policy；而 GRPO 仍在 token 级计算 ratio 和 clipping，环境执行的单位却是一整次 tool call —— 优化粒度与决策粒度没对上，训练容易出现高方差、过度 clipping，甚至reward 还在上涨、正确轨迹的 likelihood 却开始下降，再往后 entropy 上升、gradient norm 突变、整段训练崩掉。

工程上怎么改 / 面试里怎么答（该篇给出的方向）：

• 先查 GRPO 还有没有学习信号：看每组 reward 分布，统计 zero-advantage group 的比例
• 大量组内全对或全错 → dynamic sampling，优先采样能力边界附近的任务。⚠️ 但这只解决「没有组内差异」，解决不了多轮 credit assignment
• 检查 reward 能否落到 turn 上：工具调用是否合法、是否到达新环境状态、单元测试通过了多少、是否完成某个子目标 —— 这些都能提供中间反馈
• 能用执行结果验证，就尽量少用纯 LLM Judge
• 奖励「调用了工具」也不够，否则模型很容易学会反复调用工具刷分
• horizon 短、环境确定、组内方差足 → GRPO 仍可继续用；在其上加 turn-level reward / anchor-state grouping / step-level credit，通常比直接换算法更省工程成本
• GiGPO / GraphGPO：尝试把 trajectory 级别的比较，细化为相同状态下的 action 比较
• 任务长且中间状态可估值 → PPO 加 critic 与 GAE 更合适（critic 估计 V(s_t)，把终局收益逐步传回不同 turn）；异步程度高时还要单独处理 policy lag
• GSPO：调整 sequence-level ratio 与 clipping，解决的是优化稳定性
• Turn-PPO / ATPO / SORL：把 importance sampling 与 advantage 进一步对齐到 turn 级别
• 两类问题不要混着答：训练稳定 ≠ credit 分对了；credit 分细 ≠ stale trajectory 已处理好
• 训练时至少同时盯：reward 分布、非零 advantage 比例、任务成功率、有效工具调用率、trajectory 长度、每个 turn 的 entropy、KL、clip fraction、gradient norm、正确轨迹的 log probability
• 结论原话：「GRPO 没过时，但它不再是默认答案。」

⚠️ 诚实标注：GiGPO、GraphGPO、ATPO、SORL、anchor-state grouping 等名词超出我能核实的范围，此处按原文记录，不做解释。准备时自行确认，不要照抄本文件的转述。

→ 对应 02-post-training/grpo.md + 04-agent-architecture/。这一节就是 map.md 第 4 条缺口（Agentic RL 缝接材料）的原始素材。

4.9 推理 / Infra 与应用后端（A/B）#

《大模型算法工程师面经——月之暗面》（A，社招，含轮次与时长）：

• 大模型推理分哪两个阶段？每个阶段的特点是什么？
• 给一小段代码，推理时出现 OOM，可能是什么原因？如何排查？
• 输入 shape 为 (b, s, h)，详细计算 MHA 的计算量（含 self-attention 与 MLP 部分）
• 介绍 vLLM 的 PagedAttention 原理
• 讲下 FlashAttention 的原理
• 手撕：二分查找（中等题）

《DeepSeek｜大模型应用后端完整面经》（A，方向性信号最强）：

原话：「八股权重很低，项目真实性权重最高。面试官不怕你不会某个知识点，但一眼就能分辨你是不是只调用过 demo，没有线上大模型服务落地经验。」 重点考察：传统后端功底 + LLM 应用链路 —— API 服务、流式输出、KV Cache 对应用层的影响、Agent 工具调用、token 成本、长连接管理。不需要懂模型训练与 Transformer 底层数学。

《米哈游 AI 大模型开发 2h45min 面试复盘》（B）：

三轮差异化：一面「会不会做」→ 二面「能不能设计」→ 三面 + HR「适不适合团队」。 上岸关键原话：「拒绝纯理论背诵，所有技术点必须绑定业务场景 + 线上问题 + 量化结果」「不怕有短板，怕不会复盘、不会迭代」。

→ 对应 06-agent-infra/（vllm-pagedattention.md 已有）。缺的是应用岗视角：KV Cache 对应用层的影响、长连接管理、token 成本 —— 仓库现有内容偏服务端内部机制。

4.10 腾讯 Agent 二面（A 级，11 图，第三轮采图）—— 含「概念关系」与「场景题」两个新题型#

《腾讯 Agent 二面凉经带答案（较难）》，517 赞。正文只有一句「二面主要问的都是工程实际相关的问题，第一次被拷打麻了」，全部内容在 11 张图里。

原文自述一句很重要：「带个人隐私的相关内容与问题被省去，稍作了整理，答案是经过复盘优化的，不是现场回答，已被拷打」。

这决定了怎么用它：题目是一手的（可信），答案是事后复盘的（只能当参考）。不要把它当标准答案背 —— 它恰恰是「另一个人复盘后的答案」，参考价值在思路上，不在结论上。

题目（原文有编号重复，此处按顺序重排）：

1. 自我介绍
2. 讲一下两个项目
3. 项目一：元素定位 Agent 是什么？用途解释一下
4. 项目一：你的项目有动态容错机制吗？（接问：了解动态容错吗）
5. 项目二：Summary 节点在 Agent 项目 / 报告生成链路中，作用是什么？
6. 针对 Agent 系统的可靠性与并发能力，你具体做了哪些深度优化？
7. 这两个项目，你用了多少 AI coding？你是怎么问 AI 的 —— 直接提问，还是先写需求文档？
8. 你怎么理解 MCP、Prompt、CLI、Skill、Harness 这些概念，以及它们之间的关系？
9. 场景题：如果给你一个假设的需求，比如用 agent 实现一个 AI 面试的程序，你会怎么设计？
10. 你觉得你设计的这个产品有什么缺点吗？
11. 你觉得这个产品需要重点保证哪些核心指标或功能？
12. 你这个产品，怎么避免每一步出现重新规划，导致路径震荡？

★ 这篇里值得单独记的四点（其余题目仓库已有对应内容，不重复）：

① 「概念之间的关系」是新题型，仓库完全没有。 第 8 题问的不是「MCP 是什么」，而是把五个不同层级的词摆在一起问关系。原文给的答案是：

「Harness 评测 Agent，Agent 调用 Skill，Skill 通过 MCP 调用 CLI 等底层工具，Prompt 贯穿全程。」

拆开看每个词被放在哪一层：MCP 是协议标准（统一工具调用的格式、鉴权、生命周期管理，把本地文件/数据库/API/浏览器抽象成一套标准接口）；CLI 被理解为「暴露给 Agent 的一种可执行能力」（即一种特殊 Tool），通过 MCP 包装后 Agent 才能理解和调用；Skill 是更高层的封装 —— 「『发送邮件』是一个工具（通过 MCP 暴露），但『撰写一封得体的会议纪要邮件并发送』就是一个 Skill」，它面向任务、可复用，本质是「Prompt + 工具调用编排 + 控制逻辑」的组合；Prompt 是直接输入 LLM 的文本指令，贯穿全程（一个 Skill 内部会包含规划用、工具选择用、结果总结用的多个 Prompt）；Harness 是 Agent 的框架环境 —— 在可控环境里跑它、评估它、调试它，批量运行 Agent 并收集执行轨迹，用内置或自定义指标做自动化打分，也可接入 LLM-as-Judge 做定性评估，帮助系统化地做回归测试和 A/B 对比。 → 仓库缺这个：04-agent-architecture/mcp.md 与 05-agent-evaluation/agent-eval.md 各讲一半，没有「这五个词怎么摆」的正面回答。这是一个低成本高命中的补丁。

② 「你用了多少 AI coding / 怎么问 AI」进了技术面。 本篇第 7 题，以及 §4.2 引的《小绿书 agent 一面》第 10 题「AI Coding 的应用情况，为什么核心代码不用 AI 生成」—— 两篇独立面经都问了。这是一个新的考察维度：面试官在确认你是否有自己判断代码质量的能力（全盘接受 AI 输出 = 减分）。

③ 「路径震荡」被单独问，仓库没有正面回答。 第 12 题。原文给的定义与四层解法（可直接用作答题骨架）：

「路径震荡的本质是：Agent 在每一步都基于当前的、局部的上下文重新做全局规划，导致上一轮的决定被下一轮推翻，来回摇摆，既消耗 Token 又难以收敛。」

四层解法：

• 分层规划 —— 顶层计划在任务开始时生成，包含粗粒度步骤序列，在没有遇到重大障碍前保持冻结；底层执行只负责当前步骤内的工具调用与参数调整，不推翻顶层计划。只有当某一步持续失败，或返回信息与顶层假设严重冲突时，才触发有条件的重新规划。
• 决策记忆与约束 —— 「路径震荡往往是因为 Agent 忘记了之前为什么做某个决定」。在状态中显式记录上一次决策的理由，以及已经尝试过并失败的路径，作为硬约束输入下一次规划，防止反复在几条路径之间来回切换。
• 惯性机制与阈值控制 —— 引入置信度变化阈值，只有新信息对当前计划的置信度影响超过阈值才允许重规划；同时设置步数窗口，强制在生成计划后的 K 步内禁止重规划 —— 「因为许多看似矛盾的信息在执行几步后会自动消解」。
• 状态机化 —— 规划 / 执行 / 评估 / 重规划是明确分离的状态，只有在评估状态判定「当前计划不可继续」时才转移回规划状态。

④ 场景题是「设计一个 Agent」的变体，印证了 §5.2 的判断。 第 9 题「用 agent 实现一个 AI 面试程序」，原文答法是四个专职 Agent + 共享状态：面试官 Agent（提问与节奏）/ 理解与评分 Agent（分析回答）/ 追问决策 Agent（决定是否深入追问）/ 总结 Agent（生成最终报告），通过共享状态协作，并预设每道题的考察点和评分标准来约束 LLM 的自由度。四个关键技术点：状态管理（共享状态对象或消息总线记录对话历史、当前题号、每轮评分）；超时与异常处理（候选人长时间不说话或答非所问 → 追问决策 Agent 给提示或主动换题；对明显无效的回答限制追问次数，避免死循环）；题库与评分标准（预设每题的考察点 —— 逻辑、技术深度、沟通能力 —— 和参考答案要点，评分 Agent 据此做结构化判断，「而不是让 LLM 完全自由发挥」）；追问的边界控制（设定最大追问深度和方向约束，「只能针对当前问题的某一方面追问，不能跳到完全不相关的领域」）。

注意架构选择：这是多智能体而不是单体 —— 与 02-interview/design/02-multi-agent-service.md 里「多智能体何时才正当」的判据可以对上（四个角色的上下文与工具需求确实不同、且冲突裁决有明确归属）。

另外两道「反思题」值得准备（第 10、11 题「你的产品有什么缺点 / 需要保证哪些核心指标」）—— 这是「没有稿可背的问题」的典型形态，答法见 02-interview/projects/README.md 的《真实性追问》一节：从你已知的短板出发，不要从通用最佳实践出发。

4.11 Agentic RL 的工程层（两篇，均图片采集）—— 这是 §4.8 缺的另一半#

两篇，一篇来自一线工程师复盘，一篇来自大厂实验室的公开技术报告：

为什么单独开一节：§4.8 是观念层（GRPO 的四个前提怎么被多轮场景打破），这两篇是工程层（reward 怎么设、环境怎么做、崩了怎么救）。面试里 §4.8 决定你能不能接住第一问，这两篇决定你能不能被追问三轮。仓库原有的 08-agentic-rl.md 只覆盖了前者。

4.11.1 《Agent RL 训练细节》（沫波）#

（a）先问「我是不是真的需要 RL」 —— 这一段的面试价值被严重低估：「大部分团队其实不需要上 RL……第一个问题不是『怎么做 RL』，而是『我是不是真的需要 RL』。」

• SFT 在 Agent 场景的天花板（三条，比「SFT 是模仿学习」具体得多）：① distribution shift —— 标注数据给的是一条「金牌路径」，但模型部署上去之后中间随便错一步，就到了一个它训练时从来没见过的状态；对话生成里上句说得不太好下句还能接回来，Agent 不一样，一步选错工具，后面整条链路可能就全废了；② 探索能力 —— SFT 数据只记录了成功的路径，模型完全不知道「走错了怎么办」；而实际跑 Agent 时出错几乎是必然的（API 返回不符合预期、中间结果和想的不一样），模型需要能从错误中恢复，这个能力 SFT 给不了；③ 信用分配 —— 一条 Agent 轨迹可能几十步，SFT 对每一步都是同等权重的监督，但实际上可能只有第 3 步选对了工具、第 15 步的一个关键判断决定了成败。
• 什么时候该上 RL（满足至少两个）：① 任务结果能自动判 —— 「代码跑不跑得过测试、SQL 查出来的结果对不对、网页上的操作有没有到达目标状态，这些都是天然的 reward。如果你的任务结果只能靠人来评判，那 RL 的训练成本会高到不现实。这个条件其实是最关键的，没有可靠的自动 reward，后面一切都是空中楼阁」；② SFT 模型已经「会做但做不好」（偶尔成功、成功率 10%~40%）；③ 任务存在多种解法（SFT 只能学到标注员选的那一种路径）；④ 错误恢复是刚需（RL 训练过程中模型会见到大量失败状态，自然就学会了怎么从错误中恢复）。
• 什么时候别上 RL：SFT 已能到 90%+ 成功率（提升有限，不值得为几个点搞那么复杂）；没有自动评测手段（reward 全靠人打分，训练成本直接爆炸，且人打的 reward 噪声很大）；基座模型太弱（连基本的指令跟随和格式输出都搞不定 —— 「这时候老老实实先把 SFT 做好，基础没打好就上 RL 纯粹是浪费算力」）。

（b）方法选型：结论是「绝大多数 Agent RL 场景，先上 GRPO」 —— 但理由和 §4.8 不同，值得记：

「不是因为 GRPO 效果一定比 PPO 好 —— 说实话在多数场景下两者效果差不多。而是因为 Agent RL 这个事情，真正的瓶颈不在算法上，而在 rollout 生成速度、reward 设计质量和环境稳定性上。 GRPO 的工程复杂度低，能让你把精力集中在这些更重要的事情上。」

• PPO 的实际代价（比「要 4 个模型」具体）：需同时维护 Actor / Critic / Reference / Reward 四个模型，7B 模型 4 张 A100 80G 是起步价；Critic 的 value loss 动不动就爆炸、Critic 与 Actor 的学习率不匹配也是常见问题；更麻烦的是 Agent 轨迹经常有几十步，Critic 的 bootstrap 估值误差会一路累积，到后面估得越来越不准。
• 什么时候才考虑 PPO（三条判据，很实用）：手上有已经训好的 PRM（Process Reward Model）能给中间步骤打分；任务链路特别长（20 步以上），GRPO 的粗粒度信用分配明显不够用；或者团队本身有 PPO 的工程积累和基础设施。
• 三个算法旋钮：KL 惩罚系数 β —— 「设大了模型学不到东西，设小了模型容易跑飞（reward hacking）」，经验是从 0.01 起步看 KL 变化趋势来调，更好的做法是设一个目标 KL（比如 0.1），让 β 动态调整来追踪它；entropy bonus —— 「Agent 场景特别容易出现过早收敛 —— 模型很快就『认准』了一种策略，不再探索」，但要注意训练后期逐步减小，不然模型该确定的时候也在乱试；reward 的长尾处理 —— 「如果 reward 分布有长尾（个别 case 的 reward 特别高或特别低），直接拿来训会导致梯度爆炸」，做 clipping 或 normalization 能省很多调试时间。

（c）数据构造 —— 作者认为这一环比算法选型重要得多

• Prompt 集：难度要有梯度。 按简单/中等/困难分档；训练初期以简单任务为主，让模型先尝到「甜头」，建立起基本的奖励信号 —— 「如果一上来全是难题，模型采出来的 rollout 全部失败，reward 全是 0，组内标准化之后 advantage 也全是 0，相当于什么都没学」。作者的实际比例：前期 70% 简单 + 20% 中等 + 10% 困难，后面逐步调整到 30% + 40% + 30%。核心思路一句话：让每一批数据里面既有成功的也有失败的 rollout，GRPO 才有东西可以学。
• 多样性：体现在三个维度 —— 用到什么工具、需要几步完成、涉及什么领域的知识；prompt 集太单一（比如全是「搜索 + 总结」）会严重过拟合到这个模式上，换个类型就不行了；建议做一次 prompt 的聚类分析看分布是否均匀。
• 每条 prompt 必须有可自动执行的验证方法 —— 原文说「这个怎么强调都不为过」，这是 Agent RL 和通用 RLHF 最大的区别：不靠人打分，靠环境反馈。意味着每条 prompt 都得想清楚任务成功的判定条件是什么、怎么自动检查，而且不只是 happy path，边界情况也要覆盖到。「这块的工作量其实很大，经常占到整个项目工时的 30% 以上。但没办法，reward 不靠谱的话后面全白搭。」
• Reward 设计：先从最简单的 0/1 开始 —— 「别笑，这个简单粗暴的方案在很多场景下效果出奇地好。GRPO 框架下，只要同一个 prompt 的多个 rollout 里面有成功有失败，就能产生有效的训练信号。」0/1 的问题：任务太难时成功率接近 0、训练信号消失；且它分不出「差一点就成功」和「完全离谱」。于是在 0/1 上叠加辅助 reward：格式是否正确（工具调用的 JSON 格式对不对）、步骤是否高效（用更少的步骤完成给少量奖励）、某些关键中间状态有没有达到。

  ⚠️ 作者踩过的坑，原话照抄（这是全篇最有价值的一句）： 「辅助 reward 的权重一定要远小于主 reward。我们吃过一个亏 —— 步骤效率的奖励设太高了，模型直接学会了跳过关键步骤硬给一个答案，步骤数确实少了，但任务完成率反而下降了。模型是非常聪明的优化器，你给什么 reward 它就优化什么，给错了它就钻空子。」 → 这与 race-bot-hkjc.md 里「只奖励可执行性会训出永远跑得通但答非所问的 SQL」是同一个失败模式，但这次是「辅助项权重压过主项」，值得作为独立易错点记下来。

（d）环境与 rollout —— 工程量的大头

• 环境必须能快速重置到确定性的初始状态。 「每个 rollout 都要从同一个起点开始，不然 reward 的 comparability 就没了。」三种方案及各自边界：

  方案	优点	边界 / 代价
  Docker 容器沙箱	最规范	启动有开销（用容器池缓解）
  对外部 API 做 mock	速度快	覆盖度有限 —— 模型探索出来的新路径可能超出你 mock 的范围
  record-replay（真实 API 录一遍，训练时回放）	真实	问题和 mock 类似 —— Agent 走到没录过的路径就没辙了
  作者的做法：核心的确定性操作（比如代码执行）用真实沙箱，对外部 API 用 mock + record-replay 混合。

• 并行化是刚需。 GRPO 每个 prompt 采 G 个 rollout（G 一般 8 到 64），每个 rollout 可能有多轮工具调用；不做并行的话，「一个 batch 的数据可能要采几个小时」。做法：rollout 生成和模型训练异步进行 —— 一边用当前模型采样生成 rollout，一边用上一批 rollout 训练模型（代价是 policy lag，见 §4.8）；环境交互也批量并行，同时开几十个 sandbox；如果用 vLLM 做推理，注意和训练框架的 GPU 调度别打架。
• 量级参考（7B 模型）：prompt 集 5,00050,000 条；每个 prompt 采 832 个 rollout；有效训练步数几百到几千步；总 token 消耗数十亿到数百亿级别，主要取决于 Agent 轨迹长度。

  结论原话：「这个量级看着吓人，但其实 rollout 生成消耗的算力远大于模型更新本身。所以推理集群的配置往往比训练集群更重要。」 → 这一句和 08-agentic-rl.md §3.4「省掉 critic 的显存优势可能覆盖不了环境交互成本」是同一个结论，但给出了更斩钉截铁的版本。

4.11.2 《真实终端环境中的 Agentic RL 大规模训练实践》（阿里巴巴未来生活实验室）#

✅ 这是本仓库目前唯一有可核实出处的 Agentic RL 工程材料：对应 arXiv 2512.24873、开源模型 ROME、配套 Notion blog《The Bitter Lesson Behind Building Agentic RL in Terminal Environments》。§4.8 里那些被标为「未核实」的名词，这一篇给的是带实验曲线的原话 —— 而且它把 §4.8 只描述了现象的「粒度错配」，给出了形式化的解法。

（a）环境管理器（Env Manager）：三组件、两模式。 组件是 ROLL（训练框架）、iFlow CLI（Agent 框架）、ROCK（沙箱管理器）。两种互补模式：

• Roll-Managed Mode —— ROLL 负责上下文管理与轨迹构建，主要通过工具调用接口与 iFlow CLI 交互；优势是训练侧高度灵活（可按训练需求灵活组织上下文、引入更丰富的 prompt 模板与交互机制以提升鲁棒性），缺点是需要额外维护上下文处理逻辑，且不可避免会与真实 iFlow CLI Agent 的行为存在一定差距。
• CLI-Native Mode —— 上下文、会话与历史信息完全由 iFlow CLI 维护，ROLL 仅作为调用方，不负责轨迹拼接。

为什么要费劲做第二种模式（原文动机，这一句直接命中「训练/部署 harness 不一致」这个真问题）：

「在许多 Agentic RL 训练管线中，训练阶段的 prompt 设计与上下文管理，往往与生产环境中的真实 Agent 框架不同，这通常会导致部署后的模型能力下降。为了更好地与 Agent 侧的优化保持一致，我们同时也开发了 CLI-Native Mode。」

→ 这个问题的通用表述值得记住：训练时的 harness ≠ 上线时的 harness，模型会把训练 harness 的怪癖一起学走。 这也是为什么「在任意 harness 上训练」成了 2026 年这个方向的一个独立话题（本轮搜索结果里就见到多篇，如《在任意 Harness 上执行大规模 Agentic RL》《Agentic RL 怎么强化你的 Harness？》）。

（b）Mask and Filter —— 维持训练稳定性的基础保障。 终端环境里不可避免会出现瞬时网络故障、沙箱启动失败、工具调用偶发超时；把这些异常信号直接纳入策略更新，会向优化过程引入噪声。原则一句话：

「当前对训练有害或无法提供有效学习信号的样本，都可以采用 mask 或者 filter。」

而且按可恢复性分两类处理（这个区分是它的精细之处）：

• 不可恢复或大规模的错误（环境启动失败、沙箱不可用）→ 完全 mask 掉，并用占位样本替换，以保证能有 batch size 大小的数据；
• 偶发且可恢复的错误（工具超时、网速延缓）→ filter 掉，并**在全局控制比例（例如 ≤50%）**下丢弃，避免过度重试。

此外还按需引入其他 mask 操作（例如 max-turn mask）。实验对比：不使用 mask & filter 时训练波动较大、准确率不稳定（0.604）；采用后训练曲线更平滑，并收敛到显著更优的性能（0.673）。

（c）Chunked MDP / IPA —— 这一条正面回答了 §4.8 的「粒度错配」。 先说它观察到的现象：

「多轮 agentic 任务中：大多数 token 并不会改变环境状态；一条轨迹中可能包含多个决策节点；在大多数情况下，每一次交互步骤都对应一个具体的决策或状态转移。」

由此提出在 interaction chunk（交互片段） 层面建模 —— chunk 定义为「从一次环境交互到下一次环境交互之间的一段连续片段，通常以一次工具调用结束，构成一个完整的功能单元」；把每个 chunk 视为语义上的「动作单元」，并据此提出 IPA（Interaction-Perceptive Agentic Policy Optimization）：

• 在 chunk 层级而非 token 层级计算回报与重要性采样；
• 当推理策略与训练策略的偏差过大时，对整个 chunk 进行 masking，而不是逐 token masking —— 「从而更契合以结果为导向的粗粒度奖励结构」；
• 引入 chunk 初始化重采样，以及 imitation learning + RL 的混合训练方式，扩大模型在困难任务上的有效学习范围。

形式化细节（面试里讲得出「有这么回事」就够，不需要背公式）：

• chunk 级折扣回报 $G_k=\gamma^{\Delta(K,k)}R_{final}$ —— 理由很直观：token 级折扣在长序列上会指数衰减到几乎为 0，而 chunk 级的衰减次数会显著减少；同一个 chunk 内的 token 共享同一个权重；
• chunk 级重要性采样用 token ratio 的几何平均来近似（原文参照 GSPO 与 GMPO）—— 「以避免纠正单元和优化单元之间的不匹配」；
• chunk 级 train-infer diff mask —— 指出即便参数一致，rollout 引擎（SGLang）与训练引擎（Megatron）之间也会存在 logprob 的系统性偏差，因此把几何平均比值超过阈值 $H$ 的 chunk 整体 mask 掉，等价于「只让训推误差小于一定阈值的 chunk 贡献梯度」。原文也坦承这是临时保障措施而非根本解决方案，因为模型仍可能向训推不一致更大的区域漂移。

收益两条：在长程轨迹上获得更稳定的梯度；提升模型可学习能力的上限。实验给出了 token 级 vs chunk 级优化在梯度范数、训练 score、验证 score 上的直接对比（chunk 级更平滑、更高）。

面试价值：如果面试官问「GRPO 在 agent 场景的粒度问题怎么办」，标准的加分路径是 →「有一类工作把优化单元从 token 提到 交互片段（chunk），因为大多数 token 并不改变环境状态，所以按 chunk 计算回报和重要性采样、并对整个 chunk 做 masking 更契合轨迹级的奖励结构」→ 再补一句「这条路线的代表是阿里的 IPA/Chunked MDP」。这比继续说『GiGPO/ATPO』扎实得多，因为它有出处。

（d）保守起步：先从正样本轨迹学习。 前提判断：「在早期阶段，RL 往往受限于数据质量，而不是优化算法本身（当数据质量较差时，再好的优化方法也难以奏效）。」做法很朴素：在数据尚未完全可靠时，仅使用正样本轨迹进行训练。 实验证据分两段，结论相反，这个反转本身就是要点：

• 大规模合成数据上：同时使用正负轨迹更新策略会更频繁崩溃；而仅用正轨迹训练在各种设置下都保持稳定（原文提到类似现象已在 TOPR、W-REINFORCE 等研究中被提及）；
• 切换到小规模、高质量、经过专家验证的数据后趋势变化：两种方法都能稳定训练，但加入负轨迹后，下游测试集上的性能提升更显著。

于是采用课程式策略：早期只用正样本轨迹更新策略（基于大规模实例数据构建稳定的策略流形）；后期拥有小规模但高质量的实例后，才同时考虑正负轨迹训练。

⚠️ 与 RFT 的区别（原文专门点出，因为这是面试官最容易钻的一层）：看起来像 RFT，但「前者仍然优化 RL 的 surrogate objective，只是将负样本的 advantage 置零」；而 RFT 通常把筛出的成功轨迹当作监督数据、优化 likelihood 目标。且前者的策略更新仍遵循标准 RL 流程（masking、clipping、normalization 等稳定机制），从而可以自然整合样本过滤、细粒度奖励与训推不一致控制等策略。原文原话：「positive-only RL 并不是 RFT 的替代，而是一种更为保守的 RL 训练方式。」

（e）Agentic RL 为什么更难（三个机制，比 §4.8 的说法更精准）：

1. 重尾分布与极端负回报 —— 少数失败轨迹可能异常长（无限重试、长循环、重复工具调用），从而产生极大幅度的负回报；这些重尾样本容易主导梯度，导致策略分布向次优区域偏移，引发训练不稳定；
2. 带正向结果的浅层策略模式 —— 模型可能并未真正理解任务，而是依赖重复试错、某些固定命令序列或某些捷径；由于 outcome reward 只检查最终结果，这类浅层模式可能被强化，逐渐收缩策略空间并形成固化的模板；
3. 噪声型失败 —— 失败往往多样且不明确，未必由模型本身引起（可能是环境随机性或系统级干扰）；负样本的置信度通常低于正样本。

宏观上：「agentic RL 面临的问题与 RLVR 在 outcome reward 下的问题类似：信用分配、负样本不可靠、训练不平衡。但在终端环境中，这些问题更为严重：时序更长、工具交互更离散、改变环境的 token 占比极小、失败模式更多样、负样本方差更大。」

（f）★ 最有面试价值的一条：没有通用解法。 缓解手段包括：selective trajectory masking、selective token masking、trajectory-level reweighting、retry-loop penalties、以及轻量的行为塑形奖励/惩罚。它们的核心目标一致 —— 「控制哪些轨迹、轨迹的哪些部分、以何种权重参与策略梯度更新」。但原文立刻强调：

「需要强调的是，没有通用解法。不同数据条件下，同一策略可能产生相反效果。」

证据是一个反例实验：移除标准差归一化（std normalization）在一种数据设置下会迅速导致训练崩溃，而在另一种设置下，同样的操作反而使训练更加稳定（原文归因于数据分布的差异）。

为什么这条最值钱：它把「我读过几篇 Agentic RL 的方法」和「我理解这些方法为什么不是银弹」区分开了。面试里主动说「这些技巧没有通用解，同一策略在不同数据分布下可能反向」，比列举十个方法名可信得多 —— 而且这是公开技术报告里的原话，不是推测。

（g）崩溃是常态，关键是如何 Resume。 一条真实训练曲线：训练分数在大约 step ~80 开始急剧下降。但回看更早阶段，「在开始崩溃之前，优势的平均值已经出现了明显的持续下滑趋势」。进一步分析：

• 从大约 step ~50 开始，失败轨迹的最大回复长度迅速上升，但失败轨迹的样本数基本保持不变；
• 「这表明问题并非源于整体失败数量的增加，而主要是少量极端失败轨迹的影响。」

对策：对响应长度超过 20k 的失败轨迹进行 masking（以及降权）→ 优势的平均值开始回升，训练趋于稳定。约 40 个 step 之后不稳定再次出现，这次的最早的信号是负样本数量逐渐增加 → 对负样本进行全局重加权。

不稳定时优先检查的信号（原文四条，可直接当排障清单）：

另两条经验原则：优先针对极端轨迹进行定向处理（如果极端轨迹能被某些特征定位到，例如 mask 掉超长负样本），如果仍然不稳定，再采用全局重加权；RL 梯度通常比监督学习噪声更大，因此更小的学习率、配合更强的约束、退火或自适应机制，往往更稳定。

这张表 + §4.8 的指标清单 = 一套完整的「训练崩了怎么办」应答。注意两者的分工：§4.8 的清单回答「平时看什么」，这里回答「崩了先怀疑什么、动哪一刀」。

（h）细粒度行为监控与惩罚 —— 防隐蔽的 reward hacking。 原文判断：「在 Agentic RL 中，reward hacking 往往更加隐蔽。由于智能体与真实环境交互，它们常常可以以『看似合理』的方式通过测试用例。」反复出现的五种模式：

两条启示：测试用例的质量与鲁棒性至关重要 —— 「薄弱或描述不充分的测试可能在无意中奖励错误行为」；并非所有实例都适合用于 RL 训练 —— 「某些任务本身难以通过测试准确评估，反而更容易诱导模型寻找捷径或形成不良模式，而不是学习真正的解决方案」。

监控信号（很具体，可直接抄成监控面板）：不同任务的成功率趋势；不同工具的成功/失败率；重复或循环的工具调用模式；不同工具的使用频率；不同命令的使用频率。通过这些信号可以快速发现行为异常的任务（某个工具调用突然激增、出现大量重试循环、或频繁执行 kill process 类命令），一旦检测到就回滚训练，或定位并移除引发问题的实例。

（i）两条附带的发现，对「怎么讲项目」有直接用处

并行函数调用：对比 qwen3-coder-plus、glm-4.6、claude-sonnet-4.5 与 ROME 在同一批任务上的轨迹 —— claude-sonnet-4.5 的并行度显著更高（无论是并行工具调用的频率，还是单步内同时调用的工具数量都明显领先）。进一步分析发现它更擅长在执行具体操作前，先识别当前真正需要的信息：不会立刻进入执行阶段，而是先识别环境中的关键不确定性，并在同一步中通过多个并行的「检查类调用」获取信息。原文举的例子（给「Install Anaconda for me」时，单步内并行做多类检查）：

• 用 pwd / ls / cat / grep 检查目录结构与配置状态；
• 用 python -V 和 pip list 识别现有 Python 环境与依赖；
• 用 read_file 与 search 查找可行的安装方法及相关约束（如网络连通性、镜像可用性）。

启示（原文）：「在进行状态改变之前，显式鼓励一个『前置的、并行的信息收集阶段』可能是有益的。」 → 这条可以顺手接到 04-agent-architecture/context-engineering.md：先侦察后动手是可以被显式设计进 prompt / 工具集里的行为模式，不是模型自发的。

常见失败模式：终端类 agentic 任务中最常见的是 无效循环（unproductive loops） 与 超时（timeouts） —— 智能体在已有明确失败信号的情况下，仍然重复同一种策略，而不懂切换思路或重新审视假设；超时则常归因于模型缺乏对长时间运行命令执行时长的可靠感知，容易被默认超时机制误导。Terminal Bench 上的错误类型分布（原文饼图）：

这张分布图本身就是一条论据：「策略错误占三分之一、知识和幻觉加起来不到 16%」说明终端 Agent 的失败主要不是「不懂」，而是「不会」 —— 这正好解释了为什么 SFT 不够、为什么需要 RL（对应 4.11.1 的 (a)）。

5. 对备考的直接结论#

5.1 Agent 岗的追问深度在「训练」侧，不在「框架」侧#

腾讯两面共 27 题，其中一半落在 RL：loss 设计、rollout 奖励、GRPO 缺陷、GSPO、OPD、Agentic RL 与单轮 RL 的区别。

仓库现在把 02-post-training/（GRPO）和 04-agent-architecture/（Agent 循环）分成两块写，但面试里是合起来问的——「多轮工具调用的 RL loss 怎么设计」这个问题同时踩两块。 → 这是一个明确的缺口：需要一份把「Agent 循环」与「RL 训练」缝起来的材料。

5.2 「设计一个 Agent」是开场题，不是压轴题#

《面字节 AI Agent，30 篇就这几类》原文：「一面面试官：来，设计一个 Agent。我当场卡壳。」

02-interview/design/ 现有 6 题里，只有 02-multi-agent-service.md 沾 Agent，没有「单体 Agent 设计」这一题。 → 缺口：补一道单体 Agent 系统设计（工具集边界、循环终止条件、失败降级、评测闭环）。

5.3 高赞帖最不容易采到 —— 这是有方向的偏差，不是随机的（第三轮已部分消解）#

第一轮时「图采不到」还只是技术限制；第二、三轮已验证并铺开采图（方法见 §2）。但偏差的性质要说清楚：互动量最高的帖子最常是纯图文的。

第三轮采的三篇（517 / 1474 / 919 赞）正文全部只有一两句引言，内容 100% 在图里 —— 这第三次证实了那条规律。所以：

• ✅ 采图之后拿到的内容质量显著高于正文-only —— §4.10（A 级真题 12 题）和 §4.11（含一篇有 arXiv 出处的技术报告）都是采图的产物，靠正文一条都拿不到。
• ⚠️ 但偏差只是「部分消解」，没有被消除。采图是人工挑帖 + 逐张读，成本高、覆盖窄；而正文-only 采集可以铺很宽。所以本文件现在的状态是：采样宽度换来了采样深度，两者都还不是全量。
• ⚠️ 一个没找到的目标：第三轮想补采第二轮见到的那篇「346 赞」的图文帖，但搜索结果的排序已经变了，没能重新定位到它（重新搜到的同类最高赞是 517 赞的腾讯二面帖）。这说明小红书的搜索结果不稳定，隔天就可能捞不回同一篇 —— 遇到有价值的帖子应当当场记录 note id，不要指望以后再搜回来。

5.4 「项目真实性」压过八股 —— 两篇独立面经指向同一结论#

• DeepSeek：「八股权重很低，项目真实性权重最高……一眼就能分辨你是不是只调用过 demo」
• 米哈游：「拒绝纯理论背诵，所有技术点必须绑定业务场景 + 线上问题 + 量化结果」

→ 含义：01-fundamentals/ 是入场券，而决定胜负的是 02-interview/projects/ 的防守稿。这给仓库优先级提供了一个外部依据：项目的边际收益高于再补一块知识点。

第三轮给这条结论加了一个补充：腾讯二面那份 A 级真题（§4.10）12 题里有 8 题在问项目（第 36、912 题），只有第 8 题是纯概念题。这个比例本身就是证据。

5.5 第三轮采图暴露出的三个新缺口#

采图不只补了内容，也暴露了仓库此前连缺口都不知道存在的三处：

这三条有个共同点：都不是「再加一块知识点」，而是「已有的两块之间缺一座桥」 —— 与 §5.1 里 Agentic RL 缝接材料的性质相同。这说明仓库当前的边际收益更多在缝上，而不在块上。

6. 自测#

1. 为什么「挂经」比「offer 经」更值得读？

2. 小红书面经里出现「大模型推理优化 30 题」这种工整题库，应该怎么用？

3. 腾讯面经里一半题目在 RL，但仓库把 GRPO 写在 02-post-training/、Agent 循环写在 04-agent-architecture/。为什么这个结构在面试里会出问题？

4. 本文件 §4.7 的 Redis 热点 Key、MySQL 覆盖索引出现在「Agent 岗」面经里。这说明什么？

5. 只用正文采集会系统性漏掉哪一类内容？为什么说这个偏差「有方向」，而不是随机的？

6. 腾讯二面问「你怎么理解 MCP、Prompt、CLI、Skill、Harness 的关系」，为什么这题比「MCP 是什么」更难，也更能拉开差距？

7. 阿里那篇 Agentic RL 报告的核心结论之一是「没有通用解法，同一策略在不同数据条件下可能产生相反效果」。这条结论为什么在面试里比多列举几个方法名更有说服力？