Agent 开发面试最高频 50 题与参考答案

目录

• 一、Agent 核心概念与架构（第 1–9 题）
• 二、工具调用与 MCP（第 10–17 题）
• 三、上下文与记忆（第 18–24 题）
• 四、RAG 与检索（第 25–32 题）
• 五、多 Agent 协作（第 33–36 题）
• 六、评测、可靠性与安全（第 37–44 题）
• 七、性能、成本与系统设计（第 45–50 题）

---

一、Agent 核心概念与架构

★★★ 1. 什么是 AI Agent？与传统 LLM 应用 / Workflow（工作流）/ 自动化脚本的本质区别？

参考答案：

• AI Agent（智能体）是能够感知环境、推理决策、制定计划、执行行动的自主 AI 系统，核心差异在于自主性和闭环反馈：感知→推理→规划→执行→观察→循环，多步自主决策、有状态、动态流程。
• 传统 LLM（大语言模型）应用是"人设计流程，模型填内容"：输入→输出单次调用、无状态、确定性流程。以 RAG（检索增强生成）管道为例，检索、拼接 prompt（提示词）、生成每一步都由代码硬编码控制，LLM 只负责文本生成这一个环节。
• Agent 是"人设定目标，模型自己决定怎么达到目标"：控制流的归属交给 LLM 自身，模型根据中间结果动态决定下一步是调用搜索工具、执行代码，还是直接回答、继续探索或结束任务。
• Workflow（工作流）/自动化脚本的步骤固定、路径可枚举，分支和循环都由开发者预先写死；Agent 的执行路径不可预知，由模型根据环境反馈动态选择动作。
• 判定系统"不只是把大模型接口包成聊天应用"的运行时特征：系统能围绕目标、根据环境反馈选择下一步动作，并管理行动后的状态与结果（含终止条件）；不能把"循环调用模型"就等同于可靠自治系统。
• 两者不是互斥标签：固定流程中也可以包含 Agent 节点，Agent 内部也会用到确定性代码。
• 代价：Agent 带来不确定性和可控性挑战，生产环境需配合 guardrails（护栏，输出校验与安全过滤）、超时控制、Human-in-the-loop（人工介入）等机制。

面试官关注点： 能否抓住"控制流归属"这一本质区别展开论述，同时意识到自主性带来的可控性代价，而不是罗列功能差异。

★★★ 2. 一个 Agent 系统由哪些核心模块组成（Brain 大脑 / Planning 规划 / Memory 记忆 / Tool Use 工具 / Observation 观察）？

参考答案：

• Agent 本质是 LLM + 感知 + 规划 + 行动 + 记忆的闭环系统，能自主完成多步骤任务；典型架构可参考 OpenAI Function Calling（函数调用）模式、LangChain Agent、AutoGPT 循环架构。
• Brain（大脑）：LLM 负责推理与决策，包括意图理解、信息综合、因果推断，是系统的认知核心。
• Planning（规划）：任务分解（Task Decomposition）、优先级排序、资源分配；方法包括 CoT（思维链）、ToT（思维树）、ReAct（推理-行动）、Plan-and-Execute（先规划后执行）。
• Memory（记忆）：短期记忆（当前对话上下文，存放于 LLM 上下文窗口）、工作记忆（当前任务中间状态，如 scratchpad 暂存区）、长期记忆（跨会话持久化，向量数据库 / 文件系统）。
• Tool Use（工具使用）：通过 Function Calling 或 MCP（Model Context Protocol，模型上下文协议）调用搜索引擎、API、数据库、代码执行器；适合做成工具的是 LLM 本身做不好的事——实时数据查询、精确计算、外部系统操作（下单/发邮件）、文件读写。
• Observation（观察）：接收工具返回结果并反馈给 LLM，控制流一般是循环式 Perceive（感知）→ Think（思考）→ Act（行动）→ Observe（观察），直到任务完成或达到最大轮次。
• 工程层面还需：Guardrails（输出校验/安全过滤）、日志与可观测性、错误重试与降级策略。

面试官关注点： 模块划分是否完整且能说清各模块职责边界，以及循环控制流如何把它们串成闭环。

★★★ 3. ReAct（推理-行动循环）如何工作？与 CoT（思维链）的区别与联系？

参考答案：

• ReAct（Reasoning + Acting，推理+行动）由 Yao et al. 2022 提出，核心思想是把推理和行动交织进行：Thought（思考）→ Action（行动）→ Observation（观察）循环，直到能给出最终答案。
• 三要素：Thought 用自然语言分析当前状态、规划下一步；Action 调用外部工具（搜索、计算器、API）；Observation 接收工具返回结果并进入下一轮。
• 与 CoT（Chain-of-Thought，思维链）的区别：CoT 只推理不行动，无法用外部事实验证，容易产生幻觉；ReAct 通过工具获取真实观察做锚点，显著减少幻觉。
• 联系：ReAct 的 Thought 本质是内嵌的思维链——ReAct 建立在 CoT 逐步推理能力之上，只是把"想"和"做"交替进行；对比 Action-only（只行动不推理），ReAct 具备规划和错误分析能力。
• 收益：可解释性强（Thought 暴露推理过程，便于调试和建立信任）、能根据 Observation 反思并调整策略、动态决定调用什么工具、何时停止；在 HotpotQA（多跳问答数据集）上比 CoT 提升约 6%，FEVER（事实验证数据集）约 10%。
• 局限：串行执行导致多步任务延迟高、无全局规划容易走弯路或陷入循环、上下文随步骤快速膨胀。
• 工程落地：LangChain 的 AgentExecutor、OpenAI Function Calling + 循环调用本质上都是 ReAct 变体；实现时把一次决策表示为结构化动作提议（工具名+参数+调用 ID），分离模型提议与真实执行，不要把模型输出的"已执行"文本当作工具成功凭证。

面试官关注点： 能否讲清 Thought-Action-Observation 循环机制，并从"是否行动、能否外部验证"角度对比 CoT，而非只背定义。

★★★ 4. ReAct 与 Plan-and-Execute（先规划后执行）各自适用什么场景？如何混合使用？

参考答案：

• ReAct 适用：路径短、需要边观察边选工具的探索性任务，步骤数不确定的多步推理 + 信息检索问答，中等复杂度任务。
• ReAct 不适用：一步完成的简单任务（模式过重）、需要全局规划的极端复杂任务、需要并行执行子任务的场景。
• Plan-and-Execute 适用：步骤可预先分解的结构化任务（写研究报告、订机票+酒店+行程规划），需要进度展示、人工审批的场景；还可"强模型规划 + 弱模型执行"降低整体成本。
• Plan-and-Execute 不适用：高度不确定的探索性任务（无法预先规划）、实时交互场景（规划阶段延迟高）；初始计划可能不准确，Replan（重规划）会增加复杂度，Planner + Executor 双重 LLM 调用成本更高。
• 混合用法（Adaptive Planning，自适应规划）：先粗粒度 Plan 生成有序步骤列表，执行环节用 ReAct 子循环动态处理，遇异常时由 Replanner（重规划器）根据中间结果受控重规划。
• 重规划时机：瞬时故障（如网络抖动）适合有界重试；目标变化、前提被否定、工具永久不可用、多次重试无进展时才重新规划，且要限制重规划次数和总预算。
• 选型方法：用同一任务集比较成功率、成本、延迟与可解释性；两种方案都需外部预算和失败恢复机制，不能仅凭框架流行度决定架构。

面试官关注点： 能否用同一业务需求对比两种范式的取舍维度，并给出混合架构而非二选一的站队式回答。

★★★ 5. Agent、Orchestrator（编排器）、Harness（驾驭层）、Runtime（运行时）分别负责什么？为什么 while 循环不够？

参考答案：

• Agent：以 LLM 为大脑、负责感知-推理-行动决策的智能体本体，决定"做什么"。
• Orchestrator（编排器）：多 Agent / 多节点系统的调度者，负责任务分解、分发给专业子 Agent、结果汇总与质量把控（主从 Supervisor、Pipeline 流水线、Debate 辩论等模式），决定"谁来做、什么顺序"。
• Harness（驾驭层）：围绕模型的执行保障层，可拆为输入/上下文构造、模型适配、工具执行、持久化状态、权限审批、资源预算、观测评测与恢复等模块，核心是控制平面与模型决策分离。
• Runtime（运行时）：真正驱动循环与工具执行的引擎，管理状态转换、checkpoint（检查点）持久化、断点恢复与超时控制。
• 为什么 while 循环不够：权限判定、资金校验、超时和提交等不能仅由模型自行决定——模型可提出计划，但执行层必须强制约束；一份长提示词不能代替运行时控制。
• 循环之外还必须补齐：明确终止条件（业务完成、显式失败、等待外部输入、预算耗尽）、循环/无进展检测（重复动作、最大步数、截止时间、成本上限）、错误重试与恢复。
• 完成判定：任务完成应由可检查的产物证明，而非只看模型说"结束"；软终止与硬上限配合，超限时保存状态和未完成原因——最大步数只保证停下来，不保证做对。

面试官关注点： 能否把"模型决策"与"运行时控制"分层讲清，理解 Harness 各模块的失败边界，而不是以为套个死循环就是 Agent。

★★ 6. 什么场景不该用 Agent？自主决策 Agent 与固定 Workflow / 低代码节点编排如何取舍？

参考答案：

• 不该用 Agent 的场景：简单规则/固定流程能搞定的任务、低延迟要求的实时场景、成本敏感的高频调用、单步可完成的简单查询；多轮工具调用意味着多次 LLM 推理 + API 调用，成本快速累积。
• 固定 Workflow（工作流）/低代码节点编排适用：流程固定、路径可枚举、高合规要求的链路——确定性编排更可控、可测试、可审计。
• 自主决策 Agent 适用：中间信息未知、需要动态选择工具、执行步骤无法预先枚举的环节。
• 取舍维度：变化频率（流程多久变一次）、失败代价（错误操作是否可逆）、维护成本；原则是先用更简单的方案作基线，确认瓶颈后再引入 Agent。
• 混合架构：用工作流约束总体阶段，让 Agent 仅在授权节点内探索，并防止 Agent 越过工作流阶段。
• 分类看本质不看界面形态：拖拽式低代码编排也可能包含自主 Agent 节点，固定流程与 Agent 不是互斥标签。
• 安全边界：即使把固定 workflow 改成 Skill（技能/知识包），身份、租户隔离、参数语义、审批、预算和状态转换仍须由确定性执行层强制，关键动作默认拒绝——"模型看过说明"不等于操作已获授权。

