作业帮 AI Agent开发一面

1. 自我介绍

2. Qwen3.5 这类新一代模型，如果不只停留在“Transformer 变体”

更有含金量的讲法不会只说它是 Decoder-only，而是会落到训练稳定性、推理效率和长上下文适配这三条线上。比如归一化方式、注意力结构、RoPE 扩展策略、GQA 对 KV cache 的影响、SwiGLU 对表达能力的提升，以及 tokenizer 和多语种兼容设计。面试官真正想听的是这些结构选择为什么出现，它们解决了什么具体问题，而不是模块名背诵。

如果要再深一点，可以顺手带出工程后果。比如 GQA 不是为了论文好看，而是为了在长生成场景下降 KV cache 占用；长上下文扩展也不是简单把训练长度调大，而是要处理 RoPE 频率外推失真和训练分布错位问题。能把结构和系统代价连起来讲，层次会高很多。

3. GRPO 和 PPO 最本质的区别是什么，为什么很多人会把它们说浅了

PPO 的核心是策略梯度加裁剪目标，通常依赖 value function 做 advantage 估计，因此训练链路里要维护 policy、reference、reward、value 等多个角色。GRPO 的思路更偏组内相对优化，它不强依赖传统 value head，而是利用同一 prompt 下多个候选样本之间的相对奖励构造归一化优势，从而减少 value 建模误差。真正的差别不是“一个新一个旧”，而是信用分配和方差控制方式不同。

GRPO 在长推理、推理型任务和可比较输出场景里更自然，因为一组答案之间常常可以直接比较优劣，不必每次都学一个绝对值函数。代价是它对采样策略、组内分布和 reward 稳定性更敏感，组构造不好时很容易把噪声奖励放大。

4. 对比 GRPO、DPO、PPO 的适用边界

DPO 更适合静态偏好对数据足够多、任务不太依赖多步交互的场景，它训练简单、稳定、成本低，但基本不处理真正动态的多轮信用分配。PPO 适合有明确 reward、需要在线探索或多步策略修正的场景，灵活但复杂，训练稳定性和资源成本要求都高。GRPO 介于两者之间，更适合“同一个问题可以采样出多个候选，再做相对比较”的推理优化类任务，尤其是数学、代码、复杂问答这类可以构造组内竞争的场景。

面试里不要只说优缺点列表，最好点出一句：三者不是替代关系，而是数据形态和任务结构不同导致的最优训练方式不同。谁能把这句话说清楚，基本就不会被追着问崩。

5. 上下文管理方法有哪些，真正的优化目标到底是什么

上下文管理不是单纯“塞更多 token”，目标其实是让模型在有限预算下保留最有用的信息。常见方法包括滑动窗口、摘要压缩、记忆缓存、分层检索、语义切块、关键信息提炼、对话状态结构化和外部工具存储。它们本质上都在做一件事：把“原始上下文”转成“当前步骤决策真正需要的最小信息集”。

真正难的地方在于信息价值是动态变化的。某段历史在上一轮没用，不代表下一轮没用；某个槽位信息在浅层问答中无关，在执行工具调用时却是关键参数。所以优秀的上下文管理不是静态裁剪，而是任务感知的动态重写与重组。

6. 长上下文优化里，压缩和检索为什么经常要一起做，而不是二选一

单纯压缩会不可避免丢信息，尤其是长链推理时，很多后来才重要的细节在压缩阶段根本看不出来值不值得保留。单纯检索又有盲点，因为检索依赖当前 query，而用户在复杂任务里往往自己都没说清楚需求，导致相关上下文召不回来。压缩和检索结合的意义在于：压缩先做低损信息整形，检索再做阶段性按需提取，两者相互补坑。

工程上常见做法是把原始上下文切成结构化 memory 单元，一部分做摘要态存储，一部分做向量检索或键值索引。真正好的系统不是摘要得多漂亮，而是能在后续执行节点把关键证据稳定拿回来。

7. Claude Code 和 Codex 的差异，如果从系统能力层面讲，重点会落在哪

更值得讲的不是模型名字，而是产品范式。Claude Code 更强调长工作流、跨文件推理、上下文保持、工具编排和对开发环境的连续理解，它像一个“能持续参与工程任务”的协作代理；Codex 更早期更偏代码生成和补全范式，重点在局部代码产出能力和编辑建议。一个更像持续代理，一个更像局部生成器。

如果再往深一点讲，差异会体现在上下文持久化、任务拆解深度、文件系统交互、命令执行策略、错误恢复、变更解释和多轮状态管理上。真正好用不是因为“更会写代码”，而是因为它知道什么时候该看文件、什么时候该调用命令、什么时候该停下来确认。

8. 为什么 Claude Code 这类代码 Agent 好用，关键不只是模型强

好用的核心在于它把代码任务从“单步生成”变成了“观察—规划—执行—验证”的闭环。普通代码补全模型通常只对眼前上下文负责，而代码 Agent 会主动读取目录结构、搜索调用链、理解配置、执行测试、观察报错再修复，这种循环显著提高了复杂任务成功率。也就是说，它不是更会写，而是更会做。

另一个关键点是上下文组织。代码任务依赖大量跨文件信息，若没有稳定的上下文裁剪和检索策略，再强的模型也会在长工程里迷路。所以真正的优势来自模型能力、工具能力和状态管理能力同时成立。

9. Skills 和 MCP 的区别是什么，为什么很多人会把这两个概念混了

Skills 更像可复用的高层能力封装，强调“完成某类任务的方法模板”，比如代码审查、单测补全、需求拆解、表格抽取，它偏向能力编排和任务抽象。MCP 则更像标准化工具接入协议，重点是让模型以统一方式访问外部资源和服务，比如文件系统、数据库、浏览器、知识库、IDE 或私有 API。前者回答的是“会做什么”，后者回答的是“怎么接世界”。

把两者混掉通常会导致系统设计很乱。你会发现有的人把一个数据库查询接口也叫 skill，本质上是把“工具能力”和“任务能力”混成了一层，后面在权限控制、可观测性和调度上都会出问题。