小米 AI Agent 三面：压力面，全程问“你踩过什么坑”

《面试题目》

1. 在你的 Agent 项目中，遇到过最大的工程挑战是什么？如何解决？
2. Agent 系统如何实现“多租户隔离”？
3. 模型资源和沙箱资源怎么划分？
4. 如何设计 Agent 的“状态管理”，以便在服务重启后能恢复任务？
5. 如果并发 1000 个沙箱实例，你怎么设计资源池和调度策略？
6. 如何评估 Agent 生成代码的质量？用过哪些指标或方法？
7. 在长周期任务中，如何避免 Agent“行为漂移”？
8. 设计一个“代码审查 Agent”，如何确保它不会漏掉关键安全漏洞？
9. 你对 RAG 的未来发展怎么看？RAG 和长上下文模型会是替代关系吗？
10. 你刚才提到做了上下文压缩，具体怎么实现的？压缩提示词怎么写的？
11. 如果压缩后丢失了关键信息导致 Agent 出错，怎么发现和补救？压缩失败怎么回退？
12. 沙箱选型怎么做的？
13. 容器重启后会话状态怎么恢复？
14. 并发 1000 个沙箱怎么扛？
15. Agent 系统可观测性怎么做？任务失败怎么做归因？
16. 多 Agent 并发修改同一文件怎么防冲突？
17. 用户重复创建任务怎么幂等？
18. 手撕：二叉树层序遍历。

《参考解析》

1. 多租户隔离与模型、沙箱资源的划分。 隔离分层做：身份与数据层用租户 ID 贯穿所有存储（行级过滤或独立 schema、对象存储前缀分区），并做成不可绕过的中间件；运行时用独立内核的沙箱加命名空间、只读根文件系统、cgroup 限额与 seccomp 白名单，并去掉全部 capability；网络默认断网或走白名单代理，禁止内网网段与云元数据地址；密钥每租户独立。模型资源是配额与优先级问题：按租户分配额桶（QPS、并发、token 速率），用排队加优先级保证小租户不被饿死，交互式与批量任务分池；沙箱资源是容量与生命周期问题：按租户限制并发与总配额，用完即销毁，靠预热池摊平冷启动并按租户记账。两者都要有明确的超额策略：排队、降级或拒绝并给出可重试时间。

2. 状态管理与服务重启恢复。 原则是进程无状态、状态外置、每步可检查点。会话状态拆四份：会话元数据、消息历史（按轮次存，便于重放与审计）、任务中间产物（大对象放对象存储只留引用）、执行进度（已完成步骤、下一步、失败与重试次数）。存储按访问模式选：热状态放 Redis 并设计重建路径，长期放数据库，事件日志可用 append-only 形式以便从任意时刻重放。恢复要区分可重放与不可重放：纯读与确定性计算可以重放；有副作用的写操作靠幂等键与外部状态确认来保证不重复执行。检查点粒度权衡成本与收益，一般以子任务完成、工具调用前后、长模型调用结束为界。恢复还要处理陈旧：任务有租约与心跳，失联超阈值由巡检接管，并用 CAS 把状态从 running 改成可重试。

3. 并发 1000 个沙箱的资源池与调度。 核心是冷启动延迟与利用率的平衡。池化分层：预热池按历史并发的分位数预留、热池在跑、回收池待重置或销毁，峰值靠现场创建溢出。调度按任务类型分队列（交互式短任务优先、长任务单独队列），租户配额加公平调度，同租户会话尽量落同一节点提高缓存命中，任务要有超时与抢占。密度控制靠压测出单机安全水位并留余量，避免节点过载引发任务迁移的连锁雪崩。池空且创建受限时，入口就该排队或拒绝并告知可重试时间。冷启动优化靠镜像分层与预拉取、精简初始化、microVM 快照恢复，以及把起环境与跑任务解耦。最后按池命中率、平均等待时长、单机密度、失败率与 OOM 次数持续调参。

4. 长周期任务的行为漂移与代码审查 Agent。 治理是目标与状态显式化加周期校准：目标、约束与验收标准写进不可压缩的常驻区；每完成一个里程碑让模型复述当前目标与下一步并与计划比对，不一致就纠正；关键分支回计划层；用确定性检查替代模型自省；压缩时保留关键实体与数字作为锚点。代码审查 Agent 防漏检靠多引擎与可验证清单：静态分析跑确定性规则（污点传播、危险函数、依赖漏洞、密钥扫描），模型负责语义级问题（越权、错误处理、并发与事务、业务逻辑漏洞）；把 OWASP 清单拆成逐项可回答的问题（不是“找安全问题”，而是“用户输入是否进入 SQL 或命令拼接，如何证明”），每条结论必须带文件行号与证据；高风险改动强制多种检查叠加；每次漏检回流成规则或评测样例，并用已知漏洞集做回归报召回率。

5. 上下文压缩、信息保真与回退。 压缩分层做：结构化任务状态（目标、约束、已完成、待办、关键实体与证据位置）由代码维护、永不压缩；近期若干轮保留原文；更早历史做摘要；工具大结果只留摘要与引用、原文可回查。摘要提示要写成有输出契约的抽取任务而不是“请总结一下”：固定字段输出、明确不确定的信息不要猜、保留数字与专有名词；更好的做法是分块摘要再合并。发现丢失靠三道：压缩前后对关键实体与数字做一致性校验；高风险动作前做约束自检；线上监控压缩后紧跟的失败率、重试率与用户纠正率。补救与回退要预先设计：压缩只替换注入内容、原始历史保留，检测到丢失就从原文重取或重新压缩；压缩失败要能退化为不压缩加硬裁剪的兜底路径，而不是直接报错。

6. 可观测性、归因、并发写冲突与幂等。 可观测性要能回答“这一次为什么失败”：Trace 按请求、轮次、步骤三层记录（步骤层含模型调用的输入摘要、输出、用量、耗时，工具调用的参数、结果摘要、重试与错误），加指标（成功率、P95 延迟、首 token 时间、工具成功率、token 与成本、队列深度）与结构化日志，三者用同一 traceId 串起来。归因靠逐层排除与回放：换上下文或提示看是不是模型能力问题、核检索是否召回证据、核工具是否成功且参数正确、看规划与路由是否走错分支；延迟分解判断是容量问题还是逻辑问题。多 Agent 并发写同一文件靠按任务分目录避免同写，必须共写时用版本号 CAS，或让各 Agent 输出补丁由单个合并者串行应用。幂等靠业务唯一键加状态机：用“用户 ID 加意图加参数哈希”或客户端 requestId 建唯一约束，重复请求直接返回已有任务；状态流转用 CAS。

7. 二叉树层序遍历。 用 BFS 加队列：根入队，循环里先记录当前队列长度（本层节点数），弹出恰好这么多节点收集值并把非空左右子节点入队，循环结束把本层结果加入输出，空树返回空数组。要点是先取 size 再遍历，否则会把下一层节点混进本层；入队前判空避免 null 进队列。常见追问的扩展：锯齿形输出就在偶数层反转本层结果；要求 O(1) 额外空间可用 Morris 风格或给节点加 next 指针在已有层上串链。复杂度是时间 O(n)、空间 O(w)。面试时先把边界（空树、单节点、只有左或只有右的退化链）讲出来，通常比代码本身更能体现熟练度。