工作知识库

Appearance

AI智能体应用开发面试题 - 2026-06-16 ​

生成时间：2026-06-16 00:25
适用岗位：1-3年经验 AI智能体开发工程师

【面试题】1. 在大模型API调用中，如何优化token使用和成本控制？实际项目中你用过哪些具体手段？ ​

【标准答案】

我主要从三个方面控制成本：

第一，Prompt压缩。 System Prompt能复用的复用，用户对话历史做截断——不是傻傻留全部，而是用摘要代替早期对话。比如用户聊了10轮，把前5轮压缩成一段摘要存入上下文，能省30-40%的输入token。

第二，模型分级调用。 简单任务用便宜的模型（比如GPT-3.5或国产小模型），只有需要复杂推理时才调主力大模型。我们项目里分类、实体抽取这类任务都用小模型，每月API成本降了60%。

第三，缓存命中。 OpenAI和国内主流大模型都支持Prompt缓存，相同的System Prompt+工具定义如果命中缓存，价格能降到1/10。所以我们把工具定义、系统指令做成固定前缀，确保高缓存命中率。

还有就是监控，接个token用量统计，哪天突然暴涨能马上定位到是哪个功能失控了。

【面试题】2. 如何设计一个高质量的System Prompt？有哪些进阶技巧能让智能体表现更稳定？ ​

【标准答案】

System Prompt最忌讳写成长篇小说，我总结几个实战要点：

角色定义要具体。 不要写"你是一个有帮助的助手"，要写"你是一个电商售后智能体，负责处理退换货咨询，语气亲切但不过度热情"。越具体，模型越不容易跑偏。

给输出格式做强制约束。 比如要求"必须按JSON格式返回，字段为: intent/confidence/reply"，比让它"自由发挥"稳定得多。我们还会在prompt末尾重复一遍格式要求，双重保险。

放few-shot例子。 在prompt里塞2-3个真实对话案例，比写一堆规则管用。模型学例子比记规则快多了。

进阶技巧是"思维链引导"。 让模型先输出推理过程再给结论，比如"请先分析用户意图，再判断是否需要转人工，最后生成回复"。这样能减少乱答，也方便我们调试——能看到模型到底在哪一步跑偏了。

最后是定期迭代，线上跑一段时间把badcase塞进prompt做负样本，效果会越来越好。

【面试题】3. 什么场景下应该选择多智能体架构？多智能体之间如何协作？说一个你做过的实际案例。 ​

【标准答案】

单智能体搞不定的时候才上多智能体，主要看两个信号：任务太复杂、单一prompt装不下，或者需要不同专业能力。

我们做过一个电商客服项目，就是典型的多智能体场景：

  • 路由智能体：判断用户意图（退换货/物流查询/产品咨询）
  • 三个专业智能体：分别处理上面三类问题
  • 一个监督智能体：处理用户不满意时的升级

协作方式用的是" supervisor模式"——有个总控智能体负责任务拆解和结果汇总，子智能体只做自己擅长的事。通信是用结构化JSON，每个智能体的输出格式都严格定义，避免信息在传递中失真。

还有一种协作是"辩论模式"，让两个智能体互相挑战，最后取共识，适合需要高准确率的场景，比如医疗或金融问答。

多智能体的坑是延迟高，一次用户请求可能要调好几次大模型，所以不是所有场景都适合，要权衡效果和响应速度。

【面试题】4. 如何设计一个生产级的RAG系统？从文档入库到用户查询，关键技术点有哪些？ ​

【标准答案】

生产级RAG不是接个向量数据库就完事了，我按数据流说关键技术点：

文档预处理阶段：

  • 文档解析要用专门工具（ unstructured、PyMuPDF），别直接用正则抠文本，表格、图片里的文字会丢
  • Chunk大小控制在500-800字，重叠100-200字，太小没上下文、太大检索不精准
  • 给每个chunk加metadata（来源、时间、章节），后面排序和溯源都用得上

检索阶段：

  • 不要用单纯的向量检索，要"向量+关键词"混合检索，召回率能提升20%以上
  • 用Rerank模型对召回结果做重排序，不是所有向量相似度高的chunk都真的有用
  • 查询也要做优化，用户的提问可能很口语化，用Query Rewrite改写成更规范的检索语句

