工作知识库

Appearance

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

生成时间：2026-06-16 23:56 适用岗位：1-3年经验 AI Agent 开发岗

【面试题】1. 大模型API调用在生产环境中，你如何设计限流、超时和重试机制？ ​

【标准答案】 核心是靠三层防护：

重试层：用指数退避，遇到429或5xx自动重试，间隔1s→2s→4s，最多3次。用tenacity库最方便。

限流层：用Semaphore控制并发数，避免突发流量打爆配额；高频相同问题加语义缓存，命中直接返回，能省60%+调用量。

超时层：connect timeout设10s，read timeout设60s；超过就断，不能让用户一直转圈。

关键是把每次调用的token消耗、延迟、成功/失败都打日志，方便后续分析和优化。我们项目里还会对高消耗用户做告警，防止异常调用把配额耗完。

【面试题】2. 请描述一下你做过的RAG系统，召回率和准确率不高时你是怎么优化的？ ​

【标准答案】 我一般按"召回→重排→生成"三阶段来优化：

召回阶段

  • Chunk策略：语义切分比固定字数切分效果好，重叠10-20%保留上下文
  • 混合检索：向量检索+BM25关键词检索融合，召回率明显提升
  • 查询改写：用户问"这个东西怎么样"，先让LLM改写成"XX产品优缺点分析"，再去做检索

重排阶段

  • 用CrossEncoder做Rerank，Top-20召回→Top-5送入LLM，噪音少很多
  • 还会过滤相似度低于阈值的片段，避免"为了有上下文而塞垃圾"

生成阶段

  • Prompt里明确说"仅基于以下资料回答，不确定就说不知道"
  • 要求输出引用来源，方便溯源，也倒逼模型别乱编

用RAGAS跑指标，看Context Precision和Faithfulness，哪个低就针对性调哪个环节。

【面试题】3. 多智能体系统设计中，你如何选择通信机制和任务编排模式？ ​

【标准答案】 通信和编排是多Agent系统的两个核心决策：

通信机制

  • 简单场景：共享消息列表，每个Agent读上一家的输出，像流水线
  • 复杂场景：用Redis做状态总线，每个Agent独立运行，通过状态变化触发下游
  • 需要回溯：用LangChain的MessageHistory，保留完整对话树

编排模式

  • 顺序执行：任务有强依赖，A的输出是B的输入，用Supervisor统一调度
  • 并行执行：任务可拆分，用asyncio.gather并发跑，最后汇总
  • 动态路由：让Router Agent根据任务类型决定发给谁，灵活但难调试

实际落地建议：先单Agent跑通全流程，确认瓶颈在哪再拆多Agent，别一开始就搞复杂。我们之前一个项目，拆了3个Agent后发现维护成本太高，又合回去了。

【面试题】4. 智能体的工具调用（Tool Use / Function Calling）失败率高的话，你从哪几个方向排查？ ​

【标准答案】 工具调用失败我一般按"模型→参数→执行→环境"四层排查：

模型层

  • LLM有没有理解工具的用途？Tool描述写清楚"什么时候用、参数是什么格式"，比写100行代码管用
  • 复杂工具拆小，一个Tool做一件事，别让LLM困惑

参数层

  • LLM输出的JSON可能不合法，应用层必须做参数校验和类型转换
  • 必填参数缺失时，别直接报错，把缺失信息反馈给LLM，让它补全

执行层

  • 工具本身有没有Bug？加try-catch，执行失败把错误信息返回给LLM，让它决定重试还是换方案
  • 涉及写操作的工具，加二次确认或权限校验

环境层

  • API限流、网络超时、依赖服务挂了，这些要在工具外部处理，别让LLM背锅

我们项目里会给每个工具调用打日志：成功率、平均耗时、常见错误，每周复盘一次。

【面试题】5. 如果让你从零设计一个代码审查智能体，你会怎么架构？ ​

【标准答案】 我会按"理解→分析→建议→报告"四个模块来设计：

代码理解模块

  • 用AST解析器（如tree-sitter）提取函数调用关系、变量依赖
  • 把代码片段和上下文（imports、类定义）一起送给LLM，它才能看懂

问题分析模块

  • 静态检查：接ESLint/SonarQube，先过滤语法和风格问题
  • 逻辑检查：让LLM对比类似开源项目的实现，找潜在Bug
  • 安全检查：用专门的安全扫描Tool，别指望LLM发现所有漏洞

建议生成模块

  • 别只说"这里有问题"，要给具体修改方案和理由
  • 用Few-shot示例训练输出格式：问题描述+严重程度+修改建议+示例代码

报告模块

  • 按文件/函数聚合问题，优先级排序
  • 生成Markdown报告，支持在PR评论里直接展示

关键是先跑通一个语言（如Python），验证效果后再扩展多语言支持。

【面试题】6. LangChain的LangGraph和CrewAI你更推荐哪个？各自适合什么场景？ ​

【标准答案】 两个工具定位不同，没有绝对好坏：

LangGraph适合

  • 需要复杂状态流转的场景，比如"用户可能随时改变需求，Agent要动态规划下一步"
  • 需要精细控制每一步的逻辑，LangGraph的图结构让你能精确控制状态转移
  • 团队有较强Python能力，能接受较陡的学习曲线

