AI 全栈工程师（Agent 应用）一面面经

一、考得深、答得还好的问题

1. 描述一条从告警到闭环的完整链路（以网元断连为例）

参考框架：告警经 MQ 订阅进入 → 取告警元数据 → 先查知识库定"可能原因方向" → 再按方向决定调哪个工具（捞服务日志 / ping / 查通道）→ ReAct 循环收敛 → 输出结论 + 修复命令 + 参考文档链接 → HITL 人工复核（通信领域操作严格，归因必复核）→ 一键执行修复。

2. 单次告警日志可能上千条 / 10-20MB，怎么喂给 LLM？

参考框架（三层瘦身）：① 裁剪：按时间窗口、日志级别（error、warn、failed）过滤；按关键词屏蔽（health、heartbeat等定时任务日志不采集）② 去重：将大量重复的日志合并；③ 压缩：如果日志量仍然很大，触发摘要压缩，但仍保存完整日志，发给大模型，允许大模型定方向初步分析后，再使用grep命令读取日志中的关键信息。

3. Skill 里哪些是固定、哪些随观察动态调整？

参考框架：元数据、输入输出的锲约、基础提示词和工具调用地址是固定的，这些是skill的基础；动态变化的是实例化的参数，每轮请求都有不同；动态的指令、或者情景提示词，这是skill自演进的基础，通过总结经验，再遇到相似场景时自动注入；执行的路径不同，skill中存在很多条件流程，这些是根据情景动态使用的。

4. 混合检索为什么 BM25 + 向量 + RRF？怎么加权？

参考框架：领域术语（通信黑话）关键词命中率高、语义向量反而没有优势 → BM25 靠词频检索；用户不懂术语、模糊提问 → 走向量相似度检索。两条路都走，最终由RRF 融合排序。如果想要更优质的检索效果，演进方向可以是，"按 query 类型/场景动态调BM25跟向量检索的权重"。

5. 会话三层存储（记忆模块）

参考框架：zustand 内存态保证 UI 连续渲染（SSE 流式进来先刷内存）→ 浏览器两层缓存（IndexedDB 存多会话、SessionStorage 存当前会话快照，分别覆盖刷新/关页签重开）→ SQLite 落盘（重登/跨端拉历史）。

二、答得空、被追到哑口的问题

6. RAG的案例库防污染：遇到网络问题拔网线插一下好了，但根因是网络波动——这种"假案例"怎么拦住？

我当时答"没考虑到"，面试官明显失望。

参考答法：事前严控入库： 1）案例库沉淀强制填结构化模板（现象、根因证据、处置方式、验证方法），只有经过诊断闭环和根因确认的过程才能入库，否则不予入库。2）案例带置信度，无法证明“该操作是命中根因并支撑告警消除”的案例，记为临时规避，标注低置信度。3）案例进行严格的管理员人工审核。

事中全量清洗： 1）语义级冲突检测，入库前需要检测新旧知识的矛盾，当新案例与已有知识发生冲突时，需要人工介入审核；2）数据清洗与去重：通过拼写错误、大小写统一等基本文本校验，近似语义去重等手段清洗入库数据；3）防范注入攻击：在处理过程中检测是否存在恶意注入指令，防范数据本身作为指令被执行。

事后持续治理： 案例要带置信度，推荐操作被运维人员点击“不对”就要降权或者下线，避免垃圾越堆越多；案例也有版本标签，针对个别版本的案例，在产品升级后置为 inactive 失效状态。

7. 不靠大量人力 review，怎么保证进库知识又准又高效？

我当时只说了"评测体系+人工抽检"，追问防护细节就空了。参考答法（两层自动 + 一层抽样）：

自动化的入库预检：LLM 当第一道闸——查信息完整性、可执行性、是否与存量冲突、根因证据是否充分，明显异常自动拦截；

入库时自动化去重合并：相似度达到一定阈值，合并重复案例；

上线后反馈闭环：用"命中该案例后的问题解决率/采纳率"当质量信号，自动下线低效案例；案例通过版本标签管理，及时清理失效案例与知识。

8. 从对话 session 里沉淀"真正有价值的知识"，而不是"改字号/美化"这类操作噪声？

我当时只提了"压缩时触发提取，类似cc的通过focus on来针对性提取"，没有答到核心。

参考答法：我不会每轮都让 LLM 去判断"这轮是不是偏好"，那样又贵又不稳定。我的做法是每轮先过一道 免费的规则闸门——用一批信号词（"记住/以后/我不喜欢/纠正句"）扫一遍，90% 的干活指令直接放行，零成本。只有命中了才花 token 去精确提取成一条独立偏好再落库。我还把 remember 暴露成一个工具给主 LLM，它觉得遇到没明说的隐式偏好时可以主动调。两条通道写同一个记忆库，都先查重再写。所以"改字号"这种干活指令，既过不了闸门，agent 也不会主动记它。

如果说的是在摘要过程中提取关键信息：不是靠一句"提取关键信息"的提示词，而是给它立了规矩。第一，定义好保留清单和丢弃清单：进度结论、决策及原因、数字、未决问题要留；操作流水、试错过程、格式化指令不要留。第二，用增量摘要——上一次的摘要加新对话去更新，避免摘要器只记得结尾、丢了早期重要决定。第三，Map-Reduce 分块摘要前每块垫一行任务背景，防止脱离上下文误判；最后让 llm 按字段输出而不是流水账，丢了什么能看出来。真正需要长期记住的偏好，早就被长期记忆写入收走了，不会流到摘要这里。