满帮 AI 全栈一面：Agent 流程、推理延迟优化与 MySQL 慢查询排查

《面试题目》

1. 自我介绍
2. 讲解一下实习做的 agent 流程
3. 端到端延迟、大模型推理速度慢，怎么优化的
4. 如何你生成完方案，用户不满意，直接关后台，没有反馈，你如何知道用户不满意呢？
5. mysql 慢查询
6. mysql explain 字段
7. sql 语句命中索引了执行也很慢，怎么排查
8. 深分页
9. 游标深分页，牺牲了什么
10. ai 把一个原本只需优化一下就好的系统，却进行了二次开发，如果小白什么都不知道，该如何约束 ai，避免这种情况，或者说让小白也明白 ai 的生成幻觉。

《参考解析》

端到端延迟优化：先把延迟拆开埋点，分清首 token 时间、生成总时长、工具调用和网络往返各占多少，再对症下药。模型侧可以换更小或更快的模型、做量化与 KV cache 复用、减少上下文长度、并行化工具调用；工程侧用流式输出让用户先看到内容，把检索、鉴权等步骤并发或提前预热，对稳定结果加缓存，长任务改成异步加进度反馈。回答时最好给一条真实链路的分段数据，说明优化前后各段的变化，而不是只罗列手段。

用户无反馈时判断满意度：没有显式反馈就只能看隐式信号，例如生成后是否继续追问或改写、是否复制采纳、重生成次数、停留时长、关闭页面的时机、后续是否再回来。可以补一层低成本显式入口（点赞点踩、一键重答），再把隐式行为和显式反馈做相关性校验，避免拍脑袋定规则。这类题重点不是标准答案，而是体现你先把「不满意」定义成可观测指标，再谈采集与验证。

索引命中仍慢的排查：先看执行计划，重点看 type 是否退化成 range 或 ALL、key 实际用了哪个索引、rows 估算扫描行数、filtered 过滤比例、Extra 里有没有 Using filesort、Using temporary。常见原因是索引选择性差、范围扫描行数太大、需要大量回表、排序无法走索引、统计信息过期，或者慢在锁等待与 IO 而不在扫描。手段包括 explain analyze 看真实耗时、开慢日志与 profile、把 select 收窄到必要列、用覆盖索引或延迟关联、给排序字段补联合索引、更新统计信息，并确认没有隐式类型转换或函数包裹导致索引失效。

深分页与游标分页的代价：limit offset, n 深分页会先扫描并丢弃前 offset 行，越翻越慢；优化常用延迟关联（先用覆盖索引查出主键再回表）或游标分页，即记住上一页最后一条的排序键，用 where id > last_id order by id limit n 继续取。游标分页牺牲的是随机跳页能力，只能上一页下一页；同时要求排序键唯一且稳定，通常要用「时间 + id」组合键防止重复或漏行，并发写入时结果也可能有轻微漂移。答这题要能把「为什么快」和「失去了什么」都说清。

约束 AI 不擅自二次开发：核心是把改动范围和验收标准前置。让 AI 先输出方案、影响面和最小改动点，人确认后再动手；限定可修改的文件与模块，禁止随意加依赖、改公共接口，要求小步提交并附上跑过的命令和真实输出作为证据。小白场景下更要把需求翻译成可验证的验收条件，用测试、CI、代码评审和可回滚的发布兜底，而不是靠提醒 AI「不要幻觉」。同时明确告诉使用者：AI 的结论需要被验证，关键决策仍由人负责。