AI智能体应用开发面试题
生成时间：2026-06-16 00:15
【面试题】1. 大模型API调用的流式响应（SSE）和非流式响应在Agent场景下分别适合什么情况？有哪些容易忽略的坑？
【标准答案】非流式适合后端批处理、需要拿完整结果再做后处理的场景，比如批量生成、离线评估。流式适合面向用户实时交互的场景，体验差距巨大——10秒空白等待 vs 逐字显示。容易忽略的坑有三个：第一，流式拼接工具调用的JSON参数时，参数可能跨多个chunk，必须攒齐再解析，否则JSON解析必报错；第二，流式中断处理，网络抖动导致SSE断开，前端要有重连机制和超时检测，不能卡死；第三，流式模式下做内容安全审核更难，不能等全文出来再审，得边出边检，我们用的是小模型实时审核+事后复核。代码实现上FastAPI的StreamingResponse配合LangChain的astream_log方法，能同时拿到文本流和工具调用事件。
【面试题】2. 你们Agent项目里的Prompt模板是怎么管理的？多人协作时怎么避免Prompt版本混乱？
【标准答案】核心是把Prompt当代码管。我们用文件系统管理，每个Prompt一个Markdown文件，放在项目的prompts/目录下，按功能分目录，比如system/、tool_desc/、few_shot/。版本管理直接走Git，改Prompt必须提PR，线上加载时从文件读取不硬编码。多人协作的关键规则：系统级Prompt（角色设定、行为约束）改动需要评审，工具描述的修改要同步更新对应的测试用例。我们还做了一个简单的Prompt注册表，每个模板有version字段，运行时日志记录用了哪个版本，出了问题可以回溯。不要小看Prompt管理，项目大了几十个Prompt散落在代码里，改一个牵一发动全身，没有版本管理就是灾难。
【面试题】3. 场景题：老板要求做一个AI客服，能处理退货、查物流、推荐商品三种业务，你怎么设计Agent架构？
【标准答案】我推荐意图路由+专项Agent的架构，而不是一个大Agent包打天下。具体设计：第一层是意图识别，用小模型或规则做快速分类，判断用户要退货、查物流还是推荐商品；第二层是路由分发，根据意图把对话转给对应的专项Agent；第三层每个专项Agent独立设计工具和Prompt。退货Agent需要订单查询工具、退款策略知识库、人工转接能力；物流Agent需要物流追踪API、异常件处理规则；推荐Agent需要用户画像、商品向量库。好处是每个Agent职责单一，Prompt短、工具少，准确率远高于一个大Agent塞所有工具。共性能力抽取出来做共享模块，比如用户身份验证、对话历史管理。如果用Dify，就是三个工作流+一个路由节点；如果用LangGraph，就是一个Router节点分三个子图。
【面试题】4. 向量数据库选型时，Milvus、Qdrant、Chroma、Weaviate你怎么选？各自的适用场景是什么？
【标准答案】选型看三个维度：数据规模、部署方式、功能需求。Chroma最轻量，单机嵌入式，适合开发测试和小数据量（百万级以下），零运维成本但生产能力弱。Qdrant是Rust写的，性能好、支持过滤+全文混合查询，适合中等规模（千万级），Docker一键起，运维负担小，是我个人最推荐的中等规模首选。Milvus是云原生架构，支持分布式、多副本、动态扩容，适合亿级数据量和对可用性要求高的生产环境，但运维复杂，需要K8s。Weaviate强在模块化，内置向量化和多模态支持，适合不想自己管Embedding流程的团队。我的选型建议：小项目Chroma，中项目Qdrant，大项目Milvus，不想折腾Embedding选Weaviate。
【面试题】5. 多智能体系统中，一个Agent的输出是另一个Agent的输入，但中间格式经常对不上，你怎么解决"接口对齐"问题？
【标准答案】这个问题本质是多Agent的"协议层"缺失。解决方案是定义统一的中间数据格式——我们叫它Agent间通信协议（ACP）。具体做法：第一，每个Agent的输出必须符合预定义的JSON Schema，Schema文件集中管理，Agent开发时对着Schema写；第二，在Agent之间加一个适配层，如果某个Agent的输出和下游期望的格式不一致，适配层做字段映射和类型转换，而不是改Agent本身；第三，加Schema版本号，格式升级时老版本还能兼容。CrewAI里可以通过Task的output_json强制约束输出格式，LangGraph里在State定义时就把字段类型写死。核心原则：Agent之间只通过结构化数据通信，绝不传自然语言让下游去解析。
【面试题】6. 面试官问："你们RAG系统用了Rerank，但上线后延迟翻倍了，你怎么平衡效果和性能？"
【标准答案】Rerank延迟翻倍很常见，解法有三个层次。第一层是减少Rerank的输入量，不要把Top-50全送进去Rerank，先粗筛到Top-20再Rerank，或者用两阶段——先向量召回Top-100，BM25交叉过滤到Top-15，再Rerank，输入少了延迟直接降60%。第二层是异步和预计算，如果用户的问题有模式可循，可以在用户输入时就预测可能需要的知识并提前Rerank，或者把高频query的Rerank结果缓存起来。第三层是换轻量Reranker，Cohere的Rerank效果好但走HTTP有网络开销，本地部署bge-reranker-base模型，CPU推理单条10ms以内，效果只差2-3个点但延迟降一个量级。我的实际经验是：粗筛+本地Rerank的组合，延迟增加不到30%，但准确率提升15%，性价比最高。
【面试题】7. 你怎么理解"Prompt Engineering已死，Agent才是未来"这个说法？你同意吗？
【标准答案】不同意，这是偷换概念。Prompt Engineering和Agent不是替代关系，是包含关系——Agent的每一步决策、每个工具选择、每个输出生成，底层全靠Prompt驱动。Agent架构解决的是"流程编排"问题，Prompt解决的是"每一步怎么做"的问题。你搭了再好的多Agent架构，单个节点的Prompt写不好，输出一样是垃圾。实际上Agent时代对Prompt Engineering的要求更高了：以前一个Prompt搞定，现在要写系统Prompt、工具描述Prompt、路由Prompt、审核Prompt，数量多了还得分层管理。我认为准确的说法是"单轮对话式Prompt Engineering不够用了"，而不是它死了。面试中遇到这种问题，要能区分行业营销话和技术真相。
【面试题】8. 你们Agent系统上线后，怎么发现和修复"沉默失败"——就是Agent输出了看似合理但实际错误的答案？
【标准答案】沉默失败是Agent系统最危险的bug，因为不像报错那样容易被发现。我们的发现机制分三层。第一层是离线抽检，每天随机抽5%的对话做人工审核，这是最原始但最有效的方式。第二层是自动异常检测，用另一个LLM做"审计Agent"，对输出做多维评分：事实一致性、逻辑连贯性、是否幻觉，低于阈值自动标记。第三层是用户行为分析，如果用户问完一个问题立刻换种说法重问，大概率上一次回答不满意，这些case自动进入Bad Case库。修复流程是：标注问题类型→定位是Prompt问题还是检索问题还是工具问题→修改→跑评测集验证→上线。核心思路：沉默失败只能靠系统化的检测发现，不能指望用户主动反馈。
【面试题】9. 你做Agent项目时，怎么处理"用户输入模糊或存在歧义"的情况？让Agent直接猜还是主动追问？
【标准答案】关键原则是"低成本确认、高成本追问"。判断标准是：如果澄清问题的成本低于执行错误任务的成本，就追问；反过来就先执行再确认。具体来说，歧义分三类处理。第一类是参数缺失，比如"帮我订机票"没说目的地，这种必须追问，因为猜错了执行成本极高。第二类是意图模糊但有安全默认值，比如"推荐个手机"没说预算，可以先用中端机推荐并标注"如需调整请补充预算"，不用等用户。第三类是领域歧义，比如"苹果"指水果还是公司，看上下文判断，判断不了就追问，因为回答方向完全不同。技术实现上，我们在Agent的Prompt里加了"澄清决策树"，让模型自己判断该追问还是该执行，同时限制最多追问2轮，避免无限交互。
【面试题】10. 面试情景题：面试官说"我看你简历写了用LangChain做过Agent，但LangChain更新太快、抽象太重，很多人觉得不好用，你怎么看？"
【标准答案】这个问题不是在考你LangChain好不好用，是在考你有没有独立判断力，别跟风黑也别无脑吹。我的回答是：LangChain的问题确实存在——抽象层太多导致调试困难、版本迭代breaking change多、简单功能要绕很远的路。但它的优势也是客观的：生态最大、组件最全、LangGraph的StateGraph是真好用。我的实际策略是"取其精华"：LCEL和LangGraph用，因为声明式语法和状态机确实高效；BaseChain那些重抽象不用，自己写更可控；工具层用自己的封装，不依赖LangChain的Tool基类。另外团队选框架时，我会评估团队背景——Python强就用LangGraph+自己封装，Python弱就用Dify。面试官想听的是你踩过坑之后的选择，而不是人云亦云的结论。
生成时间：2026-06-16 00:15
题目数量：10道（不重复，覆盖1-3年岗位核心考点）