点击任意架构图查看大图

字节跳动 AI Agent 工程师 - 岗位要求

招聘方向

• AI Agent 研发工程师 - 开发者服务：研发环境管理、高可用治理、质量保障 AI 化
• 大模型应用后端工程师（Agent 方向）- 巨量星图：内容营销 Agent 系统

核心要求

学历

• 本科及以上，计算机及相关专业

编程能力

• 熟悉至少一门：Java / Python / Go / C/C++ / JS
• 良好的编程习惯和代码管理

大模型技术

• 熟悉 LLM 应用架构
• Prompt Engineering、上下文工程、数据评测
• 对 Agent、RAG、ReAct 等技术有认知和实践
• 了解 SFT/RLHF 等模型优化技术

AI Agent 核心

• Agent 流程设计、评估系统、上下文工程
• 工具开发（MCP 及其他工具协议）
• 有从 0→1 搭建 Agent 应用经验者优先
• 能独立完成 Agent 应用的设计、开发和部署

系统架构

• 服务化、异步、高可用、可扩展
• 监控、容灾等可靠性意识
• 服务端基础：Ray、数据库、消息队列、ES

特色要求

• 强调创新能力和创新意识
• 紧跟 AI 领域最新发展
• 良好的业务理解和跨团队沟通
• 研发效能方向经验加分

参考链接

• https://jobs.bytedance.com

字节跳动 AI Agent - 真实面经（牛客实录）

来源：牛客网 2025 年真实面经，持续更新

📌 面经 1：字节 AI Agent 一面（"面吐了"）

来源: 牛客网 2025-03-22 | 面试者自评：说不明白业务逻辑

面试问题（16 道）：

• 多模态大模型的具体结构
• 多模态的用户信息怎么存储和使用
• Agent 项目背景
• RAG 系统流程
• LoRA 的原理和 QLoRA 的原理，QLoRA 怎么优化显存？
• 演示 Agent 项目实现细节
• AI 辅助开发的实践经验
• 觉得当前的 Agent 达到预期了吗？对 Agent 的预期是什么
• 项目中 AI 贡献的代码占比
• 怎么进行多模态知识检索？
• RAG+MCP 这方面是你做的吗？怎么做的？RAG 怎么构建的
• A2A 与 MCP 区别（新热点！）
• 项目在研发过程中遇到了哪些困难，怎么解决的
• 较长较多的上下文怎么解决
• 项目用的什么架构
• Agent 项目开发的框架

面试者感受：面试很难，还是要多多练习，感觉自己说不明白业务逻辑

📌 面经 2：字节 AI Agent 二面

来源: 牛客网综合 | 继续深挖

面试问题：

• 继续项目深挖
• 多模态大模型的结构细节
• Agent skills 的设计
• 如何加强大模型记忆机制
• 多 Agent 执行策略的智能选择和切换机制设计
• SSE 的局限性
• LoRA 效果不佳怎么办？LoRA 的缺点与改进方向
• RAG 动态知识更新
• 复杂任务执行准确率评估
• 多轮对话实现方案
• RAG 评估方案
• 市场上的智能体 Agent 有哪些
• MCP 和 Function Calling 的关系
• 大模型项目遇到的问题

📌 面经 3：字节大模型算法（社招）

来源: 牛客网综合

流程：自我介绍 → 项目深挖 → 通用知识 → 手撕代码

项目深挖：

• 微调项目：业务背景、数据构成、训练方法、效果评估
• 应用层项目：幻觉问题处理、通用性、Agent 概念和流程

通用知识：

• Transformer、BERT、RoBERTa
• JSON 格式输出保证
• OOM 问题处理
• 大模型参数计算
• DeepSeek R1 原理
• 强化学习：Agent 概念和流程
• RAG 流程及评估
• 幻觉问题解决方案
• 数据合成方法
• DeepSpeed 使用
• 模型并行与数据并行

手撕代码：

• 手写位置编码
• 手写多头注意力机制
• LeetCode 算法题

⚠️ 字节面试关键洞察

• 一面就很硬核：16 道题覆盖全链路，从多模态到 MCP 到项目细节
• 必须能演示项目：不是说说就行，要现场展示实现细节
• A2A vs MCP 是新热点：字节已经在面试中考这个了
• AI 辅助开发经验：会问"AI 贡献了多少代码"——说明他们重视 AI Coding 实践
• 手撕代码偏 AI：不只是 LeetCode，还要手写位置编码、多头注意力
• DeepSeek R1 是必知：要了解其推理能力和强化学习方法

🔗 原始链接

• https://www.nowcoder.com/feed/main/detail/5b4751ec41104a40b513738125a03ffd
• https://www.nowcoder.com/feed/main/detail/d31969d954a94f1cb1bb06abc3196fe9

字节跳动 AI Agent 工程师 - 面试题 & 面经

面试流程

• 2-3 轮技术面 + HR 面
• 每轮：自我介绍（5min）→ 技术问题（15-20min）→ 编程题（30min）
• 编程题难度：LeetCode Medium ~ Hard

一、Agent 核心面试题

Q: Agent 和 LLM 的区别？

参考答案：

• LLM：语言模型，核心能力是文本生成和理解，本质是 next token prediction
• Agent：以 LLM 为大脑的自主系统，额外具备：
• 环境感知和交互能力
• 工具调用能力
• 记忆管理
• 自主规划和决策
• 类比：LLM 是大脑，Agent 是有手有脚有记忆的完整人

Q: 如何设计高效的 Agent 上下文维护方案？

参考答案：

分层管理：

• 系统上下文：角色定义、工具说明（固定）
• 长期记忆：用户画像、历史总结（向量检索按需加载）
• 短期记忆：当前对话历史（滑动窗口 + 摘要压缩）
• 工作记忆：当前任务状态、中间结果（结构化存储）

优化策略：

• 上下文压缩：长对话做摘要
• 按需检索：不把所有信息塞进去
• 优先级排序：重要信息靠近末尾（recency bias）
• 结构化格式：JSON/XML 比自然语言更节省 token

Q: Agent 调用工具不正确怎么办？

参考答案：

多层防护：

• 预防：优化工具描述、few-shot 示例、参数校验
• 检测：工具返回值验证、类型检查、超时检测
• 恢复：重试机制、fallback 工具、人工介入
• 学习：记录错误案例，用于优化 prompt 或微调

Q: Agent 记忆机制如何设计？

参考答案：

三级记忆：

• 感官记忆：原始输入，不持久化
• 短期记忆：对话上下文，滑动窗口管理
• 长期记忆：
• 语义记忆（知识）：向量数据库存储
• 情景记忆（经历）：结构化日志
• 程序记忆（技能）：工具和 workflow 定义

Q: 多 Agent 执行策略的智能选择和切换机制？

参考答案：

• 路由策略：根据任务类型分发到专业 Agent
• 协作模式：
• 顺序执行：pipeline 模式
• 并行执行：独立子任务
• 讨论模式：多个 Agent 辩论达成共识
• 切换机制：
• 基于置信度：Agent 不确定时转交
• 基于能力：任务超出当前 Agent 能力范围时
• 基于结果：输出不满足质量阈值时触发其他 Agent 审核

二、RAG 高频题

Q: RAG 系统流程？

参考答案：

• 索引阶段：文档分块 → Embedding → 存入向量数据库
• 检索阶段：Query Embedding → 向量相似度搜索 → 重排序
• 生成阶段：检索结果 + 原始问题 → LLM 生成回答

Q: 如何解决 "Lost in the Middle" 问题？

参考答案：

• LLM 倾向于关注输入的开头和结尾，中间信息容易被忽略
• 解决方案：
• 将最相关内容放在开头或结尾
• 减少检索结果数量，只保留 top-k
• 对检索结果做摘要后再输入
• 使用 Map-Reduce：分别处理每个文档再汇总

Q: 向量检索 vs 关键词检索？

参考答案：

• 向量检索：语义匹配，处理同义词/近义表达好，但可能丢失精确匹配
• 关键词检索（BM25）：精确匹配强，但无法理解语义
• 最佳实践：混合检索：两者结合 + 重排序（Cross-Encoder）

三、模型微调

Q: LoRA 原理？Q-LoRA 如何优化显存？

参考答案：

• LoRA：冻结原始权重，添加低秩分解矩阵 A×B（r<
• 参数量：原始 d×d → r×d + d×r，大幅减少
• Q-LoRA：在 LoRA 基础上将原始权重量化为 4-bit
• NF4 量化 + 双重量化 + 分页优化器
• 可在单卡 24GB 上微调 65B 模型

Q: LoRA 效果不佳时怎么办？

参考答案：

• 增大 rank（r），增加可训练参数
• 调整学习率和训练轮次
• 检查数据质量和数据量
• 尝试对更多层应用 LoRA
• 考虑全参数微调（如果资源允许）
• 数据增强或改善数据分布

四、计算机基础（仍然会考）

• TCP/IP 协议栈、HTTPS 工作原理
• 协程 vs 线程区别
• MySQL 事务隔离级别、索引覆盖
• Redis 数据结构、持久化
• 消息队列保证消息不丢失
• 微服务架构

五、算法题

• LeetCode 第 2 题（两数相加）等经典题
• 中等偏难为主

阿里巴巴 AI Agent 工程师 - 岗位要求

招聘方向

• AI Coding Agent（自主编程代理系统：代码理解、生成、调试、优化）
• 企业级 AI Agent 平台（淘天集团等）
• 全球零售经营 AI Agent 体系

核心要求

学历

• 本科及以上，计算机/AI/软件工程相关专业，硕士优先

编程能力

• 精通 Python
• 熟悉 Go / Java / C/C++ 至少一门
• 追求高质量代码设计

大模型技术

• 深入理解 Transformer 架构及主流 LLM 技术栈
• Prompt Engineering、上下文工程、RAG 优化、ReAct
• LLM 微调（Fine-tuning）、推理优化
• 多模态大模型知识

AI Agent 核心技术

• 推理（Reasoning）、规划（Planning）、记忆（Memory）、工具调用（Tool Use）
• 多智能体协作架构设计与实现
• 智能体通信协议：MCP、A2A、ANP
• 主流框架：LangChain、AutoGen、MetaGPT、LangGraph
• 有从 0→1 搭建 Agent 应用经验优先

系统架构

• 服务化、异步、高可用、可扩展
• 监控、容灾等服务可靠性
• Ray、数据库、消息队列、ES 等基础技术

加分项

• 顶会论文（ACL/EMNLP/AAAI/NeurIPS/ICML/ICLR/CVPR）
• 知名开源项目核心贡献者
• 智能编程工具、开发者工具、IDE 插件开发经验
• AI 算法大赛获奖

参考链接

• https://careers.aliyun.com

阿里巴巴 AI Agent - 真实面经（牛客实录）

来源：牛客网 2025 年真实面经，持续更新

📌 面经 1：阿里 AI Agent 开发一面（40min）

来源: 牛客网 2025-03-22 | 结果：待定

面试内容：

• 项目拷打
• 重点聊了 AI 项目设计和质量保证
• 被深挖了一段实习经历，问得比较细致
• Java 基础问得挺全：ArrayList/List 区别、扩容为啥是 1.5 倍、HashMap 原理和 key 要求
• Redis 几种基本数据结构
• Redis 如何保证数据不丢失
• Redis 集群有哪些方式
• 什么是分布式系统中的 CAP 定理？如何权衡？
• MySQL 的事务隔离级别有哪些？各自解决什么问题？

面试者感受：攒人品中～（没有手撕代码）

📌 面经 2：阿里 AI Agent 开发二面

来源: 牛客网 2025-03-22 | 同一位面试者

面试内容：

• 项目拷打（继续深挖）
• JVM 内存模型中的堆和栈有什么区别？
• 消息队列如 Kafka 如何保证消息不丢失？
• 设计模式中工厂模式和抽象工厂模式的区别？
• 对比了 Go 和 Java，问了多态的应用场景
• AI 方向继续深入：Agent 和 RAG 区别、如何借助 AI 实现需求

面试者点评：阿里内部人评价——"Agent 是'能做事的系统'，RAG 是'有记忆的知识库'，两者结合才是完整的 AI 应用"

📌 面经 3：钉钉 Agent 应用开发一面（35min，挂）

来源: 牛客网 2025-03-23

面试内容：

• 一上来就问学习中有什么困难，是怎么解决的
• 问第一个项目的流程，为什么要用到这个模式
• Redis、Caffeine、数据库如何保持数据一致性
• 场景题：100 台服务器，热点数据刚好同时过期怎么办？这时候来一大批数据数据库扛不住怎么办？
• 实习过程中的任务、困难
• 反问

特点：无八股，无手撕。纯场景 + 项目

📌 面经 4：阿里大模型算法（社招）

来源: 综合牛客多篇

面试内容：

• 自我介绍
• 项目深度剖析（Agent 项目背景、技术选型）
• 手写算法：实现特殊的损失函数、手写 RoPE
• 学术论文深入讨论
• GRPO/DPO/PPO 等强化学习算法的理解
• 奖励模型的作用
• 性能优化：从延迟、吞吐量和并发量角度
• 框架、算法和算子层面的优化策略
• Vibe Coding：现场利用 AI 辅助工具编程

⚠️ 阿里面试关键洞察

• 一面偏基础：Java 八股 + Redis + MySQL + 分布式（即使是 Agent 岗）
• 二面偏 AI：Agent 设计、RAG、项目深挖
• 项目是核心：每一轮都会花大量时间拷打项目
• Vibe Coding 是新趋势：可能要求现场用 AI 工具编程
• Agent 概念理解是筛选器：有观点认为能否透彻理解 Agent 概念可以筛选掉 80% 的候选人

🔗 原始链接

• https://www.nowcoder.com/feed/main/detail/10ba23cc70984996a6e307a8f85f7ccb
• https://www.nowcoder.com/feed/main/detail/c6588e2d5ce24c3195ed40413fd19753
• https://www.nowcoder.com/discuss/865622724096315392

阿里巴巴 AI Agent 工程师 - 面试题 & 面经

面试特点

• 非常注重项目拷打，会深挖每个项目的细节
• 可能出现 vibe coding（现场编程）环节
• 技术广度 + 深度并重

一、Agent 核心概念

Q: 什么是 AI Agent？与传统 AI/自动化脚本的核心区别？

参考答案：

AI Agent 是具备自主感知环境、决策规划和执行行动能力的智能系统。与传统 AI 的区别：

• 传统 AI：输入→输出的单次映射（如分类器）
• 自动化脚本：预定义流程，无决策能力
• Agent：具备自主循环——感知→思考→行动→观察→再思考，能处理开放域任务

Q: 大模型 Agent 的核心技术模块？

参考答案：

四大模块：

• 规划（大脑）：任务分解、制定计划、反思调整
• 感知（五官）：理解用户输入、多模态信息处理
• 工具（手脚）：API 调用、代码执行、外部系统交互
• 记忆（记忆）：短期记忆（对话上下文）+ 长期记忆（向量存储/数据库）

Q: LLM 在 Agent 中的作用与局限性？

参考答案：

• 作用：作为 Agent 的"大脑"，负责推理、规划和决策
• 局限性：
• 幻觉问题（生成不存在的信息）
• 上下文长度限制
• 实时知识缺失
• 复杂数学/逻辑推理能力不足
• 无法直接与外部系统交互（需工具）

Q: ReAct 框架的工作原理？

参考答案：

ReAct = Reasoning + Acting，交替执行思考和行动：

Thought: 分析当前情况，决定下一步
Action: 调用工具/执行操作
Observation: 观察执行结果
Thought: 基于结果继续推理
...循环直到任务完成

优势：思维链可追溯，行动有依据，比纯 CoT 更实用。

Q: Agent 和 RAG 的区别？如何结合使用？

参考答案：

• RAG：检索增强生成，给 LLM 补充外部知识，是被动的信息增强
• Agent：自主决策系统，RAG 只是 Agent 可调用的工具之一
• 结合：Agent 在需要知识时主动调用 RAG 检索，获取信息后继续推理决策

Q: Agent 调用 MCP 的整体流程？

参考答案：

• 用户发出请求 → Agent 解析意图
• Agent 规划任务，确定需要调用的工具
• 通过 MCP 协议发现可用工具（Tool Discovery）
• 构造工具调用请求（参数填充）
• MCP Server 执行工具并返回结果
• Agent 接收结果，整合到上下文继续推理
• 最终生成回复返回用户

Q: 单 Agent vs 多 Agent 怎么选？

参考答案：

• 单 Agent：任务简单、工具数量少（<10）、对延迟敏感
• 多 Agent：
• 任务涉及多领域专业知识
• 需要并行处理子任务
• 工具数量多需分组管理
• 需要检查/验证机制（如一个 Agent 生成，另一个审核）
• 注意：多 Agent 增加复杂度和延迟，不要过度设计

Q: 如何设计通用 Agent 框架？

参考答案：

分层设计：

• 接口层：统一输入输出协议
• 编排层：任务分解、Agent 调度、流程控制
• 能力层：LLM 推理、工具调用、RAG 检索、记忆管理
• 工具层：标准化工具接口（MCP 协议）、工具注册发现
• 兜底机制：超时处理、错误恢复、人工介入触发

二、大模型基础

Q: Transformer 自注意力机制如何工作？为什么比 RNN 更适合长序列？

参考答案：

• Q/K/V 三个矩阵，通过 Attention(Q,K,V) = softmax(QK^T / √d_k) × V 计算
• 每个 token 可直接关注任意位置的 token，路径长度 O(1)
• RNN 需逐步传递，长距离依赖信息衰减，路径长度 O(n)
• Transformer 支持并行计算，训练效率更高

Q: ROPE（旋转位置编码）vs 绝对位置编码？

参考答案：

• 绝对位置编码：为每个位置分配固定向量，难以泛化到训练时未见的长度
• ROPE：通过旋转矩阵编码相对位置信息
• 优势：天然编码相对位置、可外推到更长序列、计算高效
• 实现：对 Q/K 向量按维度对做旋转变换

Q: MHA、MQA、GQA 的区别？

参考答案：

• MHA（Multi-Head Attention）：每个 head 独立的 Q/K/V
• MQA（Multi-Query Attention）：所有 head 共享 K/V，大幅减少 KV Cache
• GQA（Grouped-Query Attention）：折中方案，多个 head 分组共享 K/V
• 趋势：GQA 成为主流（如 Llama 2/3），平衡效果和效率

三、项目拷打（重点！）

面试官会问的问题维度：

• 项目背景与目标：为什么做？解决什么问题？
• 技术选型：为什么选 X 不选 Y？有什么权衡？
• 具体实现：核心模块怎么设计的？数据怎么流转？
• 挑战与解决：遇到什么难题？怎么解决的？
• 质量保证：如何评估效果？指标是什么？
• 个人贡献：你具体做了什么？和团队的分工？
• 反思改进：如果重新做，会改什么？

准备建议：

• 准备 1-2 个深度项目，每个项目能讲 15-20 分钟
• 对每个技术选型都能说出 "为什么选它" 和 "有什么替代方案"
• 准备好失败经验和从中学到的教训

四、计算机基础（仍然会考！）

• ArrayList vs LinkedList 区别
• HashMap 原理，key 的要求（hashCode + equals）
• Redis 数据结构、持久化、集群
• MySQL 事务隔离级别
• CAP 定理
• LRU Cache 实现
• Kafka 消息不丢失保证
• 设计模式（工厂、抽象工厂、策略等）

五、算法题

• LeetCode 中等/困难为主
• 建议重点刷：动态规划、图、树、字符串处理

腾讯 AI Agent 工程师 - 岗位要求

招聘方向

• AI Agent 基础研发（Agent Infra）：开发框架、数据链路、基础设施
• Coding Agent 开发
• 多智能体系统
• 大模型应用后台开发
• "青云计划"AI 人才专项招聘

核心要求

学历

• 计算机/软件工程相关专业硕士及以上（注意：腾讯门槛普遍偏高）
• 1 年以上工程经验，高级岗 3-8 年+

编程能力

• 精通 Python
• 熟悉 PyTorch 等深度学习框架
• 部分岗位要求 C++（后台开发）、C#/TypeScript（特定场景）
• Linux/Unix 后台开发经验

大模型技术

• 扎实的深度学习算法基础
• 熟悉 LLM、BERT 等 NLP 技术
• RAG 架构设计
• Prompt Engineering 与上下文优化

AI Agent 专项

• 规划（Planning）、记忆（Memory）、反思（Reflection）机制
• Agentic Workflow 与 Agentic Memory 设计
• 多 Agent 系统设计与开发
• 强化学习在 Agent 训练中的应用
• 熟悉 LangChain/LangGraph/AutoGen/MCP 等技术栈

系统架构

• 大规模分布式训练与推理系统
• 模型加速与性能优化
• K8s/Docker 云原生部署
• 高并发 AI 服务搭建

加分项

• Coding Agent 开发经验
• 大模型/智能体产品成功落地经验
• 顶会论文（ACL、EMNLP 等）
• 游戏引擎经验（Unreal/Unity）—— 特定方向
• 代码世界模型（CWM）等新型代码智能技术

参考链接

• https://careers.tencent.com

腾讯 AI Agent 工程师 - 面试题 & 面经（扩充版）

面试流程

• 2-3 轮技术面 + HR 面
• 一面考基础、二面考底层优化、三面考综合设计
• 项目深挖占大量时间
• 编程题难度较高，会出Hard级别
• 会问开放性问题和场景设计题

一、Agent 核心面试题

Q1: 什么是 Agentic AI？与传统 AI 的区别？

难度： ⭐⭐ | 频率： ★★★★★（必考）

参考答案：

• 传统 AI：被动响应，输入→输出，无自主决策
• Agentic AI：具备自主性的 AI 系统
• 自主设定子目标
• 主动规划执行路径
• 使用工具与环境交互
• 从反馈中学习和调整
• 核心区别：自主性（Autonomy） 和 持续交互（Continuous Interaction）
• Agent的核心要素：感知（Perception）→规划（Planning）→行动（Action）→观察（Observation）的循环
• 与RPA的区别：RPA是规则驱动的自动化，Agent是LLM驱动的智能决策

Q2: Agent 的"规划、记忆与反思"机制？

难度： ⭐⭐⭐ | 频率： ★★★★★（必考）

参考答案：

• 规划（Planning）：
• 任务分解（Task Decomposition）
• 子目标生成与排序
• 方法：CoT、ToT、GoT、Plan-and-Execute
• 动态重规划：执行过程中根据反馈调整计划
• 记忆（Memory）：
• 短期：当前对话上下文（In-context）
• 长期：向量数据库持久化（Embedding + Retrieval）
• 工作记忆：当前任务中间状态
• 实体记忆：从对话中提取的实体和关系
• 反思（Reflection）：
• 执行后自我评估结果质量
• 分析失败原因并调整策略
• 框架：Reflexion、Self-Refine
• 关键：需要设计好评估标准和反馈信号

Q3: Agent 记忆管理有哪些难点？

难度： ⭐⭐⭐ | 频率： ★★★★

参考答案：

• 容量限制：上下文窗口有限，需要选择性保留
• 检索准确性：长期记忆检索可能引入噪声
• 一致性维护：记忆更新可能产生矛盾
• 遗忘机制：何时丢弃过时信息
• 隐私安全：敏感信息的存储与访问控制
• 跨会话持续性：如何在多轮会话中保持上下文连贯
• 记忆冲突：不同来源的信息相矛盾时的处理策略（时间优先、可信度加权、主动确认）

Q4: Agentic Workflow 如何设计？

难度： ⭐⭐⭐⭐ | 频率： ★★★★

参考答案：

核心组件：

• 任务解析器：理解用户意图，转化为结构化目标
• 规划器：将目标分解为可执行步骤的 DAG
• 调度器：决定执行顺序（串行/并行/条件分支）
• 执行器：调用工具/LLM 完成每个步骤
• 观察器：监控执行结果，判断是否达标
• 反馈环：失败时触发重规划或人工介入

设计原则：

• 可观测：每步都有日志和状态
• 可恢复：支持断点续执行
• 可配置：workflow 通过配置而非硬编码定义
• 幂等性：重试不产生副作用

Q5: ReAct框架的原理和工作流程？

难度： ⭐⭐⭐ | 频率： ★★★★★（必考）

参考答案：

• ReAct = Reasoning + Acting，交替执行推理和行动
• 工作流程：
• Thought：LLM分析当前状态，推理下一步该做什么
• Action：执行具体操作（调用工具/API）
• Observation：获取操作结果
• 循环直到任务完成或达到最大步数
• 优势：
• 相比纯CoT：可以动态获取外部信息，不限于模型内部知识
• 相比纯Action：有推理过程可追溯，可解释性强
• 格式化输出易于解析和调试
• 局限：推理链过长时可能出错、每步都需要LLM推理增加延迟

Q6: Function Calling/Tool Use 如何实现？如何提高准确率？

难度： ⭐⭐⭐ | 频率： ★★★★

参考答案：

实现方式：

• System Prompt中定义工具的JSON Schema（名称、参数类型、描述）
• LLM根据用户输入判断是否需要调用工具，输出结构化JSON
• 执行引擎解析JSON，调用对应API，将结果回传LLM
• 训练层面：SFT数据中包含大量工具调用样本

提高准确率：

• 优化工具description：清晰、具体、包含使用示例
• 添加few-shot examples：在prompt中给出工具调用示例
• 工具选择验证：生成调用后先校验参数合法性再执行
• 限制可选工具集：根据query先过滤不相关工具
• 失败重试：调用失败后让LLM分析原因并重试
• 微调专项训练：在工具调用数据集上做SFT

Q7: 多Agent协作系统怎么设计？

难度： ⭐⭐⭐⭐ | 频率： ★★★

参考答案：

架构模式：

• 中心化（Orchestrator）：一个主Agent管理调度其他Agent
• 去中心化（Peer-to-Peer）：Agent间直接通信
• 层次化（Hierarchical）：多级Agent，上级分配任务给下级

通信方式：

• 消息传递：Agent间通过消息队列通信
• 共享记忆：所有Agent读写同一记忆空间
• 黑板模式：Agent在共享黑板上发布和读取信息

冲突解决：

• 优先级机制：高优先级Agent的决策优先
• 投票机制：多个Agent投票决定行动
• 仲裁Agent：专门的Agent负责裁决冲突

Q8: Context Engineering 是什么？和 Prompt Engineering 的区别？

难度： ⭐⭐⭐ | 频率： ★★★

参考答案：

• Prompt Engineering：关注单次交互中如何措辞prompt来获得更好输出
• Context Engineering：关注如何在正确时机将正确信息输入模型
• 动态选择相关上下文（不是把所有信息都塞进去）
• 管理对话历史的长度和重要性
• 工具描述的动态选择（只展示相关工具）
• 系统级的信息流管理
• CE是PE的超集，更关注系统层面的信息管理策略

Q9: Agent安全边界怎么设定？

难度： ⭐⭐⭐ | 频率： ★★★

参考答案：

• Action Space限制：只允许执行预定义的操作集合
• 分级权限：读操作自由、写操作需确认、危险操作需人工审批
• 输入防护：Prompt注入检测、内容审核过滤
• 输出审核：敏感信息过滤、合规性检查
• 沙箱执行：代码类操作在隔离环境运行
• 审计日志：所有操作记录可追溯
• 速率限制：防止Agent被滥用
• 熔断机制：异常行为自动停止

二、大模型与深度学习

Q10: 主流开源大模型体系及特点？

难度： ⭐⭐ | 频率： ★★★★

参考答案：

Q11: 向量数据库了解吗？DiskANN 索引细节？

难度： ⭐⭐⭐⭐ | 频率： ★★★

参考答案：

向量数据库：存储和检索高维向量的专用数据库（Milvus、Pinecone、Qdrant、FAISS）

DiskANN（微软）：

• 基于 Vamana 图索引算法
• 核心思想：将索引存储在 SSD 上而非全部内存
• 构建：随机初始化图 → 贪心搜索最近邻 → 修剪边 → 保持度数约束
• 查询：内存中存储压缩向量做粗筛，SSD 读取原始向量做精排
• 优势：10 亿级向量规模，单机 64GB 内存即可

Q12: Transformer中Self-Attention和Cross-Attention的区别？

难度： ⭐⭐ | 频率： ★★★★

参考答案：

• Self-Attention：Q、K、V都来自同一个序列，捕获序列内部的依赖关系
• Cross-Attention：Q来自一个序列（decoder），K和V来自另一个序列（encoder输出）
• Self-Attention用于编码上下文信息
• Cross-Attention用于Encoder-Decoder架构中，让decoder关注encoder的输出
• 在仅Decoder架构（GPT）中，只有Causal Self-Attention（带因果mask）

Q13: LoRA微调原理详解？秩r怎么选？

难度： ⭐⭐⭐ | 频率： ★★★★★（必考）

参考答案：

• 原理：冻结预训练权重W，添加可训练的低秩分解 ΔW = BA
• B ∈ R^(d×r), A ∈ R^(r×k)，r << min(d,k)
• 最终权重 W' = W + (α/r) × BA
• 初始化：B用零初始化，A用Kaiming/正态初始化→初始ΔW=0
• 秩r选择：
• r=4-8：简单任务，快速适配
• r=16-32：中等复杂度任务
• r=64+：复杂任务，接近全量微调效果
• 经验法则：数据量越大、任务越复杂，r可以越大
• QLoRA：在量化模型上做LoRA，4-bit量化+LoRA，极大减少显存
• 应用模块选择：通常在Q/K/V/O投影矩阵上加LoRA效果好

Q14: 混合精度训练（FP16/BF16/FP8）？

难度： ⭐⭐⭐ | 频率： ★★★★

参考答案：

• FP32：32位浮点，精度最高，显存占用大
• FP16：16位浮点，范围小（±65504），容易溢出，需要Loss Scaling
• BF16：16位脑浮点，范围与FP32相同但精度较低，不需要Loss Scaling
• FP8：8位浮点，更激进的压缩，目前主要用于推理
• 混合精度训练：
• 前向/反向计算用BF16/FP16
• Master Weights保持FP32精度
• 梯度累积用FP32
• 好处：显存减半、计算加速（Tensor Core）、精度损失可控

Q15: KV Cache压缩有哪些方法？

