淘天aiagent一面

我最近把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带来的收益和踩过的坑

1. 自我介绍2. 介绍下你简历上这个项目3. 聊聊记忆系统模块设计，你会怎么拆记忆系统至少要拆成写入、索引、检索、融合和淘汰五层。写入层不是把所有对话都存下来，而是先判断值不值得记；索引层要同时支持按用户、会话、任务、实体和时间切片检索；检索层通常要把结构化过滤和语义召回结合起来；融合层负责把召回结果转成当前 prompt 可消费的上下文；淘汰层解决过期、冲突和污染。好的记忆系统不是“记得多”，而是“能在正确时刻拿回正确事实”。4. 记忆检索到底应该用 user_id、session_id，还是别的主键不能只用一个主键。session_id 更适合短期上下文恢复，能还原当前任务过程；user...

努力拥抱AI中…1.拷打项目，追问项目细节2.agent项目中做了什么3.怎么设计的agent循环执行4.是spring ai框架内的还是prompt控制输出5.system prompt怎么设计的6.调用llm的全过程7.tool什么时候发给llm，什么时候执行8.返回结果怎么知道需要调用哪个tool9.记忆压缩方式，怎么生成摘要八股1.线程池的参数2.假设一些参数求正在运行的线程数3.假设io密集型占用90%，一个四核的机器应该给核心线程数怎么配置4.mysql结合项目的表字段举例怎么查询更优ai coding 实现一个高并发场景下发放优惠券模板，购买优惠券，下单优惠券，容错处理的一个服务，跟秒杀差不太多，看着coding的代码问问题，询问ai的处理逻辑是否正确，存在什么问题，如何修改等

1. 自我介绍2. 介绍下项目，重点讲架构、关键设计和线上问题3. Agent 的上下文窗口不够时，长短期记忆应该怎么分层设计长短期记忆不能简单理解成“最近消息”和“很久以前的消息”。更合理的设计是把状态拆成三层：工作记忆负责当前回合执行所需的最小上下文，摘要记忆负责阶段性中间结论，长期记忆负责稳定事实、偏好、任务状态和关键证据索引。这样做的好处是短链路推理不会被旧噪声拖死，而长任务又能在需要时按状态检索历史事实。真正难的不是分层本身，而是写入和召回策略。不是每条消息都值得进长期记忆，通常只把高价值、可复用、低歧义的信息写进去，比如用户偏好、外部工具执行结果、关键约束、任务完成状态。否则记忆库...