题面整理 20 题：实习（2/4/5/6/7）、CodeAgent 与 AI 认知（8–13、16–19）、语言与基础（14/15/20）。有托底的题标注链接，新题写完整参考答案。

一面

1. 自我介绍

AI 岗定稿版或后端岗版（带定位句收尾），见 自我介绍。

2. 「底层用的是哪个任务调度？」 口径已立

底层是公司自研的分布式任务调度平台。调度模型四点：① 增量任务是按 cron 周期（小时/天两级）定时触发的离线批任务；② 任务间依赖 DAG——补 T-2 前自动检查 T-3 完成；③ 数据就绪检测——发布流程第 10 步注册的 Topic-Job 关系；④ 失败重试与三阈值告警（延迟、错误记录数、数据量）。全量 DataX 导入不是 cron 任务，是发布第 8 阶段的一次性低峰触发。

口径对齐：数据到达 HDFS 原始层是分钟级（P95 < 3 分钟的口径），它何时变成 Hive 分区由调度周期决定——两句话对齐，时效模型才完整。

3. 「要适配不同的数据源吧？」 口径已立

先说边界：Canal 链路的采集前提是 MySQL 协议，非关系型不走这条路——MongoDB 有 oplog 订阅通道且天然带 _id；异构源走 DataX 全量加轮询增量字段。MySQL 系里：有主键的表平台自动识别主键（information_schema），占绝大多数；无主键的表创建任务时提示显式指定业务去重键，实在没有唯一键的表引导改用保留变更模式、不做末态合并——自动识别为主，用户兜底为辅，兜不住宁可降级模式也不做出错的数据。

4. 「这条链路的难点和卡点是什么？怎么解决的？」

参考答案（难点讲深、卡点讲真实）：

最大难点是全量与增量的衔接：快照和 Binlog 流天然重叠，锚点和幂等的整套机制就是为它设计的（第二场面经 Q3 的完整答案）。

卡点讲真实的工程故事：一是合并清理链的断点——合并对象已生成、分片元数据已删时进程挂了，重试救不回来（数量校验永远过不了），靠清理补偿分支解决（先查完整文件是否已存在再决定补清理还是重组，见第二场乐观锁答案）；二是无主键表——去重键无处安放，靠显式指定业务键或降级为保留变更模式；三是故障定位——四种不同性质的故障要收敛到一个状态字段才能排查，靠「状态 + 错误原因入库」的设计做到。

5. 「数据源的去重键是自动识别还是用户设置？」 口径已立

见本会话第 5 题口径：自动识别为主（RDS 读权限 → information_schema 读主键/唯一索引，自动建表和自动加列是 schema 自动识别的证明）；用户兜底三类——无主键表显式指定业务键、联合/自定义去重键显式指定、主键不可靠的人工介入。判断句：「事实类配置自动识别，业务类配置人工指定」——主键是数据库事实，加密字段（第 7 阶段）是业务判断，所以前者自动、后者用户选。

6. 「非关系型、没有唯一约束的数据源怎么办？」 口径已立

见本会话第 6 题口径：MongoDB 走 oplog 订阅（天然带 _id）；无变更流的异构源走 DataX 全量 + 轮询增量字段（用户指定增量键）；MySQL 系无唯一键的表降级为保留变更模式。

7. 「P95 缩短到 3 分钟以内——是你优化的，还是它本来就是这个水平？」 归因题，诚实是唯一解

参考答案：

诚实说：这个分钟级水位是链路架构决定的，不是我优化出来的。前半段 Canal 到 Kafka 到 HDFS 原始层本来就是准实时的，我负责的是把这条链路在平台内编排落地，并保障它稳定在 3 分钟以内——告警基线的设置、延迟劣化时的四段排查、故障的快速恢复，这些是我的工作。我没有做过「把一个慢系统优化快」的动作——T+1 到小时级是调度配置调整，不是我的优化项。

这么答的道理：把架构红利说成个人优化，追问一句「你具体改了什么」就穿帮；说清楚「架构决定水位、我负责稳定性和可运维」，反而显得对系统的理解是真的。

8. 「这个改动是自己手敲的还是 AI 辅助的？」 口径已备

诚实 + 具体链路：数据平台的任务是配置和编排为主，我大量用 AI 辅助做排查思路整理、SQL 和脚本的生成与 review——简历技能栏就写了「擅长通过 AI 编程工具提升编码与排查效率」。CodeAgent 项目本身就是把这套提效方法产品化的实践。

9. 「CodeAgent CLI 对标 Claude Code 吗？」 题库 Q14

见 CodeAgent-专项题库 第 14 题：不比功能覆盖，定位是终端、本地、模型无关、安全内建的自研实现；价值是内部机制完整趟过一遍，判断可迁移。

10. 「写完这个，对你后面的编程有提效吗？」 新题（正面题，主动讲）

参考答案：

