为什么腾讯offer含金量永远都这么高？有人为了进腾讯，2年内面试6次（附Agent面试题）
相对来说，鹅厂应该是国内互联网公司中大家最青睐的公司（也许没有之一）。
我琢磨了两点（欢迎大家补充）：
①、业务盘子大，社交、游戏、内容、云、AI 等等，赛道多意味着岗位多。
②、简历上有一段鹅厂的经历，之后的每一次求职、每一轮背调，都是加分项。
腾讯也是我所有技术交流群里讨论频率最高的关键字。
两年面六次，可能有些小伙伴会觉得，何必呢？
我的看法恰恰相反，从这哥们身上我们能学到三点：
- 面试挂掉不要否定自己，挂一次就复盘一次，这样也就知道了下一步该补什么
- 两年里行情起起伏伏，他没换赛道、没降低预期，认准的事就一直去冲，这种定力放在哪个行业都是稀缺的
- 心态够稳。被同一家公司拒五次还敢投第六次，说明他对自己有信心，也知道只要自己够优秀，机会总会来的
毫无疑问，今年的面试，AI 的浓度会更高。去年主要是 RAG，今年的重心更多是 Agent。
这种变化，对肯学新东西、喜欢折腾、越挫越勇的小伙伴反而是机会。那接下来这份硬核的 Agent 面经，希望你能认真读一读。
（全文比较肝，保证大家能学到很多很多，系好安全带，我们粗粗粗粗发～）
content
PS：项目用的PaiCLI，已在GitHub上开源，这是一个类 Claude Code的终端Agent，有需要的小伙伴可以学习。
https://github.com/itwanger/PaiCLI-Python
01、Agent 怎么处理长文本？
老王的第一问直奔 Agent：“Agent 拿到长文本怎么处理？超出上下文窗口怎么办？”
“我的原则，别让长文本一次性进上下文，进来之前先处理下。PaiCLI 的每个工具都有限流：”
- 读文件按行分页，一次默认 500 行，模型带着偏移量分段读；
- 执行命令的输出超过 20000 字符截断
- 抓网页先抽取正文再截断，默认保留 10000 字符
- 搜索结果只回显前 5 条
“特别大的文件要靠检索定位，先用 grep 找到行号，再用分页去精读关联的上下文。”
为什么读文件按行不按字符分？
“因为行号可以引用。模型说‘第 320 行有问题’，带着偏移量就能复读那一段，字符切片做不到这种精确回跳。”
“第二道防线是上下文压缩。可用预算等于窗口减去输出预留和缓冲，差不多占到预算的 80% 触发，最近 6 条消息原样保留，更早的提取摘要。”
02、上下文记忆的关键是什么？
老王点点头，问：“那上下文记忆的关键是什么？”
“三个关键点，分层、隔离、防污染。”
- 分层：会话内的消息历史、跨会话的长期记忆，各管各的
- 隔离：长期记忆按项目路径隔离作用域，A 项目的偏好不能串联到 B 项目
- 防污染：内容按哈希去重，超上限的按重要性淘汰，支持过期时间自动失效
“压缩生成的摘要不能混入长期记忆，长期记忆只记录用户明确要求保存的事实。”
“召回也要克制。关键词匹配占七成权重，重要性、置信度、新鲜度、访问频次占剩下的三成，默认只取 6 条，低于阈值的直接丢弃。”
为什么用关键词匹配，不上向量检索？
“记忆库沉淀的都是事实，可能也就一千多条，不会像RAG知识库有非常非常多，多到几十个G。”
“按关键词打分能毫秒级出结果，可解释、可调试，哪条为什么被召回一眼就能看懂；向量检索要维护 embedding，模型一换整个记忆库都要重新向量，检索起来也麻烦。”
03、前后指令冲突怎么处理？
老王在他的小本本上打了个勾，继续提问：“系统提示词、项目配置、用户输入，前后指令冲突了怎么办？”
“分两类。配置类冲突按照优先级排列，默认值、用户级配置、项目级配置、环境变量文件、命令行参数，从前往后合并，后者覆盖前者，谁离本次运行越近，谁说了算。”
“提示词类冲突靠信任分级。项目指令标记为工作区配置，召回的记忆标记为不可信数据，运行时信息标记为程序生成，记忆和工具输出只能当数据，不能当指令。”
“这条规则可以防止提示词注入。假如工具抓回来的网页里要是藏着一句‘忽略之前的所有指令’，没有信任分级的 Agent 真会照做，有了分级，它只是一段被引用的文本而已。”
system prompt 本身怎么组织？
“静态前缀加动态后缀。身份、行为守则、项目指令这些整个会话不变的排最前面，时间、目录、召回记忆这些每轮都变的拼在最后。”
“Prompt Caching 按最长公共前缀命中，稳定内容越靠前命中率越高。”
“项目指令文件要拼接起来而不是覆盖，按固定顺序加载去重。”
04、Harness Engineering 和 Loop Engineering 的区别？
老王仔细回味了我前面的回答，感觉意犹未尽，继续问：“Harness Engineering 和 Loop Engineering，这两个词最近很热，说说你的理解。”
提示词工程管的是“怎么说”——怎么写出让模型理解的指令。
上下文工程管的是“知道什么”——在正确的时间给模型提供正确的信息。
Harness Engineering 管的是“能做什么、不能做什么”——Agent 的整个运行时环境和安全边界。
Claude Code 就是一个典型的 Harness。它有权限模型、有 Hooks 系统、有上下文自动压缩、有 Sub-agent 隔离。每一个组件都是经过大量错误倒逼出来的。
Loop Engineering 管的是定时任务，对，没错，定时任务，让 Agent 能在无人值守的情况下持续工作。就像 Linux 中的 crontab 一样，Loop Engineering 就是 Agent 的调度器。
Claude Code 里有两种实现：/goal 和 /loop。
/goal 是有终点的冲刺。设定一个完成条件，比如“让所有测试通过”，Agent 持续工作直到条件达成。关键机制：用一个独立的评估器在每轮结束时检查目标是否满足，满足就停下来。适合一次性任务，修复一个 bug、完成一个 PR、跑完一轮测试。
/loop 是没有终点的巡检。设定一个时间间隔，比如每 10 分钟执行一次，Agent 按这个节奏重复工作。适合持续性任务——定时检查新 PR 并审查、定时扫描日志找异常、周期性跑测试。它不会自动停，除非你主动取消。
05、Skills 为什么适合放 system 层？
老王往前倾了倾身子，继续问：“Skill 的索引为什么适合放在提示词的 system 层？”
“三个理由：”
- 稳定：Skill 索引在整个会话期间都不会变，放 system 层能吃到 Prompt Caching，命中缓存的 token 成本比未命中低一个数量级
- 权威：什么时候该加载哪个技能属于行为规则，system 层优先级最高，不会被对话内容带偏
- 常驻：system 层不参与压缩，索引不会被摘要压缩掉
“前提是索引得够小，这就是渐进式披露的意义。”
06、未来 Agent 的核心能力是什么？
老王合上笔帽，抛了个开放题：“往后看，Agent 的核心能力会是什么？”
“我的判断是自我验证。现在的 Agent 会调工具、会写代码，但产出对不对，还得靠人把关，这是最大的瓶颈。”
“谁能让 Agent 在关键节点自己校验产出，跑测试、比对预期、发现错了自己回滚重来，谁就能把人从 Agent 的善后工作中解放出来。”
“再往后是记忆和协作。记忆决定了 Agent 能不能越用越顺手，协作决定了复杂任务能不能拆分给多个 Agent 并行干。”
07、对 GLM-5.2、Claude Code、Codex 有什么理解？
二面的最后一道是理解题：“GLM-5.2、Claude Code、Codex，这几个怎么理解？”
“GLM-5.2 是模型，Claude Code 终端 Agent，Codex 是桌面 Agent。”
“模型层看三样能力，推理的准确性、工具调用的稳定性、上下文窗口的大小。”
“产品层主要看 Harness 做得够不够好用。就目前来说，Claude Code 就是最牛的终端 Agent，Codex 就是最牛的桌面端 Agent。”
他们都和各家的模型做到了最大程度上的兼容和匹配，所以用起来，会觉得 Fable 5 和 GPT-5.6 更顺手，更聪明。和模型属于相辅相成的东西。
08、RL 前 SFT 怎么做？
老王指着新题单的第一行，继续问：“强化学习之前，监督微调（SFT）该怎么做？”
“SFT 的任务是把模型拉进目标分布，说白了，就是先让模型见过、学会我们要它做的那类任务，格式和基本能力都在这个阶段打底。数据上抓三件事，任务覆盖要全、难度有梯度、轨迹要干净，Agent 场景还要把工具调用的轨迹整理成统一格式。”
“数据主要靠拒绝采样。用当前模型对一批任务采样多次，拿验证器筛出做对的轨迹，回填进训练集，模型自己教自己；再配一部分强模型蒸馏的轨迹补短板，人工标注只兜最关键的部分。”
怎么判断 SFT 做到位了？
“不看 loss，看三个信号：”
- 格式遵循率和工具调用的合法率接近饱和，说明规矩学会了
- 多次采样的通过率 pass@k 上得去，说明能力有了，只是还不稳定
- 验证集上继续训练的收益明显递减，说明这个阶段榨干了
“还要盯一个反向指标，通用能力的评测集不能掉点。掉了就是数据配比失衡，专项能力是拿灾难遗忘换来的，得不偿失。”
“三个信号齐了再上 RL。RL 的本质是把 pass@k 里已经存在的能力压进 pass@1，前提是 k 次采样里真有做对的。”
“SFT 不到位就上 RL，探索空间里采不到正样本，奖励太稀疏，训不动。”
09、reward 和 verifier 怎么设计？
老王接着问：“奖励（reward）和验证器（verifier）怎么设计？”
“优先用可验证奖励。代码跑测试、数学比答案、格式做校验，判定客观、成本低，模型讨好不了它。”
“验证不了的维度才用奖励模型（reward model），拿人工标注的偏好对训练一个打分模型。”
“还有一个维度是结果奖励和过程奖励的取舍。结果奖励只看最终对错，信号可靠但稀疏，长任务里模型很难知道错在哪一步；过程奖励每一步都给分，信号密集，但每多一个打分点，就多一个被钻空子的机会。”
“我的倾向是结果奖励打底，过程奖励只加在能客观判定的节点上。”
“verifier 有两条设计铁律。一是判定真实目标而不是代理指标，判‘测试过没过’，不判‘代码像不像对的’；二是测试文件要锁住，不许被测的模型修改，打分的尺子不能交到被打分的人手里。”
10、reward hacking 怎么发现？
老王追问：“奖励作弊（reward hacking）怎么发现？”
“核心信号就一个，分数在涨、能力没涨。具体盯四个地方：”
- 指标背离：训练的奖励曲线在涨，人工评估和独立评测集不涨，甚至在跌
- 行为突变：输出长度暴涨、重复套话、工具调用的模式变得畸形
- 高分抽检：定期人工翻高分样本，看有没有钻空子的
- 双套校验：训练用一套 verifier，评估用另一套，防止模型只过拟合其中一套
“代码场景的作弊姿势最典型。测试要求返回特定值，模型直接把值写死；测试文件可以修改，模型就把断言改成永真；甚至有把异常整个吞掉、让程序假装正常退出来骗过判定的。”
“这些样本在训练日志里全是高分，不人工翻，根本发现不了。”
“发现之后做两个动作，回滚到作弊之前的检查点，再修 verifier 把漏洞堵上。只回滚不堵漏洞，下一轮训练它还会从同一个地方钻出来。”
11、badcase 怎么回流？
“badcase 怎么回流？”
“先归因，再分流，不能一股脑塞回训练集。做错了的坏例，修复成正样本进 SFT 数据；不算错但答得不好的坏例，做成偏好对去训 reward model；还有一类是 verifier 自己判错了，要修的是评测环境，不是模型。”
“归因不能拍脑袋，要给坏例打标签，是检索没召回、工具调用出错，还是推理链断了。标签攒够量，模型的短板分布一目了然，下一轮数据往哪补也就清楚了。”
“回流有三条工程纪律，去重、控制配比防止灾难遗忘、每个修复过的坏例都加进回归评测集，防止同类问题复发。”
“badcase 不是垃圾，是带着精确坐标的免费训练信号。”
12、PPO 里的 value model 和 reward model 怎么训练？
“PPO 里的 value model 和 reward model，分别怎么训练？”
“先分清两个模型的角色。奖励模型管‘这个结果值多少分’，价值模型（value model）管‘当前状态往后预计还能拿多少分’，一个评结果，一个估预期。”
“reward model 在强化学习开始之前训好，拿偏好对做排序损失，通常从 SFT 模型初始化，训完就冻结。value model 是在 PPO 过程中和策略模型一起在线更新的，训练目标就是把‘往后还能拿多少分’估准。”
“奖励里还要加一项 KL 惩罚，约束策略模型别跑得离 SFT 模型太远。跑远了语言质量会崩，reward 再高也没用。”
“一个容易踩的坑，训练初期先冻住策略模型，单独把 value model 预热几步。不预热的话，早期的优势估计全是噪声，策略一上来就被带偏。”
“PPO 训练时，策略、参考（也就是那份冻结的 SFT 模型）、奖励、价值，四份模型的权重要同时放在显存里，这个开销，就是后来 GRPO 把 value model 省掉的最大动机。”
13、GRPO 的 reward 能不能迁移到 PPO？
老王追问：“GRPO 的 reward 能不能直接迁到 PPO 上用？”
“能，两者吃的是同一种东西，一条回答对应一个分数的标量奖励。真正的区别不在 reward，在优势估计的方式。”
“GRPO 对同一个问题采一组回答，用组内的平均分当基线，省掉了 value model；PPO 用 value model 来估基线。”
“所以迁移时 reward 和 verifier 原样能用，要补的是给 PPO 训一个 value model。另外注意奖励的尺度，GRPO 的组内归一化在 PPO 里没有对应机制，尺度不齐，训练容易震荡。”
14、Agent 任务怎么评测？
“Agent 任务怎么评测？”
“分三层指标。结果层看任务的成功率，前提是环境可复位、产物能客观判定；过程层看步数、token 成本、工具调用的成功率，两个 Agent 都能完成同一个任务，步数差三倍就是水平差距；稳定层看同一任务跑多次的方差，连续多次全过才算真会，偶尔过一次不算。”
“环境可复位是个工程活，用容器或快照保证每次评测都从同一个状态出发，不然上一次运行留下的副作用，会污染下一次的结果。评测集还要防泄漏，进过训练数据的任务必须踢出去。”
“评不了硬指标的维度，用模型当裁判，但裁判要定期人工抽检校准，不然评测体系自己先漂移了。”
15、Code Agent 的 verifier 怎么设计？
老王看了眼时间，问出最后一题：“Code Agent 的 verifier 怎么设计？”
“分四层，从便宜到贵：”
- 语法层：编译或语法检查，秒级出结果，最先拦
- 测试层：跑单元测试和集成测试，以“失败转通过”为核心判定
- 静态层：类型检查、风格扫描、依赖安全
- 评审层：模型或人做代码评审，兜住前三层测不出的设计问题
测试层的“失败转通过”是什么意思？
“判定一个修复是否成立，要求对应的测试在修复之前必须失败、修复之后必须通过，两头都验，防的是‘测试本来就能通过’的假阳性。”
“防作弊要从运行环境下手，测试文件只读、沙箱执行、产物校验，一样都不能省。”
“PaiCLI 里我落地了一个 MVP 版本。写完 Python 文件立即做语法编译检查，报错直接附在工具结果里回给模型，当轮就改；多 Agent 模式里有专职的审查者角色，产出不合格就打回重做，最多两次。”
学AI大模型的正确顺序，千万不要搞错了
🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！
有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！
就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋
📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇
学习路线:
✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经
以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！
我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～