工作知识库

Appearance

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

【面试题】1. 如何评估一个LLM API是否适合生产环境？要考虑哪些关键指标？ ​

【标准答案】 生产环境选型主要看四个维度：

稳定性：API的SLA是多少？有没有降级机制？我们之前用某个模型，每天下午高峰时段响应时间从2秒飙到15秒，这种就不能用。

成本：别只看单价，要算综合成本。比如GPT-4效果好但贵，如果用GPT-3.5+精细化prompt能达到80%效果，成本只有1/10，那就要权衡。我们有个项目就是从GPT-4切换到国产模型，成本降了70%。

性能：TPS、延迟、并发能力。如果要做实时对话，延迟必须控制在3秒内；如果是异步任务，可以放宽到10秒。

可控性：能不能微调？有没有内容审核？输出格式是否稳定？特别是要做JSON输出的场景，模型的format following能力很关键。

实操中我一般会先做POC，用真实业务数据测试，跑7天看各项指标，再决定要不要上线。

【面试题】2. 单智能体和多智能体架构分别适合什么场景？如何做技术选型？ ​

【标准答案】 单智能体适合：

  • 任务边界清晰、流程固定，比如客服问答、文档摘要
  • 工具数量少于10个，不会让模型"选择困难"
  • 团队资源有限，要快速上线

多智能体适合：

  • 复杂任务需要拆解，比如"帮我做竞品分析"，需要搜索、爬取、总结、对比多个子任务
  • 需要不同角色协作，比如代码生成场景，一个Agent写代码，一个Agent做code review
  • 需要并行处理，比如同时查询多个数据源

选型建议：

  1. 先试试单智能体能不能搞定，大多数场景其实单智能体够用
  2. 如果prompt超过2000字，或者工具超过15个，考虑拆多智能体
  3. 多智能体用CrewAI或LangGraph，别自己写通信协议，坑很多

我们之前的经验：一个电商客服项目，一开始用多智能体（意图识别Agent+订单查询Agent+售后Agent），结果发现延迟高、成本高，后来合并成单智能体+函数调用，效果差不多，但性能提升3倍。

【面试题】3. Agent的工具调用经常出现失败或幻觉，如何提升工具调用的稳定性？ ​

【标准答案】 这个问题我们踩过很多坑，总结下来有五个优化方向：

1. 工具定义的规范性和清晰度

  • 工具的description要写清楚，别说"用于查询数据"，要说"根据用户ID查询该用户最近30天的订单记录，返回订单号、商品名称、金额"
  • 参数要有明确的类型和描述，必要时加example

2. 使用更稳定的模型

  • Claude和GPT-4的工具调用稳定性明显好于开源模型
  • 如果必须用开源模型，用经过function calling微调的版本，比如NexusRaven、Gorilla

3. 添加工具调用的验证层

  • 在模型输出工具调用参数后，先校验参数合法性，再执行
  • 比如日期格式、枚举值、必填参数等，不合法就让模型重新生成

4. 提供few-shot示例

  • 在system prompt里给2-3个工具调用的示例，能大幅提升准确率
  • 特别是边缘场景，比如"用户没提供日期时，默认查最近7天"

5. 降级策略

  • 工具调用失败时，别直接报错，先尝试用NLP解析用户意图，或者用默认的fallback工具
  • 我们有个查询工具，失败后会降级到关键词搜索，虽然不够精准但至少能用

【面试题】4. 在RAG系统中，如何优化检索效果？Chunk大小、Overlap、Embedding模型怎么选？ ​

【标准答案】 RAG的检索效果直接影响最终答案质量，我们一般从这几个方面优化：

Chunk大小：

  • 通用文档：512-1024 tokens，太小会切断语义，太大会引入噪声
  • 代码文件：可以更大，2048-4096 tokens，因为代码依赖上下文
  • 对话历史：按轮次切分，保留完整QA对

Overlap：

  • 建议10%-20%，比如chunk=512，overlap=50-100
  • 关键是别让overlap太大，不然检索会有重复，浪费token

