2026大厂AI Agent高频面试题Top50:题目+参考答案+追问陷阱
标签 :AI Agent / 大模型面试 / 高频面试题 / 系统设计 / 秋招2026
作者 :青山布道师 | 发布于 2026-08-20 | 阅读 15.2k
这篇文章不讲方法论,不写复盘故事,只做一件事:把2026年字节、阿里、腾讯、美团、小米、蚂蚁等大厂AI Agent岗出现频率最高的面试题,按主题整理成Q&A,每题配参考答案和面试官常见的追问陷阱。
题目来源:牛客面经、脉脉真题、CSDN技术帖、掘金知识地图,去重筛选后保留50道最高频题目。每道题标注出现公司和难度等级。
难度说明:⭐基础必会 | ⭐⭐高频进阶 | ⭐⭐⭐系统设计
目录
- 一、LLM底层基础(Q1-Q8)
- 二、Agent核心架构(Q9-Q18)
- [三、Tool Calling与MCP协议(Q19-Q27)](#三、Tool Calling与MCP协议(Q19-Q27))
- 四、RAG与检索增强(Q28-Q35)
- 五、记忆与上下文管理(Q36-Q40)
- 六、多Agent系统设计(Q41-Q45)
- 七、安全治理与生产部署(Q46-Q50)
一、LLM底层基础(Q1-Q8)
Q1 ⭐ 注意力机制为什么要除以根号 d_k
出现公司:字节 / 阿里 / 小米 / 腾讯
点积注意力公式是 softmax(QK^T / sqrt(d_k)) * V。当 d_k 较大时,QK^T 的值会变得很大,导致 softmax 进入梯度饱和区------输出接近 one-hot 分布,梯度几乎为零,训练停滞。
除以 sqrt(d_k) 将点积的方差缩放回 1 附近,使 softmax 输入维持在梯度健康分布的范围内。本质上是数值稳定性的 trick。
追问陷阱:"不除会怎样?"------不除的话,当 d_k=512 时,点积的方差约为512,标准差约22,softmax 输入值会非常大,输出几乎是 one-hot,梯度消失,训练无法收敛。"除了 sqrt(d_k) 还有别的方式吗?"------可以用 d_k 本身或 d_k 的其他幂次,但 sqrt(d_k) 在数学上最自然------它使点积的方差恰好为1。
Q2 ⭐ LayerNorm 和 BatchNorm 的区别,为什么 Transformer 用 LayerNorm
出现公司:小米 / 字节 / 阿里
LayerNorm 对每个样本的特征维度做归一化,BatchNorm 对 batch 内所有样本的同一特征做归一化。
NLP 选 LayerNorm 的原因:序列长度不固定,BatchNorm 对变长序列处理不稳定;LayerNorm 不依赖 batch size,推理时行为一致;不引入 batch 内样本间的依赖,更适合自回归生成。
Q3 ⭐⭐ RoPE 为什么能实现相对位置编码
出现公司:字节 / 腾讯
RoPE 对 q 和 k 向量的每两个维度一组,乘以角度为 m*theta 的旋转矩阵(m 是位置索引,theta 是预设频率)。
由于旋转矩阵的性质,q_m 和 k_n 的点积结果只依赖于 m-n(相对位置),而非绝对位置 m 和 n。这天然实现了相对位置编码,同时避免了传统位置编码的外推问题。
Q4 ⭐ Temperature、Top-P、Top-K 的区别,Agent场景怎么调
出现公司:字节 / 小米
- Temperature:控制概率分布平滑度,值越低输出越确定
- Top-P(核采样):选累积概率达到 P 的最小 Token 集合
- Top-K:直接选概率最高的 K 个 Token
Agent场景的关键原则:工具调用阶段 Temperature 必须设低(0~0.2),否则模型可能编造不存在的工具名或生成格式错误的参数。创意生成场景可调到 0.7~0.9。
Q5 ⭐⭐ 模型幻觉怎么产生的,Agent场景如何缓解
出现公司:字节 / 阿里 / 美团
幻觉根源在于模型本质是"预测下一个Token"的概率模型,不是知识检索引擎。预训练数据含错误信息,RLHF 鼓励模型"要有帮助",导致不知道也硬编。Agent场景下幻觉更危险------模型可能编造不存在的工具参数。
缓解方案:输出结构化 JSON 而非自由文本;用 RAG 注入事实约束;关键操作人工确认;工具参数做 schema 校验;限制工具数量减少误选概率。
Q6 ⭐⭐ LoRA 的原理、初始化方式和为什么低秩矩阵能work
出现公司:小米 / 字节 / 阿里
LoRA 冻结原始权重 W,在旁边加低秩分解 ΔW = B @ A,其中 A(d×r)降维,B(r×d)升维,r 远小于 d。前向传播变成 h = Wx + BAx。
初始化:A 用随机高斯,B 初始化为零,保证训练开始时 ΔW=0。训练时只更新 A 和 B,W 冻结。
低秩矩阵能work的理论依据是"内在维度假说":模型微调时权重变化量 ΔW 具有低秩特性,r=8~64 就能很好地拟合任务所需的参数变化。
追问陷阱:"为什么优先微调 Q/K/V/O 矩阵?"------因为注意力矩阵是信息流动的核心瓶颈,微调它们能以最小参数量获得最大效果。实际项目中也可以微调 MLP 层,效果接近但参数量更大。
Q7 ⭐⭐ SFT、RLHF、PPO、DPO、GRPO 的区别
出现公司:字节 / 腾讯 / 快手
- SFT:用"指令-回答"对训练模型遵循指令格式,是"教模型做什么"
- RLHF:通过奖励模型打分+强化学习优化输出质量,是"教模型做得更好"
- PPO:经典RL算法,需维护4个模型(policy、value、reference、reward),训练复杂但效果好
- DPO:绕过奖励模型,直接用偏好数据优化策略,训练更简单稳定
- GRPO:DeepSeek提出,去掉 value 网络,用组内相对优势代替,大幅降低显存开销
Q8 ⭐⭐ KV-Cache 怎么加速推理,GQA 和 MQA 的区别
出现公司:字节 / 阿里
KV-Cache 在自回归生成时缓存已计算的 Key 和 Value 矩阵,避免每生成一个新 Token 就重新计算所有历史 Token 的 K/V。生成第 N 个 Token 时只需计算新 Token 的 Q,与缓存的 K/V 做点积即可。
MHA(Multi-Head Attention)每个头有独立的 K/V。MQA(Multi-Query Attention)所有头共享同一组 K/V,显存大幅减少但效果下降。GQA(Grouped-Query Attention)是折中方案------将头分组,组内共享 K/V,在效果和显存之间取得平衡。
二、Agent核心架构(Q9-Q18)
Q9 ⭐⭐ Agent 和传统 LLM Chatbot 的本质区别是什么
出现公司:字节 / 阿里 / 腾讯 / 百度 / MiniMax
Chatbot 数据流是"用户输入→LLM推理→输出文本",单向单次。Agent 数据流是"用户输入→LLM推理→决定用什么工具→执行工具→观察结果→决定下一步→循环直到目标达成",闭环多轮。
Agent 补上了 LLM 缺的三样东西:工具(让输出变成真实动作)、循环(多轮推理+行动直到完成)、记忆(跨轮次保存状态)。
一句话总结:LLM 负责想,Agent 负责想完了真去干。
追问陷阱:"网页版对话助手算 Agent 吗?"------看有没有 ReAct 循环。纯问答是单次调用不算;一旦它开始自己联网检索、自己跑代码、拿着中间结果继续推进,就是轻量级 Agent。判断标准不是产品形态,是有没有"决策→行动→观察→再决策"的闭合回路。
Q10 ⭐⭐ ReAct 框架的核心循环是什么,消息格式怎么设计
出现公司:字节 / 阿里 / 美团
ReAct 的核心是 Thought → Action → Observation 的循环:模型先思考下一步(Thought),执行动作(Action/工具调用),获得观察结果(Observation),再循环思考直到给出最终答案。
消息格式的工程细节:模型输出的 Thought 和 Action 用 assistant 角色,工具执行的 Observation 用 user 角色传回。<thought> 标签包裹推理过程,<action> 标签包裹工具名和参数,<observation> 标签包裹工具返回结果。
追问陷阱:"Observation 用 user 角色还是 assistant 角色传回?"------用 user 角色。因为 Observation 是外部工具返回的结果,不是模型生成的,必须以 user 角色注入,否则模型可能混淆"自己说过的话"和"工具返回的数据"。
Q11 ⭐⭐ ReAct、Plan-and-Execute、Reflexion 怎么选
出现公司:字节 / 阿里
| 维度 | ReAct | Plan-and-Execute | Reflexion |
|---|---|---|---|
| 核心思路 | 走一步看一步 | 先做完整计划再执行 | 执行后自我反思迭代 |
| 灵活性 | 高 | 低 | 中 |
| 适合场景 | 简单查询、探索性任务 | 长流程多步骤任务 | 代码生成、数学推理 |
| 主要风险 | 长任务容易跑偏 | 中间出错需重新规划 | 反思可能陷入死循环 |
实际项目中很少纯用一种,大多混合:先用 Plan-and-Execute 定大方向和步骤拆解,具体每步用 ReAct 灵活执行,卡壳了回到计划层重新规划。
Q12 ⭐⭐⭐ Agent 死循环了怎么办,检测和恢复策略有哪些
出现公司:字节 / 阿里 / 蚂蚁
死循环的典型表现:反复调用同一工具但参数不变;A工具结果喂给B、B结果又喂回A形成乒乓;模型一直自我质疑但从不执行动作。
检测策略:设最大轮次硬上限(10-15轮);记录最近N次工具调用检测是否重复且无新信息产出;设 Token 预算红线,超过即告警。
恢复策略分三档:
- 轻微:插提示让模型换思路("你已连续3次调用相同工具,请尝试不同方法")
- 中等:压缩上下文摘要后重启循环
- 严重:直接降级为普通问答或转人工
追问陷阱:"reflection 失败3次后怎么处理?"------不能无限反思,必须有熔断机制。reflection 失败3次后强制终止当前推理链,返回兜底输出"任务未完成,已记录日志,请人工介入"。
Q13 ⭐⭐ Tools、Workflow、Agent 三者的区别是什么
出现公司:字节 / 阿里 / 腾讯(几乎必出)
这三个东西不在一个层次上:
- Tools 是零件------搜索、计算、读文件这些原子能力
- Workflow 是流水线------先搜索再分析最后输出,路径是固定的
- Agent 是能换流水线的机器人------根据自己的判断决定下一步做什么
Tools 是被调用的,Workflow 是被编排的,Agent 是自主决策的。一个客服系统如果"用户问A就调工具A,问B就调工具B",那是 Workflow;如果"用户问了什么,Agent 自己判断该调什么工具、调几次、什么时候停",那才是 Agent。
Q14 ⭐⭐ CoT → ReAct → ToT 的递进关系
出现公司:字节校招一面
- CoT(思维链):让模型一步步写出推理过程,但只能"想"不能"做"
- ReAct:把推理和行动交错起来,让 Agent 边想边做
- ToT(思维树):让模型同时探索多条推理路径,选择最优方案
为什么需要从 CoT 升级到 ReAct:真实任务需要跟外部世界交互,CoT 只在文本空间里推理,模型想得再好也什么都没做。
Q15 ⭐⭐ Agentic Loop 是什么,画一下流程
出现公司:几乎所有 Agent 岗都会问
Agentic Loop 就是 Agent 的工作流水线------Think → Act → Observe 的循环。
以"帮我退掉上周五买的书"为例:Agent 先判断需要查订单(Think),调用订单查询工具(Act),拿到结果发现书已发货不能直接取消(Observe);再去查退货政策(Think),调用政策查询工具(Act),确认符合条件(Observe);最后创建退货单(Act),任务完成。
Q16 ⭐⭐⭐ 手写一个 ReAct Agent 的核心循环
出现公司:字节 / 阿里 / 美团
python
from typing import Callable, Dict
class ReActAgent:
def __init__(self, llm_call: Callable, tools: Dict[str, Callable]):
self.llm_call = llm_call
self.tools = tools
self.max_iterations = 10
def run(self, query: str) -> str:
messages = [
{"role": "system", "content": self._build_system_prompt()},
{"role": "user", "content": query}
]
for i in range(self.max_iterations):
response = self.llm_call(messages)
if response.get("finish"):
return response["answer"]
tool_name = response["tool"]
tool_args = response["args"]
if tool_name not in self.tools:
observation = f"错误: 工具 '{tool_name}' 不存在"
else:
try:
observation = self.tools[tool_name](**tool_args)
except Exception as e:
observation = f"工具执行失败: {e}"
messages.append({"role": "assistant", "content": response["raw"]})
messages.append({"role": "user", "content": f"Observation: {observation}"})
return "已达到最大推理轮次,强制终止"
def _build_system_prompt(self) -> str:
tool_descs = "\n".join(
f"- {name}: {func.__doc__ or '无描述'}"
for name, func in self.tools.items()
)
return f"""你是一个ReAct Agent。请按以下格式回复:
Thought: 思考下一步
Action: 工具名
Action Input: {{"param": "value"}}
或
Thought: 思考完成
Final Answer: 最终答案
可用工具:
{tool_descs}"""
面试官关注点 :不是看你代码写得多漂亮,而是看你有没有加 max_iterations 限制、有没有处理工具不存在的情况、有没有 try-catch 异常处理。这些才是生产级代码的标志。
Q17 ⭐⭐ LangGraph 和 LangChain 的区别,什么时候必须用 LangGraph
出现公司:字节 / 腾讯 / 阿里
LangChain 的 Chain 是线性流水线,数据单向流动,不支持循环。LangGraph 是有向图状态机,支持分支、循环、并行和条件路由。
ReAct 的"思考→行动→观察"循环必须用 LangGraph 才能表达。简单的一次性 RAG 问答用 Chain 就够了。
追问陷阱:"为什么选 LangGraph 而不是 AutoGen 或 CrewAI?"------LangGraph 状态管理更透明可控,支持持久化和人在回路;AutoGen 偏多 Agent 对话但状态管理弱;CrewAI 偏角色扮演适合简单流水线。
Q18 ⭐⭐ 大模型的灾难性遗忘问题怎么解决
出现公司:百度 / 阿里
灾难性遗忘指模型在学习新任务时丢失旧任务的能力。解决方案:
- 混合训练:新任务数据和旧任务数据混合训练
- 回放策略(Replay):保留部分旧数据在新训练中回放
- LoRA/Adapter:冻结原始权重,只训练新增的低秩矩阵,原始能力不受影响
- EWC(Elastic Weight Consolidation):对重要参数施加正则化约束,限制其大幅变动
三、Tool Calling与MCP协议(Q19-Q27)
Q19 ⭐⭐ 怎么定义一个"好的"工具,踩过哪些坑
出现公司:字节 / 阿里 / 美团
好的工具定义就像写招聘 JD------明确说明"你是干什么的""什么时候该找你""什么时候别找你""参数都是什么含义"。
常见坑:参数名写成 q、id 模型不知道填什么;没加枚举约束模型编出不存在的选项;两个工具功能重叠导致模型反复纠结。
原则:工具描述宁可啰嗦不能模糊。每个 description 要包含使用场景、输入输出说明、边界条件。
python
# 正面示例
{
"name": "search_internal_docs",
"description": """搜索公司内部技术文档库。
使用场景:用户询问公司内部产品、API、技术规范时。
不适用场景:通用知识问题、代码语法问题、外部公开信息。
返回:匹配文档的标题、摘要和链接,最多5条。""",
"parameters": {
"query": {
"type": "string",
"description": "搜索关键词,用自然语言描述要查找的内容",
"required": True
},
"category": {
"type": "string",
"enum": ["api", "architecture", "guide", "faq"],
"description": "文档分类,缩小搜索范围"
}
}
}
Q20 ⭐⭐ 工具调用失败了怎么办,错误处理策略是什么
出现公司:字节 / 阿里 / 蚂蚁
分层处理,别一报错就返回给用户:
- 第一层(瞬时错误):网络超时、限流,指数退避重试2-3次
- 第二层(参数错误):格式不对、缺参数,错误信息返回给 Agent 让它自己修正后重试
- 第三层(业务错误):查不到数据、无权限,信息给 Agent 让它决定下一步
- 第四层(安全拦截):模型瞎调用危险工具,直接拦截并插警告
关键认知:错误信息也是 Agent 的 Observation,它能据此自我修正,这才是"智能"的体现。返回结构化错误而非简单 error 字符串:
json
{"status": "failed", "error_type": "Timeout", "retry_after": 5}
Q21 ⭐⭐ 30个工具注册进去,选工具准确率下降怎么办
出现公司:字节 / 阿里
工具越多选择准确率越低------5个工具准确率约95%,20个就掉到七八十。三种优化方案:
- 分组路由:按业务域分组,先选大类再选具体工具,每级5-6个
- 意图预路由:先用小模型或规则判断意图,再给 Agent 暴露对应工具子集
- 动态注册:每轮对话只给5-8个相关工具,根据上下文动态调整
Q22 ⭐⭐⭐ MCP 协议相比传统 Function Calling 最大的改进是什么
出现公司:腾讯 / 字节
传统 Function Calling 有三大绝症:
- 厂商绑定:每个模型厂商工具定义语法不同,换模型就要改代码
- 静态配置:新增工具要改代码、部署、重启
- 无执行标准:超时、错误处理全靠开发者自己硬编码
MCP 通过标准化协议把工具描述和工具执行分开------工具定义统一存储在 Server 端,Client 通过标准协议动态发现和调用。MCP Server 写一次,所有 Agent、所有项目、所有模型都能用。
追问陷阱:"MCP 最大的改进到底是什么?"------不只是"标准化"三个字。最大的改进是把工具调用从"一次性编码"变成了"可复用资产"。Server-First 架构让工具治理复杂度从 O(N×M) 降到 O(N+M)。
Q23 ⭐⭐ MCP 和 A2A 是什么关系
出现公司:腾讯 / 字节
MCP(Model Context Protocol)是垂直连接------Agent 怎么调用外部工具和数据。A2A(Agent-to-Agent Protocol)是水平连接------Agent 和 Agent 之间怎么互相发现、委托任务、交换结果。
一句话:MCP 解决"我能用什么",A2A 解决"我能和谁合作"。两者是分层协作关系,不是竞争关系。
生产架构中,编排器(Orchestrator)通过 A2A 协调多个 Agent 之间的任务流转,每个 Agent 内部通过 MCP 访问自己的工具集。
Q24 ⭐⭐⭐ MCP 在实际使用中有什么安全风险
出现公司:字节 / 蚂蚁(高频追问)
MCP 的致命缺陷之一是 Context Poisoning------工具描述会被全量注入 Agent 上下文,恶意指令可借工具元数据污染 LLM 推理。OWASP 已将其列为 LLM 应用头号漏洞。
三大攻击面:
- Context Manipulation:工具描述里藏恶意指令
- Server-Side Injection:MCP Server 本身被攻破
- Cross-Server Compromise:一个 Server 被攻破后横向扩散
InjecAgent 基准测试揭示超过 50% 的 agentic 任务存在注入漏洞。
防御方案:工具描述审计(上线前审查所有 description)、权限最小化(每个 Server 只给最小必要权限)、MCP 隧道加密、第三方 Server 安全审查。
Q25 ⭐⭐ 当 LLM 同时调用多个工具时,如何确保调用顺序正确
出现公司:字节算法岗二面
拆成三个问题:
- 依赖管理:无依赖工具可并行调用(API 原生支持单次响应返回多个 tool_use 块),有依赖工具编码为 DAG 图管理执行顺序
- 超时控制:MCP 默认期望工具7-10秒返回,每条调用设硬超时阈值(如15秒),超时立即中断并返回结构化信息
- 异常熔断:同一工具连续失败达阈值或检测到重复模式,系统强制中断当前推理链
Q26 ⭐⭐ Claude Code 的多 Agent 实现机制是什么
出现公司:字节(2026高频)
Claude Code 有两套多 Agent 架构:
- Subagents(父子工头制):大任务拆成互不相关的子任务,每个子 Agent 在全新上下文里独立工作,干完活返回压缩摘要。上下文隔离、轻量快速,但不能互相通信
- Agent Teams(团队协作制):Lead Agent + 共享任务列表 + Mailbox 机制,多个 Agent 在独立上下文里协同工作。能互相通信、适合复杂任务,但 Token 消耗更大
决策逻辑:子任务不需要通信→用 Subagents;需要通信→用 Agent Teams。
Q27 ⭐⭐ A2A 协议的核心要素有哪些
出现公司:腾讯
A2A 的设计哲学是"Agent 间通信的 HTTPS"------不关心 Agent 内部如何推理,只定义对外暴露的身份、能力与交互规范:
- Agent Card:类似 OpenAPI Spec,声明 Agent 的身份标识、能力清单、输入输出 Schema、安全策略与速率限制
- Task Lifecycle:定义任务从创建、分配、执行、回调到确认的完整生命周期
- Structured Handoff:Agent 之间通过标准化消息格式交换结果
A2A v1.0 引入了签名 Agent Card,让接收方 Agent 能验证卡片来自真正的域名所有者而非伪造。
四、RAG与检索增强(Q28-Q35)
Q28 ⭐⭐ 你用的 embedding 模型结构是什么,输出维度多少
出现公司:小米 / 阿里 / 百度(RAG项目必考题)
以 BGE-M3 为例:基于 XLM-RoBERTa 架构,输出维度 1024,支持多语言、长文本(最多 8192 token),同时支持稠密检索、稀疏检索(ColBERT)和多向量检索。
追问陷阱:"为什么选这个模型?和 OpenAI text-embedding-3 对比过吗?向量数据库怎么构建的?用什么索引?"------必须对自己项目中的每个技术选型有清晰理由。HNSW 索引的参数(efSearch、M)也要能说出来。
Q29 ⭐⭐⭐ RAG 知识库上线后文档更新了怎么办
出现公司:小米 / 字节(经典坑题)
只回答"找到变了的 chunk 更新其向量"是不够的。面试官会追问:"内容变了,chunk 边界还和原来一样吗?"
正确方案:
- 用 hash 检测变更:对每个文档计算 hash,只处理 hash 变化的文档
- 先删后增:对变更文档重新分块,先删除该文档旧的所有向量,再插入新的
- chunk 边界移动问题:如果内容增删导致 chunk 边界移动,旧 chunk 和新 chunk 无法一一对应,必须整文档级别删除重建,不能按 chunk 粒度更新
- metadata 变化:只是 metadata 变化的可以直接更新不需要重新 embedding
Q30 ⭐⭐ Chunk 分块策略怎么设计
出现公司:字节 / 阿里
| 文档类型 | 推荐分块方式 | Chunk Size | 注意事项 |
|---|---|---|---|
| 代码文件 | 按函数/类分块 | 函数粒度 | 保留 import 和类定义上下文 |
| Markdown | 按标题层级分块 | 256-512 token | 保留标题路径作为 metadata |
| PDF长文 | 按段落+语义边界 | 512 token,重叠10-20% | 注意"第三条第二款"别被切散 |
| 对话记录 | 按轮次分块 | 1-3轮 | 保留时间戳和角色信息 |
Q31 ⭐⭐ Agentic RAG 和传统 RAG 有什么区别
出现公司:字节 / 阿里 / 百度
传统 RAG 是固定管线:检索一次 → 生成回答。Agentic RAG 把检索当作 Agent 可调用的工具之一,Agent 自己决定何时检索、检索几次、检索结果够不够用。
三个核心区别:传统 RAG 只检索一次,Agentic RAG 可多轮检索;传统 RAG 无法处理多跳问题,Agentic RAG 可链式检索多个来源;传统 RAG 检索失败直接用不完整信息生成,Agentic RAG 可调整策略重试。
追问陷阱:"Query Rewrite 算不算 Agentic?"------算,因为 Query 改写本身就是 Agent 的主动决策行为。"Agentic RAG 成本怎么控制?"------设最大检索轮次、检索结果质量判断提前终止、缓存常见查询。
Q32 ⭐⭐ RAG 为什么要加 Rerank,Recall@K 和 Precision@K 怎么取舍
出现公司:字节
向量检索速度快但精度有限,可能召回语义相关但不够精准的结果。Rerank 用更重的 Cross-Encoder 模型对召回的 Top-K 结果重新打分排序。
取舍逻辑:Recall@K 看的是"相关文档有没有被召回",K 设大一点(20-50)保证不漏;Precision@K 看的是"召回的里面有多少相关的",通过 Rerank 把 K 缩到 3-5 个高精度结果喂给 LLM。
Q33 ⭐⭐ RAG 系统召回不准,你从哪些方面优化
出现公司:阿里淘天一面
从四个层面优化:
- 检索前:优化分块策略、Query 改写、多查询扩展
- 检索中:混合检索(BM25+向量)、调整向量数据库索引参数
- 检索后:Rerank 重排序、过滤低质量结果
- 生成侧:约束解码、溯源标注、后处理事实核查
Q34 ⭐⭐ 了解 GraphRAG 吗,和传统 RAG 有什么区别
出现公司:百度 / 阿里
GraphRAG 在向量检索基础上引入知识图谱,先从文档中抽取实体和关系构建图谱,检索时不仅做向量相似度匹配,还沿图谱关系路径扩展,捕获实体间的关联信息。
优势:能回答"A和B有什么关系"这类多跳推理问题;能整合跨文档的实体关系。劣势:图谱构建成本高、维护复杂、对数据质量要求高。
Q35 ⭐⭐⭐ 场景题:搭建一个医疗知识智能助手的 RAG 链路
出现公司:百度 / 蚂蚁
设计要点:
- 数据层:医疗知识库结构化(疾病→症状→用药→禁忌的图谱关系)+ 非结构化文档(论文、指南)
- 分块策略:按医疗知识层级分块,保留 ICD 编码等结构化 metadata,"第三条第二款"不能被切散
- 检索策略:混合检索(BM25 抓医学术语精确匹配 + 向量检索抓语义相似)+ Rerank
- 生成约束:必须标注信息来源(哪份指南第几页),不能确定的内容必须声明"建议咨询专业医师"
- 安全护栏:涉及用药剂量的回答必须经过规则引擎校验,禁止给出具体处方建议
- 评估体系:Hit Rate、MRR、Answer Correctness,评测集由专业医师标注
五、记忆与上下文管理(Q36-Q40)
Q36 ⭐⭐ 多轮对话里 memory 怎么设计
出现公司:字节 / 腾讯 / 阿里
分层设计:
- 短期记忆(工作记忆):当前对话最近几轮,完整保留,放在上下文末尾
- 会话摘要:中间轮次用模型压缩成几句话代替原始内容,减少 Token 占用
- 长期记忆(外部存储):用户偏好、确认过的事实、关键决策,结构化存入向量数据库或 KV 存储,下次对话按需检索
追问陷阱:"为什么要分层?"------不同信息的访问频率和重要性不同,全塞上下文会导致 Token 爆炸和 Lost-in-the-Middle 效应。"项目级规则、用户偏好、会话上下文怎么区分?"------按生命周期和更新频率区分。
Q37 ⭐⭐ 上下文窗口满了怎么办,压缩策略是什么
出现公司:字节 / 阿里
别等满了再处理,平时就要做分层压缩。字节实习面试会追问"每一层压缩的内容一致吗,分别在什么条件触发":
- 第一层(清理):删除中间轮次的大段工具返回数据。触发条件:超过窗口 60%
- 第二层(摘要):用模型把中间对话压缩成摘要。触发条件:清理后仍超过 70%
- 第三层(提取):把关键信息提取为键值对存入外部。触发条件:摘要后仍超过 80%
核心原则:最新信息留完整,中间的压缩,重要的结构化存储。
Q38 ⭐⭐ Lost-in-the-Middle 问题是什么,怎么解决
出现公司:字节
LLM 在处理长上下文时,位于上下文中间位置的信息容易被"遗忘",模型更关注开头和结尾的信息。
解决方案:
- 重要信息放在上下文开头或结尾,不要埋在中间
- 长上下文做分段摘要,每段核心信息提到开头
- 减少不必要的上下文填充,只保留与当前任务相关的信息
Q39 ⭐⭐ 当前所有 Agent 记忆方案的本质局限是什么
出现公司:字节 / 腾讯(加分项)
当前所有主流记忆方案(向量存储、RAG、便签本、上下文窗口管理)本质上都是"备忘录(Memo)"------只是把信息存起来、用的时候检索,而不是把经验内化为权重级的学习。
港中大与浙大的最新研究直接戳破了这个幻觉。基于检索的记忆 vs 基于权重的记忆,这个区分能展示你对技术边界的认知深度。
Q40 ⭐⭐ Agent 的三大核心组件(记忆、规划、行动)各自怎么设计
出现公司:字节 / 阿里
- 记忆系统:区分工作记忆(当前任务状态)、短期记忆(会话内上下文)、长期记忆(跨会话持久化)。主流方案用 SQLite 做本地长期记忆 + 全文本搜索索引,辅以向量检索
- 规划模块:核心是任务拆解和动态重规划,把复杂任务拆成有依赖关系的子任务,用 DAG 图管理执行顺序
- 行动模块:核心是工具调用,Agent 不直接执行操作,而是输出结构化的工具调用请求,由外部执行器完成
六、多Agent系统设计(Q41-Q45)
Q41 ⭐⭐ 多 Agent 协作有哪些常见模式
出现公司:字节 / 阿里云 / 蚂蚁 / 小红书
三种常见模式:
- 流水线模式:Agent A 的输出是 B 的输入(如"研究→写作→审校")
- 黑板模式:多个 Agent 共享一个上下文黑板,各自读取和写入
- 辩论模式:多个 Agent 对同一问题给出不同方案,再由仲裁 Agent 选择最佳
什么时候该拆多 Agent:一个 Agent 角色冲突(既搞创意又做审核);需要访问不同权限的数据源;不同环节需要不同推理策略。
什么时候不该拆:一个 Agent 加好 Prompt 能解决的事就别拆------3个以上 Agent 协调成本指数级上升,容易互相甩锅。
Q42 ⭐⭐⭐ 多 Agent 怎么分工、通信和终止,如何避免相互扯皮
出现公司:字节
通信必须用结构化消息协议而非纯文本。加共享黑板存上下文,设全局超时和终止条件。
分工原则:每个 Agent 有明确的输入输出定义和专属工具集,不能所有子 Agent 共享工具------工具太多会降低选择准确率。
避免扯皮的三层防线:
- DAG 去环:任务依赖关系编码为 DAG 图,防止循环依赖
- 共享状态锁:多 Agent 操作同一资源时加锁,冲突时由 Lead Agent 协调
- 调用链监控:全链路追踪每个 Agent 的调用记录,出问题时定位到具体步骤
Q43 ⭐⭐⭐ 设计一个能处理退换货的客服 Agent 系统
出现公司:阿里
核心设计:
- 路由层:接收用户请求,意图分类(退货/换货/催发货/咨询),决定交给哪个 Agent
- Triage Agent:分类工单,提取用户ID、订单号、商品信息、严重度
- Retrieval Agent:通过 MCP 查询 CRM(用户信息)、订单系统(订单状态)、知识库(退换货政策)
- Resolution Agent:基于分类和检索数据生成回复和建议操作
- Action Agent:执行操作(创建退货单、更新工单、触发退款)
每个 Agent 有独立工具集和记忆。A2A 负责 Agent 间任务流转,MCP 负责每个 Agent 内部工具访问。编排器管理整个序列不触碰工具级执行。
Q44 ⭐⭐⭐ 设计一个 Coding Agent,和 Claude Code 有什么区别
出现公司:字节
核心设计要点:
- 规划层:面向复杂任务先做 Plan,拆解为子任务(读代码→分析→修改→测试→提交)
- 多 Agent 编排:代码理解 Agent、代码修改 Agent、测试 Agent 各有专属工具集
- 上下文管理:三层压缩策略处理大型代码库的上下文溢出
- 状态恢复:通过检查点(checkpoint)机制持久化 Agent 状态,支持跨会话恢复
和 Claude Code 的区别:Claude Code 的 Memory 做了项目级、用户级、会话级的隔离,能跨会话记住项目规范和用户偏好。需要在 Memory 设计上说明差异。
Q45 ⭐⭐⭐ 设计一个 AI 爬取视频内容的 Agent 系统
出现公司:字节
核心设计:
- 意图理解层:解析用户爬取需求(关键词、时间范围、视频类型)
- 规划层:Plan-and-Execute 模式,制定爬取计划(搜索→筛选→下载→结构化→存储)
- 执行层:ReAct 模式灵活调整。工具包括搜索API、视频信息解析、下载器、内容理解(多模态模型)、数据清洗、存储写入
- 异常处理:反爬触发时自动降速/换IP/等待重试;解析失败记录 bad case 跳过;存储失败本地暂存后重试
- 安全合规:遵守 robots.txt,限速控制,不爬取隐私内容,全量审计日志
七、安全治理与生产部署(Q46-Q50)
Q46 ⭐⭐ 怎么设计安全护栏,Agent 调了数据库 DELETE 怎么办
出现公司:字节 / 蚂蚁 / 阿里
纵深防御,多层护栏:
- 输入层:敏感信息脱敏、Prompt 注入检测、速率限制
- 推理层:按用户角色分配工具集,参数黑白名单校验,高危操作卡审批
- 执行层:工具单独配权限,结果安全检查,操作保证幂等,超时熔断
- 输出层:敏感信息打码,内容安全检测,格式校验
DELETE 删库的三层保险:System Prompt 明令禁止非只读 SQL;数据库工具内部做 SQL 解析检测危险操作直接拒绝;所有写操作必须用户二次确认,留全审计日志。
Q47 ⭐⭐⭐ AI 执行"删库"时你还没点取消怎么办
出现公司:字节 / 蚂蚁
2026年真实事故:一个 Cursor AI Agent 在9秒内从发现凭据不匹配,到搜索到云服务商 API Token,再到发出删除生产数据库的指令,全程没有触发任何人工确认机制。
标准答案不是"加个确认弹窗",而是四层防呆:
- 确认层:高危操作经过安全分类器审查,分类器独立于 Agent 上下文运行
- 规则层:PreToolUse Hook 做确定性规则匹配,DROP TABLE、kubectl delete 直接拒绝,不经过 AI 判断
- 权限层:Agent 根本不持有生产环境凭证,所有敏感凭证通过 MCP 隧道在网络边界注入
- 治理层:全量审计 Agent 操作日志,异常行为实时熔断
Q48 ⭐⭐ Prompt Injection 攻击如何防御
出现公司:字节 / 蚂蚁
Prompt Injection 比 SQL 注入难防一百倍,根源在于 LLM 的 Context Mixing------单一上下文窗口内模型无法区分系统指令、用户指令和不可信外部数据。
四层防御:
- 前置隔离:Execute-Only Agent 架构,78.4%的任务可在不让 LLM 接触不可信数据的情况下完成
- 工具调用审查:在工具调用边界部署语义审计层
- 影响溯源:追踪不可信上下文如何传播到 Agent 决策中
- 权限最小化:静态最小权限 + 凭证从 Agent 内部移除,改为网络边界注入
Q49 ⭐⭐ 怎么评估一个 Agent 好不好,评估体系怎么搭
出现公司:字节 / 阿里 / 快手
分三层评估:
- 第一层(单元测试):工具调用准不准、输出格式对不对、安全规则触没触发
- 第二层(任务级评估):任务完成率、路径是否最优、Token消耗、耗时、抗攻击能力。同一输入跑10次看统计指标
- 第三层(线上评估):用户满意度、留存率、报错率、每次对话成本
必须准备的量化指标:
| 模块 | 核心指标 | 参考值 |
|---|---|---|
| RAG系统 | Hit Rate、MRR、Answer Correctness | 87%、0.72、84% |
| Agent工具调用 | 工具选择准确率、任务完成率 | 90%+、85%+ |
| 幻觉治理 | 幻觉率 | <5% |
| 生产运行 | 平均响应时间、Token消耗/次 | <3s、<5000 token |
追问陷阱:"Recall@5 是0.81,这个数字是好是坏?baseline 是什么?"------没有 baseline 的指标毫无意义。必须同时报告基线模型和优化后模型的指标,用对比证明有效。
Q50 ⭐⭐ 一次对话花了10万Token怎么办,怎么控制成本
出现公司:字节 / 阿里
成本控制从系统设计阶段就嵌入:
- 事前:每轮设 Token 上限,最大推理轮次卡死,模型分层用(简单任务小模型、复杂任务大模型),Prompt 瘦身,工具按需分组暴露,缓存常见查询
- 事中:设告警阈值,Token 超限触发降级(自动压缩上下文、切换小模型),超上限强制终止
- 事后:每天看报表,找最费钱的对话模式,针对性优化
以上就是2026年大厂 AI Agent 面试的50道高频题。准备时不要只背答案,要把每个知识点和自己的项目经历绑定起来,准备好完整的"问题→定位→方案→验证"故事链。
面试的趋势很明确:从"你知道什么"转向"你做过什么、踩过什么坑、怎么解决的"。
祝大家秋招顺利,offer 拿到手软。
如果觉得有帮助,点个赞再走呗 ~