目录1滑动窗口 摘要压缩会话记忆怎么实现2 滑动窗口大小怎么确定一般设多少轮3AI Coding 工具遇到的问题 完整工作流 AI Native 做法4深拷贝 浅拷贝5 finally 一定会执行吗6AOP 失效的场景7 过滤器 Filter 和拦截器 Interceptor 区别8哈希冲突解决方法9完整的RAG流程?10哪个项目参与最深(介绍一下项目)和个人工作项目最难或最亮眼的地方是什么方案为何这样定之前的性能问题是怎样发现并推进解决的有哪些主动发现、推动并落地的问题11错召回、漏召回你是怎么解决的12超发/超卖问题?13审查 “DB 查工单并缓存” 的代码有什么问题14什么是 AI Agent15AI Agent 和普通 Chat 聊天机器人的核心区别是什么16何时需要分布式事务有哪些方案17有 AI Coding 工具后程序员还要会写代码吗18从零设计云产品智能客服知识、资源、排障和转人工。19AI Coding 的前端开发与交付方式20前端是否主要使用 AI Coding 开发21AI Coding 是否涉及端到端交付22当用户对智能机器人说“帮我向前移动 2 米并打开照明灯”时如何利用大模型的 Function / Tool Calling 机制输出结构化指令如果大模型在某些情况下返回了缺漏字段的 JSON例如只给出了动作类型遗漏了距离参数在后端工程上应如何设计校验与兜底逻辑23在 RAG 流程中将文本转为向量Embedding并在向量数据库中计算余弦相似度的本质是什么在切分长文档时切片过长或切片过短分别会引发什么问题24如果需要让机器人精准回答“设备机密维修手册”或“最新排班表”为什么通常采用 RAG检索增强生成方案而不是全量微调Fine-tuning模型请简述 RAG 的三个核心环节。25AI 编写的代码在本地运行时报出了一长串报错日志如由于第三方库版本更新导致函数不存在或混淆了同步与异步调用。你的排错流程是怎样的如何甄别 AI 给出的修复代码是否可靠26说一下用户数据库配置错误兜底方式27数据库动态变更不重启服务可以应用 Agent 吗28说一下 Agent 接入一个新的 MCP 的完整流程29消息回调是怎么做的30用户输入轮次过多导致模型注意力分散怎么处理31上下文超出模型 token 怎么处理32文档召回的 benchmark评估指标设计33Agent 节点流转过程中运行情况分析34AI Agent 的核心核心特征有哪些35量化评估模型回答效果怎么做的36单个文档是如何分割的37说一下后端项目中涉及到的高并发场景38说一下 Redis 的压测方式39说一下 Redis 的数据类型40Redis 缓存雪崩击穿穿透介绍以及应对方式41Redis 速度快的原因42介绍 Spring 的 IOC 和 AOP43说一下 hashmap44什么是 LLM Agent核心优势是什么45简述 AI Agent 的完整工作闭环46AI Agent 主要可以落地哪些业务场景47AI Agent 的五大核心模块是什么各自作用48简述 Agent Memory 模块的分类及应用场景49什么是 Agent 规划Planning主流规划方式有哪些50什么是 ReAct 架构在 Agent 中的作用51末尾页1滑动窗口 摘要压缩会话记忆怎么实现整体是两层记忆短期原始窗口 长期摘要。1. 滑动窗口保留最近 N 轮完整对话原始文本不压缩模型读取这部分信息保真2. 当对话轮数超过窗口阈值把**窗口外更早的历史**交给模型做摘要提炼关键信息用户需求、结论、约束条件3. 摘要存入长期记忆后续上下文只带上摘要不再携带原始长对话2 滑动窗口大小怎么确定一般设多少轮Agent 的对话窗口大小由单轮平均 token、模型上下文上限、业务成本共同决定。 计算方式窗口总 token 预算 ÷ 单轮对话平均 token换算成轮数。工程经验普通对话助手一般 5~15 轮代码类单轮 token 高轮数要更小简单问答可以放大窗口。 还要预留token 给 prompt 模板和工具返回结果不能把上下文占满。上线后用 A/B 实验根据召回准确率、token 成本、用户反馈动态调参。3AI Coding 工具遇到的问题 完整工作流 AI Native 做法一、遇到的问题幻觉生成代码存在逻辑 bug、函数不存在、接口参数错误。上下文受限代码库大无法一次性读全仓库容易丢失跨文件依赖。代码正确性差缺少编译、单元测试校验生成代码不能直接运行。输出格式混乱代码块、注释、文本混在一起难以解析。成本与速度长上下文 token 开销高推理延迟大。二、完整工作流用户输入需求仓库检索RAG 检索相关代码文件、文档上下文组装把检索片段、用户需求、系统 prompt 拼装LLM 生成代码后置校验语法检查、编译、单元测试结果返回给用户收集用户反馈迭代优化。三、AI Native 做法不再只是 “大模型外挂检索”让 AI自主规划编码任务Agent 规划拆解需求自主决定要读哪些文件、调用哪些工具多轮工具调用读代码、查定义、跑编译、执行测试发现错误自动修复增量修改只改动必要代码片段不是全量重写闭环自校验模型自己观察编译 / 测试报错迭代修复代码。4深拷贝 浅拷贝浅拷贝只拷贝对象的引用地址新对象和原对象指向同一个堆内存。基本数据类型拷贝值引用类型拷贝引用。修改新对象里的引用属性原对象也会跟着变。深拷贝完整拷贝整个对象包括所有引用类型的成员生成全新堆对象。新旧对象完全独立修改任意一方互不影响。常见实现浅拷贝clone()深拷贝可以重写 clone、序列化、JSON 序列化。Object.clone()默认是浅拷贝是的。5 finally 一定会执行吗正常情况下try 块 return 前finally 代码会执行。但**不是一定执行**。不执行场景① 代码执行System.exit(0)直接终止 JVMfinally 不跑② JVM 崩溃、系统断电、OOM 致命错误系统级错误 Error进程直接挂掉finally 不会执行③ 线程被 kill。Exception 是异常Error 是错误Error 属于系统级问题JVM 直接崩溃无法执行 finally。6AOP 失效的场景Spring AOP 基于 JDK/CGLIB 动态代理只有**外部通过代理对象调用方法**才会生效。失效场景1. 同类内部方法调用this. 方法 ()走的是原对象不是代理对象AOP 不拦截2. 目标方法不是 public3. 静态方法、final 方法无法被代理4.代理对象没有被 Spring 管理解决用ApplicationContext拿到代理对象或者AopContext.currentProxy()。7 过滤器 Filter 和拦截器 Interceptor 区别Filter 是 Servlet 规范Interceptor 是 Spring 框架提供。执行顺序请求进来先过 Filter再到 Interceptor返回时反过来。拦截粒度Filter 拦截 Servlet 请求基于 URLInterceptor 拦截 Controller 方法可拿到处理器信息。依赖Filter 不依赖 Spring 容器Interceptor 属于 Spring能注入 Bean。8哈希冲突解决方法哈希冲突不同 key 算出相同 hash 地址。两种主流方案链地址法拉链法数组每个位置挂链表 / 红黑树冲突元素挂在后面HashMap 就是这个。开放寻址法数组内找下一个空位分线性探测、二次探测、双重哈希ThreadLocalMap 用线性探测。9完整的RAG流程?知识库构建加载文档 → 切分文本 → 向量化 → 存入向量库检索生成用户提问 → 向量化 → 检索相关文档 → 拼接上下文 → 生成回答10哪个项目参与最深(介绍一下项目)和个人工作项目最难或最亮眼的地方是什么方案为何这样定之前的性能问题是怎样发现并推进解决的有哪些主动发现、推动并落地的问题根据简历上的项目具体背诵11错召回、漏召回你是怎么解决的错召回就是检索出来不相关的文档漏召回是本该召回的相关文档没被检索出来我是从检索、重排、数据预处理、阈值策略这几块分开优化的。针对漏召回首先扩充召回源混合 BM25 关键词检索和向量检索同时对 query 做改写、同义词扩展、拆分长 query调低召回的 topN 阈值保证相关材料先有机会被捞出来。针对错召回主要靠后面的重排模型做精排过滤同时收紧相似度阈值过滤掉低分的结果另外清洗知识库去除重复、脏数据给文档加元数据做过滤比如时间、业务标签提前筛掉无关内容。上线之后持续收集 bad case定期迭代把高频的错漏 case 补充到提示词、规则或者样本里。12超发/超卖问题?答超发、超卖问题往往是由于多线程的并发访问导致的。所以解决这个问题的手段就是加锁。可以采用悲观锁也可以采用乐观锁。如果并发量不是特别高就使用悲观锁就可以了。不过性能会受到一定的影响。如果并发相对较高对性能有要求那就可以选择使用乐观锁。当然乐观锁也有自己的问题就是多线程竞争时失败率比较高的问题。并行访问的N个线程只会有一个线程成功其它都会失败。所以针对这个问题再结合库存问题的特殊性我们不一定要是有版本号或者CAS机制实现乐观锁。而是改进为在where条件中加上一个对库存的判断即可。比如在where条件中除了优惠券id以外加上库存必须大于购买数量的条件。这样如果库存不足where条件不成立自然也会失败。这样做借鉴了乐观锁的思想在线程安全的情况下保证了并发性能同时也解决了乐观锁失败率较高的问题一举多得。13审查 “DB 查工单并缓存” 的代码有什么问题常见问题这个到时候拿到具体项目里面去准备具体问题1. 缓存穿透查询不存在工单每次都会打到 DB2. 缓存击穿热点工单缓存过期大量请求打数据库3. 缓存雪崩大量 key 同时过期4. 缓存和 DB 双写不一致更新数据库没有正确处理缓存5. 没有处理缓存序列化、过期时间6. 并发下缓存更新逻辑出现竞态条件。【可选扩展深挖补充】 对应解法缓存穿透存空值,使用布隆过滤器击穿用互斥锁、热点永不过期雪崩设置过期时间随机偏移更新优先删除缓存根据业务选择一致性策略。14什么是 AI AgentAI Agent 是基于大语言模型为核心具备环境感知、目标理解、自主规划、工具调用、执行反馈、自我迭代能力的智能自治系统。区别于传统问答模型它以目标为导向可以自主拆解复杂任务、主动执行操作、闭环完成完整业务流程是具备行动能力的智能体。15AI Agent 和普通 Chat 聊天机器人的核心区别是什么核心区别体现在四点1、能力维度普通机器人仅支持被动问答Agent 支持主动规划、自主执行、多轮迭代2、工作模式普通模型单次响应Agent 形成「感知 - 规划 - 执行 - 反馈」闭环3、任务能力普通模型仅处理简单对话Agent 可落地复杂长流程任务4、拓展性普通模型无工具联动能力Agent 可无缝调用各类外部工具、API、知识库。16何时需要分布式事务有哪些方案当一个业务操作需要跨多个服务、多个数据库资源要求所有操作要么全部成功要么全部回滚单库本地事务满足不了的时候就需要分布式事务。常见方案有 2PC、TCC、SAGA、本地消息表、RocketMQ 事务消息还有 Seata 框架它封装了 AT、TCC 这些模式其中 AT 模式业务无侵入使用最多。2PC 分为准备阶段和提交阶段有协调者缺点是存在阻塞、协调者单点问题性能差适合短事务TCC 分为 Try、Confirm、Cancel 三个接口业务层自己实现补偿逻辑侵入性强性能较好适合高并发核心场景SAGA 把分布式事务拆成一串本地事务每个事务配补偿操作适合长事务本地消息表和 RocketMQ 事务消息属于最终一致性方案异步执行适合接受短暂数据不一致的业务AT 是 Seata 默认模式基于 undo log 记录快照自动回滚业务几乎不用改代码。 另外优先考虑业务优化尽量避免引入分布式事务。17有 AI Coding 工具后程序员还要会写代码吗需要。AI Coding 适合做样板代码、DTO、单测、脚本提升效率。 但方案选型、业务理解、并发、事务、资损风险、边界校验需要人来把控AI 会产生幻觉可能写出隐藏 bug。程序员需要看懂、校验、修改 AI 产出定位根因承担线上责任。AI 是放大器不是替代。18从零设计云产品智能客服知识、资源、排障和转人工。1. 知识层知识库RAG 检索存储产品文档、FAQ做文档分块、向量库2. 资源层对接业务后端接口工具调用 Function Calling查询用户工单、账单信息3. 排障Agent 工具调用执行排障步骤采集日志无法解决给出排障指引4. 转人工触发条件多次回答无效、用户主动要求、涉及资损高危场景把会话上下文、历史问答一并带给人工客服。 配套会话记忆管理、权限控制、SSE 流式输出、知识库管理后台。【可选扩展深挖补充】 增加评价反馈用户反馈好坏迭代知识库设置相似度阈值避免幻觉回答。19AI Coding 的前端开发与交付方式AI Coding 是辅助手段。一般是后端先输出接口契约AI 辅助生成前端页面组件、样式人去校验交互逻辑、边界异常、联调后端接口。交付物还是标准前端工程正常打包部署。20前端是否主要使用 AI Coding 开发是的但是不会完全交给 AI。AI 可以快速生成样板页面、组件提升开发速度但是业务交互逻辑、异常处理、兼容性需要人修改、校验不能直接交付。21AI Coding 是否涉及端到端交付可以做端到端原型快速生成但不能直接线上交付。AI 生成端到端代码经常存在逻辑漏洞、边界缺失需要人工 review、自测、联调之后才可以交付上线。22当用户对智能机器人说“帮我向前移动 2 米并打开照明灯”时如何利用大模型的 Function / Tool Calling 机制输出结构化指令如果大模型在某些情况下返回了缺漏字段的 JSON例如只给出了动作类型遗漏了距离参数在后端工程上应如何设计校验与兜底逻辑工具调用流程预先定义move移动、turn_light开灯两个工具描述传给大模型。用户输入后大模型识别要执行两个工具输出结构化 JSON 数组一条控制向前移动 2 米一条打开照明灯。后端拿到 JSON分别调用对应硬件接口执行动作。缺字段兜底 ①后端做 JSON Schema 强制校验校验必填字段缺失直接拦截 ②字段缺失把错误信息回传给大模型让模型重新补全参数 ③增加业务兜底关键参数缺失不向下发硬件指令拒绝执行返回提示用户补充信息。23在 RAG 流程中将文本转为向量Embedding并在向量数据库中计算余弦相似度的本质是什么在切分长文档时切片过长或切片过短分别会引发什么问题余弦相似度本质把文本映射高维向量空间用向量夹角大小衡量两段文本语义相似程度夹角越小语义越接近。切片过长块里面包含大量无关内容引入噪声检索出来无关信息干扰大模型切片过短语义被截断丢失上下文语义碎片检索相关性下降。24如果需要让机器人精准回答“设备机密维修手册”或“最新排班表”为什么通常采用 RAG检索增强生成方案而不是全量微调Fine-tuning模型请简述 RAG 的三个核心环节。选 RAG 原因 1. 文档经常更新微调要重新训练成本高RAG 直接更新知识库即可 2. 机密数据微调会把知识固化进模型权重存在泄露风险RAG 知识库可以做权限管控 3. 微调成本高需要大量高质量样本RAG 不需要训练模型。RAG 三大核心环节文档处理与分块、向量检索召回、将检索片段注入 prompt 交给大模型生成答案。25AI 编写的代码在本地运行时报出了一长串报错日志如由于第三方库版本更新导致函数不存在或混淆了同步与异步调用。你的排错流程是怎样的如何甄别 AI 给出的修复代码是否可靠排错流程 1. 先定位报错栈确认报错位置、报错原因 2. 区分是依赖版本问题、同步异步问题还是业务逻辑问题 3. 复现问题最小复现案例 4. 再参考 AI 给出修复方案而不是直接复制粘贴。甄别修复代码1. 看修复逻辑是否匹配报错栈 2. 检查有没有引入新幻觉 API 3. 阅读代码逻辑手动梳理流程 4. 写完做单元测试本地复现验证。26说一下用户数据库配置错误兜底方式分多层兜底1.前置校验配置下发时校验地址、账号、端口格式2.连接探测Agent 拿到配置先轻量 ping / 测试连接3.捕获连接异常、权限异常区分报错文案返回给用户不直接抛堆栈4.熔断连续多次配置错误停止重试5.配置隔离坏配置不影响其他 Agent 实例。27数据库动态变更不重启服务可以应用 Agent 吗可以。不用重启靠配置中心Nacos/Apollo监听配置变更感知数据库连接信息变更Agent 注册监听器收到变更后优雅关闭旧连接池新建连接池切换数据源。28说一下 Agent 接入一个新的 MCP 的完整流程1. 定义 MCP 工具元信息名称、描述、入参 schema、出参 schema2. 注册到 Agent 工具注册表3. 编写调用适配器封装请求、参数映射、异常捕获4. 给模型的 system prompt 注入这个工具描述让模型知道什么时候调用5. 增加权限、限流、超时配置6. 测试触发模型调用、校验返回、异常 case 验证最后上线埋点统计调用成功率。29消息回调是怎么做的两种主流方式1.HTTP 回调Agent 执行完工具 / 任务主动调用业务方提供的回调地址带上结果2.MQ 消息回调执行完成投递消息到指定 topic消费方监听。同时做幂等加唯一回调 ID失败支持重试、死信兜底。30用户输入轮次过多导致模型注意力分散怎么处理1.会话摘要定期对历史对话做摘要压缩精简历史2. 按重要性做记忆分级长期重要信息存向量库不重要的轮次直接丢弃3. 控制历史轮数上限轮数到阈值触发裁剪4. 优先保留和当前问题相关的历史无关对话过滤。31上下文超出模型 token 怎么处理分层策略优先统计 token 数量超过阈值先裁剪低相关性历史再做对话摘要压缩RAG 场景减少召回文档片段最后兜底截断同时给模型提示避免丢失关键指令。32文档召回的 benchmark评估指标设计召回基础指标召回率、精确率、F1业务指标问答准确率、幻觉率、用户满意度还有时延、召回数量上限。构造 query - 标准文档标注数据集跑 benchmark。33Agent 节点流转过程中运行情况分析Agent 是状态节点流转思考→工具调用→拿到结果→继续思考。埋点记录每个节点耗时、状态、输入输出看是否卡在工具调用、是否频繁重试、是否循环调用工具统计成功率、失败原因、链路耗时。34AI Agent 的核心核心特征有哪些主要包含五大特征自主性、目标导向性、环境感知性、工具交互性、自我反思性。无需人工逐轮指令可自主推进任务适配动态环境变化实时修正执行策略。35量化评估模型回答效果怎么做的两条路线自动评估人工评估。自动用评估模型打分检查是否引用检索文档、是否幻觉、是否符合问题人工标注做golden 标准计算准确率、幻觉率同时收集用户反馈标签。36单个文档是如何分割的用滑动窗口切分固定 chunk 大小 重叠优先按语义、标题、段落边界切尽量不切断语义长文本切成多个片段每个片段单独向量化入库。37说一下后端项目中涉及到的高并发场景有的我们项目中有几个典型的高并发优化场景。场景一学习记录上报优化问题用户看视频时每隔几秒上报一次播放进度如果每次都写数据库高峰期数据库扛不住。优化播放进度先写 Redis 缓存毫秒级响应通过 DelayQueue 延迟队列检测用户是否离开只有用户离开后才做一次数据库持久化从每几秒写一次DB优化为每个视频只写一次DB数据库写入量下降了90%以上场景二优惠券领取的异步化问题领券接口同步执行校验 → 写记录 → 扣库存响应慢、吞吐低。优化前置校验全部在 Redis 中通过 Lua 脚本完成毫秒级后续持久化通过 MQ 异步完成接口响应时间从几百毫秒降到几十毫秒吞吐量提升数倍场景三积分排行榜的读写分离问题积分排行榜需要实时展示如果每次都从数据库查性能差。优化当前赛季排行榜用Redis ZSet存储查询排名 O(log N)实时更新 O(log N)历史赛季数据按月分表通过定时任务从 Redis 迁移到 MySQL前端展示只取 Top 100数据量可控场景四优惠券方案的多线程并行计算问题预下单时需要枚举优惠券的所有排列组合逐个计算优惠金额方案多时串行计算慢。优化用 CompletableFuture 自定义线程池并行计算所有方案配合 CountDownLatch 设置2秒超时把计算时间从几百毫秒压缩到几十毫秒38说一下 Redis 的压测方式用 redis-benchmark 工具指定并发数、请求量、命令也可以用 JMeter压测关注 QPS、延迟、CPU、内存测热点 key、大 key 场景看是否有瓶颈。39说一下 Redis 的数据类型答很多比如String、Hash、Set、SortedSet、BitMap等面试官追问能不能具体说说使用的场景答比如很多的缓存我们就使用了String结构来存储。还有点赞功能我们用了Set结构和SortedSet结构。签到功能我们用了BitMap结构。就拿签到来说吧。因为签到数据量非常大嘛而BitMap则是用bit位来表示签到数据31bit位就能表示1个月的签到记录非常节省空间而且查询效率也比较高。点赞业务功能答我们使用了两种数据结构set和zset首先保存点赞记录使用了set结构key是业务类型业务id值是点赞过的用户id。当用户点赞时就SADD用户id进去当用户取消点赞时就SREM删除用户id。当判断是否点赞时使用SISMEMBER即可。当要统计点赞数量时只需要SCARD就行而Redis的SET结构会在头信息中保存元素数量因此SCARD直接读取该值时间复杂度为O(1)性能非常好。为什么不用用户id为key业务id为值呢如果用户量很大可能出现BigKey您说的这个方案也是可以的不过呢考虑到我们的项目数据量并不会很大我们不会有大V因为点赞数量通常不会超过1000因此不会出现BigKey。并且由于我们采用了业务id为KEY当我们要统计点赞数量时可以直接使用SCARD来获取元素数量无需额外保存这是一个很大的优势。但如果是考虑到有大V的场景有两种选择一种还是应该选择您说的这种方案另一种则是对用户id做hash分片将大V的key拆分到多个KEY中//结构为 [bizType:bizId:userId高8位]不过这里存在一个问题就是页面需要判断当前用户有没有对某些业务点赞。这个时候会传来多个业务id的集合而SISMEMBER只能一次判断一个业务的点赞状态要判断多个业务的点赞状态就必须多次调用SISMEMBER命令与Redis多次交互这显然是不合适的。此处略停顿等待面试官追问面试官可能会问“那你们怎么解决的”。如果没追问自己接着说所以呢我们就采用了Pipeline管道方式这样就可以一次请求实现多个业务点赞状态的判断了。40Redis 缓存雪崩击穿穿透介绍以及应对方式穿透查不存在 key大量请求打 DB → 存空值、布隆过滤器。击穿热点 key 过期大量请求打 DB → 永不过期、互斥锁。雪崩大量 key 同时过期DB 压力暴增 → 过期时间加随机偏移、集群隔离、熔断降级。41Redis 速度快的原因第一Redis 是纯内存数据库数据都存在内存内存读写远快于磁盘第二采用单线程模型没有多线程锁竞争、上下文切换开销第三IO 多路复用一个线程可以管理大量客户端连接第四数据结构都是高度优化的底层结构比如SDS、跳表、压缩列表第五协议简单文本化 RESP 协议解析开销小第六RDB/AOF 持久化是后台子进程做不阻塞主线程。42介绍 Spring 的 IOC 和 AOPIOC 控制反转把对象创建、依赖交给 Spring 容器管理解耦DI 依赖注入是 IOC 的实现方式。AOP即面向切面编程在Spring中用于将那些与业务无关但对多个对象产生影响的公共行为和逻辑抽取出来实现公共模块复用降低耦合。常见的应用场景包括公共日志保存和事务处理。SSM框架 - 飞书云文档这个里面有其所有的面试题43说一下 hashmap常见集合篇 - 飞书云文档这个链接拉到最下面就是全部的hashMap面试题44什么是 LLM Agent核心优势是什么LLM Agent 是以大语言模型为核心大脑的智能体依靠 LLM 的自然语言理解、逻辑推理、文本生成能力完成任务拆解、决策判断、内容输出。核心优势无需大量标注数据、自然语言交互零门槛、泛化能力强、适配各类非结构化场景、快速落地业务。45简述 AI Agent 的完整工作闭环1、感知输入接收用户指令、环境信息、历史上下文2、目标解析精准识别核心需求与任务边界3、任务规划拆解复杂目标为可执行子任务4、行动执行调用工具、检索知识、生成内容5、结果反馈校验执行结果、判断是否完成目标6、迭代优化自我反思问题修正策略完成闭环。46AI Agent 主要可以落地哪些业务场景主流落地场景智能办公自动化、知识库问答、数据分析报告、代码开发调试、智能客服、自动化运维、多角色内容创作、私人智能助手、企业流程自动化。47AI Agent 的五大核心模块是什么各自作用1、感知模块接收用户输入、系统状态、环境数据2、记忆模块存储会话、任务、用户、知识信息3、规划模块拆解任务、制定执行路径、处理任务依赖4、决策执行模块选择工具、生成指令、执行任务5、反思反馈模块校验结果、排查错误、迭代优化策略。48简述 Agent Memory 模块的分类及应用场景分为四类1、短期记忆当前会话上下文实时交互使用2、长期记忆用户偏好、历史任务、核心知识持久化存储3、任务记忆记录当前任务进度、状态、执行日志4、知识记忆外部知识库沉淀的业务知识支撑专业问答。49什么是 Agent 规划Planning主流规划方式有哪些规划是 Agent 将复杂模糊目标拆解为有序、可执行子任务的核心能力。主流方式链式规划、树状规划、逐步拆解规划、反思式规划、重试修正规划适配简单到复杂各类任务场景。50什么是 ReAct 架构在 Agent 中的作用ReAct 是 LLM Agent 经典架构核心是推理Reasoning 行动Acting交替执行。模型先推理任务逻辑、判断是否需要工具再执行对应操作获取结果后再次推理有效解决纯生成模型幻觉问题大幅提升任务准确率。51末尾页
目录1滑动窗口 摘要压缩会话记忆怎么实现2 滑动窗口大小怎么确定一般设多少轮3AI Coding 工具遇到的问题 完整工作流 AI Native 做法4深拷贝 浅拷贝5 finally 一定会执行吗6AOP 失效的场景7 过滤器 Filter 和拦截器 Interceptor 区别8哈希冲突解决方法9完整的RAG流程?10哪个项目参与最深(介绍一下项目)和个人工作项目最难或最亮眼的地方是什么方案为何这样定之前的性能问题是怎样发现并推进解决的有哪些主动发现、推动并落地的问题11错召回、漏召回你是怎么解决的12超发/超卖问题?13审查 “DB 查工单并缓存” 的代码有什么问题14什么是 AI Agent15AI Agent 和普通 Chat 聊天机器人的核心区别是什么16何时需要分布式事务有哪些方案17有 AI Coding 工具后程序员还要会写代码吗18从零设计云产品智能客服知识、资源、排障和转人工。19AI Coding 的前端开发与交付方式20前端是否主要使用 AI Coding 开发21AI Coding 是否涉及端到端交付22当用户对智能机器人说“帮我向前移动 2 米并打开照明灯”时如何利用大模型的 Function / Tool Calling 机制输出结构化指令如果大模型在某些情况下返回了缺漏字段的 JSON例如只给出了动作类型遗漏了距离参数在后端工程上应如何设计校验与兜底逻辑23在 RAG 流程中将文本转为向量Embedding并在向量数据库中计算余弦相似度的本质是什么在切分长文档时切片过长或切片过短分别会引发什么问题24如果需要让机器人精准回答“设备机密维修手册”或“最新排班表”为什么通常采用 RAG检索增强生成方案而不是全量微调Fine-tuning模型请简述 RAG 的三个核心环节。25AI 编写的代码在本地运行时报出了一长串报错日志如由于第三方库版本更新导致函数不存在或混淆了同步与异步调用。你的排错流程是怎样的如何甄别 AI 给出的修复代码是否可靠26说一下用户数据库配置错误兜底方式27数据库动态变更不重启服务可以应用 Agent 吗28说一下 Agent 接入一个新的 MCP 的完整流程29消息回调是怎么做的30用户输入轮次过多导致模型注意力分散怎么处理31上下文超出模型 token 怎么处理32文档召回的 benchmark评估指标设计33Agent 节点流转过程中运行情况分析34AI Agent 的核心核心特征有哪些35量化评估模型回答效果怎么做的36单个文档是如何分割的37说一下后端项目中涉及到的高并发场景38说一下 Redis 的压测方式39说一下 Redis 的数据类型40Redis 缓存雪崩击穿穿透介绍以及应对方式41Redis 速度快的原因42介绍 Spring 的 IOC 和 AOP43说一下 hashmap44什么是 LLM Agent核心优势是什么45简述 AI Agent 的完整工作闭环46AI Agent 主要可以落地哪些业务场景47AI Agent 的五大核心模块是什么各自作用48简述 Agent Memory 模块的分类及应用场景49什么是 Agent 规划Planning主流规划方式有哪些50什么是 ReAct 架构在 Agent 中的作用51末尾页1滑动窗口 摘要压缩会话记忆怎么实现整体是两层记忆短期原始窗口 长期摘要。1. 滑动窗口保留最近 N 轮完整对话原始文本不压缩模型读取这部分信息保真2. 当对话轮数超过窗口阈值把**窗口外更早的历史**交给模型做摘要提炼关键信息用户需求、结论、约束条件3. 摘要存入长期记忆后续上下文只带上摘要不再携带原始长对话2 滑动窗口大小怎么确定一般设多少轮Agent 的对话窗口大小由单轮平均 token、模型上下文上限、业务成本共同决定。 计算方式窗口总 token 预算 ÷ 单轮对话平均 token换算成轮数。工程经验普通对话助手一般 5~15 轮代码类单轮 token 高轮数要更小简单问答可以放大窗口。 还要预留token 给 prompt 模板和工具返回结果不能把上下文占满。上线后用 A/B 实验根据召回准确率、token 成本、用户反馈动态调参。3AI Coding 工具遇到的问题 完整工作流 AI Native 做法一、遇到的问题幻觉生成代码存在逻辑 bug、函数不存在、接口参数错误。上下文受限代码库大无法一次性读全仓库容易丢失跨文件依赖。代码正确性差缺少编译、单元测试校验生成代码不能直接运行。输出格式混乱代码块、注释、文本混在一起难以解析。成本与速度长上下文 token 开销高推理延迟大。二、完整工作流用户输入需求仓库检索RAG 检索相关代码文件、文档上下文组装把检索片段、用户需求、系统 prompt 拼装LLM 生成代码后置校验语法检查、编译、单元测试结果返回给用户收集用户反馈迭代优化。三、AI Native 做法不再只是 “大模型外挂检索”让 AI自主规划编码任务Agent 规划拆解需求自主决定要读哪些文件、调用哪些工具多轮工具调用读代码、查定义、跑编译、执行测试发现错误自动修复增量修改只改动必要代码片段不是全量重写闭环自校验模型自己观察编译 / 测试报错迭代修复代码。4深拷贝 浅拷贝浅拷贝只拷贝对象的引用地址新对象和原对象指向同一个堆内存。基本数据类型拷贝值引用类型拷贝引用。修改新对象里的引用属性原对象也会跟着变。深拷贝完整拷贝整个对象包括所有引用类型的成员生成全新堆对象。新旧对象完全独立修改任意一方互不影响。常见实现浅拷贝clone()深拷贝可以重写 clone、序列化、JSON 序列化。Object.clone()默认是浅拷贝是的。5 finally 一定会执行吗正常情况下try 块 return 前finally 代码会执行。但**不是一定执行**。不执行场景① 代码执行System.exit(0)直接终止 JVMfinally 不跑② JVM 崩溃、系统断电、OOM 致命错误系统级错误 Error进程直接挂掉finally 不会执行③ 线程被 kill。Exception 是异常Error 是错误Error 属于系统级问题JVM 直接崩溃无法执行 finally。6AOP 失效的场景Spring AOP 基于 JDK/CGLIB 动态代理只有**外部通过代理对象调用方法**才会生效。失效场景1. 同类内部方法调用this. 方法 ()走的是原对象不是代理对象AOP 不拦截2. 目标方法不是 public3. 静态方法、final 方法无法被代理4.代理对象没有被 Spring 管理解决用ApplicationContext拿到代理对象或者AopContext.currentProxy()。7 过滤器 Filter 和拦截器 Interceptor 区别Filter 是 Servlet 规范Interceptor 是 Spring 框架提供。执行顺序请求进来先过 Filter再到 Interceptor返回时反过来。拦截粒度Filter 拦截 Servlet 请求基于 URLInterceptor 拦截 Controller 方法可拿到处理器信息。依赖Filter 不依赖 Spring 容器Interceptor 属于 Spring能注入 Bean。8哈希冲突解决方法哈希冲突不同 key 算出相同 hash 地址。两种主流方案链地址法拉链法数组每个位置挂链表 / 红黑树冲突元素挂在后面HashMap 就是这个。开放寻址法数组内找下一个空位分线性探测、二次探测、双重哈希ThreadLocalMap 用线性探测。9完整的RAG流程?知识库构建加载文档 → 切分文本 → 向量化 → 存入向量库检索生成用户提问 → 向量化 → 检索相关文档 → 拼接上下文 → 生成回答10哪个项目参与最深(介绍一下项目)和个人工作项目最难或最亮眼的地方是什么方案为何这样定之前的性能问题是怎样发现并推进解决的有哪些主动发现、推动并落地的问题根据简历上的项目具体背诵11错召回、漏召回你是怎么解决的错召回就是检索出来不相关的文档漏召回是本该召回的相关文档没被检索出来我是从检索、重排、数据预处理、阈值策略这几块分开优化的。针对漏召回首先扩充召回源混合 BM25 关键词检索和向量检索同时对 query 做改写、同义词扩展、拆分长 query调低召回的 topN 阈值保证相关材料先有机会被捞出来。针对错召回主要靠后面的重排模型做精排过滤同时收紧相似度阈值过滤掉低分的结果另外清洗知识库去除重复、脏数据给文档加元数据做过滤比如时间、业务标签提前筛掉无关内容。上线之后持续收集 bad case定期迭代把高频的错漏 case 补充到提示词、规则或者样本里。12超发/超卖问题?答超发、超卖问题往往是由于多线程的并发访问导致的。所以解决这个问题的手段就是加锁。可以采用悲观锁也可以采用乐观锁。如果并发量不是特别高就使用悲观锁就可以了。不过性能会受到一定的影响。如果并发相对较高对性能有要求那就可以选择使用乐观锁。当然乐观锁也有自己的问题就是多线程竞争时失败率比较高的问题。并行访问的N个线程只会有一个线程成功其它都会失败。所以针对这个问题再结合库存问题的特殊性我们不一定要是有版本号或者CAS机制实现乐观锁。而是改进为在where条件中加上一个对库存的判断即可。比如在where条件中除了优惠券id以外加上库存必须大于购买数量的条件。这样如果库存不足where条件不成立自然也会失败。这样做借鉴了乐观锁的思想在线程安全的情况下保证了并发性能同时也解决了乐观锁失败率较高的问题一举多得。13审查 “DB 查工单并缓存” 的代码有什么问题常见问题这个到时候拿到具体项目里面去准备具体问题1. 缓存穿透查询不存在工单每次都会打到 DB2. 缓存击穿热点工单缓存过期大量请求打数据库3. 缓存雪崩大量 key 同时过期4. 缓存和 DB 双写不一致更新数据库没有正确处理缓存5. 没有处理缓存序列化、过期时间6. 并发下缓存更新逻辑出现竞态条件。【可选扩展深挖补充】 对应解法缓存穿透存空值,使用布隆过滤器击穿用互斥锁、热点永不过期雪崩设置过期时间随机偏移更新优先删除缓存根据业务选择一致性策略。14什么是 AI AgentAI Agent 是基于大语言模型为核心具备环境感知、目标理解、自主规划、工具调用、执行反馈、自我迭代能力的智能自治系统。区别于传统问答模型它以目标为导向可以自主拆解复杂任务、主动执行操作、闭环完成完整业务流程是具备行动能力的智能体。15AI Agent 和普通 Chat 聊天机器人的核心区别是什么核心区别体现在四点1、能力维度普通机器人仅支持被动问答Agent 支持主动规划、自主执行、多轮迭代2、工作模式普通模型单次响应Agent 形成「感知 - 规划 - 执行 - 反馈」闭环3、任务能力普通模型仅处理简单对话Agent 可落地复杂长流程任务4、拓展性普通模型无工具联动能力Agent 可无缝调用各类外部工具、API、知识库。16何时需要分布式事务有哪些方案当一个业务操作需要跨多个服务、多个数据库资源要求所有操作要么全部成功要么全部回滚单库本地事务满足不了的时候就需要分布式事务。常见方案有 2PC、TCC、SAGA、本地消息表、RocketMQ 事务消息还有 Seata 框架它封装了 AT、TCC 这些模式其中 AT 模式业务无侵入使用最多。2PC 分为准备阶段和提交阶段有协调者缺点是存在阻塞、协调者单点问题性能差适合短事务TCC 分为 Try、Confirm、Cancel 三个接口业务层自己实现补偿逻辑侵入性强性能较好适合高并发核心场景SAGA 把分布式事务拆成一串本地事务每个事务配补偿操作适合长事务本地消息表和 RocketMQ 事务消息属于最终一致性方案异步执行适合接受短暂数据不一致的业务AT 是 Seata 默认模式基于 undo log 记录快照自动回滚业务几乎不用改代码。 另外优先考虑业务优化尽量避免引入分布式事务。17有 AI Coding 工具后程序员还要会写代码吗需要。AI Coding 适合做样板代码、DTO、单测、脚本提升效率。 但方案选型、业务理解、并发、事务、资损风险、边界校验需要人来把控AI 会产生幻觉可能写出隐藏 bug。程序员需要看懂、校验、修改 AI 产出定位根因承担线上责任。AI 是放大器不是替代。18从零设计云产品智能客服知识、资源、排障和转人工。1. 知识层知识库RAG 检索存储产品文档、FAQ做文档分块、向量库2. 资源层对接业务后端接口工具调用 Function Calling查询用户工单、账单信息3. 排障Agent 工具调用执行排障步骤采集日志无法解决给出排障指引4. 转人工触发条件多次回答无效、用户主动要求、涉及资损高危场景把会话上下文、历史问答一并带给人工客服。 配套会话记忆管理、权限控制、SSE 流式输出、知识库管理后台。【可选扩展深挖补充】 增加评价反馈用户反馈好坏迭代知识库设置相似度阈值避免幻觉回答。19AI Coding 的前端开发与交付方式AI Coding 是辅助手段。一般是后端先输出接口契约AI 辅助生成前端页面组件、样式人去校验交互逻辑、边界异常、联调后端接口。交付物还是标准前端工程正常打包部署。20前端是否主要使用 AI Coding 开发是的但是不会完全交给 AI。AI 可以快速生成样板页面、组件提升开发速度但是业务交互逻辑、异常处理、兼容性需要人修改、校验不能直接交付。21AI Coding 是否涉及端到端交付可以做端到端原型快速生成但不能直接线上交付。AI 生成端到端代码经常存在逻辑漏洞、边界缺失需要人工 review、自测、联调之后才可以交付上线。22当用户对智能机器人说“帮我向前移动 2 米并打开照明灯”时如何利用大模型的 Function / Tool Calling 机制输出结构化指令如果大模型在某些情况下返回了缺漏字段的 JSON例如只给出了动作类型遗漏了距离参数在后端工程上应如何设计校验与兜底逻辑工具调用流程预先定义move移动、turn_light开灯两个工具描述传给大模型。用户输入后大模型识别要执行两个工具输出结构化 JSON 数组一条控制向前移动 2 米一条打开照明灯。后端拿到 JSON分别调用对应硬件接口执行动作。缺字段兜底 ①后端做 JSON Schema 强制校验校验必填字段缺失直接拦截 ②字段缺失把错误信息回传给大模型让模型重新补全参数 ③增加业务兜底关键参数缺失不向下发硬件指令拒绝执行返回提示用户补充信息。23在 RAG 流程中将文本转为向量Embedding并在向量数据库中计算余弦相似度的本质是什么在切分长文档时切片过长或切片过短分别会引发什么问题余弦相似度本质把文本映射高维向量空间用向量夹角大小衡量两段文本语义相似程度夹角越小语义越接近。切片过长块里面包含大量无关内容引入噪声检索出来无关信息干扰大模型切片过短语义被截断丢失上下文语义碎片检索相关性下降。24如果需要让机器人精准回答“设备机密维修手册”或“最新排班表”为什么通常采用 RAG检索增强生成方案而不是全量微调Fine-tuning模型请简述 RAG 的三个核心环节。选 RAG 原因 1. 文档经常更新微调要重新训练成本高RAG 直接更新知识库即可 2. 机密数据微调会把知识固化进模型权重存在泄露风险RAG 知识库可以做权限管控 3. 微调成本高需要大量高质量样本RAG 不需要训练模型。RAG 三大核心环节文档处理与分块、向量检索召回、将检索片段注入 prompt 交给大模型生成答案。25AI 编写的代码在本地运行时报出了一长串报错日志如由于第三方库版本更新导致函数不存在或混淆了同步与异步调用。你的排错流程是怎样的如何甄别 AI 给出的修复代码是否可靠排错流程 1. 先定位报错栈确认报错位置、报错原因 2. 区分是依赖版本问题、同步异步问题还是业务逻辑问题 3. 复现问题最小复现案例 4. 再参考 AI 给出修复方案而不是直接复制粘贴。甄别修复代码1. 看修复逻辑是否匹配报错栈 2. 检查有没有引入新幻觉 API 3. 阅读代码逻辑手动梳理流程 4. 写完做单元测试本地复现验证。26说一下用户数据库配置错误兜底方式分多层兜底1.前置校验配置下发时校验地址、账号、端口格式2.连接探测Agent 拿到配置先轻量 ping / 测试连接3.捕获连接异常、权限异常区分报错文案返回给用户不直接抛堆栈4.熔断连续多次配置错误停止重试5.配置隔离坏配置不影响其他 Agent 实例。27数据库动态变更不重启服务可以应用 Agent 吗可以。不用重启靠配置中心Nacos/Apollo监听配置变更感知数据库连接信息变更Agent 注册监听器收到变更后优雅关闭旧连接池新建连接池切换数据源。28说一下 Agent 接入一个新的 MCP 的完整流程1. 定义 MCP 工具元信息名称、描述、入参 schema、出参 schema2. 注册到 Agent 工具注册表3. 编写调用适配器封装请求、参数映射、异常捕获4. 给模型的 system prompt 注入这个工具描述让模型知道什么时候调用5. 增加权限、限流、超时配置6. 测试触发模型调用、校验返回、异常 case 验证最后上线埋点统计调用成功率。29消息回调是怎么做的两种主流方式1.HTTP 回调Agent 执行完工具 / 任务主动调用业务方提供的回调地址带上结果2.MQ 消息回调执行完成投递消息到指定 topic消费方监听。同时做幂等加唯一回调 ID失败支持重试、死信兜底。30用户输入轮次过多导致模型注意力分散怎么处理1.会话摘要定期对历史对话做摘要压缩精简历史2. 按重要性做记忆分级长期重要信息存向量库不重要的轮次直接丢弃3. 控制历史轮数上限轮数到阈值触发裁剪4. 优先保留和当前问题相关的历史无关对话过滤。31上下文超出模型 token 怎么处理分层策略优先统计 token 数量超过阈值先裁剪低相关性历史再做对话摘要压缩RAG 场景减少召回文档片段最后兜底截断同时给模型提示避免丢失关键指令。32文档召回的 benchmark评估指标设计召回基础指标召回率、精确率、F1业务指标问答准确率、幻觉率、用户满意度还有时延、召回数量上限。构造 query - 标准文档标注数据集跑 benchmark。33Agent 节点流转过程中运行情况分析Agent 是状态节点流转思考→工具调用→拿到结果→继续思考。埋点记录每个节点耗时、状态、输入输出看是否卡在工具调用、是否频繁重试、是否循环调用工具统计成功率、失败原因、链路耗时。34AI Agent 的核心核心特征有哪些主要包含五大特征自主性、目标导向性、环境感知性、工具交互性、自我反思性。无需人工逐轮指令可自主推进任务适配动态环境变化实时修正执行策略。35量化评估模型回答效果怎么做的两条路线自动评估人工评估。自动用评估模型打分检查是否引用检索文档、是否幻觉、是否符合问题人工标注做golden 标准计算准确率、幻觉率同时收集用户反馈标签。36单个文档是如何分割的用滑动窗口切分固定 chunk 大小 重叠优先按语义、标题、段落边界切尽量不切断语义长文本切成多个片段每个片段单独向量化入库。37说一下后端项目中涉及到的高并发场景有的我们项目中有几个典型的高并发优化场景。场景一学习记录上报优化问题用户看视频时每隔几秒上报一次播放进度如果每次都写数据库高峰期数据库扛不住。优化播放进度先写 Redis 缓存毫秒级响应通过 DelayQueue 延迟队列检测用户是否离开只有用户离开后才做一次数据库持久化从每几秒写一次DB优化为每个视频只写一次DB数据库写入量下降了90%以上场景二优惠券领取的异步化问题领券接口同步执行校验 → 写记录 → 扣库存响应慢、吞吐低。优化前置校验全部在 Redis 中通过 Lua 脚本完成毫秒级后续持久化通过 MQ 异步完成接口响应时间从几百毫秒降到几十毫秒吞吐量提升数倍场景三积分排行榜的读写分离问题积分排行榜需要实时展示如果每次都从数据库查性能差。优化当前赛季排行榜用Redis ZSet存储查询排名 O(log N)实时更新 O(log N)历史赛季数据按月分表通过定时任务从 Redis 迁移到 MySQL前端展示只取 Top 100数据量可控场景四优惠券方案的多线程并行计算问题预下单时需要枚举优惠券的所有排列组合逐个计算优惠金额方案多时串行计算慢。优化用 CompletableFuture 自定义线程池并行计算所有方案配合 CountDownLatch 设置2秒超时把计算时间从几百毫秒压缩到几十毫秒38说一下 Redis 的压测方式用 redis-benchmark 工具指定并发数、请求量、命令也可以用 JMeter压测关注 QPS、延迟、CPU、内存测热点 key、大 key 场景看是否有瓶颈。39说一下 Redis 的数据类型答很多比如String、Hash、Set、SortedSet、BitMap等面试官追问能不能具体说说使用的场景答比如很多的缓存我们就使用了String结构来存储。还有点赞功能我们用了Set结构和SortedSet结构。签到功能我们用了BitMap结构。就拿签到来说吧。因为签到数据量非常大嘛而BitMap则是用bit位来表示签到数据31bit位就能表示1个月的签到记录非常节省空间而且查询效率也比较高。点赞业务功能答我们使用了两种数据结构set和zset首先保存点赞记录使用了set结构key是业务类型业务id值是点赞过的用户id。当用户点赞时就SADD用户id进去当用户取消点赞时就SREM删除用户id。当判断是否点赞时使用SISMEMBER即可。当要统计点赞数量时只需要SCARD就行而Redis的SET结构会在头信息中保存元素数量因此SCARD直接读取该值时间复杂度为O(1)性能非常好。为什么不用用户id为key业务id为值呢如果用户量很大可能出现BigKey您说的这个方案也是可以的不过呢考虑到我们的项目数据量并不会很大我们不会有大V因为点赞数量通常不会超过1000因此不会出现BigKey。并且由于我们采用了业务id为KEY当我们要统计点赞数量时可以直接使用SCARD来获取元素数量无需额外保存这是一个很大的优势。但如果是考虑到有大V的场景有两种选择一种还是应该选择您说的这种方案另一种则是对用户id做hash分片将大V的key拆分到多个KEY中//结构为 [bizType:bizId:userId高8位]不过这里存在一个问题就是页面需要判断当前用户有没有对某些业务点赞。这个时候会传来多个业务id的集合而SISMEMBER只能一次判断一个业务的点赞状态要判断多个业务的点赞状态就必须多次调用SISMEMBER命令与Redis多次交互这显然是不合适的。此处略停顿等待面试官追问面试官可能会问“那你们怎么解决的”。如果没追问自己接着说所以呢我们就采用了Pipeline管道方式这样就可以一次请求实现多个业务点赞状态的判断了。40Redis 缓存雪崩击穿穿透介绍以及应对方式穿透查不存在 key大量请求打 DB → 存空值、布隆过滤器。击穿热点 key 过期大量请求打 DB → 永不过期、互斥锁。雪崩大量 key 同时过期DB 压力暴增 → 过期时间加随机偏移、集群隔离、熔断降级。41Redis 速度快的原因第一Redis 是纯内存数据库数据都存在内存内存读写远快于磁盘第二采用单线程模型没有多线程锁竞争、上下文切换开销第三IO 多路复用一个线程可以管理大量客户端连接第四数据结构都是高度优化的底层结构比如SDS、跳表、压缩列表第五协议简单文本化 RESP 协议解析开销小第六RDB/AOF 持久化是后台子进程做不阻塞主线程。42介绍 Spring 的 IOC 和 AOPIOC 控制反转把对象创建、依赖交给 Spring 容器管理解耦DI 依赖注入是 IOC 的实现方式。AOP即面向切面编程在Spring中用于将那些与业务无关但对多个对象产生影响的公共行为和逻辑抽取出来实现公共模块复用降低耦合。常见的应用场景包括公共日志保存和事务处理。SSM框架 - 飞书云文档这个里面有其所有的面试题43说一下 hashmap常见集合篇 - 飞书云文档这个链接拉到最下面就是全部的hashMap面试题44什么是 LLM Agent核心优势是什么LLM Agent 是以大语言模型为核心大脑的智能体依靠 LLM 的自然语言理解、逻辑推理、文本生成能力完成任务拆解、决策判断、内容输出。核心优势无需大量标注数据、自然语言交互零门槛、泛化能力强、适配各类非结构化场景、快速落地业务。45简述 AI Agent 的完整工作闭环1、感知输入接收用户指令、环境信息、历史上下文2、目标解析精准识别核心需求与任务边界3、任务规划拆解复杂目标为可执行子任务4、行动执行调用工具、检索知识、生成内容5、结果反馈校验执行结果、判断是否完成目标6、迭代优化自我反思问题修正策略完成闭环。46AI Agent 主要可以落地哪些业务场景主流落地场景智能办公自动化、知识库问答、数据分析报告、代码开发调试、智能客服、自动化运维、多角色内容创作、私人智能助手、企业流程自动化。47AI Agent 的五大核心模块是什么各自作用1、感知模块接收用户输入、系统状态、环境数据2、记忆模块存储会话、任务、用户、知识信息3、规划模块拆解任务、制定执行路径、处理任务依赖4、决策执行模块选择工具、生成指令、执行任务5、反思反馈模块校验结果、排查错误、迭代优化策略。48简述 Agent Memory 模块的分类及应用场景分为四类1、短期记忆当前会话上下文实时交互使用2、长期记忆用户偏好、历史任务、核心知识持久化存储3、任务记忆记录当前任务进度、状态、执行日志4、知识记忆外部知识库沉淀的业务知识支撑专业问答。49什么是 Agent 规划Planning主流规划方式有哪些规划是 Agent 将复杂模糊目标拆解为有序、可执行子任务的核心能力。主流方式链式规划、树状规划、逐步拆解规划、反思式规划、重试修正规划适配简单到复杂各类任务场景。50什么是 ReAct 架构在 Agent 中的作用ReAct 是 LLM Agent 经典架构核心是推理Reasoning 行动Acting交替执行。模型先推理任务逻辑、判断是否需要工具再执行对应操作获取结果后再次推理有效解决纯生成模型幻觉问题大幅提升任务准确率。51末尾页
