2026大厂AI Agent面试全攻略：高频考点+真题解析+系统设计

标签：人工智能 / AI Agent / 面试经验
作者：青山布道师 | 发布于 2026-08-17 | 阅读 12.5k

---

2026年的秋招季，AI Agent开发岗已经取代"大模型算法岗"成为最热门的赛道。字节、阿里、腾讯、美团、小米都在疯狂招人，但面试的考察方式已经发生根本性变化——面试官不再满足于"你知道什么是Agent"，而是直接上手拷问你的工程落地能力、异常处理思维和系统设计深度。

这篇文章整理了近期牛客、脉脉、CSDN上数十篇真实面经，提炼出各大厂的考察重点差异、高频面试真题、核心知识模块和系统设计思路。无论你是校招还是社招，看完这篇至少心里有底。

目录

• 一、各厂面试风格：知己知彼
• 二、LLM底层认知：基础不牢地动山摇
• 三、Agent架构与核心模式
• 四、Tool Calling：工具调用全解析
• 五、RAG与Agentic RAG
• 六、记忆系统与上下文管理
• 七、多Agent协作与MCP/A2A协议
• 八、评估体系与可观测性
• 九、安全护栏与成本控制
• 十、系统设计真题
• 十一、备战路线

---

一、各厂面试风格：知己知彼

同样投Agent开发岗，不同大厂的考察重点差异显著。以下是2026年最新面经总结：

公司	考察风格	高频考点	难度特点
字节跳动	技术密度最高，层层追问细节	ReAct框架细节、RLHF三阶段、工具调用死循环处理、Coding Agent架构	追问到底，一个问题能连环问5-6层
阿里巴巴	最全面，强调落地瓶颈与务实方案	Agent/Workflow/工具差异、三层架构设计、RAG工程化、异构数据处理	要求画架构图，考察系统设计能力
腾讯	偏生态与协议，注重多Agent协作	Workflow与Agent区别、MCP/A2A协议、记忆系统设计	考察对技术生态的整体理解
小米	项目深挖+八股原理，反感背答案	Transformer结构拆解、LoRA细节、RAG文档更新方案	要求用自己话讲原理，追问到代码级
美团	后端基础+Agent结合	Agent循环流程、Redis分布式锁、缓存一致性、Java并发	后端八股和Agent各占一半

⚠️ 字节面试的"连环崩"：有候选人在字节RAG+Agent面试中，从切片粒度没考虑业务语义开始崩，到没有baseline评测、异常路径没设计、对公司产品一无所知，整场面试连续崩了四次。字节的面试官最看重你是否真正做过项目，而不是只跑过Demo。

---

二、LLM底层认知：基础不牢地动山摇

面试官考察Agent之前，几乎一定会先拷问LLM底层基础。这些题目看起来像"八股文"，但面试官真正在意的是你能否用自己的话讲清楚原理。

注意力机制与Transformer

【高频必问】注意力机制为什么要除以根号 d_k？

🏢 出现公司：字节 / 阿里 / 小米 / 腾讯

点积 attention 的计算公式是 softmax(QK^T / sqrt(d_k)) * V。当 d_k 较大时，QK^T 的值会变得很大，导致 softmax 函数进入梯度饱和区——输出接近 one-hot 分布，梯度几乎为零，训练停滞。

除以 sqrt(d_k) 的目的是将点积的方差缩放回 1 附近，使 softmax 的输入维持在一个梯度健康分布的范围内。本质上是一个数值稳定性的trick，保证训练能正常收敛。

---

【高频必问】LayerNorm 是对哪个维度做归一化？和 BatchNorm 有什么区别？

🏢 出现公司：小米 / 字节 / 阿里

Transformer 使用的是 LayerNorm，对 每个样本的特征维度 做归一化，即对 hidden_size 维度计算均值和方差。BatchNorm 则是对 batch 内所有样本的同一特征 做归一化。

在 NLP 场景中选 LayerNorm 的原因：序列长度不固定，BatchNorm 对变长序列处理不稳定；LayerNorm 不依赖 batch size，推理时行为一致；此外 LayerNorm 不引入 batch 内样本间的依赖，更适合自回归生成。

