无锡赫玛科技 AI应用开发面经：Agent 架构、RAG 与高并发系统设计

《面试题目》

一、技术面：项目深挖与 Agent 架构

1. 请做一下自我介绍，并简要概述你在两段实习中的核心工作与成果。
2. 能详细介绍一下电视客诉分析 Agent 的业务背景与前置流程吗？它主要处理哪些日志，当时的数据体量大概有多大？
3. 平台对于技术类客诉是如何进行前置分类与分流的？设备 ID 与报错标签是如何协同过滤的？
4. 客诉分析的专家工作流最初是如何搭建的？为什么后期取消了独立的分类器，改为将各分类沉淀为独立的 Skill 并动态挂载？
5. 该 Agent 目前除了生成根因定位报告之外，是否支持直接自动改代码？业务中没有做自动改代码闭环的考量是什么？
6. 在搭建 RAG 知识库时使用了内部部署的 Dify，你在实际使用中发现它的知识库有什么不足？
7. 在基于 ReAct / Agentic Loop 架构设计深度排障循环（Deep Research）时，你是如何给 Agent 配置工具链以及设计提示词策略的？
8. 基于 n8n 的二开主要补充了哪些自定义节点？系统为何会选择接入 Nacos，在其中起到了什么作用？
9. 这两个实习项目，在实际运行时的用户并发体量分别是多少？
10. 项目中有涉及 Kafka 等消息队列吗？针对当前体量，为什么最终选择使用线程池与阻塞队列而非引入 Kafka？
11. 除了常规的向量 RAG，你对 GraphRAG（图增强检索）或 Neo4j 这类图数据库在 Agent 中的结合应用有了解吗？

二、技术面：后端基础与高并发场景设计

12. 在高并发缓存场景中，常见的缓存穿透一般有哪些处理策略？
13. 你是如何理解悲观锁与乐观锁的？在业务设计中如何权衡锁粒度与并发性能？
14. 系统设计场景题：现有约 40 万条客户数据，后台有 610 名内部人员日常操作，同时有 23 人进行并发查询，该数据每天需要定时全量或批量更新一次。针对这个场景，从存储选型、索引设计、并发控制到 Redis 缓存设计，你会如何架构以保证系统的高稳定性？
15. 当出现并发读与每天定时更新交替时，如何设计缓存更新策略以保证数据一致性？

三、业务与高管面：职业规划与业务认知

16. 你目前的离职状态是怎样的？7 月份实习离职的具体原因是什么？
17. 作为 2027 届毕业生，你未来的工作地点诉求是怎样的？对无锡等苏南城市怎么看？
18. 你对自己在 AI 领域的岗位定位与未来规划是什么？更偏向做大模型工程化调用与状态维护，还是其他方向？
19. 面对「公司内部自研平台研发」与「服务外部制造企业的定制交付、陪跑项目」，你在二者的选择上更倾向哪一种？为什么？
20. 来面试前，你通过哪些渠道了解过我们公司？你了解到的公司核心业务方向是什么？

四、候选人反问环节

21. 后续的面试流程总共有几轮？
22. 该岗位的薪资待遇与日常工作时长、作息大概是怎样的？

《参考解析》

从「独立分类器」到「Skill 动态挂载」，架构为什么会这样演进。 早期做技术客诉分流，最自然的做法是训练或提示一个独立分类器，先判类型再进对应的专家流程。问题在于分类隐含一个封闭集假设：客诉类型会跟着产品迭代不断长出新分支，每加一类就要动标签体系和提示词，而分类只要错一次，后面整条链路都白跑。改成把每一类沉淀为独立 Skill、运行时按需挂载，本质是把「一个大而全的判定」拆成「若干小而专的能力」：某一类的准确率下降不会污染其他类，可以独立迭代与评测；Agent 只加载当前需要的 Skill 说明与工具，上下文更省；业务方补充一条排障经验时新增 Skill 即可，不需要重训模型。代价是编排复杂度上升，需要一套 Skill 路由与冲突处理机制——谁先谁后、命中多个怎么办、全都不命中如何兜底，这往往正是面试官想追问的地方。前置分流里的「设备 ID + 报错标签协同过滤」也值得讲清：先用确定性字段把候选范围收窄（同型号、同固件版本、同错误码的已知问题库），再交给模型做语义研判，成本、延迟和准确率都比把原始日志直接丢给大模型好得多。

