京东 AI应用开发一面

1. 自我介绍

2. 讲一下你做的项目，重点说你负责的模块和难点

3. 你在做 Agent 的过程中，真正学到的东西是什么，最大的坑是什么

真正学到的不是 Prompt 怎么写得花，而是怎么把模型能力约束进一个可控系统里。比如什么时候让模型自由推理，什么时候必须走工具，什么时候直接拒答，什么时候中断循环，这些都不是模型自己能解决的。最大的坑一般是把模型当成确定性组件用，结果线上一旦遇到模糊输入、脏数据或者工具超时，链路就开始发散。后面通常会补上三层约束：输入规范化、工具白名单、执行状态机。这样即使模型发挥不稳定，系统也不会直接失控。

4. RAG 这条链路里，最容易被忽略但最影响效果的环节是什么

最容易被忽略的是上下文构造，不是召回。很多人以为召回到相关 chunk 就够了，但实际上模型最终看到的是被拼装后的上下文，而不是原始检索结果。如果 chunk 顺序混乱、跨段信息断裂、同一事实重复出现、噪声片段排在前面，模型就很容易答偏。真正做得深一点会在召回之后做去重、聚合、重排、引用补全和 token 预算分配，保证模型看到的是“可回答”的上下文，而不是一堆看似相关的碎片。

5. 你为什么会选这个数据库方案，而不是直接上 MySQL 或 Elasticsearch

如果场景里既有结构化主数据，又要做语义检索，一般不会让单一存储承担所有职责。比如会把业务主数据放 MySQL，文档索引和全文过滤放 Elasticsearch，向量检索放专门的向量扩展或者独立向量库。这样设计的核心不是“技术栈高级”，而是读写模型、索引结构、查询模式完全不同。MySQL 擅长事务和关系约束，ES 擅长倒排和过滤聚合，向量库擅长相似度搜索。如果硬塞到一个库里，最终通常是业务写得别扭、查询也跑不快。

6. 八股里问线程生命周期很常见，但如果往深了问，你会怎么讲线程从创建到销毁的成本

线程生命周期不只是 new、start、running、blocked、terminated 这几个状态。真正值得讲的是线程创建要申请内核资源、分配栈空间、建立调度实体，切换时会有用户态和内核态的成本，还会带来缓存失效和上下文切换开销。所以高并发系统不可能靠无脑创建线程顶吞吐，最终还是要靠线程池、异步化、背压和任务拆分。线上一旦线程数膨胀，问题通常不是 CPU 算满，而是切换和阻塞把延迟拖高了。

7. 多线程下怎么系统性避免死锁和资源竞争，不要只说加锁顺序

真正系统性的方法不是某一条技巧，而是减少共享、缩小临界区、统一资源顺序、超时控制和可观测性结合。首先能用无锁结构或消息传递的地方，就不要提前引入共享锁；其次必须加锁时要把锁粒度收小，不要把 IO 和远程调用放在锁里；再就是多个资源一定统一申请顺序，避免循环等待；最后要给阻塞点设置超时和监控，不然线上死锁很难及时发现。很多资源竞争问题本质上不是锁设计差，而是业务边界设计错了。

Lock first = id1 < id2 ? lock1 : lock2;
Lock second = id1 < id2 ? lock2 : lock1;

if (first.tryLock(100, TimeUnit.MILLISECONDS)) {
    try {
        if (second.tryLock(100, TimeUnit.MILLISECONDS)) {
            try {
                // critical section
            } finally {
                second.unlock();
            }
        }
    } finally {
        first.unlock();
    }
}