工作知识库

Appearance

AI智能体应用开发面试题 ​

生成时间：2026-06-16 23:20
题目数量：10道
适用岗位：1-3年经验 AI Agent 开发工程师

【面试题】1. 在实际项目中，你是如何管理和优化大模型API调用的Token消耗的？请结合具体场景说明。 ​

【标准答案】 我主要从四个方面入手： 第一，输入侧做内容压缩。比如长文档场景，先用水印模型提取关键信息，再喂给主模型，能把输入Token减少60-80%。如果是多轮对话，会用摘要模型定期压缩历史消息，保留核心上下文。 第二，输出侧用max_tokens参数控制。根据业务场景设定合理上限，比如分类任务设200就够了，避免模型啰嗦。 第三，缓存策略。OpenAI和通义都支持Prompt Caching，系统提示词和Few-shot示例会被自动缓存，相同前缀的请求能省75%成本。我们把不变的System Prompt放在最前面，命中率能到90%以上。 第四，批量处理。如果是离线任务，用batch API能省50%费用，虽然延迟高一点但成本优势明显。 去年做一个客服项目，原来每次调用平均8000 Token，优化后降到2500，月度API成本从12万降到3.8万。

【面试题】2. 什么场景下应该选择单智能体架构，什么场景必须上多智能体？请给出你的决策框架。 ​

【标准答案】 我的判断标准就三条：任务复杂度、准确率要求、维护成本。

单智能体适合：任务链条清晰、工具调用在5个以内、不需要复杂协作的场景。比如"邮件自动分类+自动回复"，一个Agent配几个工具就能搞定，简单直接，运维也省心。

多智能体必须上的场景：第一，任务需要不同领域的专业能力，比如"投研报告生成"需要数据采集Agent、财务分析Agent、行业研究Agent、报告撰写Agent协作；第二，准确率要求极高，需要交叉验证，比如医疗诊断、法律文书审核，用多个Agent互相check能显著降低幻觉；第三，任务有清晰的前后依赖，并行能提速的，比如电商订单处理，库存检查、支付、物流可以分给三个Agent并行。

但实际落地我会先跑单Agent MVP，确实遇到瓶颈再拆多Agent。因为多Agent的调试成本、状态管理、错误传播处理复杂度是翻倍的。有个坑就是很多人一上来就搞多Agent，结果任务编排的bug比业务bug还多。

【面试题】3. 请解释Function Calling（工具调用）的完整执行链路，以及实际开发中常见的三个坑。 ​

【标准答案】 完整链路是：用户提问 → 模型判断是否需要调工具 → 返回工具调用参数（JSON） → 应用层执行工具 → 将结果返回模型 → 模型生成最终回复。

第一个坑：模型返回的参数格式不合规。比如该传数字的地方传了字符串，或者缺少必填参数。解决方案是在工具定义里用JSON Schema严格约束，同时加一层参数校验和自动修复，比如类型转换、默认值填充。

第二个坑：工具执行超时或失败，导致整个链路卡死。必须给每个工具调用加超时控制和重试机制，同时设计fallback策略。比如查数据库失败了，就返回"当前无法获取最新数据，基于历史信息回答"。

第三个坑：工具返回内容太长，撑爆上下文。特别是搜索类工具，经常返回大段网页内容。正确做法是工具层就做内容截断或摘要，只返回精炼信息给模型。我们一般限制单个工具返回不超过2000 Token，超了就摘要后再传。

【面试题】4. 你在落地RAG系统时，遇到过哪些核心挑战？是怎么解决的？ ​

【标准答案】 最大的三个挑战：检索准确率、上下文窗口限制、实时性。

检索准确率这块，核心是解决"相似但不相关"的问题。光靠向量相似度不够，我们用了混合检索：向量检索+关键词检索（BM25）+重排序模型（Rerank）。先召回 top-50，再用 Rerank 模型精排取 top-5，准确率从单向量的65%提升到87%。另外，Chunk切分很关键，不能粗暴按字数切，要按语义边界，我们用的是递归切分+滑动窗口，保持上下文连贯。

