22道AI Agent 工程师必会的面试题，别啥都不会就出去找工作

背景

这篇文章准备点AI Agent方面的一些面试题，与其说是文章，倒不如说是笔记，方便以后自己可以来复习巩固一些知识点，为什么做这个事情？因为夏天到了嘛，熟悉我的朋友肯定知道，哥们之前连续俩夏天都成为了待业老登，今年虽说目前还安全，但后面谁知道呢？所以先准备起来，省的自己到时候啥也没准备就去外面和别人抢工作，怎么可能抢的过

再说面试题，你说懂这些理论的东西有没有用呢，我觉得还是要掌握一些，不然人人都会用AI做东西，都会用AI生成代码去提效，那么你去面试，你的竞争力在哪？长得比别人帅还是token比别人多？面试官根据什么来选你而不是选别人？我觉得这方面就需要我们多去掌握一些平时可能不会去思考的东西，目的就是将来某一天，你跟面试官面对面坐一起的时候，他问你啥，你不会只是笑一笑，然后说一句我不知道，这篇文章一共八个部分，22个问题，建议看之前泡杯咖啡，静下心来慢慢看

1. LLM 底层认知

Q1. 请解释一下 LLM 的上下文窗口是什么，以及 Lost-in-the-Middle 现象是怎么发生的？

上下文窗口是 LLM 一次能处理的最大 Token 数量，由 Transformer 架构中的注意力机制决定。窗口内的 Token 之间通过 Self-Attention 相互可见，窗口之外的信息模型无法感知。

Lost-in-the-Middle 现象 是指：当输入上下文很长时，模型对开头和结尾 的信息利用率最高，而对中间部分的信息利用率显著下降，模型在信息位于文档开头或结尾时准确率约有 70-80%，但位于中间时可能降到 40-50%。

原因： 注意力分布不均匀，模型倾向于关注序列早期（primacy bias）和近期（recency bias）的内容，中间部分容易被稀释。

如何预防

关键信息前置/后置：System Prompt 放在最前面，重要指令放开头，最新信息放末尾
结构化 Prompt：用 Markdown/XML 标签帮助模型感知内容边界
滑动窗口 + 摘要：长对话定期做 Summarization，把中间部分压缩后放到开头
RAG 结果排序：检索到的文档按相关性重排序，最相关的放首尾
自适应裁剪：优先丢弃中间部分的低价值历史对话

Q2. Temperature、Top-P、Top-K 这三个参数有什么区别，在实际部署中怎么调？

核心区别：

参数	作用	数值含义
Temperature	控制概率分布的平滑度	越低越确定性（0 = greedy），越高越随机
Top-P (Nucleus Sampling)	累积概率超过 P 的最小 token 集合	0.9 = 取累积概率 90% 的 token 候选集
Top-K	只保留概率最高的 K 个 token	K=40 表示只从概率前 40 的 token 中采样

实际调参建议：

场景	Temperature	Top-P	Top-K
代码生成 / 函数调用	0～0.2	0.9～1.0	不启用
事实问答 (RAG)	0～0.3	0.9	不启用
创意写作 / 头脑风暴	0.7～0.9	0.9～0.95	40～50
客服回复（标准化）	0.1～0.3	0.85	不启用
Agent Tool Selection	0～0.1	不启用	不启用

建议

Agent 的 Tool Calling 阶段建议 Temperature 接近 0，确保工具选择稳定，减少幻觉调用
生成回复阶段可以略微提升 Temperature，让表达更自然
不要同时使用 Top-P 和 Top-K，通常选 Top-P 更通用
线上建议做 0.05～0.1 粒度的 A/B 测试来微调

Q3. 模型幻觉是怎么产生的？Agent 场景下如何缓解？

幻觉的根源：

数据层面：预训练数据中的错误 / 矛盾信息被模型内化
架构层面：模型本质是"下一个 Token 预测"，不是事实数据库
对齐层面：RLHF 鼓励模型"有帮助"，有时会压制"我不知道"
知识截止：模型训练后的新知识，它只能"猜"

Agent 场景下的幻觉风险（比纯文本严重得多）：

