AI Agent 工程师面试高频题
本文是 AI 岗位知识库 Part B 的第四篇，题目整理参考开源知识库 VanGong1999/FDE（MIT License）的题库结构，答案为业界共识要点。姊妹篇：FDE 面试通关。
面试考的不是背概念，而是用概念做决策。每题都给出「答题要点」——回答时先给结论，再给理由与权衡，最后给一个自己项目里的例子。
1. LLM 基础（热身区）
Q1：解释一下 token 和上下文窗口。为什么工程师要关心？ 要点：token 是模型处理文本的单位（约 0.5–0.75 个英文词 / 0.5–1 个汉字）；窗口是单次可见的 token 上限。关心它是因为计费、限流、上下文预算、截断策略都基于 token；窗口满了会截断或报错，塞太满还会稀释注意力、增加成本。
Q2：Temperature 和 Top-p 是什么？什么场景怎么设？ 要点：控制采样随机性。抽取/分类/工具调用趋近 0，创意写作调高。生产里通常固定并写进配置，保证行为可复现。
Q3：什么是幻觉？工程上如何缓解？ 要点：模型生成看似可信实则错误的内容，根源是概率生成而非检索事实。缓解：RAG 接地 + 强制引用、拒答机制、降低自由度（结构化输出）、关键场景人工复核、用评测集持续监控。缓解而非根除——所以要设计「错了也不致命」的系统。
Q4：Prompt、RAG、微调怎么选？ 要点：知识常变 → RAG（知识外置、可溯源）；行为/格式要求 → Prompt + few-shot；领域语言极特殊且有充足标注数据 → 微调（LoRA）。三者可叠加。先穷尽 Prompt + RAG 再考虑微调。
Q5：如何降低 LLM 应用的延迟和成本？ 要点：模型路由（简单问题小模型）、缓存（prompt cache/语义缓存）、上下文瘦身、流式输出改善体感、非实时任务批处理、自建推理（vLLM + 量化）。先测量再优化：trace 出每步延迟与 token 用量。
2. RAG 系统（必考区）
Q6：描述一条完整的 RAG 流水线，每个环节的失败模式是什么？ 要点：解析 → 分块 → embedding → 索引 → 混合检索 → rerank → 上下文组装 → 生成 + 引用。失败模式分别是：表格/扫描件解析烂、块切得不是语义单元、只做向量检索丢关键词、噪声排进 top-k、指令冲突、编造引用。参考 RAG 实战精要。
Q7：向量检索和关键词检索各自的优缺点？为什么要混合？ 要点：向量懂语义但对专有名词、编号、生僻术语失灵；BM25 精确匹配强但不懂同义改写。企业查询两类都有，混合检索（RRF 融合或加权）是默认起点。
Q8：你的 RAG 准确率只有 60%，怎么诊断？ 要点：先建评测集再谈优化（否则无法归因）。按流水线分层归因：检索没命中（recall@k 低）→ 治理分块/换 embedding/查询改写；命中但排后 → rerank；排前但答错 → 生成层（prompt、上下文长度、模型）；答对但用户不满 → 问题定义错了，回到需求。
Q9：设计一个支持用户权限的 RAG 系统（千万级文档）。 要点：权限作为元数据进索引，检索时按用户身份过滤（过滤在检索层做，不是生成层）；考虑权限变更的索引更新、按租户/部门分索引、缓存与权限的组合、审计日志。没有 ACL 的检索不能上生产。
Q10：怎么评测一个 RAG 系统？ 要点：检索层 recall@k/MRR；生成层忠实度、答案相关性（LLM-as-Judge + 人工抽样校准）；运营层采纳率/编辑距离。评测集要含应拒答样本，且持续回流线上坏例。详见 从 Demo 到生产 §2。
3. Agent 系统（区分度区）
Q11：什么时候不该用 Agent？ 要点：路径确定的自动化用工作流；检索问答用 RAG；只有「开放任务 + 需要运行时组合能力」才用 Agent。Agent 的代价：延迟、成本、失败模式、调试难度都更高。能不用就不用，要用就给边界。
Q12：模型调用了错误的工具/传错参数，怎么办？ 要点：预防——工具 description 写清何时用与参数含义、JSON Schema 约束 + 应用层校验；处理——错误信息回喂模型让它自我修正（限重试次数）；兜底——连续失败转人工或降级。核心思想：把模型当「不可靠的调用方」设计接口。
Q13：单 Agent 和多 Agent 怎么选？多 Agent 的坑是什么？ 要点：先证明单 Agent 不够（上下文过载、工具太多导致选择混乱、需要不同角色视角）。多 Agent 的坑：上下文同步、错误跨 Agent 传播、责任边界模糊、成本翻倍。主从式（orchestrator-worker）是最常用的起点。
Q14：如何给 Agent 设定「自主性边界」？ 要点：四道闸——最大步数与预算上限、工具白名单与只读优先、高危动作 HITL 确认、运行全程可审计。参考 核心技术栈 §5。
Q15：Agent 的记忆怎么设计？ 要点：分层——工作记忆（当前窗口）、情景记忆（会话历史+摘要滚动）、语义记忆（向量库存事实）、程序记忆（技能/SOP）。关键决策：什么进长期记忆（用户显式偏好 > 自动抽取）、如何过期与更新。
Q16：MCP 是什么？解决了什么问题？ 要点：Model Context Protocol，Anthropic 开源的「模型 ↔ 工具/数据源」标准协议，把 M×N 的集成问题变成 M+N。要点：工具描述标准化、可插拔、生态复用；同时注意第三方 MCP 的供应链安全。
4. 工程化（资深筛选区）
Q17：如何设计 AI 应用的可观测性？ 要点：结构化日志 + trace（一次 Agent 运行 = 一条链路，含每次 LLM/工具/检索调用的输入输出与耗时）+ 质量与成本看板（成功率、拒答率、单任务成本、p95 延迟）+ 突变告警。目标是「任何一条坏回答都能在 10 分钟内回放出完整过程」。
Q18：Eval 怎么进 CI/CD？ 要点：评测集进 git、每次改 prompt/模型/检索参数自动跑回归、指标跌破阈值拦合并；上线用影子模式或 A/B 灰度。配套：失败案例分析流程（每周看 bad case 回流评测集）。
Q19：模型供应商宕机了怎么办？ 要点：降级链（备用模型/供应商，注意系统 prompt 与工具协议的兼容）、熔断快速失败、队列缓冲、关键路径的静态兜底话术；故障转移方案要定期演练，不能只写在文档里。
Q20：如何防提示注入？ 要点：认清「间接注入」最危险（恶意指令藏在模型要读的文档里）。纵深防御：输入检测、工具白名单与最小权限、指令与数据隔离、输出审查、高危动作人工确认。诚实地说没有银弹，说得出分层方案就是好答案。
5. 系统设计（压轴区）
Q21：设计一个企业智能客服系统。 答题骨架：先 Clarify（渠道、指标：首响 vs 一次解决率、合规）→ 分层方案：FAQ 级走 RAG + 引用，交易类走工具调用（查订单/退款），复杂/高风险转人工 → 全程影子模式起步，坐席辅助先行 → Eval：黄金问答集 + 采纳率 → 安全：权限、PII、话术护栏。
Q22：设计一个 Text-to-SQL 数据问答。 要点：语义层先行（表/字段/指标的业务含义描述，比裸 schema 强得多）；限定主题域；生成的 SQL 先 EXPLAIN 校验 + 只读账号 + 行级权限；结果带解释与样本行供用户核对；错误率不达标的场景退回「生成查询条件 + 确认」模式。
Q23：设计一个合同审核助手。 要点：拆子任务（条款抽取、风险分级、对照模板）而非端到端；高风险条款必须 HITL（AI 建议 + 法务确认）；评测用标注合同集按条款类型分层；输出强制引用原文位置；数据不出域的部署约束先问清。
Q24：设计一个编码助手（类 Copilot）。 要点：上下文组装（相关文件检索、光标附近代码、仓库结构）、补全 vs 对话两种延迟预算、执行隔离（沙箱跑命令）、评测（HumanEval 类离线基准 + 内部真实任务通过率）、成本（小模型补全 + 旗舰模型对话的路由）。
系统设计通用骨架：Clarify → 架构图 → 核心难点与 Delta → Eval 与安全 → 灰度与运营。跟 C.A.S.E. 框架完全同构。
6. 行为面
- 为什么做 AI Agent 方向？——落在「想把模型能力变成可靠的产品」，讲一个你从 Demo 推到可用的故事
- 讲一次模型产出不可靠、你如何系统性解决的例子——展示 Eval 思维而非「多改几版 prompt」
- 用户/业务方质疑 AI 不可靠怎么办？——校准式诚信：给真实指标、说清边界、设计降级与人工兜底，而不是辩护或拍胸脯
- 如果 AI 把某个任务做错了造成损失，你怎么复盘？——trace 回放 → 评测集补 case → 流程修正（权限/HITL）→ 公开复盘文档
7. 备面清单
- 能白板画出 RAG 与 Agent 循环两张图，并标注失败模式
- 每类题准备一个自己项目里的一手例子（带数字）
- 系统设计题限时 15 分钟走完 C.A.S.E. 五步，录音复盘
- 复习 从零开始构建智能体 的范式部分（ReAct/Plan-and-Solve/Reflection）
- 行为面 5 个 STAR 故事定稿，全部含量化结果
本知识库会持续更新。觉得有帮助可以到 GitHub 交流。