Embedding模型选型：

  • 英文：OpenAI text-embedding-3-small（性价比高），或者用Cohere
  • 中文：别用OpenAI，效果一般，推荐用bge-large-zh、m3e-base，或者用文心、通义的embedding模型
  • 如果数据量大，可以考虑fine-tune embedding模型，我们用领域数据微调后，检索准确率从72%提升到89%

其他优化技巧：

  1. Hybrid检索：关键词+向量，互补短板。我们用BM25+向量检索，召回率提升15%
  2. Rerank：检索后用CrossEncoder rerank一次，精排Top3-5
  3. Query改写：用户问题很短或不完整时，用模型改写成更利于检索的query
  4. Metadata过滤：按时间、作者、标签等过滤，减少检索空间

实操建议：别一上来就搞复杂，先用默认配置跑通，再看badcase针对性优化。我们一般会在上线后收集"检索失败"的案例，分析是chunk问题、embedding问题还是query问题，再逐个击破。

【面试题】5. Milvus、Chroma、Qdrant、Pinecone这些向量数据库，各自的优势和适用场景是什么？ ​

【标准答案】 这几个我们都用过，总结一下选型建议：

Chroma：

  • 优势：轻量级，pip install就能用，适合快速原型和小项目
  • 劣势：分布式能力弱，性能一般，不适合大规模生产
  • 适用：个人项目、POC、数据量<100万

Qdrant：

  • 优势：Rust写的，性能强，支持丰富的过滤和稀疏向量，API设计友好
  • 劣势：生态不如Milvus，企业级功能（如备份、监控）需要自己搭
  • 适用：中小团队，数据量100万-1000万，需要快速上线

Milvus：

  • 优势：分布式能力强，支持十亿级向量，有完善的管理界面和监控，国内社区活跃
  • 劣势：部署复杂，资源占用高，小项目用有点杀鸡用牛刀
  • 适用：大企业、数据量>1000万、需要高可用

Pinecone：

  • 优势：完全托管，不用运维，开箱即用，性能稳定
  • 劣势：贵，而且数据在云端，有合规风险
  • 适用：海外业务、不想自己运维的团队

我们的选型逻辑：

  • 初创项目：Chroma快速验证
  • 中型项目（<1000万向量）：Qdrant，性能和易用性平衡最好
  • 大型项目（>1000万）：Milvus，或者直接用云服务的向量检索（如阿里云OpenSearch）
  • 如果是To B项目，客户要求数据不出内网，那就只能选开源方案自己部署

【面试题】6. 如何设计一个高质量的系统提示词？有哪些进阶技巧可以避免模型"忘记"指令？ ​

【标准答案】 系统提示词是Agent的"灵魂"，设计不好模型就容易"忘记"指令或者输出乱七八糟。我总结几个实战技巧：

基础结构：

  1. 角色定义：明确Agent是谁，做什么，比如"你是一个电商客服助手，负责处理用户的订单查询、退换货请求"
  2. 任务描述：分步骤写清楚，别写一大段，用"1. 2. 3."或"- "列表
  3. 输出格式：明确要求JSON、Markdown还是纯文本，给example
  4. 约束条件：什么能做，什么不能做，比如"不要泄露用户隐私""不确定时别说谎，告诉用户你不知道"

进阶技巧：

1. 分层提示词

  • 把系统提示词分成"核心指令"和"参考信息"
  • 核心指令（角色、任务、输出格式）放在最前面，而且用【重要】或***标记
  • 参考信息（背景知识、工具说明）放在后面，模型更容易记住前面的内容

2. 重复关键信息

  • 如果某个指令特别重要，在system prompt开头说一次，结尾再说一次
  • 比如"无论什么情况，都不要泄露用户隐私"，开头强调一次，工具调用说明后再强调一次

3. 用Few-shot示例

  • 文字描述不如示例直观，给2-3个输入输出的例子
  • 特别是边缘场景，比如"用户问'你们老板是谁'，你要回答'我是AI助手，没有老板'"

4. 动态注入

  • 别把所有信息都写死在system prompt里，根据对话动态注入
  • 比如用户问订单问题，再把订单查询的工具说明注入进去，减少干扰

