AI智能体应用开发面试题
生成时间：2026-06-15 23:05
题数：10道
适用：1-3年经验岗位
【面试题】1. Agent的输出有时会"自说自话"——比如用户没问相关内容，它却主动输出一大段无关推理过程。你怎么让Agent只在用户需要的时候输出、该停就停？
【标准答案】 这个问题本质是"输出边界控制"，我从三层解决。
第一层是Prompt里加硬约束："直接输出最终答案，不要展示思考过程"。如果你需要思维链做调试，用<think/>标签包裹，前端渲染时过滤掉，用户只看到最终回答。
第二层是用结构化输出约束。把Agent的输出Schema定义为{"answer": "...", "need_follow_up": false}，字段数量固定，模型就没机会"自由发挥"多写废话。
第三层是后处理截断。即使Prompt和Schema都约束了，模型偶尔还是会多输出。我在输出解析层加了一个规则：如果检测到输出超过预期长度且包含推理性语言（"我认为""首先"等），自动裁剪到答案部分。
最关键的思路：不要指望模型自觉收手，用工程手段强制框住它的输出范围。
【面试题】2. 你在Agent开发中怎么处理"模型上下文窗口突然被压缩"的场景？比如原本用128K模型，突然要切换到32K模型，你怎么快速适配？
【标准答案】 这种事真的遇到过——供应商临时调整模型配额，128K变成32K，整个链路差点崩。我的应急方案分三步。
第一步，立刻启动上下文压缩策略。对话历史从全量保留改为"最近5轮+历史摘要"，工具调用结果从全量返回改为"关键信息提取"。这步最紧急，不做就超限报错。
第二步，优化知识注入方式。原来RAG检索Top10直接全塞，改为Top5+Rerank精排，每条chunk从完整内容改为摘要版本。128K时代可以偷懒不管，32K必须精打细算。
第三步，长期方案是做"上下文预算管理"。定义一个ContextBudget类，给每个信息源分配token配额：System Prompt 2K、对话历史5K、知识检索8K、工具结果5K、输出预留12K，总和不超过32K。所有信息注入前先算token数，超配额的自动压缩。
核心教训：不要依赖特定模型的上下文长度，架构设计时就要假设窗口随时可能缩小。
【面试题】3. 你做一个内部工具调用Agent，发现模型总是"过度调用"——用户问个简单问题它连调3个工具，浪费token又慢。你怎么优化？
【标准答案】 这是"工具调用焦虑"——模型宁可多调也不愿漏调。三个优化方向。
第一，精简工具描述。很多时候过度调用是因为工具描述太模糊，模型觉得"可能相关"就调了。我把每个工具的description改成"只在XXX场景调用，其他场景不要用"的格式，像写API文档一样精确。工具描述从模糊到精确后，无效调用降了60%。
第二，加"是否需要工具"的前置判断。不是所有问题都需要工具，比如"你好""谢谢"这类直接回复就行。我在Agent前面加了一个轻量分类器（用小模型或规则引擎），判断当前问题是否需要工具，不需要就跳过工具调用环节直接生成回答。
第三，设置单轮最大调用次数。不管模型想调几个工具，一轮最多调2个，多了直接截断。用LangChain的max_iterations参数就能控制。
核心原则：工具是锦上添花不是必须品，能用模型自身知识回答的就不要调工具。
【面试题】4. 你怎么设计Agent的"退避策略"？比如Agent连续两次调用同一个工具都失败了，它应该怎么做？
【标准答案】 退避策略不是简单的"失败就重试"，而是"判断失败原因+选择下一步行动"。
第一次失败：检查错误类型。如果是网络超时，指数退避重试（等2秒再试）；如果是参数错误，把错误信息喂回模型让它修正参数；如果是工具本身报错（比如"查询无结果"），换一个替代工具或策略。
第二次失败：停止重试同一个工具，改走替代路径。比如查询MySQL失败了，换成查Redis缓存或者调REST API。如果完全没替代方案，跳过这个工具，用已有信息尽量回答。
第三次失败：主动告知用户"我暂时无法获取这个信息"，给出替代建议（比如"您可以稍后再试，或者联系人工客服"），不要让用户觉得系统卡死了。
工程实现上，我把退避逻辑封装成一个ToolCallGuard类，每次工具调用结果都过一遍它，由它决定"重试/换路/放弃"。这样Agent的业务逻辑不需要关心退避细节。
【面试题】5. 在CrewAI或LangGraph中，你如何实现"动态子任务生成"——即Agent在执行过程中发现需要新任务，而不是一开始就把所有任务定死？
【标准答案】 这叫"涌现式任务规划"，和传统"先规划后执行"不同。
在LangGraph中，我用条件边+动态节点实现。每个Agent节点执行完后，不是固定跳到下一个节点，而是走一个"任务评估"节点——让LLM判断"当前信息是否足够回答用户问题"，如果不够，动态生成新的子任务节点加入执行队列。关键是State里要维护一个pending_tasks列表，每个节点执行完可以往里面追加新任务。
在CrewAI中，可以用回调机制实现。Agent完成Task后，在callback里判断是否需要追加新Task，如果有就创建新Task实例加入Crew的队列。CrewAI原生支持这种模式——它叫"自主任务委派"。
但要注意控制风险：动态生成任务必须设上限，比如最多追加3个子任务，否则可能无限递归。我在State里加了一个task_depth计数器，超限就强制终止。
实际效果：做竞品调研Agent时，原本硬编码5个固定子任务，改为动态生成后，平均每个查询能多发现2-3个有价值的信息点，因为Agent会根据第一轮结果"追问"。
【面试题】6. 你做Agent开发时，怎么处理"多轮对话中的指代消解"？比如用户第一轮说"帮我查一下北京到上海的机票"，第二轮说"那高铁呢？"——Agent怎么理解"那"指的是什么？
【标准答案】 指代消解是Agent多轮对话的核心能力之一，我分两层处理。
第一层，上下文拼接。把最近N轮对话历史拼进当前轮的Prompt里，让模型自己理解指代关系。这是最简单的方案，大部分场景够用。但问题是如果对话太长，模型会"忘记"前面的内容。
第二层，主动改写。在用户问题进Agent之前，先用一个小模型做"指代消解+省略补全"，把"那高铁呢？"改写成"北京到上海的高铁呢？"。这比依赖模型自己理解更稳定。实现上我用一个专门的LLM调用，Prompt是"请补全用户问题中的省略和指代，输出完整问题"，成本很低（几十个token），但效果立竿见影。
还有个工程技巧：改写后的query同时存两份——一份用于检索（改写版，召回率高），一份用于展示（原始版，用户体验自然）。两份数据各司其职。
实测数据：加指代消解后，多轮对话的任务完成率从72%提升到89%，因为大部分"对话断裂"都是指代问题导致的。
【面试题】7. 你怎么理解"Agent可解释性"？生产环境中，你怎么让用户或运维理解Agent为什么做出了某个决策？
【标准答案】 Agent可解释性是它被业务方信任的前提，我从输出层和日志层分别设计。
输出层：在Agent回答中附带"决策依据"。不是让模型自己解释（那会编），而是把检索到的文档片段、调用的工具及返回结果以结构化方式展示。比如回答下方加一个"信息来源"折叠区，标注"此答案基于：XX文档第3段、XX工具查询结果"。这样用户能验证，信任感大增。
日志层：每次Agent执行都生成一条完整的"决策链日志"——输入是什么、思考了什么、调了哪个工具、工具返回了什么、最终怎么决策的。这条日志存到可观测平台（LangSmith/LangFuse），运维可以按trace_id查询完整推理链。
还有一个高级做法：在关键决策节点加"解释节点"，专门让模型用一句话解释为什么选择这个行动。比如"我选择调用查库存工具，因为用户问了'有没有货'"。这条解释存入日志，方便事后审计。
核心观点：可解释性不是可选项，是Agent上生产的必选项。没有可解释性的Agent就是黑盒，出问题无从排查，业务方也不敢用。
【面试题】8. 你做过"Agent链路压测"吗？怎么模拟高并发场景下的Agent表现？关注哪些指标？
【标准答案】 做过，Agent压测和普通API压测很不一样，因为每次请求的token消耗和耗时差异巨大——简单问题2秒搞定，复杂推理可能跑30秒。
压测方法：我先录制一批真实的用户对话（100-200条，覆盖简单/中等/复杂场景），然后用Locust做并发模拟。关键是要做"场景混合"——80%简单问题+15%中等+5%复杂，模拟真实流量分布，不要全是简单或全是复杂请求。
关注的核心指标：
系统级：QPS上限（在可接受延迟内）、P50/P95/P99延迟、错误率（超时+API限流+模型异常）。
资源级：GPU利用率（如果自部署模型）、API并发额度消耗速率、Redis/向量数据库连接池耗尽水位。
业务级：任务完成率随并发的变化趋势（通常并发高了完成率会掉）、降级触发频率。
踩过的坑：第一次压测时发现P99延迟飙到60秒，排查发现是LLM API的限流导致请求排队，不是Agent本身慢。解决方案是加了请求队列+超时丢弃，P99降到了8秒。
【面试题】9. 你在Agent开发中怎么处理"模型版本升级导致的输出漂移"？比如OpenAI从gpt-4o升级到gpt-4o-2026-06，你的Agent行为突然变了。
【标准答案】 模型版本漂移是Agent生产的"隐形杀手"，我见过好几次——某天Agent突然回答质量下降，排查半天才发现是模型静默升级了。
预防措施三层：
第一层，锁定模型版本。API调用时不写gpt-4o（默认最新），而是写死具体版本gpt-4o-2026-05-01。这样除非你主动改，模型行为不会变。OpenAI和Anthropic都支持版本锁定。
第二层，自动化回归测试。每次模型版本更新前，跑一遍标准测试集（我们维护了300条标注QA对），对比新旧版本的关键指标：答案准确率、工具调用正确率、输出格式合规率。如果有指标下降超过5%，暂缓升级。
第三层，影子对比。新版本不直接上线，而是走影子模式——同样的用户请求同时发给新旧版本，只展示旧版本结果给用户，但记录新版本的结果用于对比。跑7天后分析差异，确认新版本没有退化再切。
应急方案：如果模型厂商强制升级导致线上出问题，我的做法是立刻切到备用模型（比如OpenAI出问题切Claude），同时在Prompt里做微调适配，用最快速度恢复服务。
【面试题】10. 面试官问："你觉得当前AI Agent技术最大的短板是什么？如果让你来解决，你会从哪个方向入手？"
【标准答案】 最大短板是可靠性和可预测性。传统软件写if-else，输入确定输出确定；Agent靠LLM推理，同一输入可能产生不同输出，出了bug很难复现和修复。这导致Agent在低风险场景（闲聊、推荐）用得很好，但高风险场景（金融决策、医疗诊断）没人敢用。
如果让我来解决，我会从"确定性框架+不确定性推理的混合架构"入手。具体来说：把Agent的任务拆成"确定性步骤"和"不确定性步骤"，确定性步骤用代码硬编码（if-else、状态机），不确定性步骤才用LLM。比如一个客服Agent，"识别意图"用规则+分类模型（确定性），"生成回答"用LLM（不确定性），"发送前校验"用规则（确定性）。
这样既保留了LLM的灵活性，又用确定性框架把风险框住了。LLM出错的范围被限制在特定节点内，不会一发不可收拾。
同时，我认为评估体系也很关键——现在大多数Agent项目没有系统化的评估，凭感觉调优。建立标准化的评估集和持续回归机制，才能让Agent的改进可量化、可追溯。
本题库由AI智能体应用开发面试题生成器自动生成，聚焦1-3年经验岗位核心考点。本批次全部为全新考点，与历史题库无重复。