AI智能体应用开发面试题
生成时间：2026-06-15 23:25
【面试题】1. 请解释Function Calling和Tool Use的区别，以及在Agent开发中如何选择？
【标准答案】Function Calling是模型输出结构化JSON的能力，本质是"让模型学会调用接口"；Tool Use是运行时根据调用结果执行实际操作。两者的关系是：Function Calling负责"决定调用什么"，Tool Use负责"真正执行"。选择上，如果是GPT-4/Claude这类支持原生F/C的模型，直接用原生能力；如果是自研或特殊场景，可以用ReAct模式自己解析工具名。关键是控制好工具描述的质量——描述越清晰，模型选对工具的概率越高。
【面试题】2. 多智能体协作时，如何解决Agent之间的通信和状态共享问题？
【标准答案】常见方案有三种。第一种是共享消息队列，各Agent往同一个队列写消息，其他Agent消费，优点是解耦，缺点是延迟和顺序问题。第二种是共享向量库，把上下文存进去，Agent按需检索，适合文档类信息。第三种是中央协调器模式，一个主Agent负责任务分发和汇总，其他是执行单元，适合树形任务结构。我实际项目用的是第三种，配合状态机记录每个子任务的进度，结果统一回调给主Agent汇总。
【面试题】3. Dify和CrewAI在设计理念上有什么区别？各自适合什么场景？
【标准答案】Dify是"低代码+可视化"，强项是流程编排和非技术用户，拖拽节点、配置LLM、上线API，一条龙搞定，适合快速验证业务想法。CrewAI是"代码优先+角色扮演"，强项是多Agent协作场景，用Python写Agent、设定角色和任务链，适合技术团队做复杂自动化。选Dify的场景：内部工具、内容审核、简单问答机器人。选CrewAI的场景：研究报告生成、多角色销售流程、复杂数据处理流水线。
【面试题】4. RAG系统中，如何处理"检索到的文档太相似导致答案重复"的问题？
【标准答案】核心是增加检索多样性。常用四招：第一招是混合检索，结合稠密向量和稀疏BM25，不能总依赖语义相似度；第二招是Diverse Beam Search，在生成阶段强制采样不同视角的答案片段；第三招是重排序（Re-ranker），用Cohere之类的模型把相关度高但视角不同的文档排到前面；第四招是上下文压缩，把检索到的文档先摘要再塞进Prompt，控制冗余。我一般在第三步用Re-ranker配合MMR（最大边际相关性），效果比较稳。
【面试题】5. 请描述一次你从0到1搭建Agent项目的完整流程。
【标准答案】六步走。第一步需求对齐，明确Agent要替代哪部分人工工作，输出什么；第二步技术选型，根据团队技术栈和场景复杂度选框架，小场景用Dify，复杂多Agent用LangGraph；第三步核心链路设计，画流程图定Agent数量、工具、决策点；第四步Prompt迭代，用真实case反复调优，边测边改；第五步接入向量库和知识库，构造高质量检索；第六步上线监控，看调用成功率、响应延迟、用户满意度，上线不是终点，迭代才是。
【面试题】6. Agent的记忆系统通常包含哪几层？如何设计短期记忆和长期记忆的流转？
【标准答案】三层记忆。第一层是会话上下文，放在Prompt里直接用，适合5-10轮内的对话。第二层是会话Summary，用LLM定期摘要，跨会话保留关键信息。第三层是向量记忆，把重要对话和知识存进向量库，按需检索。流转逻辑：每轮对话先进短期记忆，直接拼进Prompt；长期记忆作为补充，通过相似度检索召回。关键设计点是"什么时候触发摘要"和"摘要写什么"，我会用对话轮次或token数做触发条件，摘要格式固定为"用户目标+关键结论+待办事项"。
【面试题】7. 在Agent任务规划中，ReAct和Plan-and-Execute两种模式的优缺点是什么？
【标准答案】ReAct是边想边做，每一步都结合思考和行动，响应快但容易"走一步看一步"，复杂任务容易跑偏。Plan-and-Execute是先规划再执行，先让Agent输出完整步骤列表，再按顺序执行，优点是全局视角、便于干预，缺点是第一步规划错了后面全错。选ReAct的场景：简单单步任务、工具调用为主的场景。选Plan-and-Execute的场景：复杂多步骤、需要人工review的业务。我现在更倾向混合模式——用Plan定框架，执行中遇到分支再用ReAct局部调整。
【面试题】8. 如何给Agent设计一套有效的错误处理和重试机制？
【标准答案】分三层设计。第一层是工具级别，每个工具调用都包try-catch，记录错误类型和上下文，返回结构化的失败信息而不是直接崩掉。第二层是Agent级别，维护一个"失败历史"列表，同一个错误不重复触发，给Agent最多3次重试机会，超限就降级或转人工。第三层是系统级别，关键任务做幂等设计，支持从断点恢复。实操中我会定义错误类型枚举，比如"网络超时"、"权限不足"、"模型幻觉"，针对不同类型给不同的兜底策略，不是简单重试。
【面试题】9. 向量数据库的索引类型（如HNSW、IVF、PQ）各自的特点是什么？如何选型？
【标准答案】HNSW是近似最近邻的老大哥，查询快、精度高，内存占用大，适合对延迟敏感的场景。IVF是倒排索引，分区管理，查询时先定位粗粒度分区再细搜，平衡精度和速度。PQ是量化压缩，把向量切成多段分别量化，极大减少内存但精度有损失，适合超大规模向量库。选型建议：百万级以下直接用HNSW，内存够就上；千万到亿级用HNSW+IVF组合；十亿级考虑Quantization+分区方案。我实际用Milvus做向量库，HNSW索引配适当ef参数，效果比较稳。
【面试题】10. 面试官问："如果LLM调用超时或返回乱码，你的Agent会怎样？你会怎么设计兜底策略？"
【标准答案】分三步处理。第一是快速失败，设置合理的timeout（比如10秒），超时就触发降级，不让用户干等。第二是降级链路设计，超时时切到本地规则引擎或关键词匹配，给一个"我收到你的问题了，正在处理"的兜底回复，不返回空。第三是异步补偿，用户不阻塞，任务进队列稍后重试，结果通过消息通知。根本原则是：用户体验优先，能给部分答案就不给空白答案，能异步就不让用户同步等待。代码层面每个LLM调用都要包超时和异常捕获，这是基本功。