百度智能云数据平台面经

百度智能云数据平台一面

一面时间

2026_0724-17:00

一面内容

1. 自我介绍
2. 看你做了一个沙箱隔离，你们的场景为什么要用到 iframe？
3. iframe 之间怎么通信？
4. AI 流程研发探索，你们是怎么做的？
5. 说说 DataAgent 吧？你主要负责哪些内容？
6. 输入网址按下回车发生了什么？
7. 中间面试官断了录音，后面记不太清了，主要都是聊项目内容。

一面结果

1h 后通知一面通过。

---

百度智能云数据平台二面

二面时间

2026_0727-14:00

二面内容

1. 自我介绍
2. 实习都做了多久？面试官觉得三个月偏短，很难吃透整套业务和研发全流程，所以实习细节没继续深挖太多。
3. 对 DataAgent 很感兴趣，能先说说项目背景和设计思路吗？
4. 智能体可对接 MySQL 等多种数据库，不同数据库的 SQL 存在差异，你们是怎么通过提示词让大模型适配数据库生成正确 SQL 的？
5. SQL 掌握怎么样？
6. 相比通用 Code Agent，你在前端做了哪些定制化开发工作？
7. 用户查询生成数据分析报表后，页面最终渲染展示成什么形式？
8. 有考虑过 ECharts 不支持的图表类型，做其他方案兼容吗？
9. 这个智能体是否支持工具 Skill 调用？
10. 整套智能体前端都是由你来负责吗？
11. 开发过程有哪些比较棘手的前端问题？
12. 这些问题都是靠 AI 解决的吗？
13. 聊下 Sub-Agent 在什么场景能大幅提升效率，哪些场景反而比较鸡肋？举例说明。
14. AI 辅助开发的所有场景里，哪些环节必须人工介入，AI 无法独立完成完整逻辑？
15. 有没有遇到 AI 写出的代码持续出错、完全无法修复，必须人工从头重写的情况？
16. 表单校验：前端校验、后端校验分别解决什么问题？
17. 前端状态管理
18. 什么场景下不适合引用专门的状态管理库？
19. ES6 有哪些核心功能？
20. Symbol 和 Symbol.for() 的区别是什么？
21. 产品给的需求描述模糊，但要求尽快开发，你会怎么处理？
22. 日常开发中，AI 写代码最容易出现哪些错误？
23. 最快到岗时间

---

面试复盘总结

1) iframe 沙箱隔离为什么要用 iframe？（一面 Q2-Q3）

iframe 的核心价值是 运行时隔离。

在低代码、实时预览、第三方页面嵌入、在线编辑器这类场景里，预览内容可能包含独立的 HTML、CSS、JS。如果直接渲染在主应用 DOM 里，会有几个问题：

1. 样式污染：预览页面的 CSS 可能影响主应用，主应用样式也可能影响预览内容。
2. JS 污染：预览代码里的全局变量、事件监听、异常可能影响主应用。
3. 安全风险：用户配置或生成的代码如果直接执行在主页面上下文里，风险很高。
4. 生命周期隔离：刷新 iframe 就能重置整个预览环境，不需要手动清理所有副作用。

iframe 通信通常用 postMessage：

// parent
iframe.contentWindow?.postMessage(
  {
    type: 'PREVIEW_UPDATE',
    payload: schema,
  },
  targetOrigin,
);

// iframe
window.addEventListener('message', (event) => {
  if (event.origin !== allowOrigin) {
    return;
  }

  if (event.data.type === 'PREVIEW_UPDATE') {
    renderPreview(event.data.payload);
  }
});

回答时要强调两点：

1. 必须校验 origin，不要无脑接收所有消息。
2. 消息结构要协议化，比如统一 type、payload、requestId，复杂场景里还要支持 ack 和错误回传。

2) DataAgent 项目怎么讲？（一面 Q5，二面 Q3-Q10）

这场二面重点围绕 DataAgent 展开，建议回答时不要直接陷入细节，而是先讲清楚项目结构。

可以按四层讲：

1. 业务背景：用户希望通过自然语言完成数据查询、分析和报表生成，降低写 SQL、查表和做图的门槛。
2. Agent 流程：用户输入问题 -> Agent 理解意图 -> 选择数据源和工具 -> 生成 SQL -> 执行查询 -> 生成图表配置 -> 页面渲染报表。
3. 前端职责：对话交互、流式输出、任务状态展示、图表渲染、错误兜底、结果导出、上下文管理。
4. 工程难点：多数据库 SQL 方言、图表类型适配、长任务状态、AI 输出不稳定、数据安全和权限边界。

面试表达：

DataAgent 不是一个单纯的 Chat UI，而是把自然语言查询、工具调用、SQL 生成、数据执行和可视化报表串成一条闭环。相比通用 Code Agent，我在前端侧更关注业务链路定制，比如流式对话状态、数据分析过程可视化、图表配置渲染、异常兜底，以及和后端工具调用协议的对齐。

