跳到主要内容

Agent面试Top100必看题

Hello，各位小伙伴。

我根据现在 Agent 面试问题出现的重要性和难度，整理出了 100 道最爱被问到的题目，包含了 AI Agent、MCP、SKills、RAG、Harness、Vibe Coding、上下文治理 各个方面，小伙伴按照此顺序复习，对面试准备会有很大的帮助。

使用方法

先按主题快速浏览 100 题；第二遍只看自己回答不准的题目；第三遍可以尝试把答案改成自己项目的内容。当面试官问到“你做过吗”时，可以优先讲真实做过的部分，没做过就说明调研过什么、准备怎样验证。

一、关于项目的介绍​

1. 先做个自我介绍，为什么会做 Agent？​

  • 用 1 分钟讲清技术方向、项目背景、自己负责的链路和结果。
  • 直接说做了什么，例如“我负责一个面向运维同学的故障分析 Agent，接入知识库和监控工具”。
  • 最后落到一个可追问的点：延迟、命中率、成本或线上故障。

面试官可能继续问： 这个项目是内部工具还是外部产品？谁在用？

2. 介绍一个你最熟悉的 Agent 项目，整体架构怎么画？​

  • 按“请求接入、路由、上下文组装、模型推理、工具执行、结果校验、流式返回、数据记录”讲一遍。
  • 画图时把控制面和执行面分开，模型只负责决策，业务服务负责执行和兜底。

3. 这个项目解决了什么痛点？为什么值得用 Agent？​

  • 说明原来的人工流程卡在哪一步，最好给出耗时或错误率。
  • 只有需要理解自然语言、跨多个步骤和工具的任务，才值得引入 Agent。固定规则能解决的流程，直接用 Workflow 通常更好。
  • 如果能说出一个“不适合用 Agent”的反例，就更好了。

4. 你在项目里具体负责什么？怎么证明结果是你做的？​

  • 按模块、提交记录、接口或上线指标回答。
  • 讲一个自己处理过的 bug：现象、定位、改动、验证结果四步够用。
  • 如果只是参与调研，就明确说“我负责验证和接入”，别说成从零搭建。

5. 为什么选择 Java 或 Python？两种语言怎么取舍？​

  • Python 生态适合模型实验、数据处理和快速接入；Java 在已有微服务、并发治理、权限和监控体系里更适合。
  • 选择要看团队现有栈、SDK 完整度、延迟和运维方式，不要只比较语法。
  • 我会把模型调用封装成独立服务，让算法试验和业务主链路解耦。

6. 你调研过哪些 Agent 框架？为什么最后选这个？​

  • 可以比较 LangChain、LangGraph、Spring AI Alibaba、OpenManus、AutoGen 等在状态管理、图编排、工具注册、可观测性上的差异。
  • 结合任务形态回答：短链路用轻量封装，长链路和可恢复执行更看重图状态和检查点。
  • 说清框架不能替你解决的事，比如权限、幂等、数据隔离和业务校验。

7. 为什么用 OpenManus？为什么没有用 LangGraph？​

  • OpenManus 更贴近通用任务执行和工具协作；LangGraph 对状态图、条件边、暂停恢复的表达更直接。
  • 选择取决于团队熟悉度、是否要人工介入、链路是否需要可回放。

8. Agent、Workflow 和普通后端服务分别适合什么？​

  • 普通服务：输入输出固定，规则确定。
  • Workflow：步骤预先定义，允许少量条件分支，重点是稳定和可观测。
  • Agent：模型根据目标和观察结果决定下一步，适合开放任务，但必须加边界、预算和终止条件。

9. 从输入到返回结果，完整链路会经过哪些阶段？​

  • 鉴权和限流 -> 意图识别/路由 -> 读取短期记忆 -> 检索知识或工具说明 -> 调模型 -> 执行工具 -> 写回 Tool Message -> 再调模型 -> 输出校验 -> SSE 返回并落日志。
  • 每一步都要有 requestId、traceId 和耗时，出问题才能定位。

10. 你遇到过最难的 Agent 技术问题是什么？​

  • 用真实案例回答，不要只说“上下文太长”。
  • 讲清约束，例如“工具结果有 30 秒延迟、模型会重复调用、用户不能等待太久”，再讲方案和权衡。

二、Agent 基础与执行循环​

11. 你怎么定义 Agent？它和普通 LLM 对话差在哪？​

  • Agent 接收目标后，会结合上下文规划步骤、选择工具、观察执行结果，再决定是否继续。
  • 普通对话通常一次生成文本；Agent 的输出可能是动作、状态变化和最终答复。
  • 最小组成可以说成：模型、工具、执行循环、状态/记忆、约束和评测。

