AI智能体应用开发面试题

生成时间：2026-06-15 22:45

【面试题】1. 智能体的流式输出（Streaming）怎么实现？为什么生产环境必须用流式？有哪些工程细节？

【标准答案】生产环境必须用流式，核心原因就两个：体感和超时。大模型生成一个完整回答可能要5-10秒，用户盯着空白页面会以为挂了；流式可以让第一个token在200ms内就渲染出来，体感延迟从"秒级"降到"毫秒级"。实现上，SSE（Server-Sent Events）是最主流的方案——服务端和LLM之间用流式API，逐chunk推给前端，前端用EventSource或fetch+ReadableStream消费。工程细节有三个：第一，token边界对齐——模型返回的是token片段，可能把一个中文字拆成两半，需要做UTF-8边界修复；第二，工具调用时需要"暂停流式"——Agent在推理过程中决定调工具，此时不能把思考过程流给用户，要等工具结果回来再继续流式输出最终答案；第三，异常处理——流式中途断连要能恢复，我们一般在断点记录已发送的token数，重连后从上次位置续传。另外还有个坑：Nginx默认有buffering，流式请求会被缓冲，必须加X-Accel-Buffering: no头或者关掉proxy_buffering。

【面试题】2. 你怎么理解"Agentic Workflow"和"Autonomous Agent"的区别？实际项目中如何选择？

【标准答案】核心区别是"控制权在谁手里"。Agentic Workflow是人定义流程节点和分支条件，模型只在节点内做决策，像流水线工人；Autonomous Agent是模型自己决定下一步干什么，像自由职业者。选型看三个维度：第一，任务确定性——流程固定、步骤可预知的用Workflow，比如"先查库再校验再生成报告"；任务开放、路径不确定的用Autonomous Agent，比如"帮我调研竞品并给建议"。第二，容错要求——Workflow每步都有预期输出，错了容易定位和重试；Autonomous Agent跑飞了你可能都不知道，所以高风险场景（涉及钱、涉及用户数据操作）优先用Workflow加人工审批节点。第三，成本敏感度——Autonomous Agent的token消耗不可控，可能一个问题跑10轮工具调用；Workflow路径固定，成本可预估。实际项目中，大部分是混合态：主流程用Workflow编排，某些节点内部放一个Autonomous Agent做灵活决策。Dify的工作流模式就是典型的Workflow+节点内Agent，LangGraph也支持在图节点里嵌套Agent做子任务。

【面试题】3. RAG系统中，如何处理"用户问题需要跨多个文档综合才能回答"的场景？

【标准答案】这是RAG的经典难题，单次检索很难一步到位。我的方案是分层处理：第一层，查询改写——把用户问题拆解成多个子查询并行检索。比如"比较A和B的退货政策"，拆成"退货政策A"和"退货政策B"两次检索，再把结果合并。这叫Query Decomposition，效果提升明显。第二层，递归检索——第一轮检索回来后，让模型判断信息是否充分，如果不充分，自动生成追问query再检索一轮。类似DeepRM的思路，一般2-3轮就够了。第三层，父文档策略——检索时用小chunk提高命中率，但取回时带出整个文档或大chunk，这样模型能看到完整上下文，减少信息碎片化。第四层，如果文档间有结构关系（比如同一产品的不同章节），用GraphRAG把实体关系建起来，检索时沿关系边扩展。最后还有个工程trick：如果判断出是跨文档问题，直接把问题路由给"深度分析模式"，调更长的context窗口模型，把多文档丢进去让模型综合，这比反复检索更稳。实际业务中，第一层和第二层组合就能覆盖80%的场景，投入产出比最高。

【面试题】4. 在Agent开发中，你如何设计"人工介入（Human-in-the-loop）"机制？什么环节必须加人工审批？

