AI智能体应用开发面试题

生成时间：2026-06-12 02:20

---

【面试题】1. 大模型调用出现"幻觉"问题，你在Agent项目中是怎么处理和缓解的？

【标准答案】幻觉是大模型的固有问题，不可能完全消除，但可以从三个层面控制：

第一层：提示词层面

• 给模型提供参考材料，让它基于材料回答，而不是凭空编造
• 加上"如果你不确定，请直接说不知道"这类指令
• 用Few-shot给几个正确回答的范例，约束输出格式

第二层：架构层面

• 关键信息走RAG检索，不要让模型凭记忆回答
• 结构化输出要求：让模型输出JSON，字段里强制要求引用来源
• 多模型交叉验证：重要答案用两个模型分别生成，对比一致性

第三层：后处理层面

• 事实核查：对模型输出的数字、日期、专有名词做规则校验
• 置信度过滤：让模型给自己答案打分，低于阈值的提示用户确认

实际经验：Agent场景最有效的是工具调用+引用溯源。让模型通过工具获取实时数据，回答时必须标注数据来源，用户能点进去验证，信任度就上来了。

---

【面试题】2. 你们团队是怎么做提示词版本管理和效果评估的？有没有踩过什么坑？

【标准答案】我们用Git做提示词版本管理，但提示词不像代码，有个坑：同一个提示词在不同模型上效果差异很大。

我们的做法：

版本管理：

• 每个提示词一个Markdown文件，开头标注适用模型、版本号、更新日期
• 用Git管理，但重要的版本变更要记录效果对比数据
• 在项目里建一个prompts/目录，按功能模块分类

效果评估：

• 建立测试集：每个提示词配套一个测试用例集（至少50条），包含各种边界情况
• 用自动化脚本跑测试，记录每条用例的输出结果和人工评分
• 核心指标：准确率、完整度、格式规范度

踩过的坑：

• 提示词改一行，整个Agent行为变了，但没有测试集没发现
• 模型升级后老提示词效果下降，但没人注意
• 团队成员各自改提示词，互相覆盖

解决方法：提示词变更走Code Review流程，必须附带测试集评估结果。

---

【面试题】3. 在Agent项目中，你是怎么实现"工具调用失败自动重试"的？重试策略怎么设计？

【标准答案】工具调用失败很常见，原因可能是：网络超时、API限流、参数错误、服务暂时不可用。重试策略要区分失败类型。

我的实现思路：

def tool_call_with_retry(tool, params, max_retries=3):
    for attempt in range(max_retries):
        try:
            result = tool.invoke(params)
            return result
        except RateLimitError:
            # 限流错误：等待后重试
            time.sleep(2 ** attempt)  # 指数退避
        except ValidationError:
            # 参数错误：不重试，直接返回错误
            return {"error": "invalid params", "detail": str(e)}
        except TimeoutError:
            # 超时：重试
            if attempt == max_retries - 1:
                return {"error": "timeout"}
        except Exception as e:
            # 未知错误：记录日志，不重试
            log_error(e)
            return {"error": "unknown"}

策略设计要点：

• 区分错误类型：参数错误不重试，网络错误才重试
• 指数退避：等待时间指数增长，避免雪崩
• 最大重试次数：通常3次，超过就降级或报错
• 失败降级：重试全部失败后，给模型一个兜底返回，让它知道工具不可用

LangChain里有Retry包装器可以直接用，CrewAI也支持在Task里配置重试策略。

---

【面试题】4. 你有没有做过"多模态Agent"？比如让Agent能看图、听语音，这类项目有什么技术难点？

【标准答案】做过一个质检报告分析Agent，用户上传产品照片，Agent自动识别缺陷类型并生成报告。

技术实现：

• 图像理解：调用GPT-4V或国内通义千问VL，把图片转成文字描述
• 文档生成：文字描述作为输入，走LLM生成结构化报告
• 多模态嵌入：图片和文字都用同一个嵌入模型（CLIP类），存到向量库做检索

核心难点：

难点1：图片信息丢失 模型看图可能漏掉细节。解决方法：先让模型做详细描述，再让另一个模型审核描述是否完整，两轮处理。