生成阶段：

  • 把检索到的chunk数量控制在5-8个，太多会撑爆上下文，太少信息不够
  • 在prompt里明确告诉模型"如果检索结果不足以回答问题，就说不知道"，减少幻觉

我们项目上线后最核心的迭代是做"检索质量评估"——定期抽样看哪些问题检索召回的chunk不对，然后针对性优化chunk策略。

【面试题】5. 向量数据库选型时应该考虑哪些因素？你用过哪些向量数据库？各自适合什么场景？ ​

【标准答案】

选型主要看四个维度：数据规模、查询性能、运维成本、生态兼容性。

我用过的几款：

Chroma：最适合原型验证和小型项目，pip install就能用，数据量在百万级以内完全够用。缺点是分布式能力不足，生产环境数据量大了要迁移。

Qdrant：生产首选，性能强（用Rust写的），支持复杂的过滤条件（metadata filtering），API设计也很合理。我们线上用的就是Qdrant，千万级向量查询延迟在50ms以内。

Milvus：适合超大规模（亿级向量），分布式架构做得好，但运维复杂，需要专门的DBA维护，小团队慎用。

Pinecone：全托管的，不用自己运维，适合快速上线。但数据是存在人家的服务器上，有数据合规风险，而且按量收费不便宜。

国内项目我一般推荐Qdrant或者腾讯云的向量数据库，性价比和合规性都比较好。选型建议先拿真实数据做个POC，别光看benchmark，实际查询效果和你的数据分布强相关。

【面试题】6. LangChain、CrewAI、Dify这三个框架各有什么优缺点？实际项目中你是怎么选型的？ ​

【标准答案】

这三个框架定位不太一样：

LangChain：最灵活，适合有定制化需求的开发。优点是生态最丰富，各种集成都有；缺点是抽象层级太多，代码可读性差，版本升级经常 breaking change。适合做复杂Agent逻辑，但学习曲线陡。

CrewAI：专注于多智能体协作，概念清晰（Agent、Task、Crew），代码写起来很直观。适合任务可以明确拆解、多个专业Agent配合的场景。缺点是对单智能体场景来说有点重，而且生态还不如LangChain丰富。

Dify：低代码平台，适合快速交付和原型验证。优点是可视化工作流，产品和运营都能参与配置；缺点是复杂逻辑不太好实现，深度定制要改源码。我们做内部工具原型时先用Dify快速验证，验证完了再用代码重写。

我的选型逻辑：

  • 要快速给老板演示 → Dify
  • 多智能体协作类产品 → CrewAI
  • 复杂业务逻辑、需要深度定制 → LangChain
  • 现在也关注LangGraph，做有状态的多步Agent很合适，比LangChain Chain那套清晰多了。

【面试题】7. Function Calling的实现原理是什么？在实际开发中有哪些最佳实践？遇到过哪些坑？ ​

【标准答案】

实现原理： 大模型并不直接"调用"函数，而是在生成回复时输出一个结构化的JSON，告诉调用方"我想调这个函数，参数是这些"。真正执行函数的是我们的应用代码，执行完把结果塞回对话上下文，让模型继续处理。

最佳实践：

  • 函数描述（description）要写清楚，模型是靠这个描述决定调不调这个函数的，描述模糊会导致该调不调、不该调乱调
  • 参数定义要有明确的类型和约束，比如用enum限制取值范围，减少模型瞎编参数
  • 函数执行结果要压缩，别把几千行的返回结果直接塞进上下文，先做摘要
  • 一定要有超时和重试，外部API不可靠，函数调用失败要有降级方案

踩过的坑：

  • 模型会"幻觉"函数名，特别是函数多的时候，要在代码层做校验，别直接把模型返回的函数名拿来调
  • 并行调用多个函数时，要注意函数之间有依赖关系的不能并行，这个要在代码里处理好
  • 函数返回错误时，要把错误信息优雅地告诉模型，让它有机会纠正，而不是直接中断对话

【面试题】8. 智能体的记忆系统应该如何设计？短期记忆和长期记忆分别怎么实现？说一下你的方案。 ​

【标准答案】

记忆系统核心是解决"上下文窗口有限"和"用户希望智能体记住历史"之间的矛盾。