面试官关注点： 是否具备"能不用就不用"的工程克制，以及用变化频率、失败代价等维度论证取舍，而非一味堆 Agent。

★★ 7. Agent 如何做任务规划？CoT / ToT（思维树）/ GoT（思维图）对比？

参考答案：

• 任务规划 = 任务分解（Task Decomposition）+ 子目标设定 + 计划执行与修正；CoT / ToT / GoT 是逐级增强搜索能力的规划/推理方法。
• CoT（Chain-of-Thought，思维链）：线性推理链，"Let's think step by step（让我们一步步思考）"，适合数学、逻辑等结构化问题；GSM8K（数学推理基准）上 PaLM 540B 从 18% 提升到 57%。
• ToT（Tree-of-Thoughts，思维树）：推理组织为树结构，每步生成多个候选思路，通过评估（LLM 自评或启发式）选择最优分支并支持回溯；适合需要探索试错的问题（如 24 点游戏、创意写作）。
• GoT（Graph-of-Thoughts，思维图）：推理拓展为有向图，思路节点可合并、分裂、循环引用，支持更复杂的推理拓扑（如把多个子问题的解合并为最终答案）。
• 选型经验：大多数场景 CoT 足够且高效；ToT / GoT 在需要搜索、回溯的复杂问题上更优，但多次 LLM 调用带来更高计算成本。
• 落地形态：Plan-and-Execute 中 Planner（规划器）生成有序步骤、Replanner 按中间结果调整；Reflection（反思/自我修正）在执行后自我评估并迭代改进计划。
• 执行中的计划维护：区分可重试错误（瞬时故障，有界重试）与需改计划错误（目标变化、前提被否定、工具永久不可用），限制重规划次数与总预算，新计划要与原验收条件和权限对照。

面试官关注点： 能否说清三种推理结构的拓扑差异与成本权衡，并落到"规划-执行-修正"的工程闭环上。

★★ 8. 为什么用图式状态编排（如 LangGraph）而不是链式调用？LangChain vs LangGraph 怎么选？

参考答案：

• 选型依据是业务所需控制流：当任务有分支、循环、并行、审批与断点恢复时，图式状态编排（如 LangGraph 的 StateGraph 状态图）能显式表达状态转换；纯线性链路则链式调用更简单。
• 链式调用（LangChain Chain）：线性管道，简单直观、上手快，适合固定顺序的 RAG / 摘要类流水线；表达不了复杂分支与回环，流程一变就要改代码结构。
• LangGraph：状态机/图式编排，节点 + 边 + 共享 State（状态），支持条件分支、循环、并行、Human-in-the-loop（人工介入）审批和 checkpoint（检查点）持久化断点恢复，适合需要精确控制流程的复杂 Agent。
• LangChain vs LangGraph 怎么选：简单线性流程或快速原型选 LangChain；复杂控制流、需要状态持久化与恢复选 LangGraph；也可组合使用（LangChain 生态做工具集成，LangGraph 做编排）。
• 评价指标：可控性、可观测性（日志、trace 追踪、调试工具）、扩展性、社区生态、生产就绪度（并发/容错/监控）；先给出业务所需控制流，再用复杂度和恢复测试证明选型。
• 两个易错点：LangGraph 的 checkpoint 不是任意代码行快照，节点重执行仍要考虑幂等（idempotency，重复执行结果一致）；不能声称使用图框架就自动获得业务 exactly-once（精确一次）语义。

面试官关注点： 是否从控制流复杂度出发选型而非追新，且了解 checkpoint 恢复与幂等这类图框架的"隐藏成本"。

★★ 9. 如何设计跨模型兼容的 Agent？模型运行时与工具运行时如何解耦？

参考答案：

• 解耦原则：控制平面与模型决策分离——模型运行时（推理/决策）与工具运行时（执行/副作用）各自定义稳定协议接口，模型可替换而工具无需重写。
• 模型层统一：消息格式、工具定义（tool schema 工具模式）、结构化动作、流事件（streaming events 流式事件）、用量（token 计量）和错误模型。
• 工具层统一：鉴权、参数校验、执行回执与幂等（idempotency，重复调用结果一致）。
• 为不同厂商写能力适配器（adapter，适配层），对不支持的能力保留显式降级（如厂商不支持并行工具调用就降级为串行）；协议统一不等于能力相同。
• 不要丢掉原始错误和用量信息，否则兼容层会"假成功"，排障和成本核算都会失真。
• 模型升级/切换前必须跑工具兼容测试和任务回归评测（同一任务集对比成功率、成本、延迟）。
• 工具接入可借 MCP（Model Context Protocol，模型上下文协议）标准化：一次开发 MCP Server（工具服务端），所有支持 MCP 的 Client（客户端）即插即用，减少 N×M 适配成本。

面试官关注点： 能否给出模型层/工具层各自的协议边界与降级策略，理解"协议统一不等于能力相同"这一关键事实。

二、工具调用与 MCP

★★★ 10. Tool、Function Calling（函数调用）、MCP（模型上下文协议）与 Skill（技能）的边界是什么？

参考答案：

• Tool（工具）是边界清晰、输入输出可验证的原子能力，如 create_issue（创建议题）、get_weather（获取天气），关注单个能力的契约
• Function Calling（函数调用）是模型推理层的能力，解决"模型怎么调工具"：模型输出结构化调用指令（函数名+参数），由应用解析执行；各厂商格式不同，绑定特定模型
• MCP（模型上下文协议）是通信协议层的开放标准，解决"工具怎么接入 AI 应用"：统一工具的发现、调用与管理，跨模型、跨平台可移植
• Skill（技能）是任务方法层：把领域知识、执行步骤和多个工具组织成可复用的任务流程，适合覆盖边界清晰的单一 Tool 无法完成的多步骤领域任务
• 三者互补而非竞争：MCP Server（服务端）暴露工具 → Host（宿主应用）通过 Function Calling 让模型决定调用哪个 → 平台以 Plugin（插件）形式分发
• Skill 不替代底层工具的授权，也不一定是独立 Agent（智能体）；不同产品对 Skill 的定义有差异，应先声明所用语义，不要把 Skill 当成 MCP 协议里的通用同义词

面试官关注点： 是否能按"模型层/协议层/平台层/任务层"分清概念边界，而不是混用术语。

★★★ 11. Function Calling 的工作原理？模型实际执行函数吗？它是如何学会"何时调用、如何生成参数"的？

参考答案：

• 工作流程：用户请求 → 模型推理判断需要工具 → 输出结构化调用指令（函数名+参数 JSON）→ 应用解析、校验并执行函数 → 结果以 tool message（工具消息）注入上下文 → 模型基于结果生成最终回复
• 模型实际不执行任何函数：它只是"决策者/翻译器"，把自然语言翻译成结构化的工具调用意图，真正的执行在应用层
• "何时调用"依据工具描述（description）：模型据此判断工具的功能与适用场景，含糊的描述会导致误调用或漏调用
• "如何生成参数"依据 JSON Schema（结构约束）：类型、枚举（enum）、必填项等约束决定参数的生成格式；strict（严格）模式可保证输出 100% 符合 schema
• 这一能力来自训练阶段对"工具描述→调用指令"模式的指令微调与对齐训练，推理时再结合用户意图和 schema 生成调用
• 可用 tool_choice（工具选择策略）控制行为：auto（自动决定）、required/any（强制调用）、指定工具名、none（禁止调用）
• 常见"幻觉"问题：不该调用时强行调用、编造参数值、声称调用了工具但实际跳过；需靠描述调优、strict 模式和应用层参数校验防治

面试官关注点： 是否清楚"模型只出意图、应用负责执行"的分工，并理解描述与 schema 对调用质量的决定性作用。

★★★ 12. 如何设计一个好的工具描述（JSON Schema）？多工具场景如何避免模型选错工具？

参考答案：

• 名称清晰：动词+名词表达意图（create_issue 而非 issue）
• description 说明功能、适用场景、限制条件、返回格式，并在描述中给出示例值
• 参数严格约束：每个参数有类型、描述、约束（enum 枚举/min/max/pattern 模式），返回值结构化
• required（必填项）数组明确标注；可选参数提供合理默认值
• 反例警示：名称含糊（search）、描述过短（"搜索东西"）、参数无描述（q、opts）会导致模型误调用或漏调用——描述差是 Agent 效果差的首要原因之一
• 多工具防选错：描述精确区分、避免功能重叠；减少暴露数量，只提供当前场景需要的工具（动态工具集）；名称语义清晰
• 在 system prompt（系统提示词）中给出工具选择指南，用 few-shot（少样本）示例展示正确的工具选择模式
• 每次修改工具描述后跑回归测试，生产环境监控工具调用成功率与参数错误率

面试官关注点： 能否给出可落地的描述清单，并意识到工具功能重叠与数量膨胀是选错工具的主因。

★★★ 13. 工具调用失败 / 超时时，如何安全重试并保证幂等（不重复副作用）？

参考答案：

• 错误分类处理：参数错误不重试，返回明确信息让模型修正参数；业务错误返回业务语义描述让模型换策略；瞬时错误（网络超时、限流 429）自动重试+指数退避（exponential backoff，如 2^n 秒、上限 30 秒）；系统错误（500）返回友好提示
• 重试要有上限（如最多 3 次），禁止无限重试；退避与熔断的总时长受任务预算约束
• 幂等设计：同一调用多次执行应产生相同结果；为每次调用绑定唯一 ID，并区分"模型参数错误、工具错误、执行结果未知"三种状态
• 超时处理：设置合理阈值（网络调用 15-30 秒）；超时后返回明确错误而非静默等待；长耗时任务改为异步模式（提交+轮询）；支持取消机制
• 有副作用的写操作重试要防重复执行：执行结果未知时先查询或对账，确认未生效再重发，重试用新的请求避免重复副作用
• 失败后优雅降级：告知用户工具暂不可用、提供替代工具、基于已有知识给出部分回答，绝不编造工具返回的数据

面试官关注点： 是否按错误类型区分重试策略，并把"执行结果未知"与幂等/对账作为安全重试的核心。

★★★ 14. MCP 的架构与三大能力原语（Tools / Resources / Prompts）？解决了什么核心问题？

参考答案：

