工作知识库

Appearance

AI智能体应用开发面试题 - 2026-06-12 ​

生成时间：2026-06-12 01:30
题目数量：10道
难度定位：1-3年经验

【面试题】1. 在实际项目中，你如何选择使用单智能体还是多智能体架构？请给出具体的决策依据。 ​

【标准答案】 主要看任务复杂度和可维护性两个维度：

  • 单智能体：适合任务链路清晰、工具调用路径固定的场景，比如客服问答、文档摘要。优势是延迟低、调试简单、成本可控。
  • 多智能体：当任务需要不同专业能力协作时才上，比如"研报生成"需要爬虫Agent+分析Agent+写作Agent。关键判断标准：能否把任务拆成多个独立子目标，且子目标之间有明确 Handoff 关系。
  • 踩坑经验：别为了炫技上多智能体。我见过团队把简单任务硬拆成3个Agent，结果协调成本比单Agent高3倍，还引入了状态同步的bug。一句话：能单不别多，能少别别多。

【面试题】2. LangChain的LCEL（LangChain Expression Language）和传统的链式调用相比，优势在哪里？请结合实际代码说明。 ​

【标准答案】 LCEL的核心优势是可组合性和流式支持：

  • 传统方式：chain.run() 是黑盒，中间过程不可控；LCEL用 | 管道符，每个组件都是可观测的Runnable。
  • 实际好处：可以做并行（RunnableParallel）、分支（RunnableBranch）、Fallback 链，而且原生支持 streaming，token 出来就能推给前端。
  • 代码示例：chain = prompt | model | output_parser，这三步任意插中间件，比如加 | RunnableLambda(log_step) 做日志。
  • 面试加分点：LCEL 的每次调用都返回标准化的 Runnable 接口，方便做单元测试和 mock，这是生产环境很看重的。

【面试题】3. 在构建RAG系统时，如何处理"检索到的上下文和用户输入语义相关但答案不准确"的问题？ ​

【标准答案】 这是RAG的经典痛点，我分三层解决：

  • 检索层：不要只用向量相似度，要混合检索——向量召回 + BM25 关键词 + 元数据过滤（时间/来源权重）。还可以用 HyDE（假设文档嵌入），让模型先生成假设答案再去检索，提升召回质量。
  • 重排层：检索回来后一定要过 Reranker 模型（比如 BGE-reranker），把真正相关的提到前面，截断无关上下文，避免"上下文污染"。
  • 生成层：Prompt 里明确告诉模型"如果上下文不足以回答，就说不知道"，别让它瞎编。还可以让模型在回答前先输出"我的依据是[文档X]"，方便溯源和兜底。
  • 实战数据：我们项目加了 Reranker 之后，答案准确率从 68% 提到 84%，成本只多了一次轻量模型调用，性价比很高。

【面试题】4. 请描述你如何设计一个具备"长期记忆"能力的AI智能体，包括技术选型和数据结构设计。 ​

【标准答案】 长期记忆的核心是分层存储 + 高效检索：

  • 技术选型：短期记忆用会话历史（Redis/内存），长期记忆用向量数据库（Qdrant/Milvus）。用户画像和关键事实单独存结构化数据库（PostgreSQL），方便精确查询。
  • 写入策略：不是所有对话都存，用 LLM 做摘要过滤——"这段话是否包含值得长期记住的信息？"只存高价值片段，避免向量库膨胀。
  • 检索策略：用户发起对话时，先查结构化画像（"这个用户是谁，偏好什么"），再语义检索相关历史片段，拼到 Prompt 里。
  • 遗忘机制：必须设计！我们按时间衰减 + 重要性打分，低分旧记忆定期清理，防止噪声积累。
  • 踩坑：早期我们所有历史都往向量库塞，结果检索出来一堆无关闲聊，反而干扰当前任务。后来加了"记忆质量评分"，效果立刻好转。

【面试题】5. CrewAI 和 LangChain 在智能体编排上有什么本质区别？分别适合什么场景？ ​

【标准答案】 本质区别是设计哲学不同：

  • LangChain：是"组件库"思路，提供各种 Lego 积木（Chain、Agent、Tool），灵活但你需要自己搭。适合需要深度定制、对执行流程有精细控制的场景。
  • CrewAI：是"框架"思路，内置了角色（Agent）、任务（Task）、流程（Process），开箱即用。它强调 Agent 之间的协作模式（顺序/层次/共识），适合快速搭建多智能体系统。
  • 选型建议：
    • 做单个复杂 Agent、需要自定义推理循环 → LangChain
    • 做多角色协作任务（比如"AI 团队写方案"） → CrewAI
    • 我们实际项目：CrewAI 做原型验证（2天出 Demo），LangChain 做生产重构（精细控制 + 监控埋点）

【面试题】6. 你如何评估一个智能体系统的"任务完成质量"？请给出具体的评估指标和设计思路。 ​