工具幻觉：模型调用了一个实际不存在的工具或参数
参数幻觉：给工具传入正确的参数名但参数值不存在（如传入一个假的城市代码）
结果幻觉：工具返回了数据，但模型在总结时曲解了数据
行动幻觉：模型认为已经调用了工具，但实际上没有（自以为做了行动但没执行）

缓解手段

手段	原理
Tool Calling + 结构化输出	让模型输出结构化 JSON 而非自由文本
约束解码 (Grammar Guidance)	用 JSON Schema / GBNF 约束模型输出
Retrieval-Augmented Generation	给模型提供事实上下文，减少"编造"需求
Self-Consistency / 多路验证	多次推理取多数答案
引用溯源	要求模型标注信息来源，无法溯源的弃用
Confidence Scoring	让模型给出置信度，低分的不展示
Human-in-the-Loop	关键决策（支付、删除）由人工确认

2. Agent 架构与模式

Q4. 手写一个 ReAct Agent 的核心循环

max_iterations的作用

防止无限循环和Token爆炸，Agent可能出现不断调用工具的死循环，每次循环都会消耗 Token，没有上限的话可能一次对话消耗数百万Token

并行Tool Calling怎么实现

如果工具之间没有依赖关系，可以让 LLM 在一次推理中生成多个 tool_call，然后 concurrently 执行。类似 Promise.all / asyncio.gather

Q5. ReAct 和 Plan-and-Execute 有什么区别？各自适用什么场景？

维度	ReAct	Plan-and-Execute
执行方式	边想边做，逐步推理	先制定完整计划，再逐步执行
灵活性	高，随时可改方向	低，计划制定后不易变
可解释性	中间推理步骤可见	计划 + 执行步骤清晰
长任务表现	容易跑偏或死循环	结构清晰，适合长流程
规划开销	无显式规划成本	计划阶段需要额外 Token
错误恢复	天然支持（随时可调整）	需要重规划机制

场景选择

场景	推荐模式	原因
单步问答 / 简单查询	ReAct	不需要规划，查完即答
多步工具调用（如订票）	ReAct	每一步依赖上一步结果，需要动态决策
复杂文档生成（如周报）	Plan-and-Execute	先定结构再填充，保证完整性
代码修改 / 多文件重构	Plan-and-Execute	需要先理解整体再做修改
未知探索任务（如做研究）	ReAct	中间发现可能改变方向
故障排查 / Debug	ReAct	逐步缩小范围，灵活调整

实际生产中最常用的是两者的混合------初始化时先生成一个 High-Level Plan，但在执行每个步骤时用 ReAct 的模式做细粒度决策，遇到阻塞时允许重规划。这就是 Plan-and-Solve + ReAct 混合模式。

Q6. 你设计过Multi-Agent系统吗？讲讲你如何决定什么时候拆成多 Agent，以及 Agent 之间怎么通信？

什么时候该拆成多Agent？

角色冲突：单个 Agent 既要严格检查又要创意回答，角色矛盾
知识域隔离：需要访问不同的数据源/工具集，放一起导致 Tool 选择准确率下降
需要不同推理策略：一个 Agent 需要严谨的逐步推理，另一个需要快速直觉判断
跨系统边界：需要调用不同权限域的资源
可观测性要求：需要分别追踪每个环节的耗时和成功率

多Agent的缺点

多Agent增加了延迟、Token成本、协调复杂度
3个以上Agent的对话系统协调成本指数级上升
一个 Agent + 好 Prompt 能解决的问题，拆成多 Agent 是过度设计

Agent 通信模式

建议

Agent之间的消息需要结构化协议（不能纯文本对话，要定义消息 Schema）
需要超时机制（一个 Agent 卡住不能阻塞整个系统）
建议引入共享上下文（一个全局的黑板 / 共享 Memory），降低重复传递信息的 Token 成本

Q7. Agent死循环（Tool Loop）的检测和恢复策略有哪些？

死循环的典型表现：

反复调用同一个工具，传入不同参数但语义一样
A 工具和 B 工具互相调用，把对方的输出当成自己的输入
持续报错→重试→报错→重试
推理阶段不断「自我质疑」不产生行动

检测策略

恢复策略

