工作知识库

Appearance

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

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

【面试题】1. 在生产环境中调用大模型API，你会从哪些维度做Token成本和性能的管控？请说具体手段。 ​

【标准答案】 四个维度： 第一，输入侧做截断和压缩。长上下文场景用文本摘要或向量检索替代全文传入，system prompt 抽成模板复用，避免每条请求都带大段重复指令。 第二，输出侧用 max_tokens 和 early_stopping 限制回复长度，防止模型"跑偏"浪费Token。 第三，缓存复用。OpenAI、Anthropic 都支持 prompt caching，相同前缀的请求第二次起费用打一折，把不变的 system prompt 和 few-shot 示例放缓存区。 第四，监控和降级。埋点统计每个功能的日均Token消耗，设告警；高峰期或预算超标时自动降级到小模型，或者走本地模型兜底。 最后补充一点，选模型时要算"单位智能的成本"，有时候 GPT-4o 贵但一次搞定，比用 3 次 GPT-4o-mini 还便宜。

【面试题】2. 你说你做过RAG项目，那怎么量化评估一个RAG系统的效果？只看回答质量够吗？ ​

【标准答案】 不够，要分模块评估，不能一锅端。 最实用的是三层的评估体系： 第一层，检索层。看召回率（Recall@K）和精确率，用标注好的"问题-相关文档"对来测，确保该召回的文档在前K条里。 第二层，生成层。用 BLEU、ROUGE 或者 LLM-as-Judge 评估最终答案和参考答案的对齐程度。 第三层，端到端。用 RAGAS 框架，它有四个核心指标：上下文精确度、上下文召回率、答案相关性、答案正确性，自动跑。 生产环境还要加业务指标：用户点赞率、追问率、人工介入率。 我之前做的客服机器人，每周跑一次 RAGAS 评估，哪个环节的得分掉了就针对性优化，比如召回率低就调 embedding 模型或者改 chunk 策略。

【面试题】3. LangChain的Chain和Agent有什么区别？各自适合什么场景，为什么不全用Agent？ ​

【标准答案】 核心区别是"是否动态决策"。 Chain 是固定流程，每一步干什么事先定好，适合确定性强、流程固定的任务，比如"先提取关键词，再查数据库，再生成回复"，用 Chain 就够了，执行快、可控、好调试。 Agent 是让模型自己决定下一步调用什么工具，有自主规划能力，适合开放域、步骤不固定的任务，比如"帮我分析这份合同有什么风险"，模型需要自己决定先看哪条、查哪个法规。 不全用 Agent 的原因有三个：第一，慢，每步都要调一次大模型；第二，不稳定，模型可能选错工具或者陷入循环；第三，成本高。所以我们的原则是：能 Chain 解决的就不用 Agent，Agent 只用在确实需要动态决策的地方。

【面试题】4. 你们做智能体记忆系统的时候，短期记忆和长期记忆分别是怎么设计的？各有什么坑？ ​

【标准答案】 短期记忆用滑动窗口 + 摘要压缩。把最近 N 轮对话全量保留，超出的部分用模型压缩成一段摘要，拼到 system prompt 里。坑是压缩会丢细节，所以对关键实体（比如用户提到的订单号）要做结构化提取，单独存，不被压缩掉。 长期记忆用向量数据库存储。把历史对话按主题分块，embedding 后存进去，每次新消息来了先检索相关记忆，拼到上下文里。坑有三个：一是检索不准，用户说"我上次问的那个问题"，没有明确的语义锚点，这时候要结合时间、关键词做混合检索；二是存储膨胀，要定期清理无效记忆；三是隐私，长期记忆可能涉及敏感信息，要有隔离和删除机制。 我们生产环境是两套并用：短期保证对话连贯，长期保证跨会话的知识连续性。

【面试题】5. 现在有一个需求：用户上传一张商品图片，智能体要识别图片内容、查询库存、生成营销文案，最后发到企微群。请说一下你会怎么设计这个多模态Agent的系统架构？ ​

【标准答案】 分四层设计： 第一层，接入层。用户上传图片，系统先调多模态模型（GPT-4o 或 Qwen-VL）做图片理解，输出结构化描述：商品名、类别、关键特征。 第二层，任务编排层。用工作流引擎（Dify 或自研）把流程串起来：识别 → 查库存（调内部API） → 生成文案（用识别结果+库存信息拼 prompt） → 发送到企微（调企微机器人API）。每个节点失败要有重试和兜底。 第三层，记忆层。把这次生成的内容存下来，下次同款商品来了可以直接复用或微调。 第四层，监控层。每个节点的耗时、成功率、Token消耗都要有埋点。 关键技术点：图片识别结果要做校验，防止幻觉；文案生成后要有人工审核环节才能发出去，不能全自动；企微API有频率限制，要加队列。

【面试题】6. 提示词工程里，Few-shot和CoT（思维链）分别解决什么问题？能不能一起用？什么场景下该用哪个？ ​