3) 多数据库 SQL 差异怎么适配？（二面 Q4-Q5）

不同数据库的 SQL 方言确实不一样，比如：

• 分页：MySQL 常用 LIMIT offset, size，部分数据库语法不同。
• 时间函数：DATE_FORMAT、TO_CHAR 等函数不同。
• 字符串函数、类型转换、窗口函数支持程度也不同。

如果只靠一句 prompt 让模型“自己适配”，很容易不稳定。更可靠的做法是 数据库方言上下文 + Schema 上下文 + 示例约束 + 执行校验。

用户问题
  -> 注入数据库类型：MySQL / PostgreSQL / ClickHouse
  -> 注入表结构和字段说明
  -> 注入方言规则和禁止事项
  -> 注入 few-shot SQL 示例
  -> 生成 SQL
  -> SQL 静态检查 / explain / dry-run
  -> 执行或返回修正

面试里可以这样说：

我不会只依赖模型记忆 SQL 方言，而是把数据库类型、表结构、字段含义、方言规则和示例 SQL 一起注入上下文。生成后还要经过 SQL 校验，比如只允许 SELECT、限制表范围、做语法检查或 dry-run。如果执行失败，再把错误信息结构化回传给模型进行修正。这样比单纯提示“请生成 MySQL SQL”稳定得多。

4) ECharts 不支持的图表类型怎么兼容？（二面 Q8）

可以分层兜底：

1. 优先映射到 ECharts 支持的基础图表：折线、柱状、饼图、散点、雷达、热力图。
2. 复杂图表转组合图：比如指标卡 + 表格 + 柱状图组合展示。
3. 保留表格兜底：任何查询结果至少可以表格化展示。
4. 接入自定义渲染：ECharts custom series、SVG、Canvas 或第三方图表库。
5. 让模型输出受限 DSL：不要让模型直接生成任意 ECharts option，而是生成受控的图表描述，再由前端转换。

核心回答：

AI 生成图表不能完全信任自由 option。更稳的是让模型输出受控图表 DSL，比如 chartType、dimensions、measures、encoding，然后前端根据白名单转换成 ECharts 配置。不支持的图表类型先降级成表格或基础图表组合，必要时再接 custom series 或其他渲染方案。

5) Sub-Agent 什么时候有用，什么时候鸡肋？（二面 Q13）

Sub-Agent 有价值的场景：

1. 任务复杂且可拆分：比如需求分析、代码生成、测试补全、代码审查可以分角色处理。
2. 上下文容易污染：比如一个 Agent 专门读日志，一个 Agent 专门读代码，一个 Agent 专门输出修复方案。
3. 需要并行探索：比如同时对比多个技术方案或多个 bug 假设。
4. 需要独立审查：实现 Agent 写完后，让 Review Agent 从缺陷角度检查。

比较鸡肋的场景：

1. 任务很小：简单改文案、改样式，多 Agent 反而增加协调成本。
2. 上下文强耦合：所有信息必须连续推理，拆开容易丢上下文。
3. 目标不明确：需求没澄清时，开多个 Agent 只会并行放大错误。
4. 缺少可验证输出：如果每个 Agent 的结果无法自动校验，很容易变成多份幻觉。

一句话：

Sub-Agent 的价值是隔离上下文和并行处理复杂任务，但前提是任务能拆、边界清晰、输出可验证。否则多 Agent 只是增加协调成本。

6) AI 哪些环节必须人工介入？（二面 Q14-Q15, Q22）

AI 很适合做代码草稿、模式迁移、样板代码、文档总结、测试补全，但以下环节必须人工介入：

1. 需求澄清：AI 不能替产品和业务决定真实目标。
2. 架构取舍：边界、长期维护成本、团队习惯需要人判断。
3. 安全和权限：鉴权、数据脱敏、越权风险必须人工审查。
4. 复杂 bug 定位：AI 容易沿着错误假设继续修。
5. 上线风险判断：灰度、回滚、监控、影响范围需要工程经验。

AI 写代码常见错误：

• 编造不存在的 API
• 忽略边界条件
• 破坏现有架构约束
• 写出能跑但不可维护的代码
• 类型和运行时行为对不上
• 只修表象，不修根因

如果 AI 连续修错，应该停止让它继续 patch，把问题拆回人类可验证的最小单元：复现路径、输入输出、日志、断点、最小修复。

7) 表单校验：前端校验和后端校验分别解决什么问题？（二面 Q16）

表单校验可以分成三层：交互体验层、业务规则层、安全可信层。

前端校验解决什么？

前端校验主要解决 用户体验和即时反馈。

比如：

