字节全栈二面：SSE、知识图谱与多 Agent 编排

《面试题目》

1. 请先简单做一下自我介绍。
2. 你简历里的 AI 经历比较多，但计算机基础相关内容较少。你对计算机基础知识的了解怎么样？
3. 你是否有前后端两方面的开发经历，包括 JavaScript、Vue 等语言和框架的使用？
4. 你简历里提到了基于 SSE 和 Event Trace 的 Agent 可视化工作台，能介绍一下 SSE 吗？
5. 为什么 Event Trace 选择 SSE？是因为只需要单向推送，不需要双向交互吗？
6. 除了单向、双向通信的区别，SSE 和 WebSocket 还有哪些区别？
7. 实习时研究的代码知识图谱，整体是用什么结构组织的？
8. 你刚才介绍的这部分，是否就是你在代码知识图谱方向主要负责的工作？
9. 你做的更多是基于知识图谱的上层应用能力，那么你对知识图谱本身的底层原理了解多少？
10. 知识图谱存成一张图时，底层使用什么数据结构？读取这张图时如何遍历？
11. 你的个人项目是否使用了 MyBatis、MySQL 和 REST API？MySQL 主要存储哪些数据？
12. 能讲一下 MySQL 的事务隔离吗？
13. 事务隔离有哪些级别？
14. RR 和 RC 最主要的区别是什么？
15. 能举一个你在项目中真实创建索引的例子吗？
16. 你的订单表大概是什么量级，有多少条数据？
17. 为什么用「订单号 + 购买者 ID」建立联合索引？
18. 选一个你投入比较多，或者收获比较大的实习项目，详细介绍一下。
19. 在这个多智能体平台中，你负责的是其中一部分，对吗？具体职责边界是什么？
20. 什么情况下应该抽象成一个专业 Agent，什么情况下只需要一个 Skill？你如何区分和判断？
21. 你说 Agent 应该自主判断、决策，但实际又使用固定的 Workflow 编排，没有完全采用 ReAct 等自主决策模式，这是怎么考虑的？
22. 是否希望整个流程的骨架与功能点固定下来？
23. 整个多 Agent 编排，包括编排引擎，是你们自己实现的吗？
24. 多 Agent 之间如果出现调度冲突、输出冲突或者其他异常，你们会怎么处理？
25. 听起来目前主要是失败通知和中断恢复，是否也有自动修复能力？
26. 这些不同场景下的冲突处理、失败处理链路，具体是怎么实现的？是提前通过 Workflow 编排好的，还是部分交给大模型判断，只在关键节点做约束？
27. 是否可以理解为 Agent 内部自主决策，而主 Agent 到各子 Agent 的流程由人为编排？
28. 以「测试环境拉不起来」为例，重试三次、失败后存储信息并通知研发，这条链路是固定的 Skill 吗？
29. 是否是把部署环境、失败信息入队等能力拆成多个 Skill，再自行编排起来？
30. 既有 Agent 之间的相互调用，又有每个 Agent 内部的多步骤执行，你们如何评估 Agent 本身的稳定性？
31. 你刚才讲的是如何验证 Agent「可用」，但可用不代表稳定。你们如何评估多次执行结果的稳定性？准确率大概维持在什么水平？
32. 你们是否做过整体、系统性的 Agent 效果评测？还是主要依赖不同的人去尝试？
33. 有没有遇到过模型幻觉，例如需求识别不准确、执行偏离预期？你们怎么规避？
34. 如果把传统电商从搜索商品到下单的全流程改造成通过与 Agent 交互完成，你会怎样设计整体架构？
35. 用什么业务指标衡量这个 Agent 的效果？
36. 你的方案是一个主 Agent 配合若干功能，还是拆成多个 Agent？是否可以概括为「单 Agent + 多 Skill」？
37. 研发平台和电商下单都是相对固定的流程，为什么前者使用多 Agent，后者使用单 Agent？这两种结构的划分依据是什么？
38. 你用「前后端可以并行」解释多 Agent 的必要性，但单 Agent 调用多个 Skill 也能实现并行。那为什么仍然需要多 Agent？
39. 是否可以理解为：研发平台整体由主 Agent 集中协调，但各子 Agent 又能独立运行、单独承接任务？
40. 手撕：非 Hot100 中等题。