【标准答案】 Few-shot 解决的是"格式对齐"和"样例学习"的问题。你给几个输入输出对，模型就能模仿这个模式，特别适合有固定格式要求的任务，比如信息抽取、数据清洗、格式转换。 CoT 解决的是"复杂推理"的问题。让模型在输出答案之前先把思考步骤写出来，能显著提升数学、逻辑、多步推理的正确率。 能一起用，而且经常一起用。比如让模型做表格信息抽取，Few-shot 给格式样例，CoT 让模型先"读表 → 定位关键行 → 提取字段"再输出，效果最好。 选型原则：任务需要模仿格式 → Few-shot；任务需要逻辑推理 → CoT；两个都需要 → 叠加使用。我实际项目里，只要输出格式有要求，必加 Few-shot；只要任务步骤超过两步，必加 CoT。

【面试题】7. 智能体调工具的时候，如果工具返回错误或者超时，你们是怎么处理这个异常的？说一下完整的错误处理链路。 ​

【标准答案】 分三层处理： 第一层，重试。网络超时、临时服务不可用，用指数退避重试3次，每次间隔翻倍，大部分问题这层就解决了。 第二层，降级。重试还失败，就走降级逻辑。比如查库存的工具挂了，就返回"库存信息暂时无法获取，请您稍后重试"而不是报错给用户；如果有缓存数据，就用缓存兜底。 第三层，人工介入。降级也搞不定，就把这个请求打上异常标签，推到人工队列，同时给用户一个合理的解释和预计处理时间。 另外，每次工具调用都要有 trace_id 全链路追踪，出了问题能快速定位是模型选错参数、还是工具本身挂了、还是网络问题。 我们还有一个"错误模式学习"机制：把高频错误样本收集起来，微调 prompt 或者加校验逻辑，防止同类错误反复发生。

【面试题】8. 向量数据库的相似检索，为什么有时候明明相关的内容召回不上来？请从Chunk策略、Embedding模型、检索策略三个角度说一下优化思路。 ​

【标准答案】 这是RAG系统最核心的问题，三个角度： 第一，Chunk策略。块太大，噪声多，语义不集中；块太小，上下文断裂，模型理解不了。我们的经验是：通用文档 512 token、重叠 50-100 token；结构化文档（如API文档）按段落或小节切；代码按函数切。关键是让每个 chunk 语义完整、独立可理解。 第二，Embedding模型。中文场景用 BGE、M3E 比 OpenAI 的 text-embedding 效果好；领域垂直的场景（法律、医疗），要用领域数据微调 embedding 模型，不然语义空间不对。 第三，检索策略。别只用向量检索，要结合关键词检索（BM25）做混合检索，再用 RRF（倒数排名融合）打分，能大幅提升召回率。还可以用 query 改写，先把用户问题扩展成多个语义相似的问题，分别检索，合并结果。 我们之前做的法律问答，光换 embedding 模型就从 60% 召回率提到了 85%，再加混合检索到了 92%。

【面试题】9. 如果让你从0到1落地一个企业内部的"AI知识助手"，你会怎么规划这个项目？说一下关键节点和风险点。 ​

【标准答案】 分四个阶段： 第一阶段，MVP验证（2周）。选一个高频、低风险场景，比如"查公司制度文件"，用 Dify 快速搭一个 RAG 原型，找 10 个同事内测，验证价值。这阶段关键是别追求完美，能跑通流程就行。 第二阶段，核心功能开发（4周）。打通企业数据源（知识库、Confluence、内部Wiki），做权限隔离（不同部门看到的内容不一样），加对话记忆，优化回答质量。这阶段最大的坑是数据源质量，垃圾进垃圾出，要花大量时间做数据清洗。 第三阶段，集成上线（2周）。接入企业微信/钉钉，做用户反馈收集，加日志监控。这阶段要注意灰度发布，先给一个小团队用，没问题再全量。 第四阶段，迭代优化（持续）。根据用户反馈和数据分析，持续优化召回准确率、回答质量，逐步扩场景。 风险点：数据安全（不能把敏感信息喂给外部大模型）、用户预期管理（AI 不是万能的，要设边界）、成本控制（全员用起来 Token 费用可能很高，要提前算账）。

【面试题】10. 你觉得目前主流Agent框架（LangChain、CrewAI、Dify、AutoGPT）各自最适合什么场景？如果让你选技术栈，你的决策逻辑是什么？ ​

【标准答案】 先说各自定位：

  • LangChain：最适合需要高度定制化的场景，作为 Python 库深度集成到自己的系统里，灵活但上手成本高。
  • CrewAI：多智能体协作的首选，角色分工清晰，适合需要多个 Agent 各司其职完成复杂任务的场景，比如"调研 → 分析 → 报告"流水线。
  • Dify：低代码/可视化首选，适合快速交付、产品原型和业务人员也能参与配置的场景，工作流编排很直观。
  • AutoGPT：自主任务执行，给一个目标让它自己拆解执行，但生产环境稳定性差，更适合个人实验。

我的决策逻辑是"三层判断"： 第一层，要不要低代码？要 → Dify；不要 → 继续判断。 第二层，是不是多Agent协作？是 → CrewAI；不是 → 继续判断。 第三层，是不是深度定制、要嵌入自己系统？是 → LangChain；不是 → 看具体需求选。 实际项目里，我经常是混合用：Dify 做原型和简单场景，LangChain 做复杂定制开发，CrewAI 做多 Agent 协作。技术选型的核心原则是：用最合适的，不是用最潮的。

本文件由 AI智能体应用开发面试题生成器 自动生成如需更多题目或针对性练习，请告知