每个做过线上服务的人都熟悉这种时刻：告警响起，日志里同时出现十几种异常，群里在问“谁改了什么”，而你只能从堆栈与零散的上下文里一点点拼图。问题不在于我们不懂排查，而在于排查这件事长期依赖三样东西： 经验、运气、和熟悉代码的人 。
RootSeeker（root_seek）想做的事很直接——把排障从“手工拼图”变成“证据驱动的定位流程”，让每一次线上错误都能更快沉淀为： 发生了什么、为什么发生、关联到哪里、该怎么修 。
为什么要做 RootSeeker？
排障慢，往往不是因为人不努力，而是因为信息分散：
- 日志在日志平台，代码在仓库 ：你需要在多个系统之间来回跳转。
- 堆栈能指出点，但未必指出“因” ：真正的根因常在更上游的条件、配置或数据路径里。
- 重复问题太多 ：同类错误反复出现，但经验难以结构化沉淀。
- 定位高度依赖“熟人” ：谁熟悉哪个模块，决定了问题解决速度。 RootSeeker 的设计目标就是把这些分散信息收拢到一条链路中： 日志接入 → 证据检索 → 推理归因 → 输出建议 ，形成可以持续运行的内网服务，而不是一次性脚本或纯聊天式工具。
RootSeeker 怎么做：把“证据”放到推理之前
很多“AI 排障”失败的原因并不是模型不够聪明，而是输入不够可靠。RootSeeker 的思路是：先把可验证的信息准备好，再让模型基于证据做判断。
1) 日志接入：从生产环境自然进入分析链路
RootSeeker 支持通用的日志接入方式，也支持阿里云 SLS webhook 等形式。你不需要把异常复制粘贴到各种工具里，日志可以直接进入系统，成为一次“分析任务”的起点。
2) 代码证据：精确检索 + 语义检索的组合拳
RootSeeker 同时使用两类检索来“找对代码”：
- Zoekt：精确代码检索 擅长快速命中堆栈、符号名、关键字、路径等，尤其适合大规模代码库的“快定位”。
- Qdrant：语义向量检索 当日志描述和代码实现不完全同词时，语义检索可以把“描述的问题”映射到“可能相关的实现与模块”，补齐精确检索找不到的上下文。 这套组合意味着：你既能得到“命中的那几行”，也能得到“真正相关的那一片”。
3) 推理输出：把结论写给工程师，而不是写给模型
RootSeeker 最终输出面向工程师的结果，强调三件事：
- 结论 ：最可能的根因是什么；
- 依据 ：这不是拍脑袋，证据来自哪些日志片段、哪些代码位置；
- 建议 ：如何验证、如何修复、可能影响面在哪里。 换句话说，它追求的是“能落地的下一步动作”。
它不仅是服务，更是团队化的工作台
RootSeeker 同时提供管理端（基于 RuoYi 二次开发的 Admin），用于团队化治理：
- 统一管理 Git 仓库与凭证（多平台接入）
- 统一管理 AI 相关配置（LLM / Embedding / 向量库）
- 配置变更后可通知分析服务刷新 catalog 当你把它部署在团队内网里，它更像是一套“排障基础设施”：可持续、可配置、可协同。
一分钟理解它的价值（用一句话）
RootSeeker 的价值不在于“它能回答问题”，而在于它能把“线上错误”快速变成一份结构化的排障报告： 带证据、能验证、可修复 。
适合谁用？
- 线上告警密集、错误重复出现的团队
- 微服务复杂、链路长、定位成本高的系统
- 希望降低 MTTR、把排障知识沉淀为资产的组织
- 对“检索 + LLM 工程化落地”感兴趣的研发与平台团队
开始关注 RootSeeker：从一次错误开始
你可以从最简单的方式体验它：把一次真实的异常日志接入进来，看看系统如何把日志与代码串起来，给出可验证的根因线索与建议。 当它能在你最痛的那类错误上帮上忙，你就会明白：排障这件事是可以被工程化的。
