22道AI‑Agent高频面试题整理，吃透轻松拿下offer

P.S. 挖到宝藏AI教程！全程通俗易懂，风趣幽默，零基础轻松入门，传送门https://blog.csdn.net/qq_34419312

前言

最近天越来越热，互联网圈的“夏季优化传统”又开始冒头了。

我身边好几个朋友，连着俩夏天都成了待业选手，在家吹空调吃西瓜，顺便海投简历。

我今年虽说还稳在岗，但谁知道明天会不会被约谈？提前背点题总没错。

总比到时候面试官坐你对面，问啥你都只会挠头傻笑，说一句“这个我不会”强吧？

今天整理了22道Agent高频面试题，全是干活踩坑踩出来的干货，看完面试至少不会当场社死。

一、LLM底层认知：基础打不牢，面试地动山摇

Q1：上下文窗口是什么？Lost-in-the-Middle现象咋回事？

上下文窗口，说人话就是模型一次能处理的最大Token数量。

就像你外卖盒就那么大，硬塞三斤米饭进去盖都盖不上，窗口外的信息模型压根看不见。

Lost-in-the-Middle说白了就是模型也有“中间遗忘症”。

一大段长文本喂进去，开头和结尾的信息它记得最牢，中间的内容基本就被稀释没了。

准确率首尾能有七八十，中间直接掉到四五十，跟你背英语单词一模一样，abandon记得最熟，中间的全忘光。

原因也简单，注意力分布不均匀，模型天生就对开头和结尾的内容更敏感。

解决办法也不复杂：重要指令放开头，最新消息放结尾，长文本定期做摘要，检索结果按相关性重排序，基本就能缓解大半。

Q2：Temperature、Top-P、Top-K三个参数有啥区别？怎么调？

这仨参数，说白了就是控制模型输出的“放飞程度”，但管的地方不一样。

Temperature管概率分布平滑度，数值越低越死板，调到0就是纯老实人，说一不二；数值越高越放飞，啥天马行空的内容都能整出来。

Top-P是核采样，找累积概率加起来超过P的最小Token集合，比如0.9就是凑够90%概率的候选词就停手。

Top-K更直接，只选概率最高的K个词，剩下的全扔掉。

调参也有固定套路，别瞎调：

写代码、调工具这种严谨活，Temperature直接拉到0到0.2，别让它瞎发挥；

事实问答、RAG场景，也别太高，0到0.3足够；

写文案、头脑风暴这种需要创意的，就调到0.7到0.9，让它放开了想。

重点提醒：工具调用阶段温度一定要低，不然它能给你编出来一堆不存在的工具，出bug你都找不到原因。

Q3：模型幻觉咋来的？Agent场景怎么缓解？

幻觉这事儿，说白了就是模型一本正经地胡说八道。

根源也简单：它本质是预测下一个Token，不是自带知识库，预训练数据里有错的也照单全收，再加上RLHF总鼓励它“要有帮助”，不知道也硬编。

放到Agent场景里，幻觉可比纯文本吓人多了。

轻则给你传个不存在的参数，重则直接调用一个根本没有的工具，甚至它自己觉得已经干完活了，实际上啥也没动。

就像你让助理去买咖啡，他回来跟你说买完了，实际上根本没下楼，全靠脑补。

缓解的法子也不少：让它输出结构化JSON，别瞎写自由文本；用RAG给它喂事实，减少瞎编空间；关键操作必须人工确认，别让它自己说了算。

二、Agent架构与模式：干活的套路得门清

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

ReAct的核心逻辑，说穿了就是“边想边干”。

先让模型思考下一步干啥，是调用工具还是直接给答案；要调用工具就去执行，执行完把结果塞回去，再让它接着思考。

循环往复，直到它给出最终答案，或者到了最大轮次强制停止。

这里必须提一嘴最大迭代次数，这玩意儿就是保命用的。

Agent要是陷入死循环，一轮接一轮调用工具，那Token烧起来跟流水似的，没上限的话一次对话能给你干出去几十万Token，账单出来你直接傻眼。

Q5：ReAct和Plan-and-Execute有啥区别？各适合啥场景？

这俩模式，一个是走一步看一步，一个是先做攻略再出发。

ReAct是边推理边行动，灵活得很，遇到不对的随时能改方向，但长任务容易跑偏，走着走着就忘了自己要干啥。

Plan-and-Execute是先把完整计划定好，再一步步执行，结构清晰，适合长流程，但灵活性差，中间出问题得重新规划。

