AI智能体应用开发 · 面试题 · 2026-06-13
【面试题】1. 你在提示词里用过哪些控制模型输出的技巧？举一个你实际调过的例子
【标准答案】
我常用的就三个：结构化输出、温度控制、分段指令。
结构化输出最有效——让模型直接返回 JSON，比让它自由说再解析靠谱得多。我之前做过客服机器人，用 system prompt 约束角色 + 举例 few-shot，准确率从 65% 提到 82%。温度设 0.3 到 0.5 之间，太高了胡说八道，太低了机械感强。分段指令是把复杂任务拆成「先做什么再做什么」，加个「如果没找到就返回空」这样的兜底。
最核心的一点：prompt 不是写一次就完事的，是要上线后根据真实 bad case 反复改的。
【面试题】2. 怎么理解单智能体和多智能体的区别？什么场景下你会选多智能体？
【标准答案】
单智能体就是一个 Agent 自己调用工具、规划、执行，适合流程固定、边界清晰的任务，比如一个客服机器人。
多智能体是多个角色各司其职，通过消息协作，适合复杂任务。我选多智能体的判断标准就一个：当一个任务的子任务需要不同领域的专业知识或不同角色判断时，就用多智能体。
比如做一个投研报告生成系统，我可以拆成：数据采集 Agent负责爬虫和API，数据分析 Agent负责计算指标，报告撰写 Agent负责生成内容，审核 Agent负责质量检查。每个 Agent 专注自己那一块，通过共享消息或共享状态协作。
多智能体的代价是复杂度高、调试难，所以能用单智能体解决的，坚决不加架构。
【面试题】3. LangChain 的 Agent 和 Tool 是怎么配合工作的？手写过自定义 Tool 吗？
【标准答案】
核心流程是：Agent 负责决策「要不要调用工具 + 调用哪个」，Tool 负责执行具体操作并返回结果。
拿 LangChain 的 conversational-reasoning-agent 来说，它先把用户问题转成 action，然后从 Tool 列表里选一个执行，执行结果再塞回上下文，Agent 继续判断。
我手写过自定义 Tool，主要是继承 BaseTool 类，实现 _run 方法就行。最常见的是把内部 API 封装成 Tool，比如查内部数据库、调内部推荐系统。关键点是你要给 Tool 写清楚 name 和 description，因为 Agent 是靠 description 来决定用哪个 Tool 的——description 写不清楚，Agent 就会选错工具。
【面试题】4. RAG 系统的召回率低，你一般怎么排查和优化？
【标准答案】
排查思路分三层：查询层 → 索引层 → 召回层。
查询层先看用户问题转成向量的时候语义对不对。中文场景常见问题是分词不准，比如「周杰伦」可能被切成「周杰」「伦」，这时候我会用「查询改写」或者加同义词扩展。
索引层看 chunk 切分合不合理。chunk 太大容易引入噪声，太小丢失上下文。我一般用 500 到 800 字、50% overlap 的策略先跑，再根据效果调。
召回层看向量模型和检索策略。向量模型有没有用领域数据微调过？有没有用 hybrid search（向量 + 关键词）结合？有没有加 rerank 阶段？
我之前做过一个内部知识库 RAG，原来召回率 55%，加了 query expansion + hybrid search + rerank 后提到 78%。核心经验是：没有一招鲜，多种策略叠加才有效。
【面试题】5. Dify 和 CrewAI 你用过哪个？讲讲你用它解决过的一个实际问题
【标准答案】
两个都用过，我主要用 Dify 做低代码编排快速验证想法，用 CrewAI 写更灵活的多智能体逻辑。
拿 Dify 来说，我用它做过一个合同审查助手。工作流是：用户上传 PDF → Dify 内置的 OCR 提取文字 → 调用大模型逐条审查条款 → 输出审查意见和风险等级。整个流程不用写代码，半天搭完原型，给业务方演示完就直接推进开发了。
CrewAI 我用来写过一个多智能体爬虫系统：有一个总调度 Agent 负责拆解任务、分发给采集 Agent 和解析 Agent，最后汇总结果。这个比 Dify 灵活，但需要写 Python 代码。
选哪个取决于场景：想快就用 Dify，想灵活就用 CrewAI，纯研究或者需要深度定制的多智能体逻辑，我会直接基于 LangChain 原生写。
【面试题】6. 智能体的记忆系统是怎么设计的？短期和长期记忆分别怎么处理？
【标准答案】
我把记忆分成三层：上下文窗口记忆 → 短期记忆 → 长期记忆。
上下文窗口记忆就是这次对话的 history，让模型知道聊到哪了，这层最简单，LangChain 的 ChatMessageHistory 直接就能用。
短期记忆是「跨会话但属于同一个任务」的信息。比如用户说「继续刚才那个分析」，我需要记住上一轮的分析结果和上下文。实现方式是把最近的对话摘要或者关键中间结果存到 Redis 或者文件里。
长期记忆是「跨会话跨任务」的知识积累。我一般用向量数据库存，检索时用相似度召回最相关的记忆片段。关键问题是记忆该存什么：不是所有对话都存，我只存决策点、用户偏好、业务关键结论。
还有一个坑——记忆不是越多越好的，加太多不相关记忆会稀释检索质量，所以要定期清理和压缩。
【面试题】7. 多模态大模型做 Agent 感知，你踩过什么坑？怎么处理的？
【标准答案】
踩过两个大坑。
第一个是图片转文字丢失关键信息。有一次做视觉巡检系统，LLM 看 OCR 后的文字描述漏掉了缺陷，但直接看图是能发现的。后来改用 GPT-4V 直接做视觉判断，不走 OCR 这条路了。
第二个是多模态输入的 token 成本爆炸。给 Agent 传一整套产品图片，每张 1MB，一轮对话下来 token 费用吓人。解决方案是加一个预筛层：先用一个小的视觉模型做初步判断，只有触发疑似问题的图片才传给人模型处理。
还有一个通用建议：多模态的输入要控制尺寸和质量。传截图而不是整张页面图，压缩到合理分辨率，能省不少成本同时不影响判断准确率。
【面试题】8. 如果让你从零搭一个 AI 客服，你会怎么设计技术架构？
【标准答案】
三层架构：接入层 → Agent 层 → 知识层。
接入层负责用户消息的统一接入，微信、网页、API 都走这里，做一个适配器做格式统一。
Agent 层是核心，用单智能体起步。流程是：意图识别 → 路由判断 → 专业问答 or 通用对话 → 回复生成。意图识别我一般用规则 + 小模型轻量识别就够了，不一定非要上大模型。专业问答走 RAG，知识库里找不到答案才走通用大模型，这样成本和幻觉都可控。
知识层就是 FAQ 向量库 + 文档 RAG。这层的质量直接决定客服体验，我会重点维护知识库的更新机制，上线后持续收集 bad case 补充知识。
部署上用 Docker，Agent 服务和知识库服务分开，独立扩缩容。监控指标盯住：意图识别准确率、首次解决率、用户满意度。
【面试题】9. 智能体任务拆解后执行出错了，你一般怎么处理错误和异常？
【标准答案】
错误处理分三层：重试 → 降级 → 人工兜底。
大部分错误是网络超时或者模型偶发输出格式异常，这类我直接设计 2 到 3 次重试，加指数退避。
重试解决不了的，进降级策略。比如 RAG 召回失败了，降级到纯大模型用自己的知识回答；某个 Tool 调用失败了，看有没有替代工具，没有就跳过这个步骤继续。
最后兜底是人工介入。连续重试失败超过阈值，自动标记任务为「需要人工处理」，同时记录完整的错误日志，方便排查。
还有一点很重要：错误日志要记清楚是哪个 step 失败的、输入是什么、输出是什么，不然线上出问题根本没法复现。
【面试题】10. 你怎么评估一个 AI Agent 项目上线后的效果？有哪些关键指标？
【标准答案】
分两层：业务指标和技术指标。
业务指标是最终要看的：任务完成率、用户满意度、首次解决率（不用转人工就解决问题的比例）、平均处理时长。这些指标直接反映 Agent 是不是真的帮到业务了。
技术指标是支撑业务指标的：意图识别准确率、Tool 调用成功率、RAG 召回率、大模型响应延迟、错误重试率。技术指标出问题，业务指标一定好不了。
数据采集这块，我一般会在关键节点埋点：用户提问、意图识别结果、调用的 Tool、最终回复。日志进了数据仓库后，跑定期的 bad case 分析，驱动知识库和 prompt 的迭代。
核心逻辑就是：用业务指标定方向，用技术指标定位问题，用 bad case 分析驱动优化。