工作知识库

Appearance

AI智能体应用开发面试题 ​

生成时间：2026-06-13 00:56
适用岗位：1-3年经验 AI Agent 开发工程师
题目数量：10道

【面试题】1. 在生产环境中调用大模型API时，如何处理限流、超时和重试？请描述你的实战方案。 ​

【标准答案】 从三个层面处理：

  1. 限流：用令牌桶或漏桶算法做客户端限流，避免突发流量打挂API；同时监控剩余quota，低水位提前告警。
  2. 超时：设置合理的connect timeout（5s）和read timeout（60s），区分网络超时和模型推理超时，分别处理。
  3. 重试：采用指数退避策略重试，只重试幂等的安全错误（429限流、500服务端错误），不重试参数错误等客户端问题。用tenacity库实现很方便，最多重试3次。
  4. 兜底：重试耗尽后走降级逻辑，比如返回缓存结果或触发人工客服，保证用户体验不中断。

【面试题】2. 什么场景下应该用单智能体，什么场景用多智能体？怎么判断？ ​

【标准答案】 核心看任务复杂度和关注点分离：

  • 单智能体：任务边界清晰、工具数量可控（<10个）、上下文能装下全部逻辑。比如：单轮问答助手、简单RAG问答、固定流程的自动化任务。
  • 多智能体：任务需要不同专业能力、子任务可以并行、需要角色隔离避免上下文污染。比如：代码生成场景（规划Agent + 编码Agent + Review Agent）、研究报告（搜索Agent + 分析Agent + 写作Agent）、复杂客服（意图识别Agent + 专业领域Agent + 质检Agent）。

判断标准：单Agent的prompt超过2000字还没说清楚、工具调用经常选错、不同任务的逻辑互相干扰——这时候就该拆多Agent了。

【面试题】3. Function Calling（工具调用）的实现原理是什么？实际开发中常见坑有哪些？ ​

【标准答案】 原理：把工具定义（JSON Schema格式）传给大模型，模型根据对话上下文决定调用哪个工具、传什么参数，返回的是结构化调用请求，业务代码执行工具后把结果回传给模型继续推理。

常见坑：

  1. 参数提取不准：模型可能瞎编参数值，需要加参数描述的约束，或用schema的enum/pattern限制
  2. 工具太多导致选择困难：超过20个工具时模型选不准，需要按场景动态筛选可用工具列表
  3. 递归调用爆栈：工具调用链太深（比如搜索→打开链接→再搜索），需要设最大调用深度（一般设5层）
  4. 执行结果太长：工具返回内容直接塞给模型会爆上下文，需要做摘要或截断处理
  5. 并行调用支持：不是所有模型都支持parallel function calling，需要确认模型能力

【面试题】4. 请设计一个RAG系统的完整方案，从文档入库到用户查询的全过程。 ​

【标准答案】 分离线和在线两条链路：

离线（文档入库）：

  1. 文档解析：支持PDF/Word/HTML，提取正文和表格
  2. 切片：按语义切分（用heading或段落），每块300-500字，重叠50字保留上下文
  3. 向量化：用embedding模型（bge-large或通义embedding）转向量
  4. 存储：存入向量数据库（Milvus/Qdrant），同时存原始文本和元数据（来源、时间）

在线（用户查询）：

  1. 查询向量化：用户问题转embedding
  2. 召回：向量数据库相似度检索，取top-K（一般5-10条）
  3. Rerank：用交叉编码器对召回结果重排序，提升精度
  4. 组装Prompt：把相关文档片段+用户问题组装成最终prompt
  5. 生成：调用LLM生成答案，引用来源

关键优化点：Hybrid Search（向量+关键词）、查询改写（多路召回）、自我评价（答案不确定时反问用户）

【面试题】5. 如果要做一个智能客服系统，支持售前咨询和售后投诉，你怎么设计Agent架构？ ​

【标准答案】 用多智能体协作架构：

  1. 路由Agent（入口）：先判断用户意图——售前/售后/闲聊，路由到不同专业Agent
  2. 售前Agent：接入商品知识库RAG，能回答参数、价格、活动；工具调用：查询库存、下单辅助
  3. 售后Agent：接入订单系统API、退款政策文档；工具调用：查订单、发起退款、创建工单
  4. 情绪识别模块：检测用户情绪，投诉升级时自动转人工，并记录到memory方便后续跟进
  5. 质检Agent（异步）：对对话质量打分，反馈给业务优化知识库和prompt

技术选型：LangChain做流程编排，Dify做可视化管理和快速迭代，Milvus存知识库，Redis存会话记忆。

落地关键：先跑MVP——单Agent+知识库问答，验证效果后再拆多Agent，避免过度设计。

【面试题】6. Agent的记忆系统有哪些实现方式？各自的优缺点和适用场景？ ​

【标准答案】 记忆分三层：

  1. 短期记忆（会话级）：

    • 实现：直接把对话历史塞context
    • 优点：简单，模型原生支持
    • 缺点：有上下文长度限制，长了会丢
    • 适用：短对话场景

  2. 长期记忆（跨会话）：

    • 实现：用向量数据库存储历史对话摘要，查询时检索相关记忆注入context
    • 优点：跨会话持久化，容量大
    • 缺点：检索可能不准，有延迟
    • 适用：需要记住用户偏好的场景（如个人助手）

  3. 工作记忆（任务级）：

    • 实现：Agent执行过程中用结构化状态机维护（如React的thought-action-observation循环）
    • 优点：任务执行过程可追溯
    • 缺点：需要额外开发
    • 适用：复杂多步任务