CrewAI适合

  • 快速搭建多角色协作系统，概念清晰（Agent/Task/Crew），代码量少
  • 原型验证阶段，2天能跑通一个多Agent Demo
  • 团队希望快速交付，不愿意在框架细节上花太多时间

我们的选择

  • 生产级复杂系统用LangGraph，灵活性够
  • 内部工具快速落地用CrewAI，交付快
  • 两个都用的话，CrewAI做原型，验证可行后迁移到LangGraph

关键看团队能力和项目周期，别为了用新框架而用新框架。

【面试题】7. 智能体系统的记忆机制，你如何平衡上下文长度和记忆质量？ ​

【标准答案】 核心是"分层记忆+智能压缩"：

分层策略

  • 最近3-5轮对话放Context Window，保证流畅
  • 历史对话做摘要，压缩后作为长期记忆
  • 关键信息（用户偏好、已完成的任务）结构化存储，按需查询

压缩策略

  • 用LLM对长对话做摘要，提取核心信息，能压缩80%以上
  • 摘要质量关键在Prompt：明确告诉LLM"保留决策、偏好、未完成的任务，去掉寒暄和重复"
  • 定期合并旧摘要，避免摘要本身变得太长

检索策略

  • 长期记忆存向量库，需要时语义检索相关片段
  • 用Time-weighted召回，最近的信息权重更高
  • 用户显式说"记住这个"的信息永久保存，不受压缩影响

实际落地，上下文长度够用（如32K+）就别过度压缩，信息损失比token成本更贵。

【面试题】8. 你如何评估一个智能体是否需要引入人类反馈（Human-in-the-Loop）机制？ ​

【标准答案】 三个信号告诉我需要加Human-in-the-Loop：

高风险操作

  • 涉及资金、合同、敏感数据修改的操作，必须人工确认
  • 我们项目里，退款超过500元、修改用户手机号，都会暂停让人工审核

低置信度场景

  • LLM输出做结构化解析后，置信度低于阈值（如0.7）自动转人工
  • 用另一个轻量模型做Fact Check，发现不一致就触发人工

新场景冷启动

  • 系统刚上线，覆盖场景有限，人工介入能积累Bad Case
  • 我们会让人工标注"模型哪里做错了"，这些数据用来优化Prompt和工具

实现方式

  • 简单场景：让用户在最终执行前点"确认"
  • 复杂场景：用LangChain的HumanApprovalCallback，暂停执行等人工反馈
  • 异步场景：把待审核任务推到企微/钉钉，人工处理完再继续

关键是别把所有决策都交给人工，那还不如不用AI；也别完全自动化，高风险场景必须留后门。

【面试题】9. 向量数据库选型时，你考虑哪些因素？Chroma、Milvus、Qdrant各自适合什么场景？ ​

【标准答案】 选型我看四个维度：数据规模、部署复杂度、功能需求、团队熟悉度。

Chroma

  • 适合：小规模（百万级以下向量），本地部署，快速原型
  • 优势：开箱即用，Python友好，不需要额外基础设施
  • 劣势：分布式能力弱，大规模检索性能下降
  • 我们用它做本地开发和POC验证

Milvus

  • 适合：大规模（亿级向量），需要水平扩展的生产环境
  • 优势：性能好，支持混合检索（向量+标量过滤），社区活跃
  • 劣势：部署复杂，需要K8s或Docker Compose，运维成本高
  • 我们生产环境用Milvus，数据量千万级，检索延迟<100ms

Qdrant

  • 适合：中等规模，需要丰富过滤功能的场景
  • 优势：Rust实现性能好，过滤语法灵活，单机部署简单
  • 劣势：分布式能力不如Milvus成熟
  • 适合做垂直场景的智能客服、知识库检索

选型建议

  • POC阶段用Chroma，快速验证
  • 生产环境数据量大（>千万）用Milvus
  • 中等规模、需要复杂过滤用Qdrant
  • 别只看性能指标，团队能不能运维起来同样重要

【面试题】10. 智能体系统上线后，你如何建立监控和迭代闭环？ ​

【标准答案】 上线只是开始，持续迭代才是关键。我一般建三个闭环：

数据监控闭环

  • 核心指标：任务完成率、人工接管率、用户满意度（👍👎）
  • 打点：每轮对话记录意图识别结果、工具调用成功/失败、LLM响应时间
  • 异常告警：成功率低于95%、P95延迟超5s，自动告警

Bad Case分析闭环

  • 每天自动拉取失败案例（人工接管、用户点👎、工具调用失败）
  • 每周复盘Top 10失败原因，分类：Prompt问题/工具Bug/知识库缺失/模型能力边界
  • 针对性优化：Prompt问题改Few-shot，工具Bug修代码，知识库缺失补文档

模型迭代闭环

  • 收集高质量对话数据，做SFT或继续预训练（如果有资源）
  • 用RAGAS或人工标注评估优化效果，避免"感觉效果好"这种主观判断
  • A/B测试：新Prompt或新模型小流量灰度，数据好再全量

关键是"可量化+快速迭代"，别等一个月再复盘，那时候用户可能已经跑了。

本题库由AI智能体应用开发面试题生成器自动生成，仅供学习交流使用。