前端转 AI Agent 面试避坑指南：面试官真实槽点全拆解

很多“前端转 AI Agent”的候选人并不是不聪明，也不是基础太差；真正的问题是：

会拼积木，但解释不了机制：能说出 LangChain / function calling / RAG，却说不清“为什么要这么做、怎么保证稳定、怎么做评估”。
会做 Demo，但缺工程闭环：做过一个聊天 UI + 调个模型接口，但没有“可靠性、观测、权限、成本、回滚”的系统设计。
会写 prompt，但不会把系统变得可预期：prompt 不是作文，而是约束 + 结构 + 测试用例。

这篇文章按面试官最常见的“槽点”来拆解：你要补的不是“更多名词”，而是“把 Agent 当成线上系统”去设计。

先把目标说清楚：AI Agent 面试到底在考什么？

面试官通常不是要你背一套定义，而是在判断：

你是否具备 把不确定的 LLM 变成可控系统 的能力。
你是否能在 失败不可避免 的前提下，仍然交付稳定体验。
你是否能说清楚一个 Agent 项目：输入是什么、状态怎么流、失败怎么兜、指标怎么验。

把 Agent 粗暴理解为“LLM + 工具”会导致答题方向全错。更接近真实的定义是：

AI Agent = 在约束条件下，围绕目标执行任务的系统。它必须管理状态、选择行动、调用工具，并对失败负责。

所以面试官真正关心的往往是：

状态与记忆：上下文窗口不够怎么办？多轮对话如何持久化？多用户如何隔离？
规划与纠错：任务拆错了怎么办？怎么检测跑偏？如何让系统可回收（stop condition）？
工具调度：超时、限流、重试、幂等、并发冲突怎么处理？
评估与观测：你怎么证明“变好了”？日志/追踪/采样/回放怎么做？
安全与权限：prompt 注入怎么防？工具调用越权怎么控？敏感数据如何最小暴露？

槽点 1：名词很多，但问两句就露馅（“只会搭积木”）

典型表现

你能说“我用 LangChain 的 Agent + Memory + Tools”。
面试官追问：为什么要 Memory？为什么用向量库？你怎么做窗口管理？
你回答变成“因为大家都这么做”。

面试官真实判断标准

面试官会用 3 个问题迅速判断你是不是“理解机制的人”：

你怎么决定把哪些信息放进上下文？
你怎么判断模型这次调用“可能不可靠”？
你怎么把一次失败变成可观察、可复盘、可改进的证据？

如果你答不出来，就算你写过 10 个 demo，也会被归类为“调用型”。

你应该怎么补：用“机制三件套”回答

你需要把回答从“组件名”切到“机制与策略”。一个可复用的结构是：

约束（Constraint）：窗口有限、时延要求、成本预算、隐私边界。
策略（Strategy）：窗口管理策略、检索策略、工具选择策略。
验证（Verification）：通过指标和测试用例证明策略有效。

举个最常见的“记忆”追问，你可以这样答：

我们把记忆分三层：
短期：最近 N 轮对话原文（用于保持语境）
工作记忆：对话摘要 + 结构化状态（比如用户目标、限制条件、已完成步骤）
外挂：向量检索的证据片段（用于补充事实、避免幻觉）
窗口管理采用“摘要 + 最近对话 + 证据注入”的组合，摘要由可回放的 summarizer 产生，并且对摘要有一致性检查（例如必须保留需求/约束/已完成步骤）。效果用两个指标验证：回答引用证据比例、以及多轮任务的完成率。

这段回答不需要背，关键是你能讲清楚：分层、策略、指标。

槽点 2：项目讲不清闭环（“有界面、没系统”）

典型表现

你展示的项目像这样：

“我做了一个 AI 助手：前端用 Vue/React，后端调用模型 API，然后返回回答。”

面试官的内心 OS 是：这叫“把 ChatGPT 接到网页上”，不叫 Agent。

面试官会追问的 5 个维度

下面 5 个维度，任何一个讲不清都很致命：

任务定义：Agent 的“目标”是什么？成功/失败如何判定？
状态流转：一个请求从输入到输出，中间有哪些状态？是否可恢复？
错误处理：模型错、工具错、外部 API 错、用户输入错，各自怎么兜底？
观测与复盘：你能回放一次失败吗？能定位是 prompt、检索、工具还是业务规则的问题吗？
成本与延迟：一次任务要几次模型调用？token 成本多少？P95 延迟多少？

一个“含金量叙事模板”：用 Run（一次执行）来讲项目

把“项目介绍”从“技术栈”变成“执行链路”。推荐你用 Run 作为最小叙事单位：

输入：用户意图 + 约束（比如预算、时间、权限）
构建上下文：短期对话 + 摘要 + RAG 证据
规划：产出结构化计划（可被校验）
执行：工具调用（带幂等、超时、重试）
校验：结果一致性检查（schema/业务规则/引用证据）
输出：最终回答 + 下一步建议
记录：trace、token、latency、tool errors、用户反馈

你可以把项目的核心“硬能力”压缩成一句话：

“我做的不只是回答，而是一次可追踪、可评估、可回放的任务执行。”

槽点 3：不会做评估与可靠性（“效果靠感觉”）

典型表现

“我觉得效果还可以。”
“用户用起来挺顺的。”

这在面试里等同于：我没有能力把系统迭代成可用产品。

你需要掌握的最小评估体系

不用上来就搞复杂的 eval 平台，但至少要能回答：我怎么知道它变好了？