策略	做法	适用场景
Prompt Intervention	插入一条 system message 提示 Agent 换个方向	轻微死循环
上下文截断	丢弃中间部分的冗余对话	Agent 积累了过多上下文
强制摘要	让另一个 LLM 压缩当前进展，重新启动循环	严重死循环
降级策略	退化为简单的问答模式，停止工具调用	无法恢复时
Human Handoff	转人工处理	以上都失败时

工程兜底 生产环境必须配置绝对兜底------达到最大轮次或 Token 预算上限后，强制结束并回复"当前无法完成，请尝试简化您的需求"或转人工。

3. Tool Calling与函数调用

Q8. 怎么定义一个"好的"工具？踩过哪些坑？

典型不好的工具定义

不好的原因是：描述太模糊，参数名意义不明，模型不知道什么时候该用

正确的定义

关键踩坑经验

坑	现象	解决
描述太短	模型不知道什么时候用这个工具	写清楚"何时调用 / 何时不要调用"
参数名太短	q / id / val 模型不知道填什么	用完整语义的名词
缺少类型约束	传入字符串 "123" 但 API 要数字	严格标注 JSON Schema 类型
枚举值不全	模型自己编造不在枚举里的值	`enum` 字段约束
缺少默认值	模型不传可选参数导致不确定性	给合理默认值
没有边界描述	用户问非技术问题也调了知识库	在 Description 中声明排除场景
工具太多	Agent 一次选错工具的几率上升	工具超过 20 个需做分组/层级暴露
工具竞食	两个工具功能重叠，模型反复纠结	保证工具职责互斥

工程原则： 工具定义的 Description 是在给模型写说明书，写清楚这是什么、什么时候用、什么时候不用、参数是什么意思。把工具定义当成API文档来写，宁可啰嗦，不能模糊

Q9. 工具调用失败了怎么办？你的错误处理策略是什么？

分层错误处理策略

代码实现

关键认知： 工具错误信息是 Agent 的"新 Observation"，输入给 LLM 之后的 LLM 行为决定了 Agent 是否智能，一个好的 Agent 会分析错误原因并修正参数重试

Q10. 如果给 Agent 注册了 30 个工具，Tool Selection 准确率下降怎么办？

这是Agent工程中非常实际的问题------模型在太多工具中选对的难度会指数级上升。

优化策略

工具分组

基于意图的预路由

动态工具注册

Tool Embedding 检索

工具聚合（Composite Tool）

把多个细粒度工具封装成一个粗粒度工具，内部做二次路由，比如：

一般来说，工具数从 5 个增加到 20 个，Tool Calling 准确率从约 95% 下降到约 75-80%。分组到每级 5-8 个可以恢复到 90%+

4. Prompt Engineering

Q11. 你如何设计和迭代一个 System Prompt？遇到过什么反直觉的问题？

System Prompt 设计方法论

示例架构

反直觉的踩坑经验

坑与反直觉点	原因	对策
越短的 System Prompt 效果越好	长 Prompt 稀释了关键指令	删除所有非关键内容，重要的放前 20%
说「不要做 X」有时反而触发 X	模型关注到负面描述的 Token	用正向引导替代负面禁止
放尾部的规则常被忽略	Lost-in-the-Middle 现象	最重要的规则放最前面
具体指令比抽象原则有效	"回答不超过 3 点"比"要简洁"有效	用可量化的约束
长 Prompt 大幅增加 Token 成本	每次对话都要带 System Prompt	定期评估"每条规则是否值得它的 Token"

Q12. 你怎么设计 Prompt 来防止 Agent 被用户注入攻击（Prompt Injection）？

Prompt Injection 在 Agent 场景下特别危险，因为 Agent 有工具调用能力，攻击者可能诱使 Agent 执行删除数据、泄露信息等操作

防御策略（分层防御）

Prompt 级别的具体实现

额外的工程手段：

对用户输入做 特殊字符转义 （如将 <> 转义为实体）
在 Agent 的 Tool Execution 层再做一次参数校验（不信任任何来自 LLM 的内容）
关键操作（支付、删除、写操作）的 Tool 在执行前先调用一个 Permission Check Tool 做前置审批

5. RAG 与记忆管理

Q13. 你设计过 RAG 系统吗？讲一下 Chunk 策略是怎么选的？

Chunking 策略决策树

关键参数

