字节面经-字节跳动AI Agent开发岗面经-08

《面试题目》

（面经 01）

1. 请做一下自我介绍。
2. 之前有实习过吗？
3. 在哪里实习？
4. 目前还在实习吗？
5. 知识社区平台是否已经上线？
6. 是否有实际用户使用？
7. Coding Agent 项目是自己的开源项目吗？
8. 这个项目是通过 Vibe Coding 做出来的吗？
9. 介绍一下你的开源贡献经历，为什么想到修复这些问题？
10. 使用什么工具完成修复？
11. 对修改后的代码，你会从哪些方面进行 Review？
12. 针对 PR 中 maintainer 提出的意见，你是如何修复的？
13. 你提交的几个 PR 中，维护者具体提出过哪些问题？
14. 最初为什么想做这个 Coding Agent 项目？
15. 在这个项目中，模型负责哪些功能，代码负责哪些功能？
16. 相比直接在 ChatGPT 中聊天，你的 Agent 多了哪些步骤和特有能力？
17. 模型外面的 Harness 工程包含哪些模块？
18. 还有哪些模块需要考虑？
19. 选一个你实现的工具，讲清完整调用链路：模型如何知道工具接收哪些参数？
20. 模型返回调用请求后，程序如何处理？
21. 执行结果如何返回给模型？
22. 以读文件工具为例，文件不存在或文件非常大时，分别返回什么结果？
23. 假设文件有 1 万行，工具每次最多读取 2500 行，调用后返回的具体结果是什么？
24. 模型如何知道文件还没有读完？
25. 如何判断是否继续读取？
26. 工具应该返回哪些额外信息辅助判断？
27. 如何判断哪些信息需要持久化到数据库，哪些只保存在内存中？
28. 数据库中主要保存哪些数据？
29. 如果进行了 10 轮工具调用，每轮结果都很大，是否全部保存到数据库？
30. 会原样保存、压缩、摘要还是丢弃？
31. 这些存储策略由模型决定，还是由代码中的规则决定？
32. 是否对 Agent 的能力做过评测？
33. 简历中的“安全执行”具体指什么？
34. 如何判断命令是否允许执行？
35. 批准、拒绝和后续授权如何处理？
36. 安全策略和规则具体如何设置？
37. 在某个工作目录启动 Agent 后，如果要读取其他目录的文件，是否会拦截或提醒？
38. 当前实现能否直接访问？
39. 如果用户要求读取本地密钥文件，系统如何处理？
40. 是否实现了沙盒或访问边界检查策略？
41. 如何判断一个请求是危险的还是安全的？
42. 具体依据是什么？
43. 知识社区平台实现了哪些功能？
44. 整体架构是什么？
45. Redis Bitmap 在计数系统中起什么作用？
46. 点赞等数据是否会落库、是否保存到数据库？
47. MySQL 索引的原理是什么？
48. 索引解决了什么问题，为什么需要索引？
49. 相比没有索引，查询效率提高多少？
50. 如何从复杂度角度计算？
51. 开发项目时，具体让 AI 做了哪些工作？
52. 自己负责哪些工作？
53. 如何与 AI 协作？
54. 如何判断 AI 给出的方案正确、有效且合理？
55. 会从哪些方面检查，判断它是否需要继续完善？
56. 算法题：有效的括号，先讲解思路，再实现代码。
57. 为这段代码设计测试用例，会覆盖哪些情况？
58. 还有哪些边界情况？
59. 除了此前提到的 AI 编程工具，还使用过哪些国产或开源工具？
60. 了解哪些热门的开源 Coding Agent 方案或 Agent 框架？
61. 开源经历、这个项目和 Pi 的关系是什么？
62. 这些工具或框架之间有什么区别？
63. 如果选择一个开源框架构建 Agent Runtime，会从哪些维度选型？
64. 当前 Agent 在本地运行，如果迁移到云端或服务器，整体架构应该如何设计？
65. 可以分成哪些层？
66. 还需要补充什么？
67. 模型如何接入系统？
68. 模型接入应该放在哪一层？
69. 系统搭建完成后，如何向用户提供服务，让用户实际使用？