• 必填项没填，立即提示
• 手机号格式不对，输入时提示
• 密码强度不够，实时反馈
• 两次密码输入不一致，提交前提示
• 日期范围不合法，直接禁止选择

前端校验的价值是减少无效提交，让用户更快修正问题，也减少一部分无意义请求。

但前端校验不能作为安全边界，因为用户可以绕过页面，直接调接口。

后端校验解决什么？

后端校验主要解决 数据正确性、安全性和最终可信。

比如：

• 用户是否有权限提交这个表单
• 金额、库存、状态流转是否合法
• 数据库唯一约束是否满足
• 是否存在越权修改
• 是否有 SQL 注入、XSS、非法字段
• 前端没有传或恶意篡改的字段是否安全

后端必须重新校验所有关键数据，因为只有后端校验才是可信的。

怎么配合？

推荐回答：

前端校验负责体验，后端校验负责可信。前端可以做必填、格式、长度、简单业务规则，让用户快速得到反馈；后端必须做权限、数据一致性、安全规则和最终业务约束。两者不是替代关系，而是分层协作。尤其是涉及金额、权限、状态流转这类关键逻辑，前端可以提前拦截，但后端必须重新校验。

8) 前端状态管理：什么时候不适合引入专门状态管理库？（二面 Q17-Q18）

不适合引入状态管理库的场景：

1. 状态只在单组件内部使用，用 useState / ref 就够了。
2. 状态只在父子组件之间传递，props / emit / context 可以解决。
3. 状态是 URL 状态，比如搜索、筛选、分页，更适合放在 query 参数里。
4. 状态是服务端缓存，比如接口数据，更适合交给 React Query / SWR 这类数据请求库。
5. 项目规模很小，引入 Pinia / Redux / Zustand 反而增加概念成本。

面试表达：

我不会因为有状态就上状态管理库。状态管理库适合跨页面、跨模块、多组件共享且更新规则复杂的状态，比如用户信息、权限、全局配置。局部 UI 状态、表单临时状态、URL 查询状态和服务端缓存数据，应该放在更合适的位置。

9) ES6 核心功能有哪些？（二面 Q19）

可以按类别回答：

• 变量声明：let、const
• 函数增强：箭头函数、默认参数、剩余参数
• 解构与扩展：数组/对象解构、扩展运算符
• 模板字符串
• 类：class、extends
• 模块化：import、export
• 异步基础：Promise
• 新集合：Map、Set、WeakMap、WeakSet
• 迭代协议：Iterator、Generator、for...of
• 元编程：Proxy、Reflect、Symbol

10) Symbol 和 Symbol.for() 的区别是什么？（二面 Q20）

Symbol 用来创建唯一值，主要用于避免属性名冲突。

const a = Symbol('id');
const b = Symbol('id');

console.log(a === b); // false

即使描述一样，每次 Symbol('id') 都会创建一个全新的唯一值。

Symbol.for(key) 会先去全局 Symbol 注册表里查找：

• 如果存在同名 key，就返回已有 Symbol。
• 如果不存在，就创建一个新的 Symbol 并注册到全局表。

const a = Symbol.for('id');
const b = Symbol.for('id');

console.log(a === b); // true

区别总结：

对比点	Symbol()	Symbol.for()
是否每次唯一	是，每次创建新值	同 key 复用同一个值
是否进入全局注册表	否	是
能否跨模块共享	不方便	可以通过 key 共享
适合场景	私有属性、防止冲突	全局约定、跨模块复用

补充：

const local = Symbol('foo');
const global = Symbol.for('foo');

console.log(Symbol.keyFor(local)); // undefined
console.log(Symbol.keyFor(global)); // 'foo'

Symbol.keyFor() 只能查到通过 Symbol.for() 注册的 Symbol。

面试表达：

Symbol() 每次都会创建唯一值，适合做对象私有 key 或避免属性冲突；Symbol.for() 会使用全局注册表，同一个 key 会返回同一个 Symbol，适合跨模块共享约定。两者最大的区别就是是否进入全局 Symbol registry。

11) 需求模糊但要求尽快开发怎么办？（二面 Q21）

可以按“先澄清最小闭环，再并行推进”的方式回答：

1. 先确认目标：这个需求解决谁的问题，核心指标是什么。
2. 切出 MVP：先交付最小可用闭环，不一开始做大而全。
3. 明确边界：哪些做，哪些暂不做，异常场景怎么处理。
4. 同步风险：把不确定点写清楚，避免默认理解不同。
5. 快速原型：用低保真页面或 Demo 让产品确认。
6. 边开发边对齐：关键节点及时同步，而不是最后才验收。

一句话：

需求越模糊，越不能直接闷头写。我会先把目标、用户路径、边界和验收标准拉齐，再拆一个最小可用版本。如果必须并行开发，就把不确定点显式列成风险，并用原型或阶段性 Demo 快速校准。