12. Agent 的基本运行机制是什么？​

  • 先理解任务，再决定动作；执行动作拿到 Observation；把 Observation 放回上下文继续判断，直到完成、失败或触发预算。
  • 循环外要有最大步数、总耗时、Token 预算和异常兜底。
  • 我会把每一步记录成事件，方便回放。

13. ReAct 中 Thought、Action、Observation 各做什么？​

  • Thought 是模型对当前目标和结果的判断；Action 是结构化工具调用；Observation 是外部系统返回的事实。
  • 线上通常不需要把完整思考过程展示给用户，保留可审计的动作摘要即可。
  • 工具报错或返回空值时，Observation 要带状态码、可重试标记和人类可读信息。

14. ReAct 和 Plan-and-Execute 怎么选？​

  • ReAct 边执行边调整，适合路径不确定、工具结果会改变下一步的任务。
  • Plan-and-Execute 先出计划，再由执行器逐步完成，适合步骤较稳定、希望控制成本和并行度的任务。
  • 实际项目可以先规划，再在单步内部用 ReAct；关键是给计划设置校验和重规划入口。

15. Reflection Agent 是什么？什么时候值得加？​

  • 它在初稿后增加检查、批评和修订环节。代码生成、报告生成、故障分析比较适合。
  • 反思本身也会消耗 Token 和时间，所以要设置检查项和最大轮数。
  • 不能把“再问一次模型”当成可靠性证明，最好配合规则校验或测试执行。

16. Planning 应该由框架做还是由大模型做？​

  • 目标拆分和顺序判断通常由模型完成；状态保存、节点跳转、重试和超时由框架/执行器负责。
  • 让模型直接控制所有系统状态，出了问题很难恢复。
  • 我会让模型输出受约束的计划 JSON，执行器只接受白名单节点。

17. Planning 有哪些实现方式？​

  • 一次性生成完整计划；逐步生成下一步；先拆任务再分派子 Agent；用固定图模板加模型选择分支。
  • 任务越开放，越需要允许重规划；任务越关键，越应该把关键步骤固化。
  • 评价规划时看完成率、无效步骤数、重规划次数和耗时。

18. 多轮工具调用时，什么时候继续，什么时候结束？​

  • 看目标是否满足、工具结果是否完整、是否还缺必需参数，以及是否触发最大步数。
  • 模型可以给出 finish 标记，但服务端要再做一次硬校验。
  • 没有证据时不能为了“有答案”强行结束，应该说明缺少什么信息。

19. Agent 为什么会陷入循环？如何止住？​

  • 常见原因是工具返回信息不完整、终止条件含糊、模型反复看到同一错误。
  • 记录 (tool, normalized_args, observation_hash)，重复次数超过阈值就暂停或换策略。
  • 给模型明确的失败出口，例如询问用户、转人工或输出部分结果。

20. 单 Agent 和多 Agent 怎么判断？​

  • 单 Agent 更省 Token、状态更简单，适合目标一致、工具数量有限的任务。
  • 多 Agent 适合角色差异明显、可以并行、需要独立上下文的任务。
  • 如果拆分后只是多了几个 Prompt，却没有独立职责和验收标准，就没有必要上多 Agent。

三、多 Agent、图编排与状态​

21. Multi-Agent 常见协作模式有哪些？​

  • 主管分派任务；流水线接力；多个专家并行后汇总；辩论/评审模式；一个 Agent 把任务交接给另一个 Agent。
  • 模式选择看依赖关系和结果合并难度，别为了“看起来高级”强行拆分。

22. 多 Agent 如何分工和路由？​

  • 先定义每个 Agent 的能力边界、输入输出协议和拒答范围。
  • 路由可以由规则、分类模型或 LLM 决定，关键路径建议规则兜底。
  • 路由结果要带置信度和理由，低置信度时回到澄清问题。

23. LangGraph 的多个子图怎样传递数据？​

  • 共享一个受控 State，或者通过明确的输入输出对象传递，不建议让子图直接读写全局变量。
  • 每个节点声明自己读写的字段，状态更新采用追加事件或版本号，避免并行覆盖。
  • 子图输出要经过 schema 校验，失败时回到上一个检查点。

24. 为什么拆成三个子图，不写成一条 Pipeline？​

  • 子图适合封装有独立状态、重试和验收标准的阶段。
  • Pipeline 更直观，但长链路的分支、人工介入和恢复会越来越难维护。
  • 拆分后要说明额外成本：状态转换、调度开销、跨图观测和错误传播。