上下文窗口限制，如果召回的文档太多，用LongContext模型（比如支持128K的）或者做分层摘要：先摘要每个Chunk，再把摘要喂给模型。

实时性方面，知识库更新有延迟。解决方案是冷热数据分离：热数据（最近7天）用Redis缓存，冷数据走向量库。同时支持增量索引，新文档5分钟内就能被检索到。

有个实战数据：我们做的技术支持RAG，上线前人工评测，回答准确率从直接从模型拿的31%提升到RAG的82%，用户满意度从2.1分涨到4.3分（5分制）。

【面试题】5. 如果让你从0到1设计一个企业级智能客服系统，你会怎么规划技术选型和实施路径？ ​

【标准答案】 技术选型：模型用国产大模型（通义或文心），成本低且合规；Agent框架用Dify，可视化编排省开发量，也方便运营人员改Prompt；向量数据库用Milvus，开源且性能好；RAG用LangChain集成。

实施路径分四期： 第一期（2周）：MVP，单Agent + 基础工具（查订单、查物流）+ 简单知识库。先跑通核心流程，覆盖60%常见问题。 第二期（4周）：补齐RAG，导入历史工单和FAQ，做混合检索；加入多轮对话管理和意图识别；支持转人工的平滑切换。 第三期（4周）：多Agent拆分，按业务线（售后、售前、技术）拆专业Agent，用Orchestrator协调；加入用户画像和个性化回复；做服务质量监控。 第四期（持续）：数据分析驱动迭代，每周看未识别问题、低分会话，补充知识库；A/B测试不同Prompt和模型配置；逐步接入微信、钉钉等多渠道。

关键成功指标：首次解决率>70%，平均响应时间<3秒，转人工率<30%。这个路径我们实际跑过，从启动到上线第一期用了18天。

【面试题】6. LangChain、CrewAI、Dify 各自的适用场景是什么？你在实际项目中是如何选型的？ ​

【标准答案】 LangChain适合深度定制场景。如果你需要细粒度控制每个Chain、每个Tool的执行逻辑，或者要集成很冷门的组件，LangChain生态最全。但它的学习曲线陡，代码量大，适合有专门AI工程团队的场景。

CrewAI适合多Agent协作的复杂任务。它的Agent Role定义和Task分配做得很优雅，特别适合需要多个专业Agent协作完成一个复杂目标的场景，比如"竞品分析报告生成"，让Research Agent、Analysis Agent、Writer Agent协作。但生产稳定性不如LangChain，适合POC和内部工具。

Dify适合快速落地和业务人员参与维护的场景。可视化工作流编排，运营可以直接改Prompt和流程，不用每次找开发。API部署也简单，适合中小团队快速交付。我们80%的对外交付项目都用Dify，交付速度比手写代码快3-5倍。

选型建议：POC阶段用Dify快速验证，复杂定制化再迁移到LangChain；多Agent研究性质用CrewAI；需要完全掌控底层用LangChain。千万别一上来就全部自研，站在框架肩膀上省力太多。

【面试题】7. 智能体的记忆系统有哪些实现方式？在不同业务场景下你如何选择？ ​

【标准答案】 记忆系统分三层：短期记忆、长期记忆、外部记忆。

短期记忆就是上下文窗口，最简单直接。适合单次会话内的连贯对话，比如订餐场景，用户说了"我要一份披萨"，后面说"换成汉堡"，模型能从上下文理解。但超过窗口限制就没了。

长期记忆用向量数据库存储历史对话摘要和用户画像。实现方式是对每轮重要对话做摘要，存进Milvus/Qdrant，配上用户ID和时间戳。下次对话时，先检索相关历史，注入上下文。比如用户三个月前反馈过"对花生过敏"，这次推荐餐品时就能避开。

外部记忆是工具调用，Agent主动去查数据库、知识库。适合需要实时准确数据的场景，比如查账户余额、查订单状态。

我的选择逻辑：简单场景只用短期+外部记忆，成本低；需要个性化推荐的加长期记忆；需要跨会话连续性的（比如私人助手）三层都要。有个坑是长期记忆容易引入噪声，不是所有历史都有用，要设计遗忘机制，比如只保留最近N条或者按相关性过滤。

