【三年面试五年模拟】2026-08-18_哔哩哔哩AI应用岗Agent开发一面面经全解析（含完整答案）

写在前面

欢迎大家关注Rocky的公众号：WeThinkIn

欢迎大家关注Rocky的知乎：Rocky Ding

《三年面试五年模拟》AIGC/LLM/AI Agent算法工程师/开发工程师求职面试秘籍独家资源：【三年面试五年模拟】WeThinkIn/AIGC-Interview-Book，欢迎大家Star～

Rocky最新撰写的10万字AI Agent（AI智能体）深入浅出全维度解析文章： 深入浅出完整解析AI Agent（AI智能体）的核心基础知识

AIGC/LLM/AI Agent算法岗/开发岗求职面试内推学习社群 （涵盖AIGC、LLM大模型、AI Agent、传统深度学习、自动驾驶、机器学习、计算机视觉、自然语言处理、强化学习、大数据挖掘、具身智能、元宇宙、AGI等AI行业最新面试干货经验与核心知识）欢迎大家加入：https://t.zsxq.com/33pJ0

大家好，我是Rocky。

一面

1、简单介绍一下自己的背景，以及选择AI Agent方向的原因。

回答：

建议用 60～90 秒完成"背景 -> 证据 -> 方向选择 -> 岗位匹配"的闭环，而不是罗列课程和模型名称。背景部分说明自己的学历或工作阶段、主技术栈，以及最相关的项目；项目部分说明业务目标、个人负责的模块、关键技术决策和可验证结果；最后解释为什么从传统开发转向 Agent。

选择 AI Agent 的本质理由不是"它是热点"，而是它把大模型的语义理解与真实软件系统的工具、状态和业务验收连接起来。传统软件擅长确定性流程，大模型擅长处理自然语言和开放式任务，但单次生成容易缺少事实、状态和执行能力。Agent 工程要解决的正是如何让模型在权限、预算、工具协议、记忆和验证器约束下完成多步任务。

比较稳妥的结尾是："我选择 AI Agent，是因为它与我已有的工程能力是连续的。我可以用后端能力处理状态、并发、权限、幂等和可观测性，再结合模型调用、RAG、工具编排和评测，把模型能力变成可交付的业务流程。"其中项目数字必须来自真实记录；没有线上数据就明确说是离线评测或故障回放结果。

2、一个完整的Agent系统通常包含哪些核心模块？相比传统LLM Chatbot，它最大的区别是什么？

回答：

完整 Agent 通常至少包含以下模块：

接入与身份层： 用户、租户、会话、鉴权、配额、输入校验和风险分级。
任务与状态层： 目标、约束、计划、步骤状态、工具结果、产物引用、checkpoint 和终止条件。长任务状态不能只存在 Prompt 中。
上下文构建层： 按当前步骤选择系统规则、近期对话、结构化状态、RAG 证据、长期记忆和候选工具，并管理 Token 预算。
决策与编排层： 意图路由、规划、模型选择、Workflow/状态机/ReAct 循环、重规划和停止策略。
工具执行层： 工具注册、Schema、参数校验、权限、超时、幂等、限流、沙箱、结果裁剪和副作用确认。
知识与记忆层： 文档索引、检索、用户或项目记忆、事件日志、写入门控、冲突处理和过期删除。
验证与治理层： 规则校验、测试、业务状态验收、重试、熔断、降级、回滚、人工审批和安全审计。
可观测与评测层： 全链路 Trace、模型/Prompt/工具版本、Token、延迟、任务成功率、工具正确率、成本和安全指标。

传统 LLM Chatbot 通常是"输入 -> 一次或有限次生成 -> 文本输出"，状态和外部知识可能存在，但模型一般不负责动态选择并执行多步动作。Agent 的核心区别不是多了一层 Prompt，而是存在一个受约束的闭环：

s t → decide a t → tool/environment o t + 1 → validate/update s t + 1 s_t \xrightarrow{\text{decide}} a_t \xrightarrow{\text{tool/environment}} o_{t+1} \xrightarrow{\text{validate/update}} s_{t+1} stdecide attool/environment ot+1validate/update st+1