25. 多 Agent 并行时会争抢哪些资源？​

  • 模型并发额度、数据库连接、向量库 QPS、文件锁、临时目录和外部 API 配额都可能冲突。
  • 为每类资源设并发上限；写操作用幂等键和锁；读操作尽量走快照。
  • 汇总阶段要处理迟到、失败和重复结果，不能假设所有分支都成功。

26. 多 Agent 的上下文和状态如何隔离？​

  • 每个 Agent 有独立的工作记忆，只传递完成任务所需的最小摘要。
  • 用 conversationId + agentId + taskId 做隔离键，权限在服务端再次校验。
  • 共享数据放在结构化 State，不要把一个 Agent 的整段聊天记录直接塞给另一个。

27. 多 Agent 的结果怎么合并？​

  • 先规定统一 schema，再由聚合器按字段合并；冲突字段保留来源和置信度。
  • 对关键结论做二次校验或让评审 Agent 只检查证据，不重新编造。
  • 某个分支失败时，可以降级为部分结果，并告诉用户缺了哪一块。

28. 多 Agent 出现分歧，怎样让它收敛？​

  • 让各方提交证据、结论和不确定项，聚合器按规则或评分选出结果。
  • 设置最大争论轮数；到阈值仍不一致就转人工或输出多个候选。
  • 不要只靠“再讨论一轮”，那通常只是增加成本。

29. 子 Agent 跑偏了要不要重跑？​

  • 先判断是输入问题、工具失败、模型决策错还是输出格式错。
  • 可重试错误用相同输入重试；决策错误要带上失败原因和修正提示；外部副作用操作必须有幂等键。
  • 超过重试次数就暂停，让上层 Agent 或用户决定下一步。

30. 人工从图中移除一个节点怎么做？​

  • 把人工操作设计成状态事件，例如 NODE_DISABLED，由执行器重新计算可达路径。
  • 不能只改前端显示；后端要校验依赖节点、权限和当前版本。
  • 恢复时使用新版本图或补偿节点，保留原执行记录。

四、RAG 检索与知识库​

31. RAG 的完整流程怎么讲？​

  • 离线链路：解析文档、清洗、切分、加元数据、Embedding、建立索引。
  • 在线链路：问题改写/路由、关键词和向量召回、过滤、重排、拼装上下文、生成带证据的回答。
  • 评测要把召回和生成拆开看，别只看最终回答。

32. 为什么需要 RAG？上下文窗口大了还需要吗？​

  • RAG 让模型访问可更新、可追溯的外部知识，减少把整库内容长期塞进 Prompt。
  • 大窗口适合一次性分析少量完整文件；知识库规模大、权限复杂或内容经常更新时，检索更划算。
  • 关键不在窗口大小，还在证据选择、时效和权限。

33. RAG 和让 Agent 用 grep 自己查文件，怎么比较？​

  • RAG 擅长语义召回和跨文档问答，速度稳定；grep 擅长精确匹配、定位代码行和追踪引用。
  • 文件结构清晰且问题带明确关键词时，工具检索可能更准；自然语言概念搜索更适合向量/混合检索。
  • 实战中可以让 Agent 先用 RAG 找候选，再用 grep 或文件工具确认原文。

34. 长文档切片粒度怎么定？​

  • 先按标题、段落、表格和代码块保留语义边界，再根据 Embedding 模型和召回长度调整 chunk。
  • 太小会丢上下文，太大会混入无关内容；用验证集比较 Recall、MRR 和最终回答。
  • Markdown 没有标题时，可以按段落、列表、代码围栏和长度递归切分，并给每块补来源位置。

35. 父子索引解决什么问题？​

  • 用小子块做精确召回，再返回较大的父块给模型，兼顾命中率和上下文完整性。
  • 父块要去重，避免同一文档占满上下文；子块和父块都要带版本、权限和来源。

36. BM25 和向量检索怎么配？​

  • BM25 对专有名词、错误码、类名和数字很强；向量检索对同义表达和自然语言问题更友好。
  • 可以并行召回后用 RRF、加权分数或统一归一化合并，再交给 Rerank。
  • 权重不要凭感觉定，拿标注问题集做离线对比。

37. Rerank 放在哪个阶段？Top-k 怎么定？​

  • 先用便宜的关键词/向量召回较大的候选集，再用 Cross-Encoder 或其他 Rerank 模型精排，最后截断给 LLM。
  • 初始 k 由召回率和延迟决定，Rerank 后的 k 由上下文预算和答案所需证据量决定。
  • 关注 Recall@k、MRR、nDCG 和端到端正确率，别只看相似度分数。