【面试题】8. 你如何评估一个AI智能体项目的成功与否？请给出可量化的指标体系。 ​

【标准答案】 我分四个维度：业务价值、用户体验、技术质量、成本效率。

业务价值：任务完成率（用户目标是否达成）、转化率提升（相比无AI前）、人工介入率（越低越好）。比如客服场景，任务完成率>70%、人工介入率<30%是及格线。

用户体验：首次响应时间（<3秒）、解决时长、用户满意度打分（CSAT）、回访率。CSAT要>4分（5分制），回访率能反映用户是否信任这个Agent。

技术质量：回答准确率（人工抽检或自动化评测）、幻觉率（关键信息错误比例，要<5%）、系统可用性（SLA>99.5%）、API失败率（<1%）。

成本效率：单会话成本（API调用成本）、人力节省比例、ROI。比如原来10个客服，上了Agent后只需要3个处理异常，那人力成本省了70%。

我一般会设计一版Dashboard，每天盯这些指标。特别是幻觉率和用户满意度，这俩是最能反映产品健康度的。有个实战经验：准确率从80%提到90%很难，但从90%到95%可能只需要调Prompt，所以别盲目追求100%，找到业务可接受平衡点就行。

【面试题】9. 在生产环境中部署Agent系统时，你遇到过哪些性能和稳定性问题？如何解决的？ ​

【标准答案】 最常见的是三个问题：API限流、响应延迟、错误级联。

API限流：大模型都有TPM（每分钟Token数）和RPM（每分钟请求数）限制。解决方案是做请求队列+限流控制，用Redis做分布式限流，超出限制自动排队。同时多API Key轮换，我们一般备3-5个Key做负载均衡。

响应延迟：模型推理本身就很慢，特别是长上下文场景。优化手段：第一，用流式输出，用户能实时看到回复，体感速度快很多；第二，并行工具调用，多个独立工具同时调，不用串行等；第三，用更快的模型做路由和简单任务，比如用GPT-3.5做意图识别，只有复杂问题才上调GPT-4。

错误级联：一个工具调用失败，导致整个Agent崩溃。必须加try-catch和降级策略。比如查知识库失败了，Agent还能基于自身知识回答；多个工具依赖的场景，设计checkpoint机制，失败能从最近的检查点恢复。

另外，监控很关键。我们用Prometheus+Grafana监控每个环节的耗时和成功率，一旦某个工具成功率掉到90%以下就告警。上线第一个月，光是超时问题我们就调了三次，最终把P99延迟从12秒压到3秒。

【面试题】10. 假设你的AI智能体在某个业务场景中长期存在"幻觉"问题，你会如何系统性地排查和解决？ ​

【标准答案】 幻觉问题我会按"数据-模型-流程"三层排查。

第一步：定位幻觉来源。把出问题的事例都拉出来，分三类：知识库没有但模型"脑补"的（纯幻觉）、知识库有但检索出来的是错误的（检索问题）、知识库有且检索对了但模型理解错的（推理问题）。我们做了个标注工具，让运营快速标记幻觉类型，一周能标500条，足够分析模式了。

第二步：对症下药。

  • 纯幻觉：加强工具调用，模型不知道的就让它去查，别瞎编。在Prompt里加"如果不确定，请使用工具查询或明确告知用户你不确定"。
  • 检索问题：优化RAG召回，加Rerank、调整Chunk大小、用HyDE（假设文档嵌入）提升召回率。
  • 推理问题：Few-shot教学，给3-5个正确推理的例子；或者换更强的模型。

第三步：防御机制。即使优化后还会有漏网之鱼，所以要加输出校验。比如关键信息（价格、时间、政策条款）必须能从知识库追溯到来源，输出时附带引用链接，用户能自己验证。

我们做过一个实验，综合用这些方法，幻觉率从18%降到了3.2%。但我要强调，幻觉不可能完全消除，关键是把它控制在不影响业务安全的范围内，同时设计好用户反馈和快速修正机制。

本文档由 AI智能体应用开发面试题生成器 自动生成