有，分三层说。一是提效本身：现在写代码的习惯变了——先让 Agent 检索定位再动手，改完让它跑测试自查，重复劳动（样板代码、单例、CRUD）基本外包给它；二是判断力提升：因为自己实现过工具路由和上下文压缩，现在用 Cursor/Claude Code 这类工具时知道它的边界在哪——什么任务适合直接丢给它、什么任务要先拆步骤、什么时候它的输出必须人工复核，用 AI 的效率反而比不懂机制的人高；三是反过来影响我写代码的方式：为了让 Agent 能看懂和改对，代码的模块边界、命名、注释规范都要更清晰——等于 AI 在反向约束代码质量。

11. 「CodeAgent 底层什么语言？封装这套工作流用了什么思想？」 题库已备

语言是 Java 17。思想四个：描述即路由（模型靠 name + description + schema 选工具，改工具联动改提示词和文档）；分层与共享（三条执行路径共享同一套 ToolRegistry / Memory / Snapshot，不为某个模式造孤立功能）；失败无害化（压缩失败跳过、快照失败仅告警、摘要失败保原历史——每个易错点都设计零代价的失败路径）；声明式安全（审批、围栏、黑名单、审计四层，用户无法批准一个策略拒绝的请求）。

12. 「crawl、scrape 你知道吗？」 新题

参考答案：

知道，两者是爬虫体系里不同层的事。crawl（爬行/遍历）：从入口页出发顺着链接发现更多页面，核心是覆盖面、去重（URL 去重队列）、广度优先调度和礼貌性（限速、robots.txt）——解决「找到要抓的 URL」。scrape（抓取/提取）：对已知 URL 拉取内容并解析出结构化字段——解决「把内容拿下来变成数据」。对应我的工具分层正好是这两层加一层：web_search 解决「发现 URL」（搜索引擎代替 crawl）、web_fetch 解决静态页 scrape（拉取转 markdown）、浏览器三件套解决动态渲染页的 scrape（JS 渲染的内容 fetch 拿不到，需要真浏览器执行）。

13. 「为什么用 Java 写，而不是其他语言？」 题库已备（差异化题）

三个理由：一是技术栈契合——目标是用它检验四年后端工程功底（并发、内存、JVM），Agent 的难点（上下文工程、并发编排、故障兜底）恰恰是工程问题不是语言问题；二是生态够用——模型接入走 OpenAI 兼容 HTTP 端点，语言无关；rg、JGit 这些关键依赖都有成熟封装；三是差异化——市面上 Agent 几乎全是 Python/TS，一个 Java 自研更能证明「机制是我实现的，不是调框架」。完整口径见 CodeAgent-专项题库 第 14 题。

14. 「Java 项目要依赖一个 Python 的 AI 能力，怎么通信？」 新题

参考答案（按耦合度从低到高选）：

1. HTTP/REST（默认首选）：把 Python 能力包成独立服务暴露 API，Java 用 OkHttp 调用——语言无关、部署独立、故障隔离；我的 CodeAgent 调 LLM 就是这么干的：OpenAI 兼容 HTTP 端点，协议才是边界，语言根本不重要。
2. gRPC：性能要求高、接口契约稳定的内部调用——protobuf 强类型契约、HTTP/2 多路复用，代价是要维护 proto 文件和双端代码生成。
3. 消息队列：异步任务场景——Java 提交任务进 Kafka，Python 消费处理回写结果，天然削峰和解耦。
4. 子进程调用：AI 能力是一个 Python 库而不是服务时，Java 用 ProcessBuilder 起子进程跑脚本、解析输出——我的 CodeAgent 里 PDF 解析就是这么做的（本地解析引擎的子进程），要注意超时、输出截断和崩溃隔离。

选型原则：同步实时用 HTTP/gRPC，异步解耦用 MQ，临时脚本用子进程；核心原则是跨语言时把边界画在协议上，而不是让两种语言共享内存或进程。

15. 「Redis 缓存和 Java 本地缓存有什么差异？」 新题

参考答案（四个维度）：

1. 一致性与共享：Redis 是所有实例共享一份，改了即全局生效；本地缓存（Caffeine）每个实例各一份，更新后其他实例存在不一致窗口，要么接受短时不一致，要么做失效广播——多实例共享状态必须 Redis。
2. 访问开销：本地缓存纳秒级（方法调用）；Redis 有网络往返，毫秒级——极高频的小数据（如配置、字典）本地缓存收益巨大。
3. 容量与生命周期：Redis 容量独立、可持久化、可设 TTL，进程重启不丢；本地缓存受堆内存限制，进程死了就没了，还有 GC 压力。
4. 故障语义：Redis 挂了是全局依赖故障（要设计降级，我的 RAG 里位图、权限缓存都能从 MySQL 重建）；本地缓存挂了只是退化为直查数据库。

实践口径：我的 RAG 里组织标签缓存、会话窗口用 Redis——多实例共享、需要和检索一致；CodeAgent 是单机 CLI，记忆全在本地——单机产品本地缓存就是全部，没有引入 Redis 的必要。选型一句话：跨实例共享或要持久化的用 Redis，单机内极高频读的用本地，两者叠加就是「本地缓存热点 + Redis 兜底」的多级结构。

16. 「CLI、MCP、Skill 三者的区别？」 新题（三层不同维度的东西）

参考答案：

