AI智能体应用开发面试题（2026-06-16）
【面试题】1. Tool Calling 在生产环境中如果调用失败，你一般怎么设计重试和降级策略？
【标准答案】分层处理。第一层是即时重试，用指数退避，比如请求失败后等 1 秒、2 秒、4 秒再试，最多 3 次，适用于网络抖动这类临时故障。第二层是降级兜底——比如调天气预报 API 失败了，可以切到备用数据源，或者直接返回"暂时无法获取天气，请稍后再试"，而不是让整个 Agent 流程挂掉。第三层是熔断降级，如果某个工具持续失败超过阈值（比如 5 分钟内失败率 > 50%），暂时把它摘掉，等系统恢复再启用。核心思想是把工具调用当成网络请求来治理，失败是常态，不能让单点故障拖垮整个 Agent。
【面试题】2. 多智能体协作时，怎么避免"信息瀑布"和"责任扩散"问题？
【标准答案】两个核心原则：明确的角色边界 + 结构化的信息传递。角色边界方面，每个 Agent 只干一件事，比如拆解 Agent 负责规划，执行 Agent 负责干活，审核 Agent 负责兜底，不能让一个 Agent 既拆解又执行又核对。信息传递方面，用模板化的输出格式，比如固定输出"结论 + 依据 + 置信度"，让下游 Agent 拿到的是结构化结果而不是自由文本猜测。另一个实操技巧是引入仲裁 Agent，所有 Agent 的输出汇总到这里做最终决策，避免各自为战。这样拆解清晰之后，信息瀑布和责任扩散基本都能控制住。
【面试题】3. Dify 和 LangChain 各自适合什么场景？如果让你选型，你依据什么判断？
【标准答案】一句话：Dify 适合跑通业务，LangChain 适合深度定制。Dify 有可视化画布，流程编排、API 暴露、插件管理点点鼠标就能搞定，适合快速上线 B2B 对外的 AI 应用，团队里没有专门算法也能维护。LangChain 灵活度更高，可以精细控制 Agent 的推理链路、记忆模块、工具调用逻辑，适合做复杂的多步骤推理系统，或者需要在向量数据库、LLM 调用层做深度性能优化的场景。选型判断三个维度：团队有没有 Python 能力、项目要快速交付还是长期深度定制、上线后复杂度会不会指数增长。实际项目里经常是两者结合——Dify 搭框架，LangChain 做核心 Agent 逻辑。
【面试题】4. RAG 系统里，怎么判断是检索层的问题还是生成层的问题？
【标准答案】先做隔离实验。最简单的方法是：把检索出来的内容单独拿出来，直接丢给 LLM 生成答案，看结果好不好。如果检索内容本身就差——比如问"小米2024年Q3财报"，检索出来的都是些噪音或者无关文档，那问题在检索；如果检索出来的内容质量很好，但生成回答还是错的，那就是生成层的问题——可能 prompt 写的有问题，或者模型本身对这块知识不熟。实操上还会在检索层加一个"相关性打分"，低于 0.5 分的直接过滤掉，避免垃圾进垃圾出。生成层常见的坑是 prompt 里没有强调"只基于检索内容回答"，模型会幻觉填充，这个一定要约束住。
【面试题】5. 你的 Agent 项目上线后，怎么监控它的表现？有具体的指标吗？
【标准答案】核心三个维度：效率、质量、安全。效率指标包括平均响应时间、首次 token 延迟、工具调用成功率、每个任务消耗的 token 数量。质量指标有任务完成率（Agent 给出的结果到底能不能用）、用户满意度评分、错误类型分布（比如是工具调用错还是规划步骤错）。安全指标是内容安全、幻觉率、数据泄露风险。实操上会建一个Agent 可观测性面板，用 LangSmith 或者自己搭，把每次 Agent 执行链路（规划→工具调用→生成）都打点记录。超过阈值自动告警，比如某类错误率突然从 5% 跳到 20%，就要立刻排查。还有个容易被忽略的是"退化检测"——模型版本没变，但效果悄悄变差了，要能发现这种隐式退化。
【面试题】6. 你接了一个需求，需要 AI Agent 直接帮用户操作线上数据库（增删改），你怎么做安全防护？
【标准答案】三层防护。第一层是输入校验和意图识别——用户说"把用户表里所有数据删了"，直接拒绝；说"查一下用户张三的订单"，才允许 SELECT。禁止任何未经审核的 DDL 和 DML 操作。第二层是工具粒度的权限控制——数据库工具只能执行预置的、审核过的 SQL 模板，不允许自由拼 SQL。比如只能"按用户ID查订单"，不能"SELECT * FROM任意表"。第三层是执行前复核——高风险操作（比如涉及金额、隐私数据）走人工确认流程，或者限制单次影响行数，DELETE 操作超过 100 行直接熔断。核心原则是：永远不要让 LLM 裸连线上数据库，中间必须有一层策略引擎做守卫。
【面试题】7. 现在你要让 Agent 处理一个 10 万字的长文档，问你怎么做上下文压缩和关键信息提取？
【标准答案】两条路。第一条是滑动窗口 + 语义切分，不要按固定字符数切，要按语义段落切，比如按章节、标题结构来划分，每段保留摘要向量，检索时先定位相关段落再精细读取。第二条是LLM 驱动的摘要蒸馏——把长文档分段喂给 LLM，每段生成摘要和关键事实，用这些压缩后的内容做 Agent 的工作内存，而不是塞原始文本。还有一个技巧是层次化索引：先建章节级别的向量索引，定位到某章后再建段落级别的索引，两阶段检索又快又准。生产环境里 10 万字文档一般不会全部丢给 LLM，太贵太慢，上述方法能压缩到原来的 10%-20%，同时保留核心信息。
【面试题】8. 如果让你设计一个能主动发现并修复自身错误的 Agent，你打算怎么做？
【标准答案】核心是"验证-反思-修正"循环。验证层：Agent 输出结果后，不是直接返回，而是有一个独立的校验 Agent 扫描结果，检查逻辑是否自洽、是否符合用户意图，如果发现矛盾点就标记"可疑"。反思层：发现问题后，Agent 重新分析问题定义，回溯自己之前的推理步骤，找到第一个出错的地方。修正层：根据反思结果重新执行，并再次验证。具体实现上常用 ReAct 模式，把工具调用和推理交替进行，每一步都留有"置信度"标记，高置信度继续，低置信度触发回退逻辑。还有一个技巧是结果交叉验证——同一个任务让两个独立的 Agent 用不同方式做一遍，对比结果一致性，不一致的地方重点审查。这个机制能让 Agent 在生产环境里少出低级错误，尤其是数值计算和事实性判断类任务。
【面试题】9. 面试官问：你觉得你做的 Agent 项目和开源的 AutoGPT 这种通用框架比，优势在哪？
【标准答案】优势有两个层面：垂直场景的深度优化 和 可控性。AutoGPT 这类通用框架追求的是能用，但为了通用性牺牲了效率——它会频繁调用 LLM 做规划，一个简单任务可能触发几十次 API 调用，成本和延迟都不可控。我的项目是针对具体业务场景设计的，比如客服或者数据分析，流程固定、工具集有限、边界清晰，所以可以用更少的 token、更快的速度、更稳定的质量完成。另外一个关键是可控性：通用框架的规划链路是黑盒的，出问题了很难追溯。而我的项目每个环节都有埋点、有回退机制、有熔断策略，上线之后出问题能快速定位，通用框架在生产环境里遇到问题基本靠撞运气。面试官其实最想听的是：你有没有意识到通用方案的问题，有没有能力做定制化改造。
【面试题】10. CrewAI 里 Role Playing 模式下，多个 Agent 互相踢皮球不干活，你怎么处理？
【标准答案】先说原因：通常是因为任务分配不清晰，或者每个 Agent 觉得别人的活自己也可以掺和，边界模糊了。处理方式分三步。第一步明确每个 Agent 的任务边界，CrewAI 的 task 描述要写死"这个任务只能由这个 Agent 触发，其他 Agent 不许抢"，用 task_guard 或者在 description 里写清楚。第二步加一个 Supervisor Agent 做路由，只有它有权分配任务，其他 Agent 只接受任务不主动抢活。第三步如果 Agent 之间的协作还是扯皮，用强制序列化——把多 Agent 并行改成顺序流水线，前一个 Agent 输出，后一个 Agent 必须接着干，不允许跳过。还有个实操技巧是在 CrewAI 的 agent_config 里限制每个 Agent 的工具集，让它"只会干自己的事"，工具集不重叠，踢皮球自然就少了。