AI智能体应用开发面试题（2026-06-16）
适用岗位：1-3年 AI应用开发 / Agent开发 题型覆盖：技术基础、架构设计、工具使用、项目落地、场景实操、面试情景问答
【面试题】1. 调用大模型API时，Token用量失控是最常见的问题。你们项目里是怎么做Token成本控制和请求的降本优化的？
【标准答案】我们主要从四个方向入手。第一，输入侧做截断和压缩，长上下文先走摘要再入Prompt，历史消息用滑动窗口只保留最近N轮。第二，输出侧加max_tokens硬上限，避免模型自由发挥刷爆额度。第三，缓存复用，OpenAI和Kimi都支持Prompt Caching，系统提示和长文档哈希命中后价格直接打一折，这个一定要开。第四，模型分级，简单任务用小模型，只有复杂推理才上主力模型，我们内部有个路由层按任务难度自动分发。整体下来Token成本能压掉60%以上。
【面试题】2. ReAct和Plan-and-Execute两种智能体推理框架，各自适合什么场景？你们是怎么选的？
【标准答案】ReAct是一步一步走，每步都反思再决定下一步，适合任务路径不确定、需要动态决策的场景，比如客服、搜索问答，优势是灵活可控，劣势是步数多、延迟高、成本高。Plan-and-Execute是先做完整规划再分步执行，适合任务结构清晰、步骤可预知的场景，比如数据分析Pipeline、报告生成，优势是可控性强、可以提前校验计划，劣势是规划错了后面全歪。我们实际项目里是两个都用了，先Plan生成任务DAG，执行过程中每个节点内部用ReAct做动态调整，相当于两层的混合架构。
【面试题】3. 多智能体协作时，消息传递和任务交接是最容易出bug的地方。你们是怎么设计Agent之间的通信协议的？
【标准答案】核心是三件事：结构化输出、状态机管理、超时与重试。每个Agent的输出必须是对应的JSON Schema，不能让下游去解析自然语言，这是最稳的。然后我们有一个中心化的任务状态管理器，记录每个子任务的status、结果、错误信息，Agent之间不直接点对点通信，而是通过状态管理器交接，这样任何一个Agent挂了都能被重新拉起。最后是每个环节都加超时，默认30秒，超时后触发降级策略或者直接报错，不能让整个链路卡死。用CrewAI的话它内置了这种机制，自己写的话建议直接用LangGraph的StateGraph，别自己造轮子。
【面试题】4. RAG系统上线后，用户反馈"搜不准""答非所问"，你从哪些维度排查和优化？
【标准答案】我一般按这个顺序排查。先看召回层：用Bad Case的真实query去查，是不是切分粒度有问题，chunk太大或太小都不行，我们一般256-512token一个chunk，重叠20%。再看Embedding模型：中文场景一定要用中文优化的模型，不要用OpenAI的ada硬上中文，bge-large-zh或者text2vec效果差很多。然后看检索策略：单纯向量检索不够，要混合检索，向量+关键词+BM25三个路融合，再按RRF重排序。最后是生成层：把召回的上下文显式拼进Prompt让用户能看到，很多"答非所问"其实是上下文没召回对，不是生成的问题。整个链路要可观测，每步都有日志，才能定位到底是哪一层的问题。
【面试题】5. LangChain、CrewAI、Dify三个框架，你们选型时是怎么考虑的？各自优劣势是什么？
【标准答案】LangChain生态最全，灵活度最高，适合需要深度定制、复杂Agent逻辑的场景，但抽象层太厚，调试不方便，新手容易写出性能很差的代码。CrewAI专注多智能体协作，概念清晰，Process串行/并行好用，适合多角色配合的任务，但生态比LangChain小，自定义工具要自己写适配。Dify是低代码平台，可视化工作流编排，产品、运营都能上手改流程，适合快速交付和业务迭代，但复杂逻辑受平台限制，深度定制要写外部工具接入。我们现在的策略是：原型验证和快速交付用Dify，复杂Agent逻辑用LangChain/LangGraph，多Agent协作用CrewAI或LangGraph的multi-agent，三个场景分开，不强行统一。
【面试题】6. 智能体的"记忆系统"有哪几种实现方式？长短期记忆分别怎么设计比较合理？
【标准答案】短期记忆就是当前会话的context，最简单是最近N轮消息全带上，进阶做法是用摘要压缩，每5轮自动摘要一次历史，只保留摘要+最近2轮详情。长期记忆有两种主流实现：向量数据库存储和结构化档案。向量数据库适合"回忆类"查询，用户说过什么相关的内容，语义检索出来拼进Prompt；结构化档案适合"属性类"信息，比如用户的偏好、历史行为标签，直接作为结构化字段存在数据库里，命中后整体注入Prompt。我们项目里是两套并用，向量库负责"记"，结构化档案负责"懂"，配合起来长期记忆的效果比较稳。还有一个工程细节：长期记忆的写入要异步，不能阻塞主流程响应。
【面试题】7. Function Calling（工具调用）时，模型返回的参数经常不规范，导致工具执行失败。你们是怎么处理这个问题的？
【标准答案】这个问题我们踩过坑，核心解法分三层。第一层是Prompt层，在工具描述里加严格的参数说明和示例，特别是必填参数加"REQUIRED"标注，能减少60%以上的参数错误。第二层是解析层，模型返回的工具调用先做JSON Schema校验，参数缺失或类型不对，不直接报错，而是把错误信息拼回给模型让它修正，一般重试1-2次就能修好。第三层是兜底层，关键工具要有默认参数，非关键参数缺失时用默认值补齐，保证流程能继续走。我们还有一个小技巧：把工具调用的历史成功案例存下来，遇到类似query时作为few-shot示例拼进Prompt，模型学得快，参数准确率明显提升。
【面试题】8. 你做一个智能体项目从0到1，完整的流程是什么？每个阶段你们最关注什么指标？
【标准答案】分五个阶段。第一阶段是需求拆解，把业务目标翻译成Agent的能力边界和工具清单，这个阶段最关注的是"是不是真的需要Agent"，很多规则引擎能搞定的事别硬上Agent。第二阶段是原型验证，用最少的代码把核心链路跑通，关注端到端成功率，不管性能，先能跑通。第三阶段是迭代优化，加RAG、加记忆、调Prompt，关注准确率和召回率，同时开始压成本。第四阶段是工程化，加监控、加日志、加降级，关注P95延迟、可用性、Token成本。第五阶段是上线运营，关注用户满意度、Bad Case数量和迭代速度。每个阶段关注的核心指标不一样，千万别在第一阶段就去优化P95延迟，那是第四阶段的事。
【面试题】9. 智能体 workflow 编排，用代码写还是用可视化平台（如Dify/n8n）？你们是怎么权衡的？
【标准答案】核心权衡点是"变更频率"和"逻辑复杂度"。业务逻辑经常变、需要产品运营自己改的，用可视化平台，Dify或Coze，改流程不用发版，迭代速度快。逻辑复杂、需要深度定制、性能要求高的，用代码写，LangGraph或CrewAI，完全可控。我们现在的实践是：前端流程、多模态输入输出这些用Dify拖，底层复杂的推理链、多Agent协作逻辑用LangGraph写，然后封装成Dify的一个"工具节点"接进去，相当于可视化编排管流程，代码管核心逻辑，两边各自发挥优势。这样产品和研发都能各司其职，不用抢着改同一个文件。
【面试题】10. 智能体项目上线后，你是怎么做监控和数据闭环的？具体来说，哪些数据是你必须收集的？
【标准答案】必须收集的数据有四类。第一类是链路日志：每轮的输入、输出、工具调用记录、耗时、Token消耗，这是排查问题的基础。第二类是业务指标：端到端任务成功率、人工介入率、用户满意度评分，这是衡量产品价值的核心。第三类是Bad Case：用户点"不好"或者任务执行失败的样本，自动入库，每周Review，这是迭代的主要来源。第四类是成本数据：每个用户的Token消耗、按工具拆解的成本，用来发现异常使用和成本泄漏。我们搭了一个简单的标注平台，Bad Case自动流入，标注完后变成评测集，每次模型或Prompt更新都先跑一遍评测集，通过才上线，这个数据闭环跑通后，模型效果是有保障的。
生成时间：2026-06-16 00:10
题目数量：10道（不重复，覆盖1-3年岗位核心考点）