AI智能体应用开发面试题 - 2026-06-16
【面试题】1. 调用大模型API时，Token超限报错是最常见的生产问题之一。请描述你在实际项目中是如何处理超长上下文的，有哪些策略？
【标准答案】 我主要从三个层面处理： 第一，输入侧截断。在调用API前对输入做滑动窗口或摘要压缩，把超长历史对话提炼成关键信息再传入，避免无意义堆叠。 第二，分段处理。把长文档按语义切分，用RAG方式只检索相关片段，而不是全部塞进上下文。 第三，模型选型。上下文需求真的很大时，直接用支持长上下文的模型（如Claude 3系列、Gemini 1.5），而不是在短上下文模型上硬凑。 实际落地时，我会设计一个ContextManager模块，统一处理截断、压缩、优先级排序，这样换模型也不用改业务代码。
【面试题】2. 你说用过LangChain、CrewAI这些框架，如果让你从0到1设计一个多智能体协作系统来解决复杂任务（比如"帮我做竞品分析报告"），你会怎么拆解和架构？
【标准答案】 我会按"任务规划层 + 执行层 + 记忆层"三层来设计： 任务规划层：用一个Planner Agent把"竞品分析"拆成子任务——收集信息、提取关键指标、对比分析、生成报告，每个子任务分配给专门的Worker Agent。 执行层：每个Worker Agent有独立的工具集，比如搜索Agent装搜索工具、分析Agent装代码解释器，通过消息队列或共享状态传递中间结果。 记忆层：用向量数据库存各Agent的输出，下一个Agent可以直接检索前面Agent的结论，不用重复计算。 框架选型上，CrewAI更适合这种有明确角色的协作场景，比自己用LangChain手撸要快很多。关键是任务边界要清晰，不然Agent之间容易互相干扰。
【面试题】3. RAG系统是智能体项目里最容易出效果但也最容易踩坑的模块。请说说你在RAG落地过程中遇到过哪些实际问题，怎么解决的？
【标准答案】 最大的坑有三个： 第一，检索不准。一开始用默认embedding，专业领域效果很差。后来换了领域微调的embedding模型，又加了Hybrid Search（向量+关键词），命中率明显提升。 第二，上下文污染。检索回来的chunk太大，把无关内容也塞进去了，反而干扰生成。解决方法是做rerank，用交叉编码器对候选chunk重新打分，只取top3-5。 第三，知识更新滞后。静态向量库跟不上业务变化。我加了一个定时增量更新 pipeline，新文档进来自动切分、embedding、更新索引，不用手动重跑。 总结一句话：RAG不是装上就能用的，检索质量决定上限，工程细节决定下限。
【面试题】4. 智能体的"记忆系统"是区分玩具原型和生产级应用的关键。请对比短期记忆、长期记忆、工作记忆的设计思路，并说说你是怎么实现的？
【标准答案】 三类记忆解决的问题不一样： 短期记忆：就是当前会话的上下文，用滑动窗口管理，超出限额就压缩或丢弃早期对话。实现上直接用对话历史列表，配合Token计数器截断。 长期记忆：跨会话的用户偏好、历史决策，存在向量数据库里。每次新对话开始时，先根据用户ID检索相关历史记忆，注入到系统提示里。 工作记忆：当前任务执行过程中的中间状态，比如多步任务的进度、已完成的子目标。我用Redis或内存字典来存，任务结束就清理。 实际项目里，我会在Agent基类里统一封装get_memory()和save_memory()接口，不同记忆类型走不同存储后端，上层调用统一，好维护。
【面试题】5. 你现在要做一个"智能客服Agent"，业务方要求：能查订单、能退款、能回答产品问题，还要能转人工。请描述你的技术选型和系统架构。
【标准答案】 技术选型：Dify做编排层，因为它有可视化的工作流，业务方自己就能改流程，不用每次找我发版。 架构设计：
- 意图识别节点：用户输入进来，先用LLM判断意图（查订单/退款/问答/转人工），路由到不同分支。
- 工具调用节点：查订单接订单API，退款接退款API，都用Function Calling规范封装。
- 知识库节点：产品问答走RAG，把产品文档、FAQ向量化存进Qdrant。
- 转人工节点：检测到用户情绪负面或3次未解决，自动触发人工介入，同时把对话摘要传给客服系统，避免用户重复描述。 关键点：每个节点的输入输出都要有schema校验，不然一个节点挂了，整个链路就崩了。Dify的异常处理节点要用上。
【面试题】6. 提示词工程很多人觉得就是"写一段话"，你觉得进阶的提示词工程应该关注哪些点？能否举一个你实际优化过的案例？
【标准答案】 进阶提示词工程核心是解决稳定性和可控性问题，不只是效果好不好，而是能不能稳定复现。 我关注几个点： 第一，结构化输出。用JSON Schema或Pydantic模型约束输出格式，而不是靠自然语言描述"请输出JSON"，失败率高。 第二，Few-shot示例的质量。示例要覆盖边界情况，不能只给happy path。我一般会准备3-5个典型case，包括一个错误处理的示例。 第三，角色+约束分离。系统提示里，角色定义、任务描述、输出格式、禁止事项分开写，用Markdown标题隔开，修改时不容易互相影响。 实际案例：之前做一个合同审查Agent，最初提示词输出格式乱七八糟，后来改用结构化提示词模板+JSON输出约束+后校验解析，格式错误率从30%降到2%以下。
【面试题】7. 智能体调用外部工具时，如果工具执行失败（比如API超时、返回异常格式），你的Agent是怎么做错误处理的？请描述你的重试和降级策略。
【标准答案】 我设计了一个三层容错机制： 第一层：重试。工具调用失败时，不是立即放弃，而是做指数退避重试（1s、2s、4s），最多3次。很多临时性网络问题这样就能解决。 第二层：降级。重试都失败了，走降级逻辑。比如搜索工具挂了，就告诉用户"实时信息暂时不可用，我用已知知识回答"，而不是直接报错崩溃。 第三层：人工兜底。关键业务链路（比如退款操作），如果工具连续失败，触发告警+转人工，不能让用户卡死在系统里。 代码实现上，我用装饰器封装重试逻辑，每个工具注册时声明自己的重试策略和降级行为，框架统一调度，不用在每个工具里手写try-catch。
【面试题】8. 向量数据库选型是RAG项目的基础决策。请对比一下你用过的向量数据库（如Milvus、Qdrant、Chroma、Pinecone），在什么场景下你会选哪个？
【标准答案】 我的选型逻辑是先看部署方式，再看性能需求： Chroma：本地原型开发首选，pip install就能跑，适合快速验证。但生产环境功能不够，没有分布式支持。 Qdrant：我目前的主力选择。Rust实现性能好，支持Hybrid Search（向量+全文），过滤语法灵活，单机就能撑千万级向量，部署也简单（Docker一行启动）。 Milvus：数据量真的上亿、需要分布式弹缩的场景。功能最全，但运维复杂度高，小团队hold不住。 Pinecone：不想自己运维、预算足够的团队。全托管，开箱即用，但数据是存在人家的云上，有合规风险。 总结：原型用Chroma，生产用Qdrant，超大规模才上Milvus，有合规要求别用全托管的。
【面试题】9. 面试场景：如果模型回复质量不稳定，有时候好有时候差，业务方投诉，你怎么排查和解决？
【标准答案】 这个问题我分四步排查： 第一步：确认是不是Prompt的问题。把最近效果差的case拿出来，看输入有什么共性（比如输入特别长、包含特殊字符、问题模糊），然后针对性优化提示词，加输入校验和标准化预处理。 第二步：检查模型参数。Temperature设太高会导致输出随机性强，生产环境我一般设0.1-0.3；Top-P也可以适当收紧。 第三步：看是不是知识库的问题。RAG场景下，检索质量直接影响生成质量。我会手动跑一遍bad case的检索，看召回的chunk是不是相关的，不行就调检索策略。 第四步：加输出校验。生成结果出来后，用规则或另一个小模型做质量打分，低于阈值就重新生成或走人工审核。 核心思路：先定位问题在哪个环节（输入/模型/知识库/输出），再针对性解决，不要盲目调提示词。
【面试题】10. 你如何评估一个智能体系统的"智能程度"和"可用性"？有哪些指标是你在项目中实际跟踪的？
【标准答案】 我分效果指标和工程指标两类来跟踪： 效果指标：
- 任务完成率：用户发起的任务，有多少比例被Agent独立完成了（不需要人工介入）
- 工具调用准确率：该调用工具时有没有调用、调用参数对不对，这个直接影响任务能不能完成
- 回答事实准确性：RAG场景下，答案是否基于检索内容、有没有幻觉，这个需要人工抽样或LLM-as-Judge 工程指标：
- P95延迟：用户感知最明显的指标，我一般要求端到端<3s
- 工具调用失败率：反映外部依赖的稳定性
- Token消耗/请求：直接影响成本，要有告警 实际落地时，我会搭一个简易的评估框架：用历史对话数据做回归测试，每次改提示词或换模型，跑一遍历史case，看核心指标是升还是降，避免"觉得改好了"但实则退步的情况。
生成时间：2026-06-16题目数量：10道覆盖方向：技术基础 / 架构设计 / 工具使用 / 项目落地 / 场景实操 / 面试情景