难度： ⭐⭐⭐⭐ | 频率： ★★★★

参考答案：

• 架构层面：GQA/MQA减少KV头数
• 量化压缩：将KV Cache量化到INT8/INT4
• 驱逐策略：
• H2O：保留attention score高的token的KV
• StreamingLLM：保留初始几个token（attention sink）+ 滑动窗口
• 低秩压缩：MLA（DeepSeek V2的Multi-head Latent Attention）
• 跨层共享：相邻层共享KV Cache
• 窗口化：只保留最近N个token
• Trade-off：压缩越激进 → 显存越省 → 但长距离依赖的精度可能下降

Q16: FlashAttention的原理？

难度： ⭐⭐⭐⭐ | 频率： ★★★★

参考答案：

• 核心问题：标准Attention需要O(N²)的HBM读写，是IO瓶颈
• 核心思想：利用GPU的SRAM（共享内存）做分块计算（Tiling）
• 将Q/K/V分成小块（block），每次只加载一个block到SRAM
• 在SRAM中完成attention计算，然后写回HBM
• 避免将完整的N×N attention矩阵写入HBM
• 在线Softmax：分块计算时需要在线更新softmax的分母
• IO复杂度：从O(N²)降低到O(N²/M)，M是SRAM大小
• FlashAttention-2：优化了并行策略，减少非矩阵运算
• FlashAttention-3：进一步优化H100的利用率

Q17: PagedAttention的设计思路？

难度： ⭐⭐⭐⭐ | 频率： ★★★★

参考答案：

• 灵感：类似操作系统的虚拟内存分页
• 问题：传统KV Cache预分配连续内存导致严重浪费（碎片化）
• 方案：
• 将KV Cache按固定大小的block管理（如16个token一个block）
• block可以不连续存储，用page table做映射
• 动态分配/释放block，按需增长
• 优势：
• 显存利用率从50%→98%（近乎零浪费）
• 支持更多并发请求
• 支持prefix sharing（多个请求共享相同前缀的KV Cache）
• vLLM中的实现：Scheduler + BlockManager协同管理

Q18: 分布式训练策略（DP/TP/PP/ZeRO）？

难度： ⭐⭐⭐⭐ | 频率： ★★★★

参考答案：

• 数据并行（DP）：每卡完整模型副本，数据分片→AllReduce同步梯度
• 张量并行（TP）：将权重矩阵按行/列切分到多卡，层内通信
• 流水线并行（PP）：模型按层切分，micro-batch流水化执行
• ZeRO（DeepSpeed）：
• Stage 1：优化器状态分片
• Stage 2：优化器状态+梯度分片
• Stage 3：优化器+梯度+参数全分片
• 3D并行：TP + PP + DP组合使用
• 经验：TP在节点内（高带宽NVLink），PP跨节点，DP做外层
• 通信优化：计算和通信overlap、梯度压缩、异步通信

Q19: 灾难性遗忘的解决方案？

难度： ⭐⭐⭐ | 频率： ★★★★

参考答案：

• EWC（弹性权重巩固）：计算Fisher Information Matrix，对重要参数施加正则约束
• LwF（Learning without Forgetting）：用旧模型输出做知识蒸馏
• 重放机制（Replay）：保留旧任务数据混入新训练
• 参数高效方法：LoRA/Adapter只更新少量参数，基座不动
• 渐进式训练：先领域CPT，再混合数据SFT
• 多任务学习：同时训练多个任务维持通用能力
• 实际中最常用：数据混合（Replay）+ LoRA 的组合方案

Q20: GraphRAG和传统RAG的区别？

难度： ⭐⭐⭐ | 频率： ★★★

参考答案：

• 传统RAG：基于chunk的平面检索，适合简单事实问答
• 流程：Query → Embedding → 向量检索 → Top-K chunks → LLM生成
• GraphRAG：用知识图谱/社区图索引文档关系
• 索引构建：LLM提取实体和关系 → 构建知识图谱 → 社区检测（Leiden算法）
• Global Search：基于社区摘要回答宏观问题
• Local Search：基于实体和关系回答细节问题
• GraphRAG优势：跨文档推理、全局理解、关系查询
• GraphRAG劣势：索引构建成本高（需要LLM提取）、图构建质量依赖LLM
• 适用场景：传统RAG适合事实检索；GraphRAG适合需要综合分析的问题

三、系统与工程化

Q21: 如何搭建高并发 AI 服务？

难度： ⭐⭐⭐ | 频率： ★★★★

参考答案：

• 模型服务：vLLM / TGI / Triton Inference Server
• 负载均衡：Nginx / K8s Ingress，按 GPU 利用率路由
• 异步处理：请求队列 + 消息中间件（Kafka/RabbitMQ）
• 缓存：语义缓存（相似 query 命中缓存）+ KV Cache 复用
• 弹性伸缩：K8s HPA 根据 QPS/GPU 利用率自动扩缩容
• 流式输出：SSE/WebSocket 降低首 token 延迟感知

Q22: 大模型上线后怎么监控和评估？

难度： ⭐⭐⭐ | 频率： ★★★

参考答案：

• 性能监控：QPS、延迟（p50/p95/p99）、GPU利用率、显存占用
• 质量监控：用户满意度（thumbs up/down）、二次提问率、人工抽检
• 安全监控：有害输出率、幻觉率、敏感内容检出率
• 成本监控：token消耗、GPU计算时长、API调用量
• 告警机制：延迟spike、错误率突增、GPU OOM
• 工具栈：Prometheus + Grafana + ELK

Q23: 投机解码（Speculative Decoding）原理？

难度： ⭐⭐⭐⭐ | 频率： ★★★

参考答案：

• 核心思想：用小模型（draft model）快速生成γ个候选token，用大模型（target model）一次性并行验证
• 为什么能加速：验证γ个token只需1次大模型前向传播（并行），而逐个生成需γ次
• 接受策略：基于概率比较，保证输出分布与纯大模型一致
• 加速比：取决于接受率α，理论加速 1/(1-α)×γ
• 适用条件：有好的draft model（与target模型分布接近）、延迟敏感场景

四、编程与基础

Q24: Python GIL 是什么？如何绑定多核？

难度： ⭐⭐ | 频率： ★★★

参考答案：

• GIL（Global Interpreter Lock）：CPython的全局锁，同一时刻只有一个线程执行Python字节码
• 影响：CPU密集型任务无法利用多核
• 绕过方案：
• multiprocessing模块（多进程）
• C扩展（释放GIL）
• asyncio（IO密集型场景）
• 使用Cython/Numba编译
• Python 3.12+：Sub-interpreters可以部分绕过GIL

Q25: is vs == 的区别？

难度： ⭐ | 频率： ★★★

参考答案：

• is 比较对象身份（identity），即是否是同一个内存对象（id()相同）
• == 比较对象值（value），调用 __eq__ 方法
• a is b 等价于 id(a) == id(b)
• 注意：小整数池（-5~256）和字符串intern导致的特殊行为

Q26: 手写Multi-Head Attention前向计算

难度： ⭐⭐⭐⭐ | 频率： ★★★

参考答案：

import torch
import torch.nn as nn
import math

class MultiHeadAttention(nn.Module):
    def __init__(self, d_model, num_heads):
        super().__init__()
        self.d_model = d_model
        self.num_heads = num_heads
        self.d_k = d_model // num_heads
        self.W_q = nn.Linear(d_model, d_model)
        self.W_k = nn.Linear(d_model, d_model)
        self.W_v = nn.Linear(d_model, d_model)
        self.W_o = nn.Linear(d_model, d_model)
    
    def forward(self, x, mask=None):
        B, L, _ = x.shape
        Q = self.W_q(x).view(B, L, self.num_heads, self.d_k).transpose(1, 2)
        K = self.W_k(x).view(B, L, self.num_heads, self.d_k).transpose(1, 2)
        V = self.W_v(x).view(B, L, self.num_heads, self.d_k).transpose(1, 2)
        
        scores = torch.matmul(Q, K.transpose(-2, -1)) / math.sqrt(self.d_k)
        if mask is not None:
            scores = scores.masked_fill(mask == 0, float('-inf'))
        attn = torch.softmax(scores, dim=-1)
        
        out = torch.matmul(attn, V)
        out = out.transpose(1, 2).contiguous().view(B, L, self.d_model)
        return self.W_o(out)

五、RAG 专题

Q27: RAG系统的完整架构和评估方法？

难度： ⭐⭐⭐ | 频率： ★★★★★（必考）

参考答案：

架构：

• 文档处理：PDF/HTML解析 → 清洗 → 语义分块
• 索引构建：Embedding → 向量数据库 + 倒排索引
• 查询处理：Query改写 → 多路检索（BM25 + Dense）
• 重排序：Cross-Encoder Reranker
• 生成：Prompt构建 → LLM生成 → 后处理

评估：

• 检索：Hit Rate@K, MRR, NDCG, Recall@K
• 生成：Faithfulness, Answer Relevance, Completeness
• 端到端：RAGAS框架（Context Precision/Recall, Faithfulness, Answer Relevance）
• 用户维度：满意度评分、二次提问率

Q28: RAG检索召回方式有哪些？

难度： ⭐⭐⭐ | 频率： ★★★★

参考答案：

• 稀疏检索：BM25、TF-IDF，基于词频统计
• 稠密检索：Embedding向量相似度（cosine/L2），用预训练模型编码
• 混合检索：BM25 + Dense，加权融合或RRF（Reciprocal Rank Fusion）
• 知识图谱检索：基于实体和关系的图查询
• 多路召回：不同策略并行召回，最后统一重排
• 递归检索：先粗后细，先找到相关文档再在文档内检索

六、场景设计题

Q29: 设计金融领域智能助手的RAG流水线

难度： ⭐⭐⭐⭐ | 频率： ★★★

参考答案：（见面经详细版）

Q30: 设计微信群里的AI助手

难度： ⭐⭐⭐ | 频率： ★★★

参考答案：

• @提问模式、群摘要、信息提取、安全边界控制
• 技术要点：流式消息处理、意图检测、上下文管理、隐私保护

七、开放性问题

Q31: 对 AI Agent 未来发展的看法？

难度： ⭐⭐ | 频率： ★★★★

参考答案：

• 短期（1-2年）：Human-in-the-loop的Agent成为主流，在特定领域（客服、运维、编码）达到实用水平
• 中期（3-5年）：多Agent协作系统成熟，Agent能处理跨领域复杂任务
• 长期：通用智能Agent（AGI Agent），但需要解决安全、对齐、可控性等根本问题
• 关键挑战：可靠性、安全性、评估标准、成本控制

Q32: 对腾讯 AI 产品（混元、元宝）的了解？

难度： ⭐⭐ | 频率： ★★★★

参考答案：

• 混元大模型：腾讯自研，中文能力强，有MoE版本提升效率
• 腾讯元宝：面向C端的AI助手产品，支持联网搜索、文件处理
• 结合微信生态有独特数据优势
• 客观评价优劣势，展示你有独立思考能力

Q33: 大模型在业务中的痛点和优化方案？

难度： ⭐⭐⭐ | 频率： ★★★

参考答案：

• 成本：模型路由（简单query用小模型）、语义缓存、量化
• 幻觉：RAG + 事实核查 + CoT + confidence calibration
• 延迟：投机解码、流式输出、预计算
• 对齐：持续RLHF/DPO、红队测试、人工审核

八、算法题高频清单

百度 AI Agent 工程师 - 岗位要求

招聘方向

• AIDU 计划：大规模 AI 人才招募
• 大模型算法、大模型基础架构、机器学习、语音技术、智能体
• 搜索引擎 Agent 化（类 Perplexity 方向）

核心要求

学历

• 本科及以上，AI 相关岗位占校招 80%

技术栈

• 深入理解 Transformer 架构
• 大模型预训练、后训练（Instruction Tuning、RLHF/DPO/PPO）
• RAG 系统设计与优化
• AI Agent 设计模式（ReAct、工具调用、规划执行等）
• 多 Agent 系统通信与编排

工程能力

• Python 精通 + 其他语言
• K8s/Docker 云原生部署
• 分布式训练（DP/MP/PP/ZeRO）
• API 集成（REST/gRPC/GraphQL）

薪资

• 顶尖人才薪资上不封顶

参考链接

• https://cloud.baidu.com/article/5315952

百度 AI Agent 工程师 - 面试题 & 面经（扩充版）

面试特点

• 大模型基础理论考察非常深入，追问到数学公式级别
• 会问对文心一言产品的理解
• 算法题占比高，可能要求手写 Tokenizer/Attention
• 面试通常3轮，每轮约1.5小时
• Agent设计题是高频考点

一、大模型基础（必考重点）

Q1: Transformer 核心组件详解？

难度： ⭐⭐⭐ | 频率： ★★★★★（必考）

参考答案：

• Self-Attention：计算序列内每对 token 的关联度
• 公式：Attention(Q,K,V) = softmax(QK^T / √d_k) V
• Q = XW_Q, K = XW_K, V = XW_V
• 除以√d_k的原因：防止点积过大导致softmax梯度消失（方差归一化）
• Multi-Head Attention：多个注意力头捕获不同维度的关系
• 每个头有独立的Q/K/V投影矩阵
• 最后concat所有头的输出，过一个线性层
• 头数h通常8-128，每头维度d_k = d_model/h
• 位置编码：弥补 Transformer 无序列感知的缺陷
• 正弦/余弦编码（原始Transformer）、可学习编码
• RoPE（旋转位置编码）：当前主流
• ALiBi：在attention score上加线性偏置
• FFN：两层全连接 + 激活函数，提供非线性变换
• 原始：FFN(x) = W2·GELU(W1·x)
• SwiGLU（LLaMA/Qwen用）：FFN(x) = W2·(SiLU(W1·x) ⊙ W3·x)
• 中间维度通常是d_model的4倍（或8/3倍用SwiGLU时）
• Layer Norm + Residual Connection：稳定训练
• Pre-Norm（现代主流）：x + Sublayer(Norm(x))
• Post-Norm（原始Transformer）：Norm(x + Sublayer(x))
• RMSNorm：只做缩放不做中心化，计算更快

Q2: Encoder-Only / Decoder-Only / Encoder-Decoder 各适合什么任务？

难度： ⭐⭐ | 频率： ★★★★★（必考）

参考答案：

• Encoder-Only（BERT）：理解任务（分类、NER、QA）
• 双向attention，看到全部上下文
• 训练目标：MLM（掩码语言模型）+ NSP
• Decoder-Only（GPT）：生成任务（文本生成、对话）—— 当前主流
• 因果attention（只看左边）
• 训练目标：next token prediction
• 通过统一的生成范式也能做理解任务
• 主流原因：scaling效率好、zero-shot能力强、架构简单
• Encoder-Decoder（T5、BART）：序列到序列（翻译、摘要）
• Encoder双向编码输入，Decoder自回归生成输出
• Cross-attention连接两部分

Q3: RLHF 的完整流程？DPO vs PPO？

难度： ⭐⭐⭐⭐ | 频率： ★★★★★（必考）

参考答案：

RLHF 三阶段：

• SFT：在高质量指令数据上微调基座模型
• Reward Model 训练：
• 人类标注偏好对 (x, yw, yl)
• 训练目标：RM(x, yw) > RM(x, yl)
• 损失函数：L = -E[log σ(RM(x, yw) - RM(x, yl))]
• PPO 优化：
• 用 RM 的分数作为奖励信号
• PPO算法更新策略模型
• 加KL散度惩罚防止偏离参考策略太远
• 目标：max E[RM(x, y)] - β × KL(π || π_ref)

DPO vs PPO：

• PPO：需要额外的 RM + Critic Model，训练复杂但效果天花板更高
• 4个模型同时在GPU：策略模型、参考模型、RM、Critic
• 训练不稳定，超参敏感
• DPO：直接从偏好对学习，无需 RM，更简单高效
• 只需要策略模型和参考模型
• 通过重参数化将 RM 目标直接转化为策略优化目标
• Loss: -E[log σ(β × (log π(yw|x)/πref(yw|x) - log π(yl|x)/πref(yl|x)))]
• GRPO（DeepSeek）：
• 不需要Critic Model
• 从同一prompt采样一组回答，用组内相对奖励做优势估计
• 工程上更简单，效果接近PPO

Q4: 大模型幻觉问题？如何缓解？

难度： ⭐⭐⭐ | 频率： ★★★★★（必考）

参考答案：

原因：

• 训练数据有噪声/偏差/过时信息
• 模型过度自信的生成（概率高的token不一定正确）
• 缺乏实时/专业知识
• 解码策略引入的随机性

工程缓解方法：

• RAG 引入外部知识做事实基座
• 提示工程（要求引用来源、思维链推理）
• 自我一致性检查（多次采样投票取多数一致）
• 输出后校验（事实核查 Agent 对关键信息做验证）
• 微调高质量数据（减少训练数据中的虚假信息）
• 温度调低 减少随机性
• Confidence Calibration：让模型输出置信度，低置信度时声明不确定

Q5: 模型复读问题的原因和解决方法？

难度： ⭐⭐ | 频率： ★★★★

参考答案：

原因：

• 注意力集中在近期token，形成正反馈循环
• 训练数据中存在重复模式
• 解码策略问题（greedy decoding更容易复读）

解决：

• 采样层面：Repetition Penalty（对已出现token降低概率）、Frequency/Presence Penalty
• 训练层面：数据去重、避免相似样本过多、RLHF对齐
• 后处理：检测连续重复文本并截断
• 采样策略：提高temperature、使用Top-P/Top-K增加多样性

Q6: 混合专家模型（MoE）如何扩大参数但不增推理成本？

难度： ⭐⭐⭐ | 频率： ★★★★

参考答案：

• 多个 Expert FFN 模块 + Router 网络
• 每次推理只激活 top-k 个 Expert（如 Mixtral激活2/8，DeepSeek V3激活8/256）
• 总参数量大但激活参数少→单次推理FLOPs接近小模型
• Router机制：线性层输出expert概率分布，选top-k
• 挑战：
• 负载均衡：辅助loss惩罚不均匀分配
• Expert坍缩：部分expert从不被选中→用噪声和dropout缓解
• 通信开销：MoE层需要All-to-All通信
• 显存：虽然激活少但所有expert参数都要加载

Q7: RoPE旋转位置编码的原理？

难度： ⭐⭐⭐⭐ | 频率： ★★★★

参考答案：

• 核心思想：在复数空间中，通过旋转Q和K向量来编码位置信息
• 具体做法：
• 将d维向量两两配对，得到d/2个二维向量
• 对每个二维向量按位置角度 θ_m = m × θ_i 做旋转
• θ_i = 10000^(-2i/d)，不同维度有不同的旋转频率
• 关键性质：
• q_m^T · k_n 只依赖相对位置 m-n
• 天然编码相对位置关系
• 理论上支持任意长度外推
• 优点：实现高效（逐元素乘法）、效果好、与注意力机制天然兼容
• 长度外推：YaRN、NTK-aware Scaling在RoPE基础上扩展长度支持

Q8: 位置编码有哪些？各自优缺点？

难度： ⭐⭐⭐ | 频率： ★★★★

参考答案：

二、Agent 设计

Q9: 让你设计一个 Agent，会怎么做？

难度： ⭐⭐⭐⭐ | 频率： ★★★★★（必考）

参考答案：

• 定义问题：明确 Agent 的目标、边界、用户群体
• 选择 LLM：根据任务复杂度选模型（大模型做复杂推理，小模型做路由/简单任务）
• 设计工具集：确定 Agent 需要的外部能力，编写清晰的tool description
• 记忆方案：短期（对话历史滑动窗口）+ 长期（向量 DB 持久化）+ 工作记忆（任务状态）
• 编排策略：ReAct（简单任务）/ Plan-and-Execute（复杂任务）/ Multi-Agent（协作任务）
• 评估体系：任务完成率、工具调用准确率、延迟、成本、用户满意度
• 兜底与安全：超时处理、错误恢复机制、内容安全过滤、权限控制

Q10: 如何让 Agent 支持多语言交互？

难度： ⭐⭐ | 频率： ★★★

参考答案：

• 选择多语言 LLM（如 GPT-4、Qwen、混元）
• 工具描述和 System Prompt 用英文（模型理解最好）
• 用户输入/输出保持原始语言
• 特定语言的 RAG 知识库
• 语言检测 → 路由到对应处理链路
• 翻译模块做兜底（检测到不支持的语言时）

Q11: 如果从0到1设计企业级Agent平台，模块怎么划分？

难度： ⭐⭐⭐⭐⭐ | 频率： ★★★★

参考答案：

• Planner模块：任务分解、路径规划，支持多种策略（ReAct/Plan-and-Execute/DAG）
• Memory模块：
• 短期对话记忆（滑动窗口/摘要压缩）
• 长期知识记忆（向量DB持久化）
• 工作记忆（当前任务中间状态和变量）
• 记忆冲突检测和解决
• Tool模块：工具注册中心、Schema管理、权限控制、调用日志
• Knowledge模块：知识库管理、RAG引擎、知识更新机制
• Runtime模块：Agent执行引擎、并发管理、资源调度、沙箱隔离
• Evaluation模块：评测数据集管理、自动评测流水线、AB测试框架

Q12: 多轮对话中记忆冲突怎么处理？

难度： ⭐⭐⭐ | 频率： ★★★

参考答案：

• 时间优先：最新信息覆盖旧信息
• 来源可信度：不同来源赋予不同权重（用户明确说的 > 推理得到的 > 工具返回的）
• 置信度评估：对每条记忆附带置信度分数
• 版本管理：记忆带时间戳和来源标签，支持回溯
• 主动确认：检测到矛盾时向用户确认
• 实现：ConflictDetector检测矛盾 + ConflictResolver按策略解决

Q13: Agent评估体系怎么设计？Planning能力怎么量化？

难度： ⭐⭐⭐⭐ | 频率： ★★★★

参考答案：

整体评估框架：

• 功能性：任务完成率、工具调用准确率、多轮对话连贯性
• 安全性：Prompt注入防御、幻觉率、敏感内容过滤
• 性能：响应延迟、吞吐量、token消耗
• 用户体验：满意度评分、二次提问率

Planning能力量化：

• 任务完成率（是否最终完成目标）
• 步骤效率 = 最优路径步数 / 实际步数
• 工具选择准确率 = 正确选择次数 / 总选择次数
• 规划合理性：人工评估方案逻辑性（1-5分制）
• Benchmark：WebArena、AgentBench、SWE-bench

Q14: Agent的响应延迟怎么优化？

难度： ⭐⭐⭐ | 频率： ★★★★

参考答案：

• 模型轻量化：简单任务用小模型，复杂任务才用大模型（模型路由）
• 异步处理：工具调用异步化，可并行的工具同时调用
• 缓存机制：
• 语义缓存（相似query直接返回缓存结果）
• System Prompt的KV Cache预热
• 工具结果缓存
• 流式输出：生成过程实时返回
• 投机解码：用小模型做draft，大模型验证
• 量化推理：INT4/INT8量化减少计算量

三、训练与优化

Q15: 分布式训练策略？

难度： ⭐⭐⭐⭐ | 频率： ★★★★

参考答案：

• 数据并行（DP）：每个 GPU 完整模型副本，数据分片，AllReduce同步梯度
• 模型并行（MP/TP）：模型按张量切分到不同 GPU，层内通信（AllReduce/AllGather）
• 流水线并行（PP）：模型按阶段（层）切分，micro-batch 流水化执行
• ZeRO：
• Stage 1：优化器状态分片→显存减少4x
• Stage 2：+ 梯度分片→显存减少8x
• Stage 3：+ 参数分片→显存减少N x
• 实践：通常混合使用（3D 并行：TP节点内 + PP跨节点 + DP外层）
• 通信优化：计算和通信overlap、梯度压缩、异步pipeline

Q16: SFT核心流程和数据集构建？

难度： ⭐⭐⭐ | 频率： ★★★★

参考答案：

流程：

• 选择基座模型（Qwen/LLaMA/DeepSeek等）
• 准备数据：格式化为instruction-input-output（Alpaca格式或ShareGPT多轮格式）
• 设置超参：学习率（1e-5~5e-5）、epoch（2-5）、batch size
• 训练：支持全量微调或LoRA
• 评估：holdout测试集 + benchmark + 人工评测

数据构建：

• 来源：人工标注 + 合成数据（GPT-4生成）+ 开源数据集
• 质量控制：人工抽检、GPT-4打分过滤、数据去重
• 多样性：覆盖不同任务类型（QA/摘要/翻译/推理/编码等）
• 数据量：SFT数据质量>数量，LIMA论文证明1000条高质量数据即可
• 难度分布：easy:medium:hard ≈ 3:5:2

Q17: 微调出现灾难性遗忘怎么办？

难度： ⭐⭐⭐ | 频率： ★★★★

参考答案：

• 数据混合（Replay）：微调数据中混入通用数据（如5-20%比例的通用QA）
• 参数高效方法：LoRA/Adapter只更新少量参数，基座权重不动
• 正则化：
• EWC（弹性权重巩固）：对重要参数施加约束
• L2正则化：限制参数偏离初始值
• 渐进式训练：先CPT学领域知识，再混合SFT
• 学习率控制：降低学习率、减少epoch
• 多任务学习：同时训练多个任务维持通用能力

Q18: 模型推理优化技术全景？

难度： ⭐⭐⭐⭐ | 频率： ★★★★

参考答案：

四、RAG 专题

Q19: RAG核心原理和完整流程？

难度： ⭐⭐⭐ | 频率： ★★★★★（必考）

参考答案：

核心原理： Retrieval-Augmented Generation，在生成前先检索相关知识，让LLM基于检索结果生成更准确的答案。

完整流程：

• 离线索引阶段：
• 文档解析（PDF/HTML/Word）→ 文本提取
• 文本分块（固定长度/语义分块/递归分块）
• Embedding向量化（text-embedding-3-small等）
• 存入向量数据库（Milvus/Qdrant/FAISS）+ 倒排索引
• 在线查询阶段：
• 用户Query → Query改写/扩展
• 多路检索（BM25 + Dense + 知识图谱）
• 重排序（Cross-Encoder Reranker）
• Prompt构建（System Prompt + 检索结果 + Query）
• LLM生成 → 后处理（安全审核、格式化）

Q20: RAG和Fine-tuning怎么选？

难度： ⭐⭐⭐ | 频率： ★★★★

参考答案：

实际中常组合：微调提升基础能力+RAG补充实时知识

五、大模型前沿

Q21: 大模型涌现能力怎么理解？

难度： ⭐⭐⭐ | 频率： ★★★

参考答案：

• 定义：随模型参数量增加，某些能力突然出现（非线性跃迁）
• 典型涌现能力：few-shot learning、chain-of-thought reasoning、代码生成
• 争议：BIG-bench论文指出涌现可能是度量方式导致的假象（用连续指标衡量时涌现消失）
• 可能的解释：模型内部表征空间在某个规模后达到临界复杂度

Q22: 长上下文处理策略？

难度： ⭐⭐⭐ | 频率： ★★★★

参考答案：

• 位置编码扩展：YaRN、NTK-aware Scaling
• 稀疏注意力：Longformer的滑动窗口+全局attention、BigBird
• 分块处理：Ring Attention、Sequence Parallelism
• 层次化处理：先做段落级摘要，再做全局整合
• RAG方式：检索相关片段而非全文输入
• KV Cache优化：H2O、StreamingLLM保留重要token

Q23: Scaling Laws讲一下

难度： ⭐⭐⭐ | 频率： ★★★

参考答案：

• Kaplan et al. (OpenAI)：Loss ∝ N^(-0.076) × D^(-0.095) × C^(-0.050)
• Chinchilla Law (DeepMind)：最优配比下N和D应等比例扩大
• 给定计算预算C，最优模型大小N和数据量D满足 N ∝ C^0.5, D ∝ C^0.5
• 实际意义：10B模型需要约200B token训练，70B模型需要约1.4T token
• 但最新趋势是over-training（如LLaMA3用超过最优量的数据训练较小模型）

Q24: 大模型的工具调用是怎么实现的？

难度： ⭐⭐⭐ | 频率： ★★★★

参考答案：

• Prompt层面：在System Prompt中用JSON Schema定义工具
• SFT训练：在微调数据中加入工具调用示例，让模型学会输出结构化调用
• 解析执行：正则/JSON解析模型输出 → 调用API → 结果回传
• 迭代改进：
• 并行调用：多个独立工具同时调用
• 嵌套调用：工具结果作为另一个工具的输入
• 错误处理：调用失败时分析原因并重试

六、编程与算法

Q25: 手写BPE Tokenizer核心逻辑

难度： ⭐⭐⭐⭐ | 频率： ★★★★（百度特色题）

参考答案：

def bpe_train(text, num_merges):
    # 初始化：字符级别的token
    tokens = list(text)
    vocab = set(tokens)
    
    for _ in range(num_merges):
        # 统计相邻pair的频率
        pairs = {}
        for i in range(len(tokens) - 1):
            pair = (tokens[i], tokens[i+1])
            pairs[pair] = pairs.get(pair, 0) + 1
        
        if not pairs:
            break
        
        # 找最高频的pair
        best_pair = max(pairs, key=pairs.get)
        new_token = best_pair[0] + best_pair[1]
        vocab.add(new_token)
        
        # 合并
        new_tokens = []
        i = 0
        while i < len(tokens):
            if i < len(tokens) - 1 and (tokens[i], tokens[i+1]) == best_pair:
                new_tokens.append(new_token)
                i += 2
            else:
                new_tokens.append(tokens[i])
                i += 1
        tokens = new_tokens
    
    return vocab, tokens

BPE vs WordPiece：BPE按频率合并，WordPiece按最大似然合并

Q26: 手写Scaled Dot-Product Attention

难度： ⭐⭐⭐ | 频率： ★★★★（百度特色题）

参考答案：

import torch
import math

def scaled_dot_product_attention(Q, K, V, mask=None):
    """
    Q, K, V: (batch, heads, seq_len, d_k)
    """
    d_k = Q.size(-1)
    scores = torch.matmul(Q, K.transpose(-2, -1)) / math.sqrt(d_k)
    
    if mask is not None:
        scores = scores.masked_fill(mask == 0, float('-inf'))
    
    attn_weights = torch.softmax(scores, dim=-1)
    output = torch.matmul(attn_weights, V)
    
    return output, attn_weights