---

【进阶追问】RoPE 为什么能实现相对位置编码？

🏢 出现公司：字节 / 腾讯

RoPE（Rotary Position Embedding）通过旋转矩阵将位置信息编码到 Query 和 Key 中。核心思想：对 q 和 k 向量的每两个维度一组，乘以一个角度为 m*theta 的旋转矩阵（m 是位置索引，theta 是预设频率）。

由于旋转矩阵的性质，q_m 和 k_n 的点积结果只依赖于 m-n（即相对位置），而非绝对位置 m 和 n。这就天然实现了相对位置编码，同时避免了传统位置编码的外推问题。

模型幻觉与参数调优

【高频必问】模型幻觉怎么产生的？Agent场景下如何缓解？

🏢 出现公司：字节 / 阿里 / 美团

幻觉的根源在于模型本质是"预测下一个Token"的概率模型，不是知识检索引擎。预训练数据本身含有错误信息，RLHF又鼓励模型"要有帮助"，导致不知道也硬编。在Agent场景下，幻觉比纯文本更危险——模型可能编造不存在的工具参数，甚至调用根本不存在的工具。

缓解方案：让模型输出结构化JSON而非自由文本，用RAG注入事实约束，关键操作必须人工确认，工具调用的参数做schema校验，限制工具数量减少误选概率。

---

【基础必问】Temperature、Top-P、Top-K 三个参数有什么区别？Agent场景怎么调？

🏢 出现公司：字节 / 小米

Temperature 控制概率分布的平滑度，值越低输出越确定。Top-P（核采样）选累积概率达到P的最小Token集合。Top-K 直接选概率最高的K个Token。

Agent场景的关键原则：**工具调用阶段 Temperature 必须设低（0_{0.2）**，否则模型可能编造不存在的工具名或生成格式错误的参数，导致整个调用链断裂。创意生成场景可以调到0.7}0.9。

微调与训练

【高频追问】LoRA 的原理是什么？训练时 Transformer 更新哪些参数？为什么用低秩矩阵能表示增量？

🏢 出现公司：小米 / 字节 / 阿里

LoRA（Low-Rank Adaptation）冻结原始预训练权重 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 的低秩矩阵就能很好地拟合任务所需的参数变化。

---

【进阶】SFT 和 RLHF 的作用有什么区别？PPO、GRPO、DPO 分别是什么？

🏢 出现公司：字节 / 腾讯 / 快手

SFT（监督微调）用人工标注的"指令-回答"对训练模型学会遵循指令格式，是"教模型做什么"。RLHF（人类反馈强化学习）通过奖励模型对模型输出打分，用强化学习优化输出质量，是"教模型做得更好"。

PPO 是经典RL算法，需要维护4个模型（policy、value、reference、reward），训练复杂但效果好。DPO（Direct Preference Optimization）绕过奖励模型，直接用偏好数据优化策略，训练更简单稳定。GRPO（Group Relative Policy Optimization）是DeepSeek提出的，去掉value网络，用组内相对优势代替，大幅降低显存开销。

💡 备战提醒：小米面试官特别反感"背八股答案"。比如"为什么除以根号d_k"这道题，只背公式不够，面试官会追问"那如果不除会怎样"“除了sqrt(d_k)还有别的缩放方式吗”。准备时务必理解到能自己推导的程度。

---

三、Agent架构与核心模式

Agent架构是面试的核心战场。面试官不仅考察你知道哪些模式，更关注你在什么场景下选什么模式、异常情况下怎么处理。

ReAct：边想边干

ReAct（Reasoning + Acting）是面试中被问得最多的Agent模式。核心逻辑是"边推理边行动"：模型先思考下一步该做什么（Thought），然后执行动作（Action/工具调用），获得观察结果（Observation），再循环思考，直到给出最终答案。

【手撕代码】手写一个 ReAct Agent 的核心循环

🏢 出现公司：字节 / 阿里 / 美团

这是字节、美团的高频手撕题。核心是 Thought → Action → Observation 的循环，加上最大轮次限制和终止条件判断。

