小红书AI Agent一面凉经 ！！！

面了70分钟从Agent架构问到JVM类加载最后扔一道算法题。我人没了。上周面了小红书的AI Agent岗位。投的时候以为是聊Agent、聊LLM、聊Prompt优化结果面试官后半程画风一转——Java线程池、MySQL两阶段提交、JVM类加载全给安排上了。直接裂开。嗯把还记得的21道题整理出来答案也一并写了。希望对准备类似岗位的朋友有点帮助。简单介绍一下自己的经历以及为什么选择AI Agent方向这个问题基本是开场必问。别背简历面试官想看的是你的思考过程。我的回答思路把经历串成一条线——之前做后端开发时遇到了哪些自动化难题当时用传统规则引擎解决但随着业务复杂度的上升发现规则根本维护不动。后来接触到LLM发现用自然语言做任务拆解和决策的思路很自然就转了Agent。标准答案参考AI Agent的核心价值在于它赋予了LLM与外部世界交互的能力。传统LLM只是被动回答问题而Agent能主动调用工具、执行计划、完成复杂任务。选择这个方向是因为我认为下一代应用形态一定是“能做事”的模型而不是“能聊天”的模型。从技术角度看Agent涉及规划、记忆、工具调用、多智能体协作等多个维度每个维度都有足够深的技术挑战。平时开发过程中主要使用哪些AI Coding工具比如Claude Code这类工具通常有哪些使用习惯问这个是想看你是不是真的在用还是停留在“听说过”。我的回答Claude Code和Cursor都在用。习惯上不会直接让它写完整模块而是把大任务拆成小函数逐个让它生成或重构。写之前会给清楚输入输出格式、边界条件有时候还会故意给个错误示例告诉它“别这样写”。标准答案参考AI Coding工具的核心价值在于提升编码效率但使用方式直接影响效果。比较好的实践包括① 分而治之单个Prompt控制在单一函数或类层面② 提供充足上下文包括相关代码路径、数据结构定义、已有接口签名③ 迭代式优化先让AI生成初版再通过多轮对话逐步修正④ 对生成的代码做Code ReviewAI也会产生逻辑漏洞尤其是在并发和异常处理上。如何理解Spec Coding和Harness你认为Harness为什么能够提升Agent完成复杂任务的能力这个问题答得一般说实话平时更多是在业务里用Agent对Harness的研究不够深。回来查了不少资料。Spec Coding先把任务写成一份结构化的规格说明Spec包含输入格式、输出格式、约束条件、验收标准。Agent照着Spec干活而不是自由发挥。Harness可以理解为一个“Agent运行沙箱”。它把Agent的执行环境、工具集、上下文、日志全部封装起来。Harness提升复杂任务能力的三个原因约束执行空间不让Agent乱跑每一步都在边界内。可观测性每个中间步骤都被记录方便定位失败点。反馈闭环Agent执行完一个子任务后Harness能自动校验结果是否符合预期不符合就触发修正。其实就是把Agent“关进笼子里训练”容错率反而更高了。如果让你从零开始设计一个Agent系统你认为需要包含哪些关键模块面试官想看的不是背八股而是你真正设计过系统。我的回答四个核心模块——感知模块接收用户输入、解析意图、规划模块把大任务拆成子任务、决定调用哪些工具、执行模块实际调用工具/API、处理返回结果、记忆模块短期存对话上下文、长期存用户偏好和历史知识。另外还需要一个监控层记录每一步的输入输出方便debug。标准答案参考Agent系统核心模块架构├── 感知层 (Perception)│ ├── 输入解析器意图识别、实体抽取│ └── 上下文组装器融合历史记忆和当前输入├── 规划层 (Planning)│ ├── 任务分解器将复杂任务拆解为子任务DAG│ └── 决策引擎基于当前状态选择下一步动作├── 执行层 (Execution)│ ├── 工具调用器统一接口调用外部API│ └── 结果处理器解析并标准化返回结果├── 记忆层 (Memory)│ ├── 短期记忆对话上下文、当前任务状态│ └── 长期记忆向量数据库、知识图谱└── 监控层 (Observability) ├── 链路追踪记录每一步的输入输出 └── 异常告警超时、重试、失败率监控Agent在执行任务时如果调用外部工具或API出现超时、异常等情况一般应该如何设计容错机制我的回答说到了超时重试、指数退避、熔断器模式还提到了需要区分“可重试异常”如网络抖动和“不可重试异常”如认证失败。标准答案参考容错机制设计可以从这几个层次入手超时控制为每次API调用设置合理的超时时间不同接口超时阈值不同。重试机制采用指数退避重试避免雪崩。一般重试3次间隔 2^i 递增。降级策略主API不可用时切换备用方案如主模型超时则换小模型快速响应。熔断器错误率达到阈值后直接熔断快速失败返回兜底话术。异常分类区分临时性错误网络超时、限流和永久性错误参数错误、认证失败只有临时性错误才重试。# 简易重试逻辑def call_with_retry(func, max_retries3): for i in range(max_retries): try: return func() except TimeoutError: wait 2 ** i # 指数退避 time.sleep(wait) except AuthError: raise# 不重试 raise Exception(Max retries exceeded)是否考虑过让大模型参与错误分析和自动恢复这种方案有什么优缺点我的回答考虑过但生产环境不太敢用。优点是灵活大模型能理解各种奇怪的错误信息并给出修复建议缺点是稳定性差模型可能误判最坏情况是把一个本可简单恢复的错误搞得更复杂。标准答案参考优点错误信息是非结构化的传统规则很难覆盖所有情况大模型的理解能力强。能提供修复建议而不只是报错。缺点大模型自身的幻觉问题可能给出错误的分析结论。自动恢复操作有风险比如误删数据或错误地重试了非幂等操作。额外调用大模型会增加成本和延迟。折中方案让大模型做错误分析和建议但最终决策由人工或预设规则执行。或者只在低风险场景如对话体验优化中启用自动恢复高风险操作如数据库写入必须人工确认。Agent中的短期记忆和长期记忆分别有什么作用通常会如何实现我的回答短期记忆存当前会话的上下文保证多轮对话的连贯性长期记忆存用户画像、历史行为、知识库。短期用Redis或内存缓存长期用向量数据库加Embedding检索。标准答案参考短期记忆作用维持当前任务的状态记录已经完成哪些步骤、下一步要做什么。实现会话窗口Sliding Window保留最近N轮对话或者用Redis缓存当前会话的完整上下文。长期记忆作用跨会话的知识沉淀比如用户的偏好设置、之前解决过的问题。实现向量数据库如Pinecone、Milvus存储Embedding配合语义检索召回相关内容。也可以结合传统数据库存储结构化信息。两者配合的关键在于检索时机——不是每次对话都查长期记忆而是先由Agent判断“这个任务是否需要历史知识”再做检索节省Token。在Agent开发过程中上下文为什么需要进行压缩压缩后可能导致信息缺失应该如何解决我的回答主要原因是大模型的上下文窗口有限长对话或复杂任务容易爆窗口。压缩的常见方法有摘要和剪枝。标准答案参考为什么需要压缩成本Token越多调用成本越高。速度输入越长推理延迟越大。窗口限制虽然现在模型上下文已经很大如200K但超长上下文的推理效果会下降。压缩方法摘要压缩用LLM对历史对话生成简短摘要。剪枝去除冗余信息比如重复的中间步骤。向量检索替代不把全部历史塞进上下文而是按需检索相关内容。信息缺失的解决分层记忆保留完整的原始日志压缩的只是传入LLM的部分。如果发现信息不足可以回溯原始日志。重要性评分对每条信息打分压缩时优先保留高分信息。渐进式披露先给模型一个摘要如果模型判断需要细节再通过工具调用获取完整内容。压缩前[完整对话 50轮 工具调用记录 中间推理步骤] → 超长压缩后[摘要用户想订机票已选好航班等待支付] → 短信息缺失风险支付方式偏好、用户特殊要求等细节可能丢失解决方案关键信息用结构化字段单独提取不与摘要混在一起Prompt优化除了添加规则约束之外还有哪些常见的方法你在实际使用中有哪些经验我的回答Few-shot示例、结构化输出约束JSON Schema、思维链、角色设定、动态Prompt拼接。实际中最管用的是Few-shot给两个高质量示例比写一堆规则效果好得多。标准答案参考Few-shot / In-context Learning给2-3个高质量示例比写规则更有效。示例要覆盖边界情况。Chain-of-ThoughtCoT引导模型一步步推理而不是直接给答案。结构化输出约束指定输出格式JSON Schema、XML标签方便后续解析。角色设定System Prompt限定Agent的人格和知识边界比如“你是一个MySQL专家只回答数据库相关问题”。动态Prompt根据任务类型动态拼接不同的Prompt片段避免单一Prompt太臃肿。自我纠错指令在Prompt里要求模型在不确定时主动说明而不是瞎编。实际经验规则写太多反而让模型畏手畏脚容易拒绝正常请求。通常保留3-5条核心约束剩下的用示例来暗示效果更好。当模型出现幻觉问题时一般有哪些解决思路我的回答幻觉的本质是模型在“猜”答案而不是“查”答案。解决思路分两条线——一是限制模型自由发挥强制它引用外部知识源二是在后置环节做校验对明显不合理的输出进行拦截。标准答案参考RAG检索增强生成让模型基于检索到的外部文档回答不要依赖参数化知识。关键是检索质量要高。约束解码用JSON Schema或正则表达式约束输出格式减少自由文本生成中的幻觉。自我一致性多次采样对多次生成结果取交集或投票。事实校验对模型输出的关键事实用外部工具如搜索引擎、数据库查询交叉验证。不确定性表达要求模型在低置信度时明确说出“我不确定”而不是强行回答。如果Token消耗突然增加你会如何定位原因并进行优化我的回答先看是单次调用Token变大Prompt太长或输出太长还是调用次数变多任务变复杂、有循环。用日志分析工具统计Token分布定位到具体环节后再针对性优化。标准答案参考定位步骤分维度统计按任务类型、时间段、用户、Agent版本等维度拆分Token消耗。检查Prompt长度是不是某个场景下拼接了过长的上下文或知识库内容。检查输出长度模型是不是在生成冗余信息如重复解释。检查调用次数是不是进入了死循环或过度规划。优化手段Prompt压缩去除冗余指令合并重复约束。输出长度限制用max_tokens参数强制限制。缓存机制对相同或相似的Query缓存之前的回答。模型降级简单任务用小模型复杂任务才用大模型。工具调用精简减少不必要的工具调用合并多个操作为一个调用。你有没有设计过Agent Skill一个Skill从设计到上线通常需要考虑哪些因素如何判断效果好坏我的回答实际项目中设计过类似插件。关键考虑因素包括Skill的职责边界、输入输出Schema、错误处理、调用频率限制。标准答案参考设计阶段考虑职责单一一个Skill只做一件事不要大而全。输入输出Schema明确定义参数类型、必填/可选、格式约束。异常处理Skill内部异常要优雅降级不能拖垮整个Agent。幂等性同一个请求多次调用结果一致尤其是涉及写操作的Skill。超时设置不同Skill的超时阈值不同查询类可长一点写操作类要短。上线考虑版本管理Skill升级要兼容旧版调用方式。灰度发布先小流量验证再全量。监控告警成功率、延迟、调用量三个核心指标。效果判断客观指标调用成功率、平均响应时间、Token消耗。主观指标用户反馈、任务完成率。对比测试有Skill和无Skill的完成质量差异。介绍一下之前做过的相关项目这个项目是完全自主开发还是基于已有开源方案进行改造如实回答就好关键是要说清楚哪些是自研、哪些是借鉴、自己的贡献是什么。我的回答项目是基于开源框架LangChain做的二次开发但核心的调度逻辑和多Agent协作协议是自研的因为开源方案在任务编排上不够灵活。面试官关注点不是考你“能不能造轮子”而是看你有没有技术判断力——什么场景该自研、什么场景该复用。如果每个项目都从零开始写反而是减分项。在项目过程中遇到过哪些比较困难的问题你主要负责哪些部分最后取得了什么结果又是老生常谈的“项目难点”问题但Agent项目确实有些特殊的坑可以讲。我的回答最头疼的是多Agent协作时的死锁问题——Agent A等Agent B的结果Agent B又在等Agent A。解法是引入超时机制和优先级调度超时未返回的Agent直接跳过由主Agent做兜底决策。标准回答框架问题是什么 → 当时怎么想的 → 尝试了什么方案 → 最终怎么解决的 → 量化结果。Java线程池的核心参数有哪些线程提交任务后的执行流程是怎样的从这里开始画风突变从AI Agent直接跳到Java基础。我的回答七个核心参数——corePoolSize、maximumPoolSize、keepAliveTime、unit、workQueue、threadFactory、handler。提交任务后的流程是核心线程数未满则新建线程执行满了则入队队列满了则新建非核心线程线程数达到最大值则触发拒绝策略。标准答案参考// Java线程池核心构造参数public ThreadPoolExecutor( int corePoolSize, // 核心线程数 int maximumPoolSize, // 最大线程数 long keepAliveTime, // 空闲线程存活时间 TimeUnit unit, // 时间单位 BlockingQueueRunnable workQueue, // 任务队列 ThreadFactory threadFactory, // 线程工厂 RejectedExecutionHandler handler // 拒绝策略)执行流程如果让你重新设计一个线程池你会重点考虑哪些问题我的回答这个问题考察的是对线程池本质的理解而不是背参数。核心问题是“线程数设多少”。IO密集型和CPU密集型的线程数配置差异很大。标准答案参考线程数动态调整根据系统负载自动调整线程数而不是固定值。可以基于CPU利用率、队列深度等指标动态扩缩。任务分类隔离不同类型的任务IO密集型 vs CPU密集型使用不同的线程池避免互相影响。队列策略选择有界队列防OOM但无界队列可能堆积任务需要根据场景权衡。优雅关闭shutdown()和shutdownNow()的合理使用确保任务能安全终止。可观测性线程池的活跃线程数、队列大小、完成任务数等指标需要暴露出来。线程数配置公式CPU密集型线程数 CPU核数 1IO密集型线程数 CPU核数 * (1 等待时间/计算时间)JVM加载一个class文件的完整过程是什么我的回答加载 → 验证 → 准备 → 解析 → 初始化五个阶段。面试官追问了“准备阶段做了什么”回答是给类变量分配内存并设置初始值不是赋值。标准答案参考加载通过全限定名查找并加载class文件生成Class对象。验证确保class文件的字节流符合JVM规范防止恶意代码。准备为类变量static变量分配内存并设置默认初始值int为0引用为null。注意不是赋值阶段赋值在初始化阶段。解析将常量池中的符号引用替换为直接引用内存地址。初始化执行类构造器clinit方法初始化静态变量和静态代码块。MySQL中的undo log、redo log和binlog分别解决什么问题它们之间有什么区别我的回答undo log做事务回滚和多版本并发控制MVCCredo log做崩溃恢复保证事务持久性binlog做主从复制和数据恢复。标准答案参考undo logredo logbinlog层次InnoDB存储引擎层InnoDB存储引擎层MySQL Server层作用事务回滚、MVCC多版本并发控制崩溃恢复保证持久性主从复制、数据恢复内容逻辑日志记录数据变更前的旧值物理日志记录数据页的物理修改逻辑日志记录SQL语句或行变更写入时机事务执行过程中写入事务执行过程中写入WAL机制事务提交时写入循环/追加循环写入循环写入追加写入什么是MySQL两阶段提交为什么需要这个机制我的回答两阶段提交是保证redo log和binlog数据一致性的机制分Prepare阶段和Commit阶段。如果不做两阶段提交数据库崩溃恢复后可能出现主从数据不一致。标准答案参考两阶段提交2PC发生在事务提交时为什么需要2PC因为redo log和binlog是两个独立的日志写入时机不同。如果只写redo log不写binlog主从同步会丢数据如果只写binlog不写redo log数据库崩溃后事务无法恢复。两阶段提交确保要么两个日志都写成功要么都不算成功。算法题合并两个有序数组LeetCode 88题经典双指针。面试时写出来了但因为在前面Java和MySQL花了太多精力写的时候思路有点卡。标准答案public void merge(int[] nums1, int m, int[] nums2, int n) { int p1 m - 1; int p2 n - 1; int p m n - 1; while (p1 0 p2 0) { if (nums1[p1] nums2[p2]) { nums1[p] nums1[p1]; p1--; } else { nums1[p] nums2[p2]; p2--; } p--; } // nums2剩余元素直接copy while (p2 0) { nums1[p] nums2[p2]; p2--; p--; }}反问环节问了一个问题Agent方向的工程落地和前沿研究这个岗位更侧重哪个方向面试官说两者都涉及但当前阶段更关注工程落地能力——能稳定、高效地把Agent系统部署到生产环境比单纯追求SOTA模型更重要。这个回答其实也解释了他为什么后半程全在问Java和MySQL——Agent系统的稳定性严重依赖后端基础设施。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】