建议你在项目里内置 4 组指标：

任务指标：完成率、平均轮次、失败原因分布
模型指标：每次 run 的调用次数、token、温度/模型版本、拒答率
工具指标：成功率、超时率、重试次数、幂等冲突次数
体验指标：P50/P95 延迟、用户点赞/点踩、转人工比例

你需要掌握的最小可靠性设计

Agent 的失败不可避免，但“失败是否可控”决定了你是工程师还是 demo 作者。

一套面试很加分的可靠性答法：

超时：每个 tool 调用单独 timeout，整体 run 也有 deadline。
重试：指数退避 + 上限 + 只对可重试错误重试。
幂等：对有副作用的工具加 idempotency key。
降级：工具不可用时返回“解释型答复 + 让用户补信息 + 建议人工路径”。
隔离：多用户状态隔离，避免串话；并发控制避免资源抢占。

面试官最常问的 12 类问题（含“想听到什么”）

下面不是题库，而是“判断维度”。你可以用它做自测：

1) 记忆与上下文

问法：上下文窗口不够怎么办？
想听到：摘要/结构化状态/RAG 证据注入；并说明如何验证摘要不丢关键信息。

2) RAG 与幻觉控制

问法：为什么你的 RAG 会答错？怎么改？
想听到：切块策略、召回/精排、引用证据、拒答策略、回放分析。

3) 规划（Planning）

问法：Agent 拆任务拆错了怎么办？
想听到：计划可校验、失败回退、重新规划、stop condition。

4) 工具调用（Function Calling）

问法：模型给错参数怎么办？
想听到：schema 校验、自动修复回路、对齐错误信息、限制工具能力。

5) 并发与限流

问法：100 人同时用会发生什么？
想听到：队列/令牌桶/并发上限；按用户/租户隔离；缓存。

6) 可观测性

问法：你怎么定位一次“答非所问”？
想听到：trace + 分阶段日志（检索、规划、工具、输出），并能回放。

7) 安全

问法：prompt 注入怎么防？
想听到：最小权限、工具白名单、敏感信息脱敏、引用证据与策略提示。

8) 成本

问法：怎么把 token 成本降下来？
想听到：摘要、检索、缓存、减少模型调用次数、模型分层（小模型做分类，大模型做生成）。

9) 质量保证

问法：你怎么测试 Agent？
想听到：固定数据集 + 离线回放 + 合成对话；输出 schema 校验。

10) 产品化

问法：你怎么把 demo 做成可用功能？
想听到：失败提示、人机协作、反馈闭环、迭代节奏。

11) 数据治理

问法：用户数据怎么存？能不能训练？
想听到：数据隔离、权限、合规意识、可删除、最小留存。

12) 工程边界

问法：什么时候不该用 Agent？
想听到：规则系统更稳的场景、可预测性优先、风险控制。

你处在哪个段位？一个“可验证能力模型”

很多人卡在“感觉会了”，但面试需要你展示“我在哪、缺什么、怎么补”。

L0：API 接入者

能做：调用模型 API、做一个聊天 UI
缺失：上下文策略、评估、可靠性

L1：Prompt 操作员

能做：写 system prompt、few-shot、结构化输出
缺失：工具与状态的工程化、失败处理

L2：RAG + 工具的应用工程师

能做：RAG、tool calling、基础日志
缺失：计划与纠错、并发/限流、权限

L3：Agent 系统工程师（面试想要的起点）

能做：规划/执行分层、失败回退、trace、评估集
输出：能讲清楚一个 run 的状态机，能给出指标

L4：产品化负责人

能做：多租户、成本优化、在线 eval、A/B、持续迭代
输出：能把系统做成“团队可维护”的能力平台

你不需要一上来就做到 L4，但至少要能把自己从 L0/L1 推到 L2/L3。

30 天补短计划：用一个项目把“槽点”一次性补齐

下面这套计划的特点是：每周都有可交付物、每个交付物都能验证。

第 1 周：把“对话”做成“有状态的任务”

交付物：一个最小 run 状态机（输入 → 构建上下文 → 输出）
要求：
- 输出必须满足 schema（JSON 或明确结构）
- 每次 run 记录：模型、token、latency、用户 id
验证：随机抽 30 次 run，能回放并解释每一步

第 2 周：加入 RAG，但把“引用证据”变成硬约束

交付物：RAG 检索 + 引用片段 + 拒答策略
要求：
- 回答必须引用检索片段（至少给出处/标题/片段）
- 检索不到时必须拒答，并建议用户补信息
验证：做 50 条 eval 集，统计引用率与准确率

第 3 周：加入工具调用，并把可靠性当成第一需求

交付物：2-3 个 tool（例如：搜索、数据库查询、生成文件）
要求：
- 每个 tool：timeout + retry + 幂等 key（有副作用时）
- 工具失败必须能回到模型，让它做“修复或降级”
验证：人为制造 30% 工具失败，系统仍能给出可用结果/解释

第 4 周：加入规划与纠错，让 Agent 变得可控

交付物：Planner/Executor 分层（哪怕是最简实现）
要求：
- 计划必须是可校验结构（步骤、输入、依赖、成功条件）
- 有 stop condition（最多 N 步 / deadline）
- 有“跑偏检测”：输出不满足成功条件就回退或重规划
验证：给 20 条复杂任务，统计完成率与平均步数

如果你能把这 4 周做完，并把指标与 trace 拿出来讲，面试官通常会把你从“调用型”直接升级到“工程型”。