模型给出下一步候选决策，Harness 负责权限与执行，外部环境返回真实 Observation，状态更新后再决定下一步。终止也应由外部验收条件确认，而不是模型说"已经完成"。固定步骤的业务仍优先使用 Workflow，不能为了使用 Agent 而把确定性流程模型化。

3、在Agent项目中，常见的规划（Planning）、记忆（Memory）、工具调用（Tool Use）和执行模块分别承担什么职责？

回答：

Planning： 把用户目标、约束和可用资源拆成有依赖关系的步骤，明确每一步的输入、产物、工具和完成条件。复杂任务要把计划外置、版本化；环境变化或步骤失败时进行局部重规划，而不是每轮无条件重写全部计划。
Memory： 保存当前任务状态和跨会话可复用的信息。短期记忆负责目标、计划、最近对话和工具结果的连续性；长期记忆保存经过筛选的偏好、事实、事件或经验，并带作用域、来源、置信度、时间和权限。
Tool Use： 把模型意图映射为结构化工具调用，负责工具发现、Schema、参数、权限、超时、幂等和结果回传。工具不是模型的"外挂函数"，而是有副作用、有容量限制和失败语义的外部系统。
Execution： 驱动状态机或 Agent Loop，执行当前可执行步骤，写入 Observation 和 checkpoint，运行验证器，并决定继续、重试、重规划、降级或人工接管。

四者不是四个必须独立部署的模型。小任务可以由一个编排器完成，长任务则应把规划和状态外置、把工具执行交给确定性运行时。面试时应说明哪些动作由模型决定、哪些规则由代码强制，以及失败后如何恢复，这比单纯背诵模块名更重要。

4、意图识别模块通常有哪些实现方式？规则匹配、小模型分类和LLM分类分别适用于哪些业务场景

回答：

意图识别可以按复杂度和不确定性分为三类：

规则匹配： 使用关键词、正则、词典、有限状态机或高置信业务条件。延迟低、可解释、容易审计，适合"退款/取消/转人工"等边界清晰且高风险的意图。但它对表达变体和隐含语义不鲁棒，规则过多后维护成本会快速上升。
小模型分类： 使用 TF-IDF/线性模型、轻量 Transformer、句向量分类器或蒸馏模型。它适合意图集合相对稳定、已有标注数据、吞吐和成本敏感的线上场景。应输出类别概率或置信度，配合拒识类和人工/LLM fallback；不能把最高概率直接当成绝对正确。
LLM 分类： 通过 Zero-shot、Few-shot 或微调完成开放语义分类、层级意图识别和低样本冷启动。它适合类别变化较快、语义复杂、需要解释或同时抽取槽位的场景，但成本、延迟、格式稳定性和越权风险更高。

工程上通常是分层路由：先用规则处理高置信高风险类，再用小模型覆盖大多数稳定请求，低置信、长尾和新类交给 LLM；最终还要由权限和业务状态校验工具动作。比较方案时看 macro-F1、各类召回率、拒识准确率、校准误差、P95 延迟、Token 成本和错误意图的业务损失，而不是只看总体准确率。

5、如果使用大模型完成意图分类，如何选择Zero-shot、Few-shot方案？当标注数据较少时，如何提升分类稳定性？

回答：

Zero-shot 只给任务定义、类别说明和输出 Schema，适合类别定义清晰、样本表达变化大、需要快速冷启动的场景。Few-shot 额外提供少量高质量示例，适合类别边界容易混淆、输出格式有特殊约定或模型不熟悉领域术语的场景。示例不应只堆正常样本，还要覆盖相邻类别、拒识、缺槽位和对抗输入。

可以按验证集做选择，而不是凭感觉：固定模型、温度、Prompt 和输出 Schema，比较 Zero-shot/Few-shot 在宏平均 F1、混淆矩阵、拒识率、解析成功率、延迟和成本上的结果。类别较多时可先做粗粒度领域路由，再做细粒度分类，减少一次 Prompt 中的类别竞争。

