AI智能体应用开发面试题
生成时间：2026-06-12 01:55:21 题目数量：10道 知识范围：1-3年岗位要求
【面试题】1. 请解释Agent中ReAct（推理+行动）模式的工作原理，以及它相比普通提示词调用的优势是什么？
【标准答案】ReAct的核心是让模型在执行动作之前先"思考一步"。具体来说，它遵循一个循环：Thought（思考当前情况）→ Action（决定做什么）→ Observation（观察执行结果）→ 再回到Thought。
比如用户问"北京今天天气怎么样"，普通调用可能是让模型直接编答案，而ReAct会先思考"我需要查天气"，然后调用天气API，观察返回数据，最后基于真实数据回答。
优势主要有三点：第一，可解释性强，整个推理链路透明可见，方便调试和优化；第二，减少幻觉，因为关键信息是通过工具获取的，不是模型瞎编的；第三，可以处理复杂多步任务，每一步都有明确的中间输出。
在实际项目中，我一般会在System Prompt里明确要求模型按Thought/Action/Observation格式输出，然后解析Action字段触发对应的工具调用。
【面试题】2. 在LangChain中，Tool和Agent的关系是什么？如果要让Agent调用自定义API，应该如何实现？
【标准答案】简单理解，Tool是Agent的"手脚"，Agent是"大脑"。Agent负责决策什么时候用什么工具，Tool负责具体执行某个能力。
要接入自定义API，有三步：
第一步，定义Tool。最简单的方式是用@tool装饰器，把一个Python函数变成Tool。函数的docstring会自动变成工具描述，告诉Agent这个工具能做什么、参数是什么。
第二步，返回Tool对象时，函数内部调用你的API，处理返回结果，把关键信息以字符串形式返回给Agent。
第三步，把Tool加入Agent的工具列表。如果是LangChain的ReAct Agent，需要用create_react_agent并传入tools参数。
关键点：工具描述要写清楚，这是Agent判断"该不该用这个工具"的唯一依据。参数类型要标注明确，LangChain会自动做参数校验。返回值尽量精简，太长的返回会占用上下文。
【面试题】3. 在多智能体系统中，如何设计Agent之间的通信机制？CrewAI和LangGraph在这方面有什么区别？
【标准答案】多Agent通信主要有三种模式：
第一，任务传递型。A完成自己的部分，把结果"交接"给B继续。适合流水线式工作流，比如"调研→撰写→审核"。
第二，共享记忆型。所有Agent读写同一个记忆存储，通过黑板机制协作。适合需要共享上下文的场景。
第三，消息总线型。Agent之间通过消息队列通信，支持一对多、异步响应。适合复杂协作网络。
CrewAI采用的是角色分工+任务分配模式，定义Agent时指定role、goal、backstory，然后创建Task分配给对应Agent。它内部会自动处理任务编排和结果传递，适合快速搭建固定工作流的团队。
LangGraph更灵活，基于状态机（State Graph）构建。每个节点是一个Agent或函数，边定义流转条件。你可以精确控制每个状态转换的逻辑，支持循环、分支、并行。适合复杂、需要精细控制的场景。
实际选型：简单固定流程用CrewAI开发快；复杂动态流程用LangGraph更可控。
【面试题】4. 请设计一个带记忆的客服Agent架构，要求支持多轮对话、用户画像记忆、知识库检索，并且能够处理用户情绪。
【标准答案】整体架构分四层：
第一层：对话管理器。负责维护session，存储对话历史，管理对话状态（闲聊、咨询、投诉等）。
第二层：记忆系统。分为三块：
- 短期记忆：当前会话的对话历史，用滑动窗口或token限制管理长度。
- 长期记忆：用户画像、历史偏好、曾解决的问题。存储在向量数据库或关系数据库。
- 工作记忆：当前任务相关的临时信息，比如正在处理的订单ID。
第三层：能力层。包含多个工具：
- 知识库检索工具：RAG查询产品FAQ、政策文档。
- 情绪识别模块：可以是一个独立的分类模型，或让LLM输出情绪标签。
- 工单系统对接：处理需要人工介入的情况。
第四层：编排层。根据用户意图和情绪动态调整策略。比如检测到用户愤怒，就切换到安抚模式，优先转人工或提供更直接的解决方案。
关键技术点：记忆检索时要做相关性过滤，不是所有历史都塞进来；情绪检测可以用规则+模型混合，简单场景用关键词匹配就够了。
【面试题】5. 在RAG系统中，如何解决"检索内容不相关"和"关键信息检索不到"这两个常见问题？
【标准答案】这两个问题其实是检索质量的两个维度：准确率和召回率。
检索不相关（准确率低）的解决方案：
重排序。先用向量检索召回Top-K（比如20条），再用Cross-Encoder精排，选出最相关的5条。效果提升明显，代价是延迟增加。
添加元数据过滤。在检索前先根据时间、来源、类型等维度过滤，缩小检索范围。
调整Chunk大小。太小的chunk信息不完整，太大的chunk噪音多。可以尝试层级切分，检索时先用小chunk定位，再返回其所属的大chunk。
关键信息检索不到（召回率低）的解决方案：
查询改写。用户原始query可能表述模糊，用LLM改写成多个搜索友好的query并行检索。
多路召回。向量检索+关键词检索（BM25）混合，向量擅长语义匹配，关键词擅长精确匹配。
假设性文档嵌入。先让LLM生成一个"理想答案"，然后用这个答案的向量去检索相似的真实文档。适合用户问题表述和文档表述差异大的场景。
数据治理。确保知识库覆盖全面，定期更新，处理过时信息。
实际项目中，我一般会用"查询改写+混合检索+重排序"这套组合拳，效果稳定。
【面试题】6. 场景题：公司要做一个"自动化周报生成Agent"，需求是：从Jira拉取本周任务、从Git获取代码提交记录、从日历获取会议情况，最后汇总成周报发给领导。请描述你的实现思路和关键技术决策。
【标准答案】整体思路是把大任务拆解成可并行的子任务，然后聚合结果。
第一步，工具层开发。
为每个数据源开发独立的Tool：
- Jira Tool：调用Jira API，按时间范围和负责人筛选任务，返回任务列表（标题、状态、优先级）。
- Git Tool：调用Gitlab/GitHub API，获取commit记录，按仓库、时间范围过滤。
- Calendar Tool：调用Outlook/飞书日历API，获取本周会议记录。
关键点：每个Tool要做好错误处理，某个数据源失败不影响其他；返回数据要做清洗，只保留周报需要的字段。
第二步，Agent编排。
有两种方案：
方案A：单Agent+多Tool。把三个工具都注册给一个Agent，让它在Prompt指导下依次调用，然后汇总。优点是简单，缺点是如果某个工具慢会阻塞整体。
方案B：多Agent并行。三个采集Agent并行执行，汇总Agent等待所有结果后生成周报。可以用LangGraph的并行节点实现。优点是快，适合数据源多、延迟要求高的场景。
我倾向于方案B，因为采集任务之间没有依赖关系，并行能显著提升速度。
第三步，周报生成。
用Prompt Template把采集的数据填入，让LLM生成结构化周报。模板要包含：本周完成事项、进行中任务、遇到的问题、下周计划等章节。
第四步，交付渠道。
生成后通过邮件或飞书发送。可以用定时任务（比如每周五下午）触发整个流程。
错误处理机制：
- 某个数据源失败时，在周报中标注"数据获取失败"，而不是整个流程崩掉。
- 添加重试逻辑，API限流时指数退避重试。
- 记录日志，方便排查问题。
【面试题】7. 在生产环境中部署Agent时，如何控制Token消耗成本？请结合具体场景说明。
【标准答案】Token成本控制是Agent落地的核心问题，我一般从四个层面入手：
第一层：Prompt优化。
- 精简System Prompt，删除冗余描述。我测过，一个1000字的System Prompt改成300字，每次调用能省700 token，调用频繁的场景累积起来很可观。
- 少样本示例控制在1-2个，不要堆太多。
- 对话历史用滑动窗口，只保留最近N轮，或者用摘要模型压缩历史对话。
第二层：模型分层。
不是所有任务都要用GPT-4级别的模型。简单分类、提取任务用GPT-3.5或国产平替模型，只有复杂推理才用旗舰模型。
实践中可以设计一个Router Agent，先判断任务复杂度，再路由到对应模型。
第三层：缓存机制。
对于重复性查询，建立语义缓存。把query向量化和历史query比对，相似度超过阈值的直接返回缓存结果，不走LLM。
适合FAQ类场景，能大幅降低成本。
第四层：工具结果精简。
Tool返回的数据要做裁剪。比如查数据库返回100条记录，每条有20个字段，全部塞给LLM就是浪费。应该在工具层只返回必要字段，或者先让模型判断需要哪些字段再查询。
监控层面：
必须建立Token消耗监控，记录每次调用的input/output token数，分析Top消耗场景，针对性优化。
举个实际案例：我之前做的客服Agent，初期每天Token消耗3万，通过Prompt精简（省40%）+模型分层（简单意图用3.5，省30%）+语义缓存（命中率20%），降到每天1万出头。
【面试题】8. 面试官问：你之前做的Agent项目遇到过什么坑？是怎么解决的？
【标准答案】说一个印象最深的——Agent死循环问题。
当时做的是一个数据分析Agent，用户问一个复杂问题，Agent需要多步调用数据库、计算、生成图表。上线后发现，偶尔会陷入死循环：同一个动作反复执行，token消耗飙升，最后超时崩溃。
排查后发现，原因有三：
第一，工具描述有歧义。Agent以为第一次调用没成功，又尝试第二次、第三次。解决方法是重新写工具描述，把触发条件、返回值含义写得更明确，并且让工具在成功时返回明确的"任务完成"标识。
第二，缺乏停止条件。Prompt里没告诉Agent"最多尝试N次"或"如果连续两次结果一样就停止"。加了这个限制后，就算陷入循环也会强制退出。
第三，错误信息误导。某个工具失败时返回的错误信息太笼统，Agent不知道该换个方法还是重试，就盲目重试。改成返回结构化错误码和建议的后续动作后，Agent能做出更合理的决策。
总结一下，Agent的鲁棒性很大程度取决于Prompt的严谨性。现在我做Agent会专门写一个"边界条件清单"，把所有可能出错的场景都过一遍，在Prompt里明确处理方式。
【面试题】9. 如何评估一个Agent系统的效果？有哪些指标和方法？
【标准答案】Agent评估比传统模型评估复杂，因为它涉及决策、执行、输出多个环节。我一般分三层来评估：
第一层：任务成功率。
核心指标。给定一批测试任务，看Agent能成功完成多少。比如客服Agent的"问题解决率"、数据分析Agent的"正确答案比例"。
构建测试集很重要。我会从历史数据中抽样，人工标注正确答案和预期行为，作为benchmark。
第二层：过程指标。
- 工具调用准确率：Agent是否在正确的时机调用了正确的工具。
- 平均步数：完成任务用了多少步，步数过多可能说明规划能力有问题。
- 错误恢复率：遇到错误时，Agent能否自我修正并最终完成任务。
这些指标需要记录Agent的完整执行轨迹，然后分析。LangSmith、Arize等工具提供了很好的可观测性支持。
第三层：成本与性能。
- 平均Token消耗：每个任务消耗多少token，直接关联成本。
- 平均响应时间：用户等待时间，影响体验。
- 错误率：各类错误的发生频率。
评估方法：
- 自动化评测：用LLM作为评判者（LLM-as-Judge），对Agent输出打分。适合大规模评估。
- 人工评测：抽样让真人评估，准确但成本高。适合上线前的最终把关。
- A/B测试：新旧版本对比，用真实用户数据验证改进效果。
实践中，我会先建立自动化评测流水线，每次改动都跑benchmark，确保不退化；定期做人工评测，校准自动评测的偏差。
【面试题】10. 请简述Dify平台的核心优势，以及它在企业级Agent落地中的定位。
【标准答案】Dify最大的优势是"低代码+可定制"的平衡。
核心能力：
可视化工作流编排。拖拽式搭建Agent流程，支持条件分支、循环、并行等复杂逻辑。非技术人员也能参与开发，降低了门槛。
内置RAG Pipeline。从文档上传到向量存储到检索，全流程可视化配置。支持多种向量数据库，分块策略可调。
多模型支持。可以一键切换不同的大模型后端，包括OpenAI、文心、通义、本地部署模型等。方便做成本和效果的平衡。
丰富的工具生态。预置了网络搜索、天气、数据库查询等常用工具，也支持自定义API工具。
在企业落地中的定位：
我把它定义为"快速验证+小规模生产"的首选。
适合的场景：
- 内部效率工具：知识库问答、文档处理、数据分析等，开发成本低，上线快。
- POC验证：快速搭一个原型验证业务可行性，成功了再考虑深度定制。
- 非核心业务：对稳定性和性能要求没那么极致的场景。
不适合的场景：
- 超大规模并发：Dify本身会有一定性能损耗，极致性能要求建议直接用LangChain/LangGraph自建。
- 高度定制需求：某些特殊业务逻辑可能超出Dify的编排能力，需要手写代码。
实际项目中，我会这样组合：用Dify快速出原型和MVP，验证成功后，如果业务重要且规模大，再考虑用LangGraph重构核心链路，获得更好的性能和可控性。
生成完毕 | 共10道题