Agent项目面试复盘

我前面几场面试讲项目的时候,一讲出来总有一种“像看过,不像做过”的感觉。
后来自己复盘才发现,问题很多时候不在项目本身,而在于我讲项目的时候太喜欢报菜名了。上来就是用了 RAG、用了 Tool Calling,听起来东西很多,但讲完之后,面试官其实还是不知道你这个项目到底在解决什么问题,你自己又到底做了什么。
3月份的时候我意识到,一个 Agent 项目讲得像不像真的做过,不是提了多少技术词,是有没有把那些只有做过才会在意的东西讲出来。比如不要一上来先讲架构,而是先讲为什么会变成这个架构。
如果只是说“我们用了多 Agent”,这句话其实很空;但如果说“最开始想用单 Agent,后来发现规划、检索和执行全塞在一起之后,链路太长,出错了也不好定位,所以才拆开”,这就一下子不一样了。因为前者是在报结果,后者是在讲你做决策的过程,后者会更像你真的参与过,而不是把一个现成方案复述一遍。
还有一个很重要的点,就是少讲“系统有什么”,多讲“改了什么”。真正会让项目突然变得“像自己做过”的,往往是那些变化。原来怎么做的,后来为什么改,改完之后解决了什么问题,哪个地方当时犹豫过,最后为什么选了现在这个方案。哪怕改动不大,只要是具体的,就会比“做了优化”这种话有说服力得多。
比如说一开始检索结果直接拼上下文,后来发现召回一多模型就会被带偏,所以又补了一层 rerank,把 topk 从 10 压到 5,这种话就很像真的做过,因为里面有问题、有改动。
还有一点我觉得很关键,就是尽量少用那种很抽象的词,多讲动作。比如“做了状态管理”这句话本身没错,但太空了。更像自己做过的说法是,因为这个任务是多步执行的,中间结果后面还要继续用,所以把当前任务状态单独存出来,不然某个 Tool 超时以后很难从中间恢复。只要开始用动作替代名词,整个项目就会一下子真实很多。
我感觉,项目讲得像不像自己真的做过,不是看讲了多少,而是看有没有把这些东西说出来:为什么这么设计,具体改了什么,哪里出过问题,当时怎么处理的,哪些地方现在还不完美,但知道问题在哪。
全部评论
可以的,写的很好呢
1 回复 分享
发布于 05-09 23:21 北京
完整面经在xhs,同名
点赞 回复 分享
发布于 05-18 11:56 浙江

相关推荐

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 设计”这块的短板,它能把记忆系统真正做成一个能被深挖的点。
点赞 评论 收藏
分享
评论
9
14
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务