• 核心问题：M×N 集成碎片化——此前每个 AI 应用都要为每个外部服务写定制集成代码；MCP 让工具写一次即可被所有支持 MCP 的 Host 调用，集成复杂度降为 M+N，类比 USB（通用串行总线）之于外设
• 同时解决：工具发现困难（协议内建 tools/list 发现机制）、工具结果注入上下文无统一规范、安全边界模糊、生态孤岛不可复用
• 四大组件：Host（宿主应用，管理生命周期与安全策略）、Client（客户端协议实例，与 Server 1:1 连接、负责能力协商与消息路由）、Server（服务端，暴露 Tools/Resources/Prompts，专注单一数据源封装）、Transport（传输层：stdio 标准输入输出、HTTP+SSE 服务器推送事件、Streamable HTTP 流式 HTTP）
• 三大能力原语与控制方：Tools（工具，模型控制，模型决定是否调用，如 create_issue）；Resources（资源，应用控制，被动提供的数据源，如文件内容、数据库 schema）；Prompts（提示模板，用户触发，如"总结这个 PR"）
• Tool 与 Resource 的边界：Tool 是模型主动调用的函数、可能有副作用；Resource 是"背景信息"类数据，由应用程序控制注入时机
• 建连时做 capability negotiation（能力协商），双方只使用共同支持的能力，保证向前兼容——旧 Client 不会因不认识新特性而崩溃

面试官关注点： 是否理解三大原语"由最合适的角色控制"的设计理念，以及 M×N→M+N 的核心价值。

★★ 15. MCP vs Function Calling vs Plugin（插件）vs A2A（智能体间协议）的区别？

参考答案：

• Function Calling：模型推理层——"模型怎么调工具"；各厂商格式不一（tool_calls/tool_use/functionCall），绑定特定模型，工具靠开发者手动注册
• Plugin（插件）：应用平台层——"平台怎么管工具"；平台私有规范，靠平台商店分发、注册与计费，绑定特定平台
• MCP：通信协议层——"工具怎么接入 AI 应用"；开放标准，内建 tools/list（工具列表）发现与权限协商，跨模型跨平台，典型场景是企业级 Agent（智能体）集成
• A2A（智能体间协议）：智能体与智能体之间的协作与互操作协议，解决 Agent 之间的对话与任务分工；与前三者"Agent 调工具"不在同一问题域，可与 MCP 互补——MCP 管"Agent 用工具"，A2A 管"Agent 之间协作"
• 关键对比维度：定义层、标准化程度、工具发现方式、可移植性、状态管理（MCP 连接级有状态，Streamable HTTP 可无状态）、安全模型（API Key / OAuth / 协议内建权限协商）
• 互补关系：MCP Server 暴露工具 → Host 通过 Function Calling 让模型决定调用哪个工具 → 平台以 Plugin 形式分发，三者不是竞争关系
• 相关辨析：OpenAPI（REST 接口规范）与 MCP 不冲突——用 OpenAPI 描述 HTTP 接口，用 MCP 让 AI 模型发现并调用，社区有自动转换工具

面试官关注点： 能否按"模型层/平台层/协议层/智能体间"分层对比，并指出四者是互补而非替代。

★★ 16. 工具参数校验、权限边界与高危操作人工确认（Human-in-the-loop，人在环中）如何设计？

参考答案：

• 校验链路分层：先用允许的工具目录和 schema（结构）校验动作与参数格式，再校验身份、租户、业务前置条件及预算；未通过校验前不得调用真实工具
• Schema 校验只证明结构合法：字符串是合法 ID 不代表它属于当前用户；还需对象级鉴权、业务约束与状态/版本检查，语义校验放在与写入一致的事务边界内
• 权限边界分层设计：用户层（认证+RBAC 角色权限，确定可用工具集）、工具层（每个工具声明所需权限和危险等级）、参数层（约束可操作的资源范围）、运行时（速率限制防滥用、审计日志可追溯）、确认机制
• 权限在实际执行入口校验，身份来自可信会话而非模型参数（租户身份由服务端注入）；规划时预检、执行前再检，不要只在 UI（用户界面）按钮上限制权限
• 高危操作人工确认：删除、支付、外发、跨租户访问等动作按风险策略审批；审批绑定具体资源、参数、版本、有效期和执行主体，参数变化后需重新审批
• MCP 落地：Server 用注解声明危险等级（如 readOnly 只读/destructive 破坏性），Host 维护白名单只暴露授权工具，敏感工具调用前要求用户确认；防御 Prompt 注入（提示注入）时同样以人工确认兜底

面试官关注点： 是否强调"执行入口校验+可信身份"，以及审批绑定资源/参数/版本而非一次性放行。

★★ 17. 工具从 10 个增长到上千个，如何做工具路由并控制描述的 Token 开销？

参考答案：

• 分层路由：按角色、权限和业务域先预筛工具，再用检索取少量候选工具描述给模型；模型选中后按需加载完整 schema 并复核权限
• 缓存的工具目录需版本化（描述/schema 变更后失效重建）；候选不足时允许有界扩展（逐步放宽筛选条件补召回）
• 安全红线：敏感工具不因语义相似就进入候选集被暴露给模型
• Token（词元）开销优化：精简工具描述、去掉冗余信息；合并功能相似的工具、减少暴露数量；工具返回结果只保留必要字段；链式调用的中间结果摘要后再注入
• 明确场景用 tool_choice 直接指定工具，减少模型的推理开销
• 评测闭环：跟踪路由的检索覆盖率（正确工具是否进入候选集）与端到端成功率；只缩短描述而不测路由召回，可能把成本优化成能力退化
• 追问应对：正确工具没进候选集时，用有界扩展、同义词/多路检索兜底，而非盲目全量暴露所有工具

面试官关注点： 是否有"预筛→检索→按需加载"的路由架构，并用覆盖率评测防止优化变成能力退化。

三、上下文与记忆

★★★ 18. 长上下文、Session（会话）、Working State（工作状态）与长期 Memory（记忆）如何分层？

参考答案：

• 分层依据是生命周期与读取范围：Working State（工作状态/工作记忆）是当前上下文窗口里的计划、变量与中间结果，单次请求内有效；Session（会话/短期记忆）保存一次会话或任务的近期交互；长期 Memory（记忆）持久化保存经确认的稳定偏好与跨任务经验
• 长上下文本身是载体而非层级：上下文是当前决策可用的临时工作集，长期记忆保存跨任务仍有价值、且有来源、权限和时效的事实，二者边界在于是否值得跨任务保存
• 三层是设计概念，不必对应三套数据库，但必须分别定义生命周期和读取范围，每条事实附来源
• 上下文组装按优先级分层：System Prompt（系统提示）→ 事实表（最新状态）→ 关键节点（决策历史）→ 最近 N 轮原文 → 滚动摘要 → 按需召回的长期记忆
• 存储上可分热/温/冷层：热层是当前上下文（约 200-500 Token（词元）），温层是会话级文件按需加载，冷层放向量数据库（Vector Database）做语义检索召回
• 不值得长期保存的：瞬时错误、未经证实的推断、秘密以及无保留依据的信息；长期记忆不是聊天日志的无限复制
• 业务状态（如订单状态）不要只存在摘要里，应放在结构化状态中，避免压缩丢失

面试官关注点： 能否按生命周期与读取范围划清各层边界，而不是把所有信息都塞进上下文或都存进长期记忆。

---

★★★ 19. Agent 记忆系统怎么设计？短期 / 工作 / 长期记忆分别存什么、如何相互转化与遗忘？

参考答案：

• 分工：工作记忆存当前任务的中间状态（Scratchpad（草稿本）、变量、当前计划），生命周期为单次请求；短期记忆存当前会话的 message history（消息历史），受 Token 限制需截断或摘要；长期记忆存经确认的稳定偏好与跨任务经验
• 存储选型：短期用 Redis/内存，长期用向量数据库 + 结构化数据库，用户画像/偏好类信息放关系型存储更合适
• 短期→长期转化：会话结束时用 LLM（大语言模型）提取摘要与关键事实，embedding（向量化）后写入长期存储；下次会话开始时检索相关记忆注入 prompt（提示词）
• 写入前做重要性过滤：用户显式偏好表达、关键决策节点、跨会话状态值得持久化；"好的""收到"这类确认性对话直接丢弃；不要把模型猜测当稳定用户事实
• 召回策略：语义检索 + 时间衰减 + 频率加权决定召回优先级，按需召回而非会话开始就全量加载
• 遗忘与更新：设计生命周期管理——TTL（生存时间）、显式删除、冲突覆盖、记忆衰减（按遗忘曲线降低陈旧记忆权重），过时偏好和错误信息要能更新或删除
• 一致性维护：长期记忆与当前对话矛盾时，当前显式指令优先于长期记忆推断；记忆条目附来源，支持更新、过期与删除

面试官关注点： 是否清楚三层记忆的存取分工与转化时机，并意识到写入过滤和遗忘机制才是记忆系统不膨胀的关键。

---

★★★ 20. Context Engineering（上下文工程）与 Prompt Engineering（提示工程）的本质区别？

参考答案：

• Karpathy 的区分：Prompt Engineering 是"你对模型说什么"，Context Engineering 是"模型知道什么"；提示工程是上下文工程的子集
• 范围不同：提示工程聚焦单条指令的措辞、格式、Few-shot（少样本示例）、CoT（思维链）；上下文工程覆盖模型推理时可访问的全部信息环境——系统指令、对话历史、检索文档、工具定义与返回值、记忆系统、动态注入数据（时间、用户画像、业务状态）
• 时间维度不同：提示工程是单次请求、无状态；上下文工程跨轮次、跨会话、有状态
• 本质定位不同：提示工程是文案/语言优化，上下文工程是信息架构与系统工程问题——信息质量大于指令质量，给对信息比写好指令更重要
• 直觉类比：LLM（大语言模型）像聪明但无背景知识的顾问，提示工程是会上说的那句话，上下文工程是会前准备的全部材料（备忘录、数据报表、会议纪要、政策手册），材料质量更决定性
• 产物与技术栈不同：提示工程产出 prompt 模板库；上下文工程产出 Context Pipeline（上下文管道），涉及 RAG（检索增强生成）、记忆系统、MCP（模型上下文协议）、工具编排、向量数据库
• 实践判断：模型表现不好往往不是 prompt 写得差，而是该给的信息没给、不该给的噪声太多

面试官关注点： 能否从"单条指令优化"上升到"信息环境设计"的视角，并用工程化（管道、预算、记忆）语言描述后者。

---

★★★ 21. 上下文压缩怎么做？如何验证压缩后仍保留决定下一步行动的关键信息？

参考答案：