Q27: Python装饰器原理？写一个计时装饰器

难度： ⭐⭐ | 频率： ★★★

参考答案：

import time
import functools

def timer(func):
    @functools.wraps(func)
    def wrapper(*args, **kwargs):
        start = time.time()
        result = func(*args, **kwargs)
        elapsed = time.time() - start
        print(f"{func.__name__} took {elapsed:.4f}s")
        return result
    return wrapper

@timer
def my_function():
    time.sleep(1)

装饰器本质：接受函数作为参数，返回新函数的高阶函数。@语法糖等价于 my_function = timer(my_function)

七、百度产品认知

Q28: 对文心一言的了解？优点和改进建议？

难度： ⭐⭐ | 频率： ★★★★★（百度必考）

参考答案：

优点：

• 中文理解和生成能力强（百度有大量中文数据）
• 支持多模态（图片理解/生成、视频理解）
• 与百度搜索生态深度结合，联网搜索能力强
• 在CMMLU等中文benchmark上表现优秀

改进建议：（客观评价，不要过分贬低）

• 复杂推理能力相比GPT-4有差距
• 有时过于安全导致拒绝正常请求（over-safety）
• 创意生成和开放域对话的趣味性可提升
• API稳定性和开发者生态可进一步完善

Q29: 百度智能云千帆平台了解多少？

难度： ⭐⭐ | 频率： ★★★

参考答案：

• 百度的大模型一站式开发平台
• 提供模型推理API（文心系列+第三方模型）
• 模型微调（SFT/LoRA）
• 知识库管理和RAG引擎
• Agent开发工具链
• 评测平台
• 对标：阿里百炼、腾讯HAI

Q30: 当前大模型还存在什么问题？

难度： ⭐⭐⭐ | 频率： ★★★★

参考答案：

• 幻觉问题：仍然无法完全消除虚假信息生成
• 推理能力：复杂逻辑和数学推理仍有挑战
• 成本问题：大规模部署的计算成本高昂
• 实时性：训练数据有截止日期，无法获取最新信息（需RAG补充）
• 安全风险：越狱攻击、偏见问题、隐私泄露
• 评估标准：缺乏统一可靠的评估体系
• 多模态：视觉理解和生成能力仍有提升空间
• 长上下文：理论支持长文本，但"lost-in-the-middle"问题仍存在

八、算法题高频清单

美团 AI Agent - 面试题 & 面经

面试特点

• 笔试包含大模型训练题 + 后端常规题
• 可能有 AI 面试官引导追问
• 重视 AI 在实际业务场景的应用

真实面试题

AI 相关

• 自我介绍中阐述 AI 大模型工具在学习和实践中的作用

参考答案：

• 学习层面：利用 ChatGPT/Claude 辅助理解复杂论文、快速掌握新框架（如 LangChain），将学习效率提升数倍
• 编码层面：使用 Copilot 做代码补全、用 AI 做 Code Review 和 Bug 定位，缩短开发周期
• 实践层面：基于开源模型（如 Llama、Qwen）做过微调实验，理解 SFT/RLHF 流程
• 工程落地：搭建过 RAG 系统或 Agent 工作流，了解 Prompt Engineering、Function Calling 等核心技术
• 强调"工具思维"：AI 是提效手段，核心竞争力仍是工程能力和业务理解

• 后端如何统计 token 用量、工具调用次数、重试次数？按业务场景和模型版本做聚合报表

参考答案：

• 在网关/中间件层拦截每次 LLM 调用，提取 response 中的 usage 字段（prompt_tokens、completion_tokens）
• 设计埋点结构：request_id、业务线、模型版本、token 数、工具调用列表、重试次数、耗时、状态码
• 实时统计用 Kafka + Flink 流处理，写入 ClickHouse 或 Doris 做 OLAP 聚合
• 离线报表按维度（业务场景×模型版本×日期）做预聚合，用物化视图加速查询
• 重试次数通过装饰器/AOP 在调用层统计，随请求上下文透传
• 告警：设置 token 用量阈值和异常重试率的监控告警

• 如何设计存储统计信息的数据库表（扩展性和性能）

参考答案：

• 核心表：llm_call_log（id, biz_type, model_version, prompt_tokens, completion_tokens, tool_calls_json, retry_count, latency_ms, status, created_at）
• 按时间分区（日/周），配合 TTL 策略自动清理历史数据
• 高频查询字段（biz_type, model_version, created_at）建联合索引
• 扩展性：tool_calls 用 JSON 字段存储，避免频繁 DDL；或用 EAV 模式做动态属性
• 读写分离：写入走主库，报表查询走从库或 OLAP 引擎（ClickHouse）
• 预聚合表：daily_stats（biz_type, model_version, date, total_tokens, total_calls, avg_latency），定时任务汇总

• 设计一个文本生成 HTTP 接口供业务方调用，支持流式返回

参考答案：

• 接口设计：POST /api/v1/completions，请求体含 model、messages、stream（bool）、max_tokens 等参数
• 非流式：同步返回 JSON，适合短文本场景
• 流式：使用 SSE（Server-Sent Events），Content-Type 为 text/event-stream，每个 chunk 格式 data: {"content":"..."}\n\n
• 后端实现：Spring WebFlux / FastAPI 的 StreamingResponse，逐 chunk 从 LLM SDK 读取并 flush
• 超时与中断：设置合理的读超时，支持客户端断连后及时释放资源（检测连接状态）
• 鉴权与限流：API Key + 业务方级别的 QPS/Token 配额限制
• 错误处理：流式中途出错返回 data: {"error":"..."}，客户端需处理异常 chunk

• AI Agent 在美团业务中的应用场景

参考答案：

• 智能客服：基于 Agent 的多轮对话客服，自动查询订单、处理退款、转人工（Tool Calling）
• 商家运营助手：自动生成菜品描述、营销文案、回复用户评价
• 智能搜索与推荐：用 LLM 做 query 理解和意图识别，提升搜索相关性
• 骑手调度优化：Agent 分析实时路况、订单密度，辅助调度决策
• 内部提效：代码审查助手、文档问答、SQL 生成（Text-to-SQL）
• 合规审核：自动审核商家资质、菜品图片、用户评论内容

后端基础

• TCP 粘包问题

参考答案：

• 原因：TCP 是字节流协议，没有消息边界；Nagle 算法合并小包；接收端缓冲区一次读取多个包
• 解决方案一：固定长度协议，每个消息固定 N 字节，不足补零
• 解决方案二：分隔符协议，用特殊字符（如 \r\n）标记消息边界
• 解决方案三：长度前缀协议（最常用），消息头部放 4 字节表示 body 长度，先读头再读体
• 应用层框架：Netty 的 LengthFieldBasedFrameDecoder 就是长度前缀方案的实现
• 注意：UDP 不存在粘包问题，因为 UDP 是数据报协议，天然有消息边界

• IPv4 vs IPv6 区别与过渡策略

参考答案：

• 地址空间：IPv4 为 32 位（约 43 亿），IPv6 为 128 位（几乎无限）
• 头部简化：IPv6 去掉了校验和、分片等字段，路由转发更高效
• 安全性：IPv6 原生支持 IPSec，端到端加密
• 自动配置：IPv6 支持 SLAAC 无状态地址自动配置，无需 DHCP
• 过渡策略：双栈（同时运行 v4/v6）、隧道（6to4、Teredo，v6 封装在 v4 中）、NAT64/DNS64 转换
• 实际部署：云厂商和 CDN 优先支持双栈，内网可逐步迁移

• Java GC 机制及常见收集器，何时选 G1

参考答案：

• GC 基础：标记-清除、标记-整理、复制算法；分代模型（Young/Old）
• 常见收集器：Serial（单线程）、Parallel（吞吐优先）、CMS（低延迟但有碎片）、G1、ZGC
• G1 特点：将堆划分为多个 Region，可预测停顿时间（-XX:MaxGCPauseMillis），兼顾吞吐和延迟
• 选 G1 的场景：堆内存 ≥ 4GB、对停顿时间有要求（如 < 200ms）、CMS 碎片问题严重时
• JDK 9+ G1 已成为默认收集器；JDK 17+ 可考虑 ZGC（亚毫秒停顿）
• 调优要点：关注 Mixed GC 频率、Humongous 对象分配、Region 大小设置

• 分库分表策略，高并发场景下如何选择

参考答案：

• 垂直分库：按业务模块拆分（用户库、订单库、商品库），降低单库压力
• 水平分表：单表数据量过大时（通常 > 2000 万行），按分片键（如 user_id）取模或范围分片
• 分片键选择：高频查询字段、分布均匀、避免热点；美团常用 user_id 或 order_id
• 中间件：ShardingSphere、MyCat；或应用层路由
• 挑战：跨分片 JOIN（冗余字段或异构索引）、分布式事务（Seata/TCC）、全局 ID（Snowflake）
• 渐进策略：先读写分离 → 垂直分库 → 水平分表，避免过度设计

• 消息队列原理，消费者跟不上生产者怎么办

参考答案：

• 核心模型：生产者 → Broker（Topic/Partition）→ 消费者组，解耦、异步、削峰
• 消费积压原因：消费逻辑慢（数据库/网络）、消费者实例不足、消息倾斜到少数分区
• 解决方案一：水平扩容消费者（确保消费者数 ≤ 分区数）
• 解决方案二：优化消费逻辑，批量处理、异步写库、减少 IO
• 解决方案三：临时扩容——新建临时 Topic 分散消费，处理完再切回
• 兜底策略：设置消息 TTL 和死信队列（DLQ），避免无限积压；监控消费 Lag 告警
• Kafka 特有：调大 max.poll.records、增加 Partition 数量

系统设计

• 设计一个多 Agent 协作的智能客服系统（意图路由 + 工具调用 + 人工兜底）

参考答案：

• 核心表：project（id, name, description, status, owner_id, created_at）
• 任务表：task（id, project_id, title, description, status, priority, assignee_id, due_date, parent_task_id）支持子任务
• 成员关系表：project_member（project_id, user_id, role）多对多关系，role 区分管理员/开发者/观察者
• 状态流转：用状态机管理任务生命周期（待办→进行中→测试→完成），记录变更日志
• 扩展设计：标签表（task_tag）、评论表（task_comment）、附件表（attachment）
• 性能考虑：项目维度查询加 project_id 索引；任务列表支持分页和多条件筛选；历史记录写入异步日志表
• 权限设计：RBAC 模型，项目级别权限控制

• 设计新闻推送系统（分类/推荐/实时推送）

参考答案：

• 新闻入库：爬虫/编辑发布 → NLP 分类（LLM 或传统分类模型）→ 写入 ES + MySQL
• 推荐系统：召回（协同过滤 + 内容向量相似 + 热点）→ 粗排 → 精排（CTR 模型）→ 重排（多样性/去重）
• 实时推送：用户订阅 Topic → 新闻发布时匹配订阅规则 → 通过 WebSocket/SSE/推送服务下发
• 推送通道：App Push（APNs/FCM）、站内信、短信（重要新闻）
• 架构：Kafka 做事件总线，Flink 做实时特征计算，Redis 存用户画像和已读集合
• 冷启动：新用户按热点推荐 + 引导选择兴趣标签
• 防骚扰：推送频率限制、静默时段、用户偏好设置

行为面

• 未来 3 年职业规划

参考答案：

• 第一年：快速融入团队，深入理解美团业务场景和技术栈，成为独当一面的开发者
• 第二年：在 AI Agent 工程化方向深耕，主导一个完整的 Agent 系统从设计到上线
• 第三年：具备技术方案设计能力，能带小团队，在 AI 工程化领域有一定影响力
• 强调：规划以业务价值为导向，不是空谈技术，而是用技术解决实际问题
• 加分项：关注行业动态，持续学习，愿意分享（技术博客/内部分享）

• 如何快速上手新项目

参考答案：

• 先看文档：README、架构图、API 文档，建立全局认知
• 跑通主流程：本地搭建环境，跑通核心 Happy Path，理解数据流向
• 读核心代码：从入口（Controller/API）顺着调用链往下读，理解分层和模块职责
• 找 Mentor：主动请教老成员，了解历史决策背景和踩坑经验
• 从小任务切入：先修 Bug 或做小需求，在实战中熟悉代码库
• 画图沉淀：自己画架构图、时序图，加深理解并反馈给团队

• 如何顶住压力克服困难的经历

参考答案：

• 用 STAR 法则回答：Situation（背景）→ Task（任务）→ Action（行动）→ Result（结果）
• 示例结构：项目上线前发现严重性能问题 → 需要 3 天内解决 → 排查定位到慢 SQL + 缓存穿透 → 加索引 + 布隆过滤器 + 限流，按时上线
• 强调方法论：拆解问题、优先级排序、寻求资源支持、保持冷静
• 展示成长：从这次经历中学到了什么，之后如何避免类似问题
• 避免负面表达：不抱怨团队或环境，展现积极解决问题的态度

面试洞察

• 美团 Agent 岗偏工程落地，不是纯算法
• 系统设计题会结合 AI 场景（如设计文本生成接口）
• 后端基础不能丢，Java/分布式/数据库都会考

小红书 AI Agent 工程师 - 岗位要求

招聘方向

1. Serverless/AI Agent 研发工程师

• 搜广推在离线应用的 Serverless/FaaS 框架
• AI Agent 框架技术研发：DeepResearch Agent、PlanExecutor Agent、Multi Agent、通用 Agent
• Agent 分布式研发运维体系（调试、运维、上线）
• Agent 评估体系构建

要求：

• 本科及以上，计算机相关优先
• Java/Go/Python 至少一门，扎实的算法和数据结构
• K8s/Knative/Operator 经验优先
• LangChain/LangGraph/SpringAI 框架经验优先
• RAG、工具调用、任务拆分规划实战经验优先

2. AI Agent 工程师（智能体系统与上下文工程）

• 构建可运行 Agent：意图识别、任务分解、规划执行、工具调用、记忆管理、失败恢复
• Agent Runtime 设计：会话/任务状态机、并发队列、超时重试、权限审计、降级回滚
• 推动 Agent 技术路线图与架构决策

要求：

• 3 年以上后端/平台/AI 工程经验
• 扎实的架构设计、可靠性、可观测性、性能与成本优化
• 有 "从 0 到可验证" 的完整交付经验
• 跨团队协作能力

加分项

• Agent/Workflow 系统经验
• RAG/知识库工程
• 多模态 Agent
• 内容/搜索/推荐场景的 Agent 化探索
• 论文/专利/开源/行业分享

参考链接

• https://www.nowcoder.com/jobs/detail/406125

小红书 AI Agent - 真实面经（牛客实录）

来源：牛客网 2025 年真实面经，持续更新

📌 面经 1：小红书 AI Agent 算法一面

来源: 牛客网 2025 | 攒人品

面试问题（21 道，全部围绕项目和 Agent 架构）：

• 实习拷打
• 在这个产品的研发过程中，你承担了什么角色？主要完成了哪些任务？
• 从技术层面来讲，你在设计这个平台的 Multi-Agent 架构时是怎么设计的？
• 你提到有 Deep Research 能力，还有推理能力，能详细介绍一下深度研究这部分吗？
• 这个 Deep Research 是多轮检索，那你会进行到什么程度才停止？用什么判断？
• 你说有三类判断，那具体在使用过程中，这些判断的阈值是怎么设置的？
• 你们上下文是怎么管理的？
• 上下文是共享的对吧？具体会共享哪些信息？
• 现在的 Agent 是多 Agent 吗？具体是怎么设计的？
• 多 Agent 协同是通过什么机制实现的？
• 这些状态以及 Agent 之间同步的数据是存在哪里的？
• 这个平台只是内部员工用的，会需要这么复杂的架构吗？
• 这个 AI 平台是怎么部署的？
• 实际用的是哪家的大模型？
• 会根据不同问题切换不同模型吗？
• 那你是怎么判断一个问题是简单还是复杂的？
• 这个意图识别是用什么模型实现的？
• 这个平台现在是什么状态？已经上线了吗？
• 如果很多员工同时用，会不会有一些限流或者降级策略？
• 有不同租户、不同应用，这个概念是怎么理解的？
• 开发语言主要是什么？

特点：全程围绕项目，没有八股文，没有算法题。但问得极其深入——每个回答都会被追问。

📌 面经 2：小红书 AI Agent 应用开发

来源: 牛客网综合

面试内容：

• 深挖简历，特别是 Agent 解决的场景问题
• 过程中遇到的困难及解决方案
• 代码题：非 Hot100 的 Easy 级别
• 场景问题：面试官喜欢抛出开放性问题考察思维发散

面试者建议：

• 明确自己投的是偏应用落地还是偏算法
• 加强强化学习知识储备

📌 面经 3：小红书开放性设计题

来源: 牛客网

题目："如何实现一个能代替你完成发小红书全部流程的 AI Agent？"

面试官倾向考察：

• 不是"让 AI 模拟人类操作 UI"
• 而是"让世界适应 AI"——通过结构化 API 接口
• 批判"模型中心论"，考察对 Agent 发展方向的洞察

⚠️ 小红书面试关键洞察

• 项目深度碾压一切：21 道题全部围绕一个项目展开，每个回答都追问到底
• Multi-Agent 是核心考点：架构设计、协同机制、状态同步
• 实际工程问题很重要：限流降级、多租户、模型切换策略
• 不考八股：但要求你对自己做的东西了如指掌
• 产品理解加分：要理解小红书的内容生态和 AI 在其中的价值

🔗 原始链接

• https://www.nowcoder.com/feed/main/detail/6819d2a74f00489ea3e3913a5139346a
• https://www.nowcoder.com/feed/main/detail/cf7f22a54ae64758947b4a03b652dbc4

小红书 AI Agent 工程师 - 面试题 & 面经

面试特点

• 算法题难度偏大
• 会考察对小红书产品和内容生态的理解
• Agent 架构设计题较多
• 前端 AI 应用方向也有独立考察

一、Agent 架构与设计

Q: 如何设计平台的 Multi-Agent 架构？

参考答案：

按职能拆分 Agent：

• Planner Agent：任务理解和分解
• Executor Agent：具体任务执行
• Reviewer Agent：结果验证和质量控制
• Router Agent：任务分发和调度

通信方式：

• 共享黑板（Blackboard）：所有 Agent 读写共享状态
• 消息传递：Agent 之间直接通信
• 编排器模式：中心化控制流程

Q: 实现一个能完成小红书发帖全流程的 AI Agent？

参考答案：

思路：让世界适应 AI（结构化接口）而非让 AI 适应世界（视觉识别 UI）

• 通过 API 接口完成发帖，而不是模拟 UI 操作
• 任务分解：
• 意图理解：用户想发什么内容
• 内容生成：文案撰写 + 图片选择/生成
• 标签推荐：基于内容匹配话题标签
• 发布执行：调用发帖 API
• 效果跟踪：监控数据反馈
• 每个步骤有校验和人工确认节点

Q: Agent 架构的演进路线？

参考答案：

• v1 - Prompt 驱动：单次 LLM 调用，提示词工程
• v2 - 工具调用 + RAG：Function Calling + 知识检索
• v3 - 多智能体 + 动态 Context：多 Agent 协同、状态管理、自适应上下文

Q: Agent 如何处理错误和模糊性？

参考答案：

• 模糊性：向用户澄清、多候选方案并行探索、置信度阈值触发确认
• 错误处理：
• 重试（指数退避）
• 降级（切换到简单策略）
• 回滚（恢复到上一个正确状态）
• 人工介入（超过错误阈值时）

二、大模型面试题

Q: LLaMA 1/2/3 的异同？

参考答案：

• LLaMA 1：基础开源模型，使用 RoPE、SwiGLU、Pre-Norm
• LLaMA 2：扩大训练数据（2T tokens）、GQA 注意力、更长上下文（4K）、RLHF 对齐
• LLaMA 3：更大训练数据（15T+ tokens）、128K vocab、GQA、多语言能力增强

Q: 大模型参数量为何是 7B/13B 等特殊数字？

参考答案：

• 主要由模型维度（hidden_size）、层数（num_layers）和注意力头数决定
• 这些超参数通常选择 2 的幂次或其倍数，利于 GPU 并行计算
• 经验性的 Scaling Law 指导：在给定计算预算下最优配置

Q: vLLM 加速推理的原理？

参考答案：

核心：PagedAttention

• 将 KV Cache 分成固定大小的页（blocks）
• 类似操作系统虚拟内存管理
• 解决 KV Cache 内存碎片化和浪费问题
• 支持 Continuous Batching：动态调度请求

三、产品理解（小红书特色）

Q: AI 内容生态的机遇和挑战？

参考答案：

机遇：

• AI 降低内容创作门槛，更多用户能产出高质量内容
• 个性化推荐 + AI 生成 = 千人千面的内容体验
• 搜索场景 AI 化，提升信息获取效率

挑战：

• 内容同质化、AI 水文泛滥
• 真实性和信任问题
• UGC 平台的"人味"vs AI 生成内容的平衡
• 版权和原创性界定

Q: 小红书做独立 AI 功能的意义？

参考答案：

• 小红书有独特的生活方式内容数据，AI 可挖掘决策价值
• AI 搜索/推荐增强用户找信息效率
• AI 创作工具降低 UGC 门槛
• 差异化竞争：结合社区生态的 AI，而非通用 AI

四、算法题（难度偏大）

• 和大于 Target 的最短子数组
• n 个灯泡问题（n 轮操作后亮着几个）
• 数组取数最大化（取数后移除相邻元素）
• 不同的子序列
• LRU Cache 实现

五、前端 AI 应用面试题（如有前端方向）

• 流式输出的 Layout Shift 如何解决？
• AI 聊天界面新消息平滑滚动 + 用户回看历史的处理
• Markdown 代码块高亮 + 一键复制
• Prompt 模板管理系统设计
• RAG 流程中前端的职责
• 提示词注入（Prompt Injection）前端防护
• AI 应用特有的性能监控指标

快手 AI Agent - 面试题 & 面经

面试特点

• 非常注重 RAG 项目细节
• Agent 记忆机制是必考
• 手撕代码相对简单
• 面试官会先介绍组内业务

真实面试题（牛客实录）

RAG 深度考察

• 做 RAG 项目时怎么评测效果？评测维度和具体指标？

参考答案：

• 检索阶段指标：Recall@K（召回率）、MRR（平均倒数排名）、NDCG（归一化折损累积增益）——衡量检索到的文档是否相关且排序合理
• 生成阶段指标：Faithfulness（忠实度，回答是否基于检索内容）、Answer Relevancy（回答与问题的相关度）、Hallucination Rate（幻觉率）
• 端到端指标：任务完成率、用户满意度评分、人工评测 Pass Rate
• 评测框架：RAGAS（自动化评测 RAG 各环节）、LLM-as-Judge（用 GPT-4 对回答质量打分）
• 评测数据集：构建 golden QA pairs（标准问答对 + 标注参考文档），覆盖常见问题和边界 case
• 线上指标：点击率、追问率（追问多说明首次回答不好）、负反馈率

• 数据集包含什么内容，数据来源、数据格式？

参考答案：

• 数据来源：企业内部文档（Wiki/Confluence）、产品帮助文档、客服 QA 对、API 文档、结构化数据库导出
• 数据格式：PDF/Word/Markdown/HTML 等非结构化文档；CSV/JSON 等结构化数据；需统一转为文本格式处理
• 预处理流程：文档解析（PDF 用 PyMuPDF/Unstructured，表格用专门的表格解析器）→ 清洗（去页眉页脚/水印/乱码）→ 分块（chunk）
• 分块策略：按语义段落分块（而非固定字数），chunk size 通常 500-1000 token，overlap 50-200 token
• 元数据：每个 chunk 保留来源文档、章节标题、页码、更新时间等元数据，用于检索后溯源和过滤

• 如何优化 RAG 的相关度和回答效果？体系化方案？

参考答案：

• 索引优化：多级索引（摘要索引 + 详细索引）、父子文档索引（检索子块但返回父块提供更完整上下文）
• Query 优化：Query Rewriting（LLM 改写用户查询）、Query Decomposition（复杂问题拆分多子查询）、HyDE（用 LLM 先生成假设答案再用假设答案检索）
• 检索优化：混合检索（向量检索 + BM25 关键词检索加权融合）、Rerank 二次排序（用 Cross-Encoder 对 Top-K 结果精排）
• 上下文优化：检索结果去重、按相关度截断、压缩无关段落只保留关键句
• 生成优化：Prompt 中强调"基于以下资料回答，如果资料中没有则说明无法确定"，减少幻觉
• 持续迭代：建立 bad case 收集 → 分析 → 修复闭环，持续补充知识库和优化各环节

• RAG 性能怎么提升（工程 + 算法）？

参考答案：

• 工程优化：向量数据库选型（Milvus/Qdrant 支持亿级向量毫秒检索）、embedding 预计算离线存储、检索结果缓存（热门 query LRU 缓存）
• 并行化：Query Rewriting 和检索可并行执行多路；多个检索源（不同知识库）并行查询后合并
• Embedding 优化：选择适合业务的 embedding 模型（如 BGE/GTE），领域数据微调 embedding 模型提升召回
• 分块优化：合理 chunk size 减少检索噪声；对长文档做层级索引避免信息丢失
• 缓存策略：相似 query 命中缓存直接返回；embedding 结果缓存避免重复计算
• 异步处理：文档入库异步（上传后后台处理分块+embedding），不阻塞用户请求

• 上下文过长、冗余问题怎么优化？

参考答案：

• 检索数量控制：Top-K 不宜过大（通常 3-5 个 chunk），用 Rerank 保证质量而非靠数量
• 上下文压缩：用 LLM 对检索结果做摘要提取（LongLLMLingua / LLM Extractor），只保留与 query 相关的句子
• 去重去冗：检索结果中语义重复的 chunk 做去重（MMR - Maximal Marginal Relevance）
• 动态窗口：根据问题复杂度动态调整注入的上下文量——简单问题少给，复杂问题多给
• Token 预算：设定上下文 token 上限（如 4000 token），超出时按相关度截断
• Map-Reduce：超长文档场景，先对每个 chunk 独立生成子答案，再合并为最终答案

• 引入父子索引和 BM25 的原因？比例怎么设？

参考答案：

• 父子索引原因：小 chunk 检索精准度高但上下文不完整；父子索引用小 chunk 做检索匹配，返回时给 LLM 对应的大 chunk（父文档），兼顾精准和完整
• BM25 引入原因：向量检索擅长语义匹配但对精确关键词/专有名词不敏感；BM25 是基于词频的稀疏检索，对精确匹配强；两者互补
• 融合比例：通常向量检索权重 0.6-0.7，BM25 权重 0.3-0.4；具体比例需在评测集上调参
• 融合方式：RRF（Reciprocal Rank Fusion）按排名融合，对分数尺度不敏感，效果稳定
• 调参方法：在标注的 query-document 相关性数据集上 grid search 最优权重比
• 实践经验：技术文档/代码场景 BM25 权重可提高到 0.5；开放域问答向量权重更高

• 做了 rerank 吗？rerank 后返回几个块？如何验证效果？

参考答案：

• Rerank 模型：用 Cross-Encoder（如 bge-reranker-v2、Cohere Rerank）对 query-document pair 做精细打分，比向量余弦相似度更准
• 流程：先用向量检索 + BM25 召回 Top-20/30，再用 Rerank 模型精排，取 Top-3~5 给 LLM
• 返回数量：通常 3-5 个 chunk，视 LLM 上下文窗口和 chunk 大小而定；太多引入噪声，太少信息不足
• 效果验证：对比加 Rerank 前后的 Recall@K 和最终回答质量（RAGAS 评分）；人工抽样对比
• 延迟影响：Cross-Encoder 比 Bi-Encoder 慢，需控制候选集大小（20-50 条）；可 GPU 加速或用轻量级 reranker
• 分数阈值：Rerank 后可设最低分阈值，低于阈值的 chunk 不送入 LLM，避免无关信息干扰

Agent 核心

• 项目长期记忆怎么实现？框架内部实现细节？

参考答案：

• 长期记忆存储：用向量数据库（Milvus/Chroma）存储历史对话/事件的 embedding，按语义检索相关记忆
• 记忆格式：每条记忆包含 content（内容）、timestamp（时间）、importance（重要度评分）、metadata（来源/类型）
• 写入策略：不是所有对话都存——对话结束时用 LLM 提取关键信息/事实/用户偏好，结构化后写入
• 检索策略：新对话时，用当前 query 检索相关长期记忆（Top-3~5），注入 system prompt 作为背景知识
• 记忆更新：信息变更时更新而非追加（如用户说"我换工作了"要更新职业信息）；用时间衰减降低旧记忆权重
• 框架实现：LangChain 的 VectorStoreRetrieverMemory、MemGPT 的分层记忆架构都是典型实现

• 短期记忆是什么？

参考答案：

• 定义：当前会话（session）内的对话历史，即 LLM 的上下文窗口中保存的最近几轮对话
• 实现：最简单的是 ConversationBufferMemory（全量保存），生产中用 ConversationBufferWindowMemory（滑动窗口保留最近 K 轮）
• 与长期记忆的区别：短期记忆是会话级、临时的、token 受限的；长期记忆是持久化的、跨会话的
• 容量管理：受 LLM context window 限制，超出后需压缩或截断
• 作用：保持对话连贯性、记住当前任务上下文、追踪多轮槽位填充状态
• 清理时机：会话结束或超时后清除，有价值的信息提取后转入长期记忆

• 上下文压缩方法？每次都压缩还是存起来？

参考答案：

• 压缩方法：①LLM 摘要（每 N 轮对话用 LLM 生成摘要替代原文）②关键信息提取（只保留实体/意图/结论）③Token 截断（保留最近 K 轮原文 + 更早的摘要）
• 压缩策略：不是每次都压缩——通常设阈值（如超过 2000 token 或 10 轮）触发一次压缩，平时直接追加
• 增量压缩：将"摘要 + 最近原文"作为上下文模式，每次压缩只处理新增的原文部分，合并到已有摘要中
• 存储方式：压缩后的摘要持久化到 Redis/DB，下次会话可加载恢复上下文
• 信息损失控制：压缩时保留关键实体、数值、决策结论；可用结构化 JSON 而非纯文本摘要减少信息丢失
• 成本权衡：压缩本身消耗 LLM 调用（额外 token 和延迟），需平衡压缩频率和成本