啥时候用哪个？简单查询、故障排查、未知探索这种需要灵活调整的，用ReAct；写周报、多文件重构这种需要整体把控的，用Plan-and-Execute。

实际干活哪有非黑即白的，大多都是混合着来：先定个大方向计划，具体每一步用ReAct灵活处理，卡壳了就重规划，香得很。

Q6：Multi-Agent系统怎么设计？什么时候拆多Agent？

很多人一上来就想搞多Agent，觉得越多个越厉害，其实根本不是。

什么时候该拆？比如一个角色既要搞创意又要做审核，人格分裂；或者要访问不同权限的数据源，放一起工具选不准；再或者不同环节需要不同的推理策略，这时候再拆。

别啥问题都上多Agent，一个Agent加好Prompt能解决的事，拆成多个就是过度设计。

三个以上Agent，协调成本直接指数级上升，跟三个和尚没水喝一个道理，最后全在那互相甩锅。

Agent之间通信也别瞎聊纯文本，得定义结构化的消息协议，再加个共享黑板存上下文，不然光传消息就能耗掉一半Token。

Q7：Agent死循环了怎么办？检测和恢复策略有哪些？

Agent死循环，简直是生产环境的噩梦。

要么反复调用同一个工具，参数变来变去但啥用没有；要么A工具的结果喂给B，B的结果又喂回A，俩工具搁这打乒乓球呢；更有甚者，一直在那自我质疑，光想不行动。

跟你上班摸鱼一模一样，反复打开同一个网页，啥也没干还假装自己很忙。

检测其实不难：设个最大轮次兜底，再检查最近几次工具调用是不是重复了、有没有带来新信息，再设个Token预算红线，超了就告警。

真检测到了也别怕，轻微的就插条提示让它换个思路；严重的就把上下文压缩摘要，重启循环；实在救不活的，就降级成普通问答，或者直接转人工。

三、Tool Calling：工具用不明白，Agent直接废一半

Q8：怎么定义一个“好的”工具？踩过哪些坑？

很多人写工具定义，就俩字：搜索。

模型哪知道你搜啥的？搜八卦还是搜文档？搜技术还是搜菜谱？它根本摸不着头脑，选错工具太正常了。

好的工具定义，就得像写招聘JD一样，写得明明白白：你是干啥的，什么时候该找你，什么时候别找你，参数都是啥意思。

踩过的坑可太多了：参数名写个q、id，模型根本不知道填啥；没加枚举约束，它能给你编出来一堆不存在的选项；工具功能重叠，俩工具干差不多的事，模型反复纠结选哪个。

记住一句话：工具描述宁可啰嗦，不能模糊。你写得越清楚，模型用得越准。

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

工具调用哪有不失败的，就像你点外卖哪有次次准时的。

分情况处理就行：

第一层，网络超时、限流这种瞬时错误，指数退避重试个两三次，一般就好了。

第二层，参数格式不对、缺参数这种，把错误返回给Agent，让它自己修正了再试。

第三层，查不到数据、没权限这种业务错误，也把信息给Agent，让它决定下一步是问用户还是换个方式。

第四层，模型瞎调用工具，比如没确认就删数据，这种直接拦截，插警告让它纠正。

别一报错就直接返回给用户，错误信息也是Agent的观察信息，它能自己修正才是真的智能。

Q10：30个工具注册进去，选工具准确率下降怎么办？

这太正常了，工具越多，选对的概率越低。

就像给你一本30道菜的菜单，让你一秒选出最合适的一道，大概率也得选错。

优化的法子有很多：

最常用的就是分组，把工具按类别分成研发组、数据组、协同组，先选大类再选具体工具，准确率立马回升。

也可以做意图预路由，先判断用户是啥意图，再给对应的Agent和工具集。

或者动态注册，每轮对话只给它5到8个相关的工具，别一股脑全塞进去。

一般来说，5个工具准确率能有95%，20个就掉到七八十，分组到每级五六个，就能回到90%以上。

四、Prompt Engineering：写提示词也是技术活

Q11：怎么设计迭代System Prompt？有啥反直觉的坑？

很多人写System Prompt，一写就是一大篇，恨不得把所有规矩都写进去。

实际上恰恰相反，越短的System Prompt效果往往越好。

写太长了关键信息就被稀释了，模型根本记不住后面的，主打一个左耳进右耳出。

还有个反直觉的坑：你越说“不要做XX”，模型越容易做XX。

