在工程规模越来越大、语言栈越来越混合的今天，“定位一个线上报错”往往不是缺少信息，而是信息太碎：日志在各处、调用链跨服务、依赖版本在构建系统里绕了好几层，最后结论还常常停留在“我觉得可能是……”。
RootSeeker 的目标很直接：把错误分析从“经验推断”变成“证据驱动”的可执行流程。它以 IDE/Agent 的工作方式为参考，把分析拆成清晰的阶段（Plan → Act → Synthesize → Check），每一步都能说明为什么这么做、用了什么证据、哪里发生了降级、下一步还缺什么信息。你得到的不只是结论，而是一条可复现的定位路径。
你会遇到的典型痛点，RootSeeker 正面解决
- 同一个错误，换个人排查结论就不一样 ：缺少统一的分析步骤与证据约束，结果不可复核。
- 依赖冲突问题最难“落地到源码” ：ClassNotFound / NoSuchMethodError 往往要追到具体依赖版本与方法签名，靠猜很容易翻车。
- 上下文太大，AI 容易跑偏 ：一次性塞满日志/代码/配置，反而降低命中率。
RootSeeker 的核心能力
- 外部依赖识别（v3.0.0 重点） 不仅“读构建文件当证据”，而是输出结构化依赖画像：声明依赖、变量/版本区间风险、必要时再进行解析后依赖树的对比，直接回答“声明与解析结果是否漂移、版本是否冲突、风险点在哪”。
- 依赖库代码定位（Headless LSP，v3.0.0 重点） 当问题落在依赖库上，RootSeeker 引入无 UI 的语义能力（Java JDT LS / Python Pyright 或 pylsp），像 IDE 一样提供：符号搜索、跳转定义、找引用、hover 信息。LSP 不可用时再回退到依赖源码（sources.jar / site-packages）索引定位，减少“只能猜版本差异”的盲区。
- 分层上下文管理（参考 Cursor/Trae/Cline） 默认只注入目标与证据（GoalContext + EvidenceContext），代码片段按需懒加载（CodeContext），并在每轮把工具结果按相关性重排，避免上下文污染，让定位更稳、更准。
- 可控工具执行与安全边界（MCP） 依赖分析命令按白名单映射执行，不允许自由拼接与注入，并明确超时、降级与错误码。该跑动态解析时才跑，不确定就先静态解析并说明缺口，减少不必要的副作用。
- 可观测降级：把“结果变差”变成“可诊断” 解析失败、扫描上限触发、截断发生、工具超时……都不会静默吞掉，而是形成结构化信号输出，告诉你“哪里退化了、结论可信度如何、还需要补什么证据”。
