我还记得24年研究RAG的时候，压根没有想到，后来技术的发展，大模型的上下文能长成现在这个样，而且随着技术进一步发展，其实Memory的加入确实能让Agent的上下文能力变得很强，但真当面试时如果被问到这个问题，你得清楚，其实是一个非常典型的面试陷阱。（我准备的答案在文末）为什么这么说？如果你跟风回答“会”，面试官很容易判断你缺乏工程落地经验，也没有真正考虑过成本问题。但如果你回答“不会”，面试官往往又会继续追问：既然不会，那现在模型拼命把上下文窗口做到几百万Token，难道方向错了吗？RAG还有存在的必要吗？你会觉得，这道题似乎怎么回答都不对：说“会”，显得外行；说“不会”，又像是在否定技术...

拼多多测试一面，

楼主的秋招真是异常惨淡，好几个终面/排序挂，北上的很多大厂根本连简历都过不去，最后拿了一个 4399 游戏开发和北京中厂的搜推业务，但都没选，背水一战备战春招。幸好机缘巧合进了在垂类领域比较有名气的 ai startup 公司实习，后续字节，阿里，b 站都主动约了面试，最后也算是终于结束校招了，base 在广州，给的薪资也挺满意的，面试过程比较顺利基本上都是秒过，面经就不发了聊的都是 agent 的实习，去做的也是 agent 后端

1. 自我介绍2. 如何理解面向对象编程，有过什么相关实践答案：理解面向对象编程，核心不只是封装、继承、多态这些概念本身，更重要的是用它来做建模、隔离变化、降低耦合。在实际开发里，比较常见的做法有：用封装隐藏内部实现细节，对外提供稳定接口用抽象基类定义能力边界，不让调用方依赖具体实现用多态替换大量条件分支，方便后续扩展用 RAII 管理资源生命周期，减少泄漏和异常路径问题实际做过的一类场景，是把不同来源的数据处理逻辑抽象成统一接口，对上层只暴露标准调用方式，底层根据实际类型走不同实现。这样后续接新的处理策略时，只需要新增类，不需要改原有调度逻辑。代码： #include <iostrea...