就像你跟小孩说“别把杯子打碎了”，他转头就能给你碰地上。模型也一样，它只关注到了“杯子打碎”这个词，反而更容易触发。

正确的做法是用正向引导代替负面禁止，把最重要的规则放最前面，用量化的约束代替抽象的要求，比如“回答不超过3点”就比“回答要简洁”好用一百倍。

Q12：怎么防Prompt注入攻击？

Prompt注入这事儿，在Agent场景下尤其危险。

毕竟Agent能调用工具，攻击者忽悠它删数据、泄露信息，那麻烦就大了。

就像有人冒充你老板给你发消息，让你转钱，你一不留神就中招了。

防御得做分层，不能只靠一层：

入口层先做关键词检测，把常见的注入话术拦下来，用户输入用标签包好，和系统指令隔开。

系统层把System Prompt钉在最前面，反复强调不能改角色、不能听用户的伪造指令。

运行时再检测一轮，看看输出有没有异常，工具参数有没有猫腻。

最后执行层再上权限控制，高危操作必须人工确认。四层下来，基本就能挡住绝大多数注入攻击。

五、RAG与记忆管理：记性不好的Agent不是好员工

Q13：RAG的Chunk策略怎么选？

Chunk分块这事儿，可不是随便切切就行。

切太小了信息不完整，切太大了检索噪声多，就像切西瓜，切太小全是皮，切太大一口吃不下。

不同的文档得用不同的切法，不能一刀切：

代码文件就按函数、类来分，保留缩进结构；Markdown文档就按标题层级分；PDF长文就按段落加语义边界分；对话记录就按轮次分。

参数也有讲究，一般Chunk Size选256到512个Token，重叠10%到20%，防止关键信息正好被切在边界上。

别嫌麻烦，Chunk分不好，后面检索再厉害也白搭。

Q14：上下文窗口满了怎么办？压缩策略是什么？

长对话聊着聊着窗口就满了，这是躲不开的事儿。

就像你手机内存，用着用着就满了，总不能一直不清理吧？

别等满了再处理，平时就得做分层压缩：

第一层，没用的直接扔，比如中间轮次的大段工具返回数据，模型看完就没用了，该删就删。

第二层，摘要压缩，把中间的对话用模型压缩成几句话，代替原始对话。

第三层，关键信息提取，用户偏好、确认过的事实，单独存成键值对，不用每次都重读上下文。

第四层，长期记忆存外部数据库，下次对话还能调出来用。

核心原则就是：最新的信息留完整，中间的压缩，重要的结构化存起来。

六、评估与可观测性：好不好用，得拿数据说话

Q15：怎么评估一个Agent好不好？评估体系怎么搭？

评估Agent可不能靠感觉，“我觉得挺好用”不算数，得有体系。

分三层来：

第一层是单元测试，最基础的，工具调用准不准、输出格式对不对、有没有敏感内容，跑一次过了就行。

第二层是任务级评估，核心看任务完成率、路径是不是最优、耗了多少Token和时间、抗不抗攻击。

第三层是线上评估，看用户满不满意、愿不愿意再来用、报错率多少、每次对话花多少钱。

测试集也得好好做，标准场景、边界场景、对抗场景、回归场景都得有，每月更新点新案例，这样评估才靠谱。

Q16：生产环境Agent出问题了怎么排查？

Agent排障可比普通代码难多了，普通代码打断点就能看，Agent每次输出都可能不一样，跟开盲盒似的。

所以上线之前，必须先把全链路追踪接上，这钱绝对不能省。

没有追踪的Agent系统，就是盲人摸象，出了问题你根本不知道哪坏的。

排查流程也很清晰：先确认是啥问题，是答错了、卡死了、调错工具了还是报错了。

然后去看追踪日志，每一步的想法、动作、结果、Token消耗、耗时，全给它扒出来，定位到出问题的那一步。

接着去测试环境复现，改Prompt、改工具定义、优化检索，改完再回归测试，灰度上线观察。

七、安全与护栏：别让Agent闯了大祸

Q17：怎么设计安全护栏？Agent调了数据库DELETE怎么办？

千万别指望Agent自己自觉，就像你不能指望小孩自己不闯祸。

护栏必须做多层，一层不够就两层，两层不够就四层，纵深防御才靠谱。

输入层先查，敏感信息脱敏、注入检测、速率限制，先把坏东西拦在外面。

推理层再管，按用户角色给工具集，参数做黑白名单校验，高危操作卡审批，Token预算监控好。