【标准答案】 不能只看"模型输出好不好"，要从三个维度建评估体系：

  • 任务完成率（硬性指标）：定义清晰的成功标准，比如"成功调用了所需工具并返回了格式正确的结果"。我们用工单系统的自动化测试，跑100个真实场景，算出通过率。
  • 输出质量（软性指标）：用 LLM-as-Judge 打分（成本可控），评估维度包括：准确性、完整性、安全性、语气适配。关键是写好评分 Prompt，把"好答案"的标准明确下来。
  • 用户满意度（最终指标）：埋点收集用户反馈（点赞/点踩/追问次数）。如果用户对答案追问超过2次，说明第一次没解决问题，这就是负样本，用来迭代 Prompt。
  • 实战经验：我们每周跑一次"失败案例复盘"，把低分样本拿出来人工分析，找到是检索问题、Prompt 问题还是模型能力边界，然后针对性优化。

【面试题】7. 在多模态智能体中，如何处理图像理解和文本生成的协同？请给出架构设计思路。 ​

【标准答案】 核心挑战是模态对齐和上下文管理：

  • 架构设计：分层处理，不要一股脑把图片塞给模型。
    1. 图像理解层：用多模态模型（GPT-4V/Qwen-VL）做图片描述、OCR、目标检测，输出结构化文本。
    2. 决策层：把结构化文本 + 用户问题拼成 Prompt，让文本模型做推理和规划。
    3. 生成层：根据需求输出文本/调用工具/生成图片。
  • 关键技术点：
    • 图片太多时，先做相似度聚类，避免重复描述消耗 Token。
    • 用"图片摘要 + 关键区域标注"的方式，让后续文本模型知道图片里有什么，而不需要每次都重新理解。
  • 实战案例：我们做电商客服 Agent，用户发商品图问"这款有没有红色"，流程是：检测商品区域 → 提取颜色特征 → 查库存 API → 回复。整个链路控制在 3 秒内。

【面试题】8. 请描述你如何优化智能体系统的响应延迟，特别是在使用多个工具调用的情况下。 ​

【标准答案】 延迟优化是系统工程，我分四层：

  • 模型层：用流式输出（streaming），Token 生成的同时就推给前端，用户感知延迟降低 50%+。对于工具选择这种中间步骤，用小模型（比如 GPT-3.5）做路由，只有真正需要推理时才调大模型。
  • 工具层：
    • 并行调用：多个无依赖的工具同时发请求（asyncio/gRPC），不要串行等。
    • 工具缓存：对于幂等查询（比如"查天气"），短时间内缓存结果，避免重复调用。
    • 设置超时和熔断：单个工具超时不能拖死整个链路。
  • 架构层：把智能体拆成"快速响应"和"深度思考"两个模式。简单问题（FAQ/查数据）走快速链路（<1s），复杂任务才走完整 ReAct 循环。
  • 数据：我们优化后，P95 延迟从 8.2s 降到 2.4s，用户满意度直接涨了 15 个点。

【面试题】9. 在智能体开发中，如何处理"模型幻觉"导致工具调用参数错误的问题？ ​

【标准答案】 这是生产环境的头号杀手，我用了四道防线：

  • Prompt 防御：在工具描述里写清楚参数约束，比如"date 格式必须是 YYYY-MM-DD，否则调用失败"。比写"请传入日期"有效得多。
  • 结构化输出：强制模型输出 JSON，并用 Pydantic 模型做校验。如果校验失败，把错误信息反馈给模型让它修正（给 3 次机会），还不行就降级到人工。
  • 工具侧防御：工具本身要做参数校验和兜底处理。比如用户说"明天"，工具层自动转成具体日期，而不是依赖模型100%准确。
  • 监控告警：记录所有工具调用失败案例，用 LLM 分析失败原因（是 Prompt 问题还是模型能力边界），然后批量优化 Prompt。
  • 实战经验：我们加了"错误反馈循环"后，工具调用成功率从 87% 升到 96%，剩下的 4% 主要是用户意图本身模糊，需要澄清。

【面试题】10. 如果让你从0到1搭建一个企业级智能体平台，你会如何设计技术架构？请说明关键决策。 ​

【标准答案】 我会分五层来设计，每层的决策依据都围绕"可扩展"和"可观测"：

  • 接入层：统一 API 网关，支持多渠道（企微/钉钉/Web），做鉴权和限流。别让智能体直接暴露，后期改会很痛。
  • 编排层：用工作流引擎（Temporal/Airflow）管理智能体执行流程，支持长时运行、断点续跑、失败重试。这是生产环境和 Demo 的核心差距。
  • 智能体层：每个智能体是独立微服务，通过标准化接口（OpenAI 的 Function Calling 格式）注册工具。这样不同团队可以独立开发智能体，只要遵守接口规范。
  • 数据层：
    • 向量库（Qdrant）存知识库
    • Redis 存会话状态
    • PostgreSQL 存业务数据和高价值记忆
    • Kafka 做操作日志埋点（用于复盘和微调数据积累）
  • 观测层：每个智能体调用都要 trace（用 LangSmith/Phoenix），记录 Prompt、工具调用、延迟、成本。没有观测等于盲飞。
  • 关键决策：第一期别贪大求全，先跑通一个高价值场景（比如客服/代码审查），把链路跑通再扩展。我们踩过的坑：一开始设计太通用，结果每个场景都要定制，反而慢了。

本文档由 AI智能体应用开发面试题生成器 自动生成
考点覆盖：架构设计、LangChain/CrewAI、RAG、记忆系统、多模态、性能优化、工具调用、平台设计