小红书 AI Agent开发 一面

1. 自我介绍

2. 介绍你写的这个项目

3. 为什么要做多 Agent，而不是把所有能力都塞进一个 Agent

多 Agent 的核心价值不是“看起来更高级”，而是把复杂任务里的角色分工显式化。单 Agent 在任务很长、工具很多、约束很多的时候，容易把规划、检索、判断和执行混在一起，导致上下文污染、错误放大、调试困难。多 Agent 可以把流程拆成规划 Agent、检索 Agent、执行 Agent、审查 Agent，每个 Agent 只负责一类清晰目标，行为边界更稳定。

但多 Agent 也不是默认更好。它会引入额外通信成本、状态同步复杂度和错误传播路径。真正适合多 Agent 的场景，一般满足三个条件：任务天然可分阶段，子任务之间职责边界清晰，且单 Agent 已经出现了明显的长链路退化。否则很多系统只是把单 Agent 的问题分散成多个 Agent 的问题。

4. MCP、Function Calling、Skills、Agent 分别是什么，它们之间是什么关系

MCP 更像一个标准化的上下文和工具接入协议，它解决的是模型怎么跟外部资源、工具、数据源用统一方式通信的问题。Function Calling 是模型输出结构化调用意图的一种接口能力，重点是让模型把“要调用什么工具、传什么参数”表达清楚。Skills 一般指被封装好的可复用能力单元，比如“查工单”“检索日志”“总结告警”。Agent 则是能围绕目标进行规划、调用能力、处理反馈并迭代执行的调度主体。

它们的关系可以理解成：MCP 负责“接得规范”，Function Calling 负责“调得出来”，Skills 负责“能力可复用”，Agent 负责“把能力组合成任务闭环”。很多面试里把这几个词混着说，但真落地时它们是不同层次的问题。

5. Agent 的规划、执行、反思三段式链路怎么设计

规划阶段的目标不是直接给答案，而是把用户目标拆成若干可执行步骤，并显式标出每一步需要哪些工具、输入依赖和终止条件。执行阶段严格按步骤推进，每一步记录中间状态和工具返回，尽量减少隐式假设。反思阶段不是让模型重新自由发挥，而是基于执行轨迹检查目标是否完成、证据是否充分、有没有漏调用关键工具、是否触发了冲突规则。

真正稳定的设计通常不会让反思阶段无限循环，而是给出明确预算，比如最多重试几轮、在哪些失败类型上允许回滚、哪些错误必须人工接管。否则系统很容易变成“模型自己和自己讨论半天”，成本和时延都失控。

6. Agent 的记忆一般怎么分层，为什么不能只靠聊天历史

只靠聊天历史的问题是，短期上下文会越来越长，而且混入大量无关内容，最后影响当前任务判断。比较常见的记忆分层是短期工作记忆、长期用户记忆和外部事实记忆。短期工作记忆保存当前任务的中间状态，比如已调用过哪些工具、哪些步骤已完成；长期用户记忆保存偏好、习惯和稳定背景信息；外部事实记忆则来自知识库、文档库和历史事件流。

这三层不能混在一起。工作记忆强调时效和可更新，长期记忆强调稳定和摘要，外部事实记忆强调可检索与可追溯。一个可控的 Agent 系统，一定会把“会话痕迹”与“事实知识”明确区分，不然很容易把一次性的错误推断沉淀成长期记忆污染。

7. RAG 可以怎么分类，Agentic RAG 和传统 RAG 差别在哪

RAG 至少可以按召回方式、推理形态和流程控制来分。按召回方式可以分 sparse、dense、hybrid、graph-based；按推理形态可以分一次检索一次生成、迭代检索、查询分解检索、多跳检索；按流程控制可以分静态 RAG 和 Agentic RAG。传统 RAG 更像固定链路：改写 query、召回、重排、拼上下文、生成。Agentic RAG 则允许系统根据中间结果动态决定是否继续检索、是否换检索策略、是否触发工具、是否分解问题。

差别不只是“多了一层 Agent”。本质上，传统 RAG 假设一次检索足够，Agentic RAG 假设复杂问题需要多轮信息搜集与决策。前者链路短、时延稳，后者更灵活，但治理难度也更大。

8. RAG 项目里怎么做召回闭环，才能让系统真的越用越准

召回闭环的关键不是简单记录用户点击，而是把失败样本结构化。比较实用的做法是把 bad case 分成几类：没召回到、召回到了但排序错、证据足够但生成错、证据冲突导致归因错。只有先分型，后面的优化方向才明确。比如“没召回到”通常查 query rewrite、chunk 策略、embedding 模型和索引覆盖；“召回到了但没排上来”更多看 rerank 和融合策略。

线上闭环最好把用户问题、改写后的 query、各路召回结果、重排结果、最终上下文和答案都记录下来，再回流到训练和评测。否则你只能知道“用户不满意”，却不知道问题到底出在检索、排序还是生成。

9. HyDE 的原理是什么，什么时候有效，什么时候会害人

HyDE 的核心思想是先让模型根据问题生成一个“假想文档”或“理想答案草稿”，再把这个草稿编码成向量去做检索。这样做的好处是，用户原始 query 可能很短、很口语化、信息密度低，而假想文档更接近知识库里的自然表达形式，因此 dense retrieval 更容易对上语义空间。

它有效的前提是问题本身具备较强的语义可展开性，比如知识问答、技术问答、规范查询。如果问题本来就很歧义，或者模型先生成的草稿已经带偏了方向，HyDE 会把错误先验进一步放大，召回会越来越像“按错误假设去找证据”。所以 HyDE 不能无脑开，最好配合原始 query 检索并做融合。

def hyde_prompt(query: str) -> str:
    return f"""请不要回答用户问题，只生成一段可能出现在知识库里的专业说明文字：
问题：{query}
要求：术语准确、包含上下文关键词、不要编造具体数值。"""

query = "数据库主从切换后为什么读到旧数据"
print(hyde_prompt(query))

10. IVF、PQ、IVF-PQ 分别在做什么，为什么它们能把向量检索做快

IVF 的思想是先把向量空间粗聚类，查询时先找到最相关的几个簇，再只在这些簇里搜，从而减少全量扫描。PQ 是产品量化，把高维向量切成多个子空间，每个子空间分别量化成较短编码，检索时用压缩表示近似计算距离，以换取更小的存储和更快的比较。IVF-PQ 就是先粗筛，再在候选集上用压缩编码做近似搜索。

它快的原因不是某个神秘公式，而是两层降本：先减少要搜的向量数量，再减少每个向量的距离计算成本。代价就是精度损失，所以工程上通常要调 nlist、nprobe、子空间数和码本大小，在召回率和时延之间做平衡。

11. 向量索引有哪些典型类别，分别适合什么场景

典型类别可以分为基于图的近邻索引、基于倒排聚类的索引、基于量化压缩的索引，以及它们的组合。HNSW 这类图索引通常召回效果很强，适合中高精度要求、内存资源相对充足的场景；IVF 更像粗筛框架，适合大规模库上的候选缩小；PQ、OPQ 这类量化压缩适合超大规模库和显存/内存敏感场景；工业系统里最常见的其实是组合方案，比如 IVF-HNSW、IVF-PQ、HNSW+rera