短期记忆（会话内）： 就是对话历史，但要做管理。我们的策略是：

  • 最近3-5轮完整保留
  • 更早的对话做摘要压缩
  • 用户明确说"记住XXX"的信息，提取成结构化数据单独存储

长期记忆（跨会话）： 这是重点，我们有两种实现方式：

  • 向量检索方案：把历史对话做成向量存起来，用户新消息来了，先检索相关历史，再注入上下文。适合"记住我们之前的讨论"这类场景
  • 结构化记忆：把用户的偏好、关键信息（比如"用户是VIP客户"、"用户对价格敏感"）提取出来存在数据库里，每次对话开始前先加载

实际落地建议： 不要一上来就搞复杂的记忆系统。先做好会话内的上下文管理，等有"用户抱怨智能体记不住事"的反馈了，再针对性地加长期记忆。我们是从第二个版本才开始做向量检索方案的，第一个版本就用简单的"关键信息提取+注入"。

还有一个经验：记忆不是越多越好，要给记忆做"遗忘机制"，过时信息要清理，否则会干扰模型判断。

【面试题】9. 生产环境中，智能体的错误处理机制应该如何设计？如何做容错和降级？举具体例子说明。 ​

【标准答案】

生产环境和demo最大的区别就是错误处理，我从三个层面说：

大模型调用层：

  • 必须有重试机制，但不是傻重试，要做指数退避（第一次等1秒，第二次等2秒，第三次等4秒）
  • 准备降级模型，主力模型连续失败3次，自动切换到备用模型（比如从GPT-4降到GPT-3.5），保证服务不中断
  • 每次调用都要加超时，不能让一个慢请求卡住整个链路

工具调用层：

  • 每个外部工具调用都要有circuit breaker（熔断），比如搜索API连续失败，就暂时跳过搜索，直接基于模型知识回答
  • 工具执行结果要做校验，别把错误堆栈直接展示给用户，要转成友好提示

用户交互层：

  • 模型答非所问或置信度低时，主动说"这个问题我不太确定，建议您联系人工客服"
  • 关键操作（比如退款、修改订单）必须有人工确认环节，不能全靠智能体

具体案例： 我们做过一个智能体，调用内部订单系统API时经常超时。解决方案是：先返回"正在查询您的订单..."，然后异步调用，同时提供一个"人工客服"的快速入口。用户体验反而比之前卡住转圈好。

【面试题】10. 如果从0到1做一个企业级智能体项目，你的技术选型和实施路径是什么？每个阶段要注意什么？ ​

【标准答案】

我一般分四个阶段推进：

第一阶段：需求拆解和MVP（2-3周） 先别写代码，把需求想清楚：用户是谁？要解决什么问题？成功指标是什么？ MVP用最简单的技术栈，比如Dify搭建原型，快速验证价值。这个阶段别追求完美，能跑通核心流程就行。

第二阶段：技术选型和核心模块开发（4-6周） 根据MVP反馈选定技术栈。我的一般配置：

  • 框架：LangChain或CrewAI
  • 向量数据库：Qdrant
  • 大模型：主力用GPT-4或国产大模型，小任务用便宜模型
  • 部署：Docker容器化

核心模块按优先级：对话管理 > 工具调用 > RAG检索 > 记忆系统。每个模块先实现基础版本，别一上来就追求完美。

第三阶段：测试和优化（2-3周） 重点测三类场景：正常流程、边界情况、异常输入。特别要注意"模型幻觉"和"工具调用失败"这两类问题。 性能优化主要看两个指标：响应时间（目标<3秒）和准确率（目标>85%）。

第四阶段：上线和迭代 上线第一天必须有人值班，随时处理突发问题。 建立反馈机制，收集用户评价和badcase，每周做一次模型迭代。

最大的经验教训： 别一上来就做通用智能体，先做垂直场景，把一件事做好，再考虑扩展。我们第一个项目就是太贪心，想做"万能客服"，结果哪个场景都做不深。

本文档由 AI智能体应用开发面试题生成器 自动生成
考点覆盖：大模型API调用、提示词工程、单/多智能体架构、RAG系统、向量数据库、Agent框架选型、Function Calling、记忆系统、错误处理、项目落地