AI智能体应用开发面试题
生成时间：2026-06-12 02:25
【面试题】1. 大模型回复不稳定，同一个提示词每次结果不一样，怎么通过提示词工程让它输出更稳定？
【标准答案】核心是减少LLM的"自由度"。三个实战技巧：
第一，指定输出格式——用JSON Schema或XML标签把输出结构锁死，比如要求必须以"answer: "开头，或者限定只能返回固定枚举值。第二，Few-shot示例——给2-3个标准问答样例，让模型"照着抄"，比自己写格式约束靠谱得多。第三，温度参数配合——生产环境一般设0.3~0.5，既有一点创造性又不至于跑偏。如果还不行，就在应用层做输出校验+重试，不符合格式就再调一次。实际项目中我一般三个手段叠加用，格式类问题基本能控制在95%以上命中率。
【面试题】2. 多智能体协作时，任务分配策略有哪些？什么场景下用哪种？
【标准答案】常见三种分配策略：
静态分配——预先定义好每个Agent的角色和能力，按固定规则路由。比如客服场景，意图识别Agent分发到不同的处理Agent。这种简单粗暴，适合职责边界清晰的场景。
动态分配——Agent自己根据上下文判断"这件事该谁干"。比如用一个大模型当调度员，理解用户意图后动态调用子Agent。灵活性高但开销大，适合开放性任务。
层级协作——Supervisor管一群Worker，先并行发散再汇总收敛。比如CrewAI的Crew模式就是这种。适合复杂任务需要多角度分析的情况。
选型原则：场景封闭、流程固定用静态；任务开放、需要理解力用动态；任务复杂、环节多有依赖用层级。
【面试题】3. Dify和CrewAI分别适合什么团队？它们的核心差异是什么？
【标准答案】Dify偏团队协作和业务落地，CrewAI偏编程控制和灵活编排。
Dify是个完整的应用平台，有可视化编排、版本管理、API发布、运维监控，非技术也能上手。它适合要做产品化、把Agent快速部署给外部用户的企业团队。
CrewAI是个Python框架，代码驱动，用Pythonic的方式定义Agent、工具、任务流程。它适合有开发能力的团队，需要深度定制复杂逻辑，或者想把Agent能力嵌入自己现有系统。
核心差异：Dify是"拖拽建应用"，CrewAI是"代码写Agent"。我实际项目里习惯用Dify做POC验证和简单客服，用CrewAI/LangGraph做需要精细控制的复杂流程。
【面试题】4. 你们的Agent上线后怎么监控效果？发现效果不好怎么快速定位问题？
【标准答案】监控分三层：
一层是基础指标——QPS、响应延迟、错误率、Token消耗，这块用普通APM就能接。
二层是业务效果——任务完成率、人工介入率、用户满意度评分。这个需要埋点，我一般会在Agent返回结果后让用户打分或者记录是否触发了人工接管。
三层是case回溯——建立Bad Case库，按问题类型分类：幻觉型、格式型、逻辑型、能力不足型。
定位问题先从Bad Case库找规律，看是同一类错误反复出现还是随机偶发。常见根源就三个：提示词没覆盖这个case、工具返回结果有噪音、模型能力本身不够。这样定位到具体点再针对性优化，不用每次全量回归。
【面试题】5. RAG的召回阶段怎么优化召回质量？遇到过召回了一大堆但全是不相关的情况吗？
【标准答案】召回质量优化有六个常用手段：
切分策略——按语义块切，不要按固定长度。重叠10%~20%，既保留上下文又不引入太多噪音。我一般用unstructured库或者大模型来做语义切分。
向量化模型选型——用领域匹配的Embedding，比如做中文法律用Law-Chinese-BERT，做通用用BGE或Text2Vec，效果差很多。
混合检索——BM25+向量检索组合，两者取并集或者RRF融合，能互补纯向量检索的召回盲区。
元数据过滤——时间、类别、来源等条件先过滤再召回，大幅减少噪音。
重排序——用BGE-Reranker或者Cohere做二阶段排序，把最相关的结果顶到前面。
Query改写——用户问得模糊时，用大模型先改写query再召回，我自己叫"召回前置清洗"。
之前确实遇到过医疗问答场景下，纯向量检索召回了一堆症状描述但用户问的是治疗方案的问题。后来加了Query改写+混合检索+重排序三件套，Top3召回准确率从60%提到了90%。
【面试题】6. Agent的记忆系统怎么设计？短期记忆和长期记忆怎么配合？
【标准答案】我一般用三层记忆架构：
短期记忆——当前对话的上下文窗口，用滑窗或摘要保留最近N轮对话。Token超限时优先丢最老的。
中期记忆——Session级别的记忆，比如用户偏好、当前任务进度。每次会话结束做一次Summary存入。
长期记忆——向量数据库存历史对话摘要、关键决策、用户档案。检索时结合当前上下文召回相关历史。
配合逻辑：当前任务需要什么就查什么。比如用户说"继续上次那个项目"，就从长期记忆里召回上次的项目上下文注入进来；如果只是当前对话内的信息传递，走短期记忆就够了。
关键点：记忆要有过期机制，不能一直堆着。长期记忆也要定期精简，去掉过时的、合并重复的。
【面试题】7. 你们Agent从0到1开发一个真实业务场景，完整流程是什么？
【标准答案】五步走：
第一步：需求拆解——搞清楚这个Agent要解决什么问题、成功的标准是什么、有没有人工兜底方案。这是很多人忽略但最重要的步骤。
第二步：Demo验证——用最简单的方式验证技术可行性。Prompt+单次LLM调用，先跑通主流程，不考虑并发和边界情况。
第三步：链路完善——加工具调用、RAG检索、记忆系统，把完整闭环跑通。这个阶段开始考虑错误处理。
第四步：效果调优——Bad Case驱动优化，逐一解决幻觉、格式、逻辑问题。同时做性能压测。
第五步：上线监控——部署+埋点+监控+DY数据回流。这步不做，前面全白干。
我自己经验是第二步和第三步可以快速迭代，但第四步往往比预期时间长2-3倍，要给足时间。
【面试题】8. 假设用户问了一个你Agent能力边界外的问题，Agent应该怎么优雅地处理而不是乱回答？
【标准答案】三层兜底机制：
第一层：边界识别——在系统提示词里明确写出Agent能做什么、不能做什么，让模型自己知道"这个问题我不该答"。同时在应用层加一个轻量级的意图分类，提前判断是否在服务范围内。
第二层：礼貌拒答——如果判断超出范围，用标准话术回复："这个问题我暂时无法处理，建议您XXX/联系人工客服/换个问题试试。"不要编，不要装懂。
第三层：优雅导流——不只是拒绝，还要给出替代方案。比如"这个问题涉及实时数据，我可以帮你查询公开信息，你要试试吗？"把用户留在对话里。
核心原则：承认边界比胡编靠谱。用户能接受"我不知道"，接受不了"你瞎说"。
【面试题】9. 向量数据库你们用的什么？为什么选它？Milvus和Chroma各适合什么场景？
【标准答案】我们线上用Milvus，调研阶段用过Chroma。
选型逻辑看三个维度：数据规模、是否需要分布式、团队技术栈。
Chroma是轻量级的嵌入式向量数据库，部署零成本，API简单，适合数据量在百万级以内、不需要高可用的个人项目或者快速POC阶段。我们之前用它做Demo，两小时就能跑起来。
Milvus是生产级分布式向量数据库，支持十亿级向量、水平扩展、高可用。适合企业正式项目。我们现在生产环境用的就是Milvus集群。
实际选型建议：如果你是独立开发者或者团队小，先用Chroma快速验证；一旦要上量、要高可用，切换到Milvus或者Pinecone、Qdrant这些。
【面试题】10. 面试官问："你觉得AI Agent和传统软件最大的区别是什么？"你怎么回答？
【标准答案】核心区别在于不确定性来源不同。
传统软件是确定性系统——输入固定、逻辑固定、输出可预期。Bug是因为程序写错了，修掉就好。
AI Agent是概率系统——输入一样，输出可能每次不同。它不是"写错了"，而是"这次猜偏了"。所以传统的测试、debug思路不完全适用，要用统计思维做质量评估。
这个区别带来两个实际影响：
第一，开发范式变了——不是写if-else，而是写Prompt、设计工具、设计反馈循环。第二，质量保障变了——不能追求100%正确，要接受有错误率，然后设计兜底机制和人工介入方案。
我觉得理解这个区别，是从"用AI"进阶到"做AI产品"的关键认知。