RAG 知识库的工程化差距在哪。 用 Dify 这类平台搭内部知识库，起步很快，但真实用起来会撞到几堵墙：切分策略是通用粒度，遇到排障手册这种「步骤强依赖」的文档，切完之后步骤之间断链，检索到的片段答不完整；默认只有向量召回，缺少关键词与向量的混合检索，也缺少 rerank 精排，专有名词、错误码这类字面信号容易漏召回；知识库版本、权限、生效时间这些元数据管理弱，内部资料有保密与时效要求时很难做细粒度隔离；没有内建评测集，改了切分参数只能靠体感比较，做不了回归。工程上的补法是：按文档结构做语义切分并保留标题路径，检索走「关键词 + 向量」双路再融合精排，chunk 里带上来源与版本元数据供生成端引用，同时建一套小而准的评测集（问题、标准答案要点、应召回文档），每次改动都跑一遍。

ReAct 与深度排障循环的工具链设计。 排障类 Agent 的可信度来自证据链，而不是模型的自我推理。工具链要按「取证—推理—验证」三段配置：取证类工具查日志、查监控指标、查变更记录、查同型号历史工单；推理类工具检索知识库与历史相似案例；验证类工具做假设检验，例如按时间窗对齐指标突增与固件升级时间。提示词策略上，与其写一堆「你要认真思考」的祈使句，不如把约束写成可判定的规则：每一步必须说明当前假设与所需证据，工具返回结构化结果并带上时间戳与来源，得出根因前必须至少有一条直接证据支撑，证据不足时输出「待确认项」而不是硬给结论；同时给循环设硬上限（最大步数、同一工具同一参数的调用去重、连续两步无新增信息即终止）。最终报告要能区分「已证实」「高度怀疑」「待验证」三档，这比一份语气笃定但证据松散的结论有用得多。

n8n 二开、Nacos 与「线程池还是 Kafka」的取舍。 工作流引擎二开补自定义节点，通常是因为平台自带节点满足不了内部系统集成：需要封装公司统一鉴权与网关调用、日志与埋点上报、结构化产物落库、失败重试与人工介入节点。接 Nacos 的价值在于把配置、服务发现、灰度开关从代码里挪出来：模型名与提示词版本、工具地址、限流阈值都能动态下发，出问题不用重新发版；服务实例注册让编排层能感知下游健康状态。至于为什么不上 Kafka，这是个典型的「按体量选型」问题：当前并发量下（面试里也追问了实际用户并发），引入 Kafka 意味着多一套中间件要部署、监控、扩容和排障，收益却只是把线程池能扛住的异步任务换成更重的形式。用线程池 + 有界阻塞队列 + 明确的拒绝策略，配合任务幂等与失败落库，已经足够；真正需要 MQ 的信号是跨系统解耦、削峰、广播、可重放这几类需求变成刚需，或者单机队列深度持续打满。

缓存穿透、锁与 40 万条数据的系统设计。 缓存穿透是查一个数据库里也不存在的键，缓存永远不命中，请求全打到存储层。三层处理：入口做参数校验与限流，挡掉明显非法的 id；对确认不存在的查询缓存空值（短 TTL，注意与「数据后来出现」的冲突）；用布隆过滤器在缓存前拦一层，代价是有假阳性且删除不友好。悲观锁先加锁再操作，适合冲突一定会发生、临界区较长的场景，粒度越细并发越好但死锁与开销上升；乐观锁用版本号或条件更新，适合冲突概率低、临界区短的场景，失败要能重试且业务可接受。二者不是替代关系，工程上常是乐观锁为主、关键路径用悲观锁兜底，最外层再叠一层唯一约束或幂等键——约束是数据库层面的最终防线，锁只是降低冲突概率。

40 万条客户数据、十来个内部操作人、两三人并发查询、每天一次批量更新的场景，第一反应应该是「不要过度设计」。存储直接上 MySQL 单库足够，40 万行对 InnoDB 是很小的量级；索引按真实查询条件建，客户唯一标识建唯一索引，常用的筛选与时间维度建联合索引并遵守最左前缀；批量更新走「导入影子表 + 校验 + 原子改名/切换」或分批 upsert，避免一次大事务长时间持锁和产生巨大 undo。并发控制上，读多写少且是内部人员操作，优先用乐观锁（版本号）而不是长事务，批量更新期间可以用「更新开关」让写请求排队或提示稍后重试。Redis 缓存做读缓存即可，键按查询维度设计，设置随机 TTL 防雪崩；缓存一致性用 Cache-Aside（读未命中回填、写先改库再删缓存），批量更新完成后主动删除受影响范围的缓存键，并配一个延迟双删或版本号前缀（把版本拼进 key，切换版本即整体失效）来兜住更新窗口。最后要有对账与监控：比对缓存与库的关键字段、给不一致率和不命中率设告警，比反复争论用哪种更新策略更管用。