执行层再把一道关，工具单独配权限，结果做安全检查，操作保证幂等，超时就熔断。

最后输出层再过滤一遍，敏感信息打码，内容安全检测，格式校验好再给用户。

至于调DELETE删库这种天大的事儿，必须三层保险安排上：

System Prompt里先明确禁止非只读SQL，先给模型打预防针；

数据库工具内部做SQL解析，检测到危险操作直接拒绝，根本不给执行机会；

所有写操作必须用户二次确认，同时留全审计日志。

三层下来，基本就杜绝了Agent乱删库的可能，毕竟删库这种事，还是人来背锅比较靠谱。

八、工程落地：光说不练假把式，场景题见真章

Q18：设计一个Android技术顾问Agent，怎么搭架构？

做技术顾问Agent，核心就是稳，别瞎给答案，更别瞎改代码。

入口先做意图分类，非技术问题直接礼貌拒绝，别浪费资源。

核心用ReAct循环就行，搭配官方文档、内部Wiki、代码仓库、Issue库几个只读检索工具，再加个代码生成、文本摘要工具。

重点：修改代码、删除文件、部署这些工具，一律不开放。

不确定的答案就说不确定，别硬编，给个查找方向就行。

成本上也得控，简单问题用小模型，复杂问题再上大模型，检索结果做缓存，单次对话设Token上限，别烧钱没节制。

Q19：Agent部署线上要考虑啥？

部署上线可不是把代码扔服务器上就完事了，要考虑的事多了去了。

首先是延迟，首Token等待时间太影响体验了，能流式输出就流式，简单问题直接用小模型，相同请求做缓存。

然后是成本，Token用量监控起来，预算超了告警，多做缓存和压缩，能省不少钱。

可靠性也得跟上，LLM API做多路重试和降级，主模型挂了还有备用的，每个步骤设超时，限流也得安排上。

还有可观测性和安全，该上的监控、日志、鉴权、权限控制，一样都不能少。

Q20：怎么控制Agent调用成本？一次花10万Token怎么办？

一次对话花10万Token？那不是在聊天，那是在烧钱。

成本控制得从一开始就设计进系统里，不能等账单出来了才心疼。

事前先预防：每轮对话设Token上限，最大推理轮次卡死，模型分层用，缓存做起来，Prompt瘦瘦身，工具按需分组暴露。

事中盯着点：设个告警阈值，Token用多了就触发降级，自动压缩上下文，超了上限就强制终止，绝不能让它无限烧。

事后复盘：每天看报表，找出最费钱的用户和对话，看看是正常使用还是bug，针对性优化。

Q21：Android本地AI助手Agent怎么实现？

端侧Agent，核心就一个原则：别指望它啥都能干。

手机上那点算力，跑不了大模型，就干点简单的活：意图分类、简单问答、工具路由，复杂的全甩给云端。

好处也明显，联系人、日历这些敏感数据，全在本地处理，绝不离开手机，隐私有保障。

实现上也不难，Agent做成前台服务常驻后台，用系统通知做交互入口，工具调用全走Android原生API，数据存在本地数据库里。

权限管控一定要严，啥工具对应啥权限，没授权就不能用，别乱拿用户数据。

Q22：非确定性的Agent系统怎么测试？

测Agent跟测传统软件可不一样，传统软件非对即错，Agent是概率性的，总不能要求它100%准确，那不现实。

得分层测：

第一层确定性测试，格式对不对、参数类型对不对、安全规则触没触发，跑一次过了就行。

第二层统计测试，同一个输入跑个十次八次，看工具选择准确率、任务完成率大概在多少，心里有个底。

第三层对抗测试，注入攻击、模糊输入、边界情况，全给它安排上，看看扛不扛造。

不用追求满分，定个合理的SLO，比如工具准确率90%以上，每次迭代跑回归，不下降就行。

最后说两句

现在人人都会用AI，就像人人都会开车。

挂个挡踩个油门谁都会，可车爆胎了你会换吗？半路熄火了你知道啥原因吗？玻璃水往哪加你清楚吗？

AI也是一样，会用AI写周报、做PPT的人一抓一大把。

但你要是懂ReAct循环为啥能防死循环，知道怎么优化Lost-in-the-Middle，清楚怎么控成本、做安全，那你就不再是AI的用户，而是AI的工程师。

面试的时候，这就是你甩开别人的底气。

P.S. 挖到宝藏AI教程！全程通俗易懂，风趣幽默，零基础轻松入门，传送门https://blog.csdn.net/qq_34419312