度小满 AI 全栈二面：故障诊断 Agent 编排与后端基础

《面试题目》

1. 请介绍故障定位的整体工作链路，中间哪些部分是你具体负责、投入比较多的？
2. 你提到把 Workflow 转成 Skill，两种方式哪一种回答更准确？各自的优势和劣势是什么？
3. 你说还需要 Agent 或 MCP 的架构配合，具体指哪一段？这些能力属于故障定位平台、云服务，还是现有平台提供？Agent 和 MCP 是你们做的，还是你只提供了一个 Skill？
4. 请简单介绍这个 Agent 的工作流编排。你提到的 Plan、ReAct 和 LangGraph 是现有技术能力，还是你们自己做的？
5. 问题定位是单次执行，还是支持多轮对话？
6. 为什么需要用户授权？中断以后怎样继续任务，保存了哪些状态？Agent 自己有没有记录执行状态？
7. 你简历上的技能很多，语言和中间件中哪些是你特别擅长的？MySQL 在实习时有使用吗？
8. 你了解 MySQL 常见的索引优化吗？慢查询如何处理，索引有哪些注意点？
9. MySQL 和 Redis 的数据一致性通常采用什么方案？你实际工作场景中使用的是哪一种？
10. 请简单讲一次 HTTP 请求的执行链路，想到的都可以说，不必过度展开。
11. 你简历中写到网关路由，网关的主要作用是什么？你觉得网关最主要的功能是什么？
12. 平常用 Codex 等工具开发时，怎样保证 AI 结果的正确性？生成后怎么验收？换一个问法：在让 AI 开始工作前，你通常会做什么来提高输出正确性和可控性？
13. 你觉得现在 AI Coding 还有什么问题？你踩过哪些坑？
14. 还有几分钟，你可以介绍一个刚才没问到、但自己比较擅长的组件或能力，展示一下你的优势。
15. 你在 Skill 或项目中提交的代码大概是什么量级？都是 AI 写的吗？
16. 在 AI Coding、手动编码、算法和互动协作之间，你觉得自己哪方面最强？
17. 请做一个简单的自我介绍。

《参考解析》

Workflow 还是 Skill：这道题在考边界划分

这类追问的本质是让候选人把”我做了什么”和”平台提供了什么”分清楚。Workflow 是确定性编排——步骤固定、条件分支显式、可测试可回放；Skill 是把某类能力封装成模型可调用的原子单位（描述 + 输入输出契约 + 实现），由 Agent 在运行时决定何时调用。把一条故障定位链路做成 Workflow，好处是可控、可审计、每步可重试，坏处是分支写死、遇到新场景要改代码；做成 Skill，好处是复用与组合灵活、能被不同 Agent 装载，坏处是调用时机交给模型、行为不完全可预测、出错路径变多。

所以”哪一种回答更准确”取决于问的是哪个层面：如果问的是故障定位的业务流程怎么走，Workflow 更准确（步骤是业务固定的）；如果问的是这套能力怎么被复用和调用，Skill 更准确（它是能力暴露形态）。好的答法是分层说：编排层用 Agent（Plan 出计划、按需调 Skill），能力层用 Skill（每类诊断动作一个），执行层用 MCP/工具（真正去查日志、拉监控、执行命令）。这样职责边界清楚，也解释了为什么”还需要 Agent 或 MCP 配合”——Skill 只负责”能做什么”，Agent 负责”什么时候做、做完怎么判断”，MCP 负责”以标准协议把这些能力接进模型”，三者不是替代关系。回答时务必如实交代哪些是自己写的、哪些是平台/云服务已有的，面试官连问三遍同一件事，通常就是在验证边界是否真实。

Agent 编排与状态恢复

Plan / ReAct / LangGraph 这三样要分清”框架提供什么”和”你实现了什么”：LangGraph 是编排框架，提供节点/边、条件跳转、检查点（checkpointer）机制；ReAct 是一种推理范式（thought → action → observation 循环），框架里有现成的 agent 实现；Plan-and-Execute 是另一种范式（先出计划再执行）。通常自己写的是：计划的结构定义、Replan 触发条件、工具契约、以及状态存储方案；框架提供的是调度循环和持久化骨架。

为什么需要用户授权、中断后怎么续跑，是同一个问题的两面。需要授权是因为诊断类 Agent 会执行有副作用的动作（重启服务、扩容、改配置、拉取敏感日志），这类操作必须有人在环确认；这也顺带解决了合规和审计问题。中断续跑的关键是状态外置：把”当前计划、已完成步骤及其产物、每步的工具调用 id 与幂等键、待确认的授权请求、会话上下文摘要”持久化到存储（DB 或 checkpointer），恢复时按任务 id 读回状态、从最后完成的一步继续，并把待授权项重新呈现给用户。要如实说明 Agent 本身有没有自己的执行状态记录——多数 Agent 只有内存里的对话历史，落盘状态是工程侧补的，这一点含糊过去会在下一轮追问里露馅。

MySQL 索引与慢查询

索引优化的主干是：先看执行计划（EXPLAIN，重点看 type、key、rows、Extra 里的 Using filesort / Using temporary），再谈加索引。常见手段有——联合索引遵循最左前缀原则（范围查询之后的列用不上索引，所以等值列放前、范围列放后）；覆盖索引避免回表（把 SELECT 需要的列放进索引，Extra 出现 Using index 才算真覆盖）；避免在索引列上做函数或隐式类型转换（WHERE DATE(create_time) = ... 用不上索引，varchar 列传数字也会导致全表扫描）；LIKE '%x' 左模糊无法用索引；OR 跨列、!=、NOT IN 选择性差时优化器可能直接放弃索引。索引不是越多越好——每个索引都增加写放大和存储，且优化器选择成本上升，一般单表索引控制在 5 个以内，优先建高频查询真正需要的。

