AI智能体应用开发面试题
生成时间：2026-06-12 01:40
【面试题】1. 大模型上下文窗口越来越长，32K、128K甚至1M都有，你在实际项目中是怎么处理长上下文的？有什么优化经验？
【标准答案】
长上下文处理有三条主线：
一是输入阶段做截断+摘要。 不会傻傻地把整本书塞进去。一般先做语义分块（按段落或语义边界切），再根据query做召回，最后对召回结果做摘要压缩。我的经验是保留核心实体和关键事件，冗长描述直接删。
二是利用滑动窗口+记忆机制。 比如处理长文档对话，用滑动窗口保留最近N轮对话作为短期记忆，重要信息抽取到长期记忆（结构化知识）。这样既不超出窗口，又能记住关键上下文。
三是分层检索。 先用轻量模型做意图分类，决定走哪个检索路径；再对不同内容做差异化处理——代码类用结构化方式保留，多轮对话用摘要+关键实体方式保留。
核心就一句话：不要依赖模型自己"看完"，要让模型"看到该看的"。
【面试题】2. 如果让你设计一个多智能体协作系统来完成复杂任务拆解，你会怎么设计架构？Agent之间怎么通信？
【标准答案】
我会用「编排层+执行层」分层架构：
编排层负责任务分发和流程控制，类似导演。可以是状态机、工作流引擎，或者一个专门的Planner Agent。核心职责是把大任务拆成子任务，分发给对应执行Agent，收集结果后再决策下一步。
执行层是具体干活的Agent，每个Agent专注单一能力——比如查资料Agent、写代码Agent、审核Agent。执行Agent之间不直接通信，都通过编排层中转。
通信方式分两种场景：
- 同步协作：Planner直接调用子Agent，像函数调用一样等返回结果，适合串行依赖的任务
- 异步协作：用消息队列或共享状态池，Agent把结果写进去，其他Agent按需消费，适合可以并行执行的子任务
关键设计点：统一的消息格式（结构化输出）、Agent能力注册表、调用超时和重试机制、结果校验层。
简单说就是：一个导演、多专工、各司其职、导演统筹。
【面试题】3. Dify和CrewAI都支持工作流编排，它们的核心差异是什么？什么场景下你会选择Dify，什么场景选CrewAI？
【标准答案】
核心差异是面向对象不同：
Dify是低代码平台，面向业务人员和非专业开发者。拖拽画布配置节点，可视化程度高，内置丰富的节点类型（LLM、代码执行、HTTP调用、条件分支等），可以直接导出API服务。适合快速搭原型、简单业务流程、运营人员自己能改的场景。
CrewAI是代码优先框架，面向开发者。用Python写Agent定义和任务流程，天然融入开发工作流，更灵活但需要编码。适合复杂Agent逻辑、需要深度定制、或者想和现有系统集成的场景。
选择逻辑：
- 团队有开发能力，要深度定制 → CrewAI
- 快速交付，运营也要能改流程 → Dify
- 需要本地部署，数据敏感 → Dify（开源可私有化）
- 多Agent复杂协作逻辑 → CrewAI（代码可控）
实际上很多团队是Dify做简单流程、CrewAI做复杂逻辑，或者Dify调用CrewAI实现的Agent，两者是互补关系。
【面试题】4. 你在做RAG项目时，遇到过召回结果不准确的问题吗？怎么解决的？
【标准答案】
RAG召回不准一般三个原因，我逐个说解法：
原因一：语义不匹配。 query说"公司去年Q3营收"，但文档写的是"第三季度收入"，embedding空间里距离远。
解法：HyDE（假设性文档生成）+ query改写。先让模型根据query生成一个"理想答案"的假设文档，再用这个去召回，语义对齐效果明显好很多。
原因二：分块策略不对。 按固定字数切，语义被切断，关键信息分散在不同块里。
解法：按语义切分（段落と见出し）优先，结合重叠滑动窗口。代码类文档按函数/类切，知识库类按主题段落切。
原因三：向量检索的top-k不够或太多。
解法：不是固定top-5，而是做动态召回——先用关键词BM25粗召回、再用向量精召回，两者取并集或重排。也可以加上下文压缩，把无关的冗余内容删掉再喂给LLM。
核心思路：召回阶段尽量多拿相关片段，生成阶段严格筛选+压缩。
【面试题】5. 写一个Agent的提示词时，"系统提示词"和"用户消息"有什么区别？你怎么设计让Agent行为更稳定？
【标准答案】
本质区别：系统提示词是"宪法"，定义Agent的身份、能力边界、行为准则；用户消息是"具体任务"。
系统提示词是跨对话持久生效的，用户消息每轮会变。
让Agent行为稳定的几个关键设计：
一、角色定义要具体。 不要只写"你是一个助手"，要写清楚：是什么领域的、输出格式是什么、什么不能做。比如"你是金融分析助手，只处理投资相关问题，输出必须包含数据来源，禁止编造数字"。
二、输出格式强约束。 用XML标签、JSON schema、或者Few-shot示例固定输出结构。Agent按格式输出的稳定性远高于自由生成。
三、Chain-of-Thought内置。 在提示词里写清楚推理步骤，让Agent"先思考再回答"，特别是复杂任务。
四、边界条件要明确。 遇到什么问题该反问、什么情况该拒绝、什么算不知道——都要写清楚，不能只靠模型"自己理解"。
五、Few-shot很重要。 给出2-3个正例和1个反例，比长篇文字描述有效得多。
【面试题】6. 情景题：面试官问你“你们项目中Agent出错了怎么处理？有没有遇到Agent跑飞的情况？”
【标准答案】
坦诚说，有遇到过，主要是早期调优阶段。
我们当时的处理机制：
第一层：输入校验。 用户输入进来先过校验层——危险操作拦截（删数据、发消息）、格式校验、超长截断。这一层挡住大部分异常输入。
第二层：执行监控。 Agent调用有超时控制（一般30秒），超时不等待直接降级。同时记录每次调用的输入输出日志，出问题可以回放。
第三层：结果校验。 不是把Agent输出直接给用户，而是过一层校验——格式校验、内容安全校验（比如涉政涉黄）、关键字段完整性校验。校验不通过就走兜底逻辑。
第四层：兜底策略。 Agent失败或者校验失败，优先返回友好提示+建议操作，而不是空结果或报错。如果涉及关键业务流程，有人工介入通道。
Agent跑飞的问题——早期遇到过Agent自己扩写任务、无限循环的情况。后来加了任务边界控制：单次任务最大步数限制、敏感操作二次确认、每个工具调用前检查是否在计划范围内。
核心就是：不要完全信任Agent输出，层层设卡，及时兜底。
【面试题】7. 向量数据库你们用的什么？Milvus、Pinecone还是Chroma？选型依据是什么？
【标准答案】
我们线上用Milvus，轻量场景用Chroma。
选型看三个维度：
数据规模。Chroma适合几千到几万条，数据量大了性能明显下降。Milvus适合百万级以上的生产环境，支持分布式、能水平扩展。
部署方式。如果需要私有化部署、数据不出网，Milvus开源版完全OK。Pinecone是云服务，省运维但数据要上云。
功能需求。Milvus支持混合检索（向量+标量过滤）、支持GPU加速、成熟度高。Pinecone生态好、和OpenAI配合丝滑，但成本高。
实际建议：
- 个人项目/小规模/快速验证 → Chroma（零配置）
- 企业级/大数据量/私有化 → Milvus
- 不差钱想省心/云原生 → Pinecone
我们选Milvus是因为数据量大需要分片、也有GPU服务器，再加上团队有运维能力。如果是小团队快速起步，我建议Chroma起步够了，别过度架构。
【面试题】8. 怎么理解Agent的"记忆系统"？短期记忆、长期记忆、上下文记忆分别怎么实现？
【标准答案】
三个层次，解决不同问题：
上下文记忆——就是当前对话窗口内的所有消息。最简单，直接塞进prompt里。但窗口有限，不能无限累积。
短期记忆——当前任务周期内的信息。比如用户问"帮我分析竞品"，短期记忆就是分析过程中用到的竞品数据、分析结论。用完即弃。实现方式：对话摘要（每N轮做一次小结）、滑动窗口（只保留最近几轮）。
长期记忆——跨会话积累的重要信息。比如用户偏好、历史交互的关键结论、常用工作流程。实现方式：
- 结构化存储：用户画像、偏好配置表，存在数据库
- 向量召回：把历史对话切片向量化，按query召回相关记忆
- 知识图谱：实体关系存储，适合复杂关联信息
实践中常用的组合：
用户输入 → 检索长期记忆 → 合并到上下文 → Agent处理 → 结果摘要写入短期记忆 → 重要结论同步到长期记忆关键点：记忆是分层的，不同层次用不同的存储和检索方式，不要一股脑全塞进prompt。
【面试题】9. 你在项目中怎么实现Tool Calling？有哪些坑是新手容易踩的？
【标准答案】
实现层面，主流框架都封装好了，核心是工具定义要规范：
{
"name": "查询库存",
"description": "查询指定商品的当前库存数量",
"parameters": {
"type": "object",
"properties": {
"product_id": {"type": "string", "description": "商品ID"}
},
"required": ["product_id"]
}
}description是给模型看的，必须写得清楚、明确、好理解，模型是根据description决定是否调用这个工具的。
新手容易踩的坑：
坑1：工具定义太模糊。 description写"查询信息"这种，模型根本不知道什么时候该调。必须写清楚输入输出是什么、适用什么场景。
坑2：参数校验不及时。 模型可能传错参数类型或缺失必填字段。一定要在工具执行前做校验，不能假设模型一定传对。
坑3：工具返回太冗长。 原始数据库查询结果直接返回，噪声太多。加一层结果压缩/格式化再返回。
坑4：缺少工具调用限制。 Agent可能反复调用同一个工具或无限循环。加最大调用次数限制。
坑5：工具执行没有超时。 外部API慢或挂掉，Agent卡住。每个工具调用都要设超时+重试+降级。
【面试题】10. 如果让你从零开始搭建一个企业级Agent应用，你会怎么规划？先做什么后做什么？
【标准答案】
分四个阶段，核心原则是：小步快跑、验证驱动。
阶段一：明确场景和评估指标（最关键） 先想清楚：Agent帮谁做什么？成功的标准是什么？是提高效率（节省多少时间）？还是提高质量（准确率提升多少）？还是扩大规模（能处理多少请求）？指标不清楚，后面都是盲人摸象。
阶段二：最小可行原型（快速验证） 选一个核心场景，用最简单的方式跑通全流程——Prompt + 基础工具 + 少量样例数据。目标是跑通，不是做漂亮。能work再往下走，work不了及时止损。
阶段三：工程化和可靠性
- 记忆系统
- 错误处理和兜底
- 日志和监控
- 安全边界 这个阶段占工作量的大头，很多团队低估了这个阶段的复杂度。
阶段四：迭代优化
- 分析bad case，针对性优化
- 补充训练数据或微调
- 性能优化（召回速度、响应延迟）
- 扩展更多场景
关键原则：
- 先跑通再优化，别一开始就搞复杂架构
- 每个阶段都输出可用的东西，不是憋大招
- 监控先行，上线前就想好怎么看效果
本题库由 AI 面试题生成器 自动生成 覆盖范围：技术基础、架构设计、工具使用、项目落地、场景实操、面试情景问答