【标准答案】Human-in-the-loop不是锦上添花，是生产环境的保命机制。设计上分三种模式：第一，审批模式——Agent执行到关键节点暂停，等人工确认后才继续。比如涉及退款、修改用户数据的操作，必须过人工。实现上，我们在LangGraph里用interrupt节点，状态序列化到数据库，等人工通过API/Webhook恢复执行。第二，监督模式——Agent正常跑，但关键操作自动通知人工，人工可以在事后 veto。适合时效性要求高但风险中等的场景，比如自动发邮件，抄送给人看。第三，纠偏模式——Agent跑出结果后，人工可以打分或修改，反馈回记忆系统，下次自动优化。这是最轻量的，适合内容生成类场景。必须加人工审批的环节：一是写操作（修改数据库、调用支付接口、发送外部消息），二是不可逆操作（删除数据、执行shell命令），三是模型置信度低于阈值的决策。实现细节上有个关键点：审批不能阻塞Agent的整个进程，否则一个审批卡住，后续任务全停。我们的做法是审批节点释放worker线程，把状态持久化，审批回调时恢复上下文继续执行。

【面试题】5. 你做过的Agent项目中，Prompt是怎么做版本管理的？多人协作时怎么避免互相覆盖？

【标准答案】Prompt就是代码，必须当代码管。我们用的是"Prompt as Code"方案：所有Prompt存在代码仓库里，用Jinja2模板引擎管理，变量用｛｛ ｝｝占位，和环境配置分离。版本管理三板斧：第一，Git管理——每个Prompt一个文件，目录按Agent/场景组织，commit message必须写明改了什么、为什么改、效果如何。第二，A/B测试——改Prompt不是直接替换线上，而是在配置中心开实验组，新旧Prompt同时跑，对比准确率、用户满意度等指标，确认新版本更好再全量切。第三，回滚机制——配置中心保留最近N个版本，一键回滚，30秒生效。多人协作的关键是"评审制"：Prompt修改必须走PR，至少一个人Review，重点看有没有引入安全漏洞（比如Prompt注入风险）和性能退化（比如token数暴涨）。还有一个实战经验：Prompt变更后必须跑回归测试集——我们维护了200+标注好的QA对，每次改Prompt都跑一遍，看通过率有没有掉。这套机制让我们在5个人协作的场景下，Prompt修改从"经常出事"变成了"基本不出事"。

【面试题】6. 你怎么实现Agent的"渐进式加载"——用户提问后先给快速答案，再逐步补充详细信息？

【标准答案】这个需求在搜索和问答场景特别常见，用户不想等完整的深度分析，要先给个快的。我的方案是"快慢双路"：快路走轻量模型（比如GPT-4o-mini）或者纯检索+模板生成，500ms内出个概要答案；慢路走重量模型+工具调用+深度推理，5-10秒出完整报告。两条路并行执行，前端先展示快路结果，慢路结果到了之后追加或替换。具体实现：用户请求进来后，调度器同时发两个任务——快路直接拿检索结果让小模型总结，慢路走完整的Agent推理链。前端用SSE推送，第一个事件是快路结果，标注"快速预览"，后续事件逐步推送慢路的详细内容。这里有个设计取舍：快路结果可能和慢路有冲突（比如快路说"大概500元"，慢路精确到"487元"），我们的做法是快路明确标注"预估，分析中…"，慢路到了之后整体替换，不留两套答案让用户困惑。还有一个变体：不是双路并行，而是单路流式+逐步加载工具结果——Agent先基于已有知识给一个初步回答，同时后台调工具拿数据，数据到了再补充"补充信息：…"。这种更简单，适合工具调用只有1-2个的场景。

【面试题】7. 在CrewAI中，Agent的role、goal、backstory分别起什么作用？怎么写才能让Agent表现更好？

【标准答案】这三个参数直接决定Agent的"人设"，人设越清晰，输出越稳定。role是身份标签，告诉模型"你是谁"——不是装饰，是约束。你写"数据分析师"模型就会往数据分析方向收敛，写"资深数据科学家"输出会更专业更深入。goal是任务目标，告诉模型"你要达成什么"——必须具体可衡量。写"分析数据"太模糊，写"从销售数据中找出下滑原因并给出3条改进建议"就好得多。backstory是背景故事，告诉模型"你的经验和倾向"——这是最被低估的参数。好的backstory能预置推理框架，比如"你有10年电商经验，擅长从用户行为数据中发现异常模式，习惯先看趋势再看细节"。这三者的关系：role定方向，goal定终点，backstory定路径。写法上有个技巧：backstory里预埋输出格式偏好，比如"你习惯用表格对比呈现分析结果"，这样不用在每轮对话里重复格式要求。还有个实战经验：不要把backstory写太长，超过300字模型容易忽略后半段，精华放前面。CrewAI会把这三个拼成system prompt，所以信息密度比长度重要。