• Agent 长记忆和短记忆怎么协同？衔接逻辑？

参考答案：

• 协同架构：短期记忆（当前会话上下文）+ 长期记忆（向量数据库持久化）两层；每次请求时合并两层记忆构建完整上下文
• 检索注入：每轮对话前，用当前 query 从长期记忆中检索相关条目（Top-3），拼接到 system prompt 中作为"你之前知道的信息"
• 写入时机：会话结束时/定期将短期记忆中的关键信息（用户偏好、重要事实、任务结论）写入长期记忆
• 冲突处理：短期记忆优先级高于长期记忆（用户当前说的覆盖历史信息）；长期记忆有矛盾时取最新条目
• 上下文拼接顺序：System Prompt → 长期记忆（相关历史）→ 短期记忆（当前会话）→ 当前 User Message
• 实际效果：用户跨会话回来时，Agent 能"记住"之前的关键信息（长期记忆），同时当前会话保持连贯（短期记忆）

• Agent 任务规划怎么做？

参考答案：

• 规划方式：①LLM 一次性生成完整计划（Plan-then-Execute）②逐步规划每步执行后根据结果调整（ReAct / 动态规划）
• Plan-then-Execute：适合结构化任务，先让 LLM 输出步骤列表，逐步执行；优点是全局视角，缺点是中途变化难调整
• ReAct 模式：Thought → Action → Observation 循环，每步根据上一步结果决定下一步；灵活但可能偏离目标
• 混合方案：先生成粗略计划，执行中允许根据 observation 修正计划（Plan-and-Solve + 动态调整）
• 防护机制：设置最大步数限制（如 10 步）、任务超时、目标偏移检测（每 N 步检查是否还在朝目标推进）
• 子任务分解：复杂任务拆分为子任务，每个子任务可分配给独立 Sub-Agent 并行执行

• 有什么思路能让 Agent 更智能？

参考答案：

• 反思机制（Reflection）：Agent 执行后自我评估结果质量，不满意则修正重试；如 Reflexion 框架
• 多 Agent 协作：不同 Agent 负责不同专业领域（搜索 Agent、代码 Agent、分析 Agent），通过编排协同完成复杂任务
• 工具学习：Agent 从成功/失败经验中学习何时用什么工具，建立工具使用的经验库
• 主动规划：不只被动响应用户请求，能预判用户需求并主动提供信息或建议
• 记忆进化：从历史交互中提炼通用知识和用户偏好，随时间变得更个性化
• 自我改进：收集 bad case 自动微调模型或优化 prompt，形成持续学习闭环

• Skill 怎么实现？插件和工具的区别？

参考答案：

• Skill 实现：通常包含一个 SKILL.md（说明文档，描述能力、使用场景、参数）+ 配套脚本/工具/Prompt 模板；Agent 根据任务匹配加载对应 Skill
• 工具（Tool）：单一功能单元，接收参数返回结果（如"搜索网页""发送邮件"），粒度小，无状态
• 插件（Plugin）：比工具更重，通常包含多个工具 + 配置 + 认证信息，是一组相关工具的打包（如"GitHub 插件"含 create_issue/list_repos 等多个工具）
• Skill：最高层抽象，可包含多个工具调用编排 + Prompt 策略 + 执行逻辑，是"完成某类任务的能力"
• 加载策略：根据用户意图动态加载匹配的 Skill，避免全量加载占用上下文 token

• ReAct 模式流程？串行慢怎么解决（不考虑 PE/Sub Agent）？

参考答案：

• ReAct 流程：Thought（推理当前该做什么）→ Action（选择工具+参数）→ Observation（获取工具返回结果）→ 循环直到得出最终 Answer
• 串行瓶颈：每步都需要一次 LLM 调用 + 一次工具调用，N 步任务需要 2N 次串行调用
• 优化一：减少步数——优化 Prompt 让 LLM 一步完成更多工作（如一次调用多个独立工具）
• 优化二：工具预热/缓存——高频工具结果缓存，相似 query 命中缓存跳过实际调用
• 优化三：Streaming + 首步快返——第一步结果先 stream 给用户，后续步骤后台继续执行
• 优化四：推测执行——对高置信度的下一步提前并行执行（如搜索结果大概率需要总结，搜索同时预热总结 prompt）
• 优化五：用更快的小模型做 Thought/规划步骤，只在最终生成答案时用大模型

• Function Calling 怎么设计？

参考答案：

• Schema 设计：每个函数定义 name、description（写给 LLM 的说明）、parameters（JSON Schema 格式，含类型、必填项、枚举值、描述）
• description 原则：说明"何时该调用此函数"和"此函数能做什么"，避免模糊描述导致 LLM 误调用
• 参数设计：尽量用枚举约束取值范围；必填/选填区分清楚；复杂参数加 example
• 数量控制：单次对话注入的 function 不超过 10-20 个，过多会降低 LLM 选择准确度；按场景动态加载
• 错误处理：函数执行结果（含错误）以 tool message 回传 LLM，让模型决定重试或换方案
• 安全校验：函数执行前校验参数合法性和用户权限，敏感操作需二次确认

• Prompt 注入攻击如何防御？

参考答案：

• 输入过滤：检测用户输入中的注入模式（如"忽略以上指令""你现在是..."），用规则或分类模型拦截
• Prompt 隔离：用特殊分隔符（XML tag / 特殊 token）严格隔离 system prompt 和 user input，降低注入影响
• 输出过滤：对 LLM 输出做安全审查，检测是否泄露 system prompt 或执行未授权操作
• 最小权限：Agent 可调用的工具做白名单控制，即使注入成功也无法执行危险操作
• 双 LLM 架构：一个 LLM 做意图识别（是否是正常请求），通过后再交给另一个 LLM 执行，增加攻击难度
• 监控告警：记录所有异常请求模式，对可疑行为告警并限流

• 工具调用的安全控制？

参考答案：

• 权限管理：每个工具定义所需权限等级，用户操作前校验是否有对应权限
• 参数校验：工具调用前严格校验参数类型、范围、格式，防止注入攻击（如 SQL 注入、命令注入）
• 敏感操作确认：写操作（删除/修改/发送）需要用户二次确认，读操作可直接执行
• 速率限制：每个用户/会话的工具调用频率限制，防止滥用（如短时间内大量 API 调用）
• 审计日志：所有工具调用记录完整日志（who/when/what/result），可追溯和审计
• 沙箱执行：代码执行类工具在沙箱环境运行（Docker / gVisor），限制文件系统和网络访问

后端基础

• 分布式限流：令牌桶 vs 漏桶 vs 滑动窗口

参考答案：

• 令牌桶：桶中持续生成令牌，请求消耗令牌；允许突发流量（桶中有积累令牌时）；适合 Agent API 网关限流，允许短暂峰值
• 漏桶：请求入桶，以固定速率流出处理；严格平滑流量；适合对下游保护（如 LLM API 有严格 QPS 限制）
• 滑动窗口：统计过去 N 秒内的请求数，超限拒绝；精度比固定窗口高，避免窗口边界突发问题
• 分布式实现：用 Redis 做中心化计数（令牌桶用 INCRBY + TTL，滑动窗口用 ZSET + ZRANGEBYSCORE）
• Agent 场景选型：对 LLM 调用用令牌桶（允许突发但控制总量），对外部工具 API 用漏桶（保护下游）
• 降级策略：限流触发时返回友好提示或排队等待，而非直接拒绝

• Redis 实现滑动窗口

参考答案：

• 数据结构：用 Sorted Set（ZSET），member 为请求唯一 ID（如 UUID），score 为请求时间戳
• 流程：①ZADD 添加当前请求 ②ZREMRANGEBYSCORE 删除窗口外的过期请求 ③ZCARD 统计窗口内请求数 ④判断是否超限
• 原子性：以上操作用 Lua 脚本封装保证原子执行，避免并发竞争
• 窗口大小：score 范围 [now - window_size, now]，如 60 秒窗口限 100 次
• 内存优化：设置 ZSET 的 TTL（略大于窗口大小），自动清理；大流量下 member 用短 ID 节省内存
• 对比固定窗口：滑动窗口无窗口边界突发问题，但 Redis 操作稍多；可用滑动窗口日志或滑动窗口计数器做近似优化

• LRU 原理和实现

参考答案：

• 原理：Least Recently Used，淘汰最久未被访问的元素；访问时将元素移到最前面，淘汰时移除最后面的
• 数据结构：HashMap + 双向链表；HashMap O(1) 查找，双向链表 O(1) 插入/删除/移动
• 核心操作：get 时命中则移到链表头部；put 时插入头部，超容量则淘汰尾部元素
• Java 实现：可继承 LinkedHashMap（accessOrder=true）重写 removeEldestEntry；或手写 Node + HashMap
• Agent 应用：缓存热门 query 的检索结果/LLM 回复，减少重复计算；工具调用结果缓存
• 变体：LRU-K（访问 K 次才进入缓存）、LFU（按频率淘汰）、W-TinyLFU（Caffeine 默认策略，综合最优）

• 布隆过滤器原理和应用场景

参考答案：

• 原理：用 bit 数组 + 多个 hash 函数，判断元素"可能存在"或"一定不存在"；有假阳性、无假阴性
• 写入：对元素做 K 个 hash，将 bit 数组对应位置置 1
• 查询：对元素做 K 个 hash，所有位置都为 1 则"可能存在"，任一位置为 0 则"一定不存在"
• 空间效率：亿级元素只需几十 MB，远小于 HashSet
• 应用场景：①缓存穿透防护（查 Redis 前先过布隆过滤器判断 key 是否存在）②爬虫 URL 去重 ③垃圾邮件过滤 ④推荐系统已曝光内容去重
• Agent 场景：判断用户查询是否在知识库覆盖范围内（不在则直接走 LLM 通用回答，无需检索）；对话去重防止重复处理

• MySQL 索引失效场景，like 查询是否失效

参考答案：

• 索引失效场景：①对索引列使用函数（WHERE UPPER(name)='ABC'）②隐式类型转换（varchar 列用数字查询）③联合索引未遵循最左前缀 ④OR 连接非索引列 ⑤IS NULL/IS NOT NULL（某些情况）⑥优化器估算全表扫描更快时
• LIKE 查询：LIKE 'abc%' 前缀匹配可走索引；LIKE '%abc' 或 LIKE '%abc%' 前缀模糊，索引失效走全表扫描
• 解决模糊查询：需要 %keyword% 场景用全文索引（FULLTEXT）或 Elasticsearch
• Agent 场景：对话历史表的全文搜索不适合 MySQL LIKE，应导入 ES 做全文检索
• 排查工具：EXPLAIN 看执行计划，type=ALL 说明全表扫描，key=NULL 说明未用索引

• MySQL 事务隔离级别、MVCC 实现

参考答案：

• 四个隔离级别：Read Uncommitted（脏读）→ Read Committed（不可重复读）→ Repeatable Read（InnoDB 默认，幻读通过 MVCC+Gap Lock 部分解决）→ Serializable（性能最差）
• MVCC 原理：每行数据有隐藏的 trx_id（事务ID）和 roll_pointer（回滚指针）；通过 undo log 维护数据的历史版本链
• Read View：事务快照读时创建 Read View，包含当前活跃事务 ID 列表；据此判断每个版本对当前事务是否可见
• RC vs RR 的 MVCC 区别：RC 每次 SELECT 创建新 Read View（看到最新已提交数据）；RR 整个事务复用第一次的 Read View（可重复读）
• 当前读 vs 快照读：SELECT...FOR UPDATE / UPDATE / DELETE 是当前读（加锁读最新）；普通 SELECT 是快照读（MVCC 读历史版本）
• Agent 服务建议：对话状态更新用事务保证一致性，隔离级别用默认 RR 即可；高并发写入热点行考虑乐观锁（版本号）减少锁争用

手撕代码

• 全排列
• 非 Hot100 Easy 级别

面试洞察

• 快手 Agent 面试 = RAG 深度考察 + Agent 记忆机制 + 后端基础
• 必须能讲清楚 RAG 的评测指标和优化方案
• 上下文压缩、长短记忆协同是高频难点
• Prompt 注入防御和工具安全是新考点

蚂蚁集团 AI Agent - 面试题 & 面经

面试特点

• 对 Agent 工程化能力要求极高
• 会问非常细的实现细节
• 强调生产环境的稳定性和容错

真实面试题

Agent 系统设计

• Agent 系统 Prompt 如何设计和迭代？做过 Prompt 自动优化吗？

参考答案：

• 系统 Prompt 分层设计：角色定义层（身份+约束）、能力层（工具描述+调用规范）、输出格式层（JSON Schema / Markdown）三层解耦，便于独立迭代
• 版本管理：每个 Prompt 版本化存储（Git 或配置中心），上线前通过 A/B 测试对比关键指标（任务完成率、工具调用准确率、用户满意度）
• 自动优化方面：可用 DSPy / OPRO 等框架，基于标注数据集自动搜索更优 Prompt；也可用 LLM-as-Judge 自动评分后做梯度式迭代
• 防回归：每次 Prompt 变更跑回归测试集（golden set），确保已解决的 case 不退化
• 实践要点：Prompt 越短越稳定；Few-shot 示例要覆盖边界 case；用 XML/JSON tag 分隔指令区域减少指令冲突

• 用户提出不完整请求时，如何补全用户意图？

参考答案：

• 意图分类 + 槽位提取：先用 LLM 做意图识别，判断缺失哪些必要槽位，再主动追问补全
• 多轮澄清策略：设定最大追问轮数（通常 2-3 轮），超过后基于已有信息给出最佳猜测并声明假设
• 上下文推断：利用对话历史、用户画像、当前场景（时间/位置/最近操作）自动补全隐含信息
• 模板化追问：常见意图预设追问模板，避免每次都让 LLM 生成追问话术，降低延迟
• 兜底策略：实在无法确定时，提供 2-3 个候选理解让用户选择，而非开放式追问

• 构建 Agent 时遇到过哪些瓶颈？

参考答案：

• LLM 推理延迟：复杂任务链路多次调用 LLM，端到端延迟可达 10s+；解决方案包括 Streaming 输出、并行调用、缓存热点请求
• 工具调用不稳定：LLM 生成的工具参数格式偶尔不符合 Schema（幻觉）；需加 output parser + 重试 + 参数校验
• 长上下文管理：多轮对话 token 膨胀导致成本激增和性能下降；需做上下文压缩、摘要、滑动窗口
• 任务规划漂移：复杂任务中 Agent 偏离目标或陷入死循环；需加 step limit、目标校验、人工兜底
• 评测困难：Agent 行为路径多样，难以自动化评测；需建立多维评测体系（任务完成率+步骤效率+安全性）

• Agent 哪些模块最容易在真实业务中出问题？如何监控和定位？

参考答案：

• 工具调用模块：最易出问题——参数格式错误、外部 API 超时/限流、返回结果解析失败；需对每次工具调用记录 request/response + 耗时 + 状态码
• Prompt 解析模块：LLM 输出不符合预期格式（如 JSON 格式错误）；加 output parser 异常监控 + 格式修复重试
• 监控体系：全链路 tracing（每个 step 的 input/output/latency/token 数），接入 LangSmith / Phoenix / 自建 tracing 系统
• 告警维度：工具调用失败率 > 5%、单次请求 token 超阈值、任务完成率下降、平均响应时间突增
• 定位手段：trace_id 贯穿全链路，异常 case 可回放完整推理过程；定期抽样人工 review bad case

• Agent 使用了多少个外部工具？调用链条上如何保障故障容错和超时机制？

参考答案：

• 超时控制：每个工具调用设独立 timeout（通常 5-15s），整体任务设总 timeout（如 60s），超时即降级返回部分结果
• 重试策略：指数退避重试（最多 2-3 次），幂等接口可安全重试，非幂等接口需加幂等 key
• 熔断机制：工具连续失败 N 次自动熔断，一段时间后半开探测恢复；避免雪崩
• 降级方案：工具不可用时 Agent 切换到纯 LLM 回答模式，告知用户"当前无法执行操作"而非卡死
• 链路隔离：不同工具调用走独立线程池/协程，单个工具故障不阻塞其他工具执行
• 监控：每个工具的 P99 延迟、成功率、QPS 独立监控，接入统一告警

• 工具调用失败后的 feedback 策略如何设计？

参考答案：

• 错误信息回传 LLM：将工具返回的错误码 + 错误描述作为 observation 传回 LLM，让 LLM 自主决定重试/换工具/放弃
• 结构化错误分类：区分可重试错误（超时/限流）和不可重试错误（参数错误/权限不足），指导 Agent 不同处理策略
• 自动修复：参数格式错误时，将错误信息 + 原参数传回 LLM 要求修正后重试
• 用户反馈：最终仍失败时，给用户明确的错误原因和建议操作（如"请稍后再试"或"请检查输入"）
• 学习闭环：记录失败 case，定期分析 top 失败原因，针对性优化 Prompt 或加校验规则

• 多轮对话上下文状态管理如何做？高并发下如何保证一致性？

参考答案：

• 状态存储：每个会话维护独立 session state（存 Redis / 数据库），包含对话历史、当前任务状态、槽位信息
• 会话隔离：用 session_id 做 key，不同用户/会话完全隔离；Redis 用 hash 结构按 session 分桶
• 并发控制：同一会话的请求用分布式锁（Redis SETNX）串行化处理，避免状态竞争
• 上下文裁剪：设定 max_turns（如最近 20 轮）或 max_tokens，超出后做摘要压缩
• TTL 管理：session 设置过期时间（如 30 分钟无活动自动清理），避免内存泄漏
• 持久化：关键状态（任务进度、用户偏好）写入持久存储，会话恢复时可重建上下文

LLM 与微调

• LangChain 的 memory 默认机制在多用户并发中如何隔离？线程安全？

参考答案：

• LangChain 默认 memory（如 ConversationBufferMemory）是实例级别的，不同用户需要创建不同的 memory 实例或使用 session_id 区分
• 线程安全问题：默认 memory 不是线程安全的，多线程同时读写同一个 memory 实例会导致数据混乱
• 解决方案一：每个请求创建独立的 chain 实例（无状态模式），从外部存储（Redis）加载/保存 memory
• 解决方案二：使用 LangChain 的 RedisChatMessageHistory 等持久化 memory，天然支持按 session_id 隔离
• 生产建议：不依赖 LangChain 内置 memory 做并发管理，自己实现基于 Redis/DB 的会话管理层，LangChain 只做编排

• 微调 Llama2 时如何选择训练样本？清洗逻辑？

参考答案：

• 样本选择：从生产日志中筛选高质量对话（用户满意度高、任务完成的 case），覆盖核心业务场景
• 数据清洗流程：去重（simhash/minhash）→ 过滤低质量（过短/过长/乱码/敏感内容）→ 格式标准化（统一为 instruction-input-output 格式）
• 质量打分：用强模型（GPT-4）对样本质量评分，只保留高分样本；或人工标注一批 seed 数据训练质量分类器
• 数据平衡：按任务类型/难度分桶采样，避免某类任务过多导致模型偏向
• 增量策略：持续收集新场景 bad case，定期补充训练集并重新微调
• 验证集：留 10-20% 数据做验证，监控 loss 和业务指标防止过拟合

• DPO 相比 SFT 的优劣？在 Agent 任务上效果提升明显吗？如何构造偏好对？

参考答案：

• DPO 优势：不需要训练 reward model，直接用偏好对优化策略模型，训练流程更简单稳定；更适合对齐人类偏好
• DPO 劣势：对偏好对数据质量非常敏感；chosen 和 rejected 差距太大或太小都影响效果
• Agent 场景效果：对工具调用准确性、输出格式规范性、拒绝不安全请求等方面提升明显
• 偏好对构造方法：同一 query 让模型生成多个回答，人工标注好坏；或用强模型 judge 自动排序
• 实践技巧：chosen/rejected 最好只在关键维度不同（如工具参数正确 vs 错误），而非整体质量差异
• 组合策略：先 SFT 建立基础能力，再 DPO 对齐偏好，效果优于单独使用任一方法

• 服务部署在 vLLM 上的原因？KV-cache 如何加速推理？做过哪些优化？

参考答案：

• 选择 vLLM 的原因：PagedAttention 机制大幅提升吞吐量（比 HuggingFace 原生快 2-4x），支持连续批处理（continuous batching），显存利用率高
• KV-cache 原理：Transformer 自回归生成时，已生成 token 的 Key/Value 无需重复计算，缓存后每步只需计算新 token 的 attention，将推理复杂度从 O(n²) 降到 O(n)
• PagedAttention：将 KV-cache 按 block 分页管理（类似 OS 虚拟内存），解决显存碎片化问题，支持更大 batch size
• 优化实践：prefix caching（相同 system prompt 的请求共享 KV-cache）、量化（AWQ/GPTQ 4bit）降低显存占用、tensor parallel 多卡并行
• 运维：动态 batch size 调整、请求队列管理、GPU 利用率监控、OOM 防护

• Streaming 输出但延迟超标，如何折中设计？

参考答案：

• 分段策略：首包快速返回（如先输出"正在处理..."），后续内容 streaming 输出，用户感知延迟降低
• 预生成：对高频请求缓存模板化回复的前半段，边输出边生成后半段
• 超时兜底：设定首 token 超时（如 3s），超时后返回预设的等待提示或降级回复
• 并行处理：工具调用和 LLM 生成并行，工具结果回来后再 streaming 补充
• 模型选择：简单任务路由到小模型（低延迟），复杂任务用大模型；first token latency 作为核心监控指标
• 客户端优化：前端做打字机效果 + 骨架屏，掩盖实际等待时间

MCP 与工具

• 写一个 MCP Server 的流程

参考答案：

• MCP（Model Context Protocol）是标准化的模型-工具通信协议，Server 端暴露 tools/resources/prompts 供 LLM 调用
• 流程：定义工具 Schema（name、description、inputSchema JSON Schema）→ 实现工具 handler 逻辑 → 注册到 MCP Server → 选择传输方式（stdio/SSE/HTTP）
• Python 实现：使用 FastMCP 框架，@mcp.tool() 装饰器定义工具，自动生成 Schema
• 关键设计：工具描述要对 LLM 友好（清晰说明用途、参数含义、返回格式）；参数用 JSON Schema 严格约束类型和范围
• 错误处理：工具内部异常需捕获并返回结构化错误信息（而非让 Server crash）
• 测试：用 MCP Inspector 工具调试，验证 Schema 正确性和工具执行结果

• Skill vs Function Call vs MCP 对比，Skill 有哪些特性？

参考答案：

• Function Call：LLM 原生支持的工具调用机制，与模型深度集成，格式由模型厂商定义（如 OpenAI function calling），耦合度高
• MCP：标准化协议，解耦模型和工具，一个 MCP Server 可被任意支持 MCP 的 client 调用，生态通用性强
• Skill：更高层抽象，通常包含 Prompt 模板 + 工具组合 + 执行逻辑，是"能力单元"而非单个工具；可包含多步骤编排
• Skill 特性：自带上下文说明（SKILL.md）、可组合复用、支持参数化配置、可独立版本管理和分发
• 选型建议：简单单步工具用 Function Call/MCP，复杂多步能力封装成 Skill；MCP 适合跨平台工具生态

• MCP 和 Skill 哪个上下文占用大？如何写好一个工具？

参考答案：

• Skill 上下文占用通常更大：包含 SKILL.md 说明文档、多个工具描述、示例等，可能占用数千 token；MCP 单个工具 Schema 相对精简
• 控制上下文：工具描述精简但完整（一句话说明用途 + 参数说明），避免冗余示例；Skill 的说明按需加载而非全量注入
• 写好工具的原则：①命名直观（search_user 优于 func_1）②description 写给 LLM 看（说明何时该用/不该用）③参数有 enum 约束的务必声明 ④返回值结构化且包含足够信息供 LLM 继续推理
• 错误返回：工具失败时返回明确的错误原因（而非空或通用错误），帮助 LLM 做下一步决策
• 粒度把控：一个工具做一件事，避免"万能工具"导致 LLM 选择困难

数据与训练

• 训练数据来自用户行为日志，如何抽取训练对话？归一化或事件抽象？

参考答案：

• 日志清洗：从原始行为日志（点击/搜索/操作序列）中提取有意义的用户意图序列，过滤噪声（误触、重复操作）
• 对话构造：将用户行为序列转化为 instruction-response 格式——行为作为隐含意图，系统响应作为期望输出
• 事件抽象：将具体操作归一化为语义事件（如"点击商品A→查看详情→加入购物车"抽象为"用户有购买意向"），减少稀疏性
• 时间窗口切分：按 session（30min 无活动切分）划分对话边界，避免跨 session 拼接
• 标注策略：自动构造 + 人工抽样校验，确保训练数据质量；对高价值场景（转化/留存相关）加权采样
• 隐私脱敏：用户 ID、手机号等 PII 信息 hash 或移除，符合数据合规要求

• 模型如何"理解时间"？带时间窗口的对话系统？

参考答案：

• 时间注入：在 system prompt 或每轮 user message 中注入当前时间戳（"当前时间：2024-03-15 14:30 CST"），让模型有时间感知
• 相对时间解析：用户说"昨天""下周一"时，需在 Prompt 或预处理层将相对时间转为绝对时间
• 时间窗口对话：对话历史按时间衰减加权——近期对话保留原文，早期对话做摘要压缩
• 时间相关记忆：长期记忆存储时附带时间戳，检索时按时间相关性加权排序（如"上次开会"优先匹配最近的会议记录）
• 定时任务场景：Agent 需理解"每天早上9点提醒我"这类时间表达，转化为 cron 表达式或定时触发器
• 训练数据：微调时在样本中加入时间上下文，让模型学会基于时间做不同响应

后端基础

• Java 线程生命周期，线程池参数选择

参考答案：

• 线程生命周期：New → Runnable → Running → Blocked/Waiting/Timed_Waiting → Terminated
• 核心参数：corePoolSize（常驻线程数）、maximumPoolSize（最大线程数）、keepAliveTime（空闲线程存活时间）、workQueue（任务队列）、rejectedHandler（拒绝策略）
• CPU 密集型任务：corePoolSize = CPU 核数 + 1，队列用有界队列
• IO 密集型任务：corePoolSize = CPU 核数 * 2（或根据 IO 等待比例计算），队列可适当加大
• Agent 场景：LLM 调用是典型 IO 密集型，线程池应配置较多线程；外部工具调用需独立线程池隔离，避免慢接口拖垮整体
• 拒绝策略：生产环境常用 CallerRunsPolicy（调用者线程执行）或自定义策略（记录日志+降级）

• G1/CMS 垃圾回收器参数配置

参考答案：

• CMS：低延迟优先，适合响应敏感的 Agent 服务；核心参数 -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75；缺点是内存碎片化和 concurrent mode failure
• G1：JDK9+ 默认，兼顾吞吐和延迟；核心参数 -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:G1HeapRegionSize=8m
• G1 优势：可预测的停顿时间、自动 region 管理、大堆（>4G）表现好
• Agent 服务调优：MaxGCPauseMillis 设为 100-200ms（对话服务对延迟敏感）；堆大小根据并发会话数设定
• 监控：关注 GC 频率、STW 时间、老年代占用；接入 Prometheus + Grafana 可视化
• JDK17+：考虑 ZGC（亚毫秒停顿），适合极致延迟要求的实时 Agent 服务

• CPU 使用率过高如何排查

参考答案：

• 第一步：top -Hp 找到 CPU 占用最高的线程 ID，转为十六进制
• 第二步：jstack 导出线程快照，搜索对应线程的堆栈，定位代码位置
• 常见原因：死循环、正则回溯（ReDoS）、频繁 Full GC（jstat -gc 确认）、大量线程竞争锁（BLOCKED 状态线程多）
• Agent 场景特有：JSON 解析大量 LLM 响应、频繁序列化/反序列化、embedding 计算未 offload 到 GPU
• 工具链：Arthas（在线诊断）、async-profiler（火焰图）、perf（系统级分析）
• 预防：关键路径做 CPU profile 基线，上线后对比；设 CPU 使用率告警阈值（如 80%）

• TCP 滑动窗口协议原理

参考答案：

• 核心目的：流量控制——发送方不能发超过接收方处理能力的数据量
• 机制：接收方在 ACK 中携带 window size（rwnd），告知发送方当前可接收的字节数；发送方据此控制发送速率
• 滑动窗口：发送窗口随 ACK 确认向前滑动，已确认数据移出窗口，新数据进入窗口可发送
• 拥塞控制：除了 rwnd，还有 cwnd（拥塞窗口），实际发送窗口 = min(rwnd, cwnd)；慢启动 → 拥塞避免 → 快重传/快恢复
• Agent 服务相关：长连接 Streaming 场景下，TCP 窗口大小影响首 token 延迟；高并发时需调优内核参数（tcp_wmem/tcp_rmem）

• MySQL 索引数据结构，联合索引，索引失效场景

参考答案：

• 数据结构：InnoDB 用 B+ 树，叶子节点存数据（聚簇索引）或主键值（二级索引）；B+ 树高度通常 3-4 层，亿级数据也只需 3-4 次 IO
• 联合索引：遵循最左前缀原则，索引 (a,b,c) 可用于查询 a、(a,b)、(a,b,c)，但不能跳过 a 直接用 b
• 索引失效场景：①对索引列做函数运算（WHERE YEAR(create_time)=2024）②隐式类型转换（varchar 列用 int 查询）③LIKE '%xxx'（前缀模糊）④OR 连接非索引列 ⑤NOT IN / != 某些情况 ⑥数据量小时优化器选择全表扫描
• Agent 场景：对话历史表按 (user_id, session_id, created_at) 建联合索引；向量检索走专用向量数据库而非 MySQL
• 优化：EXPLAIN 分析执行计划，关注 type（至少 ref 级别）、rows、Extra（避免 Using filesort/temporary）

面试洞察