《参考解析》

SSE 与 WebSocket 的选择。 SSE（Server-Sent Events）是浏览器原生的单向服务器推送：一个普通 HTTP 长连接，响应头 Content-Type: text/event-stream，服务端按 data: ...\n\n 的格式持续写，浏览器用 EventSource 接收，自带断线重连和 Last-Event-ID 续传。WebSocket 是独立协议，通过 HTTP Upgrade 握手后变成全双工帧通道，客户端和服务端都能主动发。选 SSE 的典型理由是：事件流只需要服务端 → 客户端单向推送（Agent 执行 trace、日志、进度），实现简单、走标准 HTTP（鉴权、网关、压缩、HTTP/2 多路复用都现成），断线重连不用自己写；代价是单向、浏览器并发连接数有限（HTTP/1.1 下同域 6 个）、以及需要处理代理缓冲（X-Accel-Buffering: no）。选 WebSocket 的理由是需要双向、低延迟、高频交互（协同编辑、聊天、游戏）。「单向」不是唯一区别：SSE 是文本协议、自动重连、天然支持事件 id；WebSocket 是二进制/文本帧、需要自己设计心跳和重连、但全双工且没有 HTTP 头开销。

知识图谱的存储与遍历。 逻辑上是「实体-关系-实体」的三元组，物理上两种主流存法：原生图数据库（Neo4j 用邻接表 + 属性存储，遍历走指针）和关系型/三元组表（subject, predicate, object 三列，加索引），大规模还会用 RDF 存储或图计算框架。底层数据结构可以答「邻接表」（每个顶点挂出边列表，适合稀疏图、遍历邻居快）或「邻接矩阵」（适合稠密图、判断两点是否相连 O(1)，但空间 O(n²)）；图数据库通常用「无索引邻接」——每个节点直接存关系指针，跳数少时比关系型 join 快几个数量级。遍历算法：BFS（最短路径、按层扩展）、DFS（连通性、路径枚举）、以及带权的最短路（Dijkstra/A*）和社区发现（Louvain）。工程上还要讲：点/边属性索引、超节点（超级节点会导致遍历爆炸，要做截断或分层）、以及图查询语言（Cypher/Gremlin/SPARQL）。如果只是「代码知识图谱」，更常见的是把代码实体（类、方法、调用关系）抽成图，存 Neo4j 或直接用向量库 + 图结构混合检索。

MySQL 隔离与索引。 隔离级别见另一题的展开：RU/RC/RR/Serializable，InnoDB 默认 RR；RR 与 RC 的核心差异是快照读的 ReadView 生成时机——RC 每次快照读都生成新 ReadView（能看到别人已提交的新数据），RR 在事务第一次快照读时生成并复用（同一事务内看到的是同一个快照）。索引方面，「订单号 + 购买者 ID」的联合索引要讲清最左前缀：如果查询条件是 order_no = ? AND buyer_id = ?，联合索引能同时命中两列；如果只按 buyer_id 查，用不上这个索引（除非有覆盖索引或索引跳跃扫描）。设计理由通常是：订单号唯一、查询以订单号为主，同时按购买者查订单列表；把区分度高的列放左边，把范围查询列放最后。还要能说清回表、覆盖索引、以及 EXPLAIN 里 type/rows/Extra 的含义。订单量级问题是在验证你是否真的做过容量设计：日订单量、总行数、单表多大、有没有分库分表、索引占多少空间。