• 主要技术路线：摘要压缩（LLM 把长文本压成摘要，适合对话历史）；Token 级压缩（LLMLingua 用小模型计算 Perplexity（困惑度），删除低信息量词元，可 2-10 倍压缩且任务性能损失小）；结构化提取（长文本提取为 key-value（键值对），压缩率极高）；选择性上下文（按对当前 query（查询）的信息贡献度保留片段）；RECOMP（训练专用压缩模型把检索文档压成紧凑摘要）
• 组合与分层：对话历史用摘要压缩、RAG 结果用 Token 级压缩、工具返回值用结构化提取；越远的内容压缩越狠，最近轮次保留原文
• 优先保全的信息：目标、权限限制、用户承诺、关键实体/数值、资源 ID、否定约束、当前步骤、失败原因、未完成的外部动作与审批范围，结构化保存并附来源
• 保留可恢复性：保留原文引用供按需回读，必要时检索原文补回；业务状态不只存在摘要中
• 验证方法：字段检查（必须保留的字段与事实是否齐全）+ 任务级回放（比较压缩前后在同一任务上的下一步决策与最终验收结果是否一致）
• 测试用例要覆盖：长对话、冲突信息、否定指令、相似实体、跨轮改口与恢复场景
• 易错点：不能只让同一个模型评价"压缩得很好"就算验证；压缩只能降低信息成本，不能保证无损；要记录压缩版本及回放表现，监测摘要累积误差

面试官关注点： 是否把压缩当成有损过程来管理——先定义必须保全的行动关键信息，再用字段检查加任务回放验证，而不是只看压缩率。

---

★★ 22. Context Window（上下文窗口）即将耗尽怎么办？Token 预算如何分配？

参考答案：

• 预算分配示例（总预算 128K Token）：System Prompt 2-4K、工具定义 2-6K、用户画像/动态数据 1-2K、RAG 结果 4-16K、对话历史 8-32K、工具调用结果 4-16K、输出预留 4-8K，其余留安全余量
• 核心原则：永远不要用满上下文窗口，留 30%+ 余量——工具返回值大小不可预测、接近窗口上限时模型性能下降、还要为多轮工具调用预留空间
• 三级响应机制：预防级设 Token 预算硬限制并对使用率设 70%/85%/95% 告警；应对级（70%-85%）压缩对话历史、裁剪工具返回值（只保留最近几次完整结果）、RAG 注入从 Top-10 降到 Top-3；紧急级（85%-95%）只保留事实注册表（键值对状态）+ 最近 2 轮原文，或将整个上下文重建为 2-3K 的 briefing document（简报文档），Agentic（智能体式）场景可把任务状态写入文件后重启新会话续跑
• 固定保留目标、约束与当前状态；近期对话用滑动窗口，旧历史转可追溯摘要，长期事实按需检索
• 选择性加载与外部化：按意图路由只加载相关上下文模块；详细信息存外部（数据库/文件），上下文中只放摘要或索引，需要时通过工具按需读取
• 架构级手段：多 Agent 架构下每个 Agent 只关注子任务、各自维护独立上下文窗口，用"分布式上下文"突破单窗口限制
• 估算时按 Token 计费口径进行并显式预留输出空间；不要只按消息条数截断，那会忽略单条超大消息

面试官关注点： 有没有"预留余量、分级响应"的工程意识——在窗口真正耗尽前主动压缩或重建，而不是被动截断。

---

★★★ 23. "Lost in the Middle"（中间遗失）问题的成因与缓解手段？

参考答案：

• 成因：2023 年 Stanford（斯坦福大学）的研究揭示，LLM 对上下文头部和尾部的信息关注度最高，中间部分的信息容易被忽略，注意力呈 U 形分布；上下文越长、塞得越满，注意力稀释越严重（窗口大不等于可以随便塞）
• 位置策略：最重要的信息（核心指令、关键事实）放在上下文的开头或结尾，次要参考信息放中间
• 结构化标记：用明确的标题、分隔符和标记帮助模型定位关键信息，降低在长文本中"迷路"的概率
• 缩短总长度优先：减少上下文总长度比调整位置更有效——配合压缩、裁剪、按需加载降低噪声
• 重要规则前置：System Prompt 设计中把不可违反的红线规则放前面，模型对靠前内容注意力更强
• 对抗上下文腐化（Context Rot）：过时信息、矛盾内容、噪声（无效闲聊、失败尝试、冗余确认）会加剧中间段被淹没，应定期主动清洗对话历史、重注入关键指令

面试官关注点： 是否理解这是注意力分布问题，缓解时优先"放对位置 + 缩短总长"，而非单纯依赖更长的窗口。

---

★★ 24. 多 Agent 之间上下文如何传递与隔离？记忆出现矛盾或污染时如何检测修复？

参考答案：

• 传递遵循最小知识原则：主 Agent 构造 Task Brief（任务简报）= 任务目标 + 必要背景 + 输入数据 + 输出格式 + 约束条件，而不是复制整段父上下文；约束和资源 ID 不做模糊摘要，提供引用由子 Agent 按需检索
• 回传走结构化结果：子 Agent 返回结论、证据和未解问题（而非完整对话轨迹），共享信息经显式合并才能进入父状态；子结论不自动升级为权威事实
• 隔离用三层上下文模型：全局层（安全规则、项目元信息，只读）、任务层（同一任务链共享的中间状态，经 Blackboard（黑板）共享或 Message Passing（消息传递）路由）、私有层（各 Agent 独有的 System Prompt、工具集、领域知识）；子 Agent 要有独立状态与权限作用域，隔离租户和敏感字段
• 易错点：逻辑上的角色划分不等于存储和工具权限已经隔离，权限要在运行时强制
• 矛盾检测：上下文组装阶段加检测层，用 NLI（自然语言推理）模型或 LLM 判矛盾对；新注入信息与已有上下文矛盾时，删除旧内容或显式标注"以下内容已更新"
• 矛盾记忆的更新：把记忆当作有来源、时间、适用范围和置信度的断言，而不是盲目覆盖的字符串；区分偏好改变、事实冲突与身份风险，高风险冲突需人工确认，旧记录保留版本或失效标记；权威来源优先但不能只看最新
• 污染修复流程：从错误输出追溯到具体记忆及其来源，暂停该条参与检索，核验后更正或撤销，再清理派生摘要、向量和缓存并保留纠错审计记录；只改一处数据库字段可能被旧摘要重新污染

面试官关注点： 传递与隔离是否落实到契约和权限（而非复制上下文），以及污染修复是否覆盖派生数据和影响范围。

四、RAG 与检索

★★★ 25. RAG（检索增强生成）的完整流程？RAG 与微调（Fine-tuning）如何取舍？

参考答案：

• 完整流程分离线与在线两阶段：离线阶段（知识库构建）为 文档收集 → 预处理/清洗去重 → 分块（Chunking，文档切块）→ Embedding（向量化）→ 存入向量数据库；在线阶段为 用户查询 → Query（查询）改写/扩展 → Embedding → 向量检索取 Top-K（前 K 条）→ 重排序（Rerank）→ 上下文拼接 → LLM（大语言模型）生成 → 返回答案并附引用。
• 生成之后还有后处理：引用溯源（标注答案来自哪个文档块）、幻觉检测、格式化输出。
• RAG 的价值：回答基于真实文档减少幻觉、知识更新只需更新知识库、可标注来源便于验证、成本远低于微调。
• 取舍——RAG 适合：知识频繁更新、需要引用溯源、数据量大但标注少、需要快速上线；微调适合：特定领域的语言风格/格式要求、任务模式固定（如分类/抽取）、需要内化领域知识以降低推理延迟。
• 成本对比：RAG 主要成本在检索基础设施和 Embedding 计算；微调成本在训练数据标注和 GPU（图形处理器）训练；实时性上 RAG 好（更新知识库即可），微调差（需重新训练）。
• 决策框架：优先上 RAG（快、灵活），效果不够再加微调；微调不能解决"模型不知道"的问题，RAG 可以；反模式是用微调去"记住"事实——事实会变，微调后很难更新。
• 两者不矛盾、可组合：微调让模型学会领域"语感"和输出格式，RAG 提供实时知识，最佳实践是二者结合。

面试官关注点： 是否真正落地过全链路，能否按知识更新频率、溯源需求和成本给出选型依据，而不是只会背流程。

★★★ 26. RAG 召回或回答效果差时，如何逐层定位（切块→改写→召回→重排→生成）？

参考答案：

• 基本方法是分段评估、逐层归因：先确认正确证据是否存在且被正确解析（切块层），再看它是否进入召回候选（改写/召回层），随后看融合/重排后是否保留（重排层），最后检查生成引用（生成层）。
• 每层保存候选 ID、版本、分数与标签，逐层建立可复现的失败用例集；控制一次只改一个环节，避免多变量同时改动无法归因。
• 切块层：检查是否因切块不当导致语义破碎，同时观察跨块证据丢失和重复召回；固定检索预算，对比不同分块方案的证据覆盖、排序质量、回答正确率与延迟——不要只调 chunk size（文档切块大小）。
• 改写层：用真实输入按错别字、同义口语、指代、歧义分桶，分别查看召回与答案变化；改写要防止实体和数值被改变，也不能把陌生查询强行改写成已知意图。
• 召回层：用标注好的 QA 对（问答对）看 Recall@K（前 K 条召回率）是否命中正确证据；命中率低再考虑 Query 改写、混合检索、升级 Embedding（向量化）模型等手段。
• 重排/融合层：检查正确证据在 RRF（倒数排序融合）合并或 Rerank（重排）之后是否被压出截断范围，评估截断是否丢掉了答案证据。
• 生成层：召回正确而回答错误时不应继续调 Top-K（前 K 条数量），应查上下文组织（如 "Lost in the Middle"（长上下文中部信息被忽略）问题：最相关文档放开头和结尾、只保留 3-5 个）、Prompt（提示词）约束与引用校验。
• 易错点：不能看到回答差就一律扩大召回数量，要先定位是哪一层的证据链断了。

面试官关注点： 有没有建立可复现失败集和分层证据链的习惯，能否避免"回答差就调 Top-K"的盲目做法。

★★★ 27. Chunk（文档切块）大小如何确定？Markdown 无标题、PDF 表格等怎么切分并保留结构元数据？

参考答案：

