还是太菜了，下去沉淀一下1.深入剖析ReAct框架的局限性，并在此基础上，详细解释Plan-Then-Act、ReAct + 轻规划以及Tree/Graph Planning（如ToT、LATS）这三种范式的核心区别、适用场景和各自的优缺点。 ​2.请阐述“思维链”（Chain-of-Thought, CoT）与“规划”（Planning）的本质区别。为什么说CoT仅仅是“将推理过程写出来”而Planning是生成一个“可执行的任务表”？请用具体例子说明。 ​3.在处理一个需要多步工具调用的复杂任务（例如“调研三篇关于RAG+RL的论文并输出中文总结”）时，如何设计一个鲁棒的规划机制来应对中间步骤的失败（如某个API调用超时或返回数据格式错误）请描述具体的重试、回滚或重规划策略。 ​4.详细解释Tree-of-Thoughts (ToT) 或类似LATS（使用LLM进行蒙特卡洛树搜索）的框架是如何工作的？它们与传统的线性规划相比，在探索最优解题路径上有何本质优势？ ​5.在Agent推理过程中，经常会出现“推理断层”或“结果与目标偏离”的问题。请结合具体技术或你的实践经验，说明如何通过提示工程、记忆机制或架构设计来缓解或解决这一问题。​6.请深入剖析大模型Agent的“长期记忆”模块。在设计一个能够持续运行、与用户长期交互的Agent时，你会如何设计记忆的存储结构（如向量数据库、图数据库）、更新策略（如记忆合并、遗忘机制）、检索机制（如重排序、混合检索）来确保记忆的高效和准确？ ​7.当历史对话记录非常长时（远超模型上下文窗口）你有哪些策略来优化记忆的查询效率并保证关键信息不丢失？请比较“滑动窗口”、“总结压缩”、“向量检索”等不同方案的优劣。 ​8.什么是“混合检索”（Hybrid Search）？请解释为什么在工业级RAG系统中，纯向量检索往往不够用，需要结合关键词检索（如BM25）。请给出一个具体的业务场景，说明混合检索的必要性。

最近按当前筛选整理了一波面经，这次挑了 8 篇相对值得复盘的内容，方便刷题和回看。1. 蚂蚁｜暑期实习｜未知日期：2026-04-24关键词：Agent面经难度：4 星标签：技术面技术栈：Java、Spring Boot、AOP、JDK 8、G1、ZGC、MySQL、Redis面经总结本场面试以 Java 后端基础、数据库与网络场景题、AI Agent 项目深挖及 AI Coding 认知为核心。高频问题【并发与多线程】线程池的核心构造参数有哪些？【并发与多线程】一个有队列的线程池，请求不断进来，说说线程池内部的执行逻辑？【编程语言特性】平时用什么 JDK 版本？【操作系统】JDK 8 的垃圾...

27届计科末9本，之前0实习，3月开始一直投产品经理的暑期，但大厂一直挂。听建议四月中旬去了一个toB制造业的中小厂干产品经理，300/天有食堂还管住，住的地方确实不错。目前边干边投，但五一已经过了，暑期是不是没机会了，是接着干到秋招还是等暑假干第二段啊。

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