38. 向量检索为什么会漏掉短 query？​

  • 短 query 信息量少，Embedding 后区分度低；长 chunk 又可能包含很多无关语义。
  • 先做查询扩展、实体补全或问题改写，再结合 BM25、元数据过滤和 Rerank。
  • 用长问题与三五字短问题分别做召回实验，别用一套参数想当然。

39. 什么时候用静态知识库，什么时候用网页检索？​

  • 规章、产品手册、内部 SOP 等稳定且需要权限控制的内容适合静态库。
  • 新闻、价格、实时政策等变化快的信息需要动态搜索，并记录抓取时间和来源。
  • 动态网页要做域名白名单、内容清洗、超时和引用校验。

40. 知识库更新时怎样避免旧内容被召回？​

  • 文档采用版本号或有效时间，更新时原子切换索引；查询过滤当前版本。
  • 删除/替换向量、缓存和关键词索引要有一致的更新事件。
  • 给回答附文档版本或更新时间，发现旧答案时能追到具体索引批次。

五、上下文、记忆与 Harness​

41. Agent 上下文为什么会越聊越长？​

  • 历史消息、工具入参、返回结果、错误重试和中间计划都在累积。
  • 长上下文不只增加费用，还会让模型注意力分散、重复调用工具。
  • 我会按“当前目标、最近动作、稳定事实、可重新获取数据”分层处理。

42. 上下文压缩有哪些常用方案？​

  • 滑动窗口保留最近消息；摘要压缩历史；按任务阶段归档；把大工具结果存外部，只留引用。
  • 摘要要保留目标、约束、已完成步骤、失败原因、关键 ID 和待办，不要只保留聊天主题。
  • 压缩后做事实一致性检查，必要时允许回读原始记录。

43. Claude Code 的“三层压缩”可以怎么理解？​

  • 第一层清理可丢弃的工具细节；第二层把较早对话压成任务摘要；第三层把长文件、日志和历史结果移到外部，按需读取。
  • 核心是逐级降低上下文负担，不是一到阈值就把全部历史总结成一句话。
  • 实现时要保留压缩前后的版本和触发原因，方便排查信息丢失。

44. 短期记忆和长期记忆有什么区别？​

  • 短期记忆服务当前会话，包含最近对话、计划和工具结果；长期记忆保存跨会话仍有价值的偏好、事实和经验。
  • 长期记忆写入要经过筛选、脱敏和用户授权，不能把所有聊天都永久存下来。
  • 两者检索时都要带时间、来源和置信度。

45. Function Call 内容要不要放进短期记忆？​

  • 当前任务需要重放或解释时要保留调用名、参数、结果和状态；大段原始结果可以只留摘要和引用。
  • 完全删掉 Tool Message 会让模型看不见上一步结果，容易重复调用或编造已经完成的动作。
  • 敏感参数要脱敏，副作用操作保留审计 ID。

46. 长期记忆为什么不能简单 FIFO？​

  • 新消息不一定比旧消息重要，FIFO 可能删掉用户偏好、业务约束和关键决策。
  • 可以按重要性、最近使用、时效和来源评分，分层淘汰；过期事实先失效，再异步清理。
  • 每条记忆保留更新时间和冲突版本，出现矛盾时以新证据为准。

47. 上下文压缩怎样验证没有丢关键事实？​

  • 建一组带关键实体、数字、约束和工具状态的回归样本，比较压缩前后回答和动作是否一致。
  • 对摘要做 schema 校验，例如必须包含任务目标、已完成步骤、待办和风险。
  • 线上记录压缩触发率、恢复读取率、重试率和用户纠正次数。

48. Prompt Engineering、Context Engineering、Harness Engineering 有什么区别？​

  • Prompt 关注指令怎么写；Context 关注每一轮给模型哪些信息；Harness 负责模型外的工具、状态、权限、循环、重试和验证。
  • 三者是不同层次的问题，改 Prompt 解决不了权限越界，做摘要也替代不了状态机。
  • 真实项目里我会把规则和证据尽量结构化，让 Harness 兜住模型的不确定性。

49. Harness 具体做哪些事？​

  • 管理工具注册、参数校验、执行超时、重试、并发、上下文裁剪、检查点、日志、权限和输出格式。
  • 它还负责把失败转成模型能理解的 Observation，并决定是否重规划或转人工。
  • 面试时最好讲一个 Harness 规则如何阻止错误调用。

50. Prompt Cache 是什么？适合缓存什么？​

  • 对稳定的 System Prompt、工具定义和长文档前缀做前缀缓存，减少重复输入的计算和费用。
  • 用户隐私、动态权限和会话状态不能混进共享缓存；缓存键要包含模型、版本和租户信息。
  • 评估命中率、失效策略和缓存污染风险。

六、工具调用、MCP 与 Skills​