• 大小没有万能值，需按文档类型和检索场景实验调优：太小（<100-128 tokens（词元））语义不完整、检索到碎片；太大（>1000-2000 tokens）噪声多、相关性被稀释；常见区间 256-1024 tokens，overlap（重叠区）设 10-20%（约 50-100 tokens）。
• 按类型的经验值：FAQ（常见问题）/知识库 256-512 tokens；技术文档/法律合同 512-1024 tokens；长篇叙述按段落/章节切；代码按函数/类、对话按轮次、表格保持完整性；且块大小不应超过 Embedding（向量化）模型的有效编码长度（如 BGE 约 512 tokens）。
• 评测办法：用标注好的 QA 对（问答对）做 A/B 对比，比较不同 chunk 大小下的 Recall@K（前 K 条召回率）与最终回答质量；不存在对所有文档都最优的固定长度。
• Markdown（轻量标记语言）无标题时：先解析段落、列表、代码和表格边界，再按 token 上限组合成块；超长段按句子或有界窗口继续切，保留适当重叠和原文偏移；语义切分作为可比较的方案而非必选项；绝不能因为没有标题就把整篇文档当成一个块。
• 按标题切块后大小极不均匀时：小节可在不跨越语义边界的前提下合并，大节按段落、句子或结构元素再分，并把章节路径作为元数据（描述数据的数据）或短前缀（注意限制重复父标题的开销）。
• PDF（便携文档格式）表格等：保持表格完整性，可将表格转 Markdown/HTML（超文本标记语言）后嵌入，复杂表格可生成自然语言描述作为补充索引，结构化表格可走 Text2SQL（文本转 SQL 查询）；代码块或大表格超过上限时按其内部结构继续切分。
• 结构元数据保留：文档 ID、版本、章节路径、页码、文本/字符偏移、段落类型与访问权限；PDF 还应保存版面坐标及 OCR（光学字符识别）映射；纯文本没有的结构不应伪造。
• 存原文及可回溯的清洗映射，给块附上文档版本和定位，用真实查询与答案证据回归验证；只保存清洗后的字符串会丢失可靠溯源位置。

面试官关注点： 是否兼顾检索精度与溯源定位，能否对无结构文档给出可执行的切分方案，而不是背经验值。

★★★ 28. 向量召回不准怎么办？Query 改写 / 扩展、HyDE（假设文档嵌入）等手段？

参考答案：

• 先诊断再优化：用真实查询建立错别字、同义口语、指代、歧义分桶，分别查看召回与答案变化，同时排查是否因切块不当导致语义破碎。
• Query（查询）改写/扩展：用 LLM（大语言模型）把原始查询改写为多个变体（Multi-Query，多查询改写）分别检索后合并；复合问题用查询分解（Query Decomposition）拆成子问题分别检索；Step-back Prompting（后退提问）先问更抽象的问题获取背景知识。
• HyDE（假设文档嵌入）：先让 LLM 生成一个假设性回答（不需要准确，只需包含相关术语），对假想文档做 Embedding（向量化）再去检索真实文档——文档-文档匹配通常比查询-文档匹配更准，能弥补短查询的语义鸿沟。
• HyDE 适用简短/模糊查询、用户用语与领域术语差异大的场景；不适合精确查询（如"Python 3.12 的发布日期"），且多一次 LLM 调用会增加延迟，假想文档质量依赖 LLM 本身的知识。
• 多轮对话做查询上下文化（Query Contextualization）：把"它的价格呢？"与历史对话合并为自包含查询；意图不明时优先澄清并保留原始查询；改写要防止实体和数值被改变。
• 混合检索：向量检索 + BM25（基于词频与逆文档频率的关键词检索算法）关键词检索互补，结果用 RRF（倒数排序融合）合并。
• 升级或微调 Embedding 模型：换更强模型（如 BGE-M3、E5-Mistral 等），或在领域数据上 fine-tune（微调）嵌入模型；同时遵守所选模型的 query/document（查询/文档）非对称编码约定。
• 元数据过滤 + Rerank（重排）：先按时间/类别/租户等元数据过滤缩小范围再向量检索；引入交叉编码器精排，通常可带来 10-30% 的 MRR（平均倒数排名）提升。

面试官关注点： 是否清楚各改写手段的适用边界与代价（如 HyDE 的额外延迟），并坚持先诊断分桶再动手优化。

★★★ 29. 为什么要混合检索（BM25 关键词 + 稠密向量）？RRF（倒数排序融合）如何工作？

参考答案：

• 动机是互补盲区：稀疏检索（BM25 关键词匹配）精确但没有语义理解，稠密向量检索（dense retrieval）理解语义但可能丢失精确匹配；混合检索（Hybrid Search）结合两者，效果最佳。
• 哪些查询暴露纯向量召回不足：精确编号、型号、姓名、错误码和少见术语——关键词检索保留精确命中，向量检索补同义和概念匹配；向量相似不等于事实或实体相同（数字差一位也可能误召回）。
• BM25（经典稀疏检索算法）的排序依据：查询词匹配、逆文档频率（IDF，稀有词权重更高）、词频饱和与文档长度归一化；k1 控制词频饱和，b 控制长度归一化强度，参数要结合分词、字段和验证集来调。
• RRF（倒数排序融合）原理：对每个候选文档，在每路召回中的得分累加 1/(k+rank_i)，即按各路排名倒数加权求和；它融合的是各路排名，而不是直接相加量纲不可比的相关性分数。
• 参数影响：k 是平滑常数（k 越小越偏重头部排名；常见取 60，但 60 是常见配置，不是数学上必然最优）；注意区分平滑常数 k 与每路召回的 Top-K（前 K 条）深度。
• 工程要点：各路召回深度要平衡（如向量 top-50 + BM25 top-30），避免某一路完全主导结果；处理重复去重与某路缺失的情况；用验证集选配置，并用相关性和延迟一起选型。
• 是否上混合看数据说话：按查询分桶（专名/编号类 vs 语义问答类），在相同语料和检索预算下做对照实验；同时控制好分词与字段设置。

面试官关注点： 是否理解"分数不可比所以融合排名而非分数"，以及 k、召回深度等参数要用验证集拍板而不是抄默认值。

★★ 30. Rerank（重排）的原理与模型选择？增加的延迟如何证明值得？

参考答案：

• 原理对比：向量召回是双塔模型（Bi-Encoder，查询和文档独立编码，无法细粒度交互）；Rerank（重排）用交叉编码器（Cross-Encoder），把查询和每个候选文档拼接成一个序列联合编码打分，能做 token（词元）级注意力交互，精度远高于双塔。
• 因 Cross-Encoder 计算量大、无法对全库文档打分，标准做法是"宽检索、精排序"：粗召回 50-100 个候选，精排后取 top 3-5（或 5-10）作为最终上下文喂给 LLM（大语言模型）。
• 常用模型：Cohere Rerank API（应用程序接口）、bge-reranker-v2-m3（开源中较强）、cross-encoder/ms-marco-MiniLM；轻量替代是让 LLM 对候选列表直接排序（效果好但成本高，适合离线场景）；还可做多阶段重排：向量召回 → 轻量 Reranker → 重型 Reranker，平衡效果与延迟。
• 代价：Rerank 通常增加 50-200ms（毫秒）延迟（取决于候选数和模型大小）；可通过减少候选数、用蒸馏小模型、异步重排（先返回粗排结果）、简单查询跳过 Rerank 来控制。
• 证明值得的实验设计：固定第一阶段候选规模与最终上下文预算，对比"无重排 / 不同重排模型 / 不同候选规模"下的证据排序质量、回答正确率及尾延迟（如 P99）。
• 还要记录单位成功任务的成本，评估重排后截断是否丢掉了答案证据；注意重排模型只见到截断后的局部文本时可能误判。
• 关键认知：检索指标提升（如 MRR（平均倒数排名）提升 10-30%）不必然转化为最终业务提升，应以端到端回答质量为准，并按任务难度决定是否条件式启用重排。

面试官关注点： 能否用对照实验（固定预算比较回答正确率与尾延迟）量化重排收益，而不是只说"效果显著"。

★★★ 31. RAG 效果如何评估？检索与生成两阶段指标（Recall@K / Faithfulness 忠实度等）、RAGAS 等框架？

参考答案：

• 总原则是分段评估：分别评估检索准不准、生成好不好，再看端到端表现，用三者差异定位瓶颈在哪一环节。
• 检索质量指标：Recall@K（前 K 条召回率，衡量"找全"）、Precision@K（前 K 条准确率，衡量"找准"）、MRR（平均倒数排名，看相关文档是否排在前面）、NDCG（归一化折损累计增益，考虑相关性等级与位置）、Hit Rate（命中率，至少返回一个相关文档的查询比例）。
• 生成质量指标：Faithfulness（忠实度，回答是否忠于检索到的文档、不编造，是 RAG（检索增强生成）最重要的生成指标）、Answer Relevancy（回答相关性，是否真正回答了问题）、Completeness（完整性）、Correctness（正确性）。
• 端到端指标：Context Relevancy（上下文相关性，即信噪比）、Answer Similarity（与参考答案的语义相似度）、Latency（延迟）、Token Efficiency（词元使用效率/成本），以及用户满意度、任务完成率、人工评分。
• 评估数据集构建：从真实用户查询中采样，人工标注 ground truth（标准答案）和相关文档，形成标注 QA 对（问答对）。
• 主流框架：RAGAS（检索增强生成评估框架，最流行）、TruLens（提供 Groundedness（有据性）等反馈函数）、DeepEval、LangSmith、Arize Phoenix；可用 LLM-as-Judge（大模型当评审）自动打分。
• RAGAS 的核心方法：Faithfulness 把回答拆解为独立 claim（论断）逐一检查是否被上下文支持；Answer Relevancy 从回答反向生成可能的问题、再与原始问题比相似度；Context Precision（相关上下文是否排在前面）、Context Recall（参考答案的信息是否都能在上下文中找到）。

面试官关注点： 是否坚持"检索与生成分开评、用真实标注集"，并能说清 Faithfulness 等指标的具体计算思路。

★★ 32. Agentic RAG（智能体检索）/ Self-RAG / CRAG（纠正式）/ GraphRAG（图谱检索）各适合什么场景？

参考答案：