标注少时的稳定化手段包括：

先定义互斥、完备、可判定的标签规范，给每类写正例、反例和边界说明；
让模型输出结构化 intent、confidence、evidence，服务端用 Schema 和枚举校验；
采用多次采样或多个提示模板做一致性检查，但要设置成本上限，不能用多数投票掩盖标签定义问题；
用主动学习优先标注低置信、易混淆和高业务损失样本；
进行同义改写、噪声和对抗样本增强，并保留真实线上分布的验证集；
让低置信或新意图进入拒识/人工/更强模型路径，不强迫模型在错误标签中选择；
当任务稳定且数据规模足够时再做监督微调或蒸馏，并通过版本化回归集验证。

Temperature 降到 0 只能减少随机性，不能保证正确；真正的稳定来自标签边界、示例质量、结构化约束、拒识机制和持续评测。

6、RAG系统从文档进入到最终生成答案的完整流程是什么？离线知识库构建和在线检索阶段分别包含哪些步骤？

回答：

离线阶段先处理数据质量，而不是直接切片：采集文档，解析 PDF/HTML/Office 等格式，保留标题、段落、表格、代码和页码等结构；清洗重复、导航、乱码和无效内容；按章节、语义或布局切分，并为每个 Chunk 写入文档 ID、标题路径、页码、权限、版本和时间等元数据。然后使用与查询同分布的 Embedding 生成向量，建立向量索引，同时为关键词检索建立倒排索引；必要时生成父文档关系、摘要或实体索引。

在线阶段通常是：

识别问题类型、权限和过滤条件；
做 Query Rewrite、查询扩展、语言归一化或拆分多跳问题；
并行执行稠密向量召回、BM25/倒排召回、结构化过滤和必要的父文档召回；
合并候选集并去重，使用 RRF、加权分数或学习排序融合；
通过 Cross-Encoder 或 LLM Reranker 对候选 Chunk 重排，并根据上下文预算截断；
把证据、来源和不确定性注入 Context，要求模型只基于证据回答，证据不足时拒答或澄清；
对答案做引用、事实一致性、权限和格式校验，记录检索与生成 Trace。

评测要拆开看：检索侧看 Recall@K、MRR、nDCG、证据覆盖率和权限过滤正确率；生成侧看答案正确性、忠实度、引用准确率、拒答准确率、延迟和成本。RAG 不是"向量库 + Prompt"，而是一条从数据治理到答案验收的系统链路。

7、文档切片有哪些常见策略？RecursiveCharacterTextSplitter的实现逻辑是什么？针对中文文档处理需要注意哪些问题？

回答：

常见切片策略包括固定 Token/字符长度、按标题和段落的结构切片、语义边界切片、递归分隔符切片，以及父子文档索引。固定长度简单稳定，但容易切断定义；结构切片可读性好，但遇到超长段落仍需要二次切分；语义切片成本更高，需要验证收益；父子索引可以用小块召回、用较大父块提供上下文。

RecursiveCharacterTextSplitter 的核心逻辑不是按一个分隔符硬切，而是维护一组从粗到细的分隔符，例如段落、换行、句号、空格和空字符串：先用当前分隔符拆分文本；对仍超过 chunk_size 的片段递归使用下一级分隔符；对已经足够短的相邻片段按长度合并，并通过 chunk_overlap 保留边界上下文。最终还要处理空片段、超长不可分字符串和长度单位选择。不同版本的实现细节可能变化，应以使用的 LangChain 版本源码和测试为准。

中文处理要注意：中文没有稳定空格，不能把空格当作主要词边界；应优先保留段落、标题和中文句末标点，再考虑按 Token 长度控制；中英文混排、代码、表格、URL 和 Markdown 标记要分别处理；不要在表格行、公式、代码块中间随意切断；重叠应按 Token 或语义验证，不迷信固定字符数；为每块保留标题路径、页码和权限信息。切片参数必须在目标文档集上用 Recall@K、证据完整率和生成正确性做对比，不能把 chunk_size=固定值 当成普适答案。