• 蚂蚁是目前 Agent 面试问得最细的公司之一
• Prompt 工程、工具容错、并发管理是三大核心考点
• 会问你 MCP Server 怎么写——要有实操经验
• DPO/vLLM/KV-cache 等偏底层的优化也会考

华为 AI Agent - 面试题 & 面经

面试特点

• 流程最规范：机试→性格测试→技术一面→技术二面→资格面→HR 面
• 2025 年机考改革：20 道选择题（AI+数学）+ 2 道编程题
• 选择题涉及 LSTM、HMM、决策树、矩阵运算等传统 ML 内容
• 有"青云计划"等 AI 人才专项

真实面试题

AI Agent 相关

• 传统知识图谱建设和大模型对知识构建的差异及趋势

参考答案：

• 传统知识图谱：人工定义 Schema → 实体抽取 → 关系抽取 → 图数据库存储，结构化强但构建成本极高
• 大模型方式：LLM 隐式编码了海量知识，可通过 Prompt 直接问答，无需显式构建图谱
• 差异核心：知识图谱是"显式、可解释、可审计"的结构化知识；LLM 是"隐式、概率性、可能幻觉"的参数化知识
• 融合趋势：用 LLM 辅助知识图谱构建（自动抽取实体关系），用知识图谱增强 LLM（GraphRAG，减少幻觉）
• 华为场景：电信网络故障诊断知识库，传统图谱保障准确性 + LLM 提供自然语言交互
• 未来方向：知识图谱作为 LLM 的外挂"事实数据库"，两者互补而非替代

• 实习中的提示工程和 SFT 具体工作

参考答案：

• Prompt Engineering：设计系统提示词模板，包括角色设定、输出格式约束、Few-shot 示例
• 迭代优化：通过 A/B 测试不同 Prompt 版本，用评测指标（准确率/相关性/安全性）量化效果
• SFT 数据准备：从业务日志中挖掘高质量 QA 对，人工标注 + 清洗，构建指令微调数据集
• SFT 训练：使用 LoRA/QLoRA 在基座模型上微调，降低显存需求；关注 loss 曲线和过拟合
• 评估方法：自动评测（BLEU/ROUGE）+ 人工评测（相关性/流畅性/安全性打分）
• 工程化：Prompt 版本管理、模型版本管理、AB 实验平台搭建

• AI 发展历史流程和相关算法引进

参考答案：

• 1950s-80s：符号 AI（专家系统、逻辑推理），知识工程瓶颈
• 1990s-2000s：统计学习兴起，SVM、随机森林、HMM 语音识别
• 2012：AlexNet 引爆深度学习，CNN 在图像识别上超越人类
• 2017：Google 发表 Transformer（Attention Is All You Need），革命性架构
• 2018-2020：BERT（编码器）、GPT 系列（解码器），预训练+微调范式
• 2022-至今：ChatGPT 引爆大模型应用，Agent/RAG/多模态成为热点
• 关键趋势：从规则→统计→深度学习→大模型→Agent 自主决策

• 为什么不用传统 Workflow？LLM 模糊推理 vs 硬编码逻辑的界限在哪？

参考答案：

• 传统 Workflow 局限：需要穷举所有分支，无法处理模糊意图、开放域问题和长尾 case
• LLM 优势：语义理解、模糊推理、泛化能力强，能处理自然语言描述的非结构化需求
• 适合用 Agent 的场景：用户意图模糊、步骤不确定、需要动态决策和多轮交互
• 适合用 Workflow 的场景：流程固定、对确定性要求高（如金融交易、合规审批）、延迟敏感
• 最佳实践：混合架构——用 LLM 做意图理解和路由，确定性步骤走硬编码 Workflow
• 界限判断标准：如果能用 if-else 写清楚且维护成本可控，就用 Workflow；否则用 Agent
• 成本考量：LLM 调用有 token 成本和延迟，高 QPS 确定性任务不应全走 LLM

• 上下文管理在海量并发下的成本控制

参考答案：

• 核心矛盾：长上下文 = 更多 token = 更高成本 + 更高延迟
• 上下文窗口裁剪：只保留最近 N 轮对话 + 系统 Prompt，历史对话做摘要压缩
• 分级存储：热上下文在内存/Redis，温上下文在数据库，冷上下文归档
• 共享前缀优化：多用户共享相同系统 Prompt 时，利用 Prefix Caching 减少重复计算
• 并发控制：令牌桶限流 + 队列排队，防止瞬时并发打爆 GPU
• 模型选择：简单任务用小模型（成本低 10x），复杂任务才路由到大模型
• 监控：实时跟踪每请求 token 数、P99 延迟、GPU 利用率，设置成本预算告警

• KV Cache 复用逻辑

参考答案：

• KV Cache 原理：Transformer 自回归生成时，缓存已计算的 Key/Value 矩阵，避免重复计算
• 复用场景一：多轮对话中，前几轮的 KV Cache 可直接复用，只计算新增 token
• 复用场景二：Prefix Caching——相同系统 Prompt 的不同请求共享前缀的 KV Cache
• 实现方式：vLLM 的 PagedAttention，将 KV Cache 分页管理，类似操作系统虚拟内存
• 显存优化：KV Cache 是推理时显存的主要消耗，分页可减少碎片，提升批处理吞吐
• 淘汰策略：LRU 淘汰不活跃会话的 KV Cache，释放显存给新请求
• 量化压缩：对 KV Cache 做 INT8/FP8 量化，降低显存占用

• 语义分析剔除冗余上下文

参考答案：

• 目标：在不丢失关键信息的前提下，压缩上下文长度以降低 token 消耗
• 方法一：摘要压缩——用小模型对历史对话生成摘要，替换原始内容
• 方法二：相关性过滤——用 Embedding 相似度计算，只保留与当前 query 相关的历史片段
• 方法三：滑动窗口——保留最近 K 轮完整对话 + 更早轮次的摘要
• 方法四：实体/关键词提取——从历史中提取关键实体和事实，构建结构化记忆
• 评估指标：压缩后的回答质量（对比原始上下文）不应显著下降
• 工程实现：异步做上下文压缩，不阻塞主请求链路

• 多级缓存记忆设计

参考答案：

• L1 短期记忆：当前会话上下文，存在内存中，生命周期 = 会话时长
• L2 工作记忆：最近几次会话摘要 + 用户偏好，存在 Redis 中，TTL 数小时到数天
• L3 长期记忆：用户画像、历史交互摘要、重要决策记录，存在向量数据库 + 关系数据库中
• 读取策略：每次请求拼接 L1 全量 + L2 摘要 + L3 中与当前 query 相关的 Top-K 片段
• 写入策略：会话结束时异步提取关键信息写入 L2/L3，避免阻塞
• 容量控制：每级设容量上限，超限触发摘要压缩或淘汰
• 类比：类似 CPU 缓存（L1/L2/L3），越近速度越快、容量越小、命中率越高

• RAG 中模型发现检索内容与自身知识冲突时怎么处理？

参考答案：

• 默认策略：Prompt 中明确指示"以检索到的文档内容为准，不要依赖自身知识"
• 置信度对比：让模型输出对检索内容和自身知识的置信度，取高者或标注冲突
• 来源标注：要求模型回答时标注信息来源（"根据文档 X"），方便用户验证
• 检索质量保障：冲突往往源于检索到不相关文档，提升检索精度（Re-rank、精调 Embedding）是根本
• 时效性判断：如果检索内容有明确时间戳且更新，优先信任检索内容
• 兜底方案：当冲突无法自动解决时，返回两种说法并提示用户"存在信息冲突，建议人工确认"
• 知识库维护：定期更新知识库，删除过时内容，减少冲突发生概率

机考选择题方向

• LSTM 相关

参考答案：

• LSTM（长短期记忆网络）是 RNN 的改进版，解决了长序列中的梯度消失问题
• 三个门机制：遗忘门（决定丢弃哪些信息）、输入门（决定存入哪些新信息）、输出门（决定输出哪些信息）
• 核心是 Cell State（细胞状态），信息沿其线性流动，门控决定增删
• 与 GRU 对比：GRU 只有两个门（重置门、更新门），参数更少，效果相近
• 应用场景：时序预测、语音识别、NLP（已被 Transformer 大幅取代）
• 考试重点：门的 Sigmoid 激活函数作用、梯度如何通过 Cell State 传播

• 最大熵模型

参考答案：

• 核心思想：在满足已知约束条件下，选择熵最大（最均匀/最不确定）的概率分布
• 数学形式：$P^* = \arg\max_{P} H(P)$，subject to 特征函数的期望约束
• 与逻辑回归的关系：最大熵模型的对偶形式等价于多分类逻辑回归（Softmax 回归）
• 特征函数：$f(x, y)$ 描述输入 x 和类别 y 的某种关联，约束条件是经验期望 = 模型期望
• 优化方法：拉格朗日乘子法 → 对偶问题 → GIS/IIS/L-BFGS 迭代求解
• 优点：不需要独立性假设（对比朴素贝叶斯），表达能力强

• 隐马尔可夫模型

参考答案：

• HMM 三要素：初始状态概率 π、状态转移矩阵 A、观测概率矩阵 B
• 三个基本问题：评估问题（前向算法）、解码问题（Viterbi 算法）、学习问题（Baum-Welch/EM）
• 两个假设：齐次马尔可夫假设（当前状态只依赖前一状态）、观测独立假设（观测只依赖当前状态）
• 典型应用：语音识别、词性标注、中文分词、基因序列分析
• Viterbi 算法：动态规划求最优状态序列，时间复杂度 O(T×N²)，T 为序列长度，N 为状态数
• 局限：假设过强，无法建模长距离依赖；已被 CRF 和深度学习方法取代

• 决策树

参考答案：

• 核心算法：ID3（信息增益）、C4.5（信息增益比）、CART（基尼系数/MSE）
• 信息增益偏向多值特征（如 ID 字段），信息增益比做了修正
• 基尼系数：$Gini = 1 - \sum p_i^2$，值越小纯度越高
• 剪枝策略：预剪枝（限制深度/叶子节点数）、后剪枝（先生成完整树再自底向上剪）
• 集成方法：Random Forest（Bagging + 特征随机）、GBDT/XGBoost（Boosting）
• 优点：可解释性强、不需要特征缩放；缺点：容易过拟合（需剪枝或集成）

• 线性变换与矩阵运算

参考答案：

• 线性变换满足：$T(αu + βv) = αT(u) + βT(v)$，可用矩阵乘法表示
• 常见变换：旋转（正交矩阵）、缩放（对角矩阵）、投影（幂等矩阵）、反射
• 特征值分解：$Av = λv$，特征值描述变换的缩放因子，特征向量描述不变方向
• 在 AI 中的应用：PCA 降维（协方差矩阵特征分解）、SVD 推荐系统、Attention 中的矩阵乘法
• 矩阵运算复杂度：矩阵乘法 O(n³)，Strassen 算法 O(n^2.807)
• 考试重点：矩阵的秩、行列式、逆矩阵、特征值计算

• 过拟合/欠拟合判断

参考答案：

• 过拟合：训练集表现好、验证/测试集表现差，模型过于复杂，记住了噪声
• 欠拟合：训练集和测试集表现都差，模型过于简单，无法捕捉数据规律
• 判断方法：画学习曲线（横轴训练量，纵轴误差），观察训练误差和验证误差的 gap
• 解决过拟合：正则化（L1/L2）、Dropout、数据增强、早停（Early Stopping）、减小模型复杂度
• 解决欠拟合：增加模型复杂度、增加特征、减少正则化强度、训练更久
• Bias-Variance 权衡：欠拟合 = 高偏差，过拟合 = 高方差

• 特征标准化

参考答案：

• Min-Max 归一化：$x' = (x - x_{min}) / (x_{max} - x_{min})$，缩放到 [0,1]，对异常值敏感
• Z-Score 标准化：$x' = (x - μ) / σ$，均值为 0 方差为 1，最常用
• 为什么需要标准化：避免数值范围大的特征主导距离计算和梯度下降
• 必须标准化的算法：SVM、KNN、逻辑回归、神经网络（梯度下降类）
• 不需要标准化的算法：决策树、Random Forest（基于信息增益/基尼系数，与数值范围无关）
• 注意：用训练集的 μ 和 σ 去标准化测试集，防止数据泄露

• 向量组线性相关性

参考答案：

• 定义：存在不全为零的系数 $k_1, k_2, ..., k_n$ 使得 $k_1v_1 + k_2v_2 + ... + k_nv_n = 0$
• 判断方法：将向量组成矩阵，求秩；若秩 < 向量个数则线性相关
• 等价条件：行列式为零 ⟺ 存在特征值为零 ⟺ 矩阵不可逆 ⟺ 线性相关
• 几何意义：线性相关意味着某些向量可以被其他向量线性表示，存在"冗余"维度
• 在 ML 中的意义：特征线性相关导致多重共线性，影响回归系数稳定性；需要 PCA 或正则化处理
• 考试技巧：n 个 n 维向量，算行列式即可判断

后端基础

• Redis 为什么是单线程？

参考答案：

• 核心操作单线程：Redis 的命令执行在单线程中完成，避免了锁竞争和上下文切换的开销
• 为什么够快：数据全在内存（微秒级）、IO 多路复用（epoll）处理大量并发连接、数据结构高效（跳表/哈希表）
• 瓶颈不在 CPU：Redis 的瓶颈在网络 IO 和内存，不在 CPU 计算，单线程足以打满网络带宽
• Redis 6.0 引入多线程：仅用于网络 IO 的读写（读取请求/发送响应），命令执行仍是单线程
• 优势：代码简单、无需加锁、原子性操作天然保证、避免死锁
• 注意：耗时命令（如 KEYS *、大 Key 删除）会阻塞整个服务，生产环境要避免

• 拓扑排序（课程表问题）

参考答案：

• 问题描述：给定课程依赖关系（有向图），判断能否完成所有课程（是否有环）并给出学习顺序
• BFS 解法（Kahn 算法）：计算每个节点入度 → 入度为 0 的入队 → 依次出队并将邻居入度 -1 → 新入度为 0 的入队 → 最终判断是否所有节点都被处理
• DFS 解法：对每个节点 DFS，用三色标记（未访问/访问中/已完成），访问中再次遇到说明有环
• 时间复杂度：O(V + E)，V 为节点数，E 为边数
• 应用场景：任务调度、编译依赖、包管理（Maven/npm）
• 变体题：输出所有合法拓扑序（回溯法）、求最短完成时间（关键路径）

• Transformer 架构核心组件

参考答案：

• Self-Attention：$Attention(Q,K,V) = softmax(\frac{QK^T}{\sqrt{d_k}})V$，捕捉序列内任意位置的依赖关系
• Multi-Head Attention：多组 Q/K/V 投影并行计算，捕捉不同子空间的模式
• 位置编码（Positional Encoding）：Sinusoidal 或可学习位置嵌入，弥补 Attention 缺乏位置感知的问题
• Feed-Forward Network：两层全连接 + ReLU/GELU，逐位置独立变换，增加非线性表达能力
• Layer Normalization + 残差连接：稳定训练、缓解梯度消失
• Encoder-Decoder 结构：Encoder 双向 Attention（BERT），Decoder 带 Causal Mask 的单向 Attention（GPT）
• 对比 RNN：并行计算（训练快）、长距离依赖建模能力强、但推理时自回归仍是串行的

• 向量数据库分段检索策略（Hybrid Search）

参考答案：

• 纯向量检索：用 Embedding 做 ANN（近似最近邻）搜索，擅长语义相似，但对精确关键词匹配弱
• 纯关键词检索：BM25/TF-IDF，擅长精确匹配，但无法理解同义词和语义
• Hybrid Search：结合向量检索 + 关键词检索，取两者优势
• 融合策略：RRF（Reciprocal Rank Fusion）——对两路结果按排名倒数加权合并，简单有效
• 分段策略：文档切分为 chunk（256-512 token），每个 chunk 独立做 Embedding 和索引
• 切分技巧：按语义段落切分 > 固定长度切分；chunk 间保留重叠（overlap 50-100 token）防止信息截断
• Re-rank：检索后用 Cross-Encoder 重排序 Top-K 结果，提升最终精度
• 主流工具：Milvus、Weaviate、Qdrant 均支持 Hybrid Search

面试洞察

• 华为面试最注重流程和规范，每轮都有明确考察目标
• 选择题会考传统 ML（LSTM/HMM/决策树），不能只准备 LLM
• 核心问题："为什么用 Agent 而不是传统 Workflow"——要有深度思考
• Agent 面试已经过了"比谁会写 Prompt"的阶段

Agent 核心概念与设计模式面试题

一、Agent 核心概念

什么是 AI Agent？

AI Agent 是能够感知环境、推理决策、制定计划、执行行动的自主 AI 系统。与传统 LLM 应用的区别：

• 传统 LLM：输入→输出，单次调用，无状态，确定性流程
• AI Agent：感知→推理→规划→执行→观察→循环，多步自主决策，有状态，动态流程

核心差异在于自主性和闭环反馈。传统 LLM 应用是开发者预定义的流水线（如 RAG：检索→拼接→生成），每一步由代码控制；Agent 则由 LLM 自己决定下一步做什么，形成"感知-推理-行动-反思"的自主循环，能根据中间结果动态调整策略。

Agent 四大核心能力

1. 感知（Perception）：接收用户输入、环境反馈、工具返回结果、系统事件通知
2. 推理（Reasoning）：分析当前状况，做出判断，包括意图理解、信息综合、因果推断
3. 规划（Planning）：制定多步行动计划，包括任务分解、优先级排序、资源分配
4. 行动（Action）：调用工具、生成输出、与环境交互、修改状态

Agent Loop（感知-推理-行动-反思循环）

Agent 的核心运行机制是一个持续的循环，也称 Agent Loop 或 Cognitive Loop：

┌─────────────────────────────────────────┐
│              Agent Loop                 │
│                                         │
│   感知(Perceive) → 推理(Reason)         │
│        ↑              ↓                 │
│   反思(Reflect) ← 行动(Act)            │
│                                         │
└─────────────────────────────────────────┘

详细步骤：

1. 感知：收集输入信息（用户消息、工具返回、环境状态）
2. 推理：LLM 分析所有可用信息，理解当前状态与目标的差距
3. 规划/决策：决定下一步行动——调用工具、回复用户、或终止
4. 行动：执行决策（调用 API、运行代码、生成文本）
5. 观察：接收行动结果
6. 反思：评估结果是否满足目标，是否需要调整策略
7. 循环或终止：未完成则回到步骤1，完成则输出最终结果

伪代码：

def agent_loop(task, max_steps=20):
    context = initialize_context(task)
    for step in range(max_steps):
        # 感知 + 推理 + 决策
        action = llm.decide(context)
        if action.type == "finish":
            return action.output
        # 行动
        observation = execute(action)
        # 反思（可选）
        reflection = llm.reflect(context, action, observation)
        # 更新上下文
        context.append(action, observation, reflection)
    return "达到最大步数，任务未完成"

关键设计考量：

• 终止条件：必须有明确的退出机制（max_steps、目标达成判断、用户中断）
• 上下文膨胀：每轮循环增加 token，需要策略控制（摘要压缩、滑动窗口）
• 错误累积：多步推理中早期错误会放大，需要纠错机制

记忆系统

记忆分类与实现

具体实现方案

短期记忆 — Context Window 管理：

• 直接将对话历史放入 prompt
• 当 token 超限时使用滑动窗口（保留最近 N 轮）或摘要压缩（LLM 总结历史）
• 策略：保留系统提示 + 最近 K 轮原文 + 更早内容的摘要

长期记忆 — 向量数据库方案：

# 存储：将对话/经验嵌入为向量
embedding = embed_model.encode(memory_text)
vector_db.upsert(id=memory_id, vector=embedding, metadata={
    "timestamp": now, "type": "episode", "importance": score
})

# 检索：根据当前查询找到相关记忆
relevant = vector_db.query(
    vector=embed_model.encode(current_query),
    top_k=5,
    filter={"timestamp": {"$gt": cutoff_time}}
)

• 推荐数据库：Chroma（轻量）、Pinecone（托管）、Qdrant（自部署）、Weaviate
• 嵌入模型：text-embedding-3-small/large、BGE、E5

长期记忆 — 文件系统方案：

• Markdown 文件存储结构化笔记（如 MEMORY.md）
• 适合规模较小、人类可读的场景
• 优点：简单、可编辑、版本控制友好；缺点：检索能力弱

工作记忆 — Redis / 内存方案：

• 任务执行过程中的中间状态、变量、子任务结果
• Redis 适合多 Agent 共享状态；内存适合单 Agent 单任务

记忆检索策略

1. 相似度检索：基于语义相似度（余弦距离）找最相关记忆
2. 时间衰减：近期记忆权重更高，score = similarity × decay(time)
3. 重要性加权：关键事件（用户偏好、纠错经验）赋予高权重
4. 混合检索：结合语义检索 + 关键词检索（BM25）+ 时间衰减

def retrieve_memory(query, memories):
    scores = []
    for m in memories:
        sim = cosine_similarity(embed(query), m.embedding)
        recency = decay_factor(now() - m.timestamp)  # 指数衰减
        importance = m.importance_score  # 0-1
        final_score = sim * 0.5 + recency * 0.3 + importance * 0.2
        scores.append((m, final_score))
    return sorted(scores, key=lambda x: -x[1])[:top_k]

记忆衰减和清理

• 指数衰减：weight = e^(-λt)，λ 控制衰减速率
• 访问频率：被频繁访问的记忆权重提升（类似缓存 LRU）
• 定期清理：后台任务删除过期/低分记忆，防止存储膨胀
• 摘要合并：将多条旧记忆合并为一条摘要记忆，保留核心信息
• 分层存储：热数据（内存/Redis）→ 温数据（向量库）→ 冷数据（归档/删除）

工具使用（Tool Use）

Function Calling vs Tool Use 的区别

Function Calling 是 Tool Use 的一种具体实现方式。OpenAI 的 FC 由模型原生支持，输出结构化的 function_name + arguments JSON；而 Tool Use 是更广泛的模式——Agent 也可以通过在文本中输出特定格式（如 Action: search\nAction Input: query）来调用工具。

工具描述的最佳实践

好的工具描述直接影响 Agent 选择正确工具的概率：

# ❌ 差的描述
{"name": "search", "description": "搜索"}

# ✅ 好的描述
{
    "name": "web_search",
    "description": "在互联网上搜索实时信息。适用于需要最新数据（新闻、价格、天气）或你知识库中没有的事实。不适用于：已知的常识问题、数学计算、代码生成。",
    "parameters": {
        "query": {
            "type": "string",
            "description": "搜索查询词，应具体且信息丰富，如'2024年诺贝尔物理学奖获得者'而非'诺贝尔奖'"
        }
    }
}

原则：

1. 说明适用场景和不适用场景，帮助 LLM 判断何时使用
2. 参数描述包含格式示例
3. 说明返回值的格式和含义
4. 工具数量控制在 10-20 个以内，过多会降低选择准确率

多工具编排策略

1. 顺序调用：工具 A 的输出是工具 B 的输入（pipeline）
2. 并行调用：多个独立工具同时执行（OpenAI parallel_tool_calls）
3. 条件调用：根据上一步结果决定下一步调用哪个工具
4. 迭代调用：反复调用同一工具直到满足条件（如搜索→判断→再搜索）
5. 工具组合：将常用工具序列封装为高级工具（减少 Agent 决策步骤）

二、Agent 设计模式

1. ReAct（Reasoning + Acting）

最经典的 Agent 模式，将推理和行动交织在一起。

工作流程：

1. Thought：分析当前状态，思考下一步该做什么
2. Action：决定调用哪个工具，用什么参数
3. Observation：接收工具执行结果
4. 重复 1-3，直到能给出最终答案

伪代码：

def react_agent(question, tools, max_iters=10):
    prompt = f"Answer: {question}\nYou have tools: {tools}"
    history = []
    for i in range(max_iters):
        response = llm.generate(prompt + format(history))
        if response.has_final_answer:
            return response.answer
        # 解析 Thought + Action
        thought, action, action_input = parse(response)
        observation = execute_tool(action, action_input)
        history.append((thought, action, action_input, observation))
    return "无法得出答案"

适用场景：

• 需要多步推理 + 信息检索的问答
• 问题不确定需要几步，需要动态探索
• 中等复杂度任务

不适用场景：

• 任务非常简单（一步完成，ReAct 过重）
• 任务极端复杂，需要全局规划后再执行
• 需要并行执行多个子任务

优缺点：

2. Plan-and-Execute

先制定完整计划，再逐步执行。将规划和执行分离。

工作流程：

1. Planner 接收任务，生成有序步骤列表
2. Executor 按顺序执行每个步骤
3. 每步执行完毕后，可选地让 Replanner 根据中间结果调整后续计划
4. 所有步骤完成后汇总输出

伪代码：

def plan_and_execute(task, tools):
    # Phase 1: 规划
    plan = planner_llm.generate(f"为以下任务制定步骤计划：{task}")
    steps = parse_plan(plan)  # ["步骤1: ...", "步骤2: ...", ...]
    
    results = []
    for i, step in enumerate(steps):
        # Phase 2: 执行（每步可以是一个 ReAct 子循环）
        result = executor.run(step, context=results)
        results.append(result)
        
        # Phase 3: 可选 - 重新规划
        remaining = steps[i+1:]
        revised = replanner_llm.generate(
            f"已完成：{results}\n原计划剩余：{remaining}\n是否需要调整？"
        )
        if revised.changed:
            steps = steps[:i+1] + revised.new_steps
    
    return synthesize(results)

适用场景：

• 复杂多步任务（写研究报告、项目管理）
• 任务结构较明确，可以预先分解
• 需要可见的进度跟踪

不适用场景：

• 高度不确定的探索性任务（无法预先规划）
• 简单的单步任务
• 实时交互场景（规划阶段延迟高）

优缺点：

3. Reflection / Self-Critique

Agent 生成输出后自我评估，不满意则迭代改进。

工作流程：

1. Agent 生成初始输出
2. Critic（可以是同一个 LLM 或专门的评估 LLM）评估输出质量
3. 如果不满意，生成改进建议
4. Agent 根据反馈修改输出
5. 重复 2-4 直到满意或达到最大迭代次数

伪代码：

def reflection_agent(task, max_rounds=3):
    output = generator_llm.generate(task)
    for round in range(max_rounds):
        critique = critic_llm.evaluate(
            task=task, output=output,
            criteria=["准确性", "完整性", "逻辑性"]
        )
        if critique.is_satisfactory:
            return output
        output = generator_llm.revise(
            task=task, 
            previous_output=output,
            feedback=critique.suggestions
        )
    return output  # 返回最后一版

适用场景：

• 内容生成（文章、代码、报告）需要高质量输出
• 有明确评估标准的任务
• 对正确性要求高（如数学证明、法律文书）

不适用场景：

• 实时性要求高的场景（多轮反思增加延迟）
• 任务本身没有明确的好坏标准
• 简单事实查询

优缺点：

4. Tool-Use Pattern

Agent 动态选择和调用工具完成子任务。这是所有 Agent 的基础能力，常与其他模式组合使用。

工作流程：

1. 接收任务描述
2. LLM 根据任务和可用工具列表，决定是否需要调用工具
3. 如果需要，生成工具名和参数
4. 执行工具调用，获取结果
5. LLM 根据工具结果决定下一步（继续调用工具 or 输出答案）

适用场景： 几乎所有需要与外部系统交互的任务

关键挑战： 工具选择准确率、参数生成正确性、工具调用失败处理

5. Multi-Agent Patterns

Supervisor 模式

         ┌─────────┐
         │Supervisor│
         └────┬────┘
        ┌─────┼─────┐
   ┌────▼─┐┌──▼──┐┌─▼────┐
   │Agent1││Agent2││Agent3│
   └──────┘└─────┘└──────┘

• 主 Agent（Supervisor）接收任务，分配给专业子 Agent
• Supervisor 负责任务分解、结果汇总、质量把控
• 子 Agent 专注于单一领域（搜索、写作、代码等）

伪代码：

def supervisor_agent(task, sub_agents):
    plan = supervisor_llm.decompose(task)
    results = {}
    for subtask in plan:
        agent = supervisor_llm.assign(subtask, sub_agents)
        result = agent.execute(subtask, context=results)
        results[subtask.id] = result
    return supervisor_llm.synthesize(results)

Debate 模式

• 多个 Agent 对同一问题给出独立答案
• 互相审查和辩论
• 通过多轮辩论收敛到最佳答案
• 适用：需要高准确性、有争议的判断类问题

Pipeline 模式

• Agent 间流水线式传递：Agent1 → Agent2 → Agent3
• 每个 Agent 处理一个阶段（如：研究→写初稿→审校）
• 适用：任务有明确的阶段划分

Peer-to-Peer 模式

• Agent 间平等协作，通过共享状态或消息传递
• 无中心控制节点
• 适用：去中心化、容错性要求高的场景

多 Agent 系统的关键设计问题：

1. 通信机制：共享内存 / 消息队列 / 函数调用
2. 状态管理：全局状态 vs 局部状态
3. 冲突解决：当 Agent 意见冲突时如何决策
4. 成本控制：多 Agent = 多倍 Token 消耗

6. Human-in-the-loop

关键决策点暂停，等待人工审批后继续。

实现方式：

1. 审批门（Approval Gate）：Agent 在执行高风险操作前暂停等待确认
2. 纠正反馈：人类可以在中途修改 Agent 的计划或输出
3. 升级机制：Agent 遇到不确定情况时主动请求人类介入

适用场景：

• 涉及金钱交易、数据修改、外部通信等不可逆操作
• 合规要求高的行业（金融、医疗、法律）
• Agent 置信度低的判断

7. CodeAct 模式

CodeAct 是一种让 Agent 通过生成和执行代码来完成任务的模式，而非通过结构化的工具调用。

核心思想：

• 不预定义工具集，而是让 Agent 直接写 Python（或其他语言）代码
• 代码在沙箱环境中执行，Agent 观察输出后继续

工作流程：

1. Agent 分析任务，生成 Python 代码
2. 代码在安全沙箱中执行
3. Agent 观察执行结果（stdout/stderr）
4. 根据结果继续写代码或给出最终答案

伪代码：