• Agentic RAG（智能体检索）：把 Agent（智能体）的自主决策引入 RAG 流程——判断是否需要检索、选择数据源（向量库/SQL（结构化查询语言）/Web 搜索/API（应用程序接口））、评估检索结果、不够就改写查询多轮重试、生成后自检幻觉；适合复杂多步骤研究任务、多数据源动态路由、需要迭代纠错的场景；代价是延迟高、成本大、Agent 决策可能出错，简单问题不必用。
• Self-RAG（自反思检索增强生成）：模型在生成中用四种反思 token（[Retrieve] 是否检索、[ISREL] 段落是否相关、[ISSUP] 回答是否被支持、[ISUSE] 有用性打分）自主决定何时检索并自评质量；用 Critic Model（评审模型，如 GPT-4）标注反思 token 后训练目标模型，端到端可训练、反思能力内化在权重里，推理时可用树搜索选最优路径；适合需要自适应检索且能投入训练的场景。
• CRAG（纠正式检索增强生成）：在检索后、生成前插入轻量检索评估器打分——Correct（正确）→知识精炼（把文档切成 knowledge strips（知识条）逐条过滤噪声）；Incorrect（不正确）→丢弃检索结果并触发 Web 搜索兜底；Ambiguous（模糊）→精炼后的检索结果 + Web 结果双保险；适合知识库覆盖不全、长尾知识多的场景（在 PopQA（长尾知识问答数据集）等困难数据集上提升显著）。
• Self-RAG 与 CRAG 的关键区别：Self-RAG 是端到端训练、反思内化于模型权重；CRAG 是 pipeline（管道）式方法，靠外部评估器加 Web 搜索兜底。
• GraphRAG（图谱检索）：先用 LLM 抽取实体和关系构建知识图谱，再做图遍历与社区摘要检索；适合实体关系分析、多跳推理（如"A 的导师的学生参与了什么项目"）、跨文档连接、全局性综合问题（"数据集主要主题/趋势"）和隐含关联发现；典型领域：企业知识管理、学术引用网络、法律合规、情报分析、医疗知识。
• GraphRAG 的局限：索引成本高（10 万 token 文档需成百上千次 LLM 调用）、实时性差（更新要重跑实体提取和社区检测）、简单事实查询反而不如向量 RAG、不适合百万级文档或关系稀疏的语料；图中找不到路径也不能推出关系不存在。
• 总体选型：简单 QA（问答）用基础 RAG，企业知识库问答用"多路召回 + 重排"的 Advanced RAG（进阶检索增强生成）；可按查询复杂度路由（Adaptive RAG（自适应检索增强生成）：简单问题不检索、中等问题单步检索、复杂问题多步检索），并非每个问题都需要最复杂的方案。

面试官关注点： 能否按查询类型和数据特点选范式并说出各自代价（成本/延迟/更新），而不是堆砌名词。

五、多 Agent 协作

★★★ 33. 为什么一定要 Multi-Agent（多智能体）？单 Agent 或 Workflow 不行吗？

参考答案：

• 拆分前提：只有子任务需要相对独立的推理、上下文、工具权限或可并行探索时才考虑 Multi-Agent（多智能体）；确定性的数据转换优先用普通函数或 Workflow（工作流）节点
• Workflow（工作流）预定义控制流，Agent（智能体）在授权范围内根据反馈动态选择动作，两者可以混合；以需求的不确定性而非团队角色名决定架构
• 不值得拆成自治协作的场景：确定性计算、高风险固定审批、短小转换，以及简单规则能搞定、低延迟要求、成本敏感的任务
• 多 Agent 的收益：专业化分工（Coder 编码 / Reviewer 审查 / Tester 测试）、独立子任务并行、多 Agent 讨论辩论（Debate）提升决策质量、单个 Agent 失败不影响整体（鲁棒性 Robustness）
• 多 Agent 的代价：Agent 间通信增加延迟和 Token（词元）消耗、任务分配/冲突解决/死锁避免等协调难题、多个 Agent 对同一事实的一致性维护、调试困难（问题可能出在任意 Agent 或其交互中），还有成本控制与死循环检测
• 公平对照评测：单/多 Agent 用相同任务、模型能力、工具、数据及总 Token/时间预算，计入调度与汇总调用，做去角色和去通信消融（Ablation）实验；增加预算后的高分不能归因于架构本身
• 易错点：不要把每个工具都包装成 Agent；多个模型节点不一定构成有意义的多 Agent 系统；角色拆分不等于运行时隔离，拆分前先定义子任务契约

面试官关注点： 考察"该不该拆"的判断力——用子任务独立性、需求不确定性与成本/故障面权衡来论证，而不是为拆而拆。

★★★ 34. 多 Agent 协作模式有哪些（Supervisor 主管 / 管道 / 辩论）？LangGraph / CrewAI / AutoGen 怎么选？

参考答案：

• 常见协作模式：主从/Supervisor（主管）模式——Orchestrator（编排器）+ Worker Agents（工作智能体）分发与执行；管道（Pipeline）模式——顺序逐级传递；辩论（Debate）模式——多 Agent 讨论达成共识
• Supervisor（主管）与 Orchestrator（编排）的取舍：主管模式由中心节点决策并分发任务，编排模式侧重流程控制，要结合任务是否需要中心决策来选适用场景
• 通信机制：共享 Blackboard（共享状态空间）、消息传递（Agent 之间直接对话）、中央协调器分发任务
• 框架定位：LangGraph 是图状态机编排，适合需要精确控制流程的复杂 Agent，学习曲线适中；CrewAI 是角色扮演式多 Agent，API（应用程序接口）简洁、适合团队协作场景；AutoGen 是微软出品的对话式多 Agent，支持人机协作、适合研究
• 选型评价指标：可控性（能否精确控制执行流程和错误处理）、可观测性（日志、Trace（链路追踪）、调试工具是否完善）、扩展性（自定义工具/模型/存储的便捷度）、社区生态、生产就绪度（并发、容错、监控、部署支持）
• 工程要点：每个 Agent 要有明确的角色定义和能力边界，避免职责重叠导致冲突；典型组合是 Planner（规划）拆需求 + Coder（编码）写代码 + Reviewer（审查）+ Executor（执行）跑测试
• 跨框架协作可用 A2A（Agent-to-Agent，智能体间通信协议）：Agent Card（能力声明）、Task（标准化任务格式）、Streaming（实时状态更新），与 MCP（Model Context Protocol，模型上下文协议）互补——MCP 连工具、A2A 连 Agent
• 面试建议：选 1-2 个框架深入讲，结合实际项目经验说明选型理由和踩坑经验

面试官关注点： 能否把协作模式、通信机制与框架特性对上号，并给出有依据的选型逻辑，而不是罗列框架名字。

★★ 35. 多 Agent 的角色职责与交付边界怎么划分？哪些状态共享、哪些隔离？

参考答案：

• 按可独立验证的交付物切职责，专家角色名称不能替代可验证职责；每个 Agent 要有明确的角色定义和能力边界，避免职责重叠导致冲突
• 每个角色的契约定义清楚：输入、约束、工具权限、输出 Schema（结构定义）、证据、截止时间和失败上报
• 给每项子任务指定责任主体（唯一负责人），并明确共享资源和写入权
• 跨角色分歧由明确策略处理（仲裁/裁决），而不是让多个角色无限互相讨论
• 共享的状态：任务契约、只读证据、经提交的产物
• 隔离的状态：私有消息、工具授权、临时文件、未提交状态
• 共享状态的保障机制：单写者（Single Writer）、事务版本或明确合并规则，不靠随意共享对话数组；共同编辑计划时要避免读到半更新状态
• 权限从可信上下文派生，存储与缓存都带作用域；上下文隔离不是在提示词（Prompt）里写一句"不要串任务"

面试官关注点： 看职责划分是否落到可验证交付物和契约上，共享/隔离状态是否有单写者、版本等机制保障，而非口头约定。

★★ 36. 子 Agent 超时 / 崩溃后，父 Agent 如何决策重试、接管还是终止？

参考答案：

• 决策顺序：先判断是否可重试、外部效果是否未知，再按重试预算、截止时间和替代能力决定重试、接管还是终止
• 具体分流：能安全重放（幂等 Idempotency、无副作用）则重试；证据齐全可接管继续执行；外部副作用未知先对账（确认动作是否已发生）；无法恢复则转人工或终止，并报告部分结果
• 接管从持久化边界开始：父 Agent 读取子 Agent 已持久化的状态接着做，而不是只等一条消息或从头重跑
• 避免父子同时拥有写权限，防止接管时重复写入；写入要做幂等与版本检查
• 关键易错点：子 Agent 失联不意味着它执行的外部动作没发生，必须先对账再重试
• 消息通信层面：消息携带任务/尝试/操作 ID、状态版本和关联 ID；按至少一次（At-Least-Once）投递考虑重复、乱序与超时，消费后幂等落状态再发完成事件（或用 Outbox（发件箱）模式），超限进入可审计的死信（Dead Letter）/人工流程，取消也要版本化
• 错误恢复手段归纳：重试、回退、换路径、升级（转人工）
• 易错点：消息队列（Message Queue）的确认不等于外部业务动作恰好执行一次

面试官关注点： 考察故障后的状态判断力——是否清楚"失联不等于外部动作未执行"，能否给出重试/接管/终止的决策依据与幂等保障。

六、评测、可靠性与安全

★★★ 37. 如何设计 Agent 的离线评测、线上指标和失败样本回流？

参考答案：

• 先定义任务成功条件：从任务契约拆出目标、工具、权限、轮数与依赖，明确最终验收、过程约束和可接受的部分成功，再冻结输入、来源与环境构建成评测集
• 离线评测分层采样真实任务并做故障注入（fault injection），覆盖工具超时、未知副作用、取消、恢复与恶意输入，加入无答案和对抗样本（adversarial sample），只有正常路径（happy path）的高分不能证明可靠性
• 评分区分三个维度：结果评分（outcome grading）看最终产物是否满足验收；轨迹评分（trajectory grading）看步骤效率与工具调用准确率；状态评分（state grading）看外部副作用与持久化状态是否正确，分层报告而非合并成一个总分
• 评分手段组合：确定性规则负责格式、权限和数值约束，LLM-as-Judge（模型评审）负责开放语义，人工复核高风险与争议项，用有标签样本校准一致性并保留原始结果与分歧
• 线上指标除任务成功率外，还要看违规/越权、错误引用、工具失败与未知结果、恢复与取消表现、端到端尾延迟、单任务成本和人工接管率，按场景、版本、租户分桶，防止平均值掩盖风险
• 建立回归门禁（regression gate）：每次 Prompt（提示词）、模型或框架变更后自动跑冻结测试集，设置质量门槛阻止退化上线，报告多次运行方差与失败样本，验收检查尽量独立于被测 Agent（智能体）
• 失败样本回流形成数据飞轮（data flywheel）：把线上失败案例、人工接管和未覆盖意图聚类后按频率、风险、影响排序补进评测集，持续回归并定期重采样，同时保留冻结集，避免为追分不停改测试
• 防数据污染与评测漂移：训练与测试按来源分离，测试集按文档、时间、实体划分防止近重复泄漏，模型升级单独评估并做同样本配对比较

面试官关注点： 考察是否形成“离线评测—线上指标—失败回流”闭环，能否分层评分并识别数据污染，而不是只报一个总分。

★★★ 38. 为什么不能只用 LLM-as-Judge（模型评审）？结果评分（outcome）与轨迹评分（trajectory）如何区分？

参考答案：

