京东 AI Agent开发一面

1. 自我介绍

2. RocketMQ 里顺序消息、普通消息、事务消息分别适合什么场景，为什么不能混着用

普通消息适合最终一致、无严格顺序约束的场景，比如日志分发、画像更新、通知投递。顺序消息适合同一业务键必须按时间线推进状态的链路，比如同一工单、同一订单、同一会话的状态演进，但顺序消息的吞吐和容错设计会受到队列粒度限制。事务消息适合本地事务与异步投递之间要建立“发送承诺”的场景，比如主库先落事实，再由 MQ 推动旁路索引或下游补偿。三者不能混着用，是因为它们解决的问题不同，消费模型、失败恢复方式和成本模型也完全不同。

3. 如果 RocketMQ 出现消息积压，你会怎样定位，不要只说“扩容消费者”

先区分是生产过快、消费变慢，还是某个分区热点导致局部堆积。然后看堆积是持续增长还是短时尖峰，消费线程是否阻塞在数据库、RPC、锁竞争、反序列化还是重试逻辑。再往下要拆到 Topic、Queue、Consumer Group 和具体业务键，很多积压不是整体消费慢，而是少数热点消息把有序队列拖死。真正排查时还要结合重试次数、死信比例和消费耗时分布，而不是只看总 Lag。

4. RocketMQ 在业务里最容易被忽略的一个问题是什么，为什么很多系统明明用了 MQ 还是会把故障放大

最容易被忽略的是消费端副作用没有隔离。很多系统把 MQ 当作“异步万金油”，结果消费逻辑里同步调用多个下游、失败无限重试、缺乏退避和幂等，最终 Broker 本身没问题，消费端却把后端抖动放大成全链路雪崩。MQ 只是把压力转移了位置，不会自动把系统变稳，真正决定稳定性的是消费动作是否可重试、可中断、可收敛。

5. MySQL 联合索引什么时候会看起来“命中了”，但执行计划仍然很差

最典型的情况是虽然用了联合索引的前缀，但后续过滤、排序或回表成本太高，导致整体代价仍然很大。比如 where a = ? and c = ? order by b，索引是 (a,b,c)，看起来命中了 a，但 c 无法高效过滤，排序也未必受益。再比如索引列选择性太差、范围条件过早出现、查询列不覆盖导致大量回表，都可能让“命中索引”变成一种错觉。判断索引效果不能只看 key，还要看 rows、filtered、Extra 和实际扫描路径。

6. MySQL 索引为什么底层一般选 B+ 树而不是红黑树、哈希表或者跳表

B+ 树最核心的优势不是“查找快”，而是它对磁盘和页缓存友好。它的分支因子高，树高低，一次查找需要的随机 IO 更少；叶子节点天然有序，范围查询和排序扫描成本低；内部节点只存键不存数据，能最大化扇出。红黑树在内存结构上很好，但树高更高，不适合磁盘页组织；哈希只适合等值，不适合范围；跳表在内存里实现简单，但在数据库页管理和范围扫描上没有 B+ 树稳定。

7. 索引失效除了函数操作、隐式转换、范围查询，还有哪些更隐蔽的情况

字符集和排序规则不一致、条件两边类型不一致、or 组合条件破坏优化路径、前导模糊匹配、统计信息过旧导致优化器误判、表达式改写触发不了索引下推，这些都很容易让索引“理论可用，实际上不用”。另外，联合索引中如果查询条件顺序没问题，但返回列很多、回表代价大，也会出现优化器主动放弃索引的情况。真正线上排查时不能只背失效口诀，要结合执行计划和数据分布看。

8. 在高并发写入场景下，B+ 树的页分裂和页合并会带来什么问题

页分裂会导致写放大、锁竞争、缓存失效和局部热点，尤其是插入键随机分布时会让叶子页频繁分裂。页合并虽然不像分裂那样高频，但在删除较多、空间利用率下降时也会影响页组织和后台整理成本。对于 InnoDB 来说，顺序递增主键通常能减少页分裂带来的额外开销，而随机 UUID 类主键会让索引维护代价明显上升。这类问题往往不会直接表现成“SQL 错”，而是长期吞吐下降和写延迟波动。

9. AI 工具在研发流程里真正有价值的部分是什么，回答时不要停留在“提效”

真正有价值的是把高认知负担、低决策密度的工作切下来，比如大仓库代码理解、调用链归纳、测试样例生成、变更影响面扫描、故障根因候选收敛和规范检查自动化。它不适合替代架构边界判断和高风险改动拍板，但非常适合在复杂信息面前先做第一轮压缩。工程上能把 AI 用好的团队，往往不是让它“帮我写代码”，而是让它参与可验证的子任务。

10. 模型效果评估为什么不能只看问答准确率，Agent 系统至少还要评什么

因为 Agent 不是只输出一句话，它还会选工具、填参数、决定是否继续、决定是否拒答、决定是否转人工。所以除了最终答案，还要评路由准确率、工具选择准确率、参数结构合法率、调用轮数、无效调用率、失败恢复成功率和高风险场景的保守性。一个答案看起来不错的系统，可能工具乱调、成本过高、越权风险严重，这种系统在工程上依然不合格。

def eval_agent_case(case, result):
    return {
        "route_ok": int(result["route"] == case["route"]),
        "tool_ok": int(result["tool"] == case["tool"]),
        "args_ok": int(result["args"] == case["args"]),
        "final_ok": int(result["answer"] == case["answer"]),
        "steps": result["steps"]
    }