51. Function Calling 的底层流程是什么？​

  • 服务端把工具名称、描述和 JSON Schema 发给模型；模型只返回结构化调用意图。
  • 应用层解析并校验参数，真正执行函数，再把 Tool Message 发回模型生成下一步或最终答复。
  • 模型没有直接执行函数，权限和副作用控制都在应用层。

52. 为什么要单独设计 Tool Message？​

  • 它把“模型想做什么”和“工具实际返回什么”分开，模型可以根据结果继续决策。
  • 消息里应有 toolCallId、工具名、参数摘要、结果、错误类型和时间。
  • 这样既能重放，也能审计和定位重复调用。

53. 工具描述为什么要写“什么时候用”？​

  • 模型需要在相似工具之间做选择，触发条件比泛泛的能力介绍更有帮助。
  • 描述应包含用途、输入约束、返回结构、不能处理的情况和一个短例子。
  • 工具名、参数名要稳定，避免同一含义出现多种叫法。

54. 如何防止模型编造 API 或传错参数？​

  • 工具只能从服务端白名单注册，参数用 JSON Schema、枚举、类型和业务规则多层校验。
  • 执行前检查资源归属、权限和幂等键；失败信息回传给模型时要说明可修正字段。
  • 记录无效调用率和人工拦截次数，持续改工具说明和示例。

55. 工具超时、空值或部分失败时怎么处理？​

  • 超时先区分可重试和不可重试；空值要带明确状态，不能让模型把空结果当成事实。
  • 达到重试上限后给用户可操作的反馈，例如稍后重试、补充参数或转人工。
  • 多工具任务要允许部分成功，并保存每个工具的状态。

56. 工具调用有哪些安全风险？​

  • 越权读取、危险写操作、参数注入、重复扣款、敏感数据泄露、服务端 SSRF 和沙箱逃逸都要考虑。
  • 采用最小权限、资源级鉴权、域名白名单、参数校验、审批和审计。
  • System Prompt 不是安全边界，服务端必须独立拦截。

57. MCP 解决了什么问题？​

  • MCP 用统一协议描述工具、资源和提示模板，让模型应用更容易接入不同外部服务。
  • 它解决的是连接和发现的标准化，不会自动解决业务权限、可靠性和数据治理。
  • 面试时可以从 Host、Client、Server 和传输方式讲清调用链。

58. MCP 和 Skills 有什么区别？​

  • MCP 更像能力连接层，把外部工具或资源接进来；Skills 是方法和规则的能力包，告诉 Agent 怎样完成一类任务。
  • 一个 Skill 可以调用多个 MCP 工具；一个 MCP Server 也可以被多个 Skill 使用。
  • 两者都要控制上下文加载量和权限范围。

59. MCP Server 和客户端怎么做生产化？​

  • Server 做工具注册、鉴权、超时、限流、版本和错误码；Client 管理连接、能力发现、重试和断线恢复。
  • 长任务可以异步返回任务 ID，避免占住模型请求。
  • 关键调用要记录 server、tool、版本和 traceId。

60. Skills 为什么比把所有规则都写进 Prompt 更合适？​

  • 规则多时，完整 Prompt 会变长，模型也更难找到当前任务真正需要的部分。
  • Skills 先提供索引，命中后再加载详细说明、参考资料和脚本。
  • Skill 要有适用范围、输入输出、失败处理和版本，避免变成另一个“万能 Prompt”。

七、模型、训练与多模态​

61. 模型选型会看哪些指标？​

  • 任务准确率、工具调用稳定性、上下文长度、延迟、价格、中文/代码能力、部署方式和数据合规。
  • 先用代表性问题集做离线对比，再压测 P95 延迟和并发成本。
  • 复杂任务可以大模型规划、小模型做分类或摘要，别所有环节都用最贵模型。

62. 单一模型和多模型路由怎么取舍？​

  • 单一模型接入简单，行为更一致；多模型能按任务和成本切换，但要维护统一协议、评测集和降级策略。
  • 路由依据可以是任务类型、上下文长度、实时负载和租户配置。
  • 切换模型后要重新验证工具调用和结构化输出。

63. 开源模型 Function Calling 较弱怎么办？​

  • 先收紧工具 schema、减少候选工具、提供正反例和少量示例。
  • 再考虑 SFT、LoRA 或专门的工具调用数据；微调前要确认问题来自模型能力还是执行器设计。
  • 用无效调用率、参数正确率和端到端完成率衡量改进。

64. Prompt 微调、SFT 和强化学习分别解决什么？​

  • Prompt 调整行为约束，成本最低；SFT 让模型学会稳定的格式和任务模式；强化学习适合用奖励信号优化长链路策略。
  • 训练数据要包含失败轨迹、工具结果和拒答样本。
  • 先用评测确认值得训练，再投入算力。