5. 定期"提醒"

  • 在长对话中，模型容易忘记初始指令，可以在每5轮对话后，自动插入一条"提醒"
  • 比如"[系统提示：你是一个客服助手，保持礼貌和专业]"

避坑指南：

  • 别写太长，超过3000字的system prompt，模型很容易"遗忘"中间的内容
  • 别用否定句，说"不要做X"不如说"应该做Y"
  • 别假设模型懂你的业务，该解释的要解释，比如"SKU是指库存量单位"

【面试题】7. 智能体的记忆系统如何设计？短期记忆、长期记忆、工作记忆分别怎么实现？ ​

【标准答案】 记忆系统是智能体的核心能力之一，我们一般分三层设计：

短期记忆（对话上下文）：

  • 实现：直接用LLM的context window，把最近N轮对话拼接到prompt里
  • 优化：如果对话很长，用滑动窗口（保留最近20轮）+ 摘要（对更早的对话做总结）
  • 我们用的策略：每10轮对话触发一次摘要，把之前的对话压缩成3-5句话

工作记忆（当前任务状态）：

  • 实现：用结构化数据存储在Redis或内存里，比如"当前正在处理用户的订单查询，已获取订单号12345，等待用户确认"
  • 关键：要能支持多轮对话中的状态追踪，比如用户说"帮我查一下订单"，你查了，然后用户说"帮我取消这个订单"，你要知道"这个订单"指的是刚才查的那个
  • 实现方式：在每次工具调用后，把关键结果存到工作记忆里，下一轮对话时取出来

长期记忆（跨会话的知识）：

  • 实现：用向量数据库存储，把用户的历史对话、偏好、重要信息做embedding，需要时检索
  • 更新策略：不是所有对话都要存，只存"有价值"的信息，比如用户的偏好（"我喜欢科幻小说"）、重要决策（"用户决定购买产品A"）
  • 检索策略：在每次对话开始时，根据用户输入检索相关记忆，注入到prompt里
  • 我们用的方案：用Qdrant存长期记忆，每次对话开始时检索Top3相关记忆，拼到system prompt里

踩过的坑：

  1. 短期记忆别塞太满，我们一开始把最近50轮对话都塞进去，结果超token限制，后来改成动态摘要
  2. 长期记忆的检索别太激进，不是每次都要检索，只有当用户输入明显需要历史信息时才检索（比如"我上次问的那个问题"）
  3. 记忆要去重，不然会出现"我记得我喜欢科幻，我也记得我喜欢科幻，我还记得..."这种冗余

开源方案参考：

  • LangChain的Memory模块（适合快速上手）
  • MemGPT（专门做记忆管理的框架）
  • 自研：我们用Redis存短期+工作记忆，Qdrant存长期记忆，效果不错

【面试题】8. 多智能体协作时，如何设计通信机制和任务分配策略？有哪些常见的协作模式？ ​

【标准答案】 多智能体协作是个复杂问题，我们之前用CrewAI和LangGraph做过几个项目，总结一下经验：

通信机制设计：

1. 中心化 vs 去中心化

  • 中心化：有个"管理员"Agent，负责分配任务、汇总结果。好处是可控，坏处是管理员成为瓶颈
  • 去中心化：Agent之间直接通信，用消息队列或共享状态。好处是灵活，坏处是容易混乱
  • 推荐：中小规模用中心化（CrewAI的hierarchical process），大规模才考虑去中心化

2. 通信协议

  • 别自己设计，用成熟的：CrewAI的Agent通信、LangGraph的State Graph
  • 如果必须自己写，用JSON格式，定义清楚：{"from": "agent_A", "to": "agent_B", "type": "task", "content": "...", "expect_reply": true}

任务分配策略：

1. 按能力分配

  • 每个Agent有自己的"技能树"，管理员根据任务类型匹配最合适的Agent
  • 比如"写代码"分配给Coder Agent，"做测试"分配给QA Agent