8、如果RAG系统出现召回效果差的问题，你会如何定位？会优先检查Embedding、Chunk策略、Query Rewrite、Hybrid Search还是Rerank？

回答：

我会先把"召回差"拆成索引覆盖问题、候选召回问题和排序问题，而不是直接调 Rerank。用带有标准答案证据块的离线数据集做逐层回放，记录原始 Query、改写 Query、召回候选、分数、过滤条件、Rerank 结果和最终引用。

定位顺序通常是：

数据与权限： 文档是否被成功解析和入库，版本是否最新，权限过滤是否误删，元数据是否正确，目标证据是否存在。
Chunk： 证据是否被切碎、标题是否丢失、块是否过长或过短、重叠是否合适，父子关系和去重是否正确。
Embedding： 查询和文档是否使用同一模型与相同归一化方式，模型是否支持中文和领域术语，向量库距离度量和索引参数是否匹配。
Query Rewrite： 改写是否改变了原意、丢失实体和否定条件；把原 Query 与改写 Query 都纳入召回，避免错误改写成为单点故障。
召回策略： 对术语、编号、产品名、精确短语和数值问题，BM25 往往补足向量召回；通过 RRF 或校准后的加权融合比较增益。
Rerank： 只有候选集中已经包含正确证据时，Rerank 才能解决排序问题；如果 Top-N 候选里没有证据，换 Reranker 不能补回缺失文档。

所以我会先验证候选集 Recall，再判断是否是排序问题。最终用分层实验比较 Base Embedding、Chunk、Query Rewrite、Hybrid 和 Rerank 的增量，不用单个线上案例决定参数。

9、Embedding模型如何选择？不同Embedding模型会对检索效果产生哪些影响？

回答：

Embedding 模型把文本映射到向量空间，使语义相关文本距离更近。选择时要看目标语言、领域、输入长度、查询/文档任务是否匹配、部署形态、维度、推理吞吐、许可和成本，而不是只看通用榜单分数。

具体要检查：中文和中英混合能力，技术术语、产品名、编号和长文档表现，是否有 query/document 不同指令，最大上下文和截断策略，向量维度与存储成本，归一化方式与距离度量，以及模型是否支持批量、量化和本地部署。若数据敏感，本地部署和数据不出域可能比少量离线分数更重要。

模型会影响三个层面：

语义召回： 近义表达、跨语言和上下位概念是否聚近；过度语义化可能把关键词相近但事实不同的文档召回。
细节区分： 版本号、错误码、类名和数字等精确信息通常需要 BM25/倒排补充。
系统资源： 维度、索引大小、编码速度和延迟直接影响成本与吞吐；模型升级还可能改变向量分布，不能直接混用旧索引。

最终应构建与线上分布一致的 Query-证据集，比较 Recall@K、MRR/nDCG、长短问题、中文术语、噪声和权限场景，并同时记录 P95、吞吐、内存、成本和版本迁移方案。Embedding 是召回组件，不是完整 RAG 质量的唯一决定因素。

10、LangChain框架主要有哪些核心组件？相比传统Chain模式，LCEL带来了哪些改进？

回答：

LangChain 的核心可以按抽象职责理解：模型接口，Prompt 模板，输出解析器，Retriever/VectorStore，Document 与文档加载/切分，Tools，Memory/Checkpoint，Runnable/Callback/Tracer，以及用于组合的链和 Agent。不同版本 API 会变化，回答时应以当前项目实际使用的版本为准，不要把旧版 LLMChain 的组织方式当成永远不变的接口。

传统 Chain 往往是手写顺序调用：先格式化 Prompt，再调用模型，再解析，再把结果传给下一个 Chain。LCEL（LangChain Expression Language）把这些步骤统一为 Runnable，使用管道和组合表达式描述数据流，从而获得：

