1. 自我介绍2. 介绍一下 AI 智能体的 workflow，以及 RAG 知识库是怎么设计的智能体 workflow 一般不是一次模型调用，而是多阶段任务流。我会把它拆成意图识别、任务规划、工具选择、检索增强、结果生成、校验和记忆更新几个阶段。比如运营人员问一个商品问题，系统先判断是选品分析、广告诊断、库存预警还是内容优化，再决定调用商品库、广告系统、向量知识库或规则引擎。RAG 知识库设计上会分离结构化数据和非结构化文档。结构化数据比如商品指标、广告 ROI、库存周转用 MySQL、ClickHouse 或 ES 查询；非结构化内容比如运营 SOP、平台规则、历史案例、达人脚本会做切分、...

年前一面通过，后面问是否考虑外包岗位，撤回的消息说的是“没办法，学历是硬性指标”，难绷那你面我干啥呢，浪费双方时间，你早说是外包岗我还接你面试干啥😂

今天早高峰10号线，人挤人，我好不容易站稳，余光扫到旁边座位上有个穿校服戴红领巾的小男孩，正低头盯着iPad。我以为他在看动画片，好奇瞟了一眼——好家伙，在刷leetcode。我人都傻了。我小学五年级还在玩赛尔号，人家已经在地铁上刷题了。让我想起来现在也有很多机构推出面向小孩的人工智能课、AI使用课...现在连小孩都这么卷了吗？

1. 自我介绍，围绕一条链路说明你做过什么、你负责什么、难点在哪2. 一个面向多业务域的 Agent 系统，为什么不能只用一个大 Agent 把所有事情做完单 Agent 的问题不是“不能做”，而是做大以后上下文会混杂，知识边界、工具边界和状态边界都不清楚。比如订单查询、风控审计、赔付建议、配置解释，本质上就是不同任务类型，它们需要的知识、状态和可调用工具完全不同。如果硬塞到一个 Agent，模型容易被无关上下文干扰，也容易误用工具。实际工程里更稳的做法是做任务拆分：入口先做路由，再把请求交给垂直 Agent 或垂直 Skill 处理。3. 对多场景、多上下文的请求做路由时，如何判断当前应该调...