AI智能体应用开发面试题 - 2026-06-17
【面试题】1. 在大模型API调用中，temperature和top_p参数分别控制什么？实际项目中你一般怎么设置这两个参数？
【标准答案】
- temperature控制生成的随机性，值越高输出越多样越不可预测；top_p是核采样，控制考虑token的概率累积范围
- 实际项目经验：
- 代码生成、数据提取场景：temperature=0.1-0.3，要稳定可预期
- 文案创作、头脑风暴：temperature=0.7-0.9，需要多样性
- top_p一般设0.9，除非有特殊需求不轻易动
- 关键点：两个参数不要同时调，容易互相干扰，一般只调temperature
【面试题】2. 什么场景下选择单智能体架构，什么场景下必须上多智能体？能不能举个你实际做过的项目例子？
【标准答案】
- 单智能体适用：任务边界清晰、流程线性、一个角色能搞定，比如"客服问答机器人"、"文档摘要工具"
- 多智能体必须用上的场景：
- 任务需要不同专业能力（比如"写代码+代码审查+测试用例生成"就需要3个Agent）
- 需要辩论/对抗来提升输出质量（比如"方案生成Agent + 质疑Agent"）
- 流程复杂需要并行处理（比如"同时爬数据、分析、生成报告"）
- 实际案例：做过一个"竞品分析助手"，用3个Agent分别负责"数据收集"、"SWOT分析"、"报告生成"，比单Agent效果好30%，因为每个Agent的prompt更专注，不容易混淆角色
【面试题】3. Function Calling和ReAct两种工具调用范式有什么区别？各自适合什么场景？
【标准答案】
- Function Calling：模型直接输出结构化JSON调用工具，由外部执行后把结果返回给模型
- 优点：调用精准、延迟低、适合确定性强的工具调用
- 适合：天气查询、数据库查询、计算器这类"输入确定→输出确定"的工具
- ReAct（Reasoning + Acting）：模型先"思考"再决定"行动"，循环多次
- 优点：能处理复杂多步任务、有推理过程可解释
- 适合：需要多步推理的任务，比如"帮我分析这个PDF并生成PPT"
- 实战建议：简单工具用Function Calling，复杂任务用ReAct，现在很多框架（LangChain）是两者结合的
【面试题】4. RAG系统中，如何评估召回质量？如果用户反馈"回答不准确"，你会从哪几个维度排查？
【标准答案】
- 评估召回质量的核心指标：
- 召回率（Recall）：相关文档有没有都被召回
- 精确率（Precision）：召回的文档里有多少是真正相关的
- 可以用"人工标注的query-document相关对"来计算
- 回答不准确的排查链路：
- 召回层：embedding模型是否合适？chunk_size是否合理？有没有做hybrid search（向量+关键词）？
- 重排层：有没有用Rerank模型对召回结果重新排序？
- 生成层：prompt有没有把上下文质量说清楚？有没有让模型"只根据给定文档回答"？
- 数据层：原始文档质量如何？有没有做数据清洗？
- 实战技巧：先打印出"召回了哪些chunk"给人工看，80%的问题在这一步就能定位
【面试题】5. 你用LangChain或CrewAI做过项目吗？说说你最喜欢和最吐槽它的一个设计，以及你是怎么解决那个问题的？
【标准答案】
- 我用LangChain比较多，CrewAI也研究过
- 最喜欢的设计：LCEL（LangChain Expression Language）链式调用，代码可读性高，调试方便，比如
prompt | llm | output_parser这种写法很直观 - 最吐槽的点：LangChain抽象层级太多，新手容易"不知道背后发生了什么"，调试困难；而且版本更新快，API经常变
- 我的解决方案：
- 关键链路不用LangChain的高级封装，直接用底层API（比如只用它做document loader，embedding和向量库我自己写）
- 或者干脆用更轻量的框架（比如原生的OpenAI API + 自己写prompt管理）
- 给面试官的感觉：不是盲目用框架，而是理解原理后选择性使用
【面试题】6. 智能体的"记忆系统"有哪些实现方式？长对话场景下如何避免上下文超限？
【标准答案】
- 记忆系统的三层实现：
- 短期记忆：直接放context window，最简单但受token限制
- 中期记忆：用向量数据库存储历史对话，需要时召回相关片段（RAG思路）
- 长期记忆：结构化存储重要信息（比如用户画像、项目背景），用工具调用主动写入/读取
- 长对话避免超限的策略：
- 滑动窗口：只保留最近N轮对话
- 摘要压缩：定期用模型把历史对话压缩成摘要（LangChain的ConversationSummaryMemory就是这个思路）
- 分层存储：把"事实性信息"提取出来存数据库，对话里只放"当前任务相关的上下文"
- 实战经验：我一般组合用"滑动窗口（最近5轮）+ 定期摘要 + 关键事实提取"，能在保持连贯性的同时把token控制在预算内
【面试题】7. 如果让你从0到1搭建一个"AI客服助手"，你会怎么设计技术架构？需要考虑哪些关键点？
【标准答案】
- 技术架构设计：
- 接入层：企微/钉钉/Webhook接入，处理消息接收和发送
- 意图识别层：用大模型判断用户意图（咨询/投诉/转人工），简单意图直接回复，复杂意图进Agent
- 知识库RAG：FAQ文档、产品手册做向量化，召回相关片段辅助回答
- Agent层：需要处理复杂问题的才进Agent（比如"查订单+取消+退款"多步操作）
- 工具调用层：查订单API、退款API、CRM系统对接
- 安全层：敏感词过滤、回复审核、权限控制
- 关键点：
- 转人工策略：置信度低于阈值或用户明确要求时及时转人工，别让AI硬撑
- 回复质量：用few-shot + CoT提升回答质量，关键是要"像人"
- 监控迭代：记录"用户不满意"的对话，定期分析优化prompt和知识库
【面试题】8. 多模态智能体（能处理文本+图片+语音）在实际落地时有哪些技术难点？你是怎么解决的？
【标准答案】
- 主要技术难点：
- 模态对齐：不同模态的embedding空间不一样，怎么让模型"理解"图片和文本的关联？
- 成本问题：多模态API调用（比如GPT-4V）比纯文本贵很多，怎么控制成本？
- 延迟问题：处理图片比文本慢，怎么优化用户体验？
- 我的解决方案：
- 模态对齐：用CLIP这类预训练模型做统一的向量表示，或者用支持多模态的大模型（Qwen-VL、GPT-4V）直接处理
- 成本控制：先做"模态路由"，简单问题只用文本模型，只有真的需要看图的问题才调多模态API
- 延迟优化：图片预处理（压缩、裁剪）异步做，先用文本模型给用户一个"正在处理图片"的反馈
- 实战案例：做过一个"装修设计助手"，用户上传房间照片→AI给出设计建议，核心是用Qwen-VL做图片理解 + RAG召回装修风格案例
【面试题】9. 智能体项目上线后，你用什么指标监控效果？如果发现"用户满意度下降"，你会怎么排查？
【标准答案】
- 核心监控指标：
- 业务指标：任务完成率、转人工率、用户评分（点赞/点踩）
- 技术指标：API调用成功率、P95延迟、token消耗成本
- 质量指标：人工抽检的"回答准确率"、幻觉率
- 用户满意度下降的排查步骤：
- 看数据：是不是某个时间段开始下降？有没有发版记录？是不是新版本prompt引入的问题？
- 看case：随机抽20-50个"用户点踩"的对话，人工分析失败原因（召回失败？幻觉？语气问题？）
- 看分布：是不是某类问题（比如"投诉类"）下降特别明显？针对性优化那类场景的prompt或知识库
- A/B测试：优化后做小流量A/B，确认效果再全量
- 实战经验：很多时候是"边界case"没处理好，比如用户问"你们老板是谁"这种闲聊，AI回答很僵硬导致体验差，这类问题需要专门优化prompt的"闲聊人格"
【面试题】10. 说说你在做AI智能体项目时遇到的最坑的一个问题，你是怎么解决的？如果现在重新做，你会怎么避免？
【标准答案】
- 最坑的问题：做了一个"合同审核助手"，上线后发现有20%的合同它给出错误建议，原因是训练数据里的合同格式和真实用户上传的格式差异很大，导致模型"幻觉"出不存在的条款
- 我的解决方案：
- 紧急修复：加了一层"条款抽取验证"，让模型先列出它看到的条款，人工核对后再给建议
- 长期优化：收集真实用户合同数据，做fine-tuning；同时优化prompt，让模型"如果不确定就说不确定"
- 如果重新做，我会：
- 先做数据探索：上线前先把100份真实合同跑一遍，看召回和理解的准确率，不达标不上线
- 加置信度机制：让模型输出"我对此建议的置信度是X%"，低于阈值就转人工
- 灰度发布：先给内部员工用，收集反馈后再对外开放
- 给面试官的印象：有实战经验、会复盘、知道怎么避免重复踩坑
出题说明
- 出题时间：2026-06-17 00:00
- 题目数量：10道
- 覆盖知识点：大模型API调用、单/多智能体架构、Function Calling、RAG系统、LangChain/CrewAI框架、记忆系统、项目落地、多模态、监控迭代、实战踩坑
- 难度定位：1-3年经验AI智能体开发岗位
- 答案特点：口语化、有实战案例、有具体数据、有可落地的建议
本题库由AI智能体应用开发面试题生成器自动生成，适用于技术面试、自我检测、团队培训等场景。