统一的 invoke、批量和流式接口；
更清晰的输入输出契约和可组合性；
对并行、分支、fallback、重试和配置覆盖的统一表达；
callback/tracing、事件流和运行时配置更容易接入；
能把固定链与 Agent/工具节点组合，而不必每一步都手写胶水代码。

但 LCEL 不等于自动获得可靠性。生产系统仍要明确状态、超时、重试边界、幂等、权限、版本和验证器；对于有大量循环、分支和持久化状态的流程，LangGraph 或自研状态机可能更合适。框架的价值是降低编排成本，系统正确性仍由架构和测试负责。

11、Function Calling和Tool Calling的执行流程是什么？模型是如何判断需要调用工具，以及生成对应参数的？

回答：

Function Calling 和 Tool Calling 的核心机制相同：服务端向模型提供工具名称、描述、参数 JSON Schema 和使用约束；模型根据用户目标与当前上下文决定直接回答，或输出结构化的工具调用意图。真正执行函数的是应用侧运行时，不是模型本身。

标准流程是：

应用注册当前允许的工具及 Schema；
模型读取用户问题、系统规则、工具描述和历史 Observation，产生文本回复或 tool_calls；
应用解析调用名和参数，进行 Schema、类型、权限、资源状态、预算和安全策略校验；
合法调用进入工具运行时，工具返回结构化结果或结构化错误；
应用把结果以工具消息写回上下文；
模型根据 Observation 决定继续调用、修正参数、请求用户补充信息或生成最终答案；
外部验证器检查任务是否真的完成。

模型并不是通过执行代码"判断"是否需要工具，而是在训练和上下文条件下预测工具调用或普通文本的概率。它是否选对工具取决于工具描述、候选集合、模型能力、当前状态和示例。参数合法不等于业务正确，所以必须由服务端再次校验；有副作用的调用还需要幂等键、状态回读和人工审批。Function/Tool Calling 是协议和输出形态，不自动等于完整 Agent。

12、如果Agent接入大量工具，如何避免工具描述过长导致Prompt膨胀？有哪些优化方式？

回答：

核心原则是工具渐进披露：模型不需要在每一轮看到所有工具的完整 Schema。可以采用以下方案：

先用规则、小模型或轻量 LLM 做意图/领域路由，只暴露当前任务可能用到的工具；
建立工具目录，第一阶段只给工具名、短描述、标签和能力摘要，模型选定候选后再加载详细 Schema；
合并高度相似的工具，统一参数模型，减少重复描述；
将稳定的工具文档放在外部检索库，按需获取示例、错误码和约束；
对多 Agent 采用按角色分配工具，子 Agent 只看到自己的最小权限集合；
对参数枚举、默认值和必填项使用结构化 Schema，减少自然语言冗余；
缓存版本化的公共工具描述，监控工具 Token 占比和选择错误率；
对工具结果做裁剪、摘要和结构化投影，避免 Observation 反过来造成上下文膨胀。

工具发现本身也要可验证。目录搜索不能把不存在的工具、过期版本或越权工具暴露给模型；工具被选中后仍要由服务端做权限和 Schema 校验。应通过任务成功率、工具选择准确率、参数解析率、Token、P95 延迟和错误率比较"全量工具描述"和渐进披露，而不是只看 Prompt 变短。

13、Prompt一般如何设计和组织？System Prompt、Few-shot示例以及CoT通常分别承担什么作用？

回答：

Prompt 设计应围绕任务契约组织：目标与非目标、输入边界、可信数据来源、决策规则、工具使用条件、输出 Schema、失败语义和示例。不同内容要按优先级和生命周期分区，避免把所有东西堆成一段无法维护的长文本。

System Prompt： 定义角色边界、任务目标、不可违反的安全与权限规则、输出协议和可用能力。它不是绝对安全边界，真正的权限、金额、数据写入和合规规则仍必须在代码和策略引擎中执行。
Few-shot： 通过少量样例展示输入到输出的映射、标签边界、格式和拒答方式。示例应覆盖易混类别、边界条件、错误用法和反例；质量比数量更重要。
CoT： 指引模型分解复杂问题或进行中间推理。生产系统不应默认把完整私有推理过程原样暴露给用户或长期保存，更稳妥的是要求输出可验证的中间结构、依据、步骤摘要或工具调用计划，并通过测试和验证器检查。

