AI智能体应用开发面试题
生成时间：2026-06-15 23:45
【面试题】1. 在Agent开发中，如何设计一个可靠的"思考-行动-观察"循环来避免死循环？
【标准答案】三个关键机制。第一是最大迭代限制，硬编码上限比如5轮，超过就强制输出兜底回复，这是硬约束不能省。第二是重复检测，记录每轮的action和参数，如果连续两轮调了相同的工具且参数高度相似，判定为循环直接中断。第三是进度校验，每轮结束时让Agent自检"当前结果是否推进了目标"，如果没有推进就触发策略切换——换工具、换思路或承认无法完成。代码实现上，我用一个状态对象跟踪每轮的action_type、tool_name、params和result摘要，循环检测用哈希比对。核心原则：宁可提前终止给一个不完美答案，也不要让Agent无限烧Token。
【面试题】2. LangGraph中的StateGraph和MessageGraph有什么区别？什么时候用哪个？
【标准答案】StateGraph是自定义状态图，状态可以是任何结构（字典、对象），每个节点按你定义的schema读写状态，适合有明确业务流程的场景，比如订单审批流、工单处理，状态里可以存业务字段。MessageGraph是消息驱动图，状态就是消息列表，每个节点追加消息，天然适合对话型Agent，比如客服机器人、多轮问答。选StateGraph的场景：需要追踪业务进度、多分支决策、状态字段多。选MessageGraph的场景：纯对话交互、不需要复杂状态管理。我实际做客服系统用的是StateGraph，因为要追踪工单状态、客户等级、处理进度，单纯消息流搞不了这些业务逻辑。
【面试题】3. RAG系统中，如何处理用户问题涉及多个知识领域的情况？比如"对比A产品和B产品的售后服务政策"。
【标准答案】这类跨域问题需要两步策略。第一步是问题拆解，用LLM把复合问题拆成子问题，比如"A产品售后政策"和"B产品售后政策"，分别检索各自的知识库分区。第二步是结果聚合，把两次检索的结果合并后让LLM做对比分析，生成结构化答案。技术实现上，知识库要按领域分区建索引，检索时先做领域路由再定向召回。如果知识库没分区，就用元数据过滤，给每个文档标注领域标签，检索时根据子问题关键词筛选。还有一个细节：对比类问题容易因为两份文档长度不一致导致模型偏向信息更多的那一方，解决方案是对检索结果做等量截取，保证信息对称。
【面试题】4. 你在Agent项目中用过流式输出（Streaming）吗？为什么要做流式？有哪些实现细节需要注意？
【标准答案】流式输出是生产环境的标配，不做流式用户体验很差——用户等10秒看到一大段文字突然出现，体验远不如逐字显示。实现上用SSE（Server-Sent Events）推送，前端监听onmessage逐步渲染。需要注意的细节：第一，工具调用阶段也要流式，让用户看到Agent正在"搜索数据库"或"调用天气API"，给进度感；第二，流式chunk的拼接要处理好边界，特别是工具调用的JSON参数可能跨多个chunk，要攒齐了再执行；第三，异常处理不能丢，流式中断时前端要能识别并显示错误提示，不能卡在半截。我用LangChain的astream方法配合FastAPI的StreamingResponse，代码量不大但效果提升明显。
【面试题】5. 多模态Agent在处理语音输入时，你会怎么设计从语音到行动的完整链路？
【标准答案】四步链路。第一步语音转文字，用Whisper或ASR服务，注意加降噪和断句处理，长语音分段转写。第二步意图理解，文本进LLM做意图识别和槽位提取，语音场景容易有口语化表达和模糊指令，Prompt要专门适配。第三步行动执行，根据意图调用对应工具或知识库，结果转文字。第四步文字转语音回复，用TTS生成语音，注意语速和情感适配——查询结果用快语速，复杂解释放慢节奏。关键设计点：全程要做端到端延迟优化，ASR+LLM+TTS串起来很容易超过10秒，我的方案是ASR流式边转边送、LLM流式边生成边TTS，把串行变流水线，延迟从12秒压到4秒。
【面试题】6. Agent项目中如何做Prompt版本管理和效果回归测试？
【标准答案】Prompt就是代码，必须版本管理。我的做法是：每个Prompt单独存文件，文件名带版本号和日期，比如intent_classifier_v3_20260615.md，git追踪变更历史。效果回归测试分两层：第一层是自动化单元测试，准备一组固定输入，检查输出格式和关键字段是否正确，用pytest跑；第二层是语义评估测试，用另一个LLM做"评分裁判"，对比新旧Prompt输出质量的差异，评分维度包括准确性、完整性和格式合规率。实操建议：每次改Prompt必须跑回归测试，不要手动凭感觉判断效果。我还用LangSmith做trace记录，每次调用都能回溯到具体Prompt版本，出问题秒级定位。
【面试题】7. 在CrewAI中，Agent的role、goal和backstory三个属性分别怎么设计？写出你实际配置过的例子。
【标准答案】role定义身份标签，决定Agent在团队中的定位；goal定义核心任务目标，是Agent决策的导向标；backstory定义背景故事和性格，影响Agent的推理风格和输出语气。三者配合才能让Agent"像一个人"而不是"一段代码"。实际配置例子——数据分析师Agent：role="Senior Data Analyst"，goal="从原始数据中提取可行动的业务洞察，识别异常趋势"，backstory="10年数据分析经验，擅长用统计方法发现隐藏模式，表达简洁用数据说话，不喜欢模糊结论"。注意点：backstory不要太长，50-100字够了，冗长反而分散注意力；goal要具体可衡量，不要写"做好分析"这种废话。
【面试题】8. 向量数据库实战中，Milvus和Pinecone各有什么优劣？你的选型逻辑是什么？
【标准答案】Milvus是开源、自部署，功能全面，支持多种索引类型（HNSW、IVF_FLAT、IVF_PQ），适合数据量大、需要定制化、对成本敏感的场景，缺点是运维负担大。Pinecone是全托管SaaS，零运维，上手快，API简单，适合团队小、快速验证的场景，缺点是价格随数据量涨得快，定制空间小。我的选型逻辑：如果是内部项目、数据量百万级以上、有运维能力，选Milvus，成本可控；如果是创业项目MVP阶段、数据量十万级、想最快上线，选Pinecone。还有一个决策因素：数据合规，有些金融/政务数据不能放海外SaaS，这种情况Milvus是唯一选择。
【面试题】9. 面试官问："你们Agent上线后的数据怎么驱动的？说一个具体的迭代案例。"
【标准答案】我们上线了客服Agent后，第一周发现20%的对话在"退货政策"类问题上回答不完整。数据链路是这样走的：日志系统记录每轮对话的工具调用和最终输出；质量评估模块每周抽样100条对话，用LLM打分+人工review交叉验证；数据仪表盘可视化低分问题的分布。迭代案例：发现退货政策回答差后，我做了三件事——一是把退货政策文档从通用知识库单独拎出来建专库，检索优先级提到最高；二是Prompt加了"涉及退货时必须引用具体条款编号"的硬约束；三是新增了一个"退货政策专项问答"工具，直接查结构化数据而不是走RAG。迭代后这类问题的满意度从3.2分升到4.7分，整个过程两周完成。数据驱动不是口号，要有完整的采集-分析-改进闭环。
【面试题】10. 如果让你给一个传统的规则引擎系统（比如客服工单路由）用Agent方式改造，你会怎么做？什么保留、什么替换？
【标准答案】不是全盘推翻，是渐进式增强。保留的部分：规则引擎处理确定性强的任务，比如工单分类、优先级判定、SLA计时，这些逻辑清晰不需要LLM，速度快成本低。替换的部分：意图理解从关键词匹配改成LLM分类，准确率从60%提到90%以上；复杂问题处理从固定话术改成Agent动态推理+工具调用；跨领域知识查询从FAQ数据库改成RAG。改造步骤：第一步加一层Agent入口做意图路由，简单问题还是走规则引擎快速响应，复杂问题转Agent处理；第二步逐步把规则引擎里维护成本高的部分迁移到Agent；第三步保留规则引擎做兜底，Agent失败时降级到规则引擎。关键是不能为了用Agent就抛弃确定性逻辑，规则和Agent是互补不是对立。
知识点覆盖：
- 技术基础：死循环防护、Prompt版本管理、CrewAI角色设计
- 架构设计：LangGraph状态图选型、语音Agent链路、规则引擎改造
- 工具使用：流式输出实现、向量数据库选型
- 项目落地：数据驱动迭代案例
- RAG进阶：跨域复合问题处理
- 场景实操：面试情景问答