字节剪映 AI 应用开发一面：Agent 工程四十五问

《面试题目》

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

《参考解析》

工具调用的完整链路：模型之所以能调工具，是因为请求里带了每个工具的 name、description 和参数的 JSON Schema，模型输出的不是自然语言而是一段结构化的调用意图（工具名加参数 JSON）；运行时解析它、按名字查工具注册表、做参数校验（必填、类型、取值范围、路径规范化），再执行，然后把结果或结构化错误作为一条 tool 消息回填进上下文，模型据此决定继续调用还是给最终答复。工程上要补的是：非法 JSON 与幻觉工具名的兜底、超时与取消、单轮最大调用次数、失败重试的边界，以及每次调用都落日志以便回放排查。

读文件工具该返回什么：健壮的读工具不该只返回内容字符串，还要带元信息——总行数或总字节数、本次返回的区间（offset/limit）、是否被截断、下一段的起始位置。文件有 1 万行、单次最多 2500 行时，第一次应返回第 1 到 2500 行，并明确告诉模型「总计 10000 行、还有 7500 行、下次从 2501 开始」，模型才知道要续读；只给内容，模型会以为已经读完。「文件不存在」必须和「读到了空文件」区分：前者返回明确的错误与原因（路径不存在、无权限），后者返回空内容加总数 0。超大文件还要按 token 预算做双重上限截断，并提示改用搜索类工具而不是整读。

上下文与持久化：什么该落库、落多少：判断标准是「未来是否还需要、能否重建、重建代价多大」。会话与消息、工具调用审计（在什么目录执行了什么、结果摘要）应该落库，便于回放和定位问题；纯中间推理、能由工具随时重算的数据留在内存即可。十轮调用各自结果都很大时，全量落库既贵又会把上下文撑爆，常见做法是分层：原始结果存文件或对象存储并留引用，库里存摘要与指针；送进模型的部分做裁剪，保留头尾、去重、摘要或只留结构化字段。策略建议由代码规则兜底（大小阈值、字段白名单、保留时长），模型只在规则允许的范围内选；全交给模型会出现不可复现的存储行为，排障时无从下手。

安全执行与沙盒边界：危险判定要有具体依据：命令是否在允许列表内、是否含重定向或命令替换之类的组合模式、是否改系统目录或权限、是否触达凭据与密钥文件、是否向外发数据。工作目录边界靠路径规范化后做前缀校验，同时要处理相对路径穿越与符号链接。批准流程一般分三档——只读与工作区内操作自动放行，可疑操作给出理由并要求人工确认，明确危险直接拒绝；一次批准要带作用域（这条命令、这个目录、有效期），而不是「以后都允许」。密钥与凭据类文件应默认拒绝并给出替代方案。最终的隔离还是要落到操作系统层：低权限账号、容器、只读挂载、出网策略，规则与提示词只能降低概率，不能当边界。

MySQL 索引为什么快：没有索引时按条件查只能全表扫描，扫描行数与表规模成正比，而且每一行的访问都可能带来额外的磁盘页读取；索引把数据按列值组织成一棵多路平衡树（InnoDB 用 B+ 树），树高通常只有几层，等值查询和范围查询都只需要沿路径访问少数页面，复杂度从与行数线性相关降到对数级别。B+ 树的设计要点是内部节点只存键不存数据，单页能容纳更多键从而压低树高，叶子节点按序相连又天然支持范围扫描和排序。落地要注意：二级索引查到主键后往往还要回表取整行，覆盖索引可以避免；联合索引遵循最左前缀，范围条件之后的列用不上；索引本身有写入放大与存储成本，选择性极低的列做单列索引意义不大。被问「快了多少倍」时，从扫描行数和磁盘访问次数的量级去讲比给一个拍脑袋的倍数更稳。

Redis Bitmap 与计数落库：Bitmap 用每个用户一个 bit 记录「是否点过赞、是否签过到」，内存按最大用户 ID 分摊，用户量到百万级也只占很小的空间，SETBIT/GETBIT 都是 O(1)，配合 BITCOUNT、BITOP 还能直接做统计。它的局限有两个：稀疏的超大 ID 会浪费空间（按 ID 分片或改用压缩位图缓解），以及数据在内存里，必须考虑持久化与重建。点赞这类数据通常分层处理：Redis 承接高并发的去重与热度，异步批量落库保证持久化和对账；回答「是否落库」时要讲清最终一致性、消息丢失后的补偿（定时对账、按需回源重建），以及缓存与库不一致时怎么读。

Coding Agent 的选型与上云架构：选框架看几个维度——模型与工具抽象是否解耦（会不会被锁定）、工具调用与流式输出支持得如何、上下文与记忆管理、多步编排与中断恢复、沙盒执行能力、可观测与评测、社区活跃度和协议许可。从本地迁到云端的典型分层是：接入层（鉴权、限流、会话）、编排层（Agent Runtime、状态机、上下文管理）、工具执行层（沙盒容器、文件系统挂载、出网策略）、模型接入层（统一网关负责路由、密钥管理、重试与配额，放在服务端而不是客户端）、存储层（会话、任务、产物、审计）、观测与评测层（链路追踪、指标、回放）。上云真正要补的是多租户隔离、任务队列与超时、取消与恢复，以及成本控制。

评测与「AI 产出怎么验」：判断模型给的方案能不能用，分三层看：能不能跑（编译或测试通过、结果符合预期）、对不对（边界与异常路径、是否与既有约定一致）、值不值（可读性、复杂度、有没有引入新依赖）。工程化做法是攒一个小评测集，把典型任务固化成题目，改提示词或换模型后跑一遍，对比通过率与返工成本；对 Agent 自身则看任务成功率、平均工具调用轮数、失败模式分布和人工接管率。日常协作里 AI 适合做脚手架、样板代码、批量重构和测试生成，涉及核心链路与安全边界的部分仍然要人来定。

算法题与用例设计：有效的括号是栈的典型应用——遍历字符串，左括号入栈，右括号与栈顶配对，遍历结束栈为空才算合法；实现上用映射表存配对关系，注意提前返回和空串边界。设计测试用例要成体系地分类：正常用例（单层、多层嵌套）、非法用例（右括号多余、左括号未闭合、交叉嵌套如 ([)]）、边界（空串、单个字符、只有左括号），再补大输入的性能与字符集范围。面试里把「我按什么维度分类」讲出来，比多写几行代码更能得分。