Prompt 优化还包括 Query/Context 选择、任务拆分、结构化解码、工具和外部知识接入、模型与采样参数适配。每次改动应在固定回归集上比较任务成功率、事实正确率、解析成功率、拒答准确率、Token、延迟和成本；"规则写得更多"本身不是质量提升。

14、如何降低大模型输出幻觉？除了Prompt约束之外，还有哪些工程优化方案？

回答：

幻觉包括事实不存在、证据不支持、引用错配、工具结果误读和业务状态误判，不能只靠一句"不要编造"。工程上要把生成任务变成有证据、有边界、有验收的流程：

Grounding： 对时效性或领域事实使用 RAG、数据库、搜索或业务 API；要求答案绑定证据片段、页码或结构化字段，证据不足就澄清或拒答。
工具化计算： 金额、日期、统计、权限和状态查询由确定性程序完成；模型只负责理解意图和组织结果。
结构化输出与校验： 使用 JSON Schema、枚举、类型和范围检查；对引用存在性、字段一致性和业务不变量做服务端验证。
拆分与验证： 将抽取、检索、推理、生成和审查分段，使用规则、单元测试、数据库状态或独立评估器验收；不要让模型自称完成作为唯一标准。
模型和解码控制： 选择与任务匹配的模型，合理设置温度和输出长度；高风险场景宁可走人工或模板路径，也不要用更高随机性换"自然"。
数据与评测治理： 修复训练/知识库中的冲突和过期文档，维护真实分布的回归集，分层统计事实错误、拒答错误、引用错误、工具误用和严重业务损失。
运行时安全： 对外部文档和工具返回标记为不可信数据，防止 Prompt Injection；隔离权限、预算和副作用，记录完整 Trace 便于回放。

最终指标不能只看"看起来流畅"。应同时测答案正确率、证据忠实度、引用精确率、拒答准确率、工具状态一致性、敏感信息泄漏率、成本和延迟。幻觉治理的本质是缩小模型可以无依据自由发挥的空间，并把关键结论交给外部证据和确定性系统确认。

15、Agent执行任务时，如果出现重复调用工具、无法结束或者任务循环的问题，应该如何设计保护机制？

回答：

我会从"检测、限制、恢复、验收"四层设计：

重复检测： 对规范化后的工具名、参数、当前状态版本和结果摘要计算动作指纹；连续相同调用、同一错误参数重复修正、状态没有变化的调用都应触发告警。不能只比较原始 JSON，因为字段顺序和无关参数可能不同。
预算限制： 设置最大步数、总 deadline、模型调用次数、Token/费用预算、单工具重试次数和最大并行分支数；预算由运行时强制，不能交给模型自己承诺。
状态与终止： 使用显式状态机和 checkpoint，定义外部完成条件、失败条件和升级条件；只有业务状态、测试或验证器满足要求才进入 DONE。
错误恢复： 区分瞬时错误、参数错误、权限错误和不确定副作用。可重试错误使用有上限的指数退避；写操作用幂等键并先查询状态；连续失败可重规划、降级到只读/模板流程或人工接管。
上下文治理： 对工具结果做大小上限、摘要和结构化投影，避免模型被无关 Observation 推向循环；保留原始结果引用以便回查。

循环检测不应简单地"看到两次相同调用就停止"，因为有些轮询本来需要等待状态变化。应结合状态版本、时间窗口、进度信号和工具语义判断。例如轮询任务必须要求 status 在 deadline 内发生变化，否则转人工。所有中止原因、动作指纹、预算消耗和最终状态都要进入 Trace，才能在回放中修复策略。

16、Agent中的Memory通常如何实现？短期记忆和长期记忆分别解决什么问题？

回答：