参数	推荐值	说明
Chunk Size	256～512 tokens	太小信息不完整，太大检索噪声多
Overlap	10%～20% of chunk size	避免关键信息正好被切在边界
Embedding Model	ada-002 / bge-large / text-embedding-3-small	领域特定数据建议微调或选更大型号
Top-K Retrieval	3～5	答案需要的信息通常来自 3-5 个块

踩过的坑

没有 Overlap → 一些关键信息恰好在两个 Chunk 的边界被截断，检索不到
Chunk 太大 → 一个 Chunk 包含多个主题，检索到但模型不知道该用哪部分
只做单层检索 → 加一层 Rerank 可以显著提升 Top-K 的质量
不区分文档类型统一参数 → 代码和自然语言文档应该用完全不同的 Chunk 策略

进阶

Q14. Agent 的上下文窗口满了怎么办？你的压缩策略是什么？

上下文窗口满了是不能回避的问题，特别是长对话 Agent。

分层压缩策略

Token 预算分配策略

核心原则： 最新的信息保留最完整，中间的要压缩，关键事实结构化提取，不要等到满了才处理，每次对话后会做增量压缩

6. 评估与可观测性

Q15. 你怎么评估一个 Agent 好不好？Eval 体系怎么搭建？

Agent Eval 三层体系

Eval数据集构建

Eval 工作流

Q16. 你的 Agent 在生产环境出问题了，怎么排查？

Agent 排障的难点在于，你不能像 Debug 代码那样去 Debug Agent，因为每次输出都可能不同。

排查工具箱

一站式排查流程

没有 Tracing 的 Agent 系统就是盲人摸象，在 Agent 上线前，必须先接入Tracing工具（LangSmith / LangFuse），这是最重要的基础设施投资。

7. 安全与护栏

Q17. 你给 Agent 设计过安全护栏吗？怎么防止 Agent 做它不该做的事？Agent调数据库DELETE 怎么办？

分层安全模型（Defense in Depth）

编码实现示例

Agent调数据库DELETE 怎么办？

System Prompt 明确禁止"执行非只读 SQL"
数据库 Tool 内部做 SQL 解析，检测到 DELETE / DROP / TRUNCATE 直接拒绝
写操作类 Tool 需要用户二次确认 + 操作审计日志

8. 工程落地与场景题

Q18. 设计一个Android技术顾问 Agent，你会怎么设计架构？

系统架构

工具定义

Tool	用途	权限
`search_android_doc`	搜索官方 Android 文档	只读
`search_tech_wiki`	搜索内部技术 Wiki	只读
`search_gitlab_code`	搜索 GitLab 仓库代码	只读
`search_issue`	搜索 Bug / 需求	只读
`read_file_content`	读取文件内容了解上下文	只读
`summarize`	对长文本做摘要	无副作用
`generate_code_snippet`	生成代码片段	只输出文本

刻意不开放的工具：

modify_code : 不开放，Agent 不做代码修改
delete_file : 不开放
deploy : 不开放

边界处理：

非技术问题：意图分类器检测到非 Android 技术问题 → 礼貌拒绝
公司内部信息：Agent 需要确认用户有权限访问该信息，否则说"没有权限"
不确定的答案：必须说"这个我不确定"，并给出查找方向
代码安全性：生成的代码片段必须包含注释说明风险和适用版本

成本控制：

简单问题用 Claude Haiku / GPT-4o-mini 处理，复杂问题才升级到旗舰模型
RAG 检索结果的缓存（相同问题直接命中缓存）
设置单次对话 Token 上限，防止预算失控

Q19. 你要把一个 AI Agent 部署到线上，要考虑哪些问题？画一个部署架构

部署关注点清单

延迟 (Latency)

LLM 调用的 P50 / P95 / P99 耗时监控
流式输出（Streaming）减少首 Token 等待时间
RB-Tree 缓存：相同请求直接返回缓存结果
对简单问题做模型降级（Claude Sonnet → Claude Haiku）

成本 (Cost)

Token 用量监控 + 预算告警
缓存策略减少重复调用
Prompt 压缩降低每次调用的 Token 数
长对话的自动摘要压缩

可靠性 (Reliability)

LLM API 的重试 + 降级（主模型挂了 → 备用模型）
每个 Agent 步骤设置超时 → 超时触发降级
健康检查（Health Check）：/ping → 快速检测 Agent 是否健康
限流（Rate Limiting）：防单个用户刷量