慢查询的处理流程：开 slow_query_log 与 long_query_time，用 mysqldumpslow 或 pt-query-digest 聚合出 TOP SQL，按”改 SQL（消除回表/排序）→ 加或调索引 → 改表结构（分表、加冗余列）→ 改架构（缓存、读写分离、归档冷数据）“的代价顺序逐级处理。另外要能说出深分页（LIMIT 1000000, 10）的优化方式：用上次的最大 id 做游标（WHERE id > last_id LIMIT 10）或延迟关联（先用覆盖索引取主键再 join 回表）。

MySQL 与 Redis 的一致性

常见方案按一致性强度排：① 先更新 DB 再删除缓存（Cache-Aside，最常用）；② 先删缓存再更新 DB（并发下有旧值回填风险，需要延迟双删）；③ 订阅 binlog（Canal/Debezium）异步删缓存，把”删除动作”从业务代码里解耦，可靠性最高；④ 强一致场景用分布式锁或把缓存当只读副本走版本号校验。要能说清为什么是”删缓存”而不是”更新缓存”——并发写时更新缓存容易留下旧值，而且很多缓存值需要计算，删除是惰性的、更安全。

最经典的失效场景是”读请求回填旧值”：请求 A 更新 DB 后删缓存，但请求 B 在 A 更新前读到的旧值恰好在 A 删缓存之后才写入缓存，缓存里就长期留下旧数据。缓解手段是给缓存设 TTL（兜底最终一致）、延迟双删（写完 DB 后隔几百毫秒再删一次）、或者用 binlog 订阅 + 重试。要如实说清自己项目里用的是哪一种以及为什么——面试官问”你实际用的是哪种”就是在验真实性，答”我们用的延迟双删，TTL 兜底，因为业务对一致性要求是秒级”比背八股可信得多。

HTTP 链路与网关的作用

一次 HTTP 请求的链路可以按顺序叙述：DNS 解析（浏览器缓存 → 系统 hosts → 本地 DNS → 递归查询，返回 IP）→ 建立 TCP 连接（三次握手；HTTPS 还要 TLS 握手，协商密钥与证书校验）→ 构造请求（方法、路径、头部、Cookie、请求体）→ 可能经过 CDN 边缘节点（命中缓存直接返回，未命中回源）→ 负载均衡（LVS/四层 → Nginx/七层）→ 网关（鉴权、限流、路由、协议转换）→ 应用服务（中间件、DB、缓存）→ 反向返回（响应头、状态码、可能的压缩与分块）→ 连接复用或关闭。加分项是提一句 HTTP/1.1 的队头阻塞与 HTTP/2 多路复用、HTTP/3 走 QUIC 的差异。

网关的主要作用：统一入口与路由转发、鉴权与认证、限流与熔断、灰度与流量染色、协议转换（HTTP ↔ gRPC/Dubbo）、可观测性（统一 access log、traceId 透传）。如果只能选一个”最主要的功能”，答统一入口最稳：它把”所有外部流量都从这里进”这件事变成架构约束，鉴权、限流、灰度、日志都是这个约束带来的副产品；对外部系统来说，网关是唯一需要暴露的地址，内部服务可以随意重构而不影响调用方。这个答法比罗列功能更显结构化。

AI Coding 的正确性保障

让 AI 工作之前做的事，比生成之后补救更重要：把任务拆到足够小（一次改一个函数/一个模块，改动面越小越好验收）、明确写出验收标准和边界条件、提供必要的上下文（相关文件、接口约定、既有代码风格、不可破坏的约束）、让它先给方案再写代码（改哪几个文件、为什么这么改，方案错了就停）、以及把可自动验证的信号准备好（测试命令、类型检查、lint）。生成之后：跑测试和类型检查、逐块 review diff、检查错误处理与边界、把关键路径补上测试、必要时让另一个模型做对抗性 review。

AI Coding 现存的问题和坑：幻觉出并不存在的 API 或库函数（尤其是版本较新的框架）；只实现 happy path，错误处理、超时、并发、边界全靠人补；“改 A 引起 B 坏”（看不到隐含调用方）；为了通过测试而改测试而不是改实现；大范围重构时静默丢掉原有行为；上下文窗口外的代码被忽略导致风格/约定不一致；以及过度自信的解释（说得头头是道但结论错）。对应的工程经验是：小步提交、每步可回滚、关键模块不让 AI 单独决定架构、把重复踩的坑写成项目级的规则文档喂给它。

自我展示类问题怎么答

“介绍一个没问到但你擅长的能力”这类题，考的是取舍能力——不要罗列，选一个和岗位最相关的、能讲三层深度的（是什么、我在里面解决过什么具体问题、如果重做会怎么改）。代码量级要如实说，并且分清”我提交的”和”AI 生成的”：可以答”这个模块大约几千行，其中骨架和接口是我设计的，实现和测试有相当一部分是 AI 补的，但每一行我都 review 过”，同时给一个你确实亲手调过的难点的例子来证明这一点——比硬说”全是我写的”更可信。最后一问”你哪方面最强”要给出理由和证据（比如”算法和排障，因为线上那次事故是我用二分定位到具体 SQL 的，过程是这样……”），而不是只报一个词。