短期记忆解决当前任务的连续性：模型要知道用户目标、约束、最近对话、计划、已经完成的步骤、工具结果和待确认事项。实现上通常把结构化任务状态放在 Workflow checkpoint、Redis 或数据库中，把最近消息保留为窗口，把已完成阶段压缩为摘要和事件引用；Prompt 只是这些状态在当前步骤的投影视图。KV Cache 是推理加速状态，不是 Agent Memory。

长期记忆解决跨会话复用：例如经过确认的用户偏好、项目约定、历史事件和可复用经验。不同数据使用不同存储：稳定事实和权限关系用关系表或 KV，事件用 append-only log，自然语言经验用向量加全文混合索引，实体关系复杂时再考虑图结构。每条记忆应带用户/租户/项目作用域、来源、时间、置信度、有效期、权限和原始事件引用。

完整生命周期是：候选提取 -> 敏感性/重要性过滤 -> 去重和结构化 -> 写入 -> 按需检索 -> 权限、时效和相关性重排 -> 注入 -> 冲突更新、过期或删除。当前用户明确指令优先于旧偏好，业务主库的实时事实优先于历史摘要，模型推断不能覆盖明确事实。记忆系统的目标不是保留最多，而是在正确作用域内提供可纠正、可追溯且对未来任务有价值的信息。

17、如何设计一个记忆检索流程？历史信息应该如何筛选、存储和召回？

回答：

可以把流程设计成"写入门控 -> 多路存储 -> 查询召回 -> 重排注入 -> 反馈更新"。

写入门控： 从对话和工具事件中提取候选事实，判断是否稳定、可复用、由谁确认、是否敏感，过滤寒暄、一次性状态和未经证实的推断。对用户偏好最好让用户确认或保留低置信标记。
分型存储： 身份、权限和稳定偏好放结构化数据库；事件放带时间和版本的事件表；语义经验写入向量/全文索引；大对象只保存引用。不要把所有聊天原文无差别塞进一个向量库。
查询构建： 从当前目标、实体、时间约束和用户/项目作用域生成检索条件；必要时做查询改写，但保留原始查询，避免改写错误丢失关键条件。
多路召回： 结构化过滤、关键词、向量和时间/实体索引并行召回，去重并合并；先执行权限过滤，不能在召回后才把越权内容交给模型。
重排与注入： 按相关性、时效、置信度、来源可靠性、冲突状态和 Token 预算重排；注入时标记为记忆而非当前事实，并保留来源和更新时间。
反馈更新： 记录是否被引用、是否帮助任务成功、是否被用户纠正；纠正应产生新版本或失效旧版本，而不是静默覆盖审计记录。

评价要看记忆 Precision/Recall、错误记忆引用率、任务成功率、重复询问减少量、跨用户串线率、删除可达性和 Token 成本。长期记忆必须作用域隔离，且要支持用户查看、修改和删除，这是功能正确性和隐私合规的一部分。

18、手撕代码：合并重叠区间（LeetCode 56），并分析算法复杂度

回答：

先按区间左端点升序排序。遍历排序后的区间，维护结果中最后一个区间 last：如果当前区间的左端点大于 last 的右端点，说明两者不重叠，直接加入结果；否则把 last 的右端点更新为两者右端点的最大值。边界相等时通常视为可以合并，例如 [1, 4] 与 [4, 5] 合并成 [1, 5]。

python 复制代码

from typing import List


def merge(intervals: List[List[int]]) -> List[List[int]]:
    if not intervals:
        return []

    intervals.sort(key=lambda item: item[0])
    merged: List[List[int]] = [intervals[0][:]]

    for start, end in intervals[1:]:
        last = merged[-1]
        if start <= last[1]:
            last[1] = max(last[1], end)
        else:
            merged.append([start, end])

    return merged

排序耗时 O(n log n)，线性合并耗时 O(n)，总时间复杂度为 O(n log n)；结果之外的额外空间复杂度为 O(1)（忽略排序实现栈和输入是否原地修改），如果不修改输入则复制并排序，额外空间通常为 O(n)。需要说明空数组、单区间、完全包含、链式重叠、相邻端点和负数端点等边界情况。算法成立的关键是不变量：遍历到当前位置时，merged 已经是此前所有区间的最小不重叠表示。