可观测性 (Observability)

全链路 Tracing（每步的耗时 / Token / 工具调用）
业务指标监控（成功率 / 用户满意度 / 工具准确率）
异常告警（Token 激增 / 成功率骤降 / 延迟飙升）
日志保留（Agent 的 Thought 过程是 Debug 的核心依据）

安全 (Security)

用户鉴权（JWT / API Key）
工具调用权限控制
输入输出安全检查
审计日志（所有操作可追溯）

Q20. 你如何控制Agent的调用成本？用户一次对话花了10万Token怎么办？

成本控制应该是系统设计的一部分，而不是出了问题再去查。

事前预防

措施	效果
每轮对话 Token 上限（如 20K）	防止单次失控
最大推理轮次（如 10 步）	防止 Tool Loop 消耗
模型分层（简单→小模型，复杂→大模型）	降低 50-70% 成本
缓存命中（相同的 RAG 查询直接返回）	降低检索成本
Prompt 瘦身（去掉非关键指令，用短名称）	每轮节省 5-10%
工具分组（只暴露当前需要的）	减少 Tool Definition 占用的窗口

事中监控

事后分析

每日常规 Token 用量报表（按用户 / 对话 / Agent 分类）
识别CPU（Cost Per User）最高的用户------是正常使用还是滥用
识别异常的 Token Spike,突然暴涨通常意味着 Bug

事后按照以下问题排查

是不是 Agent 陷入了 Tool Loop？
是不是有工具返回了巨量数据？
是不是用户的问题是 LLM 无法处理的？
是不是 System Prompt 或 Tool Definition 太大？

然后针对根因做修复：加轮次上限、工具返回结果截断、Prompt 瘦身

Q21. 如果你现在要在 Android 手机上实现一个本地 AI助手Agent，你会怎么做？

整体架构

端侧模型的取舍

不要期望端侧模型能像 GPT-4 一样推理
端侧做：意图分类 + 简单问答 + 工具路由
云端做：复杂推理 + 长文本生成
关键数据（通讯录/短信）绝不离开设备

实现要点：

Agent 作为一个 Foreground Service 运行，常驻后台
用 Notification 快捷回复 作为交互入口
Tool Calling 通过 Android 原生 API 实现
用 DataStore / Room 做会话持久化
需要 Privacy Sandbox 级别的权限管控

端侧 Agent 的工具举例：

Tool	实现	权限
`query_contacts`	`ContentResolver.query(ContactsContract)`	READ_CONTACTS
`read_calendar_events`	`ContentResolver.query(CalendarContract)`	READ_CALENDAR
`send_notification`	`NotificationManager.notify()`	POST_NOTIFICATIONS
`search_files`	`MediaStore` 或 SAF	文件访问权限
`take_screenshot`	`MediaProjection`	屏幕录制权限
`open_app`	`PackageManager.getLaunchIntentForPackage()`	无特殊权限
`web_search`	网络 API 调用	INTERNET

Q22. 在 Agent 场景下，你怎么测一个非确定性系统？

核心认知：Agent 的测试不是传统"对或错"的测试，而是统计学的"在多少情况下表现可接受"

分层测试策略

自动化评估工具

关键指标

不要求 100% 准确（不可能，因为 LLM 有概率性）
设定 SLO（Service Level Objective）：如 Tool Selection 准确率 ≥ 90
持续监控：每次模型升级 / Prompt 修改后回归测试
异常检测：如果成功率突然从 92% 降到 85%，说明有回归问题

收个尾

我觉得现在用AI跟开车有点相似，开车现在基本谁都会开，挂个档踩个油门没啥难度，但是如果车出点问题，爆胎了你会换胎吗，车子开一半熄火了你能知道是什么原因吗，甚至之前我看到一视频里面有人玻璃水都不知道往哪个洞洞眼里面灌，也不知道是不是真的，AI也是如此，会用AI的人很多，但懂AI的人很少，当所有人都在用AI写周报、做PPT、画图的时候，你如果能理解ReAct循环为什么能防死循环、知道如何优化Lost-in-the-Middle现象，那么你就不再是AI的"用户"了，而是AI的"工程师"