【面试题】8. 你在做RAG的时候，Embedding模型的选型是怎么考虑的？不同语言、不同领域（医疗、法律）怎么选？

【标准答案】Embedding选型看三个维度：语言支持、领域适配、性能开销。通用场景，英文用OpenAI的text-embedding-3-small/large，中文用BGE系列（bge-large-zh-v1.5）或者M3E，多语言用multilingual-e5-large。这是基线。领域适配是关键差异点——通用Embedding在专业领域效果会掉。医疗场景，通用模型可能把"心肌梗死"和"心肌炎"的向量搞得很近，但临床上是完全不同的疾病。解决方案有两个：一是用领域预训练的Embedding模型，比如医疗领域有PubMedBERT衍生的Embedding，法律领域有LegalBERT；二是微调——用领域的标注数据（问答对、相似文档对）对通用模型做fine-tune，几百条数据就能有明显提升，而且成本低。性能开销也要考虑：在线检索场景，Embedding维度越高存储和计算成本越大。text-embedding-3-large是3072维，bge-large-zh是1024维，如果你有千万级文档，存储差3倍。OpenAI的维度缩减功能（Matryoshka）可以降到256维还能保持90%+效果，值得用。我的选型流程：先拿领域测试集（50-100个query）跑几个候选模型的Recall@10，谁高选谁，差距不大的选便宜和快的。

【面试题】9. 你们线上Agent系统的错误率是多少？怎么定义的？出了问题怎么快速定位？

【标准答案】先说怎么定义"错误"——Agent系统的错误不是简单的"报错vs不报错"，而是分层的。我们定义三层：L1系统错误（API超时、工具调用异常、服务宕机），L2逻辑错误（Agent调了错误的工具、传了错误参数、走了错误分支），L3质量错误（回答不准确、不完整、有幻觉）。L1错误率我们控制在0.5%以下，靠重试和降级兜底；L2是最难搞的，我们通过日志链路追踪定位，错误率大约3-5%，主要靠优化Prompt和工具描述来降低；L3靠用户反馈和抽样评估，目标是抽样通过率>85%。快速定位的核心是"全链路追踪"——每个请求分配一个trace_id，从用户输入到每步工具调用到最终输出，全部记录到可观测系统（我们用LangSmith+自建看板）。出了问题，拿trace_id一搜就能看到完整决策链：模型思考了什么、调了哪些工具、工具返回了什么、最终怎么决策的。90%的问题5分钟内能定位到是哪个环节出了问题。还有个经验：L2错误很多时候不是模型的锅，是工具描述不清晰导致模型误调，所以我们会定期review工具调用日志，把高频误调的工具描述优化掉。

【面试题】10. 面试官问："如果让你优化一个已有Agent项目，你会从哪些方面入手？请给出优先级排序。"

【标准答案】我的优先级排序：效果>成本>速度>体验。第一步，评估效果——先搞清楚当前系统的真实水平。跑一个标注测试集看准确率，看用户反馈数据和投诉记录，搞清楚"差在哪"。效果不行的话其他优化都没意义。第二步，看RAG链路——80%的Agent项目效果问题出在检索环节。检查召回率、chunk策略、Embedding质量，这些是性价比最高的优化点。第三步，优化Prompt——很多时候Prompt写得太模糊导致模型行为不稳定，加上few-shot示例和明确的输出格式约束，效果能提升一大截。第四步，降成本——效果稳了再看怎么省钱。语义缓存、模型降级（简单问题用小模型）、prompt压缩、减少不必要的工具调用轮次。第五步，提速度——流式输出、并行工具调用、预热模型缓存。第六步，打磨体验——加载动画、渐进式展示、错误时的友好提示。为什么这个顺序？因为效果是1，其他是0。效果不行你优化再快再便宜用户也不会用。而且效果问题的修复往往成本最低——调Prompt和检索策略比重构架构快得多。我之前接手一个客服Agent项目，准确率从62%提到85%，只花了一周，主要就是优化了chunk策略和Prompt。