【三年面试五年模拟】2026-08-18_哔哩哔哩AI应用岗Agent开发一面面经全解析（含完整答案）

写在前面

一面

1、简单介绍一下自己的背景，以及选择AI Agent方向的原因。

2、一个完整的Agent系统通常包含哪些核心模块？相比传统LLM Chatbot，它最大的区别是什么？

3、在Agent项目中，常见的规划（Planning）、记忆（Memory）、工具调用（Tool Use）和执行模块分别承担什么职责？

4、意图识别模块通常有哪些实现方式？规则匹配、小模型分类和LLM分类分别适用于哪些业务场景

5、如果使用大模型完成意图分类，如何选择Zero-shot、Few-shot方案？当标注数据较少时，如何提升分类稳定性？

6、RAG系统从文档进入到最终生成答案的完整流程是什么？离线知识库构建和在线检索阶段分别包含哪些步骤？

7、文档切片有哪些常见策略？RecursiveCharacterTextSplitter的实现逻辑是什么？针对中文文档处理需要注意哪些问题？

8、如果RAG系统出现召回效果差的问题，你会如何定位？会优先检查Embedding、Chunk策略、Query Rewrite、Hybrid Search还是Rerank？

9、Embedding模型如何选择？不同Embedding模型会对检索效果产生哪些影响？

10、LangChain框架主要有哪些核心组件？相比传统Chain模式，LCEL带来了哪些改进？

11、Function Calling和Tool Calling的执行流程是什么？模型是如何判断需要调用工具，以及生成对应参数的？

12、如果Agent接入大量工具，如何避免工具描述过长导致Prompt膨胀？有哪些优化方式？

13、Prompt一般如何设计和组织？System Prompt、Few-shot示例以及CoT通常分别承担什么作用？

14、如何降低大模型输出幻觉？除了Prompt约束之外，还有哪些工程优化方案？

15、Agent执行任务时，如果出现重复调用工具、无法结束或者任务循环的问题，应该如何设计保护机制？

16、Agent中的Memory通常如何实现？短期记忆和长期记忆分别解决什么问题？

17、如何设计一个记忆检索流程？历史信息应该如何筛选、存储和召回？

18、手撕代码：合并重叠区间（LeetCode 56），并分析算法复杂度

推荐阅读

1. 深入浅出完整解析AI Agent（AI智能体）的核心基础知识

2. 深入浅出完整解析扩散模型DDPM、DDIM、Score-Based、SDE、LDM、Classifier/Classifier-Free Guidance、Rectified Flow核心基础知识

3. 入浅出完整解析FLUX.2、Seedream（即梦）、Z-image、GLM-Image核心基础知识

4. 深入浅出完整解析FLUX.1 Kontext和FLUX.1 Krea核心基础知识

5. 深入浅出完整解析DeepSeek系列核心基础知识

6. 深入浅出完整解析Stable Diffusion 3（SD 3）和FLUX.1系列核心基础知识

7. 深入浅出完整解析Stable Diffusion XL（SDXL）核心基础知识

8. 深入浅出完整解析Stable Diffusion（SD）核心基础知识

9. 深入浅出完整解析Stable Diffusion中U-Net的前世今生与核心知识

10. 深入浅出完整解析LoRA（Low-Rank Adaptation）模型核心基础知识

11. 深入浅出完整解析ControlNet核心基础知识

12. 深入浅出完整解析Sora、Seedance、keling等AI视频大模型核心基础知识

13. 深入浅出完整解析AIGC时代Transformer核心基础知识

14. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识

15. 深入浅出完整解析ComfyUI、Diffusers、Stable Diffusion WebUI等主流AIGC创作框架核心基础知识

16. AIGC产业的深度思考与分析

17. AI算法工程师的独孤九剑秘籍

18. 深入浅出完整解析AIGC时代中GAN（Generative Adversarial Network）系列模型核心基础知识