Agent 与 Skill 的抽象边界。 判断标准不是「功能大小」，而是「是否需要独立的决策循环」。Skill 是确定性的能力封装：输入输出明确、步骤固定、可测试、失败可枚举（查天气、发消息、跑一条 SQL、调一个部署接口）。Agent 是带自主性的执行者：需要自己规划步骤、选择工具、根据中间结果调整策略、处理开放式目标。所以「测试环境拉不起来」这种链路，如果是固定脚本（拉起 → 检查 → 重试三次 → 通知），它就是 Skill/Workflow，不该包装成 Agent；如果它需要根据日志判断失败原因、决定换哪种修复手段，那才需要 Agent。反过来说，把一切都做成 Agent 会带来不可控：延迟高、成本高、评测难、出错难复现。合理的架构是「Workflow 定骨架、Agent 填不确定的环节、Skill 做确定性动作」——骨架保证可观测和可恢复，Agent 只在需要判断的节点介入。

为什么用固定 Workflow 而不是全 ReAct。 ReAct 是「 thought → action → observation」循环，灵活但不可控：容易死循环、步骤数不可预期、成本高、失败后难以定位、也不容易做权限与审计。研发平台这类流程有明确的阶段（理解需求 → 定位仓库 → 改代码 → 跑测试 → 部署 → 验证），每个阶段的输入输出、成功条件、回滚动作都能定义，所以用 Workflow 编排更合适：每个节点可以是 LLM 调用、Skill、或子 Agent，节点之间用状态机/ DAG 串起来，失败可重试、可中断恢复、可人工接管。折中做法是「外层 Workflow、内层 ReAct」：在某个节点内部允许 Agent 自主探索，但整个流程的骨架、预算、终止条件由外层控制。回答时要承认取舍：Workflow 的代价是灵活性差，遇到没预设的路径需要人工扩编排；ReAct 的代价是不可控与难评测。

多 Agent 的冲突、稳定性与评测。 冲突分三类：调度冲突（多个 Agent 抢同一资源/同一任务）、输出冲突（对同一问题给出不一致结论）、状态冲突（共享上下文被并发修改）。处理手段：任务队列 + 幂等键 + 租约（避免重复执行）、主 Agent 统一裁决（子 Agent 只给建议，主 Agent 做最终决策）、以及共享状态用版本号/乐观锁。失败处理要区分「可重试」（网络、限流）和「不可重试」（参数错、权限不足），前者指数退避，后者直接上报；中断恢复靠持久化执行状态（每步写 checkpoint），而不是靠内存。稳定性评估不能只看「跑通一次」：要建固定评测集（输入 + 期望结果/评分标准），重复跑 N 次统计成功率、方差、平均步数、平均成本；线上再看任务完成率、人工接管率、平均耗时、失败原因分布。准确率要给出定义（端到端成功率？关键字段准确率？人工评分？），否则数字没有意义。幻觉规避靠「缩小自由发挥空间」：结构化输出 + Schema 校验、工具返回事实而不是让模型记忆、关键动作前二次确认、以及失败时明确说「不知道」而不是编。

电商 Agent 的架构与指标。 先定边界：是「帮用户找商品」还是「端到端下单」；下单涉及支付、地址、库存、售后，风险和权限要求完全不同。合理设计是分层：意图理解（搜索、比价、咨询、下单）→ 任务规划（需要哪些步骤）→ 工具层（商品搜索、详情、库存、优惠、购物车、订单、支付）→ 执行与确认（涉及金额/地址的步骤必须让用户确认）→ 结果汇总。单 Agent + 多 Skill 适合「流程相对固定、工具边界清晰」的场景：一个 Agent 负责理解与编排，Skill 负责确定性动作，优点是可控、易评测、延迟低。多 Agent 适合「子任务彼此独立、需要并行、且各自有专业判断」的场景：比如同时让「选品 Agent」「比价 Agent」「售后 Agent」独立工作，再由主 Agent 汇总。判断依据是「并行的收益是否大于协调成本」：如果单 Agent 顺序调用三个 Skill 也能在可接受时间内完成，就没必要拆多 Agent；如果子任务需要不同的提示词、工具集、模型、甚至不同的权限边界，拆开更清晰。业务指标要分层：结果指标（下单转化率、GMV、退货率）、过程指标（任务完成率、平均轮次、人工接管率、端到端时延）、质量指标（推荐相关性、价格准确性、幻觉率）、成本指标（token/次、工具调用次数）。上线前用离线评测集 + 小流量灰度，别直接全量。