AI智能体应用开发面试题
生成时间：2026-06-16 00:30
【面试题】1. 大模型API调用时，如何设计重试和降级策略保证系统稳定性？
【标准答案】 我一般用三层策略： 第一层是指数退避重试，针对429限流和5xx服务端错误，初始间隔1秒，每次翻倍，最多重试3次。用tenacity或者自己写个装饰器就能搞定。 第二层是模型降级，主模型比如GPT-4超时后，自动切到GPT-3.5或者国产模型备选，保证业务不中断。我在配置文件里维护一个模型优先级列表。 第三层是结果缓存，对于相同请求，用Redis缓存结果，TTL设短一点比如5分钟，既能抗峰值又能避免重复花钱。 实际项目中，这套组合拳让我负责的Agent服务可用性从95%提升到99.5%。
【面试题】2. Agent的工具调用(Tool Calling)和插件开发有什么区别？什么场景用哪个？
【标准答案】 工具调用是大模型原生的能力，模型自己决定什么时候调用、传什么参数。适合标准化、高频的操作，比如查天气、搜文档、调API。主流框架像LangChain的@tool装饰器、OpenAI的function calling都是这个思路。 插件开发更重，需要实现完整的认证、权限、生命周期管理。适合复杂业务场景，比如对接企业内部ERP、需要OAuth授权的第三方系统。 我的判断标准是：如果操作简单、调用频繁、不需要复杂权限，用工具调用；如果涉及敏感数据、需要用户授权、有多步业务逻辑，就做成插件。 之前我做了一个智能客服Agent，查订单用工具调用（高频简单），退款操作做成插件（涉及资金和权限），这样分工最合理。
【面试题】3. 多智能体协作中，如何解决Agent之间的冲突和重复工作？
【标准答案】 这个问题很关键，我实践过三种方案： 第一种是中央调度模式，设一个Manager Agent负责分配任务和协调，其他Agent只管执行。优点是逻辑清晰，缺点是Manager可能成为瓶颈。 第二种是黑板模式，所有Agent往一个共享状态里写中间结果，后来者先看黑板再决定做什么，避免重复。我在用CrewAI做内容生产时就是这样，写作Agent先检查编辑Agent的反馈再改稿。 第三种是投票机制，多个Agent给出方案后投票或加权平均。适合开放性问题，比如创意生成。 实际项目中我推荐混合使用：有明确流程的用中央调度，需要信息共享的用黑板，需要多样性的用投票。关键是提前设计好通信协议，别让Agent各干各的。
【面试题】4. RAG系统中，如何处理用户的模糊查询和多轮对话中的指代消解？
【标准答案】 这是RAG落地的两大痛点，我的解决方案： 模糊查询处理：用户说"那个方案"，系统不知道是哪个。我会在检索前加一个查询扩展步骤，用大模型把模糊查询改写成具体查询，比如提取关键词、补充上下文。另外向量检索和关键词检索混合使用（Hybrid Search），召回率能提升30%以上。 指代消解：多轮对话里用户说"它的价格呢"，我会在检索前做查询重写，把当前query和历史对话拼在一起，让模型生成完整query。比如把"它的价格呢"重写成"iPhone 15 Pro的价格是多少"。 我在Dify上做过一个产品知识库，加了这两步后，用户满意度从72%涨到89%。核心就是别把用户query直接扔进向量库，先"翻译"成检索系统能懂的完整表达。
【面试题】5. 智能体的记忆系统怎么设计？短期记忆和长期记忆如何配合？
【标准答案】 我的设计思路是模仿人类记忆： 短期记忆用对话历史，放在Prompt的上下文里。但上下文有长度限制，所以我会做滑动窗口，只保留最近N轮，或者用重要度打分保留关键对话。 长期记忆用向量数据库存储，每轮对话结束后提取关键信息（用户偏好、决策结论、任务状态）向量化存入。下次对话开始时，先检索相关记忆注入Prompt。 配合机制是：短期记忆保流畅性，长期记忆保一致性。比如用户说"按我之前说的改"，短期记忆里没有就去长期记忆里搜。 我用LangChain的ConversationBufferMemory + 向量库组合，在做一个个人助理Agent时，用户不用每次重复说背景，系统自动记住他的工作习惯和偏好。
【面试题】6. 面试情景：面试官问"你之前做的Agent项目遇到过最大的坑是什么？怎么解决的？"
【标准答案】 （这是经典行为面试题，我会用STAR法则回答） 最大的坑是大模型的幻觉问题导致工具调用失败。 情境：我做了一个智能选品Agent，让它分析市场数据后推荐商品。结果它有时会"编造"数据源，比如调用一个不存在的API，然后基于假数据给建议。 任务：需要在工具调用层面加校验，防止模型瞎编。 行动：我做了三件事。第一，工具定义时加详细的参数校验规则，不符合规范直接拒绝。第二，调用结果加一层"事实核查"，用另一个模型验证返回数据的合理性。第三，在最终输出里标注数据来源，让用户能追溯。 结果：上线后幻觉导致的错误从15%降到3%，用户信任度明显提升。这个经历让我明白，Agent不能只依赖模型的"自觉"，必须在框架层面加防护网。
【面试题】7. LangChain和CrewAI在多智能体开发上有什么区别？你怎么选择？
【标准答案】 LangChain是"积木式"框架，灵活但需要自己搭建。它的AgentExecutor、Tool、Memory都是独立组件，适合定制化程度高的项目。缺点是学习曲线陡，文档有时跟不上版本。 CrewAI是"一站式"框架，定义好Agent角色和任务就能跑。它的Concept是Agent、Task、Crew三层，多Agent协作开箱即用。缺点是灵活性差，复杂场景得绕框架。 我的选择标准：快速原型和简单协作用CrewAI，能省一半开发时间；复杂业务逻辑、需要深度定制用LangChain。 我最近一个项目是自动写研报的多Agent系统，涉及数据获取、分析、写作、审核四个角色，我选了CrewAI，两周就上线了。但之前做的金融交易Agent，需要精细控制每一步，就用LangChain手撸的。
【面试题】8. 如何评估一个Agent系统的效果？有哪些关键指标？
【标准答案】 Agent评估分三个维度： 任务完成率：核心指标。给Agent一组测试任务，看完成比例。比如客服Agent，100个问题里解决了多少个。 过程质量：不只看结果，看中间过程是否合理。包括工具调用准确率（该调的调了没）、推理步数（是不是走了弯路）、错误恢复率（出错了能不能自己修正）。 成本效率：Token消耗、响应时间、API调用次数。同样的任务，哪个方案省钱又快。 具体工具我用过LangSmith的评估框架，还有Dify内置的测试集功能。建议在开发阶段就建立测试集，别等上线了才发现问题。 之前我负责的Agent项目，先把任务完成率从60%优化到85%，然后发现Token消耗太高，又做了Prompt优化和缓存，最终成本降了40%。
【面试题】9. 长上下文时代，还需要RAG吗？什么场景用RAG，什么场景直接用长上下文？
【标准答案】 长上下文确实改变了游戏规则，但RAG仍然有价值： 用长上下文的场景：文档量不大（比如几十篇）、需要全文理解、用户要求快速响应。把文档直接塞Prompt，让模型一次读完，省去检索的麻烦。 用RAG的场景：文档量大（成千上万篇）、需要精准定位、数据实时更新、成本敏感。RAG只检索相关片段，Token消耗可控，数据更新只需改向量库不用重新训练。 我的经验是：文档<10万字且不频繁更新，优先长上下文；超过就上RAG。还有个混合方案叫Long-Context RAG，先RAG粗筛，再让模型读完整的相关文档，兼顾准确性和成本。 我做法律咨询Agent时，法规库有百万字，长上下文撑不住，只能RAG。但用户上传的单个合同，就直接塞长上下文分析。
【面试题】10. 如何从0到1落地一个AI Agent项目？请描述关键步骤和常见误区。
【标准答案】 我的五步方法论： 第一步：明确边界。Agent能做什么、不能做什么。很多项目失败是因为边界不清，用户期望过高。先定义清楚"成功标准"，比如客服Agent就是"解决80%常见问题"。 第二步：选择架构。单Agent还是多Agent？需要记忆吗？要哪些工具？我一般画个架构图，和产品对齐再动工。 第三步：数据准备。RAG要准备知识库，工具调用要准备API文档，少样本示例要准备高质量样例。垃圾进垃圾出，数据质量决定上限。 第四步：迭代开发。先跑通主流程，再优化细节。别一开始就追求完美Prompt，边跑边调。 第五步：监控上线。埋点记录每次交互，定期分析失败案例，持续迭代。 常见误区：一是低估Prompt工程难度，以为随便写写就行；二是忽视异常处理，Agent出错了怎么办没想清楚；三是成本失控，Token消耗没监控。 我经手的第一个Agent项目就踩过这些坑，后来总结成这套流程，项目成功率明显提高。
知识点覆盖：API稳定性、工具调用vs插件、多Agent协作、RAG查询优化、记忆系统设计、行为面试、框架选型、评估体系、长上下文vs RAG、项目落地
本文档由AI面试题生成器自动生成