难点2：上下文长度爆炸 一张图转成文字可能上千token，多张图直接爆掉。解决方法：图片先做摘要或分类，只把关键信息传给主模型。

难点3：多模态对齐 用户说"这个零件有问题"，模型不知道"这个"指图上哪个位置。解决方法：让模型输出坐标或标注，支持视觉定位。

难点4：成本控制 多模态模型贵很多。解决方法：先用便宜的文字模型判断是否需要看图，只有必要时才调用视觉模型。

---

【面试题】5. 如果让你设计一个Agent的"错误处理与恢复"机制，你会怎么设计？举几个实际场景。

【标准答案】Agent的错误处理比传统软件复杂，因为模型行为不可预测。我设计三层机制：

第一层：工具级错误处理

• 每个工具内部做参数校验和异常捕获
• 返回统一格式：{"success": bool, "data": any, "error": str or null}
• 工具失败后，把错误信息返回给模型，让它决定下一步

第二层：规划级错误处理

• Agent执行计划时，如果某一步失败，触发重新规划
• 给模型输入：原始任务 + 已执行步骤 + 失败原因，让它生成新计划
• 设置最大重规划次数，避免无限循环

第三层：系统级熔断

• 当工具调用失败率超过阈值，自动禁用该工具
• 当请求成本超过预算，降级到更便宜的模型
• 当响应时间超过阈值，返回缓存结果或默认答案

实际场景：

场景1：用户让Agent查订单，订单系统API挂了 → 工具返回错误，模型判断"查询失败，建议稍后再试或联系客服"

场景2：模型生成了错误的工具参数，反复调用失败 → 规划层检测到同一工具连续失败，触发重新规划

场景3：某时段大量用户涌入，LLM API超时 → 系统级熔断，降级到本地规则引擎处理简单请求

---

【面试题】6. 你们公司的Agent项目是怎么做上线部署和运维监控的？

【标准答案】我们走的是渐进式上线策略，先灰度再全量。

部署架构：

• Agent服务跑在K8s，按业务模块拆分微服务
• 大模型调用走内部API网关，统一管理密钥和限流
• 向量库用Milvus集群，数据持久化到云存储
• 日志全部打到ELK，关键指标上报Prometheus

上线流程：

1. 沙盒环境测试：内部员工试用，收集badcase
2. 灰度发布：先开10%流量，观察错误率和成本
3. 全量发布：指标稳定后逐步放开
4. AB测试：新版本和旧版本并行，对比效果

监控指标：

• 业务指标：意图识别准确率、任务完成率、用户满意度
• 技术指标：响应时间P99、token消耗、工具调用成功率
• 成本指标：单次请求成本、日成本趋势

告警机制：

• 响应时间 > 10秒 → 告警
• 错误率 > 5% → 告警
• 日成本超预算30% → 告警
• 大模型API不可用 → 告警

我踩过的坑：有一次向量库索引没建好，查询慢了10倍，但没有及时告警，用户投诉才发现。后来给向量库也加了慢查询监控。

---

【面试题】7. 长上下文场景下，你是怎么处理"信息遗漏"和"重点淹没"问题的？

【标准答案】长上下文是大模型的卖点，但实际用起来有两个问题：

问题1：信息遗漏 模型对开头和结尾的内容记得清楚，中间的容易忘。这叫"中间丢失效应"。

问题2：重点淹没 几万字塞进去，模型分不清哪些是关键信息，输出变得泛泛而谈。

我的解决方案：

方案A：分层处理

• 长文档先做摘要提取，把关键信息抽出来放在prompt开头
• 原文按需检索，不全部塞进去
• 让模型先读摘要，再根据需要调原文

方案B：位置强化

• 重要信息放在prompt的开头或结尾
• 用"以下是最关键的信息："这类语句显式标注
• 多次重复关键信息，提高注意力权重

方案C：动态上下文

• 不是一次性把所有信息给模型，而是按需检索
• 第一轮给摘要，模型追问时再检索细节
• 这样每次请求的上下文都短，信息密度高

方案D：结构化输入

• 长内容用JSON或XML结构化，模型更容易定位
• 每个段落加标签："【背景】【问题】【约束条件】"