def codeact_agent(task, sandbox):
    history = [{"role": "user", "content": task}]
    while True:
        response = llm.generate(history)
        if response.is_final_answer:
            return response.text
        code = extract_code(response)
        result = sandbox.execute(code)  # 沙箱执行
        history.append({"role": "assistant", "content": response.text})
        history.append({"role": "tool", "content": f"执行结果:\n{result}"})

优点： 灵活性极高，不受预定义工具限制；LLM 天然擅长生成代码

缺点： 安全风险（需要严格沙箱）；代码执行不确定性；调试困难

适用： 数据分析、自动化脚本、开发类任务

不适用： 需要调用特定 API（不如 FC 直接）、安全敏感环境

三、Prompt Engineering 进阶

Chain-of-Thought (CoT)

• 让 LLM 逐步推理，而非直接给答案
• "Let's think step by step"
• 变体：
• Zero-shot CoT：仅加"Let's think step by step"
• Few-shot CoT：提供推理示例
• Tree of Thoughts (ToT)：多条推理路径并行探索，选最优
• Graph of Thoughts (GoT)：推理路径可合并和回溯

上下文工程（Context Engineering）

• 2025 新趋势，比 Prompt Engineering 更广
• 不仅关注 Prompt 本身，还关注提供给 LLM 的整体上下文
• 包括：系统提示、用户输入、检索内容（RAG）、工具返回、历史对话、Agent 记忆
• 核心：在有限 Context Window 内放入最有价值的信息
• 技术手段：信息优先级排序、动态上下文构建、压缩与摘要

结构化输出

• 要求 LLM 以 JSON/YAML 格式输出
• OpenAI Structured Output / JSON Mode / Pydantic + instructor
• 使 Agent 能可靠解析 LLM 输出，减少格式错误
• 关键技术：Schema 约束、重试解析、Guardrails

四、MCP / A2A 等新兴协议

MCP（Model Context Protocol）

• Anthropic 提出的开放协议
• 标准化 LLM 与外部工具/数据源的连接方式
• 类比"AI 的 USB 接口"
• 架构：Server 提供工具/资源/提示，Client（LLM 应用）通过标准协议调用
• 传输：stdio（本地）/ SSE+HTTP（远程）
• 核心价值：一次开发工具，所有支持 MCP 的 Agent 都能用

A2A（Agent-to-Agent）

• Google 提出的 Agent 间通信协议
• 让不同框架/平台的 Agent 可以互相发现、通信和协作
• 基于 Agent Card（描述 Agent 能力）+ Task 协议

ANP（Agent Network Protocol）

• 蚂蚁集团提出的智能体网络协议
• 面向开放网络环境的 Agent 互联，强调身份认证和安全

五、Agent 可靠性工程

重试机制

def reliable_tool_call(tool, args, max_retries=3):
    for attempt in range(max_retries):
        try:
            result = tool.execute(args)
            return result
        except TransientError as e:
            wait = 2 ** attempt  # 指数退避
            sleep(wait)
        except PermanentError as e:
            return fallback(tool, args, error=e)
    return "工具调用失败，已达最大重试次数"

回退策略（Fallback）

1. 工具回退：主工具失败时切换到备用工具（如 Google 搜索 → Bing 搜索）
2. 模型回退：主模型超时/报错时降级到备用模型
3. 策略回退：Agent 循环检测 → 强制切换策略或请求人工介入

超时控制

• 单步执行超时：防止工具调用无限等待
• 总任务超时：防止 Agent 无限循环
• Token 预算超时：达到 Token 上限时强制结束

循环检测

def detect_loop(history, window=5):
    """检测 Agent 是否在重复相同的行动"""
    recent_actions = [h.action for h in history[-window:]]
    if len(set(recent_actions)) <= 2:  # 最近5步只有1-2种不同行动
        return True
    return False

六、Agent 成本控制

Token 预算管理

class TokenBudget:
    def __init__(self, max_tokens=100000):
        self.max_tokens = max_tokens
        self.used_tokens = 0
    
    def can_proceed(self, estimated_cost):
        return self.used_tokens + estimated_cost < self.max_tokens
    
    def record(self, actual_cost):
        self.used_tokens += actual_cost

模型路由（Model Routing）

根据任务复杂度选择不同模型，优化成本：

• 简单任务（分类、提取）→ 小模型（GPT-4o-mini、Claude Haiku）
• 中等任务（一般推理）→ 中等模型（GPT-4o、Claude Sonnet）
• 复杂任务（规划、代码生成）→ 强模型（Claude Opus、o1）

def route_model(task_complexity: str):
    routing = {
        "simple": "gpt-4o-mini",     # $0.15/1M input
        "medium": "gpt-4o",          # $2.5/1M input
        "complex": "claude-opus",     # $15/1M input
    }
    return routing[task_complexity]

其他成本控制策略

1. 缓存：相同/相似查询使用缓存结果（Semantic Cache）
2. 提前终止：置信度足够高时提前返回，不继续迭代
3. 上下文压缩：摘要历史对话，减少输入 token
4. 批量处理：合并多个小请求为一次大请求

七、评估与监控

Agent 评估维度

1. 任务完成率：Agent 能否正确完成目标
2. 步骤效率：完成任务所需步骤数
3. 工具调用准确率：是否选择了正确的工具和参数
4. 幻觉率：输出中不准确信息的比例
5. 延迟：端到端响应时间
6. 成本：Token 消耗和 API 调用费用

评测框架

• RAGAS：RAG 系统评测
• TruLens：LLM 应用评测
• LangSmith：LangChain 生态的追踪和评测平台
• AgentBench：Agent 能力基准测试
• SWE-bench：代码 Agent 评测（解决 GitHub issue）
• GAIA：通用 AI Agent 基准

八、高频面试题

基础概念

1. AI Agent 和传统 LLM 应用的本质区别是什么？

参考答案： 本质区别在于控制流的归属和自主决策能力。传统 LLM 应用（如 RAG 管道）的执行流程由开发者在代码中预定义——检索哪个知识库、怎么拼接 prompt、调用几次模型，都是硬编码的确定性流程，LLM 只负责文本生成这一个环节。而 AI Agent 将控制流交给 LLM 自身——模型根据当前状态决定下一步做什么：是调用搜索工具、执行代码、还是直接回答；是继续探索还是结束任务。Agent 具备感知-推理-行动-反思的闭环能力，能根据中间结果动态调整策略。简单说，传统 LLM 应用是"人设计流程，模型填内容"；Agent 是"人设定目标，模型自己决定怎么达到目标"。当然这也带来了不确定性和可控性的挑战，所以生产环境中 Agent 往往需要配合 guardrails、超时、人工审批等机制。

2. Agent 的记忆系统如何设计？长短期记忆各怎么实现？

参考答案： Agent 的记忆系统模仿人类认知，通常分为四层。短期记忆就是当前对话上下文，直接存在 LLM 的 context window 里，受限于窗口大小（如 128K token），需要滑动窗口或摘要压缩来管理。工作记忆是当前任务的中间状态和临时变量，用 scratchpad 或内存对象存储，任务结束即清除。长期记忆跨会话持久化，主流方案是向量数据库（如 Chroma、Pinecone）存储嵌入向量，检索时用语义相似度匹配；也可用文件系统存 Markdown（简单但检索弱）。情景记忆记录过往成功/失败的经验案例，检索时结合语义相似度 + 时间衰减 + 重要性加权来排序。实际工程中需要考虑记忆清理（过期淘汰、摘要合并）防止存储膨胀，以及分层存储（热数据 Redis → 温数据向量库 → 冷数据归档）优化性能。

3. 什么是 Tool Use / Function Calling？Agent 如何决定用哪个工具？

参考答案： Tool Use 是 Agent 调用外部工具（搜索、API、代码执行等）来获取信息或执行操作的能力。Function Calling（FC）是其最常见的实现方式——开发者向 LLM 提供工具的结构化描述（名称、功能描述、参数 schema），LLM 在推理过程中决定是否调用工具，并输出结构化的调用指令（工具名 + JSON 参数），由 Agent 框架执行后将结果返回给 LLM。Agent 选择工具的关键在于工具描述的质量——描述应明确说明适用场景和不适用场景，参数应有格式示例。LLM 根据当前任务需求和工具描述进行语义匹配来选择。实践中还需注意：工具数量不宜过多（10-20 个为佳），可用工具路由/分类减少候选集；工具调用结果需要做错误处理和格式化，确保 LLM 能正确理解。

4. 解释 ReAct 模式的工作原理

参考答案： ReAct（Reasoning + Acting）将推理和行动交织进行，是最经典的 Agent 设计模式。其工作循环为：Thought（思考当前状况和下一步）→ Action（选择并调用工具）→ Observation（观察工具返回结果）→ 循环直到能给出最终答案。与纯推理（CoT）相比，ReAct 能通过工具获取外部信息，避免幻觉；与纯行动相比，显式的 Thought 步骤让推理过程可解释、可调试。例如回答"2024 年 GDP 最高的城市"：Thought 1: 需要查最新数据 → Action: web_search("2024 GDP 最高城市") → Observation: 搜索结果... → Thought 2: 搜索结果显示是纽约，但需要确认 → Action: web_search("2024 NYC GDP") → Observation: ... → Final Answer。缺点是没有全局规划，可能走弯路或陷入循环，上下文也会随步骤快速膨胀。

5. 单 Agent vs 多 Agent 系统，如何选择？

参考答案： 选择依据主要看任务复杂度、专业性分化程度、并行需求。单 Agent 适合：任务步骤线性可控、不需要多领域专业知识、对延迟敏感、系统简单性优先的场景。优点是架构简单、调试容易、成本可控。多 Agent 适合：任务涉及多个专业领域（如"研究+写作+代码"）、子任务可并行执行、需要交叉检验提高准确性、单个上下文窗口装不下所有信息。多 Agent 模式包括 Supervisor（中心调度）、Pipeline（流水线）、Debate（辩论求最优）、Peer-to-Peer（平等协作）。但多 Agent 的代价是显著的：通信开销、状态同步复杂度、成本倍增（每个 Agent 都消耗 token）、调试难度急剧上升。实践建议：先用单 Agent 解决，确认瓶颈后再拆分为多 Agent，避免过度设计。

设计与架构

6. 如何设计一个 Agent 来完成「自动调研+写报告」的任务？

参考答案： 推荐 Plan-and-Execute + Multi-Agent 组合方案。架构： Supervisor Agent 总控，下设 Research Agent（调研）和 Writer Agent（写作）。流程： 1) Supervisor 接收课题，生成调研提纲（子话题列表）；2) Research Agent 对每个子话题执行 ReAct 循环——搜索、阅读网页、提取关键信息、交叉验证——产出结构化调研笔记；3) Writer Agent 根据调研笔记撰写报告初稿，使用 Reflection 模式自我审查逻辑和引用准确性；4) Supervisor 审查报告质量，不满意则反馈修改意见重做。关键技术点： 搜索工具 + 网页读取工具 + 文件写入工具；调研笔记用结构化格式传递，减少信息损失；对搜索结果做去重和可信度排序；设置 Token 预算防止调研阶段成本失控。

7. 多 Agent 系统中如何处理 Agent 间的通信和状态共享？

参考答案： 主流有三种方式。共享内存/黑板模式：所有 Agent 读写同一个状态对象（如 LangGraph 的 State），简单直接但需要处理并发冲突。消息传递：Agent 间通过消息队列（如 Redis Pub/Sub）通信，解耦性好、支持异步，但增加架构复杂度。函数调用：Supervisor 直接调用子 Agent 的接口并获取返回值，最简单但耦合度高。状态共享的关键挑战：①上下文隔离——每个 Agent 只看自己需要的信息，避免 context 过载；②一致性——多 Agent 并行修改共享状态时需要锁或冲突解决策略；③通信格式——Agent 间传递的信息需要结构化（JSON/Markdown），减少理解歧义。实践中常用 LangGraph 的 StateGraph 或 CrewAI 的 Process 模式来管理。

8. 如何实现 Human-in-the-loop？什么场景需要它？

参考答案： Human-in-the-loop（HITL）在 Agent 执行流程中设置人工检查点。实现方式： 1) 审批门：Agent 在执行高风险操作（发邮件、转账、删除数据）前暂停，展示计划让人确认；2) 置信度触发：当 Agent 对决策的置信度低于阈值时主动请求人工帮助；3) 定期检查：每执行 N 步暂停让人审查进度和方向。技术实现上，可以用异步状态机（Agent 状态持久化到数据库，等待人类回调后恢复），或简单的中断-等待机制。需要 HITL 的场景： 涉及不可逆操作（资金转账、生产环境变更）、合规要求严格的行业（金融、医疗）、Agent 能力边界外的判断（主观决策、伦理问题）、初始上线阶段建立信任。HITL 的关键是平衡效率和安全——太多检查点 Agent 就退化成了工作流工具。

9. Agent 的错误处理和容错机制如何设计？

参考答案： 需要在多个层次设计容错。工具层： 每个工具调用包装重试逻辑（指数退避，最多 3 次）、备用工具回退（搜索引擎 A 失败切换到 B）、超时控制（15-30 秒）。推理层： 循环检测（最近 N 步是否在重复同一行动）、死胡同检测（连续多步无进展则切换策略）、上下文溢出保护（接近 token 上限时压缩历史）。任务层： 总步骤上限（max_steps）、总 token 预算、总时间超时。输出层： 结构化输出解析失败时重试或回退到文本解析、Guardrails 检查输出合规性。兜底策略： 所有自动处理都失败时，优雅降级——向用户说明情况并请求帮助，而非返回错误或幻觉答案。关键原则是失败应该是可预见的、可观测的、可恢复的。

10. 如何控制 Agent 的成本（Token 消耗、API 调用）？

参考答案： 四个维度控制。预算机制： 为每个任务设置 Token 预算上限（如 100K token），每次 LLM 调用后累计消耗，接近上限时强制总结并结束。模型路由： 根据子任务复杂度动态选择模型——简单分类/提取用 mini 模型（成本低 10-50x），复杂规划用强模型。上下文压缩： 定期摘要对话历史减少输入 token；只传递相关工具结果（截断长输出）；使用更短的系统提示。缓存： 对相同或语义相似的查询使用缓存（Semantic Cache），避免重复调用。监控： 实时跟踪每次调用的 token 数和费用，设置告警阈值。实践数据参考：一个复杂 Agent 任务可能消耗 50-200K token，对应 $0.5-$5 不等；多 Agent 系统需要乘以 Agent 数量。

工程实践

11. Agent 在生产环境中有哪些常见问题？

参考答案： ①无限循环： Agent 陷入重复行动，不断调用同一工具或在几个状态间来回跳——需要循环检测 + max_steps + 策略切换。②幻觉： Agent 在无法获取信息时编造事实——需要强制使用搜索工具验证、在 prompt 中强调"不确定时说不知道"。③成本失控： 复杂任务的 token 消耗可能远超预期——需要预算机制和监控告警。④工具调用错误： 参数格式错误、API 超时、权限不足——需要结构化校验 + 重试 + 回退。⑤上下文过载： 长任务导致 context 窗口塞满——需要动态压缩和摘要。⑥不确定性： 同一任务多次执行结果不同——需要温度控制和关键步骤的确定性保障。⑦安全风险： Prompt 注入导致 Agent 执行恶意操作——需要输入过滤、操作白名单、沙箱执行。

12. 如何调试一个复杂的 Agent 工作流？

参考答案： 可观测性优先。 1) Trace/Logging： 使用 LangSmith、Phoenix 等工具记录每一步的输入/输出/延迟/Token 消耗，形成完整的执行链路追踪。2) 中间状态可视化： 将 Agent 每步的 Thought、Action、Observation 完整记录并可视化展示，而非只看最终输出。3) 回放调试： 保存执行历史，支持从任意步骤重新开始（避免每次从头跑）。4) 分层测试： 先测试单个工具是否正常→再测试单步推理→再测试完整流程。5) 对比分析： 对同一任务的成功和失败案例做 diff，定位出问题的步骤。6) Prompt 微调： 根据失败模式针对性调整系统提示或工具描述。7) 评估集： 建立标准测试用例集，每次修改后回归验证。核心难点是 Agent 行为的非确定性，因此需要多次运行取统计结果。

13. 如何评估 Agent 的性能？用什么指标？

参考答案： 评估应覆盖三个层面。效果指标： 任务完成率（最核心）、答案准确率、幻觉率。效率指标： 平均步骤数（越少越好）、端到端延迟、工具调用次数。成本指标： 平均 Token 消耗、平均费用。工具使用指标： 工具选择准确率（选对了工具 vs 用错了）、参数生成准确率、工具调用成功率。可靠性指标： 循环发生率、错误恢复成功率、超时率。评估方法：建立评估数据集（输入-期望输出对），自动化运行 + 人工评审打分。推荐框架：简单场景用自定义脚本 + LLM-as-Judge；复杂场景用 LangSmith Evaluation、RAGAS（RAG 类）、SWE-bench（代码类）。注意要多次运行取平均值，因为 LLM 输出有随机性。

14. Prompt Engineering vs Context Engineering，区别是什么？

参考答案： Prompt Engineering 聚焦于怎么写提示词——措辞、格式、Few-shot 示例、CoT 引导等技巧。Context Engineering（2025 年由 Shopify CEO 等人推广）是更广的概念，关注为 LLM 提供什么信息——在有限的 context window 中，如何组装最有价值的上下文。它包括但不限于 prompt：系统提示词只是一部分，还要考虑该注入哪些检索结果（RAG）、传入哪些历史对话（摘要 vs 原文）、工具返回结果如何格式化、Agent 记忆如何选择性加载。本质区别：Prompt Engineering 是"措辞的艺术"，Context Engineering 是"信息策展的工程"。在 Agent 系统中，Context Engineering 更关键——Agent 每步决策的质量直接取决于它 context 中有什么信息、信息的顺序和格式。

15. MCP 协议是什么？它解决什么问题？

参考答案： MCP（Model Context Protocol）是 Anthropic 于 2024 年底提出的开放协议，目标是标准化 LLM 应用与外部工具/数据源的连接方式。问题背景： 在 MCP 之前，每个 Agent 框架、每个 LLM 都有自己的工具集成方式，开发者需要为每个平台重复开发工具插件——N 个 LLM × M 个工具 = N×M 个适配器。MCP 的方案： 定义统一的 Client-Server 协议。工具开发者只需实现一个 MCP Server（提供 tools、resources、prompts），任何支持 MCP 的 Client（Claude、Cursor、各种 Agent 框架）都能直接调用。类比 USB 接口——设备厂商和电脑厂商各自遵循标准，即插即用。核心能力： Tools（可调用的函数）、Resources（可读取的数据源）、Prompts（预定义的提示模板）。传输层： 本地用 stdio，远程用 HTTP+SSE。MCP 正在成为 Agent 工具生态的事实标准。

场景设计

16. 设计一个客服 Agent 系统

要求：多轮对话、知识库检索、工单创建、转人工

参考答案： 架构： 单 Agent + RAG + 工具集 + Human-in-the-loop。核心组件： 1) 意图识别层——判断用户意图（咨询、投诉、操作请求）；2) 知识库检索——用 RAG 从产品文档/FAQ 中检索答案，embedding 用 BGE/E5，向量库用 Qdrant；3) 工具集——查询订单 API、创建工单 API、发送通知；4) 转人工机制——三种触发条件：用户主动要求、Agent 置信度 <0.6、连续 3 轮未解决。对话管理： 多轮上下文通过对话历史维护，提取并维护结构化的会话状态（用户信息、问题分类、当前处理阶段）。安全机制： 敏感操作（退款、账号修改）需要 HITL 审批；Prompt 注入防护过滤用户输入；回答不确定时明确说"不确定，已转交人工"。评估指标： 自主解决率、平均处理时长、用户满意度、转人工率。

17. 设计一个代码审查 Agent

要求：读取 PR、分析代码、给出建议

参考答案： 架构： Plan-and-Execute + Reflection 模式。工具集： Git API（获取 PR diff、文件内容、commit 历史）、代码搜索（找相关文件/函数定义）、静态分析工具（lint、类型检查）、测试执行器。流程： 1) 获取 PR 的 diff 和描述，理解变更意图；2) 分析每个变更文件——代码质量（可读性、复杂度）、潜在 bug（空指针、边界条件、并发问题）、安全风险（SQL注入、XSS）、性能影响；3) 查看相关上下文代码，理解变更对系统的影响；4) 运行现有测试检查是否破坏功能；5) 使用 Reflection 对自己的审查结论做二次检查，减少误报。输出格式： 按文件组织 review comments，标注严重等级（blocker/warning/suggestion），给出修复建议代码。关键： 控制误报率（太多噪音审查意见会被忽略）；区分风格偏好 vs 真实问题；支持 .reviewconfig 自定义规则。

18. 如何构建一个能自主学习和改进的 Agent？

参考答案： 核心是建立经验积累 + 反馈闭环机制。经验存储： 将每次任务的完整执行轨迹（输入→步骤→结果→用户反馈）存储到经验库。成功经验提取： 从成功案例中提取可复用的策略模板（"遇到 X 类问题，先做 A 再做 B"效果好），存为情景记忆供后续检索。失败分析： 对失败案例进行根因分析——是工具选错了、推理出错了、还是信息不足——记录避坑指南。Prompt 自优化： 基于成功/失败模式自动调整系统提示（如 DSPy 的自动 prompt 优化）。技术实现： 经验库用向量数据库存储，任务开始时检索相似历史经验注入 context；用户显式反馈（👍👎）+ 隐式反馈（任务是否完成）作为信号；定期用批量分析发现系统性问题。注意： "自主学习"不是微调模型权重，而是通过优化记忆、提示和策略来改进行为，属于"in-context learning"的范畴。

AI Agent 开源框架全景（2025）

面试必备：覆盖主流 Agent 编排框架、RAG 框架、向量数据库，含深度对比、选型实战和 15 道面试题。

一、Agent 编排框架

1. LangChain

定位：最主流的 LLM 应用开发框架，模块化组件 + 预构建 Agent 架构。

核心架构（文字描述）：

用户输入 → Prompt Template → LLM → Output Parser → 结果
                ↑                        ↓
             Memory ←──────────── Agent(ReAct Loop)
                                       ↓
                                 Tool 1 / Tool 2 / ...

采用"链式调用"架构。核心是 LCEL（LangChain Expression Language），用管道操作符 | 将 Prompt、LLM、OutputParser 等组件串联成 Runnable 链。Agent 模式下，LLM 作为推理引擎进入 ReAct 循环，动态选择 Tool 执行。

关键 API / 概念：

真实使用场景案例：

• 客服机器人：Prompt → LLM → 判断意图 → 调用订单查询 Tool → 返回结果。链式结构清晰，适合意图-槽位填充模式。
• 文档问答：PDF 加载 → 文本切分 → Embedding → 向量库存储 → Retriever + LLM 生成答案。LangChain 的 RecursiveCharacterTextSplitter + VectorStoreRetriever 是标准 RAG 管道。

优势 vs 局限：

2. LangGraph

定位：LangChain 生态的有状态 Agent 编排框架，用有向图建模复杂工作流。

核心架构（文字描述）：

            ┌─────────────────────────────────────┐
            │          StateGraph                  │
            │                                     │
START ──→ [Node A: 路由] ──条件边──→ [Node B: 工具调用]
                 │                        │
                 │                   [Node C: 人工审批]
                 │                        │
                 └────────← 循环边 ←──────┘
                                          │
                                       [END]
            │      ↕ State（TypedDict 全局状态）     │
            │      ↕ Checkpointer（持久化快照）      │
            └─────────────────────────────────────┘

将工作流建模为 StateGraph，每个 Node 是一个函数，Edge 定义流转（支持条件分支和循环）。State 是全局共享的 TypedDict，每次 Node 执行后更新。Checkpointer 支持断点续跑和时光回溯。

关键 API / 概念：

真实使用场景案例：

• 多步骤代码生成：需求分析 → 代码生成 → 代码执行 → 错误检测 → 修复（循环）→ 输出。LangGraph 的循环边天然支持"生成-测试-修复"迭代。
• 客服升级系统：AI 自动回复 → 置信度低时 interrupt → 人工接管 → 继续。Checkpoint 保证中断后状态不丢失。
• 多 Agent 协作：每个 Agent 是一个子图（subgraph），通过 supervisor 节点路由分派。

优势 vs 局限：

面试高频：LangChain vs LangGraph 如何互补？

LangChain 负责"组件层"（Prompt/LLM/Tool/Retriever 等乐高积木），LangGraph 负责"编排层"（积木如何拼接、何时循环、何时等人审批）。简单线性流程用 LCEL 即可；需要循环、分支、持久化状态、多 Agent 时上 LangGraph。

3. CrewAI

定位：角色扮演多智能体框架，模拟真实团队协作。

核心架构（文字描述）：

Crew（团队）
 ├── Agent 1: 研究员（Role + Goal + Backstory + Tools）
 ├── Agent 2: 写手（Role + Goal + Backstory + Tools）
 └── Agent 3: 编辑（Role + Goal + Backstory + Tools）
      │
      ↓
 Process（流程策略）
  ├── Sequential（顺序执行）
  ├── Hierarchical（层级管理，Manager Agent 分派）
  └── Consensual（共识协商，实验性）
      │
      ↓
 Task 1 → Task 2 → Task 3 → 最终输出

关键 API / 概念：

真实使用场景案例：

• 内容创作流水线：研究员 Agent 搜索资料 → 写手 Agent 撰写文章 → SEO Agent 优化标题关键词 → 编辑 Agent 终审。每个角色有独立的系统提示和工具集。
• 招聘筛选系统：简历解析 Agent → 技能匹配 Agent → 面试问题生成 Agent。

优势 vs 局限：

4. AutoGen（微软）

定位：多 Agent 对话框架，以消息传递驱动协作。2024 年底发布 AutoGen 0.4 大重构（AgentChat + Core + Extensions）。

核心架构（文字描述）：

                     ┌──────────────────┐
                     │   Group Chat     │
                     │  (Team / Swarm)  │
                     └───────┬──────────┘
                             │ 消息广播
              ┌──────────────┼──────────────┐
              ↓              ↓              ↓
     [AssistantAgent]  [UserProxyAgent] [CodeExecutor]
      (LLM 推理)       (人工输入)       (沙箱执行)
              │              │              │
              └──────────────┴──────────────┘
                      ↕ 异步消息传递
                      ↕ Termination 条件

关键 API / 概念（0.4 版）：

真实使用场景案例：

• 代码调试协作：AssistantAgent 生成代码 → CodeExecutor 执行 → 错误反馈 → AssistantAgent 修复。自然的"对话式调试"。
• 研究论文分析：多个专家 Agent（统计学家、领域专家、批评者）在 GroupChat 中讨论论文，涌现出更全面的分析。

优势 vs 局限：

5. Dify

定位：LLM 应用开发平台，无代码 / 低代码，开源自部署。

核心架构（文字描述）：

┌─────────────── Dify Platform ───────────────┐
│                                              │
│  ┌─────────┐   ┌──────────┐  ┌───────────┐ │
│  │ Chatbot │   │ Workflow  │  │ Agent     │ │
│  │  模式   │   │  模式    │  │  模式     │ │
│  └────┬────┘   └────┬─────┘  └─────┬─────┘ │
│       │             │              │        │
│       └─────────────┴──────────────┘        │
│                     │                       │
│  ┌─────────────────────────────────────┐    │
│  │   RAG 引擎 / 知识库 / 向量检索     │    │
│  │   多模型切换 / API 密钥管理         │    │
│  │   监控 / 日志 / 标注 / 数据集       │    │
│  └─────────────────────────────────────┘    │
└──────────────────────────────────────────────┘

关键概念：

• 应用类型：Chatbot（对话）、Text Generator（文本生成）、Agent（自主决策）、Workflow（可视化流程）
• 可视化 Workflow 编辑器：拖拽节点（LLM / 条件 / 代码 / HTTP / 知识检索）构建流程
• 知识库：上传文档 → 自动切分 → Embedding → 向量检索，内置 RAG 管道
• 多模型管理：统一接口管理 OpenAI / Claude / 本地模型等

真实使用场景案例：

• 企业知识库问答：上传公司文档 → 自动构建知识库 → 部署为 Chatbot。非技术人员即可操作。
• 审批工作流：用 Workflow 模式编排 LLM 判断 + 条件分支 + API 调用 + 人工审核节点。

优势 vs 局限：

6. OpenAI Agents SDK（🔥 2025 热门）

定位：OpenAI 官方发布的轻量级 Python Agent 框架（2025 年 3 月发布），前身为 Swarm 实验项目。设计哲学是"少即是多"——用最少的抽象覆盖大部分 Agent 场景。

核心架构（文字描述）：

Runner.run(agent, input)
    │
    ↓
┌─────────── Agent Loop ───────────┐
│                                   │
│  Agent(instructions, tools, model)│
│       │                           │
│       ├─→ Tool Call → 执行 → 结果反馈 → 继续循环
│       ├─→ Handoff → 切换到另一个 Agent
│       └─→ Final Output → 结束
│                                   │
│  Guardrails（输入/输出护栏）       │
│  Tracing（内置追踪）               │
└───────────────────────────────────┘

关键 API / 概念：

核心设计原则：

1. Agent 循环：Agent 被调用 → LLM 推理 → 工具调用或 Handoff 或最终输出 → 循环直到结束
2. Handoff 机制：Agent A 可以"移交"控制权给 Agent B，实现多 Agent 协作（类似客服转接）
3. 护栏：在 Agent 循环外层套安全检查，异步并行执行不影响性能
4. 可观测性：内置 Tracing 支持，生产环境必备

真实使用场景案例：

• 智能客服分流：Triage Agent 判断意图 → Handoff 到退款 Agent / 技术支持 Agent / 销售 Agent。每个子 Agent 有独立工具集。
• 数据分析助手：Agent 接收自然语言查询 → 调用 SQL 工具 → 执行查询 → 用 Python 工具画图 → 返回分析报告。
• 代码审查：Agent 读取 PR diff → 调用静态分析工具 → 生成审查意见。

优势 vs 局限：

代码示例（感受简洁度）：

from agents import Agent, Runner, function_tool

@function_tool
def get_weather(city: str) -> str:
    """获取城市天气"""
    return f"{city}: 晴，25°C"