import json
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):
            # 1. Thought: 模型思考下一步
            response = self.llm_call(messages)

            # 2. 判断是否给出最终答案
            if response.get("finish"):
                return response["answer"]

            # 3. Action: 执行工具调用
            tool_name = response["tool"]
            tool_args = response["args"]

            if tool_name not in self.tools:
                observation = f"错误: 工具 '{tool_name}' 不存在，可选: {list(self.tools.keys())}"
            else:
                try:
                    observation = self.tools[tool_name](**tool_args)
                except Exception as e:
                    observation = f"工具执行失败: {e}"

            # 4. Observation: 把结果喂回去，继续循环
            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}"""

ReAct vs Plan-and-Execute vs Reflexion

维度	ReAct	Plan-and-Execute	Reflexion
核心思路	走一步看一步，边推理边行动	先做完整计划再逐步执行	执行后自我反思，迭代改进
灵活性	高，随时调整方向	低，计划一旦确定较难改	中，基于反思调整
适合场景	简单查询、故障排查、探索性任务	多文件重构、周报生成等长流程任务	代码生成、数学推理等需要迭代优化的任务
主要风险	长任务容易跑偏，中间步骤遗忘目标	中间出错需要重新规划，开销大	反思本身可能出错，陷入"自我怀疑"死循环

【场景题】ReAct 和 Plan-and-Execute 怎么选？实际项目中怎么用？

🏢 出现公司：字节 / 阿里

实际项目中很少纯用一种模式，大多是混合：先用 Plan-and-Execute 定大方向和步骤拆解，具体每一步用 ReAct 灵活执行，卡壳了就回到计划层重新规划。字节面试官特别关注"你为什么这么拆流程"“哪些节点是确定性Workflow，哪些交给LLM决策”——核心是考察你对确定性和非确定性边界的把控。

Agent死循环检测与恢复

【高频必问】Agent 死循环了怎么办？检测和恢复策略有哪些？

🏢 出现公司：字节 / 阿里 / 蚂蚁

死循环的典型表现：反复调用同一工具但参数不变；A工具结果喂给B、B结果又喂回A形成乒乓；模型一直自我质疑但从不执行动作。

检测策略：设最大轮次硬上限（通常10-15轮）；记录最近N次工具调用，检测是否重复且无新信息产出；设Token预算红线，超过即告警。

恢复策略分三档：轻微的插一条提示让模型换思路（如"你已连续3次调用相同工具，请尝试不同方法"）；中等的压缩上下文摘要后重启循环；严重的直接降级为普通问答或转人工。字节面试官会追问"reflection 失败3次后怎么处理"——答案是不能无限反思，必须有熔断机制。

---

四、Tool Calling：工具调用全解析

Tool Calling 是 Agent 面试中分值最高的模块之一。面试官不仅关心你怎么定义工具，更关心工具调用失败时怎么兜底、工具数量多了怎么优化选择准确率。

工具定义的最佳实践

【高频必问】怎么定义一个"好的"工具？踩过哪些坑？

🏢 出现公司：字节 / 阿里 / 美团

好的工具定义就像写招聘JD——明确说明"你是干什么的"“什么时候该找你”“什么时候别找你”“参数都是什么含义”。常见坑：参数名写成 q、id 模型不知道填什么；没加枚举约束模型编出不存在的选项；两个工具功能重叠导致模型反复纠结。

原则：工具描述宁可啰嗦不能模糊。每个工具的 description 要包含使用场景、输入输出说明、边界条件。参数要有类型、描述、是否必填、枚举值约束。

# 反面示例：模型根本不知道搜什么
{
    "name": "search",
    "description": "搜索",
    "parameters": {"q": {"type": "string"}}
}

# 正面示例：像JD一样写清楚
{
    "name": "search_internal_docs",
    "description": """搜索公司内部技术文档库。
    使用场景：用户询问公司内部产品、API、技术规范、内部流程时。
    不适用场景：通用知识问题、代码语法问题、外部公开信息。
    返回：匹配文档的标题、摘要和文档链接，最多5条。""",
    "parameters": {
        "query": {
            "type": "string",
            "description": "搜索关键词，用自然语言描述要查找的内容",
            "required": True
        },
        "category": {
            "type": "string",
            "enum": ["api", "architecture", "guide", "faq"],
            "description": "文档分类，缩小搜索范围",
            "required": False
        }
    }
}

工具调用失败的错误处理

【高频追问】工具调用失败了怎么办？错误处理策略是什么？

🏢 出现公司：字节 / 阿里 / 蚂蚁

分层处理，别一报错就返回给用户：

• 第一层（瞬时错误）：网络超时、限流等，指数退避重试2-3次。
• 第二层（参数错误）：格式不对、缺参数，把错误信息返回给Agent，让它自己修正后重试。
• 第三层（业务错误）：查不到数据、无权限，把信息给Agent让它决定下一步——是问用户还是换个方式。
• 第四层（安全拦截）：模型瞎调用危险工具（如未确认就删数据），直接拦截并插警告。

关键认知：错误信息也是Agent的Observation，它能据此自我修正，这才是"智能"的体现。

工具数量爆炸的优化

【进阶题】30个工具注册进去，选工具准确率下降怎么办？

🏢 出现公司：字节 / 阿里

这是字节的高频题。工具越多，选择准确率越低——5个工具准确率约95%，20个就掉到七八十。三种优化方案：

• 分组路由：按业务域分组（研发组、数据组、协同组），先选大类再选具体工具，每级5-6个，准确率回到90%+。
• 意图预路由：先用小模型或规则判断用户意图，再给Agent暴露对应的工具子集。
• 动态注册：每轮对话只给5-8个相关工具，根据对话上下文动态调整。

---

五、RAG与Agentic RAG

RAG是面试中几乎100%会问的模块，尤其是做过RAG项目的候选人，面试官会往死里深挖工程细节。

RAG基础与工程化

【高频必问】你用的 embedding 模型结构是什么？输出向量维度是多少？

🏢 出现公司：小米 / 阿里 / 百度

这是RAG项目的"必考题中的必考题"。以 BGE-M3 为例：基于 XLM-RoBERTa 架构，输出维度1024，支持多语言、长文本（最多8192 token），同时支持稠密检索、稀疏检索（ColBERT）和多向量检索。

面试官会继续追问"为什么选这个模型"“和OpenAI text-embedding-3对比过吗”“向量数据库怎么构建的”“用的什么索引（HNSW/IVF）”。必须对自己项目中的每个技术选型有清晰的理由。

---

【经典坑题】RAG 知识库上线后文档更新了怎么办？不重建全量就搞不定？

🏢 出现公司：小米 / 字节

小米经典面试题。只回答"找到变了的chunk更新其向量"是不够的。面试官会追问：“内容变了，chunk边界还和原来一样吗？”

正确方案：用hash检测变更——对每个文档计算hash，只处理hash变化的文档；对变更文档重新分块，先删后增——先删除该文档旧的所有向量，再插入新的；对于只是metadata变化的，可以直接更新不需要重新embedding。

如果chunk边界因为内容增删而移动，旧chunk和新chunk无法一一对应，必须整文档级别的删除重建，不能按chunk粒度更新。

Chunk分块策略

文档类型	推荐分块方式	Chunk Size	注意事项
代码文件	按函数/类分块，保留缩进	函数粒度	保留import和类定义上下文
Markdown	按标题层级分块	256-512 token	保留标题路径作为metadata
PDF长文	按段落+语义边界	512 token，重叠10-20%	注意"第三条第二款"别被切散
对话记录	按轮次分块	1-3轮	保留时间戳和角色信息

Agentic RAG：从固定管线到智能检索

【高频必问】Agentic RAG 和传统 RAG 有什么区别？

🏢 出现公司：字节 / 阿里 / 百度

传统RAG是固定管线：检索一次 → 生成回答。Agentic RAG 把检索当作Agent可调用的工具之一，Agent自己决定何时检索、检索几次、检索结果够不够用。

核心区别在三点：传统RAG只检索一次，Agentic RAG可以多轮检索；传统RAG无法处理多跳问题，Agentic RAG可以链式检索多个来源；传统RAG检索失败就直接用不完整信息生成，Agentic RAG可以调整检索策略重试。

字节会追问"Query Rewrite算不算Agentic"——算，因为Query改写本身就是Agent的主动决策行为。还会问"Agentic RAG成本怎么控制"——通过设置最大检索轮次、检索结果质量判断提前终止、缓存常见查询结果来控制。

---

【进阶追问】RAG 为什么要加 Rerank？Recall@K 和 Precision@K 怎么取舍？

🏢 出现公司：字节

向量检索速度快但精度有限，可能召回语义相关但不够精准的结果。Rerank用更重的Cross-Encoder模型对召回的Top-K结果重新打分排序，把最相关的排到前面。

取舍逻辑：Recall@K 看的是"相关文档有没有被召回"，K设大一点（如20-50）保证不漏；Precision@K 看的是"召回的里面有多少相关的"，通过Rerank把K缩到3-5个高精度结果喂给LLM，减少噪声、节省Token。

如果BM25已经很好（关键词匹配场景），向量检索仍有必要——它能覆盖语义相似但用词不同的case。两者融合（hybrid search）效果最佳。

---

六、记忆系统与上下文管理

记忆系统是区分"做过Demo"和"做过生产级Agent"的关键分水岭。面试官特别爱问"多轮对话memory怎么设计"“上下文窗口满了怎么办”。

分层记忆架构

【高频必问】多轮对话里 memory 应该怎么设计？

🏢 出现公司：字节 / 腾讯 / 阿里

不能简单把所有历史对话塞进上下文，要分层设计：

• 短期记忆（工作记忆）：当前对话的最近几轮，完整保留，放在上下文末尾。
• 会话摘要：中间轮次的对话用模型压缩成几句话，代替原始内容，减少Token占用。
• 长期记忆（外部存储）：用户偏好、确认过的事实、关键决策，结构化存入向量数据库或KV存储，下次对话按需检索。

字节会追问"为什么要分层"——因为不同信息的访问频率和重要性不同，全塞上下文会导致Token爆炸和Lost-in-the-Middle效应；还会问"项目级规则、用户偏好、会话上下文怎么区分"——按生命周期和更新频率区分。

上下文压缩策略

【进阶题】上下文窗口满了怎么办？压缩策略是什么？

🏢 出现公司：字节 / 阿里

别等满了再处理，平时就要做分层压缩。字节实习面试会追问"为什么要采用三层压缩策略，每一层压缩的内容一致吗，分别在什么条件触发"：

• 第一层（清理）：删除无用信息，如中间轮次的大段工具返回数据。触发条件：上下文超过窗口的60%。
• 第二层（摘要）：用模型把中间对话压缩成摘要。触发条件：清理后仍超过70%。
• 第三层（提取）：把关键信息（用户偏好、确认事实）提取为键值对存入外部。触发条件：摘要后仍超过80%。

核心原则：最新信息留完整，中间的压缩，重要的结构化存储。如果压缩过度导致效果下降，通过评测集对比压缩前后的任务完成率来发现，然后调整压缩阈值。

---

七、多Agent协作与MCP/A2A协议

多Agent系统设计

【高频必问】多Agent协作有哪些常见模式？什么时候拆多Agent？

🏢 出现公司：字节 / 阿里云 / 蚂蚁 / 小红书

常见模式有三种：流水线模式（Agent A的输出是B的输入，如"研究→写作→审校"）；黑板模式（多个Agent共享一个上下文黑板，各自读取和写入）；辩论模式（多个Agent对同一问题给出不同方案，再由仲裁Agent选择最佳）。

什么时候该拆？一个Agent角色冲突（既搞创意又做审核）；需要访问不同权限的数据源；不同环节需要不同推理策略。什么时候不该拆？一个Agent加好Prompt能解决的事就别拆——3个以上Agent协调成本指数级上升，容易互相甩锅。

字节追问"多Agent如何分工、通信和终止"“如何避免多个Agent相互扯皮或死循环”——通信必须用结构化消息协议而非纯文本，加共享黑板存上下文，设全局超时和终止条件。

MCP与A2A协议

【2026新热点】MCP 是什么？和原始 Function Calling 有什么区别？为什么要标准化？

🏢 出现公司：腾讯 / 字节

MCP（Model Context Protocol）是 Anthropic 于2024年底发布的开放标准，定义了 LLM 应用与外部工具/数据源之间的统一通信协议。采用 Client-Server 架构：MCP Server 封装工具能力，MCP Client（Agent）通过标准协议连接。

和原始 Function Calling 的区别：Function Calling 是模型层面的能力（模型决定调用什么），MCP 是传输和发现层面的标准（工具如何注册、发现、通信）。过去每接一个工具就要写定制集成代码，MCP 让工具即插即用——一个 MCP Server 可以被任何支持 MCP 的 Agent 复用。

A2A（Agent-to-Agent）协议则解决多Agent之间的通信标准问题，定义了Agent之间如何发现彼此、委派任务、返回结果。腾讯特别爱考这个方向。

Agent框架对比

【高频必问】LangGraph 和 LangChain 的区别是什么？什么时候必须用 LangGraph？

🏢 出现公司：字节 / 腾讯 / 阿里

LangChain 的 Chain 是线性流水线，数据单向流动，不支持循环。LangGraph 是有向图状态机，支持分支、循环、并行和条件路由——ReAct的"思考→行动→观察"循环必须用LangGraph才能表达。

什么时候必须用LangGraph：需要动态决策和迭代的复杂Agent场景（ReAct循环、多Agent协作带条件跳转、需要回溯重试的工作流）。简单的一次性RAG问答用Chain就够了。

字节会继续追问"为什么选LangGraph而不是AutoGen、CrewAI或手写状态机"——LangGraph 的状态管理更透明可控，支持持久化和人在回路；AutoGen偏多Agent对话但状态管理弱；CrewAI偏角色扮演适合简单流水线；手写状态机灵活但维护成本高。

框架	核心特点	适合场景	局限
LangGraph	有向图状态机，支持循环/分支/持久化	复杂Agent工作流、ReAct循环	学习曲线较陡
LangChain	链式调用，组件丰富	简单RAG、线性流程	不支持循环，复杂Agent力不从心
AutoGen	多Agent对话框架	多Agent协作讨论	状态管理弱，调试困难
CrewAI	角色驱动的任务分配	简单流水线分工	灵活性不足

---

八、评估体系与可观测性

评估是面试中容易被忽视但极其加分的模块。能说出"我怎么知道我的Agent好不好用"的候选人，在面试官眼里立刻从"跑过Demo"升级到"做过生产"。

【高频必问】怎么评估一个 Agent 好不好？评估体系怎么搭？

🏢 出现公司：字节 / 阿里 / 快手

分三层评估：

• 第一层（单元测试）：工具调用准不准、输出格式对不对、安全规则触没触发，跑一次过了就行。
• 第二层（任务级评估）：核心看任务完成率、路径是否最优、Token消耗、耗时、抗攻击能力。同一个输入跑10次看统计指标，因为Agent是非确定性的。
• 第三层（线上评估）：用户满意度、留存率、报错率、每次对话成本。

字节面试有一个经典的崩盘点：候选人说Recall@5是0.81，面试官问"这个数字是好是坏？baseline是什么？评测集分布怎么样？"——没有baseline的指标毫无意义。评测集要覆盖标准场景、边界场景、对抗场景，每月更新新案例。

---

【进阶题】非确定性的 Agent 系统怎么测试？

🏢 出现公司：字节 / 阿里

传统软件非对即错，Agent是概率性的，不能要求100%准确。分层测试：确定性测试验证格式、参数类型、安全规则；统计测试同一输入跑10-20次看工具选择准确率和任务完成率；对抗测试注入攻击、模糊输入、边界情况。定合理SLO（如工具准确率90%+），每次迭代跑回归不低于基线即可。

全链路追踪

🔑 生产环境必做：上线前必须接入全链路追踪（LangSmith / Langfuse / 自建）。没有追踪的Agent系统就是盲人摸象，出了问题根本不知道哪一步坏了。追踪要记录每一步的Thought、Action、Observation、Token消耗、耗时。排查时先确认问题类型（答错/卡死/调错工具/报错），看追踪日志定位到出问题的步骤，测试环境复现，改Prompt或工具定义，回归测试后灰度上线。

---

九、安全护栏与成本控制

安全护栏设计

【高频必问】怎么设计安全护栏？Agent调了数据库 DELETE 怎么办？

🏢 出现公司：字节 / 蚂蚁 / 阿里

纵深防御，多层护栏：

• 输入层：敏感信息脱敏、Prompt注入检测、速率限制。
• 推理层：按用户角色分配工具集，参数黑白名单校验，高危操作卡审批，Token预算监控。
• 执行层：工具单独配权限，结果做安全检查，操作保证幂等，超时熔断。
• 输出层：敏感信息打码，内容安全检测，格式校验。

对于DELETE删库这种高危操作，三层保险：System Prompt明令禁止非只读SQL；数据库工具内部做SQL解析，检测到危险操作直接拒绝；所有写操作必须用户二次确认，留全审计日志。

Prompt注入防御

【安全高频】怎么防 Prompt 注入攻击？

🏢 出现公司：字节 / 蚂蚁

Agent能调用工具，注入攻击的危害远大于纯文本场景。分层防御：入口层做关键词检测拦截常见注入话术，用户输入用特殊标签包裹与系统指令隔离；系统层把System Prompt钉在最前面，强调"不能改角色、不能听用户伪造指令"；运行时检测输出异常和工具参数异常；执行层高危操作人工确认。

成本控制

【场景题】一次对话花了10万Token怎么办？怎么控制Agent调用成本？

🏢 出现公司：字节 / 阿里

成本控制要从系统设计阶段就嵌入：事前每轮设Token上限，最大推理轮次卡死，模型分层用（简单任务小模型、复杂任务大模型），Prompt瘦身，工具按需分组暴露，缓存常见查询；事中设告警阈值，Token超限触发降级（自动压缩上下文、切换小模型），超上限强制终止；事后每天看报表，找最费钱的对话模式，针对性优化。

---

十、系统设计真题

系统设计题是大厂面试的"压轴题"，通常在二面或三面出现，考察综合能力。

【系统设计】设计一个AI爬取字节视频的Agent系统，怎么设计？

🏢 出现公司：字节

这是一道典型的字节系统设计题。核心设计要点：

• 意图理解层：解析用户的爬取需求（关键词、时间范围、视频类型）。
• 规划层：Plan-and-Execute模式，先制定爬取计划（搜索→筛选→下载→结构化→存储）。
• 执行层：ReAct模式，每步灵活调整。工具包括：搜索API、视频信息解析、下载器、内容理解（多模态模型）、数据清洗、存储写入。
• 异常处理：反爬触发时自动降速/换IP/等待重试；视频解析失败时记录bad case跳过；存储失败时本地暂存后重试。
• 安全合规：遵守robots.txt，限速控制，不爬取隐私内容，所有操作留审计日志。

---

【系统设计】阿里要求画 Agent 的路由/管理/执行三层架构，怎么画？

🏢 出现公司：阿里

阿里面试特色——要求你白板画出三层架构图：

• 路由层（Router）：接收用户请求，做意图分类和请求路由，决定交给哪个Agent或Workflow处理。可以用规则+小模型实现。
• 管理层（Manager/Orchestrator）：管理Agent的生命周期、状态、记忆、工具集分配。负责多Agent协调、任务拆解、结果汇总。对应LangGraph的State Graph。
• 执行层（Executor）：具体的Agent执行单元，包含LLM调用、工具调用、ReAct循环。每个Executor有独立的工具集和记忆。

阿里强调"落地瓶颈与务实方案"——要说清楚每层的性能瓶颈在哪（路由层延迟、管理层Token消耗、执行层LLM调用耗时），以及对应的务实解法（路由层用缓存、管理层做上下文压缩、执行层用模型分级）。

---

【系统设计】设计一个 Coding Agent，和 Claude Code / Codex 有什么区别？

🏢 出现公司：字节

字节2026年Coding Agent方向的高频题。核心设计要点：

• 规划层：面向复杂任务先做Plan，拆解为子任务（读代码→分析→修改→测试→提交）。
• 多Agent编排：不同子Agent负责不同环节（代码理解Agent、代码修改Agent、测试Agent），每个Agent有专属工具集，不能所有子Agent共享工具——因为工具太多会降低选择准确率，且不同环节需要的工具完全不同。
• 上下文管理：三层压缩策略，处理大型代码库的上下文溢出问题。如果用户要求在原任务基础上新增功能，需要恢复之前的会话状态——通过检查点（checkpoint）机制持久化Agent状态。
• 和Claude Code的区别：Claude Code的Memory机制做了项目级、用户级、会话级的隔离，能跨会话记住项目规范和用户偏好。你的Coding Agent需要在Memory设计上说明差异。

---

十一、备战路线

项目准备：极深挖策略

面试官对项目的追问深度远超想象。以RAG项目为例，你需要准备好以下问题的回答链：

• Embedding模型的结构是什么？输出维度多少？为什么选这个？
• 向量数据库怎么构建的？用什么索引？参数怎么调的？
• Chunk策略是什么？为什么这么切？业务语义边界怎么处理？
• 检索效果怎么样？Recall@K是多少？Baseline是什么？评测集怎么构造的？分布怎样？
• 上线后文档更新怎么办？增量更新还是全量重建？
• 不同文档内容冲突了怎么处理？有没有版本控制？

以Agent项目为例，追问链更长：

• Agent整体流程是什么？为什么这么拆？哪些是确定性Workflow，哪些交给LLM？
• 工具调用怎么设计的？Schema怎么定义？失败怎么兜底？危险工具怎么防？
• 模型不听指令怎么办？是Prompt问题还是模型能力问题？怎么定位的？
• 死循环怎么检测？reflection失败3次后怎么处理？
• 多Agent怎么分工？通信协议是什么？怎么终止？怎么防扯皮？
• 用的什么框架？为什么选它？能力不满足时怎么扩展？

八股准备：背原理不背答案

大厂面试官反感"背八股答案"，要求你能用自己的话讲清楚原理。重点攻克以下模块：

模块	核心知识点	高频追问
Transformer	自注意力、位置编码（RoPE）、LayerNorm	“为什么除以sqrt(d_k)”“RoPE怎么实现相对位置”
微调	LoRA、P-Tuning、Prefix Tuning、全参SFT	“LoRA怎么初始化”“为什么优先微调Q/K/V/O”
对齐	SFT、RLHF、PPO、DPO、GRPO	“RLHF三阶段”“GRPO为什么不需要Value网络”
推理优化	KV-Cache、MHA/GQA/MQA/MLA、PD分离	“KV-Cache怎么加速”“GQA和MQA区别”
分布式训练	TP、PP、DP、DeepSpeed ZeRO三个Stage	“ZeRO Stage 1/2/3分别切什么”

代码手撕：LeetCode + 大模型核心模块

手撕代码分两类：算法题以LeetCode Medium为主（反转链表、二叉树层次遍历、编辑距离、括号生成、不同路径变式），偶尔出Hard（地下城游戏）。大模型核心模块手写是加分项——手写MHA（多头注意力，要求用numpy不用torch）、手写位置编码、手写ReAct Agent核心循环。

💡 面试心态：现在人人都会用AI写周报、做PPT，但你要是懂ReAct循环为什么能防死循环、知道怎么优化Lost-in-the-Middle、清楚怎么控成本做安全护栏，那你就不再是AI的用户，而是AI的工程师。面试的时候，这就是你甩开别人的底气。

---

以上就是2026年大厂AI Agent面试的核心内容。面试的趋势很明确：从"你知道什么"转向"你做过什么、踩过什么坑、怎么解决的"。准备时不要只背概念，要把每个知识点和自己的项目经历绑定起来，准备好完整的"问题→定位→方案→验证"故事链。

祝大家秋招顺利，offer拿到手软。

---

标签：AI Agent / 大模型面试 / ReAct / RAG / Tool Calling / LangGraph / MCP协议 / 秋招2026

如果觉得有帮助，点个赞再走呗 ~