实际经验：超过8000token的内容，分层处理效果最好。先让模型理解全局，再逐层展开细节。

---

【面试题】8. 你在Agent项目里是怎么做"数据监控和效果迭代"的？有没有形成闭环？

【标准答案】我们有个数据驱动的迭代闭环，核心是收集真实用户反馈。

数据收集层：

• 每次对话记录：用户输入、Agent输出、工具调用链路、耗时
• 用户反馈：点赞/点踩、修改建议、转人工率
• 自动标注：用规则或小模型标注意图、情绪、是否完成任务

数据分析层：

• 每周拉一份badcase报告，人工标注失败原因
• 按错误类型分类：意图识别错误、知识库缺失、工具调用失败、模型幻觉
• 统计高频问题，优先级排序

迭代优化层：

• 知识库缺失 → 补充文档
• 意图识别错误 → 补充训练数据或调整规则
• 工具调用失败 → 优化工具描述或参数校验
• 模型幻觉 → 优化提示词或加引用约束

效果验证：

• 改完后用测试集验证，确保改动没有引入新问题
• A/B测试对比新旧版本效果
• 关键指标提升才上线

闭环的关键：把用户反馈变成可量化的数据，把数据变成具体的优化动作，把优化动作变成可验证的效果提升。

---

【面试题】9. 面试官问："你在Agent项目里遇到过什么安全风险？怎么防范的？"

【标准答案】Agent的安全风险比传统软件多，因为它会"主动做事"。我遇到过的几类：

风险1：提示词注入 用户输入包含恶意指令，让Agent泄露系统信息或执行危险操作。

• 防范：用户输入做过滤，检测敏感关键词；系统提示词和用户输入用分隔符隔离；关键操作加二次确认。

风险2：工具滥用 模型调用删除、转账等高危工具，造成实际损失。

• 防范：高危工具加权限控制，必须用户确认才执行；敏感操作记录审计日志；设置每日调用上限。

风险3：数据泄露 Agent把用户隐私数据传给第三方API，或在回答中泄露其他用户数据。

• 防范：数据脱敏后再传模型；用户数据隔离存储；回答前做敏感信息过滤。

风险4：越狱攻击 用户绕过安全限制，让模型生成有害内容。

• 防范：加安全审核层，对模型输出做二次检测；对接内容安全API（如阿里云绿网）。

风险5：成本攻击 恶意用户发起大量请求，消耗API配额或造成高额账单。

• 防范：用户级限流；单次请求token上限；异常流量自动熔断。

我的原则：安全措施要分层，不能只靠模型自己判断。关键操作必须有代码层面的硬约束。

---

【面试题】10. 假设让你负责一个"智能研究助手"Agent项目，从0到1你会怎么规划？需要哪些核心能力？

【标准答案】智能研究助手是个典型的信息聚合+知识生产场景，我会分三阶段规划：

第一阶段：MVP验证（2周） 核心能力：联网搜索 + 网页内容提取 + 报告生成

• 用户输入研究主题，Agent搜索相关信息
• 调用网页提取工具获取正文内容
• LLM汇总生成研究报告初稿
• 技术选型：LangChain + Serper搜索 + Jina Reader

第二阶段：能力扩展（1个月） 新增能力：多源数据 + 对比分析 + 引用溯源

• 接入学术论文库（arXiv API）、新闻源、行业数据库
• 多源信息交叉验证，自动标注引用来源
• 支持自定义研究框架（SWOT、PEST等）
• 加入用户反馈机制，迭代优化

第三阶段：专业深化（持续） 新增能力：领域知识库 + 协作研究 + 版本管理

• 建立行业知识库（研报、政策、案例）
• 支持多用户协作，共享研究素材
• 研究报告版本管理，追踪修改历史
• 输出格式多样化：PPT、Excel、可视化图表

关键设计点：

• 搜索质量：用多搜索引擎聚合，加相关性过滤
• 信息去重：相似内容合并，避免报告冗余
• 引用准确：每个结论必须标注来源，可溯源
• 用户可控：用户可以调整研究方向，Agent不自己乱跑

成本控制：研究报告生成涉及多次API调用，单次成本控制在1元以内。

---