（面经 02） 70. 先整体介绍项目，为什么选 LangGraph？ 71. 工作流是怎样的？ 72. 项目中的评测数据集是怎么构造的？ 73. 数据主要由 AI 生成，如何保证数据集质量和覆盖度？ 74. 如何保证 Agent 能在这些数据上更好地回答问题？ 75. 用户问题比较口语化、有错别字或意图不明确时，如何处理？ 76. 知识库如何构建？ 77. Markdown、TXT、PDF 分别怎么切块？ 78. 为什么同时使用 BM25 和向量检索？ 79. 两者各自适合什么问题？ 80. 两路召回结果如何融合？ 81. RRF 的原理是什么？ 82. 为什么不直接融合两种检索的原始分数？ 83. 粗排后为什么还要使用 Cross-Encoder 重排？ 84. Cross-Encoder 为什么会比向量相似度更准确？ 85. 直接使用预训练 Cross-Encoder，训练目标和你的业务场景并不一致，如何保证效果？ 86. 简历里写了多种检索方式，分别是什么，为什么需要这么多种？ 87. 这个项目和上一个项目除了技术栈不同，还有什么本质区别？ 88. 做这个项目最大的收获是什么？ 89. 项目里遇到的最大困难是什么，怎么解决？ 90. 评测体系里有很多指标，哪个指标最能衡量系统是否达成目标？ 91. 手撕算法：一道偏简单的贪心题。

（面经 03） 92. 实现一个通用智能体要考虑哪些功能点？ 93. HTTPS 端到端链路是怎样的？ 94. 手撕二叉树的右视图。 95. 手撕前缀树。 96. 前缀树的应用场景有哪些？ 97. 应用层、传输层的职责分别是什么？ 98. 从浏览器请求到服务机房的全链路是怎样的？ 99. 什么情况下会把某个能力做成 skill？ 100. 什么时候做成 tool？ 101. 实习当中遇到过这样的问题吗？ 102. LangChain、LangGraph 的区别是什么？ 103. 除 ReAct 还有别的模型交互模式吗？ 104. SSE 底层实现原理是什么？

（面经 04） 105. 自我介绍。 106. Agent 没有遵循 Skill 中的限制和描述时，你是如何解决的？ 107. 是否尝试过把 Skill 规则写入更底层、优先级更高的规范，以提高遵从性？ 108. 面对海量监控视频，如何避免内存高占用或 OOM？ 109. 多个长视频是串行还是并行处理，处理时间大约多久？ 110. 分块上传如何保证成功？ 111. 断点续传、一致性和清理逻辑是如何实现的？ 112. 视频文件物理存储在哪里？ 113. 视频合并失败时，清理逻辑是如何实现的？ 114. MySQL 索引使用什么数据结构？ 115. 介绍一下它的组织方式和工作原理。 116. 一条 SQL 执行需要几百毫秒，你会如何分析和优化？ 117. SQL 已从 800 毫秒优化到 50 毫秒，但整体接口仍然很慢，如何继续定位和优化？ 118. 接口总耗时 80 毫秒、单次 SQL 只有 10 毫秒，如果还要继续优化，你会从哪些方面分析？ 119. 项目中是否使用过缓存或并发手段？ 120. 大数相加（手撕）。 121. 了解堆吗？ 122. 介绍一下最大堆和最小堆。 123. HashMap。 124. 一致性哈希。

（面经 05） 125. 自我介绍。 126. 最近一段实习做的这套 ai-pipeline 的主要目的是什么？ 127. 在这套 AI pipeline 中，你如何保证它的每一个节点执行效果的准确性？ 128. 让 AI 自己发挥的话，它肯定是会有一些幻觉或者偏移，你是怎么解决这些问题的？ 129. 你是怎么想到这套方案的？ 130. 有参考过什么项目或者文章吗？ 131. 这套 pipeline 的最终效果怎么评估？ 132. pipeline 中的 generate 步骤，也就是代码生成这个环节，你怎么去保证代码的生成质量比较高？ 133. ai-pipeline 对业务知识的理解怎么去保证准确？ 134. 在这个项目当中，你觉得你遇到过的最大的问题是什么？ 135. 数据漏斗是怎么做的？ 136. 数据存储介质用得是什么？ 137. 筛选过滤方案是什么？ 138. 第二段实习中，针对营销场景模块，你对其中的大规模数据的 SQL 是如何处理优化的？ 139. 存储介质为什么用 Doris，不用 Hive 或 ES？ 140. Doris 的优势在哪里？ 141. 如何做的技术选型？ 142. 你觉得这段实习中间，对你来说最大的挑战是什么？ 143. 从脚本出数改为自动化流程出数，带来的价值是什么？ 144. 为什么要去做这样一个改造？ 145. 像你这样几亿几十亿的大数据量，对你来说有什么挑战，处理过程中遇到过什么问题吗？ 146. 如何解决的？ 147. 除了在 SQL 手段上，有没有想过通过其他的技术手段来解决这个出数任务的效率问题，让它跑得更快？ 148. 当时是怎么想到去给 Doris 加倒排索引的呢？ 149. 你是怎么分析、怎么排查瓶颈的？ 150. 当时你整个完整的思考过程是怎样的？ 151. 有没有考虑过不用倒排索引，选择其他的方案去做优化？ 152. 现在有一个场景，也是对几十亿的数据进行筛选和过滤，但加了索引之后效果还是不好，这个时候你会怎么优化这个链路？（量级特别大，底表数据可能上千亿，加了索引去查还是有几亿数据出来） 153. 设计实现上，你会怎么考虑？ 154. 在你这套方案中，你觉得哪块是成本最高的、最复杂的？ 155. 最近 20 条信息你是如何过滤的？ 156. 消息是一条一条地推送的，你如何去做截断？

