最近老有人问我：Agent 面试到底问什么？
前几天聊天时，有个网友问：现在转 Agent 开发，面试到底会问什么？
前言
这两年岗位变化挺明显：前端开始补后端，后端开始做 Agent，很多全栈岗位也顺手加上 RAG、工具调用和模型服务。
我在 L 站瞅了下，挑了几个有意思的面试题。它们不太考“背定义”，更在意你能不能把模型放进业务里跑起来。
十个现场问题
1. 从零搭一套智能客服，你先做什么？
场景是：模型已经选定，现在要从零搭一套通用型智能客服，怎么做技术选型和落地？
别急着画“LLM + RAG + Multi-Agent”的大图。先把问题分流：闲聊、订单查询、政策问答和人工转接是不是同一条路径？能用确定性接口解决的事情，不必交给模型猜。
上线时，知识库、工具权限、会话状态、人工接管、审计日志和灰度策略缺一不可。模型只是一个不稳定的组件，客服系统最终还是看解决率、转人工率、错误率和单次会话成本。
评论区有人说：“这些公司压根不懂 Agent 真正应该做什么。”这句话虽然有点冲，但提醒了一个事实：只会堆框架，不等于理解业务。
2. 知识库为什么要人工审核两道？
场景很具体：文档、PDF 和课件怎样切分、入库，为什么知识库还要人工审核两道？
因为入库不是把文件丢进向量库就结束了。标题、版本、生效时间、适用范围和表格结构都可能影响答案。第一道审核可以检查解析和切块，第二道审核确认内容是否能回答真实问题。对政策、合同和财务资料，宁可少收录，也不能把过期内容混进召回结果。
每条知识都应该带上来源、版本和审核状态。回答出问题时，至少能回到原文定位，而不是只看到一段无法解释的向量结果。
3. 混合检索已经召回了，为什么还要 Re-rank？
面试里经常会追问：Elasticsearch 加向量库怎样做混合检索？已经分组、排序、去重了，为什么还要再次精排？
关键词检索擅长命中专有名词，向量检索擅长相似语义，两者合并后仍可能把“看起来相关”的段落排在前面。Re-rank 的作用是用更贵但更准确的模型，在较小候选集里重新判断问题和文档的匹配度。
代价是延迟和费用会上升，候选集不能无限放大。把召回率、精排耗时和最终答案的引用准确率分开记，才能知道精排带来的收益值不值得这笔成本。
4. 上下文压缩把答案压坏了，怎么办？
真实复盘里有一道追问：上下文压缩策略是什么？如果模型能力导致压缩质量有问题，怎么解决？
可以先把上下文拆成几类：任务目标、硬约束、未完成事项、工具结果和普通聊天。压缩时优先保留前几类，普通对话可以摘要，工具结果则保留结构化字段和原始引用。
如果压缩后质量下降，不能只换一个 Prompt。用长任务回放对比压缩前后的决策，调整触发阈值，增加分层摘要，必要时从持久化状态重新加载关键事实。
评论区有人评价这些题“看了下，确实都是一些八股问题”。上下文压缩这题有点不一样：只要继续追问“压缩错了怎么发现、怎么恢复”，它就从概念题变成了故障题。
5. Agent 调用工具失败，怎样避免它越错越远？
题目很短：AI 调用工具失败了怎么处理？
先把错误分成四类：参数不合法、权限不足、网络超时和业务拒绝。参数错误修正 Schema，权限错误停止并请求授权，超时才考虑退避重试，业务拒绝则把原因返回给上层策略。
每次调用都要有请求 ID、参数快照和幂等键。否则 Agent 重试一次，可能就重复扣款、重复发消息，最后谁也说不清是模型错了还是系统重放造成的。
6. 单个 Agent 已经能分配任务，为什么还要 Multi-Agent？
单 Agent 也可以分配多个职能，为什么还要拆成多个 Agent？
拆分通常只有三个理由：角色需要不同权限，任务可以并行，或者每个角色有独立的评测标准。比如招聘系统里，简历分析、考勤核验和面试题生成可以分工，但最终结论仍需要一个有明确规则的仲裁层。
如果只是把一个大 Prompt 拆成三个 Prompt，系统通常会更慢、更贵，也更难排查。Multi-Agent 的收益必须能在业务指标里体现出来，而不是架构图上看起来热闹。
7. 长任务中断后，怎样断点续跑又不重复扣钱？
真实面试会把问题落到任务队列：进程崩溃、K8s 重启后任务会不会丢？重试会不会重复调用模型？中途断了怎样继续？
把任务拆成有状态的步骤，每一步记录输入、输出、状态和版本。执行工具时使用幂等键，完成后再提交状态；重启后从最后一个确认过的检查点继续，而不是从头把整段 Prompt 再跑一遍。
对于不可重试的副作用操作，要有人工确认或补偿逻辑。所谓“自动恢复”，不是简单地再试一次。
8. SSE 断线、刷新页面后，用户还能继续看到结果吗？
用户关掉窗口或刷新页面后，怎样继续接收后端任务流？
SSE 适合服务器向浏览器单向推送，但它本身不保存历史。给每个任务分配事件序号，把事件写入可查询的存储；客户端重连时带上最后收到的序号，服务端补发缺失部分，再切回实时流。
如果任务需要双向实时协商，才考虑 WebSocket。选协议之前先看通信方向和恢复要求，不要因为“实时”两个字就默认上 WebSocket。
9. 多租户 Agent 服务，是否应该一个租户一个 Pod？
这是很典型的落地追问：多租户场景下，K8s 是不是一个租户对应一个 Pod？
答案取决于隔离等级、租户规模和成本预算。高敏感租户可能需要独立运行时、密钥和资源配额；普通租户可以共享服务，但必须在数据、缓存、队列和日志层做好租户隔离。
先算清楚每种方案的资源利用率、扩缩容速度和故障影响面，再决定是共享 Pod、按组隔离，还是少数大租户独立部署。把“一个租户一个 Pod”当成默认答案，通常只是把隔离问题换成了成本问题。
10. AI 项目上线后，怎么证明它真的带来了收益？
面试官会追问：系统用户量、日活、Agent 使用量和 Token 消耗多少？AI 投入前后收益多少？成本优化后降了多少？
先定义业务基线，再对比上线后的解决率、人工处理时长、转人工率、延迟、Token 成本和错误率。比如客服系统不能只说“回答更快”，还要看人工工单有没有减少，错误答案有没有增加。
所有百分比都要带口径、时间范围和样本量。没有这些数据，“效率提升 30%”更像汇报话术，不像工程结论。
有意思的地方
这些题表面上在问 Agent，实际上一直在问老问题：系统边界在哪里，出了错谁负责，怎么恢复，如何证明值得上线。
从前端转全栈、从后端转 Agent，真正需要补的也不是一串框架名，而是把一次模型调用放进真实业务后，能够讲清楚数据、权限、成本和故障。
总结
如果下一场面试只问“什么是 RAG”“什么是 Multi-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时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～