极智科实习面经

极智科实习面经

面试时间

2026_0902-20:00

面试内容

1. 做一下自我介绍
2. 介绍百度 Data Builder 平台业务流程和大致技术架构
3. Data Agent 多 Agent 同时执行分析任务，前端如何做状态隔离、事件缓冲和多任务并发处理？
4. 大规模日志渲染优化，数据量级是多少？做了哪些处理？
5. 日志搜索跳转到指定行号，offset 偏移量如何计算？
6. 日志数据是全部存在内存中吗？
7. 搜索输入过程中，对 API 请求做了哪些限制与处理？例如防抖、请求竞态等
8. 实习主要做前端，有没有接触过后端开发？
9. 百度 Data Agent 与阿里 Spring AI 开源 Data Agent，两个项目有什么区别？
10. 从前端角度对比两个项目的技术栈、优缺点
11. 开源 Data Agent 项目做 Next 4 框架迁移，为什么要做这次迁移？
12. 为什么“约定大于配置”的模式会对 AI 编码更友好？
13. 介绍双层上下文治理机制；该技术为什么没有在百度 Agent 项目使用？两者差异是什么？
14. 快手电商审核治理平台，介绍运营拖拽生成罚单模板这套 Schema 驱动零代码方案
15. Schema 内部存放什么内容？Schema 的定义边界是什么？
16. 如果运营配置 Schema 出错，影响范围多大？如何规避错误？
17. 新增需求，需要从新接口拿用户等级做差异化文案展示，Schema 是否原生支持？该如何处理？
18. 候选人反问环节，了解业务和团队 AI 开发工作流

---

面试复盘总结

1. 大规模日志渲染优化

日志场景的核心问题是数据量大、更新频繁和搜索定位要求高。可以从几个方面回答：

• 使用虚拟列表，只渲染可视区域的日志行。
• 将日志分块加载，避免一次性把全部数据放进 DOM。
• 对静态内容和实时追加内容分开处理，减少整列表重渲染。
• 使用稳定的行 ID 和 memo，避免无关行重复更新。
• 搜索时只返回匹配结果和必要上下文，不在主线程进行大规模同步计算。
• 对高频输入做防抖，对请求结果做竞态控制和取消。

日志数据也不应该简单地全部放在前端内存中。可以根据场景采用分页、分片、服务端搜索或流式读取；前端只保留当前窗口、搜索上下文和必要的缓存，避免内存持续增长。

2. 日志跳转与 offset 计算

如果日志按固定行高渲染，可以通过：

offset = targetLineIndex * rowHeight

直接定位；如果行高不固定，则需要记录每行高度或使用虚拟列表提供的测量结果，维护行号到滚动位置的映射。服务端返回搜索结果时，最好携带文件或分片 ID、行号、字符偏移等稳定信息，前端再根据当前渲染窗口计算目标位置。

定位时还需要考虑：

• 搜索结果对应的日志分片是否已经加载。
• 目标行是否在当前虚拟列表窗口之外。
• 字体、折行和容器宽度变化导致的动态高度。
• 新日志追加后行号和 offset 是否发生变化。

3. Data Agent 多任务状态隔离

多个 Agent 同时执行分析任务时，不能把所有事件放进一个全局消息池。更合理的数据结构是按会话和任务隔离：

conversationId
  -> taskId
    -> eventBuffer
    -> messageList
    -> status
    -> subscribers

每条事件携带 conversationId、taskId、事件 ID、序号和状态。前端根据任务 ID 路由事件，分别更新任务卡片、消息列表和进度状态。事件缓冲用于处理网络抖动、消费速度不一致和重连补发；旧任务结束后及时释放订阅和缓存，避免内存泄漏。

4. 为什么迁移到 Next 4

框架迁移不能只说“新版本更好”，需要结合项目目标说明：

• 统一前后端开发模型和路由、数据请求、页面渲染方式。
• 利用服务端渲染、流式响应和更完整的工程能力改善体验。
• 获得更好的 TypeScript、构建、部署和生态支持。
• 降低历史框架约束，方便 AI 按约定目录和模式生成代码。

迁移前还需要评估兼容性、依赖替换、路由差异、部署方式、性能收益和回滚方案，不能为了追新版本而迁移。

5. 为什么约定大于配置更适合 AI 编码

配置分散在多个文件、隐含在团队习惯或依赖人工记忆时，AI 很难稳定推断正确写法。约定大于配置可以把目录结构、文件命名、路由位置、组件入口和数据流固定下来，让 AI 更容易通过少量上下文推断完整项目结构。

它的价值包括：

• 减少方案搜索空间，降低模型决策难度。
• 让代码检索、模块 README 和 AST 索引更容易建立。
• 生成结果更符合现有工程结构，减少无意义的配置代码。
• 更容易通过静态检查和自动化规则发现偏离约定的实现。

6. Schema 驱动零代码方案

罚单低代码平台中的 Schema 通常描述表单结构和运行时行为，包括：

• 字段类型、标题、默认值和校验规则。
• 布局、组件属性和数据源。
• 字段联动、显示隐藏、可编辑状态和依赖关系。
• 提交接口、权限信息和必要的业务扩展点。

Schema 的边界应该是“可配置的稳定业务规则”，而不是把所有复杂业务逻辑都塞进 JSON。跨字段联动、动态选项和展示规则适合通过表达式或 reactions 描述；复杂异步逻辑、权限校验和强业务流程仍应由服务端或受控扩展点负责。

7. 如何规避错误 Schema 的影响

运营配置出错时，影响范围可能从单个表单字段扩展到整条审核流程，因此需要多层防护：

1. Schema 编辑器提供字段类型、必填项、依赖关系和表达式校验。
2. 保存前进行 JSON Schema 校验、版本校验和静态检查。
3. 发布前提供预览、测试数据和灰度环境。
4. 正式发布使用版本号、审批流和可回滚配置。
5. 运行时保留默认值、错误边界和异常降级。
6. 对高风险配置限制权限，并记录修改人和变更内容。

8. 新接口差异化展示如何处理

如果只是根据用户等级展示不同文案，Schema 可以原生支持数据依赖和条件表达式：先声明用户等级作为依赖，再由展示规则决定文案或组件状态。如果需要调用新接口获取用户等级，则应由数据源或受控扩展层提供数据，Schema 只描述“依赖什么数据、满足什么条件、展示什么结果”。

这样可以保持配置层清晰，避免把请求、鉴权、错误重试等复杂逻辑直接写进 Schema，同时让相同的展示规则可以复用到不同表单和业务页面。

9. 这场面试的核心提醒

这场面试同时覆盖了 Data Agent 的并发状态、日志系统性能、框架迁移、上下文治理和 Schema 低代码，考察的是把 AI 能力和前端工程落地结合起来的能力。准备时需要同时能讲清楚底层数据流、性能边界、业务配置边界和团队协作方式。