AI智能体应用开发面试题
生成时间：2026-06-12 01:50
【面试题】1. Agent在执行复杂任务时，中间步骤的结果往往不可控。你怎么设计"结果校验层"来保证最终输出的质量？
【标准答案】
我一般做三层校验：
第一层，格式校验。 工具返回结果后先过Schema校验，字段缺失、类型不对的直接打回重试。这个用Pydantic或JSON Schema就能做，成本最低、收效最大。
第二层，语义校验。 关键步骤的输出用另一个轻量模型做"review"，比如摘要步骤后让小模型判断"是否遗漏了原文关键信息"，分类步骤后判断"分类结果是否和原文语义一致"。这里用便宜快速的小模型就行，比如GPT-4o-mini，单次成本忽略不计。
第三层，终检兜底。 最终输出给用户之前，过一个"质量守门Agent"，检查事实一致性、格式规范性、是否有明显错误。如果终检不通过，触发重试或走人工兜底。
关键原则：不是每一步都校验，只校验关键节点。过度校验会拖慢整个流程，成本也上去了。我一般对最终答案生成、数值计算、外部API调用这三类步骤强制校验，其他步骤抽查。
【面试题】2. 你们Agent项目里是怎么做日志和监控的？模型调用的链路追踪怎么做？
【标准答案】
我用的核心方案是OpenTelemetry + LangFuse：
链路追踪：每次用户请求生成一个trace_id，从用户输入到最终输出，中间每一层（意图识别→工具选择→工具执行→答案生成）都作为span记录下来。这样出问题时能一眼看到卡在哪一步、哪一步耗时异常。
关键指标监控：我重点盯四个——
- 延迟P99：整个链路的响应时间分布，特别是工具调用耗时
- Token消耗：每个请求的输入/输出Token数，异常飙升说明prompt有泄漏风险
- 工具成功率：每个工具的调用成功/失败率，失败率突然上升可能是第三方API挂了
- 用户满意度：点赞/踩的比例，这是最直接的效果指标
告警策略：工具成功率低于90%告警，P99延迟超过30秒告警，Token单次消耗超过阈值告警。
实际经验：没有监控的Agent上线就是裸奔。我之前踩过一个坑——第三方翻译API静默返回空结果，Agent拿着空结果继续推理，最终给了用户一个离谱答案。加监控后才15分钟就发现了问题。
【面试题】3. 情景题：面试官说"我们需要做一个AI Agent帮运营团队自动生成周报，数据来源有内部数据库、飞书文档、企业微信消息，你怎么设计？"
【标准答案】
我会分四步走：
第一步，数据接入层。 这是最关键也最脏的活。内部数据库走SQL查询Agent，飞书文档走飞书开放API拉取，企微消息走webhook订阅。统一封装成数据源工具，每个工具返回标准化的JSON结构，上层不关心数据从哪来。
第二步，任务编排。 周报生成是典型的工作流场景，用Dify画布比纯Agent自主决策更稳——流程是固定的：数据采集→汇总统计→趋势分析→文案生成→排版输出。每一步都是确定性的，不需要Agent自主决策。
第三步，关键难点处理。
- 数据时间范围：明确限定"本周一至周日"，避免模型自己猜
- 数字准确性：统计类结果必须走代码执行，不能让模型"算"，幻觉率极高
- 文案风格：给3篇历史周报作为Few-shot，比写100字风格描述管用
第四步，人工兜底。 生成后先发到飞书群给运营确认，一键修改后再正式发送。第一周必须有人工审核环节，等准确率稳定在95%以上再考虑全自动。
【面试题】4. 你在Agent开发中是怎么处理"流式输出"的？用户等不了10秒才看到回答，这个工程问题你怎么解？
【标准答案】
流式输出我分两种场景处理：
简单问答场景，直接用大模型的Streaming API，逐token推给前端，SSE（Server-Sent Events）协议。用户看到的是打字机效果，体感延迟从10秒降到1秒内。这块没什么技术难点，关键是前端要做好markdown实时渲染，别等全部出来才渲染。
复杂Agent场景，比如需要调工具的，用户看到的不应该是"正在思考..."干等。我的做法是进度可视化：每完成一个步骤就推一条状态消息——"正在查询数据库..."→"正在分析数据..."→"正在生成报告..."。技术上就是Agent每执行完一个工具调用，就通过SSE推一条进度事件给前端。
工程细节：
- 流式输出要处理"部分JSON"问题，模型可能中途输出了半个JSON，解析会报错。我的方案是流式累积buffer，检测到完整JSON再解析
- 工具调用阶段的流式更复杂，Claude的tool_use在流式中有特殊的block标记，需要按官方文档处理
- 如果用户中途取消，要能中断模型推理，不然白烧Token。服务端要监听客户端断连事件
【面试题】5. 你怎么做Agent的Prompt版本管理？线上跑了3个月，Prompt改了20多版，怎么保证不混乱？
【标准答案】
我的核心方案是Git管理 + 配置中心 + 灰度发布：
Prompt即代码。 所有Prompt存在代码仓库里，和业务代码一起走Git流程。每次修改有commit记录、有review、能回滚。不写在代码里，而是单独的YAML/Markdown文件，运行时加载。
变量化拆分。 Prompt里会变的部分抽成变量，比如角色描述、输出格式、Few-shot示例。改Few-shot不需要改整个Prompt，只改示例部分。
版本标记。 每个Prompt文件有版本号，线上运行的版本号记录在配置中心（我们用的Apollo）。切换版本改配置就行，不需要重新部署。
灰度验证。 新版Prompt先给5%流量，对比老版本的关键指标（准确率、用户满意度、平均Token消耗）。没问题再全量。有问题秒级回滚到老版本。
避坑经验：千万别在数据库里存Prompt然后后台改。我见过有人半夜改了Prompt导致线上大面积幻觉，还不知道改了啥。Git的好处是每次变更都有迹可循。
【面试题】6. RAG系统中，用户query很短很模糊（比如"那个方案怎么样"），你怎么提升这种短query的检索效果？
【标准答案】
短query是RAG系统的经典难题，我一般用Query改写 + HyDE + 多路召回组合拳：
第一招，Query改写。 利用对话历史补全指代和省略。比如用户说"那个方案怎么样"，结合上下文把query改写成"2024年Q3市场扩张方案的评估结果怎么样"。这一步用小模型就行，GPT-4o-mini足够，成本低、速度快。
第二招，HyDE（Hypothetical Document Embedding）。 让模型先根据query生成一个"假设性答案"，拿这个假设答案去做向量检索。原理是假设答案和真实文档的语义空间更接近，比直接用短query检索效果好很多。实测Recall@5能提15-25%。
第三招，多路召回融合。 向量检索、关键词检索、实体检索三路并行，结果去重后用Reranker重排。短query的关键词检索反而可能比向量检索更准（因为关键词更明确）。
进阶优化：记录用户的历史query模式，对高频模糊query预生成改写模板，不走实时改写，直接查表，延迟更低。
【面试题】7. 你在多Agent项目中，是怎么处理"Agent调用链路过长"导致延迟过高的问题的？
【标准答案】
我从并行化、缓存、裁剪三个方向优化：
并行化：分析Agent间的依赖关系，没有前后依赖的子任务并行执行。比如"调研竞品+分析数据+撰写摘要"，调研和分析可以同时跑，最后汇总给撰写Agent。我用异步编排把串行3步变并行2步，总延迟降了40%。
缓存：相同或相似query的结果缓存。分两层——
- 精确缓存：完全相同的query直接返回历史结果，适合FAQ类场景
- 语义缓存：用Embedding计算query相似度，超过阈值（我一般设0.95）就复用历史结果。用Redis存，TTL按业务设
裁剪：不是每个query都需要走完整的Agent链路。我加了一个轻量路由层，简单问题直接走RAG+LLM，不走Agent编排。大概30%的query可以被路由走捷径，平均响应时间从8秒降到2秒。
还有一招：把大任务拆成"快路径"和"慢路径"。用户先拿到一个快速版答案（基于缓存的摘要），后台Agent继续跑完整分析，跑完再推送完整版。体验上用户不用干等。
【面试题】8. 你怎么理解Agent的"自主性"和"可控性"之间的平衡？实际项目中怎么把握这个度？
【标准答案】
这是个非常实际的权衡问题，我的原则是业务容错率决定自主性上限：
高容错场景放手自主：比如内部工具、创意辅助、信息检索，错了改改就行。这类场景给Agent更多自主决策空间，用ReAct模式让它自己规划步骤、选工具。效率更高，人也不累。
低容错场景严格管控：比如财务处理、合同审核、对外客服，错了就是事故。这类场景走工作流编排，每一步都是预设的，Agent只能在固定节点上做有限决策。关键节点加人工确认。
实际项目案例：我做了一个法务合同审查Agent，流程完全固定——提取条款→逐条风险评分→生成审查意见。Agent只在"风险评分"这一步有自主判断空间，其他环节都是模板化处理。这样既利用了模型的语义理解能力，又不会出现Agent"自作主张"的情况。
度量方法：我会统计Agent自主决策的"偏差率"——Agent自主选择的工具/步骤和人工期望的偏差有多大。偏差率超过15%，就降低自主性，增加约束。
【面试题】9. 面试官问："你觉得现在Agent开发最大的技术瓶颈是什么？你怎么看待这个方向的发展？"
【标准答案】
我认为目前最大的瓶颈是可靠性和可预测性：
具体表现：同样的输入，Agent可能走完全不同的路径、调用不同的工具、给出不同质量的结果。这在demo里不是问题，在生产环境是致命的。传统软件的确定性保证在Agent体系里很难做到。
为什么会这样：核心是大模型的"非确定性推理"。模型本身有随机性，加上工具调用可能失败、外部状态可能变化，导致Agent行为难以100%预测。
我的应对思路：
- 短期靠工程兜底——工作流约束、结果校验、人工审核、灰度发布，把不可控的边界收窄
- 中期靠评估体系——建立Agent行为的自动化评测，像测试代码一样测试Agent，把可靠性量化
- 长期看模型演进——更好的指令遵循能力、更稳定的结构化输出、更长的有效上下文，这些都在快速进步
对方向的看法：Agent不会替代传统软件，而是补充。确定性逻辑继续用代码写，只有需要语义理解的环节才交给Agent。二者混合的架构会是主流。
【面试题】10. 你们Agent项目上线后，是怎么做效果评估和持续迭代的？具体说说从数据到改进的闭环。
【标准答案】
我搭了一套"采集→标注→分析→改进→验证"的闭环：
采集层：线上所有对话自动记录，包括用户输入、Agent中间步骤、最终输出、用户反馈（点赞/踩/修改）。关键是中间步骤也要记录，光看最终答案无法定位问题。
标注层：每周抽100条badcase做人工标注，分类归因——是检索不准？工具选错？推理出错？格式不对？用标注平台（我们用的Label Studio）管理，标签体系提前定义好。
分析层：按归因维度统计占比。比如发现40%的badcase是检索不准，那RAG就是第一优先改进项。用数据驱动决策，不拍脑袋。
改进层：根据分析结果针对性优化——检索不准就调chunking策略或换embedding模型，工具选错就优化工具描述，推理出错就加CoT或Few-shot。每次只改一个变量，方便归因。
验证层：改完后在标注数据集上跑评测，对比改进前后的指标。线上走灰度，5%流量验证，指标不退步才全量。
迭代节奏：我们是双周迭代，每周标注，双周发版。持续跑了3个月，准确率从78%提到了93%。