摸鱼酱在coding level
获赞
60
粉丝
20
关注
0
看过 TA
223
浙江大学
2026
C++
IP属地:浙江
后端转Agent开发 xhs同名
私信
关注
05-28 20:12
浙江大学 C++
最近帮不少同学看了Agent开发方向的简历。能明显感觉到,能过初筛的简历,其实不一定项目多复杂,但都有一些共同特点。而很多简历被刷,也往往是因为几个重复出现的问题。下面这些问题,我几乎在每份简历里都会看到,对照看看你的简历有没有中招。1、把团队项目写成个人独立这是比较危险的写法,也是最常见的。项目描述里写着"多智能体协作系统",但每一条bullet都是"我实现了 X""我负责了 Z",涵盖了从模型训练到前端推送、从检索模块到容错机制的全部内容。一个人在一两个月内独立完成所有这些板块,面试官可能存疑。问题不在于参与了团队项目,而在于没有把自己的边界画清楚。如果追问"这部分你自己写的还是有人配合",答案是"有人配合",但简历上写的是"我实现了",整份简历的可信度都会被打折。正确的做法是收窄范围、写深细节,独立负责的两三个模块,认认真真写清楚技术细节和效果。范围缩小了,每一条反而更可信,面试官也更容易顺着你写的方向深挖。2、有数字,但baseline不清楚数字本身不是问题,baseline不明确才是问题。"召回率提升 25.9%""平均压缩率 62.6%"这些写在简历上看起来很有说服力,但面试官的下一句话一定是:"相比什么提升的?怎么测的?测试集是什么?"如果回答不上来,这个数字就从加分项变成了减分项。面试官会开始怀疑:这个数字是精心设计的测试条件下跑出来的,还是真实场景的效果?更麻烦的是,有些数字写出来反而会自己暴露问题。比如 7路并行说效率提升 70%,这意味着大部分任务是串行的,面试官一追问"那并行的部分是哪些,为什么其他部分不能并行",反而把系统设计的弱点暴露出来了。还有一类是"理论值型"数字,比如 N 路并行加速比"接近 N 倍",在有网络 IO 和 LLM 调用的 Agent 场景里,这个数字几乎不可能出现,听起来就是理论上限而不是实测结果。3、两个项目方向完全不搭一份简历里,一个项目是 Agent 应用开发,另一个是系统编程或算法研究,两者之间没有任何叙事联系。两个项目平权放着,篇幅差不多,面试官读完不知道主方向是什么。如果和 Agent 无关的项目篇幅反而更长、细节反而更丰富,面试官会产生疑问,Agent 项目是你真正主攻的方向,还是顺手做的实验室小活?这个疑问一旦有了,对 Agent 项目的可信度也会打折。项目之间不搭,有时候是因为经历本来就跨方向,没办法。但写法上可以做处理:和投递岗位关系不大的项目,压缩到三四行,只保留"我有这方面底子"的标签信号,细节全砍;主项目展开写,把篇幅和密度都给它。更好的做法是找到两个项目之间的联系,哪怕只是"系统编程项目证明了我有 C++ 工程能力,Agent 项目体现了我把这个能力用在了大模型应用上",有了这条线,两个项目就不再是割裂的,而是互相支撑的。4、bullet只说了做了什么,没有怎么做和结果这是最普遍的问题,几乎每份简历都有。"构建了包含意图理解、动态检索、文档过滤和流式生成的完整 Agent 工作流。"读完知道你做了这个东西,但不知道难点在哪,不知道你的技术选择是什么,不知道做完之后效果怎么样。"完整工作流""全流程闭环""端到端链路",这类词不传递任何信息,面试官看到只会跳过。一条合格的 bullet 应该包含三件事:做了什么 + 怎么做的(关键技术选择) + 解决了什么问题或达到了什么效果。缺"怎么做的",没有区分度。缺"效果",面试官不知道这件事做没做成、做到什么程度。三件事齐全,才能给面试官一个可以深挖的入口。效果不一定是百分比。"从需要人工介入降到全自动运行""时延从 1.4s 降至 360ms",有具体对比就比形容词强。最后写简历的时候有一个最简单的自测方法:把每一条 bullet 单独拿出来,问自己"如果面试官对这句话感兴趣,连续追问三个问题,我能不能全部答上来"。答得上来的留,答不上来的,要么删要么补完细节再写。简历的作用是给面试官提供一个可以深挖的入口,能撑住追问的 bullet,才是真正的加分项。
0 点赞 评论 收藏
分享
05-24 16:55
浙江大学 C++
最近复盘面试的时候,我越来越明显地感觉到一件事:面试里“稳”这个东西,真的不完全等于项目有多强。有些人项目经历看下来其实不算特别炸裂,做的东西也未必比别人复杂多少,但一开口就会让人感觉很舒服。不是那种特别会包装、特别会吹的感觉,而是他说话的时候,你能明显感觉到他脑子里是有线的,知道自己在讲什么,也知道面试官为什么会问这个。反过来,有些人项目其实不差,甚至做过的东西更多,但一到面试里就是会显得虚。不是不会,而是讲出来的时候很散,东一句西一句,重点也不明确。我后来慢慢发现,那种“让人觉得稳”的表达,通常都有几个共同点。第一是他说问题的时候,不会一上来就堆名词。很多人讲项目特别喜欢先报菜名,什么用了RAG、用了Multi-Agent、用了Tool Calling、用了向量库,听起来很满,但其实听完之后你还是不知道这个项目到底解决了什么问题。相对稳的人一般不是这么讲的,他会先把背景和目标说清楚,再去讲方案。这样哪怕项目本身没那么复杂,也会显得非常清楚。第二是他会自然带出“为什么”。这一点我觉得特别关键。很多时候面试官并不是想听你做了什么,而是想听你为什么这么做。比如为什么要拆成多个Agent,为什么这里要加RAG,为什么不用更简单的办法。如果一个人回答里经常能自己把“为什么”带出来,会很容易让人觉得他不是在背,而是真的理解过这套东西。第三是他讲的时候是有边界感的。这个其实很容易被忽略。有些人一回答问题就越说越多,生怕漏掉,最后把自己绕进去。稳的人反而通常会先把问题收住,先给一个比较清楚的主线,再根据面试官反应决定要不要往下展开。你会觉得他不是在拼命证明自己懂很多,而是在很自然地把自己最核心的理解交代出来。第四是他对“不完美”这件事是有准备的。这个特别真实。项目里很多东西本来就不可能设计得特别完美,面试官也知道。所以真正让人觉得稳的,不是你把方案吹得毫无缺点,而是你能承认它有什么限制、当时为什么这么取舍、如果继续做你会往哪改。这个反而比一味说自己方案多好更有说服力。我自己前几次面试最明显的问题,其实就是项目不算太差,但讲出来没有那种“稳感”。脑子里是有内容的,但一开口就开始担心自己讲不全,于是拼命往里面塞东西,最后反而把重点冲掉了。项目强不强当然重要,但能不能把一个项目讲得有主线、有取舍、有边界,很多时候更直接影响面试体验。尤其是这种本身就容易被往深了问的岗位,如果你一开口就能让对方感觉到你不是在堆概念,而是在讲一个自己真的理解过的系统,后面的很多问题其实都会顺很多。有时候面试官觉得你“稳”,不一定是因为你什么都会,而是因为你让他相信:你知道自己会什么,也知道自己不会什么
0 点赞 评论 收藏
分享
05-24 01:05
浙江大学 C++
说一个我每次面试前都会做的事。不是临时抱佛脚,是一套固定的热身流程。从暑期实习面到秋招再到春招,反复验证下来效果很稳。总共一个小时,分三段。前30分钟:过面经八股这30分钟不是用来背新东西的,是回忆已经准备好的内容。我会看整理的按模块分好的面经文档,不是随手收藏的帖子,是每个问题我自己消化之后用自己的话重新写一遍的版本。后端四块:数据库、计算机网络、操作系统、C++;agent方向再加:LLM基础、RAG链路、Agent范式、工程落地。每个问题下面除了答案,还有我自己加的"追问方向"——就是这个问题通常会被往哪里深挖,我提前想好怎么接。30分钟看这份文档,看的方式是在脑子里模拟开口。不是默读答案,想象面试官现在问了这个问题,我开口第一句说什么,中间分几个点,大概说多久,收尾怎么收。走一遍之后基本就热起来了。节奏不用慢,这轮的目的是激活,不是学习。真正不会的知识点现在也补不回来了,盯着看只会焦虑,过就好了。有一类题要单独留意:上一场面试答崩了的。我的习惯是每场面试当天晚上就把没答好的问题补进文档,打一个标记。下次面试前这30分钟,这些题要多停两秒,把逻辑重新捋一遍,确认自己现在能说清楚了。这是我在秋招后期越面越顺的核心原因——每次挂都在给下一次喂料。中间20分钟:过项目这段是三块里最容易被忽视的,但我认为是最关键的。很多朋友说面试前只看八股,觉得项目又不会忘,不用过。但问题恰恰出在这里——项目不是忘了,是临场组织不出来。面试官问"介绍一下你的XX项目",你开口,说了两句突然不知道重点在哪,或者被追问一个细节,明明当时亲手做过,楞了三秒说"这个……我想想"。这种感觉不是不会,是没热身。我把每个项目整理成固定结构:项目背景一句话 → 我负责什么模块 → 核心技术决策是什么、为什么这么选 → 过程中踩了什么坑、怎么解的 → 最终结果或收益。这20分钟就是把这个结构在脑子里完整走一遍,不用出声,但要具体,要能想到细节,不能走个大概。重点过两类内容:一是技术决策的理由。 举个例子,AI Coding Agent里我为什么用AST解析来切代码而不是固定长度,当时是怎么发现问题的,怎么改的,改了之后效果怎么变。这些细节在做项目的时候是清楚的,但隔了两三个月再去面试,被追问的时候很容易答得很虚,"就是……感觉这样比较好",这种回答会让面试官觉得你对自己的项目没有真正的掌控感。专门过一遍,细节就回来了。二是之前被问过的追问点。 每场面试结束我会把项目被追问到的问题单独记一条,跟八股文档放在一起。有些问题在好几家面试里反复出现,说明这个项目天然会在这里被挖,必须每次上场前都确认自己能答清楚。比如我的MiniSQL,几乎每次都会被追问"Clock算法的延迟删除具体怎么实现的",B+树会被问"合并和分裂的触发条件",过了两三次之后这些问题简直像条件反射。这20分钟结束之后,每个项目的讲法应该是清晰有顺序的,不是一团糊的印象。最后5分钟:顺自我介绍自我介绍要在投简历开始之前打磨好,这5分钟只是把它从"存储状态"切换到"待发射状态"。出声说两遍,不用很大声,听到自己说话的感觉就够了,主要是找语感,确认节奏是流畅的。我的自我介绍结构很固定,总共控制在3分钟以内:一句话身份(学校专业届)→ 实习经历 → 两个最想被问到的项目 → 一句话说为什么对这个方向感兴趣。说两遍的另一个目的是确认今天的开口状态。有时候睡眠不好或者太紧张,说话会有点卡,顺两遍自我介绍能感觉出来,也能提前调一下。如果说得顺,信心也会跟着起来一点。自我介绍还有一个容易被忽视的作用:你提到什么,面试官大概率先问什么。这是整场面试里唯一一个你能主动设置议题的时机。所以自我介绍里提到的项目,一定要是你最想被问、最有把握展开的那几个,而不是按时间顺序把所有经历流水账报一遍。还有一件事,这一个小时不去临时查任何很复杂/完全陌生的东西。尤其是不去查"XX公司面试高频题"——这种事应该在一周前干,不是一小时前。临时查到一个不会的知识点只有两种结果:要么来不及看完,要么看完了也没消化,还把自己搞得更慌。这一小时的目标只有一个:进入状态。状态稳了,发挥才能稳。
查看7道真题和解析
0 点赞 评论 收藏
分享
05-22 00:29
浙江大学 C++
很多设计题聊到最后,都会慢慢绕回“稳定性”这件事。一开始还没那么强烈的意识。觉得 Agent 设计题重点应该是架构怎么拆、工具怎么接、Memory 怎么存、RAG 怎么做,或者 Multi-Agent 怎么协作。结果面多了之后发现,这些东西聊着聊着,最后几乎都会被问到同一个方向:如果它出错了怎么办,如果它一直跑不回来怎么办,如果线上真的来很多请求怎么办。后来想想其实也挺正常。因为 Agent 这类系统和传统那种很固定的后端流程不太一样,它天然就更“不稳”。传统系统很多时候是你把规则写死,输入和输出路径都比较确定;但 Agent 不是,它中间有模型决策、有工具调用、有外部数据、有多轮上下文,链路一长,变量就会变得很多。只要中间任何一层开始飘,整个结果都可能跟着飘。所以面试官前面问你架构、问你 Tool Calling、问你 Memory,看起来像是在听方案,实际上很快就会往后问:这个方案怎么稳住。比如你说模型自己判断该调哪个工具,那下一句就可能是,如果它调错了呢;你说用了 Multi-Agent 去拆任务,那后面可能就会接,如果其中一个 Agent 输出错了,下游怎么处理;你说接了知识库做 RAG,那也很容易继续问,检索到了不相关内容怎么办,知识库更新不及时怎么办。Agent 设计题里最容易被忽略的一点就是,很多人会默认自己是在讲“理想链路”,但面试官其实更关心“非理想链路”。也就是说,你当然可以先讲正常情况下系统怎么跑,但如果你只会讲 happy path,后面大概率就会被一直追问。因为真正难的地方,本来就不是“它能不能工作一次”,而是“它能不能在复杂场景里别太失控”。而且这种稳定性,还不是只指服务别挂这么简单。它其实分很多层。最表层的是接口别报错、调用别超时,再往里一点是模型别乱调工具、别死循环、别把参数填错;再往后一点,是上下文别越跑越脏,Memory 别把旧信息带偏,多个 Agent 之间别互相污染;再工程一点,还会涉及监控、降级、重试、回滚、权限控制这些。现在再被问这种题,我会更有意识地去想两条线:一条是系统怎么工作,另一条是系统怎么出问题。很多时候后者反而更重要,因为 Agent 这类东西你只要真的做过一点,就会知道它最麻烦的从来不是第一轮跑通,而是后面怎么别失控。
0 点赞 评论 收藏
分享
05-19 17:19
浙江大学 C++
这段时间看了不少面经,也面了n场,有个感受挺明显的,很多问题表面上看是在问基础,实际上只是一个起手式。你如果只答第一层,后面基本都会被顺着往下拽。我感觉最容易被继续追问的,基本就这4个点。第一是执行过程。就是你这个Agent到底怎么跑起来的。很多人会先说模型、工具、知识库这些,但说完就没了。但面试官更想听的是,这个东西到底怎么动:用户一句话进来以后,先干嘛,后干嘛,什么时候决定去调tool,什么时候继续想和停。只要这块说不顺,后面就很容易被接着问:有没有loop,怎么判断结束,卡住了怎么办。第二是为什么这么拆。这个真的很高频,尤其你项目里只要提到了多Agent、多个tool、多个模块,基本都会被问。你说“因为这样更清晰”“更方便扩展”,一般都不太够。面试官后面大概率会接着问,那为什么不能放一起?拆了之后通信怎么做?成本是不是更高?挂一个会不会全挂?这块挺容易暴露问题的,因为很多时候自己做项目的时候只是“这样做了”,但没认真想过“为什么一定要这样做”。第三是失败怎么处理。这个点也容易继续往下挖。比如前面讲了Tool Calling、自动规划、知识库检索,面试官多半都会顺手问一句:那失败了怎么办?而且这里的失败不只是接口报错,还包括工具调错了、参数填错了、模型开始胡说、检索内容不相关、输出格式不对这种。很多人这时候第一反应就是 retry,但通常面试官还想再听:怎么识别是哪一层出的问题,怎么降级,怎么回退,怎么兜底。第四是怎么让它稳定。我现在感觉Agent面试到后面,几乎都会绕到这件事上。因为“能做”其实不算特别难,难的是“别乱做”。怎么防止它无限循环,怎么限制它调不该调的东西,怎么做状态管理,怎么做评估,怎么知道它到底是好是坏。尤其一旦你前面回答得比较像 demo 视角,后面面试官就很容易把你往线上场景拉,看你有没有想过真正在生产里会发生什么。所以我现在对面试的感觉是,它表面问得很散,今天问你RAG,明天问你Memory,后天问你Multi-Agent,但本质上老是在问同一类问题:这个系统到底是怎么跑的,为什么长这样,出问题怎么办,怎么别让它太飘。
发面经攒人品
0 点赞 评论 收藏
分享
05-18 01:53
浙江大学 C++
一开始我其实不太信这个。总觉得面试嘛,最后还是看你会不会,前面开场聊项目那几分钟顶多算热身,真正决定生死的还是后面那些技术问题。结果面多了之后,发现根本不是这样。很多场面试,前10分钟的状态,几乎已经决定了后面是“正常交流”,还是“被一路拷打”。如果开头讲项目的时候讲得顺,逻辑比较清楚,面试官一般会更愿意跟着你的节奏走。哪怕后面有一两个问题答得一般,对方也更容易把你当成“整体不错,有些点还可以再看”的那种候选人。相反,如果一上来项目讲得很乱,东一句西一句,自己都没把背景、目标、方案、结果说清楚,后面就很容易进入一种很被动的状态。面试官会默认你没有准备好,或者觉得你只是做过,但没有真正想明白,于是接下来问问题的方式都会变得更“审”。我自己有几场很明显。明明后面问到的东西,回头看其实都不算特别难,但因为开头没讲顺,整个人状态就有点飘。面试官一追问,我自己先慌了,越慌越想赶紧补,结果越补越碎。还有一个特别现实的点是,很多面试官其实前面也在观察你的表达习惯。你是不是一上来就只会堆名词,还是能把事情讲清楚;你是说了很多但没有重点,还是能抓住真正有价值的东西。这些东西虽然不写在JD里,但真的会影响对方后面怎么问你。有时候不是题变难了,而是对方在前面几分钟里已经决定了要怎么“测”你。所以现在我每次复盘,越来越重视开头那一段了。不是为了背一个固定模板,而是要把最核心的那几句话想清楚。项目背景怎么起,为什么做这个,系统大概怎么跑,我负责的关键点是什么,最难的地方在哪里。如果这几句自己都讲不顺,后面大概率也很难稳。复盘了三十多场之后,我现在最大的感受反而不是“哪些题最容易被问到”,而是一个更朴素的事:好的开头,真的能救很多东西。它不一定能直接让你拿下这场面试,但它至少能让你别那么快把自己送进被动局面里。尤其是这种本来就容易越问越深的岗位,一旦前面开场顺了,后面整场的体感都会不一样。现在回头看,很多挂掉的面试,可能不是输在某一道题,而是从第一段自我展开的时候,就已经开始掉链子了。
0 点赞 评论 收藏
分享
05-15 19:58
浙江大学 C++
上一篇发出来之后,私信和评论里问得最多的就是:"有没有具体项目可以参考",现在四个方向各挑了一个GitHub 高质量开源项目供大家参考。AI Coding:Aider44k+ stars,Apache 2.0最值得学的部分是 repo map。前一篇里讲过"为什么不能直接把整个仓库塞给模型",repo map 就是这个问题最早的开源答案之一:用tree-sitter解析代码,提取每个文件里的类、函数、关键定义,再用图算法算出哪些符号和当前任务最相关,只把这些塞进context。二改:repo map 适配熟悉的语言生态(Aider对Python/JS 最好Deep Research:GPT-Researcher27k+ stars,MIT核心是planner和execution两类agent分工:planner把研究问题拆成一组子问题,execution agents并行去抓信息,最后由publisher聚合成带引用的报告。为了控制成本,会按需在 gpt-4o-mini 和 gpt-4o 之间切,一次任务平均 2 分钟、几美分。二改:挑具体领域,比如医疗文献综述、行业财报对比、学术 survey,在被大部分项目忽略的环节上做深,评测体系、引用质量、矛盾信息的处理。AIOps:HolmesGPT2025 年 10 月成为 CNCF Sandbox 项目,Apache 2.0。只读权限和 RBAC 是写在架构层的,agent 没有误操作生产的能力二改方向:HolmesGPT 默认覆盖云原生场景,如果方向偏数据库、偏前端监控、偏业务告警,可以基于它的架构做垂直版本。长期记忆:Letta(原 MemGPT)22k+ stars,Apache 2.0Letta 是 agent runtime,整个 agent 跑在 Letta 里,记忆系统是它的核心而不是附加层。核心设计来自 MemGPT 论文:把 LLM 的 context window 当成虚拟内存来管。二改方向:挑一个很小但真实的场景,比如基于过去几个月聊天记录学写作风格助手,然后在 short-term/long-term怎么分、何时清理、怎么避免老信息污染上做扎实。
0 点赞 评论 收藏
分享
05-13 20:42
浙江大学 C++
最近看了不少 Agent 相关项目,我慢慢感觉:不是所有 Agent 项目都适合写进简历。有些项目看着挺热闹,功能也不少,但一到面试里其实不太好讲。你能把它跑起来,不代表你能把它讲清楚,也不代表它能撑住深入追问。值得写进简历的 Agent 项目,要能同时体现业务场景、系统设计和工程实现。我现在更推荐的,大概是这 4 类。第一类是 AI Coding / 代码仓库问答 Agent。 这一类很适合拿来写简历,也适合面试展开。好处是天然能把很多高频考点串起来:代码切片、RAG、Tool Calling、上下文组织、状态管理,往深了甚至还能聊 AST、调用链、测试生成这些内容。这类项目不只是“接了个模型做问答”,很容易讲成一个真正服务开发流程的系统。面试官一般也比较喜欢问,因为它兼具 Agent 和工程,不太容易沦为一个单纯套壳的 demo。第二类是 Deep Research / 联网搜索总结 Agent。 一个比较好的 Deep Research 项目,通常会涉及 query 拆分、搜索、多源信息抽取、去重、重排、结构化整理、最后生成带引用的结果。这里面既有 Agent 的规划和执行,也有工具协同和结果校验。对简历来说这类项目通常很占便宜,别人一看就明白做的不是简单聊天机器人,是真的在解决复杂任务的问题系统。第三类是 AIOps / 排障 Agent。 这个方向推荐给偏后端、平台或者基础架构一点的人。它天然和日志、指标、告警、知识库、runbook、故障定位这些东西绑在一起,一旦做出来,整个项目会非常有“真实业务系统”的味道。如果能把“告警来了以后怎么决定查哪些日志、什么时候需要人工接管、误报怎么处理”这些链路讲清楚,这种项目在简历里是很有含金量的。第四类是 长期记忆 / 个人知识库 Assistant。 很多人简历里都会写长期记忆、多轮上下文、个性化助手,但真问到“长期和短期怎么分”“什么时候写记忆”“怎么避免旧信息污染当前任务”,回答就会开始发散。这类项目适合拿来补“Memory 设计”这块的短板,它能把记忆系统真正做成一个能被深挖的点。
0 点赞 评论 收藏
分享
05-08 03:55
浙江大学 C++
我前面几场面试讲项目的时候,一讲出来总有一种“像看过,不像做过”的感觉。后来自己复盘才发现,问题很多时候不在项目本身,而在于我讲项目的时候太喜欢报菜名了。上来就是用了 RAG、用了 Tool Calling,听起来东西很多,但讲完之后,面试官其实还是不知道你这个项目到底在解决什么问题,你自己又到底做了什么。3月份的时候我意识到,一个 Agent 项目讲得像不像真的做过,不是提了多少技术词,是有没有把那些只有做过才会在意的东西讲出来。比如不要一上来先讲架构,而是先讲为什么会变成这个架构。如果只是说“我们用了多 Agent”,这句话其实很空;但如果说“最开始想用单 Agent,后来发现规划、检索和执行全塞在一起之后,链路太长,出错了也不好定位,所以才拆开”,这就一下子不一样了。因为前者是在报结果,后者是在讲你做决策的过程,后者会更像你真的参与过,而不是把一个现成方案复述一遍。还有一个很重要的点,就是少讲“系统有什么”,多讲“改了什么”。真正会让项目突然变得“像自己做过”的,往往是那些变化。原来怎么做的,后来为什么改,改完之后解决了什么问题,哪个地方当时犹豫过,最后为什么选了现在这个方案。哪怕改动不大,只要是具体的,就会比“做了优化”这种话有说服力得多。比如说一开始检索结果直接拼上下文,后来发现召回一多模型就会被带偏,所以又补了一层 rerank,把 topk 从 10 压到 5,这种话就很像真的做过,因为里面有问题、有改动。还有一点我觉得很关键,就是尽量少用那种很抽象的词,多讲动作。比如“做了状态管理”这句话本身没错,但太空了。更像自己做过的说法是,因为这个任务是多步执行的,中间结果后面还要继续用,所以把当前任务状态单独存出来,不然某个 Tool 超时以后很难从中间恢复。只要开始用动作替代名词,整个项目就会一下子真实很多。我感觉,项目讲得像不像自己真的做过,不是看讲了多少,而是看有没有把这些东西说出来:为什么这么设计,具体改了什么,哪里出过问题,当时怎么处理的,哪些地方现在还不完美,但知道问题在哪。
查看5道真题和解析
0 点赞 评论 收藏
分享
04-28 22:40
浙江大学 C++
1、工具调用失败或 LLM 幻觉,怎么办?"我会把这个问题拆成两个子问题,因为工具失败和 LLM 幻觉是完全不同的故障模式,解法不能混用。工具失败有明确信号——异常、超时、错误码——我的处理是三层:先用指数退避重试,重试前让 LLM 反思上次参数哪里出了问题,相当于让模型自我纠错;重试耗尽后降级到备用逻辑,比如换一个工具或走规则引擎;如果涉及写操作,每次执行前必须记 Checkpoint,失败后能回滚到上一个干净状态,且写操作要做幂等,防止重放。LLM 幻觉更难检测,因为没有报错。我的做法是:对关键推理结果做 Self-consistency 验证,同一问题采样三次,少数服从多数;对外部事实型问题,用第二个模型做交叉 Fact-check;对于高风险操作,强制加 Human-in-the-loop 确认节点,不管模型多确定都要过人工。生产上我会为每个 Agent 实例暴露健康度指标:工具失败率、幻觉拦截率、平均重试次数,超阈值自动熔断并告警。这样从 demo 到上线,容错体系才是完整的。"2、Agent 的 Memory 怎么设计?"我把 Agent Memory 设计成三层,对应人类记忆的三种形式。第一层是 Working Memory,就是当前 LLM 的 Context Window,存当前任务的执行状态和工具调用历史。它的核心问题是容量管理——超出 window 时我不会直接截断,而是对老的消息做摘要压缩,保留语义但压缩 token。第二层是 Episodic Memory,存历史任务轨迹和用户偏好,用向量数据库按相似度检索。写入是任务结束后异步进行,不阻塞主链路。这层需要遗忘机制——我用一个重要性评分:访问频率乘以时效性衰减再乘以任务相关度,低分记录定期压缩,避免向量库无限膨胀。第三层是 Semantic Memory,存领域知识。这里有一个选型决策点:非结构化知识用向量检索,强结构化的多跳实体关系用 Knowledge Graph——向量库做多跳关系推理效率很差,这是实际踩过的坑。多 Agent 场景还要解决共享 Memory 的一致性问题:写操作加版本号做乐观锁,读操作做版本校验,防止多个 Agent 并发写入产生脏数据。"
查看2道真题和解析
0 点赞 评论 收藏
分享
04-13 01:52
浙江大学 C++
我最近把AI Agent面经从0到1全部梳了一遍(含字节、阿里、腾讯真实面试),发现面试官真正想听的根本不是定义。很多人(包括苯人一开始)以为Agent面试就是背ReAct、背Tool Calling、背LangChain,结果一开口就被面试官打断:“这些我都知道,你说说你的设计思路。”我问懵过两次后才醒悟,Agent面试不是八股,是体系考察。下面这3个问题,几乎是每场面经中必问,🐮友们看看自己会不会踩坑。1.如果你做一个Agent,遇到工具调用失败或者LLM幻觉怎么办?我当时直接答“加retry”或“加human in the loop”,秒挂后面问claude,面试官想听的是完整容错体系:- 怎么判断是工具错还是LLM幻觉?- 用另一个LLM做fact-check / self-consistency- 降级到弱Agent / 规则引擎 / 人工兜底- 失败后状态怎么回滚?- 生产环境怎么监控Agent健康度2. Agent的Memory你怎么设计?大多数人(和我一样会说短期用ConversationBuffer,长期用向量数据库,直接寄。面试官想听的是分层记忆体系 + 读写策略:- Working Memory(当前任务上下文)- Episodic Memory(历史任务轨迹)- Semantic Memory(领域知识)- 什么时候用向量检索?什么时候用Graph?- 遗忘机制怎么做?(重要性评分 + 定期压缩)- 多Agent共享Memory时的读写锁和一致性问题3.单Agent和Multi-Agent你什么时候选哪个?怎么协作?”如果直接说任务复杂就用Multi基本凉。真正要讲的是决策框架:- 任务可分解性、通信成本、调试难度、单点故障风险- 协作模式(Hierarchical / Decentralized / Mixture-of-Agents)- 协调机制(Shared State / Message Queue / Supervisor)- 实际项目里Multi-Agent带来的收益和踩过的坑
查看3道真题和解析
0 点赞 评论 收藏
分享

创作者周榜

更多
关注他的用户也关注了:
牛客网
牛客网在线编程
牛客网题解
牛客企业服务