阿里云 AI 应用开发一面

《面试题目》

1. 介绍一下 Agent 项目整体架构，讲讲整体的执行流程。
2. Agent 调用某工具为什么选择串行而不是并行？并行会带来什么问题？
3. 怎么避免 Agent 陷入循环？
4. 项目里的上下文是怎么共享的？讲一讲多层上下文控制的方案。
5. 什么时候做上下文压缩？压缩的策略是什么，优先压缩哪部分内容？
6. 这个 Agent 工具调用大概多少次、循环多少轮，为什么是这个量级？
7. 多租户场景下，不同租户怎么做资源隔离、并发限制？
8. 你之前的项目从 Hello Agent 改成 LangGraph，改造做了哪些改动，解决了什么痛点？
9. LangGraph 的核心特点是什么，为什么适合 Agent 开发？对比公司自研 Agent 框架有什么优缺点？
10. 如果做电商客服类 Agent，用 LangGraph 怎么设计工作流和节点？状态会怎么设计？
11. 讲一条 SQL 执行的完整过程，包括语法校验、索引、锁相关流程。
12. MySQL 里 redo log、undo log、binlog 分别是什么，各自作用？
13. Redis 为什么速度快？Redis 单线程模型原理，IO 多路复用怎么理解？
14. 浅拷贝和深拷贝的区别。
15. Python 的 thread local 是什么，作用是什么，怎么实现线程变量隔离？
16. Python 协程 async/await 原理。

《参考解析》

1. 工具串行还是并行：判断依据是有没有依赖、有没有副作用。串行保证顺序与状态一致，并行能压掉等待时间，但会带来竞态（同一资源被并发改写）、结果顺序错乱、下游限流被打爆、失败后难以回滚。稳妥做法是只并行无依赖的只读调用，有依赖或有写操作的走串行，并对并行度设上限，同时接受”并行度越高越难复现问题”这个代价。
2. 怎么避免 Agent 陷入循环：只靠 max_iterations 不够，还要有循环检测——同一工具加同一参数的指纹重复出现就打断；任务进展判定——没有产生新信息就不允许再规划；以及把开放循环拆成有预算的有限执行图。再配合步数、Token、时间三类预算，超预算就降级或转人工，而不是继续跑到自然结束。
3. 上下文怎么共享与压缩：多层上下文一般拆成系统约束、任务状态、检索证据、近期对话、工具结果几层，每层有独立预算；共享靠把状态抽成结构化对象（目标、已确认事实、硬约束、待办、证据引用）在各节点之间传递，而不是把整段消息列表到处带。压缩的时机是接近预算上限或阶段切换时，优先压工具返回的大块原文和重复的检索结果，最不该压的是目标、硬约束和未完成事项。
4. 多租户资源隔离：按租户维度做配额——每租户的并发上限、QPS、Token 预算，配合连接池与线程池的舱壁隔离，缓存 key 带租户前缀避免串数据；重任务走队列按租户公平调度，防止一个租户把全局资源打满。同时要有可观测，按租户看用量、失败率与延迟，否则出了问题只能全局降级。
5. SQL 执行过程：客户端请求进来先做连接与权限校验，然后把 SQL 解析成语法树做语义校验，优化器基于统计信息选索引与连接顺序生成执行计划，执行器按计划调用存储引擎；InnoDB 按页读数据，命中缓冲池就直接返回，否则从磁盘读并可能触发预读。涉及写操作时要加锁并写 undo/redo，被追问锁的部分要能说清行锁加在索引上、以及间隙锁与隔离级别的关系。
6. redo/undo/binlog：redo log 是 InnoDB 的物理日志、循环写，用 WAL 保证崩溃恢复时已提交的数据不丢；undo log 是逻辑日志，支撑事务回滚和 MVCC 的快照读；binlog 是 Server 层的逻辑日志，用于主从复制与数据恢复，格式分 statement、row、mixed。三者协同的关键是一致性提交，redo 与 binlog 通过两阶段提交对齐，否则主从数据会不一致。