65. Agentic CFT 可以怎么理解？​

  • 它强调用完整 Agent 轨迹做持续微调，让模型学习规划、调用、观察和修正，而非只学单轮问答。
  • 训练样本应保留状态变化和工具反馈，不能只截取最终答案。
  • 要防止把错误轨迹也学进去，数据需要自动检查和人工抽样。

66. 为什么训练 Agent 时可能要 Mask Observation Token？​

  • Observation 来自外部工具，不一定是模型应该模仿生成的内容；直接计算损失会让模型学会复制结果，影响决策能力。
  • Mask 后主要训练模型产生计划、动作和最终回答。
  • 是否 Mask 要看训练目标，不能机械套用。

67. GRPO 和 PPO 有什么核心差别？​

  • PPO 通常依赖价值模型做优势估计；GRPO 用同一问题下多条采样结果的相对奖励估计优势，减少价值模型开销。
  • PPO 的优势估计更细，但训练和显存成本高；GRPO 对组内比较依赖更强，奖励设计要稳定。
  • 面试时把信用分配、方差和工程成本一起说，别只背缩写。

68. 多模态 Agent 怎样把视觉信息接给语言模型？​

  • 视觉编码器把图像转成视觉特征，再通过投影层或跨模态模块映射到语言模型可处理的表示空间。
  • Agent 层还要处理图片裁剪、分辨率、坐标、OCR 文本和工具返回的图像引用。
  • 评测要覆盖看图、定位、操作和文字推理，不能只测图片描述。

69. 强化学习 Agent 和 Prompt Agent 有什么不同？​

  • Prompt Agent 运行时靠指令和工具循环完成任务，修改快、训练成本低；强化学习 Agent 通过奖励学习策略，适合重复、可量化的长期任务。
  • 奖励函数不准会让策略钻空子，线上安全边界仍要由执行器控制。

70. Vibe Coding 和 Spec Coding 怎么看？​

  • Vibe Coding 先用自然语言快速试出结果，适合原型和探索；Spec Coding 先写清需求、接口、约束和验收，再让 AI 实现，适合长期维护。
  • 我会在探索阶段用前者，在合并代码前补规格、测试、审查和回滚方案。
  • AI 写出的代码必须经过测试、静态检查和人工阅读。

八、评测、幻觉与输出质量​

71. RAG 评测要拆哪些层？​

  • 检索层看 Recall@K、Hit@K、MRR、nDCG；生成层看忠实性、相关性、完整性和引用正确率。
  • 线上再看一次解决率、追问率、人工转接率、延迟和成本。
  • 指标要和业务目标绑定，不能只追一个分数。

72. Rerank 的有效性怎么验证？​

  • 固定召回候选集，只替换 Rerank 模型，比较 top-k 中相关文档位置和端到端答案。
  • 看 MRR、nDCG、Recall@k 以及延迟增加；还要检查它是否把相似但过时的文档排在前面。

73. Agent 执行效果怎么评估？​

  • 任务是否完成、步骤是否合理、工具调用是否正确、是否遵守权限、耗时和成本如何。
  • 建立成功/失败/部分成功样本，保存完整轨迹，允许回放。
  • 对开放任务可用人工评分或 LLM-as-Judge，但关键指标要有规则和真实结果兜底。

74. 怎么确认 RAG 回答没有幻觉？​

  • 要求回答绑定检索证据，做句子级引用和事实核对。
  • 检索不到证据时明确拒答或请求补充信息；不要用“模型很自信”当通过标准。
  • 线上抽样复核，按错误类型区分召回错、引用错和生成编造。

75. 如何识别剩下那 1% 的错误？​

  • 做高风险问题集、边界输入、对抗 Prompt 和长尾实体测试。
  • 对关键动作增加独立校验器、数据库事实比对和人工审批。
  • 线上监控用户纠正、重复提问、撤销操作和异常转人工信号。

76. 结构化结论用什么格式？​

  • 用 JSON Schema、Java record/DTO 或 Pydantic 模型定义字段、枚举、必填项和约束。
  • 输出解析失败时有限次数重试，仍失败就走修复器或返回可读错误。
  • 结构化输出只保证格式，业务正确性还要靠规则和证据校验。

77. 分析师 Agent 的结论怎样确保正确？​

  • 把结论拆成事实、计算、推断三类；事实必须有来源，计算由代码执行，推断标注置信度。
  • 对关键数字做独立复算，对跨来源冲突保留版本和解释。
  • 输出前走审核节点，审核失败时回到检索或补充数据。