三者不在同一个维度上。CLI 是产品形态——终端交互的 Agent 程序，和它相对的是 IDE 插件、Web 服务这些形态。MCP 是协议——标准化「模型如何调用外部工具和数据源」的接口层，解决的是能力接入问题：工具提供方写一次 server，任何 MCP 客户端即插即用。Skill 是知识注入机制——把领域知识（提示词流程、脚本）做成按需加载的包，解决的是「上下文里带多少知识」的问题：索引先行、按需加载正文。

一句话关系：MCP 扩展的是工具与数据的外部能力边界，Skill 扩展的是模型在特定领域的知识深度，CLI 是承载这一切的形态——三者正交，可以叠加：我的 CodeAgent 就是 CLI 形态，接了 MCP 工具，也带了 web-access 这个 Skill。

17. 「你自己有常用的 Skill 吗？」 个人向

参考答案（诚实 + 具体）：

自己写过和常用的是一个 web-access Skill——让 Agent 具备联网查询和动态页面访问能力的知识包，CodeAgent 里默认带。日常用 AI 编码工具时常用的还有两类：代码规范类（让生成的代码符合团队约定）和测试生成类。我的判断是：Skill 的价值在「领域流程的沉淀」——凡是某类任务你反复给 AI 讲同样的前置要求和步骤，就值得沉淀成一个 Skill。

18. 「关注哪些 AI 热点？」 个人向（落到实践，避免报菜名）

参考答案：

三个方向，都和我的实践挂钩。一是上下文工程——长上下文的压缩、记忆分层、工具清单管理，我在 CodeAgent 里做了动态阈值压缩，所以对各家长上下文方案的变化特别敏感；二是 Agentic RAG——从固定流水线到模型自主决定检索，我的 RAG 项目走的正是这条路，现在关注的是评测怎么跟上（检索和回答质量的结构化评测）；三是 Agent 的安全与权限——工具越权、提示词注入的防护，CodeAgent 的审批加围栏加快照就是我对这个问题的回答。报菜名谁都会，我能讲的是这三个方向里我自己踩过的取舍。

19. 「Java 链路响应慢，如何结合 AI 快速定位？」 新题（先观测后 AI）

参考答案：

核心观点先立住：AI 是分析的放大器，不能替代观测数据——没有证据链，AI 只能猜。流程四步：

① 先拿观测证据：链路慢先分层定位——网关看耗时分布，服务内用 Arthas（trace 看方法级耗时、profiler 看火焰图）、数据库看慢 SQL 日志、JVM 看 GC 和线程状态。这一步是传统手段，AI 帮不上核心忙。 ② 把证据喂给 AI 分析：Arthas 的 trace 输出、慢 SQL 语句和执行计划、线程 dump，连同业务上下文一起给 AI，让它找热点、提假设——比如「这个 trace 里 80% 耗时在一个远程调用，且重试了三次」。 ③ 让 AI 产出验证动作：根据假设让它生成复现代码、压力脚本、或一段 Arthas 命令去验证假设——假设必须被证据确认，不接受「可能是」。 ④ 修复与回归：AI 给出修复建议后让它写回归测试和前后对比，改完跑数字确认。

结合我自己：CodeAgent 里模型响应慢的定位就是这么做的——先看 token 数（超阈值触发了压缩就是慢的主因），再看是首 token 延迟还是生成太长，分别对应网络问题和任务拆分问题。一句话总结：观测数据是输入，AI 是加速推理的引擎，验证闭环是底线。

20. 「9×9 数独棋盘，给入坐标和值，判断该落点是否合法」 算法

参考答案：

合法性三个约束：所在行、所在列、所在 3×3 宫内都不能已有该值。每个约束扫描 9 格，共 O(27) = O(1)：

boolean isValid(char[][] board, int r, int c, char v) {
 for (int i = 0; i < 9; i++) {
 if (board[r][i] == v) return false; // 第 r 行
 if (board[i][c] == v) return false; // 第 c 列
 int gr = r / 3 * 3 + i / 3; // 第 (r,c) 所在 3x3 宫
 int gc = c / 3 * 3 + i % 3;
 if (board[gr][gc] == v) return false;
 }
 return true;
}

关键点：宫内坐标的映射公式——宫的左上角是 (r/3*3, c/3*3)，宫内第 i 格是 (左上r + i/3, 左上c + i%3)，一条循环同时扫行、列、宫。若落子查询非常频繁（解数独的回溯），可以预处理行 / 列 / 宫各 9 个位掩码（int 的 9 个 bit），合法性判断变成三次位运算 O(1)——这也是 LC 37 解数独的标准加速手段。

复盘提示

• 本场结构：实习深挖（2/5/6/7 连环追问配置与边界）+ AI 项目认知（9/10/11/16–18）+ 基础与算法（14/15/20）——AI 应用岗的面试形态越来越「工程 + AI 认知」混合，两份专项题库正是按这个形态备的
• 新增待补口径：Q17 常用 Skill、Q18 AI 热点——答案给了框架，用之前改成自己的真实清单
• 第 7 题归因口径（架构决定水位、我负责稳定性）是全场最需要背死的一句话