AI智能体应用开发面试题 - 2026-06-12 00:00
【面试题】1. 你在项目中怎么控制大模型API调用的成本和延迟？
【标准答案】三板斧：第一，加缓存层——相同或相似问题先查缓存，命中直接返回，LLM调用量立减30%-50%；第二，按任务复杂度分级选模型——简单意图分类用小参数模型，复杂推理才上大模型；第三，流式输出+首token优化，开启stream让用户感知延迟降到最低。我们线上日均调用十万次，成本控制在千元级以内。
【面试题】2. Agent调用外部工具时，如果工具返回异常或超时，你怎么处理？
【标准答案】我设计了三层容错：第一层，工具侧设置超时阈值，默认10秒，关键接口设重试3次；第二层，Agent侧用结构化错误码返回给LLM，不是直接抛异常——让模型能理解"这个工具暂时不可用"并自主决定走备用方案还是回退给用户；第三层，兜底plan B，比如查数据库失败就降级用缓存数据，支付接口超时就转人工确认。核心思路是让Agent优雅降级，而不是崩掉整个对话流。
【面试题】3. RAG系统里，检索回来的文档质量参差不齐，你怎么保证最终答案的准确性？
【标准答案】分三步：检索阶段用混合检索——向量检索抓语义相近的，BM25关键词检索抓精确匹配的，两边结果做RRF融合排序，取TopN；重排序阶段加一个cross-encoder精排模型，把Top20里真正相关的挑出来；生成阶段在prompt里明确要求"只根据提供的文档片段作答，找不到依据就说不知道"。我们实测这套下来幻觉率从15%压到了3%以下。
【面试题】4. 多Agent协作时，Agent之间的通信和数据传递你是怎么设计的？
【标准答案】我用的是消息总线+共享上下文两层结构。消息总线负责Agent间的任务分配和结果回传，每个Agent注册自己能处理的工具类型，调度器按能力路由；共享上下文是一个结构化的任务状态对象，所有Agent只读消费之前的输出、只追加自己产出的部分，互不覆盖。踩过最大的坑是Agent之间互相"传话"导致信息失真——所以规定关键数据必须用结构化字段传递，不允许自然语言转述。
【面试题】5. 从零搭建一个企业知识库问答Agent，你会怎么拆任务、预估工期？
【标准答案】六步走，两周可交付MVP：第一周前两天，文档解析和切片——支持PDF/Word/Markdown，按语义分块而不是粗暴截断；第三天到第四天，搭向量库和检索链路——评估选Milvus还是ES的向量能力，编码模型选BGE或text2vec；第五天，写Agent主逻辑——包括意图识别、检索、prompt拼装、生成、引用标注；第二周前两天联调和评测，建一个50条测试集跑一遍准确率和召回率；后三天做前端和部署。核心风险点是文档质量参差和用户问法多样，前期要花时间做query改写和意图分类。
【面试题】6. 面试官：Agent的记忆系统你怎么设计？短期记忆和长期记忆分别怎么存？
【标准答案】短期记忆用对话历史的滑动窗口，最近N轮完整保留给模型，超出窗口的老对话做摘要压缩后拼进prompt头部——这样既控制token消耗又不丢上下文。长期记忆分两块：用户画像类（偏好、习惯、历史事实）存结构化数据库，每次对话开始时检索注入；知识类记忆（用户教你的东西）走向量库，需要时语义召回。关键原则：记忆不是越多越好，跟当前对话无关的记忆不要塞进prompt，会干扰模型判断。
【面试题】7. 你怎么评估一个Agent上线后的实际效果？用哪些指标？
【标准答案】分层看：第一层是任务成功率——用户意图最终有没有被满足，靠人工抽检+自动规则判断（比如"订机票成功"就是订单系统中的确认状态）；第二层是效率指标——平均对话轮次、首轮解决率、工具调用次数，越少越好；第三层是体验指标——用户点赞率、复问率（同一个问题短期内再问说明上次没答好）、平均交互时长。上线第一周我会每天看bad case，建一个"踩坑清单"针对性优化prompt和工具。
【面试题】8. 用LangChain/CrewAI这些框架时，你遇到过什么坑？怎么解决的？
【标准答案】最大的坑是框架封装的"黑盒感"——LangChain的Chain调用链一长，debug极其痛苦，中间哪个环节prompt拼错了根本看不到。我的做法是：核心逻辑不用框架，自己写plain Python调API；框架只用它的工具定义和编排能力。第二个坑是CrewAI的多Agent并发——它默认顺序执行，实际任务经常可以并行，我改成了task dependency DAG调度，构建依赖图让无依赖的任务同时跑，效率提升了40%以上。一句话：框架是脚手架，别当万能胶。
【面试题】9. 业务场景：用户说"帮我分析这季度的销售数据，找出下滑最严重的3个品类，写一份报告"——你的Agent怎么拆解和完成这个任务？
【标准答案】这是一个典型的多步推理任务，我会拆成6步：第1步，意图解析——识别出"分析销售数据""找下滑品类""生成报告"三个子目标；第2步，工具选择——调用数据库查询工具拉季度销售明细；第3步，数据分析——把原始数据交给LLM做同比环比计算，找出下滑Top3品类和下滑幅度；第4步，原因推测——让模型基于品类名称和时间段做合理的下滑原因推测，但明确标注这是"推测"不是事实；第5步，报告生成——按"数据概览→下滑明细→原因分析→改进建议"结构输出；第6步，最终校验——让Agent自检一遍数字是否矛盾、建议是否合理再交付。关键是把推理过程用thought字段透传给用户，让整个过程可解释。
【面试题】10. 面试情景：面试官问"你觉得Agent和传统if-else流程自动化有什么区别？用Agent会不会过度设计？"
【标准答案】核心区别是决策路径。if-else是确定性分支——你来定义所有情况，流程是死的；Agent是非确定性推理——它自己判断当前该做什么，能应对你没预定义的场景。什么时候用Agent？规则能穷举的场景千万别上Agent，成本高还不稳定；规则穷举不了的——比如客服意图识别、非结构化文档处理、多步骤推理决策——Agent才有价值。我判断的标准很简单：如果一个需求的流程图你画半小时画不清楚，用Agent；画得清楚，老老实实写代码。过度设计是Agent项目最常见的失败原因。