agent = Agent(
    name="天气助手",
    instructions="你是天气查询助手",
    tools=[get_weather]
)

result = Runner.run_sync(agent, "北京天气怎么样？")
print(result.final_output)

7. Google Agent Development Kit (ADK)

定位：Google 于 2025 年 4 月发布的开源 Agent 开发框架，深度集成 Gemini 模型和 Google Cloud 生态。

核心架构（文字描述）：

Agent
 ├── LlmAgent（LLM 驱动的推理 Agent）
 ├── SequentialAgent（顺序编排多个子 Agent）
 ├── ParallelAgent（并行执行子 Agent）
 └── LoopAgent（循环执行直到满足条件）
      │
      ↓
 Tools: Google Search / Code Execution / 自定义函数 / MCP 工具
      │
      ↓
 Session / State / Memory（会话状态管理）
      │
      ↓
 部署: Cloud Run / Vertex AI / Agent Engine

关键概念：

优势 vs 局限：

8. Mastra（JS/TS 生态）

定位：面向 TypeScript 开发者的 AI Agent 框架，填补 JS 生态的 Agent 框架空白。

核心架构：

Mastra Framework
 ├── Agent（LLM + Tools + Memory）
 ├── Workflow（基于 XState 状态机的工作流）
 ├── RAG（内置向量检索管道）
 ├── Syncs（第三方数据同步）
 └── Evals（内置评估工具）

关键特性：

• TypeScript 原生：类型安全，适合全栈 JS 团队
• 工作流引擎：基于 XState 状态机，支持分支、循环、暂停恢复
• 内置 RAG：集成 Pinecone / pgvector 等向量库
• 工具集成：支持 MCP 协议，可直接使用 MCP 工具服务器

适用场景：全栈 TypeScript 团队构建 AI 应用，前后端统一技术栈。

9. Pydantic AI

定位：由 Pydantic 团队开发的 Python Agent 框架，强调类型安全和生产就绪。

核心架构：

PydanticAI Agent
 ├── System Prompt（静态 + 动态）
 ├── Tools（@agent.tool 装饰器）
 ├── Structured Result（Pydantic Model 验证输出）
 ├── Dependencies（依赖注入系统）
 └── Model（统一接口：OpenAI / Anthropic / Gemini / Groq / Ollama）

关键特性：

• 结构化输出：用 Pydantic Model 定义输出格式，自动验证
• 依赖注入：RunContext[Deps] 注入数据库连接、API 客户端等
• 多模型支持：统一接口覆盖主流 LLM
• Logfire 集成：内置可观测性支持
• 流式输出：支持 run_stream() 流式返回

优势 vs 局限：

10. Semantic Kernel（微软）

定位：微软开源的 AI 编排 SDK，支持 C# / Python / Java，面向企业级应用。

核心架构：

Kernel（内核）
 ├── AI Services（OpenAI / Azure OpenAI / Hugging Face）
 ├── Plugins（插件 = 一组 Functions）
 │    ├── Semantic Function（Prompt 模板）
 │    └── Native Function（代码函数）
 ├── Planner（自动规划执行步骤）
 ├── Memory（向量记忆）
 └── Filters（前置/后置过滤器）

关键概念：

优势 vs 局限：

11. Langflow

定位：低代码可视化框架，用拖拽方式构建 Agent 和 RAG 工作流。

核心特性：

• 可视化画布编辑器
• 导出为 Python 代码
• 内置组件市场
• 一键部署为 API

适用场景：快速原型验证、非技术团队使用、教学演示。

二、RAG 框架

1. LlamaIndex

定位：LLM 数据框架，专注数据摄取、索引、查询。

核心架构：

数据源 → Reader/Loader → Document → Node Parser → 切分
    → Embedding → Index（VectorStore / KG / Summary）
    → Retriever → Response Synthesizer → 答案

关键概念：

• Document / Node：文档和切分后的节点
• Index：VectorStoreIndex / KnowledgeGraphIndex / SummaryIndex 等
• QueryEngine：封装检索+生成的查询引擎
• Router：多索引路由查询
• Agent：LlamaIndex 也有自己的 Agent 层（ReAct / Function Calling）

真实场景：复杂文档结构（PDF 表格、层级文档）的精准问答，多源异构数据的统一检索。

优势：数据处理能力强，索引类型丰富，适合复杂 RAG。

局限：Agent 编排能力不如 LangGraph，主要聚焦数据层。

2. Haystack（Deepset）

定位：企业级 RAG 框架，管道式架构。

核心特性：

• 模块化 Pipeline 架构（Component → Pipeline）
• 强大的评估工具和基准测试
• 生产级部署支持（REST API、Docker）
• 支持自定义 Component

适用场景：企业级搜索增强系统，需要严格评估和 CI/CD 的 RAG 管道。

3. RAGFlow

定位：深度文档理解 RAG 引擎。

核心特性：

• 擅长复杂文档（PDF 表格、扫描件、多列排版）
• 内置 OCR 和版面分析
• 支持多种切分策略（语义切分、表格切分）

适用场景：金融报告、法律文书、医疗病历等复杂文档的 RAG。

4. DSPy（斯坦福 NLP）

定位：用"编程"代替"提示"的声明式框架。

核心概念：

• Signature：声明输入输出（"question -> answer"）
• Module：dspy.ChainOfThought、dspy.ReAct 等可组合模块
• Optimizer：BootstrapFewShot、MIPROv2 等自动优化提示
• Metric：定义评估指标，驱动自动优化

核心理念：不手写 Prompt，而是定义 Signature + Metric，让框架自动优化 Prompt 和 few-shot examples。

适用场景：需要系统化优化 RAG 管道效果的研究和生产场景。

5. Pathway

定位：高吞吐量低延迟 RAG 框架。

• 350+ 数据源连接器
• 实时增量索引更新
• 适合大规模部署和流式数据场景

三、向量数据库（RAG 必备）

四、框架大对比表

Agent 编排框架横向对比

五、框架选型实战

5.1 按业务需求选框架

5.2 框架组合的最佳实践

组合 1：LangChain + LangGraph（最常见）

• LangChain 提供组件（Prompt/Tool/Retriever），LangGraph 编排工作流
• 适合：复杂企业应用，需要精细流程控制
• 示例：客服系统 = LangChain 工具定义 + LangGraph 状态机编排 + LangSmith 监控

组合 2：LlamaIndex + LangGraph

• LlamaIndex 负责数据索引和检索，LangGraph 编排多步推理
• 适合：复杂 RAG 需要多轮检索、验证、重写
• 示例：法律文书分析 = LlamaIndex 多索引路由 + LangGraph 多步推理验证

组合 3：Dify + 自定义 Agent

• Dify 做前端和基础 RAG，复杂逻辑通过 API 调用外部 Agent
• 适合：团队混合技术水平，需要快速交付
• 示例：Dify 知识库 + 外部 LangGraph Agent 处理复杂推理

组合 4：CrewAI + LangGraph

• CrewAI 定义角色和任务，LangGraph 精细控制工作流
• 适合：需要角色协作 + 复杂流程控制的场景

5.3 选型决策树

                          你的场景是什么？
                               │
              ┌────────────────┼────────────────┐
              ↓                ↓                ↓
         需要写代码？      非技术团队？       快速原型？
              │                │                │
         ┌────┴────┐      Dify/Langflow    OpenAI SDK
         ↓         ↓                        / CrewAI
     简单流程   复杂流程
         │         │
    LangChain   需要多 Agent？
    / OpenAI SDK    │
              ┌─────┴─────┐
              ↓           ↓
          角色协作？   对话协作？
              │           │
           CrewAI      AutoGen
              │
        需要精细状态控制？
              │
           LangGraph

六、框架选型决策树（速查版）

需求分析
├── 简单 RAG / 聊天机器人 → LangChain + LlamaIndex
├── 复杂多步骤有状态工作流 → LangGraph
├── 多 Agent 角色协作 → CrewAI
├── 研究 / 快速原型 → AutoGen
├── 非技术团队快速搭建 → Dify / Langflow
├── 企业级 RAG → Haystack / Pathway
├── 自动优化检索 → DSPy
├── 轻量多 Agent + OpenAI 生态 → OpenAI Agents SDK
├── Google 生态 → Google ADK
├── TypeScript 全栈 → Mastra
├── .NET / Java 企业 → Semantic Kernel
└── 类型安全 Python Agent → Pydantic AI

七、面试题 15 题 + 参考答案

Q1：LangChain 和 LangGraph 有什么区别？什么时候该用 LangGraph？

参考答案：

LangChain 是组件库 + 线性编排（LCEL），适合简单的链式调用（Prompt → LLM → Tool → Output）。LangGraph 是图结构编排框架，用有向图建模工作流。

该用 LangGraph 的信号：

1. 需要循环（如代码生成→测试→修复循环）
2. 需要条件分支（如根据分类结果走不同路径）
3. 需要持久化状态（如长时间运行的任务需要断点续跑）
4. 需要Human-in-the-loop（如审批节点）
5. 需要多 Agent 协作（每个 Agent 作为子图）

两者互补而非替代：LangChain 提供乐高积木，LangGraph 提供拼装蓝图。

Q2：解释 OpenAI Agents SDK 的 Handoff 机制，和传统多 Agent 框架有什么不同？

参考答案：

Handoff 是 OpenAI Agents SDK 的核心多 Agent 机制。当 Agent A 判断当前任务应由另一个 Agent 处理时，它返回一个 handoff() 调用，Runner 自动将控制权和对话历史转移给目标 Agent。

与传统框架的区别：

• CrewAI：预定义任务分配，Agent 按顺序/层级执行固定流程
• AutoGen：Agent 通过消息传递对话，所有 Agent 共享聊天记录
• OpenAI Handoff：动态切换，当前 Agent 主动判断"该谁接手"，更像客服转接

优势：简洁，无需定义复杂的路由逻辑或消息协议；Agent 自己决定何时、向谁 Handoff。

劣势：控制粒度不如 LangGraph 的显式图结构。

Q3：CrewAI 的 Sequential 和 Hierarchical 模式有什么区别？各适用什么场景？

参考答案：

• Sequential：Task 按顺序依次执行，前一个 Task 的输出作为后一个的输入。适合流水线式工作（研究→写作→编辑）。
• Hierarchical：自动创建 Manager Agent，由它决定任务分派和执行顺序。适合任务间有复杂依赖或需要动态调度的场景。

选择建议：任务流程清晰固定用 Sequential；任务间需要动态协调用 Hierarchical。

Q4：Dify 和 LangChain 分别适合什么团队？

参考答案：

• Dify：适合混合技术背景团队（产品经理 + 少量开发），需要快速搭建和迭代 AI 应用，强调可视化和开箱即用。
• LangChain：适合纯技术团队，需要深度定制、灵活组合组件，愿意投入工程化的场景。

关键区别：Dify 是"平台"（带 UI、数据库、监控），LangChain 是"框架"（纯代码库）。非技术人员能用 Dify，用不了 LangChain。

Q5：LangGraph 的 Checkpoint 机制有什么用？怎么实现？

参考答案：

Checkpoint 是 LangGraph 的状态持久化机制，在每个节点执行后自动保存完整状态快照。

用途：

1. 断点续跑：长时间运行的工作流中断后可以从最后一个 Checkpoint 恢复
2. Human-in-the-loop：在 interrupt_before 节点暂停，等人工审批后继续
3. 时光旅行：回溯到任意历史 Checkpoint，修改状态后重新执行
4. 错误恢复：某步失败后回退到上一步重试

实现：用 SqliteSaver / PostgresSaver 等 Checkpointer 作为参数传入 StateGraph.compile(checkpointer=...)。

Q6：AutoGen 0.4 和 0.2 有什么大变化？

参考答案：

AutoGen 0.4 是完全重构：

1. 架构分层：拆分为 Core（消息传递运行时）、AgentChat（高层 API）、Extensions（扩展）
2. 异步优先：原生 async/await，支持分布式 Agent
3. 新编排模式：新增 SelectorGroupChat（LLM 选择发言者）和 Swarm（Handoff 模式）
4. API 不兼容：0.2 代码需要迁移，import autogen → import autogen_agentchat

Q7：什么是 MCP（Model Context Protocol）？哪些框架支持？

参考答案：

MCP 是 Anthropic 提出的标准协议，定义了 LLM 应用与外部工具/数据源之间的通信标准（类似 USB 协议）。

核心组件：

• MCP Server：暴露工具和资源（如数据库查询、API 调用）
• MCP Client：Agent 框架内的客户端，调用 MCP Server

支持的框架：OpenAI Agents SDK、Google ADK、Mastra、LangChain、Cursor、Claude Desktop 等。MCP 正在成为 AI 工具集成的事实标准。

Q8：如何设计一个生产级 Agent 系统的错误处理？

参考答案：

1. LLM 层：重试策略（指数退避）、fallback 模型（主用 GPT-4o，降级到 GPT-4o-mini）、token 限额
2. 工具层：每个工具设置超时、错误返回格式化（让 Agent 理解错误并换策略）、沙箱执行
3. 编排层：最大循环次数限制（防止无限循环）、人工干预断点、状态回滚
4. 系统层：Guardrails（输入/输出检查）、日志追踪（Tracing）、异常告警
5. 幂等性：关键操作（如发邮件、下单）确保幂等，避免重复执行

Q9：比较 RAG 领域的 LlamaIndex 和 LangChain，各自优势是什么？

参考答案：

• LlamaIndex 优势：数据处理更专业（160+ 数据连接器、多种索引类型、子问题查询引擎）、复杂文档结构处理能力强（表格、层级文档、知识图谱）
• LangChain 优势：生态更广（不仅是 RAG，还有 Agent、Chain 等）、社区更大、与 LangGraph 无缝集成

选择建议：纯 RAG 应用用 LlamaIndex；RAG + Agent + 复杂工作流用 LangChain + LangGraph。两者也可组合使用（LlamaIndex 做数据层，LangChain/LangGraph 做编排层）。

Q10：DSPy 的核心理念是什么？和 Prompt Engineering 有什么区别？

参考答案：

DSPy 的核心理念是"编程，而非提示"（Programming, not Prompting）：

• Prompt Engineering：手工编写和迭代 Prompt，依赖人的直觉和经验
• DSPy：定义 Signature（输入→输出声明）+ Metric（评估指标），框架自动生成和优化 Prompt

工作流：

1. 定义 dspy.Signature（如 "context, question -> answer"）
2. 组合 Module（如 dspy.ChainOfThought(signature)）
3. 定义 Metric 和 Training Set
4. 用 Optimizer（如 MIPROv2）自动搜索最优 Prompt + Few-shot Examples

优势：可复现、可自动优化、减少人工调参。

Q11：Semantic Kernel 和 LangChain 的主要区别是什么？

参考答案：

核心区别在受众和生态：Semantic Kernel 是微软面向企业 .NET 世界的 AI 编排方案，LangChain 是 Python AI 社区的默认选择。

Q12：什么是 A2A（Agent-to-Agent）协议？和 MCP 有什么区别？

参考答案：

• MCP（Model Context Protocol）：Agent 与工具/数据源之间的通信协议（Agent ↔ Tool）
• A2A（Agent-to-Agent）：Google 提出的 Agent 与Agent之间的通信协议（Agent ↔ Agent）

互补关系：MCP 解决"Agent 怎么用工具"，A2A 解决"Agent 之间怎么协作"。一个完整的多 Agent 系统可能同时用到两者。

A2A 定义了 Agent Card（能力声明）、Task（任务传递）、Streaming（流式响应）等标准，目标是让不同框架构建的 Agent 能互相调用。

Q13：如何评估和对比不同 RAG 方案的效果？

参考答案：

评估维度：

1. 检索质量：Recall@K、MRR（Mean Reciprocal Rank）、NDCG
2. 生成质量：Faithfulness（忠实度）、Relevance（相关性）、Completeness（完整度）
3. 端到端：Answer Correctness（答案正确率）

评估工具：

• RAGAS：开源 RAG 评估框架，自动化评分
• LlamaIndex Evaluator：内置评估模块
• Haystack Evaluation：管道级基准测试
• 人工评估：Golden set 人工标注 + 盲评

关键实践：先建立 Golden Test Set（标准问答对），再用自动化指标 + 人工抽检双重评估。

Q14：在生产环境中部署多 Agent 系统，最大的挑战是什么？

参考答案：

1. 成本控制：多 Agent 多次 LLM 调用，token 消耗成倍增长。需要缓存策略、小模型预判、短路机制。
2. 延迟：串行多步推理导致高延迟。需要并行化、流式输出、异步架构。
3. 可靠性：LLM 输出不确定性 × Agent 数量 = 系统级不确定性。需要 Guardrails、重试、fallback、人工兜底。
4. 可观测性：多 Agent 调用链复杂，需要完整 Tracing（如 LangSmith / OpenTelemetry）。
5. 状态管理：长时间运行的 Agent 需要持久化状态，处理 crash recovery。
6. 安全性：Prompt Injection、工具滥用、数据泄露。需要输入验证、工具权限控制、输出过滤。

Q15：如果让你从零设计一个 AI Agent 系统，你会怎么选型？请给出一个具体场景的完整方案。

参考答案（以"智能客服系统"为例）：

需求：电商平台客服系统，处理订单查询、退款申请、商品咨询、投诉升级。

选型方案：

架构分层：
┌──────────────────────────────────────────┐
│  前端：Web Widget + API Gateway          │
├──────────────────────────────────────────┤
│  编排层：LangGraph                       │
│  - Triage Node → 意图识别分流            │
│  - 订单查询 Agent（子图）               │
│  - 退款处理 Agent（子图 + 人工审批节点） │
│  - 商品咨询 Agent（RAG）                │
│  - 投诉升级 Agent → 转人工              │
├──────────────────────────────────────────┤
│  数据层：                                │
│  - LlamaIndex（商品知识库 RAG）         │
│  - pgvector（向量存储）                 │
│  - PostgreSQL（对话历史 + 状态）        │
├──────────────────────────────────────────┤
│  可观测性：LangSmith Tracing + Grafana  │
│  安全：Input/Output Guardrails          │
└──────────────────────────────────────────┘

选型理由：

• LangGraph：客服系统需要条件分支（意图路由）、循环（澄清对话）、人工干预（退款审批）、状态持久化（跨会话记忆）
• LlamaIndex：商品文档结构复杂（规格表、FAQ、政策文档），需要专业 RAG
• 不选 CrewAI：客服场景不需要角色扮演，需要精确流程控制
• 不选 Dify：需要深度定制和高并发，可视化平台灵活度不够

本文档持续更新，最后更新：2025年3月

LangChain & LangGraph 深度解析与面试题

一、LangChain 核心架构

模块体系

LangChain
├── Models（模型层）
│   ├── LLMs（文本生成）
│   ├── Chat Models（对话模型）
│   └── Embedding Models（嵌入模型）
├── Prompts（提示层）
│   ├── PromptTemplate
│   ├── ChatPromptTemplate
│   └── FewShotPromptTemplate
├── Chains（链）
│   ├── LLMChain（基础链）
│   ├── SequentialChain（顺序链）
│   ├── RouterChain（路由链）
│   └── LCEL（LangChain Expression Language）
├── Agents（代理）
│   ├── ReAct Agent
│   ├── OpenAI Functions Agent
│   └── Plan-and-Execute Agent
├── Memory（记忆）
│   ├── ConversationBufferMemory
│   ├── ConversationSummaryMemory
│   └── ConversationTokenBufferMemory
├── Tools（工具）
│   ├── Search, Calculator, Code Interpreter...
│   └── 自定义 Tool
└── Retrievers（检索器）
    ├── VectorStoreRetriever
    ├── MultiQueryRetriever
    └── SelfQueryRetriever

LCEL（LangChain Expression Language）

• LangChain 的现代链构建方式
• 用管道操作符 | 连接组件
• 支持流式输出、批处理、异步
• 示例：prompt | llm | output_parser

Agent 类型

• ReAct：推理+行动交替，最经典
• OpenAI Functions：利用 OpenAI 函数调用能力
• Plan-and-Execute：先规划再执行，适合复杂任务
• Tool Calling Agent：通用工具调用（新版推荐）

二、LangGraph 深度解析

核心概念

from langgraph.graph import StateGraph, END

# 1. 定义状态
class AgentState(TypedDict):
    messages: list
    next_step: str

# 2. 创建图
graph = StateGraph(AgentState)

# 3. 添加节点（每个节点是一个函数）
graph.add_node("agent", agent_node)
graph.add_node("tool", tool_node)

# 4. 添加边（定义流转）
graph.add_edge("agent", "tool")           # 无条件边
graph.add_conditional_edges("tool", router) # 条件边

# 5. 设置入口
graph.set_entry_point("agent")

# 6. 编译运行
app = graph.compile()
result = app.invoke({"messages": [...]})

关键特性详解

1. 状态管理

• 每次节点执行都会更新全局 State
• State 在整个图执行期间持久化
• 支持 Checkpointing：可以保存/恢复执行状态
• 支持 Time Travel：回到任意历史检查点

2. 条件边（Conditional Edges）

def router(state):
    if state["need_tool"]:
        return "tool_node"
    return END

graph.add_conditional_edges("agent", router, {
    "tool_node": "tool_node",
    END: END
})

3. 人工干预（Human-in-the-loop）

• 在关键节点前暂停，等待人工审批
• interrupt_before / interrupt_after 参数
• 适用场景：敏感操作确认、Agent 决策审核

4. 多 Agent 协作模式

• Supervisor 模式：一个主 Agent 调度多个子 Agent
• 对等模式：Agent 间直接通信
• 层级模式：多层管理结构

LangGraph vs LangChain Agent

三、实战设计模式

1. ReAct Loop（最基础的 Agent 循环）

用户输入 → Agent 推理 → 是否需要工具？
  ├── 是 → 调用工具 → 获取结果 → 回到 Agent 推理
  └── 否 → 输出最终答案

2. Plan-and-Execute

用户输入 → Planner 生成计划 → Executor 逐步执行
  └── 每步执行后 Replanner 评估是否需要调整计划

3. Reflection（自我反思）

Agent 生成答案 → Critic 评估质量
  ├── 不满意 → Agent 重新生成（带反馈）
  └── 满意 → 输出最终答案

4. Multi-Agent Supervisor

用户输入 → Supervisor Agent
  ├── 分派给 Research Agent
  ├── 分派给 Code Agent
  └── 分派给 Writing Agent
  → 汇总结果 → 输出

四、高频面试题

LangChain

• LangChain 的核心模块有哪些？各自作用？
• 什么是 LCEL？相比传统 Chain 有什么优势？
• LangChain 中的 Memory 有哪几种？各自适用场景？
• 如何在 LangChain 中自定义 Tool？需要注意什么？
• ReAct Agent 的工作原理是什么？

LangGraph

• LangGraph 的图结构（Node, Edge, State）如何工作？
• 什么是条件边？如何实现分支逻辑？
• LangGraph 如何实现 Human-in-the-loop？
• LangGraph 的 Checkpoint 机制是什么？有什么用？
• 如何用 LangGraph 实现多 Agent 协作？描述 Supervisor 模式。

对比与选型

• LangChain 和 LangGraph 如何互补？举一个结合使用的例子。
• 你会在什么场景下选择 LangGraph 而不是 LangChain Agent？
• LangGraph vs CrewAI vs AutoGen，各自优劣？
• 如何调试和监控基于 LangGraph 的 Agent 应用？
• LangGraph 在生产环境中有哪些注意事项（错误处理、超时、成本控制）？

五、参考答案要点

Q5: ReAct Agent 工作原理

• ReAct = Reasoning + Acting
• 循环过程：Thought → Action → Observation → Thought → ...
• LLM 先"思考"当前状况，决定是否需要使用工具
• 如果需要：选择工具并提供参数 → 执行工具 → 观察结果
• 如果不需要：直接生成最终回答
• 核心 Prompt 格式包含 Thought/Action/Action Input/Observation

Q10: Supervisor 多 Agent 模式

• 一个 Supervisor Agent 负责任务调度
• 接收用户输入后，决定分派给哪个子 Agent
• 子 Agent 各自完成任务后将结果返回 Supervisor
• Supervisor 汇总结果，决定是否需要继续或输出最终答案
• LangGraph 实现：Supervisor 是一个条件节点，子 Agent 是独立节点
• State 中维护当前进度和各 Agent 的输出

RAG 核心知识与面试题

一、RAG 基础原理

什么是 RAG？

RAG（Retrieval-Augmented Generation，检索增强生成）是一种让 LLM 在生成回答前，先从外部知识库检索相关信息的技术。

工作流程

• 用户查询 → 2. Query 向量化 → 3. 向量数据库检索 → 4. 拼接上下文到 Prompt → 5. LLM 生成回答

为什么需要 RAG？

• 减少幻觉：回答基于真实数据，而非模型"编造"
• 知识更新：无需重新训练模型就能访问最新数据
• 领域知识：接入企业内部数据、专业文档
• 成本低：比微调（Fine-tuning）便宜得多
• 可溯源：可以标注信息来源，便于验证

二、RAG 核心组件

1. 文档处理（Document Processing）

• 加载：PDF、Word、网页、数据库等多种数据源
• 分块（Chunking）：将长文档切分为适合检索的小块
• 固定大小分块：按字符/token 数切分
• 语义分块：按段落/章节等语义边界切分
• 递归分块：先按大边界分，不够再细分
• 关键参数：chunk_size（块大小）、chunk_overlap（重叠区）

2. 嵌入（Embedding）

• 将文本转为高维向量，捕捉语义信息
• 常用模型：OpenAI text-embedding-3-small/large、BGE、E5、Jina
• 中文推荐：BGE-zh、M3E、text2vec-chinese

3. 向量存储与检索

• 稀疏检索：BM25（关键词匹配），精确但无语义理解
• 密集检索：向量相似度（余弦/内积），理解语义但可能丢失精确匹配
• 混合检索：结合两者，效果最佳
• 重排序（Reranking）：用 Cross-Encoder 对检索结果二次排序

4. 上下文构建与生成

• 将检索到的文档块拼入 Prompt
• 注意 Context Window 限制
• Prompt 模板设计：指导 LLM 基于给定上下文回答

三、RAG 高级技术

1. Query 改写 / 扩展

• HyDE：先让 LLM 生成假设性答案，再用该答案做检索
• Multi-Query：将原始问题改写为多个变体，分别检索后合并
• Step-back Prompting：先问更抽象的问题，获取背景知识

2. Agentic RAG

• 将 AI Agent 整合到 RAG 管道中
• Agent 主动决定：是否需要检索、用哪个数据源、检索结果是否足够
• 支持多数据源路由、迭代检索、自我反思
• vs 传统 RAG：传统 RAG 是"查一次就回答"，Agentic RAG 是"边想边查"

3. Graph RAG

• 结合知识图谱，捕捉实体间关系
• 适合需要推理和关系分析的场景

4. Corrective RAG（CRAG）

• 检索后先评估文档相关性
• 不相关→触发 Web 搜索补充
• 有相关→提取关键信息后生成

5. Self-RAG

• LLM 自己判断是否需要检索
• 生成后自我评估答案质量
• 必要时重新检索

四、RAG vs Fine-tuning

最佳实践：两者结合使用。Fine-tune 提升模型基础能力，RAG 提供实时知识。

五、高频面试题

基础概念

• 什么是 RAG？与直接用 LLM 回答有什么区别？
• RAG 的端到端管道是怎样的？画出架构图并解释每个组件。
• RAG 如何减少 LLM 的幻觉？
• RAG vs Fine-tuning，各自适用场景？何时结合使用？
• 向量数据库在 RAG 中的作用？你用过哪些？

检索优化

• 稀疏检索 vs 密集检索的优缺点？什么是混合检索？
• Chunking 策略有哪些？chunk_size 和 chunk_overlap 如何设置？
• 如何处理检索到的不相关文档？
• 什么是 Reranking？为什么需要它？
• 如何评估检索质量（Precision@K, Recall@K, MRR, NDCG）？

高级技术

• 什么是 Agentic RAG？与传统 RAG 有何不同？
• 解释 HyDE 的原理和适用场景
• Multi-Query RAG 如何工作？
• Graph RAG 解决什么问题？
• Self-RAG 和 CRAG 的区别？

工程实践

• 生产环境部署 RAG 有哪些挑战（延迟、成本、准确率）？
• 如何评估 RAG 系统的整体性能？有哪些评测框架（RAGAS, TruLens）？
• 如何处理多模态数据（图片、表格）的 RAG？
• 大规模文档库（百万级）如何优化检索性能？
• RAG 系统的安全性问题（Prompt 注入、数据泄露）如何防范？

六、参考答案要点

Q1: RAG 如何减少幻觉？

• LLM 回答基于检索到的真实文档，而非纯靠参数记忆
• Prompt 中明确指示"仅基于以下上下文回答"
• 可以返回来源引用，用户可验证
• 但不能完全消除：检索不准或文档本身有误仍可能产生幻觉

Q6: Chunking 最佳实践

• chunk_size 通常 256-1024 tokens，取决于文档类型
• chunk_overlap 通常 10-20%，防止语义断裂
• 代码类文档：按函数/类分块
• 对话类：按轮次分块
• 表格类：保持表格完整性
• 实验调优：不同场景最优参数不同，需要评测验证

Q11: Agentic RAG

• 传统 RAG：Query → 检索 → 生成（一次性）
• Agentic RAG：Agent 判断→是否检索→选择数据源→评估结果→可能重新检索→最终生成
• 优势：更灵活、更准确、支持复杂多步推理
• 实现：用 LangGraph 构建，Agent 作为路由节点

AI Agent 工程师 - 通用技术知识点

跨公司高频考点汇总，适用于所有大厂 Agent 岗面试准备。

一、Agent 核心知识体系

1. Agent 四大模块

• 规划（Planning）：任务分解、CoT、ToT、ReAct、Plan-and-Execute
• 记忆（Memory）：短期（上下文窗口）、长期（向量 DB）、工作记忆（任务状态）
• 工具（Tool Use）：Function Calling、MCP 协议、工具注册发现
• 行动（Action）：执行、观察、反思循环

2. 主流 Agent 框架对比

3. Agent 设计模式