2. 按负载分配

  • 如果多个Agent都能做同一个任务，选当前负载最低的
  • 需要实现心跳机制，Agent定期上报自己的状态（空闲/忙碌/离线）

3. 动态调度

  • 别一次性分配所有任务，根据中间结果动态调整
  • 比如"做竞品分析"，先分配给Research Agent，它完成后发现需要爬取数据，再动态分配给Crawler Agent

常见协作模式：

1. 流水线模式（Pipeline）

  • Agent A → Agent B → Agent C，每个Agent负责一个环节
  • 适合：流程固定的任务，比如"文章生成→润色→配图"

2. 评审模式（Review）

  • Agent A生成结果，Agent B评审，提修改意见，Agent A再修改
  • 适合：对质量要求高的场景，比如代码生成、文案创作
  • 我们之前做代码生成，用"Writer + Reviewer"模式，bug率降低40%

3. 辩论模式（Debate）

  • 多个Agent从不同角度分析问题，最后投票或汇总
  • 适合：需要多角度思考的任务，比如投资决策、方案评估

4. 专家咨询模式

  • 主Agent遇到专业问题时，临时请教专家Agent
  • 适合：主Agent是通用助手，但需要专业知识的场景

避坑指南：

  1. 避免死循环：Agent A让Agent B做，Agent B又让Agent A做。要设置最大交互次数（比如5次）
  2. 上下文传递：Agent之间传递信息时，别只传结论，要传"思考过程"，不然下一个Agent会丢失关键信息
  3. 错误隔离：一个Agent失败了，别让整个流程崩掉，要有降级策略（比如换一个Agent，或者人工介入）

【面试题】9. 从0到1搭建一个AI智能体项目，关键步骤有哪些？如何快速验证MVP？ ​

【标准答案】 这个问题很实战，我之前从0到1搭过3个Agent项目，总结一下流程：

第一阶段：需求分析和方案设计（1-2天）

  1. 明确边界：这个Agent要解决什么问题？做到什么程度？

    • 别一上来就想做"万能助手"，先聚焦一个具体场景，比如"电商客服"就比"智能助手"靠谱
    • 输出：用一句话描述，"这是一个XXX，能够帮助用户完成XXX"

  2. 技术选型：

    • LLM：先用成熟的（GPT-4/Claude），别一上来就用开源模型，等验证完再考虑降本
    • 框架：LangChain（生态好）、CrewAI（多Agent友好）、Dify（低代码，适合快速上线）
    • 工具：需要哪些外部API？提前列清楚

  3. 原型设计：画一下用户交互流程，比如"用户输入→Agent推理→调用工具→返回结果"，有哪些分支？

第二阶段：MVP开发（3-5天）

  1. 先跑通主流程：别追求完美，先把"happy path"跑通

    • 比如做客服Agent，先能回答"查订单"这一个问题，别一上来就支持所有功能
    • 用hard-coded的示例数据，别一上来就接真实API

  2. 工具集成：逐个接入外部工具，每个工具写清楚description和参数

    • 建议：先mock工具返回，验证Agent能正确调用，再接真实API

  3. Prompt迭代：这是最花时间的，要不断调优

    • 准备10-20个真实用户问题，测试Agent的回答
    • 记录badcase，针对性优化prompt

第三阶段：测试和优化（2-3天）

  1. 边界测试：问一些Agent应该拒绝的问题，看它会不会"越界"

    • 比如客服Agent，问它"你帮我写个代码"，它应该拒绝或者转人工

  2. 性能测试：测一下响应时间、成功率

    • 如果响应时间>5秒，要考虑优化（比如换更快的模型、减少工具调用次数）

  3. 成本估算：算一下每个对话的平均成本，看能不能接受

第四阶段：上线和监控

  1. 灰度发布：别全量上线，先给10%用户用，收集反馈
  2. 监控：重点监控"工具调用失败率""响应时间""用户满意度"
  3. 快速迭代：前两周每天看badcase，快速优化

快速验证MVP的核心原则：

  • 别追求完美：MVP的目标是"验证可行性"，不是"交付完美产品"
  • 用真实数据测试：别只用理想化的测试用例，要找真实用户问真实问题
  • 控制范围：第一个版本只解决核心问题，边缘场景可以后续迭代

