AI智能体应用开发面试题 - 2026-06-15-214000
【面试题】1. 你在用LangChain做RAG的时候，chunk_size和chunk_overlap是怎么选的？有什么调优经验？
【标准答案】这个问题我实战中踩过坑。chunk_size不是越大越好，也不是越小越好，关键看你的业务场景。文档是技术文档、API文档这种结构化强的，我一般用512-1024；如果是问答对、FAQ这种短文本，256就够了。overlap通常设chunk_size的10%-20%，目的是保证语义不要被硬切割。调优方法很简单：拿10-20个典型query跑一遍，看检索recall，换几组参数对比。我还会用Ragas框架自动评估retrieval相关的指标（context_precision、context_recall），比人工判断高效很多。另外有个细节，分块前先按段落、标题做语义分割，比纯按token数切效果明显好。
【面试题】2. 多智能体协作时，Agent之间怎么通信？你实际用过哪种模式？有什么优劣？
【标准答案】我主要用过两种模式。第一种是"编排式"，像CrewAI或者LangGraph里定义一个Manager Agent来调度其他Agent，Agent之间不直接对话，都通过Manager中转。好处是流程可控、好调试，适合任务边界清晰的场景，比如"研究→写作→审校"这种流水线。第二种是"对等式"，Agent之间可以互相发消息、协商，像AutoGen的GroupChat模式。好处是灵活，适合需要讨论和迭代的创意类任务，但缺点是容易跑偏、token消耗大、不好调试。实际项目中我更倾向编排式，因为生产环境可控性比灵活性更重要。对等式我一般用在内部探索阶段，验证思路后再改成编排式上线。
【面试题】3. 智能体在调用工具时，大模型生成了错误的工具参数（比如传了个不存在的ID），你怎么处理？
【标准答案】这是一个很常见的问题，我的策略分三层。第一层是前置校验，在工具执行前用JSON Schema或Pydantic模型做参数校验，类型不对、必填缺失、枚举值越界这些直接拦截，返回明确的错误描述让大模型重试。第二层是工具内部防御，工具函数本身做好异常捕获，不信任上游传来的任何参数。第三层是调用层重试机制，把错误信息格式化后喂回大模型，让它修正参数再调用，我一般设最多2次重试，超过就直接降级返回兜底响应。关键是错误信息要写清楚——不能只返回"参数错误"，要告诉模型"参数user_id格式应为UUID，你传的是纯数字"，这样大模型才能有效修正。
【面试题】4. 你用Dify做过项目吗？说说它和LangChain对比的优缺点，什么场景选Dify？
【标准答案】用过。Dify最大的优势是低代码可视化编排，业务人员也能参与调试prompt和工作流，上线速度快。它的知识库管理、API发布这些都开箱即用，不用自己搭。缺点是灵活性有限，复杂逻辑比如自定义的分支策略、动态工具选择这些，在Dify里实现起来比较绕，有时候还不如直接写代码。我的选择标准是：如果需求明确、流程固定、团队需要快速迭代，选Dify；如果需要复杂的自定义逻辑、多Agent深度集成、需要精细控制每个环节，选LangChain/LangGraph。另外Dify适合做MVP快速验证，验证通过后再用代码重构也行。
【面试题】5. 你怎么给智能体做"权限控制"？比如防止它越权删除数据、访问不该访问的接口？
【标准答案】核心思路是"最小权限+白名单"。具体做法：第一，每个Agent分配独立的API Key，只授权它职责范围内需要的接口，读数据的Agent不给写权限。第二，工具层做权限声明，每个工具注册时标注所需权限级别，Agent调用时做鉴权拦截。第三，高危操作（删除、支付、发送消息）强制加人工确认环节，不交给Agent自主执行。第四，所有Agent操作留审计日志，方便事后追溯。我在项目里还会做一个"意图审查"层，在工具调用前先让一个小模型快速判断这个调用是否合理，不合理就直接拦截。安全这块宁可多一层，不能少。
【面试题】6. 你做过多模态智能体吗？比如同时处理图片和文本的Agent，架构怎么设计？
【标准答案】做过一个商品信息提取的场景，用户上传商品图片，Agent需要识别图片内容、提取关键信息、再生成商品描述。架构分三层：第一层是多模态理解层，用GPT-4o或者Qwen-VL这类原生多模态模型直接处理图片+文本输入，不需要单独做OCR。第二层是信息结构化层，用Structured Output让模型返回JSON格式的商品属性。第三层是业务处理层，根据结构化数据做后续的价格比对、描述生成等。关键经验：不要试图把多模态和后续处理放在一个prompt里，分开做更容易调试，也更稳定。另外图片预处理很重要，分辨率太高token消耗爆炸，我会先压缩到合理尺寸再传给模型。
【面试题】7. 智能体的上下文越来越长，token超限了怎么处理？你有什么实际方案？
【标准答案】这个是生产环境必须解决的问题。我的方案按优先级排：第一优先是用模型自带的长上下文（128K甚至1M），成本允许的话这是最简单的。第二是做上下文压缩，把历史对话用小模型做摘要，只保留摘要+最近几轮完整对话。第三是滑动窗口策略，设一个token预算上限，超了就按策略丢弃最早的内容，但关键信息（比如用户偏好、任务状态）要持久化到外部存储，不能丢。第四是RAG化处理，把历史对话存入向量数据库，需要时检索相关片段注入上下文。实际项目里我一般组合使用——短期滑动窗口+长期RAG检索，效果最稳定。
【面试题】8. 你怎么设计一个智能体的"工作流编排"？从需求到上线，说你的流程。
【标准答案】我的流程分四步。第一步是画流程图，用Mermaid或者白板把业务流程画出来，明确每个节点的输入输出、决策分支、异常路径。这一步一定要和业务方一起确认，很多时候需求不清是后续返工的最大原因。第二步是选型，简单线性流程用LangChain的LCEL或者Dify的Workflow，有复杂分支和循环的用LangGraph，因为它的状态机和图执行引擎更适合。第三步是分节点开发调试，每个节点单独测试，确保输入输出符合预期。第四步是集成测试，重点测边界情况：API超时、模型返回格式异常、空结果、并发冲突。上线后我会接监控，看每个节点的成功率、耗时、token消耗，有异常自动告警。
【面试题】9. 你遇到过智能体的"死循环"问题吗？比如Agent反复调用同一个工具出不来，怎么解决？
【标准答案】遇到过，特别是在ReAct循环里，Agent选错了工具、参数填不对、或者模型陷入重复模式，就会一直循环。我的解决方案：第一，设最大循环次数，一般3-5次，超过强制终止并返回兜底响应。第二，检测重复模式，如果连续两次调用同一个工具且参数相同，说明卡住了，直接跳出循环。第三，在prompt里明确告知模型"如果某个工具调用失败2次，请换一个思路或直接告知用户无法完成"。第四，加一个超时机制，整个Agent执行超过一定时间（比如30秒）就中断。第五，关键是在日志里记录完整的工具调用链，这样出了问题能快速定位是卡在哪个环节、什么原因。
【面试题】10. 面试场景：产品经理说"我们想把现有的搜索功能升级成AI智能体搜索"，你会怎么评估可行性和推进？
【标准答案】我会从三个维度评估。技术维度：现有搜索的数据源是什么格式、数据量多大、实时性要求如何，这决定了RAG方案的复杂度。如果数据结构化好、量不大，几周就能出MVP；如果是多源异构数据、还需要实时更新，周期就要拉长。价值维度：现有搜索的用户痛点是什么？是搜不到、搜不准、还是搜到了但不会用？AI能解决的是"理解意图+整合信息"，如果核心问题是数据不全，那AI也帮不了太多。风险维度：AI搜索有幻觉风险，需要明确哪些场景可以容忍不准确、哪些必须100%准确，后者要做事实核查机制。评估完我会先做2周的POC，用真实用户query测试效果，用数据说话再决定是否全面铺开。不会一上来就承诺"AI能解决一切"。