实战建议：短期用滑动窗口（保留最近10轮）+ 长期用向量检索，两者结合效果最好。记忆写入时机很重要——不是每轮都写，而是在任务完成或关键信息出现时才持久化。

【面试题】7. 提示词工程中，针对Agent开发有哪些进阶技巧？举具体例子说明。 ​

【标准答案】 Agent的prompt和普通问答不一样，核心是让模型学会用工具和规范输出格式：

  1. Few-shot工具调用示例：在system prompt里放2-3个工具调用的完整示例，比纯文字描述效果好得多。比如展示一个"用户问天气→调用get_weather→返回结果→回答"的完整过程。

  2. 结构化输出约束：要求模型用固定JSON格式返回工具调用请求，用JSON Schema做后置校验，解析失败就让他重新生成。

  3. 思维链引导：在复杂任务前加"请先思考解决这个问题需要哪些步骤"，让模型先规划再执行，减少工具调用错误。

  4. 错误处理指引：在prompt里告诉模型"如果工具调用失败，不要放弃，尝试用其他方式或告知用户"，避免直接崩溃。

  5. 角色和边界明确：比如"你是技术支持助手，只能回答技术问题，超出范围请引导用户联系人工"——减少幻觉和越权回答。

实战技巧：用LangChain的PromptTemplate管理多版本prompt，配合LangSmith做A/B测试和效果评估。

【面试题】8. 在多智能体协作中，Agent之间怎么通信？有哪些成熟的实现模式？ ​

【标准答案】 Agent通信分同步和异步两种模式：

同步模式（适合串行流程）：

  • 实现：一个Agent直接调用另一个Agent，等待返回结果
  • 框架支持：LangChain的AgentExecutor链式调用、CrewAI的sequential process
  • 适用：步骤之间有强依赖，比如先搜索再总结

异步模式（适合并行流程）：

  • 实现：用消息队列（Redis/RabbitMQ）或共享状态（数据库）解耦
  • 框架支持：AutoGen的GroupChat、LangGraph的并行节点
  • 适用：多个Agent可以并行工作，比如同时搜索不同来源

成熟模式：

  1. 路由模式：主Agent根据输入分发到子Agent
  2. 流水线模式：Agent A→B→C串行处理，每步加工数据
  3. 协作模式：多个Agent平等协作，通过投票或辩论达成共识（适合复杂决策）
  4. 层级模式：Manager Agent拆解任务，Worker Agent执行，适合复杂项目

实战建议：不要一上来就用复杂的异步通信，先用同步模式把流程跑通，瓶颈出现后再引入消息队列解耦。

【面试题】9. 向量数据库选型时，Milvus、Qdrant、Chroma、PGVector各自适合什么场景？ ​

【标准答案】 按数据规模和团队情况选：

  1. Chroma：

    • 适合：快速原型、小项目（百万级以下向量）
    • 优点：开箱即用，Python友好，无需部署服务
    • 缺点：性能一般，不适合生产大规模
    • 建议：验证方案阶段用Chroma，快速验证embedding和检索效果

  2. Qdrant：

    • 适合：中型项目（千万级向量），需要丰富过滤功能
    • 优点：Rust实现性能好，支持复杂过滤条件，API友好
    • 缺点：生态相对Milvus小一些
    • 建议：生产推荐，部署简单（Docker一键起）

  3. Milvus：

    • 适合：大规模生产（亿级向量），需要企业级特性
    • 优点：性能强，支持混合检索（向量+标量），有大厂背书
    • 缺点：部署复杂，资源占用高
    • 建议：数据量大（>千万）或需要GPU加速时用Milvus

  4. PGVector：

    • 适合：已有PostgreSQL基础设施的团队
    • 优点：无需额外维护向量数据库，事务支持好
    • 缺点：性能不如专门向量库，大规模检索慢
    • 建议：小团队、数据量不大时的省事选择

经验总结：百万级以下Chroma快速验证 → 千万级以下Qdrant生产 → 更大规模或企业场景Milvus。

【面试题】10. Agent系统上线后，怎么监控效果、发现问题、持续迭代？说一套完整的方法论。 ​

【标准答案】 监控分技术指标和业务指标两层：

技术监控：

  1. 调用链路追踪：每次Agent运行的完整日志（用了哪些工具、每步耗时、token消耗），用LangSmith或自研日志系统
  2. 异常监控：工具调用失败率、API超时率、大模型返回异常的比例，设告警阈值
  3. 性能监控：端到端响应时间P50/P95，找出慢的工具或流程瓶颈

业务效果监控：

  1. 答案质量：人工抽检+自动化评估（用LLM当裁判打分），关注准确性、完整性、安全性
  2. 用户反馈：每次对话后加👍👎反馈按钮，收集用户主观评价
  3. 任务完成率：比如客服场景的"问题是否解决"，定义明确的成功指标

迭代流程：

  1. 每周看监控报表，找出Top 3问题（比如某个工具经常失败、某类问题回答不好）
  2. 针对性优化：调prompt、加few-shot、更新知识库、修工具bug
  3. A/B测试：新版本和旧版本对比，确认效果提升再全量发布
  4. 用户反馈闭环：用户点👎的问题自动进入待优化队列，人工review后更新系统

关键：监控不是一次性工作，要融入日常开发节奏，一般每周花1小时review监控数据。

本文档由 AI智能体应用开发面试题生成器 自动生成