AI智能体应用开发面试题
生成时间：2026-06-15
【面试题】1. 你在调用大模型API时，遇到过哪些"明明模型能力强但实际效果差"的情况？你是怎么定位和解决的？
【标准答案】
这种情况我遇到最多的就是上下文太长导致的遗忘和输出格式不稳定。
比如给模型一堆参考文档让它提取信息，文档长了它就开始丢关键内容，或者输出格式乱掉。
我的排查思路是：
- 先做减法：把上下文砍到原来的一半甚至三分之一，看问题是否消失。如果好了，说明是上下文长度问题。
- 加证据密度：长文本用摘要+原文的方式喂给模型，而不是直接塞完整文档。
- Few-shot强化：在prompt里给2-3个完整示例，让模型理解你真正要什么格式。
- 输出结构约束：用JSON Schema或markdown表格框死输出格式，减少模型自由度。
核心就一句话：模型强不等于用它强，要帮它减负、控制输出。
【面试题】2. 解释一下什么是"Agent记忆系统"，你会在什么场景下选择用短期记忆、长期记忆、还是混合方案？
【标准答案】
短期记忆：当前会话内的上下文窗口，用完即弃。比如对话历史、刚处理的任务状态。
长期记忆：持久化存储，跨会话存在。用向量数据库存历史经验、用户偏好、知识片段。
我的选择逻辑：
- 纯短期：单轮问答、一次性任务、用户明确说"这次用完不要记住"
- 纯长期：需要持续学习用户习惯的个人助理，比如每天跟进用户的工作进度
- 混合（最常用）：短期记忆负责当前任务上下文，长期记忆负责"冷启动"——比如用户一说"继续上次那个项目"，从向量库召回之前的关键信息注入短期上下文
实操中我一般用这种架构：最近N轮对话 → 短期记忆 → 向量库检索 → 长期记忆召回 → 注入当前上下文。这样既不会让上下文爆炸，又能继承历史。
【面试题】3. Dify和CrewAI在多智能体协作上的设计思路有什么区别？你更倾向怎么选？
【标准答案】
Dify：偏向工作流编排，用可视化画布把节点串起来。每个节点可以是LLM、工具或子工作流，擅长流程固定、环节多的业务场景。比如"信息收集→审核→生成→发布"这种流水线。
CrewAI：偏向角色驱动的多Agent协作。每个Agent有角色、目标、 backstory，Agent之间通过任务分发和结果汇报协作。适合"让不同角色自主协作解决问题"的场景。
我的选择：
- 业务流程固定、需要人工干预节点 → Dify
- 需要多个角色自主协商、动态分工 → CrewAI
- 复杂项目里也可以组合用：Dify做外层工作流，CrewAI做某个环节的多角色协作模块
说白了，Dify是流水线思维，CrewAI是团队协作思维。
【面试题】4. 你怎么理解"ReAct"和"Plan-and-Execute"这两种Agent推理模式？分别在什么场景下用？
【标准答案】
ReAct（推理+行动交替）：边想边干，每一步都基于当前观察做决策。适合环境反馈重要、步骤需要动态调整的场景。比如在网页上操作，每一步要看上一步的结果再决定下一步。
Plan-and-Execute（计划然后执行）：先一次性规划完整路径，再按计划执行。适合任务路径相对固定、执行效率优先的场景。比如批量处理文档，先规划好"读取→清洗→入库→生成报告"的路径再跑。
实际选型：
- 探索性、交互式任务 → ReAct
- 批量自动化、管道式任务 → Plan-and-Execute
有个优化技巧：可以把两者结合——用Plan-and-Execute做外层大框架，ReAct处理框架中需要灵活应对的环节。这样既有规划效率，又有动态适应能力。
【面试题】5. 场景题：用户说"AI回答总是很空洞，像正确的废话"，你从哪些角度优化？
【标准答案】
这个问题本质是缺少约束和具体性，我从四个角度改：
- 加角色约束：让AI扮演特定身份，比如"你是有个10年经验的电商运营"，逼它输出具体业务语言
- 强制要求证据：prompt里明确"每条结论必须给出数据支撑或案例支撑"，让它没法空对空
- 限定输出结构：要求它必须按"观点+论据+示例"的格式输出，强制它填充内容
- 注入真实上下文：把用户自己的数据、之前的对话、相关文档作为输入喂给它，让它基于具体信息回答
核心思路：AI的"废话感"来自于太抽象、太通用、太自由。给它具体角色、具体信息、具体格式约束，它自然就落地了。
【面试题】6. 你在项目中用过哪些向量数据库？为什么选它？有没有遇到过召回质量问题？
【标准答案】
我用过的有Milvus、Chroma、Qdrant三个。
- Chroma：本地轻量级，调试阶段用，部署简单。缺点是生产环境并发不行。
- Milvus：分布式、亿级向量支持，适合大规模生产环境。但运维成本高。
- Qdrant：我目前主推，向量+元数据混合过滤做得好，支持动态 Schema，对复杂检索场景更友好。
召回质量问题排查：
- Embedding模型不匹配：用中文场景就必须用中文Embedding，用英文模型跑中文基本废掉
- 分块策略不对：块太大稀释相关性，块太小丢失上下文。我一般测试 256/512/1024 token 三个档位
- Top-K取值：K太大引入噪声，K太小容易漏掉。经验值是 3-5，配合rerank用效果更好
- 加 rerank 层：先向量召回粗筛，再用BGE-reranker精排，效果提升明显
【面试题】7. 在多智能体协作中，如果两个Agent的观点冲突了，你怎么处理？
【标准答案】
我一般分三种策略：
- 预设仲裁规则：在系统prompt里定义优先级，比如"技术Agent的判断优先级高于运营Agent"。适用于冲突可预判的场景。
- 投票/协商机制：设计一个"裁判Agent"或让多个Agent对同一个问题各给方案，再通过投票或第三方裁决决定。
- 人工兜底：关键决策点设置人工确认环节，不让AI自己闭环。适用于涉及金钱、合规等高风险场景。
实操建议：
- 80%的情况下，冲突来自于信息不对称，先让双方共享上下文再决策
- 设计Agent时，明确每个Agent的职责边界，冲突往往是因为边界模糊
- 做好冲突日志记录，方便事后复盘优化
【面试题】8. 你怎么做Agent的错误处理和容错？有没有具体的降级策略？
【标准答案】
我的容错体系分三层：
第一层：重试
- API超时、偶发错误 → 自动重试3次，指数退避（1s→2s→4s）
第二层：降级
- 模型回复格式错 → 触发备用prompt模板
- 模型完全不可用 → 降级到规则引擎或返回"当前服务繁忙，请稍后重试"
- RAG召回为空 → 返回"未找到相关信息，建议您换个问法"
第三层：告警与人工介入
- 连续失败超过阈值 → 记录日志+发告警+挂起任务，等人工处理
关键原则：每个Tool都要定义明确的错误码和错误描述，不能让Agent自己猜测错误原因。我一般用try-catch包裹每个工具调用，异常时直接返回结构化的错误信息给上层决策逻辑。
【面试题】9. 面试情景题：面试官问"你觉得Agent从0到1落地最难的部分是什么？"，你怎么回答？
【标准答案】
我觉得最难的不是技术，是定义问题和验证价值。
技术层面，现成的框架和模型已经很强了，按文档搭个能跑的系统不难。但：
- 问题定义不清：很多需求方自己都不知道想要什么，说"做个智能客服"，结果真正要解决的是"降低30%投诉率"，这两个完全不是一回事
- 效果怎么量化：Agent的输出不像传统代码有明确的对错，怎么定义"好"、怎么设baseline、怎么证明提效了，都是坑
- 冷启动成本：Agent需要足够的上下文和知识才能表现好，但往往项目初期数据最少、最难调优
我的经验是：先花双倍时间做需求拆解和效果定义，技术实现反而是后半段的事。而且一定要做灰度发布，先让真实用户用起来再迭代，别憋大招。
【面试题】10. 你怎么做Agent系统的性能优化？有没有具体的优化手段？
【标准答案】
性能优化我分三个维度：
延迟优化：
- 减少模型调用：能用规则判断的就不要调模型，比如意图分类，简单场景用关键词匹配
- 流式输出：不要等模型完整回复，用户感知更快
- 模型选型：非关键任务用小模型，重要任务才上大模型。比如摘要用GPT-3.5，创意生成用GPT-4
成本优化：
- Prompt压缩：去掉冗余表达，减少token消耗
- 缓存相似请求：用户问题重复率高，用语义缓存命中直接返回
- 批量处理：把多个可以并行的任务聚合调用，减少API开销
稳定性优化：
- 限流熔断：防止突发流量打爆后端
- 异步队列：非实时任务进队列，削峰填谷
- 多模型兜底：主模型挂了切备用模型
核心原则：先profile找到瓶颈再优化，不要过早优化。一般先优化调用链路和缓存，再考虑模型层面的压缩和降级。