今天有点开心，先不似

第一次真正感受到“技术判断”这四个字，不是在写完代码的时候，而是在一次方案评审前。需求看起来并不复杂，业务要上线一个新能力，时间不算宽裕，但链路很长，涉及多个模块联动。导师把文档丢过来，只说了一句：先别急着写，先把可能出问题的地方找出来。 我最开始也和很多实习生一样，下意识会先看接口、看表结构、看怎么把功能做出来。但越往下梳理，越发现这不是一个“把需求实现”就结束的任务。高并发场景下，任何一个看起来正常的调用路径，都可能在流量起来之后变成瓶颈；任何一个默认重试、超时设置、依赖堆叠，都可能把局部问题放大成全链路抖动。 于是我先没动代码，反而花时间把调用链、异常路径和兜底逻辑一条条画清楚。哪些请求...

拼多多测试一面，

一、基础概念类说说你对 Agent 的理解，和传统 LLM 有什么区别？常见的 Agent 架构有哪些？ReAct、Reflexion、Plan-and-Solve 你用过哪些？Tool Calling 原理是什么？怎么保证工具调用稳定？RAG 和 Agent 怎么结合？各自适用什么场景？二、技术实现类你做过的 Agent 项目流程是怎样的？从 0 到 1 怎么搭建？如何做 Prompt 工程优化 Agent 的思考与执行？多轮对话中怎么维护状态、记忆和上下文？遇到模型拒绝执行、幻觉、工具调用失败怎么解决？有没有做过多 Agent 协作？任务如何拆分、调度？向量数据库怎么选？chunk 大小、...