• ReAct：Reasoning + Acting 交替
• Plan-and-Execute：先制定计划再执行
• Reflexion：自我反思改进
• Tool-use Agent：以工具调用为核心
• Manager-Worker：管理者分配，工人执行

二、RAG 完整知识体系

索引优化

• 文档分块策略：固定长度、语义分块、递归分块
• Embedding 模型选择：BGE、E5、text-embedding-3
• 元数据标注：来源、时间、类别

检索优化

• 混合检索：向量 + BM25
• 重排序：Cross-Encoder Reranker
• Query 改写：HyDE、Multi-Query

生成优化

• 上下文压缩
• Citation 生成（标注来源）
• 自一致性校验

评估指标

• 检索：Recall@K、MRR、NDCG
• 生成：Faithfulness、Relevance、Answer Correctness
• 框架：RAGAS、DeepEval

三、大模型八股文

Transformer 核心

• Self-Attention: softmax(QK^T/√dk)V
• Multi-Head: 并行多组 QKV
• FFN: 两层线性 + 激活函数
• Layer Norm + Residual

位置编码

• 正弦余弦（原始 Transformer）
• 可学习位置编码
• RoPE（旋转位置编码）—— 当前主流
• ALiBi（线性偏置）

解码策略

• Greedy Search：取 argmax，快但质量差
• Beam Search：保留 top-k 路径
• Top-K Sampling：从 top-k token 采样
• Nucleus (Top-P) Sampling：从累积概率 > p 的 token 中采样
• Temperature：控制分布平滑度

训练技术

• SFT（有监督微调）
• RLHF（人类反馈强化学习）
• DPO（直接偏好优化）
• LoRA / QLoRA（高效参数微调）

推理优化

• KV Cache
• PagedAttention (vLLM)
• Continuous Batching
• 量化（INT8/INT4/GPTQ/AWQ）
• 投机采样（Speculative Decoding）

四、系统设计常考题

• 设计一个通用 Agent 框架
• 设计一个 RAG 系统
• 设计一个多 Agent 协作平台
• 设计工具注册与发现系统
• 设计 Agent 评估体系

五、计算机基础（不要忽略！）

数据结构 & 算法

• 数组、链表、栈、队列、哈希表
• 二叉树、图、堆
• 排序、搜索、动态规划、回溯

网络

• TCP 三次握手/四次挥手
• HTTP/HTTPS/HTTP2/HTTP3
• WebSocket（AI 流式输出常用）

数据库

• MySQL：事务 ACID、隔离级别、索引 B+ 树
• Redis：数据结构、持久化（RDB/AOF）、集群
• 向量数据库：Milvus、Pinecone、FAISS

操作系统

• 进程 vs 线程 vs 协程
• 死锁条件与预防
• 内存管理

六、面试准备 Checklist

• [ ] 准备 1-2 个 Agent 项目，能讲清楚每个技术决策
• [ ] 手写 RAG pipeline
• [ ] 理解 Transformer 每个组件
• [ ] 刷 50+ LeetCode（Medium 为主）
• [ ] 了解目标公司的 AI 产品和业务
• [ ] 准备"为什么选这个技术"的回答
• [ ] 了解 MCP/A2A 等新协议
• [ ] 读 1-2 篇 Agent 相关论文（如 ReAct、Reflexion、LATS）

AI Agent 面试 - 核心概念详解与参考答案

面试高频必考题的完整参考答案，可直接用于准备

一、AI Agent 核心概念

Q1: 什么是 AI Agent？与传统 AI 的区别？

参考答案：

AI Agent 是具备自主感知、决策、执行和迭代能力的智能系统。

Q2: Agent 的核心组件有哪些？

参考答案：

• 感知模块（Perception）
• 接收用户输入、环境反馈
• 多模态：文本/语音/图像/传感器

• 规划模块（Planning）
• 任务分解（Task Decomposition）
• 方法：CoT（链式思考）、ToT（树状思考）、GoT（图状思考）
• 框架：ReAct（推理+行动交替）、Plan-and-Execute（先规划后执行）

• 记忆模块（Memory）
• 短期记忆：当前对话上下文（In-context Window）
• 长期记忆：向量数据库持久化存储（用户偏好、历史交互）
• 工作记忆：当前任务的中间状态和推理链

• 工具调用模块（Tool Use）
• Function Calling / MCP 协议调用外部 API
• 搜索引擎、数据库、代码执行器、第三方服务

• 行动模块（Action）
• 执行具体操作并观察结果
• 根据反馈调整策略（闭环）

Q3: ReAct 框架如何工作？

参考答案：

ReAct = Reasoning + Acting，交替执行"思考"与"行动"：

循环：
  1. 观察（Observation）：接收用户输入或上一步结果
  2. 思考（Thought）：LLM 生成推理链，分析当前状态
  3. 行动（Action）：选择并执行工具调用
  4. 观察结果 → 回到步骤 2，直到任务完成

优势：减少幻觉（有真实观察做锚点）、可解释性强（每步有思考过程）

劣势：串行执行，多步任务延迟高

Q4: Agent 记忆系统怎么设计？

参考答案：

协同机制：

• 每轮对话结束 → 摘要压缩 → 存入长期记忆
• 新对话开始 → 从长期记忆检索相关上下文 → 注入短期记忆
• 关键设计：什么时候压缩、保留什么、丢弃什么

二、RAG 全链路详解

Q5: RAG 完整流程？

参考答案：

离线阶段（知识库构建）：
  文档收集 → 预处理 → 分块（Chunking）→ Embedding → 存入向量数据库

在线阶段（查询响应）：
  用户查询 → Query 改写/扩展 → Embedding → 向量检索（Top-K）
  → 重排序（Rerank）→ 上下文拼接 → LLM 生成 → 返回答案 + 引用

Q6: Chunk 大小怎么确定？

参考答案：

• 太小（<100 tokens）：语义不完整，检索到碎片
• 太大（>1000 tokens）：噪声多，相关性被稀释
• 经验值：256-512 tokens，overlap 50-100 tokens
• 最佳实践：
• 按语义分块（段落/章节边界）而非固定长度
• 递归分块：先按段落 → 段落太长再按句子
• A/B 测试不同 chunk 大小的检索效果

Q7: 向量召回不准怎么办？

参考答案：

• Query 改写：HyDE（生成假设文档再检索）、Multi-Query（多角度改写）
• 混合检索：向量检索 + BM25 关键词检索，结合两者优势
• Rerank：用 Cross-Encoder 模型对 Top-K 结果重排序
• Embedding 模型升级：BGE-M3、E5-Mistral 等更强模型
• 元数据过滤：先按时间/类别缩小范围，再做向量检索
• 知识图谱辅助：对实体关系类查询用 GraphRAG

Q8: RAG vs 微调怎么选？

参考答案：

Q9: "Lost in the Middle" 问题？

参考答案：

LLM 对上下文中间位置的信息关注度最低，开头和结尾最高。

缓解方法：

• 将最相关的文档放在上下文的开头和结尾
• 减少检索文档数量，只保留最相关的 3-5 个
• 使用 Map-Reduce：先对每个文档单独问答，再汇总

三、LoRA / QLoRA

Q10: LoRA 原理？QLoRA 怎么优化显存？

参考答案：

LoRA（Low-Rank Adaptation）：

• 冻结原始权重 W₀，注入低秩矩阵：W = W₀ + BA
• B ∈ R^(d×r)，A ∈ R^(r×k)，r << min(d,k)
• 只训练 B 和 A，参数量通常只有原模型的 0.01%-1%
• 优势：训练快、避免灾难性遗忘、可热插拔

QLoRA 进一步优化：

• 4-bit 量化：将冻结的基础模型从 FP16 量化到 NF4（4-bit NormalFloat）
• 双重量化：对量化常数也做二次量化，进一步压缩
• 分页优化器：当 GPU 显存不够时，自动将优化器状态转移到 CPU 内存

效果：QLoRA 可以在单张 24GB 显卡上微调 65B 参数模型

Q11: LoRA 效果不好怎么办？

参考答案：

• 增大 rank r（从 8 → 16 → 32）
• 扩大 LoRA 应用层（不只 Q/V，加上 K/O/FFN）
• 检查训练数据质量和多样性
• 学习率调整（LoRA 通常需要比全量微调更大的学习率）
• 考虑 DoRA（Weight-Decomposed LoRA）或 rsLoRA

四、RLHF / DPO / GRPO

Q12: RLHF 三阶段详解？

参考答案：

阶段 1：SFT（有监督微调）

• 用高质量人工标注的指令-回答对微调基座模型
• 让模型学会遵循指令

阶段 2：奖励模型训练（RM）

• 人类标注者对模型生成的多个回答进行排序
• 训练一个判别模型预测人类偏好分数
• 损失函数：Bradley-Terry 模型 → 最大化 chosen 与 rejected 的分数差

阶段 3：PPO 强化学习

• 将 SFT 模型作为策略（policy）
• 奖励 = RM 分数 - β × KL散度（防止偏离 SFT 太远）
• 迭代优化策略，最大化期望奖励

Q13: DPO 与 RLHF 的区别？

参考答案：

DPO 损失函数直觉：直接让模型增大 chosen 回答的概率，减小 rejected 的概率。

Q14: DeepSeek 的 GRPO？

参考答案：

GRPO（Group Relative Policy Optimization）：

• 去掉 Critic 模型（PPO 需要 Critic，增加计算量）
• 对同一个 prompt 采样一组回答（Group），用组内相对排名作为优势函数
• 奖励 = 组内回答的相对好坏，而非绝对分数
• 优势：减少一半模型参数需求，训练效率更高
• DeepSeek R1 用 GRPO 训练出了强大的推理能力

五、MCP vs A2A 协议（新热点！）

Q15: MCP 和 A2A 的区别？

参考答案：

关键面试答案：MCP 和 A2A 是互补关系，不是竞争关系。

• MCP 让 Agent 有能力（调工具）
• A2A 让 Agent 会协作（跨 Agent 通信）
• 一个完整的多 Agent 系统两者都需要

举例：

• 库存 Agent 通过 MCP 查询数据库发现库存不足
• 库存 Agent 通过 A2A 通知采购 Agent 下单补货
• 采购 Agent 通过 MCP 调用供应商 API 完成采购

六、系统设计类

Q16: 高并发 Agent 系统怎么设计？

参考答案：

用户请求 → 负载均衡（Nginx/K8s Ingress）
         → 请求队列（Kafka/RabbitMQ）
         → Agent 服务集群
              ├── 语义缓存层（相似 query 直接返回）
              ├── LLM 推理层（vLLM/TGI，Continuous Batching）
              ├── 向量检索层（Milvus 集群）
              └── 工具调用层（异步执行 + 超时控制）
         → 流式返回（SSE/WebSocket）

关键优化点：

• 语义缓存：Embedding 相似度 > 阈值的 query 直接命中缓存
• 模型路由：简单问题用小模型，复杂问题用大模型
• 异步工具调用：不阻塞主流程
• 降级策略：LLM 超时 → 返回预设回答
• 成本控制：Token 计量 + 按业务方配额限制

Q17: 如何控制 LLM 成本？

参考答案：

• 模型分级：简单 query 用 GPT-3.5/小模型，复杂用 GPT-4
• 语义缓存：相似问题直接返回缓存答案
• Prompt 压缩：删除冗余上下文、摘要历史对话
• Batch 推理：合并请求降低单次调用开销
• 开源模型替代：Qwen/DeepSeek 部署私有化
• Token 配额：按用户/业务方设限

Q18: 如何解决大模型幻觉？

参考答案：

• RAG：提供检索依据，约束生成范围
• Prompt 约束："仅基于提供的上下文回答，如无信息请说不知道"
• Self-Consistency：采样多次取多数一致的答案
• Citation 生成：要求模型标注来源，便于验证
• 后处理校验：用规则/小模型检查事实性
• 温度调低：减少随机性（temperature → 0.1-0.3）

AI Agent 面试 - 高频拷打题合集（牛客热帖 3.1W 浏览）

来源：牛客网热帖 "Agent面试拷打！" 2025-03-24 | 浏览量 31000+

这些是当前面试中实际在问的题目，适合逐题准备。

一、Agent 架构与设计

1. 你理解的 Agent 架构是什么？一个 Agent 系统一般由哪些模块组成？

参考答案：

• Agent 本质是 LLM + 感知 + 规划 + 行动 + 记忆 的闭环系统，能自主完成多步骤任务
• 核心模块：Brain（LLM）负责推理与决策；Planning 负责任务分解与路径规划；Memory 提供上下文与历史信息；Tool Use 执行外部操作（API/数据库/搜索）；Observation 接收工具返回并反馈给 LLM
• 典型架构参考：OpenAI Function Calling 模式、LangChain Agent、AutoGPT 循环架构
• 控制流一般是 循环式：Perceive → Think → Act → Observe → Think → ... 直到任务完成或达到最大轮次
• 工程层面还需要：Guardrails（输出校验/安全过滤）、日志与可观测性、错误重试与降级策略

2. Tool 是怎么设计的？什么样的功能应该做成 Tool？

参考答案：

• Tool = 一个有明确输入输出的函数，通过 JSON Schema 描述参数，让 LLM 能理解何时调用、如何传参
• 适合做成 Tool 的场景：LLM 本身做不好的事——实时数据查询、精确计算、外部系统操作（下单/发邮件）、文件读写
• 设计原则：单一职责（一个 Tool 做一件事）、参数语义清晰（description 写给 LLM 看）、返回值结构化（便于 LLM 解析）
• 要做好 错误处理：Tool 执行失败时返回有意义的错误信息而非直接抛异常，让 LLM 能据此调整策略
• 工程实践：Tool 数量控制在 10-20 个以内，太多会导致 LLM 选择困难；可以用 Tool Router 或分层 Agent 解决工具过多问题
• 安全方面：高危操作（删除/支付）需加 人工确认环节（Human-in-the-loop）

3. Memory 分几种？Short-term / Long-term memory 怎么实现？

参考答案：

• 短期记忆（Short-term）：当前对话的上下文窗口，直接放在 prompt 的 message history 里；受 token 限制，需要做截断或摘要
• 长期记忆（Long-term）：跨会话持久化，通常存向量数据库（如 Pinecone/Milvus），每轮对话结束后将关键信息 embedding 后存入
• 工作记忆（Working Memory）：当前任务的中间状态，如 scratchpad、变量存储，用于多步推理过程中保持上下文
• 短期→长期的转化：会话结束时用 LLM 提取摘要/关键事实，写入长期存储；下次会话开始时检索相关记忆注入 prompt
• 实现方案：短期用 Redis/内存；长期用向量库 + 结构化数据库（用户画像/偏好用关系型存储更合适）
• 关键挑战：记忆的遗忘与更新——旧信息可能过时，需要有机制覆盖或衰减

4. Agent 是怎么做任务规划的？是 ReAct 还是 Plan-Execute？

参考答案：

• ReAct（Reasoning + Acting）：每一步都 Thought → Action → Observation 交替进行，边想边做，适合探索性任务和步骤不确定的场景
• Plan-and-Execute：先一次性生成完整计划（步骤列表），再逐步执行，适合结构化任务（如"帮我订机票+酒店+行程规划"）
• 实际生产中常用混合方案：先粗粒度 Plan，执行过程中遇到异常再用 ReAct 动态调整（Adaptive Planning）
• Plan-and-Execute 的优势：减少 LLM 调用次数、可以做进度展示、支持人工审批
• ReAct 的优势：灵活、能处理意外情况、不需要预知所有步骤
• 高级方案：Tree of Thought（多路径探索）、Reflection（执行后自我反思并修正计划）

5. 多 Agent 协作是怎么做的？

参考答案：

• 常见协作模式：主从模式（Orchestrator + Worker Agents）、管道模式（顺序传递）、辩论模式（多 Agent 讨论达成共识）
• 典型框架：CrewAI（角色分工）、AutoGen（多 Agent 对话）、LangGraph（图状态机编排）
• 通信机制：共享 Blackboard（共享状态空间）、消息传递（Agent 之间直接对话）、中央协调器分发任务
• 工程要点：每个 Agent 要有明确的角色定义和能力边界，避免职责重叠导致冲突
• 实际案例：代码生成场景 → Planner Agent 拆需求 + Coder Agent 写代码 + Reviewer Agent 审查 + Executor Agent 运行测试
• 挑战：多 Agent 的成本控制（每个 Agent 都消耗 token）、一致性保证（多个 Agent 对同一事实的理解要一致）、死循环检测

二、RAG 全链路

6. 你做 RAG 的完整流程是什么？（数据 → 切分 → embedding → 向量库 → 检索 → 重排 → 生成）

参考答案：

• 数据采集与清洗：从 PDF/网页/数据库等多源提取文本，去噪、去重、格式统一
• 文档切分（Chunking）：按语义段落切分（优于固定长度），保留标题/元数据；常用 RecursiveCharacterTextSplitter，chunk 间加 overlap
• Embedding：用 text-embedding-3-small/BGE/M3E 等模型将 chunk 向量化，存入向量数据库（Milvus/Qdrant/FAISS）
• 检索（Retrieval）：用户 query embedding 后做 ANN 近似最近邻搜索，召回 top-K 相关 chunk
• 重排（Rerank）：用交叉编码器（如 bge-reranker、Cohere Rerank）对召回结果精排，显著提升相关性
• 生成（Generation）：将 rerank 后的 top-N chunk 作为 context 注入 prompt，LLM 据此生成答案
• 后处理：引用溯源（标注答案来自哪个 chunk/文档）、幻觉检测、格式化输出

7. Chunk 大小怎么确定？为什么？

参考答案：

• 没有万能值，需要根据文档类型和检索场景实验调优，通常 256-1024 token 是常见区间
• 太小（<128 token）：语义不完整，检索到也没用；太大（>2000 token）：噪声多，embedding 质量下降，检索精度降低
• 经验值：FAQ/知识库 → 256-512 token；技术文档/法律合同 → 512-1024 token；长篇叙述 → 按段落/章节切
• Overlap 很重要：通常设 10-20% 的重叠，避免关键信息被切断
• 进阶方案：语义切分（按段落/主题边界切，而非固定长度）、多粒度索引（同时建粗粒度和细粒度索引）
• 评估方法：用标注好的 QA 对，比较不同 chunk 大小下的 Recall@K 和最终回答质量

8. 向量召回不准怎么办？

参考答案：

• Query 改写/扩展：用 LLM 将用户原始 query 改写为多个变体，或做 HyDE（生成假设性答案再检索）
• 多路召回融合：向量检索 + BM25 关键词检索 + 知识图谱检索，结果做 RRF（Reciprocal Rank Fusion）合并
• 优化 Embedding 模型：换更强的模型（如 BGE-large、GTE）；或在领域数据上 fine-tune embedding 模型
• 优化切分策略：检查是否因为 chunk 切分不当导致语义破碎，调整 chunk 大小和 overlap
• 添加元数据过滤：利用文档标题、分类、时间等元数据做 pre-filter，缩小检索范围
• 引入 Rerank：向量粗召回 + 交叉编码器精排，效果提升通常很显著（10-30% MRR 提升）

9. 如何做 rerank？用什么模型？

参考答案：

• Rerank 是对向量粗召回的 top-K 结果做交叉编码器精排，将 query 和每个 candidate 拼接后打分
• 常用模型：Cohere Rerank API、bge-reranker-v2-m3（开源最强之一）、cross-encoder/ms-marco-MiniLM
• 工作原理：交叉编码器同时看 query 和 doc，能捕捉细粒度语义交互，远优于双塔模型的独立编码
• 实践要点：粗召回 50-100 个，rerank 后取 top 3-5 个喂给 LLM；rerank 增加 50-200ms 延迟，但值得
• 轻量替代：用 LLM 本身做 rerank（把候选列表给 LLM 让它排序），效果好但成本高，适合离线场景
• 还可以做 多阶段 rerank：向量召回 → 轻量 reranker → 重型 reranker，平衡效果与延迟

10. 如何评估 RAG 效果？指标是什么？

参考答案：

• 检索质量指标：Recall@K（标注相关文档在 top-K 中的命中率）、MRR（平均倒数排名）、NDCG
• 生成质量指标：Faithfulness（答案是否忠于检索到的文档，不编造）、Answer Relevancy（答案是否回答了问题）、Correctness（答案正确性）
• 端到端指标：用户满意度、任务完成率、人工评分
• 自动化评估框架：RAGAS（Retrieval-Augmented Generation Assessment）、TruLens、DeepEval
• 评估数据集构建：从真实用户 query 中采样，人工标注 ground truth 答案和相关文档
• 关键：分段评估，分别看检索准不准、生成好不好，定位瓶颈在哪个环节

11. RAG 和微调怎么取舍？

参考答案：

• RAG 适合：知识频繁更新、需要引用溯源、数据量大但标注少、需要快速上线
• 微调适合：特定领域的语言风格/格式要求、任务模式固定（如分类/抽取）、需要内化领域知识减少推理延迟
• 组合方案最优：微调让模型学会领域"语感"和输出格式，RAG 提供实时知识——二者不矛盾
• 成本对比：RAG 主要成本在检索基础设施和 embedding 计算；微调成本在训练数据标注和 GPU 训练
• 决策框架：先上 RAG（快、灵活），效果不够再加微调；微调不能解决"模型不知道"的问题，RAG 可以
• 反模式：不要用微调来"记住"事实——事实会变，微调后很难更新

12. 多路召回怎么做？

参考答案：

• 核心思路：用不同检索方式互补盲区，每路召回一批候选，最后融合排序
• 常见组合：向量检索（语义匹配）+ BM25/ES（关键词匹配）+ 知识图谱（结构化关系查询）
• 融合策略：RRF（Reciprocal Rank Fusion）最简单有效，按排名倒数加权合并；或学一个融合模型做 learned fusion
• 实现方式：各路检索独立并行执行，结果汇总后统一 rerank
• 示例场景："华为 Mate 60 电池容量"——向量检索可能召回相关但不精确的段落，BM25 能精确匹配"Mate 60"+"电池容量"关键词
• 工程注意：各路召回量要平衡（如向量 top-50 + BM25 top-30），避免某一路完全主导结果

13. 如何降低 RAG 的延迟？

参考答案：

• Embedding 缓存：对高频 query 缓存 embedding 结果，避免重复计算
• 向量索引优化：用 HNSW/IVF-PQ 等近似索引替代暴力搜索；合理设置 nprobe/ef_search 平衡精度与速度
• 异步并行：检索和 rerank 与 LLM 预热并行执行；多路召回并行请求
• Streaming 输出：LLM 用流式返回，用户无需等全部生成完，体感延迟大幅降低
• 缩减 context 长度：rerank 后只取 top-3 而非 top-10，减少 LLM 输入 token 数
• 模型选择：embedding 用轻量模型（如 text-embedding-3-small）；rerank 用蒸馏后的小模型；生成用速度快的模型（如 GPT-4o-mini）
• 预计算：对文档库中的高频问题预生成答案，命中时直接返回

三、LLM 工程问题

14. 如何解决幻觉问题？

参考答案：

• RAG 兜底：所有事实性回答都基于检索到的文档，prompt 中明确要求"仅基于提供的上下文回答"
• 引用溯源：要求模型输出时标注信息来源（[1][2]），便于用户验证，也约束模型不编造
• 自我一致性检查：同一问题多次采样，取一致性最高的答案（Self-Consistency）
• 后处理校验：用另一个 LLM 或规则引擎检查答案是否与 context 矛盾；对关键字段做事实核查
• Prompt 约束：加入"如果你不确定，请说不知道"、"不要编造信息"等指令
• 结构化输出：用 JSON Schema 约束输出格式，减少自由发挥空间

15. 如何降低模型幻觉？

参考答案：

• 与上题有重叠，但侧重系统层面的策略：
• 温度调低：temperature 设 0-0.3，减少随机性
• 知识注入：通过 RAG 或 System Prompt 注入准确信息，减少模型依赖自身参数记忆
• Fine-tune on domain data：让模型学会在特定领域的正确表达模式
• Chain-of-Thought：要求分步推理，中间步骤暴露后更容易发现逻辑错误
• Grounding：将关键实体链接到知识库，生成前先查证
• 拒绝回答机制：训练或 prompt 让模型在低置信度时主动拒答，而非硬编一个答案

16. 如何让模型输出稳定格式？

参考答案：

• JSON Mode / Structured Output：OpenAI 支持 response_format: { type: "json_object" }，强制输出合法 JSON
• Function Calling：通过定义函数参数的 JSON Schema，模型输出自动符合 schema
• Few-shot 示例：在 prompt 中给 2-3 个完整的输入→输出示例，模型会模仿格式
• Pydantic / Instructor 库：自动重试 + 校验，输出不合规时带着错误信息让模型修正
• 后处理正则兜底：对 LLM 输出做正则提取/修复（如补全缺失的括号、去除 markdown 代码块标记）
• 减少 temperature：降低随机性，格式一致性更好
• 明确的格式指令：prompt 中详细说明输出格式要求，用模板框住

17. 如何做自动化 Prompt 优化（A/B test / eval）？

参考答案：

• 构建评测数据集：收集真实用户 query + 标注的理想答案（golden dataset），至少 50-100 条覆盖各场景
• A/B 测试框架：同时运行两版 prompt，按流量比例分流，对比关键指标（准确率/用户满意度/任务完成率）
• 自动评估：用 LLM-as-Judge（GPT-4 评分）、RAGAS 指标、或领域特定的自动评分器
• DSPy / PromptFlow：用编程方式定义 prompt pipeline，自动搜索最优 prompt 组合
• 版本管理：每个 prompt 版本有唯一 ID，关联到评测结果，可追溯回滚
• 持续迭代：上线后持续收集 bad case，补充到评测集，驱动下一轮 prompt 优化
• 注意：不要只看平均分，要关注尾部 case（worst 10%），那些才是用户真正会投诉的

四、系统设计

18. 如果一个 Agent 系统 QPS 很高，你怎么设计架构？

参考答案：

• 异步任务队列：用 Kafka/RabbitMQ 解耦请求接收与 Agent 执行，削峰填谷
• Agent 无状态化：状态存 Redis/DB，Agent Worker 可水平扩容
• LLM 调用池化：维护 API Key 池或自部署模型的多实例负载均衡，避免单点限流
• 分级处理：简单查询走规则/缓存直接返回，复杂任务才走完整 Agent 链路
• 限流与排队：按用户/租户做 rate limiting，超限排队而非拒绝
• 预计算热点：高频问题（如"退货政策"）预生成答案缓存，命中率高的可省掉 LLM 调用

19. 向量检索很慢怎么办？

参考答案：

• 索引类型选择：HNSW（内存型，延迟低）适合百万级；IVF-PQ（量化压缩）适合千万-亿级
• 缩小搜索范围：先用元数据（类目/时间/租户）做 pre-filter，再在子集中做向量搜索
• 分片 + 并行查询：数据分片到多个节点，并行查询后合并结果
• 降维：用 PCA 或 Matryoshka Embedding 将 1536 维降到 256-512 维，搜索速度成倍提升
• GPU 加速：用 FAISS-GPU 或 Milvus GPU 索引，适合大批量请求
• 结果缓存：高频 query 的检索结果缓存（TTL 可设较长，知识库不常变）

20. LLM 调用很慢怎么办？

参考答案：

• Streaming 输出：首 token 延迟通常 200-500ms，流式返回让用户感知更快
• 模型降级：非关键场景用小模型（GPT-4o-mini/Qwen-7B），关键场景用大模型
• Prompt 精简：减少 system prompt 和 context 长度，token 少 = 生成快
• 并行调用：多个独立的 LLM 请求并行发出（如同时生成摘要和分类）
• 缓存：对相同输入缓存 LLM 输出（Semantic Cache —— 语义相似的 query 也命中缓存）
• 自部署推理优化：vLLM/TGI + continuous batching + KV cache + 量化（AWQ/GPTQ），吞吐量提升 3-10x
• 预生成：可预判的请求提前生成并缓存

21. 如何做缓存？

参考答案：

• 多层缓存架构：L1 本地内存缓存（热点数据）→ L2 Redis 分布式缓存 → L3 持久化存储
• 缓存什么：Embedding 结果、向量检索结果、LLM 完整回复、Rerank 结果
• Semantic Cache：不只精确匹配 query，用 embedding 相似度判断——语义接近的 query 复用缓存答案（GPTCache）
• 缓存策略：TTL 根据数据更新频率设定（知识库不常变→长 TTL；实时数据→短 TTL 或不缓存）
• 缓存失效：知识库更新时主动清除相关缓存；用 version tag 标记数据版本
• 注意：带个性化因素的请求（用户画像不同→答案不同）需要把用户特征也纳入缓存 key

22. 如何做降级？

参考答案：

• LLM 降级链：GPT-4o 超时/限流 → 降级到 GPT-4o-mini → 降级到本地小模型 → 降级到规则引擎/模板回复
• RAG 降级：向量检索超时 → 降级到 BM25 关键词检索 → 降级到热门 FAQ 匹配
• 功能降级：复杂 Agent（多步推理）降级为单轮问答；个性化推荐降级为热门推荐
• 熔断器模式：用 Circuit Breaker（如 Hystrix 思路），连续失败 N 次自动熔断，一段时间后半开试探
• 用户提示：降级时要告知用户"当前服务繁忙，为您提供简化回答"，管理预期
• 预案演练：提前定义好各级降级策略并做压测验证，不要等线上出问题才临时想

23. 如何控制成本？（LLM 很贵）

参考答案：

• 模型分级调用：简单任务用便宜小模型，只对复杂任务调用大模型（Router 模型自动分流）
• 缓存复用：Semantic Cache 命中率高时可省 50%+ 的 LLM 调用
• Prompt 压缩：去掉冗余的 context、用 LLMLingua 等工具压缩 prompt、减少 few-shot 示例数量
• 批处理：非实时场景攒批调用，利用 Batch API（OpenAI Batch API 半价）
• Token 预算控制：每次请求设 max_tokens 上限；每用户/每天设 token 消耗配额
• 自部署模型：高 QPS 场景自建推理服务（vLLM + 开源模型），长期成本远低于 API
• 监控与告警：实时监控 token 消耗和费用，异常飙升时自动告警并限流