78. Agent 评测集怎么构建？​

  • 从真实日志脱敏抽样，再补充业务边界、失败场景、越权尝试和工具异常。
  • 每条样本记录目标、允许工具、参考证据、期望状态和评分规则。
  • 数据集分训练/调参集和最终验收集，避免反复调到“背答案”。

79. LLM-as-Judge 有哪些坑？​

  • 评审模型会偏好更长、更像自己的答案，也可能忽略事实错误。
  • 给评分标准、参考答案和证据，做多模型或人工抽样校准。
  • 高风险场景不要只依赖模型评审。

80. 如何把评测接进发布流程？​

  • 每次改 Prompt、模型、切分或工具 schema 都跑固定回归集。
  • 设定准确率、工具错误率、P95 延迟、成本和安全拦截阈值，超过阈值阻止发布。
  • 保留版本、配置和轨迹，出现回退时能复现。

九、安全、权限与可靠性​

81. Prompt Injection 怎么防止？​

  • 把用户输入、检索内容和系统规则分层标记，模型只把外部文本当数据，不当指令。
  • 工具权限、敏感字段过滤、输出检查和高危审批放在模型之外。
  • 对网页、文件和代码仓库内容做注入扫描，并把攻击样本加入回归集。

82. 用户诱导 Agent 泄露 System Prompt，怎么处理？​

  • 不返回系统指令原文，只说明当前能做什么；服务端过滤密钥、内部 URL 和策略文本。
  • 即使模型被说服，后端也不应把 Prompt 当作权限凭证。
  • 记录攻击事件，但不要把原始敏感内容写进普通业务日志。

83. Agent 工具不设限制会发生什么？​

  • 可能越权读写、误删数据、重复提交、访问内网、泄露隐私或触发高额费用。
  • 每个工具都要有资源范围、动作级权限、参数上限、速率限制和审计。
  • 高风险写操作先生成预览，再让用户或人工确认。

84. 沙箱逃逸和代码执行如何防止？​

  • 代码执行放进隔离容器或受限运行时，限制网络、文件系统、系统调用、CPU、内存和执行时间。
  • 运行前扫描危险命令，运行后清理临时文件并收集审计信息。
  • 不把宿主机凭证、Docker Socket 或内部网络直接暴露给 Agent。

85. 怎样设计权限模型？​

  • 按租户、用户、Agent、工具和资源做最小权限控制，读写权限分开。
  • 权限判断要基于服务端身份和资源归属，不能相信模型传来的 userId。
  • 权限变更要版本化，执行时再次检查，审计记录保留决策依据。

86. 如何防止重复执行有副作用的工具？​

  • 使用业务幂等键、请求去重表和状态机；重试只针对明确的瞬态错误。
  • 先查询当前状态，再决定是否执行；支付、退款、删除等操作增加人工确认。
  • 工具响应要区分“已成功”“处理中”“未知”，不能把超时当失败直接重做。

87. 生产 Agent 如何做超时和降级？​

  • 为模型、检索、工具和整个请求分别设超时预算，避免某一步耗尽全部时间。
  • 模型不可用时走备用模型或模板回答；检索失败时说明无法确认；高风险任务转人工。
  • 监控超时率、降级率和用户完成率，避免只看服务存活。

88. 如何设计重试？​

  • 只重试网络抖动、限流等可恢复错误，使用指数退避和随机抖动。
  • 参数错误、权限错误和业务冲突应直接返回，不要盲目重试。
  • 重试次数、总预算和幂等策略由 Harness 统一管理。

89. Agent 需要哪些可观测性？​

  • 记录 trace、模型版本、Prompt/工具版本、输入输出摘要、Token、耗时、重试和最终状态。
  • 敏感内容脱敏，原文按权限存储；支持按任务回放每个节点。
  • 指标至少包括成功率、工具错误率、循环率、P95 延迟、成本和人工接管率。

90. 如何支持暂停、恢复和断点续跑？​

  • 每个节点完成后写检查点，状态包含图版本、任务版本、工具结果和待办。
  • 恢复时校验权限、状态版本和外部资源是否仍有效。
  • 对已经产生副作用的步骤用幂等和补偿动作，不能简单从头再跑。

十、工程化与生产落地​

91. Agent 系统怎样做异步任务处理？​

  • 请求线程只负责创建任务和返回 taskId，真正执行交给消息队列或任务调度器。
  • Worker 更新状态、写事件和发送进度；前端用 SSE/WebSocket 或轮询读取。
  • 任务表保存状态、重试次数、租约和错误原因，避免只靠内存。