我们的一次实战：

  • 项目：AI简历筛选助手
  • MVP周期：5天
  • Day 1-2：用GPT-4 + LangChain，跑通"上传简历→解析→匹配岗位"的流程
  • Day 3-4：接入真实简历（10份），测试效果，发现解析准确率只有70%，优化prompt
  • Day 5：给HR同事试用，收集反馈，发现"匹配理由"不够详细，加了一版
  • 结果：MVP验证成功，准确率提升到85%，继续迭代

【面试题】10. Agent调用链很长，中间某一步失败了，如何设计重试、降级和兜底机制？ ​

【标准答案】 长调用链的错误处理是个工程难题，我们之前做过一个"智能投研Agent"，调用链有"意图识别→数据查询→数据分析→报告生成"四步，中间任何一步失败都会影响最终结果。总结一下我们的方案：

1. 分层错误处理

工具调用层：

  • 重试策略：网络超时、临时错误，自动重试3次，用指数退避（1秒、2秒、4秒）
  • 参数校验：调用工具前先校验参数合法性，不合法的直接让LLM重新生成，别等到调用时才报错
  • 超时控制：每个工具调用设置超时时间（比如10秒），超时就中断

Agent推理层：

  • 输出校验：LLM的输出可能不符合预期（比如要求JSON但返回了文本），用Pydantic模型校验，不通过就让LLM重新生成（最多2次）
  • Fallback模型：主模型（GPT-4）调用失败时，自动降级到备用模型（GPT-3.5或Claude）

任务层：

  • 断点续传：如果多步骤任务中间失败了，别让用户重新来，记录每步的中间结果，失败后从最近的成功步骤继续
  • 比如"查数据→分析→生成报告"，如果"分析"这步失败了，下次可以从"分析"开始，不用重新查数据

2. 降级策略

功能降级：

  • 主功能不可用时有替代方案
  • 比如"智能推荐"功能依赖用户行为数据，如果数据查询失败，降级到"热门推荐"

模型降级：

  • GPT-4失败→GPT-3.5→规则引擎（if-else）
  • 我们设计的降级链：顶级模型 → 中级模型 → 简单规则，确保至少有响应

数据降级：

  • 精排数据不可用，用粗排数据
  • 实时数据不可用，用缓存数据（标注"数据可能延迟"）

3. 兜底机制

兜底回复：

  • 所有方案都失败了，别返回技术错误（"500 Internal Server Error"），返回友好的提示
  • 比如"抱歉，我暂时无法处理您的请求，已记录问题，人工客服会尽快联系您"
  • 同时要把错误信息、用户输入、调用链记录到日志，方便排查

人工介入：

  • 如果Agent连续失败3次，或者用户明确说"转人工"，就转到人工客服
  • 实现方式：在Agent的响应里加个flag，比如{"need_human": true, "reason": "连续3次工具调用失败"}

4. 监控和告警

  • 关键指标：工具调用失败率、Agent推理失败率、降级触发次数
  • 实时告警：失败率超过10%，或者降级触发超过5次/分钟，就告警
  • Badcase分析：每次失败后，把上下文、错误信息、最终处理方式记录到数据库，定期分析

核心原则：

  • 快速失败：别让用户等太久，超时就有降级方案
  • 优雅降级：主方案不行，至少有Plan B、Plan C
  • 记录一切：每次失败都要记录，方便后续优化
  • 用户体验优先：技术细节别暴露给用户，返回友好的提示

总结 ​

以上10道面试题覆盖了：

  • 技术基础（LLM评估、工具调用）
  • 架构设计（单/多智能体选型、记忆系统）
  • 工具使用（RAG优化、向量数据库选型）
  • 项目落地（从0到1搭建、MVP验证）
  • 场景实操（多智能体协作、错误处理）
  • 面试情景问答（系统设计、踩坑经验）

每道题的答案都注重实战经验，避免纯理论堆砌，符合1-3年经验岗位的面试要求。