AI智能体应用开发面试题 - 2026-06-15 23:10
【面试题】1. LangChain中的Agent和Chain核心区别是什么？什么场景该用Agent而不是Chain？
【标准答案】Chain是确定性执行路径，输入→处理→输出，流程写死。Agent是大模型自己决定下一步调什么工具、走哪条路，是动态决策。简单说：流程能画流程图的用Chain，流程需要根据中间结果动态选择的用Agent。比如固定步骤的数据清洗管道用Chain；但用户提问可能需要查数据库、可能需要搜网页、也可能直接回答的，这种就得Agent。实际项目中，很多场景是混合的——主干用Chain，关键分支用Agent做路由决策。
【面试题】2. RAG系统中检索召回率低怎么优化？请从链路角度分析。
【标准答案】RAG召回率低要分段排查：第一，分块策略——chunk太大信息稀释，太小丢失上下文，实践中500-1000 token带50-100 overlap是比较常见的起点，语义分块比固定长度效果好；第二，Embedding模型——中文场景别用英文模型硬套，bge-large-zh、m3e这些中文专用模型效果明显好；第三，检索方式——纯向量检索对精确关键词匹配弱，加BM25混合检索能补上这块，用RRF或倒 数排名融合做rerank；第四，查询改写——用户原始query可能表达不清，让LLM先改写或分解成子查询再检索。这四步挨个排查，基本能定位问题。
【面试题】3. 多智能体协作中，怎么避免Agent之间陷入死循环或者互相推诿？
【标准答案】这是多Agent落地的经典坑。核心解法三层：第一，角色边界要清晰——每个Agent的职责、能调什么工具、输出什么格式，全在system prompt里写死，别让两个Agent觉得"这事该对方干"；第二，加全局协调器——不管是CrewAI的Manager模式还是自定义一个Router Agent，得有人拍板谁干活、谁审批，不能全员平权；第三，死循环防护——设最大轮次上限，比如对话超过10轮还没结果就强制终止并上报。实际经验是：超过3个Agent协作，几乎必须上协调器，否则维护成本爆炸。
【面试题】4. 工具调用（Function Calling）的schema设计有哪些实战经验？踩过什么坑？
【标准答案】几个关键经验：第一，参数要少且明确——一个工具超过5个参数，LLM调用出错率直线上升，能拆就拆成多个小工具；第二，description要写人话加示例——别只写"日期字符串"，写"日期字符串，格式YYYY-MM-DD，如2024-01-15"，LLM靠这个理解参数语义；第三，枚举值优于自由文本——状态、类型这种字段，用enum限制取值范围，减少幻觉；第四，必填和选填要标清——LLM经常偷懒不填可选参数，关键参数必须required。踩过的坑：返回结果格式不一致导致下游解析失败，所以工具返回值一定要schema化，别返回裸字符串。
【面试题】5. Dify和LangChain分别适合什么项目？怎么选型？
【标准答案】核心看团队和场景。Dify适合业务驱动的团队——产品经理能直接在可视化界面编排工作流、调试prompt，不需要写代码，快速出活，适合内部工具、客服、知识库这类标准化场景。LangChain适合技术驱动的团队——需要深度定制Agent逻辑、自己写工具、控制每一步执行细节，代码灵活度拉满。简单说：要快、要可视化、团队技术弱→Dify；要深度定制、有工程能力→LangChain。混合方案也常见：用Dify做原型验证，验证通过后用LangChain重写生产版。千万别反过来，拿LangChain做原型太慢了。
【面试题】6. 智能体的记忆系统怎么设计？短期记忆和长期记忆分别怎么实现？
【标准答案】短期记忆就是当前对话上下文，放对话历史里，但要注意token管理——超出窗口就要做截断或摘要，不能无脑全塞。长期记忆分两类：一是语义记忆，就是用户偏好、知识事实，存向量数据库，按相似度召回；二是情景记忆，就是历史交互记录，按时间索引，可以用传统数据库存。实际落地方案：短期用对话窗口+滑动摘要；长期用Milvus/Chroma做语义存储，Redis做热数据缓存。关键点是要有遗忘机制——不是所有对话都值得记住，用重要度评分过滤，只存真正有用的，否则记忆库会变成垃圾堆。
【面试题】7. Agent线上出错了怎么处理？讲讲你的错误处理和重试策略。
【标准答案】分三层：第一，工具调用失败——网络超时、API限流这种，用指数退避重试，最多3次，超过就降级处理，比如搜索工具挂了就回退到内置知识回答并标注"信息可能不是最新"；第二，LLM输出异常——格式不对、调了不存在的工具，做输出校验+自修复，把错误信息喂回LLM让它重新生成，最多修2次；第三，整体流程异常——设全局超时和兜底回复，不能让用户一直等。关键原则：对外永远有回复，对内错误全记录。所有异常都要打日志+监控告警，不能静默失败。实际项目中80%的线上问题都是工具调用层出的，这层防护最值得投入。
【面试题】8. 向量数据库选型，Milvus、Chroma、Pinecone怎么选？考虑哪些因素？
【标准答案】四个维度：数据规模、部署方式、性能需求、成本。Milvus——分布式架构，十亿级数据没问题，但部署重，需要集群，适合大规模生产环境，自建成本低但运维成本高。Chroma——轻量嵌入式，百万级以下够用，pip install就能跑，适合原型和小规模应用，但高并发撑不住。Pinecone——全托管，零运维，性能稳定，但按查询量收费，数据量大时成本高，还有数据出境合规问题。我的建议：原型阶段用Chroma快速验证；上生产看规模——百万级以内且不想运维就用Pinecone，数据敏感或大规模就Milvus自建。别在原型阶段就上Milvus，过度工程。
【面试题】9. 从0到1做一个企业知识库问答Agent，你会怎么规划？关键节点是什么？
【标准答案】分五步走：第一步需求澄清——覆盖哪些文档？用户是谁？准确率要求多高？延迟预算多少？这些不澄清后面全白做。第二步数据准备——文档采集、清洗、分块，这块工作量占60%，格式不统一的PDF、扫描件、表格都是坑，提前评估。第三步技术选型——Embedding模型+向量库+LLM，中文场景bge+zilliz+国产大模型是性价比组合。第四步MVP验证——先拿100篇文档上线内部测试，看准确率和召回率，RAG效果不行就调分块策略和检索策略，别急着扩量。第五步迭代优化——加rerank、加query改写、加用户反馈闭环。关键节点是第四步MVP验证，很多人跳过这步直接全量上线，结果效果差推翻重来。
【面试题】10. 面试官问：你们项目里Agent的实际效果怎么样？有哪些指标？你怎么回答？
【标准答案】我这样回答：我们主要看三类指标。第一，任务完成率——用户意图是否被正确满足，我们人工抽样标注，目标85%以上。第二，工具调用成功率——Agent调工具是否选对了、参数是否正确，这个可以自动化统计，我们做到了92%。第三，端到端延迟——用户发问到得到回复的总时长，P95控制在8秒以内，其中LLM推理5秒、工具调用2秒、检索1秒。另外还有两个业务指标：用户采纳率（回答被复制或点赞的比例）和自主解决率（不需要转人工的比例）。这些指标不是一上来就全有的，我们是先有任务完成率，再逐步加其他维度。说实话早期数据不好看，迭代了三轮才达标。