• LLM-as-Judge（模型评审）有系统性偏差：位置偏差（position bias，偏好排在前面的答案）、自我偏好（self-preference，偏爱与自己风格相似或自己生成的内容）、冗长偏好（verbosity bias，偏爱更长的答案），且在医疗、法律等专业领域难以判断技术正确性
• 模型评分高不等于业务事实正确；不能让同一模型独自出题、作答又给分；模型自述“已完成”必须由独立验证确认
• 校准与缓解：交换答案顺序评估两次取平均、盲评和多次采样、temperature=0（温度参数，控制随机性）提高一致性，用有标签的人工样本校准 Judge（评审模型）并定期人工抽检
• 组合分工：确定性规则管格式、权限和数值约束，模型评审管开放语义，人工复核高风险与争议项；保留原始结果、评审版本和分歧，而非简单平均
• 结果评分（outcome grading）只看最终产物：任务完成率（精确匹配、宽松完成、加权完成）以及最终答案是否满足验收标准
• 轨迹评分（trajectory grading）看过程质量：步骤效率（最优步骤数/实际步骤数）、工具调用准确率（选对工具且参数正确）、动作是否越权违规、是否绕了弯路
• 状态评分（state grading）看执行后果：外部系统副作用与持久化状态是否符合预期，比如有没有重复工单、状态是否正确推进、是否产生重复副作用
• 三种评分经常不一致：结果对但轨迹违规（蒙对或越权完成）、轨迹漂亮但结果错，必须分开报告、分桶分析，不能互相抵消

面试官关注点： 考察是否理解模型评审的偏差与校准方法，能否说清结果、轨迹、状态三种评分各管什么、为何要分开报告。

★★★ 39. 如何验证 AI Coding（AI 编程）生成的代码质量，而不是直接接受结果？

参考答案：

• 先区分“生成”与“交付”：AI 产出只是候选改动，必须通过验证链才能合入；避免 Vibe Coding（凭感觉编程，不理解代码就直接使用），否则就是技术债务
• 静态检查（static analysis）先行：lint（代码风格检查）、类型检查、格式化，拦截低级错误
• 安全扫描：识别 SQL injection（SQL 注入）、XSS（跨站脚本）、硬编码密钥和不安全依赖，不能因为“模型说没问题”而跳过
• 测试验证：补单元测试和属性测试（property-based testing，基于属性的测试），覆盖边界用例；同时明确测试盲区——测试全过不等于没有缺陷
• 差异审查（code review，代码评审）：逐行审查 AI 的改动而非全盘接受，能解释每行代码；警惕 AI 生成“能跑”但可维护性差的代码
• 运行时验证：在隔离环境、沙箱（sandbox）中实际运行，验证行为与需求一致；静态检查通过不能代替运行时隔离
• 保留证据而非口头确认：把检查落进 CI/CD（持续集成/持续交付），自动代码评审、自动生成测试，留存可追溯的检查记录，并准备回滚（rollback）方案
• AI 反复生成错误代码时不要无限重试：换思路、补充上下文、手动定位后精确提问

面试官关注点： 考察是否把 AI 输出当候选而非成品，用“静态检查—测试—审查—运行验证”的证据链把关，而不是直接接受结果。

★★ 40. 如何检测和缓解大模型 / Agent 的幻觉问题？

参考答案：

• 把幻觉率（hallucination rate，即生成虚假信息的频率）纳入评测指标，并坚持“模型自述完成”与独立验证分开
• RAG（检索增强生成）场景先分层归因：区分召回失败与生成失败——检索内容里没有答案是召回问题，检索正确但回答不忠实是生成忠实度（faithfulness）问题
• 用 RAGAS（RAG 评测框架）等量化：Faithfulness（答案对检索上下文的忠实度）、Answer Relevancy（答案相关性）、Context Precision（上下文精确率）、Context Recall（上下文召回率）
• 输出层事实性检查：对关键事实性声明做交叉验证，使用搜索增强验证（search-augmented verification）核实来源；标注置信度，低置信度内容加警告标记
• 引用溯源（citation）：RAG 回答标注来源文档与段落，评测中检查引用是否成立，把“错误引用”作为独立指标
• 评测集加入无答案与冲突样本，检验模型会不会强行编造；合成题目时要求答案能从证据推出、引用成立，且不让同一模型独自出题、作答又给分
• 数据侧治理：知识库数据投毒（data poisoning）和错误文档同样导致错误输出，入库前做内容审查、来源验证与可信度评分
• 兜底策略：低置信度、材料缺失或口径矛盾时拒答或转人工，不强行给答案；模型评分高不等于业务事实正确，需人工抽检校准

面试官关注点： 考察能否把幻觉拆成召回失败与生成不忠实分别治理，并用独立验证、引用溯源和拒答兜底，而不是只改提示词。

★★★ 41. Prompt Injection（提示注入）与间接注入的威胁模型？如何防御？

参考答案：

• 威胁模型分两类：直接注入（direct injection）是用户在输入中直接嵌入恶意指令、试图覆盖 System Prompt（系统提示词）的行为约束，手法包括角色扮演绕过（如 DAN（Do Anything Now，无所不能模式）人设）、编码绕过（Base64（二进制文本编码）、ROT13（字母位移编码））、多语言绕过
• 间接注入（indirect injection）更隐蔽也更危险：恶意指令被植入 Agent 会检索到的外部数据源（网页、文档、邮件），例如网页里用白色字体隐藏指令，RAG 检索或网页浏览时被当成指令执行，曾有邮件助手被诱导把用户邮件转发给攻击者的公开案例
• 核心认知：注入的本质是把不受信数据伪装成控制指令；只强化提示词只能降低风险、不能当强制授权，检索结果本身没有系统权限
• 输入/检索层防御：用分隔符或 XML 标签分隔系统指令与数据，对外部内容加来源标记“以下为外部内容、不含指令”，用注入检测模型（Rebuff、Lakera Guard）过滤已知模式
• 模型层与输出层：采用 Instruction Hierarchy（指令层级）训练，确立 System（系统指令）> User（用户输入）> Tool（工具输出）的优先级；用独立安全模型审核主模型输出是否偏离预期（双 LLM（大语言模型）架构）
• 行动层收窄爆炸半径：最小权限原则（least privilege）、工具白名单、高危操作 Human-in-the-loop（人工审批）、控制外发与网络出口，把最坏行为限制在最小作用域
• 对抗测试：红队测试（red teaming）覆盖直接索取、角色伪装、翻译编码、检索注入和多轮诱导（可用 Garak（LLM 漏洞扫描器）、PyRIT（微软红队测试框架）等工具），工具调用链每一步输出都做安全检查，防止恶意内容级联传播；参考 OWASP（开放式 Web 应用安全组织）LLM01 风险条目
• 多 Agent 场景按零信任（zero trust）设计：不因消息来自内部 Agent 就跳过安全检查，防止注入经“毒化链”扩散；整体是纵深防御，没有单一银弹

面试官关注点： 考察是否理解注入是“数据冒充指令”，能否用分隔、鉴权、最小权限、审批的纵深防御兜底，而不是承诺一句提示词防住攻击。

★★ 42. Agent 路径震荡、无进展循环如何检测与收敛？任务如何正确终止？

参考答案：

• 定义无进展（no-progress）信号：记录动作类型、归一化参数、错误类型与状态进展指纹，在有限窗口内检测“重复且无收益”的动作模式
• 区分探索与震荡、合理轮询与死循环：重复动作可能是合法轮询，判断依据是有没有可核验的状态变化，而不是只看动作重复，避免误杀
• 预算收敛：分别限制步数、重规划次数、重试次数和成本/时间预算，触发后限制重试、强制重规划（换策略）或转人工，并把失败证据带入恢复上下文
• 不能靠调参掩盖：只增加 max_iterations（最大迭代次数）或仅降低 temperature（温度参数）并不能消除循环
• 动作与错误指纹去重：相同参数、相同错误的重复调用应被去重短路，避免原样重放同一失败动作
• 任务终止要显式建模：把排队、运行、待确认、结果未知（unknown outcome）、成功、失败、取消等状态和允许的转换显式化，终止判定依据任务契约的验收条件和独立验证，而不是模型自称“完成”
• 超时与取消配合：设置任务截止时间和单次调用预算；收到取消后停止调度新动作、传播取消并持久化取消意图；已发出的外部副作用可能无法中止，须查询结果或做补偿，不能只回“已取消”
• 保留诊断链：终止或收敛时记录震荡证据、失败链和终止原因，回流到评测集供回归测试与人工复核

面试官关注点： 考察能否用指纹和进展信号识别无进展循环、用失败预算收敛而非硬拧参数，以及终态显式建模加独立验收。

★★ 43. 长任务 / 服务重启后如何恢复？持久化字段、租约（Lease）、fencing token（隔离令牌）、幂等如何配合？

参考答案：

• 持久化字段：至少保存任务契约、输入/来源版本、当前步骤与状态版本、计划、工具意图/幂等键/回执、产物引用、审批与权限版本、重试预算、租约及错误；模型版本和关键配置可回溯；敏感数据不无差别落盘
• 恢复流程：先读已有回执和产物，只重跑可安全重放的部分；恢复时重新校验已失效的审批和外部状态；checkpoint（检查点）不是节点内部语句的事务快照，LangGraph（LangChain 的状态图执行框架）可能重新执行节点函数，副作用必须幂等封装
• 幂等（idempotency）配合：为步骤和外部操作保存稳定 ID、输入指纹与完成回执；写入超时、结果未知时标“未知”而非“失败”，用稳定业务幂等键向外部查询或同键重试，不能换新键重试制造重复副作用
• 租约（lease）：租约到期只表示新 Worker（工作进程）可以接管，不会让旧进程自动停止；旧 Worker 续租失败应主动停止
• fencing token（隔离令牌）：每次所有权发放递增 epoch（所有权世代）/token（令牌），资源写入端拒绝旧 token，把所有权与写入校验相连；要覆盖长 GC（垃圾回收）暂停、网络分区和时钟漂移
• token 落到存储校验：下游原子地保存已见过的最大 token 并拒绝更小的写入，检查与写入不可分离；同一 token 内再用操作 ID 与步骤版本保证幂等和顺序；token 不是对所有外部系统都生效的万能锁，下游不支持时要明确保证边界
• 防状态回退：提交时用比较并交换（compare-and-swap，先比较后写入）或版本条件更新，只接受预期版本与合法状态转换，冲突者重读后重规划，终态不可随意回退
• 组合而非单点：分布式锁不保护已发出的外部请求，有锁不等于业务正确；要组合 fencing（令牌校验）、版本条件、幂等与业务校验，恢复次数设上限，外部效果未知先查证再动作