《参考解析》

Agent 的工具调用闭环

工具调用是一个「模型 → 程序 → 模型」的循环。请求里带上每个工具的名字、描述和参数 JSON Schema，模型由此知道该传什么；它返回的 tool_call 只有工具名和参数，没有函数体，由外层程序路由到真实实现，并校验参数类型与必填项，校验失败时把结构化错误回传让模型改参数，而不是抛异常断链路。执行结果序列化成一条 tool 消息追加进对话，再发起下一轮。工程上要处理三件事：同一轮多个 tool_call 并发执行、超时与重试（写操作必须带幂等键，否则重试等于重复执行）、以及超长结果先摘要或落外部存储，上下文只留引用，否则几轮就撑满窗口。

读文件工具的分片与续读

单次读取必须有上限，不能让一个大文件一次灌进上下文。以 1 万行、每次 2500 行为例，返回值应包含四样东西：本段内容、本段起止行号、文件总行数、以及是否还有剩余（has_more 或 next_offset）。模型判断「没读完」靠的是这些显式字段而不是自己数行数：只要 next_offset 非空，就带新偏移再调一次，直到 has_more 为 false。文件不存在要返回可区分的错误结构（错误码加原因与建议动作），不能返回空字符串——空字符串和「文件确实是空的」无法区分。超大文件还要加字节上限，某一行几兆时按字节截断并标注该行被截断。

上下文与持久化策略

内存只放本轮推理必需的：当前消息、本轮工具结果、临时状态；数据库放需要跨会话或跨进程存活的：会话与消息、任务与步骤状态、工具调用审计、产物引用、用户偏好。判据是「进程重启后重建得出来吗」——能重建的留内存，重建代价高或必须留痕的落库。10 轮工具调用、每轮结果都很大时，绝不能全量入库或全量留在上下文：原始产物写对象存储，库里只留元数据和引用，进上下文的是摘要或裁剪片段；接近预算时按最旧优先淘汰，并留一条压缩摘要保住主线。这套策略应由代码里的确定性规则决定，模型只在规则给的选项里取舍，否则行为不可复现、也没法压测。

安全执行：命令判定与授权

拆成四层。①解析与规范化：把命令和路径解成结构化形式——真实绝对路径、是否含 ../ 逃逸、是否软链到目录外，别拿字符串匹配当判据。②策略判定：工作目录白名单、危险动作清单（递归删除、下载后管道执行、改系统配置），读取 .ssh、.env 这类密钥文件必须拦截。③批准流程：命中需确认的动作先暂停，向用户展示完整命令与影响范围；批准可以是一次、本会话或长期，拒绝要把原因回给模型，授权范围显式记录、不可静默放大。④沙盒兜底：即使用户批准也在受限环境里跑，把判错的后果限制在可恢复范围内。

Agent 评测体系

评测要回答三件事：数据集从哪来、指标是什么、改动后怎么知道没退化。数据集分层构造：线上问题脱敏回流、按能力维度人工改写（多步推理、含糊指代、应当拒答）、对抗样本（工具报错、参数缺失、超长输入）。纯 AI 生成必须配覆盖度检查——按意图和难度聚类、每类抽样人工过一遍，否则同一种问法刷满集合，指标好看但能力没涨。指标分两层：终态（任务成功率、答案正确率，靠规则校验加模型打分加人工抽检交叉验证）和过程（步数、token、工具调用次数、错误恢复率、人工接管率）；只看终态会把碰巧答对算成能力。回归集固定，评分口径随 prompt 版本一起版本化。

LangGraph 选型与工作流

选它的理由是流程被显式建模成状态图：节点是函数、边是转移条件、共享可持久化的 State，天然支持分支、循环、中断和人工介入，这些在 Chain 抽象里要靠回调硬凑。工作流通常写成「入口 → 意图路由 → 检索或工具节点 → 生成 → 校验 → 条件回边 → 输出」，把 Agent 的自主循环限制在受控子图内。Checkpoint 是关键：每个节点执行后把 State 快照落盘（内存、SQLite、Postgres 都能接），同一 thread_id 可断点续跑、回放、等人工审批后继续。它和 ReAct 不是替代关系：ReAct 是循环范式，状态图是承载它的编排框架，中间还能插入确定性的固定步骤。

