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

最近在准备找第二段实习，主要方向想转向 Agent / 智能体开发。目前已经学习了 SpringAI 和 langchain等技术栈，完成了一个支持自定义工作流的项目，能够理解整体架构设计与执行逻辑，具备一定的智能任务编排思路。希望大佬们看看我的简历！

我发现可以通过教培指数来判断一个学校的就业水平，即该校教培入职应届生人数➗该校当年应届生总人数，该指数越大说明学校就业越烂，还可以分别计算各个学院的就业水平😄。华理今年的该指数目前为0.09（根据新东方、猿辅导、作业帮、有道、学大、昂立与学而思教师总人数之比近似计算各机构在华理录取人数）哪位教培hr能给各92排个名让高考生避雷一下。😄

"这个接口为什么要同步调用？" 导师在code review时随口问了一句，我愣了三秒。 "因为……需要立即返回结果？" "那如果下游服务挂了呢？整个链路都会被拖垮。"他在白板上画了一个简单的架构图，"你看，这里应该用异步+回调，或者引入消息队列做削峰填谷。" 那一刻我才意识到，在拼多多，每一行代码背后都藏着架构思维。 📝 那些被我打印出来的"金句" Week 1：关于架构设计  "不要为了用技术而用技术，先想清楚业务场景和流量模型。"  我把这句话贴在显示器旁边。后来在做...