92. 消息队列为什么比直接用数据库传任务更合适？​

  • 队列适合削峰、重试和消费者解耦；数据库适合持久化事实和查询。
  • 实际上通常两者一起用：数据库记录任务状态，队列传递待执行事件。
  • 要处理重复投递、顺序、死信和消息与数据库事务的一致性。

93. Redis 在 Agent 系统里能做什么？​

  • 会话短期状态、分布式锁、限流、任务租约、语义缓存和流式进度都可以用 Redis。
  • 不同数据设置不同 TTL；长期记忆和审计记录放持久化数据库。
  • 缓存键要带租户、模型/Prompt 版本和权限范围，防止串数据。

94. Agentic RAG 和传统 RAG 有什么区别？​

  • 传统 RAG 的链路通常比较固定，按照问题改写、检索、重排和生成依次执行；Agentic RAG 会让 Agent 根据当前问题决定要不要检索、去哪里检索、是否需要换关键词再查一次。
  • Agentic RAG 更适合复杂问题和多数据源场景，不过链路更长，成本、延迟和调试难度也会增加。
  • 回答时最好结合项目说明哪些环节交给模型决策，哪些环节仍由固定规则控制。

95. Milvus 和自己写余弦相似度有什么区别？​

  • 自己遍历向量简单直观，但数据一大就变成线性扫描，索引、持久化、过滤和并发都要自己补。
  • Milvus 提供 ANN 索引、分片、持久化、标量过滤和运维能力，也带来部署与调参成本。
  • 小规模原型可先用内存检索，生产选型看数据量、QPS、更新频率和团队运维能力。

96. 多个工具存在前后依赖时，调度引擎怎么设计？​

  • 先把任务拆成带依赖关系的执行图，只有上游成功并产出所需字段，下游工具才能进入可执行状态。
  • 没有依赖的节点可以并行；共享模型额度、数据库连接或外部 API 配额时，还要设置并发上限。
  • 调度器负责状态、超时、重试和终止，模型负责生成或调整计划，不能让模型直接修改任务状态。

97. 如何让 Agent 把成功经验沉淀下来？​

  • 一次执行结束后，先从完整轨迹中提取任务类型、有效步骤、失败原因和最终结果，再经过规则或人工审核写入经验库。
  • 下次遇到相似任务时检索相关经验，作为参考计划或工具使用提示，不能未经校验就照搬旧步骤。
  • 经验需要记录来源、版本、适用条件和效果反馈，长期无效或已经过期的内容要降权、失效或删除。

98. Agent 执行太慢，工程侧和模型侧分别怎么优化？​

  • 工程侧先看链路：减少无效循环和重复检索，让无依赖工具并行执行，对稳定前缀和结果做缓存，并给每一步设置时间预算。
  • 模型侧可以缩短上下文、压缩工具描述、减少输出长度，或者让小模型处理路由、分类和摘要，把复杂推理留给大模型。
  • 优化前先拆出模型耗时、工具耗时和排队耗时，避免只换一个更快的模型却没有解决真正的瓶颈。

99. 包含多轮模型调用和工具执行时，流式输出怎么设计？​

  • 不要只流式返回模型生成的文字，还要定义“开始规划、正在调用工具、工具完成、生成回答、任务失败”等事件。
  • 每个事件携带 taskId、stepId、事件类型和序号，前端才能按顺序更新进度，断线重连后也能从上次位置继续接收。
  • 内部思考过程和敏感工具参数不直接展示，可以给用户一段简短的状态说明。

100. Agent 扩展到大量设备，同时覆盖本地端和云端，架构怎么设计？​

  • 云端负责身份、任务编排、模型路由、策略下发和全局观测；本地 Agent 负责设备数据读取、低延迟执行和断网时的有限自治。
  • 每台设备要有独立身份和最小权限，云端下发的任务带版本、有效期和签名，本地执行前再次校验。
  • 还要处理设备在线状态、灰度发布、能力差异、离线任务、失败补偿和日志回传，不能假设所有设备始终联网且配置一致。

给自己一份复习清单​

我建议小伙伴最后不要只说这些概念和明细，要拿自己的项目来进行逐项的对照：

  • 能不能在 1 分钟内梳理出请求链路，并指出自己负责的节点？
  • 每个工具有没有权限、超时、幂等和审计？
  • RAG 是否有标注集，能不能分清召回错和生成错？
  • 上下文压缩后，任务目标、约束和工具状态还在不在？
  • 多 Agent 是否真的带来并行或隔离收益？
  • 模型换供应商、工具失败、消息重复和服务重启时，系统能不能恢复？

这些问题答到“为什么这样做、怎么验证、失败怎么办”，面试官通常就有足够的空间继续聊项目细节了。

🎁优惠