RAG 切块与混合检索

切块按结构走：Markdown 按标题层级切并把标题路径带进块内，TXT 按段落加重叠窗口，PDF 先做版面还原再按段落和表格切，别按页切。BM25 与向量互补——前者擅长专有名词、编号、缩写，后者擅长语义改写；两路别直接加分数，因为量纲不同（BM25 无界、余弦在 -1 到 1），归一化也对不齐，稳妥做法是 RRF：按排名取 1/(k+rank) 求和重排，只依赖顺序。召回后上 Cross-Encoder，是因为双塔分别编码、彼此没有交互，而它把 query 与文档拼在一起过模型，能建模词级交互；代价是耗时随候选数线性增长，所以只在 top-20~50 上跑，或蒸馏小模型控成本。

MySQL 索引原理

本质是用额外的有序结构换更少的扫描量。InnoDB 用 B+ 树：非叶子节点只存键和指针，一页能放几百个键，百万行表的树高通常只有 34 层，一次等值查询约 34 次页 IO，复杂度 O(log n)；没有索引就是 O(n) 全表扫描，这个差距在百万行量级上就是几百毫秒和几毫秒的区别。叶子节点按序链表串联，范围查询和 order by 能顺序读、省掉排序。索引不是免费的：占空间，写入要维护树、可能触发页分裂，所以联合索引按「等值在前、范围在后」排。被问「快多少」时给量级判断和测算方法（扫描行数、IO 次数、实测），不要报拍出来的倍数。

慢 SQL 与接口性能排查

先量化再动手。几百毫秒的 SQL 先 EXPLAIN 看访问类型、命中哪个索引、预估扫描行数、有没有 Using filesort 或 temporary，再对慢日志和真实返回行数；常见病因是没走索引（函数包列、隐式类型转换、前导通配 like）、索引选择性差、回表太多、一次捞太多。SQL 降到 50ms 接口还慢，说明瓶颈不在这条 SQL：看单次请求的调用次数（N+1）、连接池排队、事务持锁、结果序列化与网络、下游 RPC。接口 80ms 而 SQL 只占 10ms，就把时间切段看框架开销、模板渲染、同步日志、GC 与跨机房往返，解法是合并请求、加缓存、异步化。答题顺序是测量、定位、再优化。

Redis Bitmap 与点赞落库

Bitmap 把用户 id 当偏移量、一个用户一位，置 1 表示已点赞：统计用 BITCOUNT，判断单人是否点过用 GETBIT，把去重和计数压到极小内存，适合 id 连续、基数可控的场景（签到、点赞、活跃统计）；id 稀疏时会按最大偏移量分配，反而浪费，得压缩位图或分片。点赞不能只存 Redis：还要支撑「谁赞过、赞了什么、什么时候」，这是关系数据，落库用 (user_id, target_id) 唯一索引保幂等。常见做法是 Redis 抗住并发写入并原子计数，异步或定时批量落库，点赞与取消用队列保序，重复消费也不重复计数；缓存与库的最终一致靠对账兜底。

本地 Agent 迁移到云端的架构分层

大致分六层：接入层（网关、鉴权、限流、长连接）、会话与任务层（会话管理、任务编排、状态机与 checkpoint）、Agent 运行时层（模型调用、工具执行、上下文与记忆）、工具与沙盒层（每会话一个隔离容器，带资源与网络策略）、存储层（会话消息、向量库、对象存储放产物）、可观测层（trace、token 与成本计量）。模型接入放运行时层，用统一 Provider 抽象收敛：模型名、超时、重试、降级、密钥都由配置中心下发，上层只认「任务名到模型能力」的映射。真正难的是多租户隔离与配额、用户代码碰不到别人数据和内网、以及状态从进程内存改成可持久化的共享状态。

算法与数据结构手撕

括号匹配用栈：左括号入栈，右括号比对栈顶并弹出，最后栈空即合法；要主动报边界用例——空串、只有右括号、交叉嵌套、类型不匹配、超长输入，先讲思路再写代码。大数相加用字符串逐位相加处理进位，注意结果可能多一位、前导零与符号。二叉树右视图用 BFS 每层取最后一个，或 DFS 按深度优先记录右侧节点。前缀树用字符做边的多叉树，插入查询都是 O(词长)，适合前缀检索、自动补全、敏感词过滤，代价是内存开销大。堆是完全二叉树，取极值 O(1)、插入删除 O(log n)，常用于 topK。一致性哈希把节点与 key 映射到环上顺时针归属，增删只影响相邻区间，配虚拟节点解决倾斜。