面试官关注点： 考察是否掌握“持久化意图—幂等重放—租约接管—令牌防旧写—版本防覆盖”的组合拳，以及锁不能替代幂等和业务校验。

★★ 44. 如何保证模型生成的结构化输出 / 工具参数既合法又语义一致？

参考答案：

• 合法性第一道是 Schema（结构模式）校验：用 JSON Schema（JSON 结构约束模式）或 Pydantic（Python 数据校验库）定义输出结构和工具参数，校验类型、必填字段、枚举与格式
• 约束解码（constrained decoding）：在生成端按语法/Schema 约束解码，先保证格式合法，减少解析失败和来回修复
• 格式正确不等于业务正确：还要做语义校验——参数是否符合任务意图、数值是否在业务范围内、对象和条件是否与请求一致
• 参数要做权限和范围校验：路径穿越防护、参数化查询防 SQL 注入、收件人白名单、scope（权限范围）受限的 Token（访问令牌），越权参数直接拒绝
• 修复重试与失败降级：解析或校验失败时带错误信息定向重试修复；重试仍失败就降级处理（转规则、转人工或显式失败），不能悄悄接受半解析结果
• 语义一致性延伸到执行：高风险操作展示结构化变更并二次确认，审批绑定动作指纹，确认过的参数与最终执行参数必须一致，参数变更后要重新审批
• 留痕审计：模型原始输出、校验结果与实际执行参数分开保留，可回溯“模型说了什么 vs 实际执行了什么”
• 度量上把工具调用准确率拆成工具选择准确率与参数传递准确率两个维度，纳入评测与回归

面试官关注点： 考察是否区分“格式合法”与“语义正确”两层校验，并把校验延伸到权限、审批绑定和审计留痕。

七、性能、成本与系统设计

★★★ 45. 多模型、多工具的 Agent 链路如何优化端到端延迟与成本？

参考答案：

• 先用 Trace（链路追踪）分解延迟：给同一任务标记排队、模型、检索、工具及提交各段耗时，重试和并行分支单独统计，端到端看关键路径而非把重叠 Span（调用跨度）全相加；按版本、场景和尾分位（P50/P95/P99）定位变化。
• 并行执行无依赖的模型/工具调用以缩短墙钟时间；先验证调用彼此独立，设置并发上限，关注幂等（Idempotency）、取消与结果顺序，避免共享资源争用和重试放大下游负载。
• 引入缓存（Cache）：语义缓存（Embedding 相似度超阈值直接命中）、Prompt 缓存、工具目录缓存与版本绑定；缓存必须带来源和权限版本，不能绕过权限。
• 模型路由（Model Routing）/模型分级：简单问题走小模型，复杂问题走大模型；工具描述按权限和业务域筛选、用简短区分性描述初选、按需加载完整 Schema（结构定义），控制上下文预算。
• 成本侧手段：Prompt（提示词）压缩与历史对话摘要、Batch 推理（批量推理）合并请求、Token（词元）计量与按业务方配额限制。
• 超时与降级：LLM（大语言模型）超时返回预设回答，工具调用异步执行不阻塞主流程；不能只按工具数量开启无限并发。
• 汇报口径：给出 P50/P95 延迟与每个成功任务成本，同时报告质量回归，不能只说换小模型。

面试官关注点： 是否先做延迟/成本分解再动手优化，能否在降本提速的同时给出质量回归数据。

★★ 46. 降低 Token 费用时，如何同时证明质量没有明显退化？

参考答案：

• 在固定样本与验收门槛下比较上下文裁剪、缓存、模型路由和调用次数优化等手段，统计每个成功任务成本而非单次调用的便宜程度。
• 成本核算要计入失败、重试与人工接管：少用大模型后更多任务转人工，未必真的更便宜。
• 质量与高风险指标设门槛，不达标则回退该优化项；缓存带来源和权限版本。
• 评测不能只用 LLM-as-Judge（大模型当评审），要区分模型自述完成与独立验证，可用 outcome（结果）/trajectory（轨迹）/state（状态）分级评分，并构建失败与对抗样本做回归门禁。
• 用消融（Ablation，逐项开关对比）方式归因：保持相同任务集与最终上下文预算，单独开关每项优化观察质量与成本变化。
• 只报告 Token（词元）减少而省略成功率下降是典型错误，还要关注数据污染和评测漂移。

面试官关注点： 成本口径是否为"每个成功任务成本"，是否有质量门槛与回退机制，能否给出成功率不下降的证据。

★★★ 47. 系统设计题代表：如何设计一个智能客服 Agent（意图路由→工具→多轮状态→转人工）？

参考答案：

• 意图路由：入口先做意图分类与路由，简单 FAQ（常见问题）走检索直答，复杂任务走多步 Agent；按权限和业务域筛选可用工具，配合模型分级控制成本。
• 知识检索：RAG（检索增强生成）全链路——Query 改写（查询改写）→ 向量 + BM25（关键词检索算法）混合召回 → 重排序（Rerank）→ 上下文拼接 → 生成并附引用来源，让答案有据可查。
• 工具调用层：工具注册与描述、约束解码保证参数合法、参数权限与范围校验、超时重试与幂等键（Idempotency Key）、结果日志；敏感操作走 human-in-the-loop（人工介入）审批。
• 多轮状态管理：短期记忆（对话上下文）+ 工作记忆（任务中间状态）+ 长期记忆（向量库中的用户偏好），每轮结束摘要压缩存入长期记忆，新会话检索相关上下文注入短期记忆；关键是何时压缩、保留什么、丢弃什么。
• 转人工（升级边界）：用户明确要求、连续失败或无进展循环（no-progress 信号与失败预算）、高风险操作（如退款）、置信度低、合规敏感场景。
• 准确性与合规：Prompt（提示词）约束"仅基于上下文回答，无信息就说不知道"、要求标注来源、后处理事实校验、敏感数据管控与审计日志（Audit Log）。
• 降级兜底：LLM 超时返回预设回答，语义缓存兜底高频问题。

面试官关注点： 能否画出从意图路由到转人工的清晰链路与升级边界，同时覆盖准确性、合规和状态管理。

★★ 48. 如何设计 Agent 的监控、Trace（链路追踪）与 A/B 测试 / 灰度发布体系？

参考答案：

• Trace：同一任务标记排队、模型、检索、工具、提交各段耗时，重试与并行分支单独统计，端到端看关键路径；区分服务等待与实际执行，控制时钟与采样开销影响。
• 监控指标分层：任务成功率（先定义任务成功条件）、幻觉（Hallucination）检测、成本（每个成功任务成本、Token 计量）、延迟（P50/P95/P99 尾分位）、安全指标；按版本与场景切分，平均变好但 p99 变差要能解释。
• 离线评测与失败回流：区分 outcome（结果）/trajectory（轨迹）/state grading（状态评分），构建失败与对抗样本并回流，建立回归门禁；不能只用 LLM-as-Judge（大模型当评审），要区分模型自述完成与独立验证，警惕数据污染与评测漂移。
• A/B 测试平台：对比不同 Prompt（提示词）/模型/工具组合，设计流量分配，做统计显著性判断，支持自动化收敛。
• 灰度发布：小流量放量观察关键指标，异常自动回滚；配合多租户隔离、RBAC（基于角色的访问控制）与审计日志。
• 成本监控与优化持续进行，回归门禁挡住质量退化的变更上线。

面试官关注点： 指标能否落到可独立验证的口径，实验能否统计显著收敛、灰度能否安全回滚。

★★ 49. Agentic RL（智能体强化学习）方向：多步工具轨迹的 Reward（奖励）设计与信用分配怎么做？

参考答案：

• Outcome Reward（结果奖励）：按最终任务成败给奖励，语义最准但信号稀疏（Sparse Reward），多步长轨迹下大多数步骤拿不到直接反馈。
• Process Reward（过程奖励）：对关键中间步骤给分（选对工具、参数合法有效、检索有进展），缓解稀疏奖励问题，与结果奖励结合使用。
• 格式与工具合法性奖惩：输出符合 JSON Schema（结构定义）、工具调用合法、参数通过权限与范围校验，作为独立的奖励分量。
• 延迟与成本惩罚：对 Token（词元）、轮次（Turn）、轨迹（Trajectory）长度施加成本惩罚；信用分配（Credit Assignment）可按 token/turn/trajectory 粒度设计。
• 信用分配方法：GRPO（组相对策略优化）对同一问题采样一组轨迹、用组内相对排名作为优势函数（Advantage），去掉 Critic（评论家模型）以降低计算成本。
• Reward Hacking（奖励作弊）防护：防止模型钻奖励漏洞（如刷格式分而不完成任务），任务是否完成要独立验证而非依赖模型自述。
• 区分训练指标与线上成功：训练奖励上升不等于线上任务成功率提升，最终以线上成功率与延迟、成本指标验收。

面试官关注点： 是否理解稀疏奖励与多步信用分配的难点，能否防奖励作弊并区分训练指标和线上成功。

★★ 50. 百万级 DAU（日活跃用户）的高并发 Agent 服务架构如何设计？稳定性如何保障？

参考答案：

• 容量估算：用 L=λW（在途任务数≈到达率×平均在途时间）估算并发需求，声明并行、到达分布与利用率假设；平均并发不等于所需机器数，按峰值和尾延迟规划容量。
• 接入与调度：负载均衡（Nginx/K8s Ingress，K8s 即 Kubernetes 容器编排）→ 请求队列（Kafka/RabbitMQ）→ Agent 服务集群；拒绝或排队优于无限超卖，沙箱等资源按规格池化、租户配额、公平调度、并发上限、热池预热与空闲回收。
• 分层执行：语义缓存层（相似 query 直接命中）→ LLM 推理层（vLLM/TGI，Continuous Batching 连续批处理）→ 向量检索层（Milvus 集群）→ 工具调用层（异步执行 + 超时控制）。
• 流式体验：SSE（服务器发送事件）/WebSocket（全双工通信协议）流式返回，长时间任务做进度通知。
• 稳定性保障：降级策略（LLM 超时返回预设回答）、超时管理与重试（幂等键、指数退避、补偿事务、结果日志，超时不等于未执行）、失败预算与无进展（no-progress）检测转人工，高风险操作人工审批。
• 成本与租户：模型路由分流（简单问题用小模型）、Token 计量与按业务方配额；多租户隔离、RBAC（基于角色的访问控制）、合规审计、灰度发布。
• 验证与排障：优化要看 P50/P95 尾分位与质量回归；故障时先区分服务等待与执行耗时，关联排队、连接池、依赖延迟等证据再定位。

面试官关注点： 能否从容量估算、分层架构到降级兜底形成闭环，稳定性手段可量化、可回滚。