AI智能体应用开发面试题
生成时间：2026-06-16
题目数量：10道
适用岗位：1-3年经验 AI Agent 开发工程师
【面试题】1. 在实际项目中，调用大模型 API 时如何应对限流（Rate Limit）和超时问题？请给出你的解决方案。
【标准答案】 三层防护： 第一层，客户端限流。用令牌桶或滑动窗口控制请求频率，避免触发平台限制。 第二层，重试机制。遇到 429 或超时，指数退避重试（1s、2s、4s…），最多 3-5 次，同时记录日志方便后续分析。 第三层，降级策略。主模型挂了自动切备用模型，或者返回缓存的历史相似回答，保证用户体验不中断。 另外，生产环境一定要做并发控制，别让用户请求直接打到 API，加个队列或者连接池管理。
【面试题】2. 什么场景下用单智能体，什么场景下必须上多智能体？说一个你做过的项目决策。
【标准答案】 单智能体适合任务边界清晰、流程固定的场景，比如"根据用户问题查数据库并返回结果"，一个 Agent + 几个工具就能搞定，维护成本低。 多智能体适合任务需要分工协作的复杂场景。我之前做过一个研报生成项目，就拆成了三个 Agent：一个负责搜集资料（调用搜索工具），一个负责提取关键信息（读文档+摘要），一个负责生成报告（写作+格式化）。三个 Agent 通过消息队列传递结果，各司其职，比一个"万能 Agent"效果好太多——因为提示词可以更专注，不容易混淆角色。 判断标准很简单：如果一个 Agent 的提示词超过 500 字还在加功能，就该拆了。
【面试题】3. Function Calling 和 ReAct 有什么区别？实际开发中你会怎么选？
【标准答案】 Function Calling 是大模型原生的工具调用能力，模型输出结构化 JSON 告诉你要调哪个函数、参数是什么，你执行完把结果返回给模型，它再决定下一步。优点是精准、延迟低，适合工具数量固定、调用逻辑清晰的场景。 ReAct 是"推理+行动"循环，模型自己决定下一步做什么（Thought → Action → Observation），更灵活，适合开放域任务，但容易"跑偏"，而且 token 消耗大。 我的选择逻辑：工具少于 10 个、任务流程可预期 → Function Calling；需要模型自主探索、工具动态发现 → ReAct。实际项目里，我一般用 Function Calling 做核心链路，ReAct 只用在需要"智能探索"的环节。
【面试题】4. 你做过 RAG 项目吗？说一个最坑的问题，以及你是怎么解决的。
【标准答案】 最坑的是"检索对了但回答错了"——文档召回准确率是 85%，但最终回答准确率只有 60%，用户投诉说"你们 AI 瞎编"。 排查发现两个问题：一是召回的 chunk 太大，包含无关信息干扰了模型；二是模型没有严格基于检索内容回答，容易"自由发挥"。 解决方案：
- Chunk 优化：从 500 字降到 200 字，重叠区从 50 字调到 30 字，用语义切分而不是固定字数；
- Prompt 改造：在系统提示词里加强制约束，"你必须且只能基于 <retrieved_docs> 中的内容回答，如果信息不足，明确告知用户"；
- 加了一层"答案可追溯"机制：回答里标注引用来源，用户可以看到 AI 依据的是哪段文档。 改完之后，回答准确率从 60% 拉到了 82%。
【面试题】5. 假设让你设计一个"智能客服 Agent"，支持查订单、退换货、推荐商品，你会怎么架构？
【标准答案】 分层设计： 接入层：企微/小程序/API，统一消息格式传入。 理解层：用意图分类模型（或大模型零样本分类）识别用户需求：查订单 / 退换货 / 推荐 / 闲聊，路由到不同 Agent。 执行层：
- 查订单 Agent：调订单 API，参数从用户对话里提取（订单号、手机号），返回格式化结果；
- 退换货 Agent：先查订单状态（是否已发货、是否在售后期内），再引导用户填写原因，调售后 API 创建工单；
- 推荐 Agent：拉取用户历史购买记录 + 当前对话上下文，调推荐算法 API，返回 Top3 商品卡片。 记忆层：用 Redis 存会话上下文（用户 ID、当前订单号、对话历史），保证多轮对话不丢状态。 兜底层：命中不了任何 Agent 就转人工，同时把对话日志存下来，后续分析问题。 关键是每个 Agent 只做一件事，别搞一个"超级 Agent"什么都干。
【面试题】6. 向量数据库你用过哪些？选型时你最看重哪三个指标？
【标准答案】 用过 Pinecone、Milvus、Pgvector。选型我最看重这三个： 第一，检索性能。百万级向量，召回延迟能不能稳定在 50ms 以内？Pinecone 托管服务这块很强，但成本高；Milvus 自建，调优后也能做到，而且支持 GPU 加速。 第二，过滤能力。实际业务里，你很少"全量语义检索"，通常是"在指定知识库 + 指定时间范围 + 指定文档类型"里检索，这就需要向量数据库支持元数据过滤（scalar filtering）。Milvus 和 Pinecone 都支持，Pgvector 较弱。 第三，运维成本。小团队优先托管服务（Pinecone / Azure AI Search），别在数据库运维上分散精力；大厂有基础设施团队，Milvus / Qdrant 自建更省钱。 补充一个坑：别只看"支持多少维向量"，要看实际业务里你的 embedding 模型输出多少维（比如 text-embedding-3-small 是 1536 维），维度不匹配直接没法用。
【面试题】7. 智能体的"记忆系统"你怎么设计？短期记忆和长期记忆怎么区分？
【标准答案】 短期记忆（会话级）：存在 Redis 或内存，key 是 session_id，value 是最近 N 轮对话（我一般存 10-20 轮），超时自动过期。作用是保证多轮对话连贯，比如用户说"帮我查订单"，下一句"那个订单能退吗"，Agent 得知道"那个订单"指的是什么。 长期记忆（用户级）：存在向量数据库，每个用户有一个 memory index，把重要信息（用户偏好、历史决策、关键结论）写成摘要存进去。每次对话开始前，先根据用户 ID 检索相关历史记忆，注入到 prompt 里。 区分原则：短期记忆解决"刚才说了什么"，长期记忆解决"这个用户是什么样的"。 实际落地时，我会让 Agent 在每次对话结束时自动提炼 1-3 条"值得长期记住"的信息，调用写入接口存长期记忆，不用人工标注。
【面试题】8. 你用 LangChain 或 CrewAI 踩过什么坑？给新手三个避坑建议。
【标准答案】 踩过最大的坑是"链式调用嵌套太深，debug 到崩溃"——一个 Chain 调另一个 Chain，另一个 Chain 里还有 Agent，报错信息完全看不懂，不知道是哪层挂了。 三个避坑建议： 第一，别过度抽象。LangChain 的 LCEL（LangChain Expression Language）很爽，但别什么都写成链式。简单的顺序调用，直接写 Python 函数更清晰，出错了也好调。 第二，工具别太多。给 Agent 挂 20 个工具，它选择工具的准确性会大幅下降，而且 token 消耗爆炸。按场景拆分 Agent，每个 Agent 挂 5-8 个工具就够了。 第三，一定要加日志。每个工具调用、每轮模型交互，都要记录输入输出了什么。生产环境出问题，没有日志你就是瞎子。我一般用 LangSmith 或自己写个 decorator 打日志。
【面试题】9. 如果让你从 0 到 1 落地一个"内部知识库问答 Agent"，你会怎么规划？说清楚关键节点和风险评估。
【标准答案】 第一阶段（2 周）：MVP 验证。选 1 个部门（比如技术部），整理 50-100 篇文档，搭一个最简化 RAG 链路：文档切分 → embedding → 存入向量库 → 检索 → 大模型生成。目标是验证"技术上可行"，别追求完美。 第二阶段（4 周）：核心功能补齐。加权限控制（谁能看什么文档）、加引用标注（回答要标明来源）、加反馈机制（用户点赞/点踩，数据存下来）。同时开始做评估：用 50 个真实问题测准确率，定基线。 第三阶段（4 周）：规模化 + 上线。接入更多部门文档，做文档自动同步（检测更新自动重新 embedding），加监控（回答准确率、响应时间、用户满意度），培训用户使用。 关键风险：
- 文档质量差（格式混乱、内容过时）→ 上线前必须做文档清洗和人工审核；
- 用户期望过高（觉得 AI 什么都知道）→ 上线时要明确告知"当前覆盖的知识范围"；
- 成本失控（大量用户使用，API 费用爆炸）→ 加热门问题缓存，重复问题不重复调模型。
【面试题】10. 面试官最后问你："你觉得自己做 Agent 开发最大的优势是什么？" 你怎么答？
【标准答案】 我觉得是两个： 第一，我不迷信模型，更相信工程化。 很多人做 Agent 一味追求"更强大的模型""更复杂的提示词"，但我更关注"这个任务能不能用确定性的代码解决"。能写 if-else 的就不让模型做，能写工具的就不让模型自由发挥。这样一来，系统可控、可调试、成本低。 第二，我有真实的落地经验，知道哪里会出问题。 不是"跑通一个 Demo"就完事，而是真的处理过生产环境的并发、延迟、错误兜底、用户反馈闭环。我知道 RAG 的回答准确率从 60% 到 85% 需要做什么，知道多智能体协作时消息队列怎么设计，知道成本怎么控制——这些只有踩过坑才知道。 如果贵司需要的是一个能快速把 Agent 从 Demo 推到生产的人，我觉得我挺合适的。
本文件由 AI 面试题生成器自动生成，题目覆盖技术基础、架构设计、工具使用、项目落地、场景实操、面试情景问答等维度。