Agent 怎么处理代码库数据?

这道题其实是在问：当[[Agent]]面对的不再是几段零散代码，而是一个完整的、有复杂依赖关系的代码库时，怎么让它像资深工程师一样理解、定位和修改代码。这跟通用[[RAG]]最大的区别在于，代码的结构化语义太强了，函数间的调用关系、继承关系、跨文件引用，光靠向量检索是搞不定的。

我的核心思路是，先把代码库拆成多粒度的表征，再配合一套分层检索架构。具体说一下，文件级我用代码摘要做[[Embedding]]，用来粗筛相关模块；函数和类级别，我会用AST解析出签名和调用关系，配合Embedding做精确定位；行级就是原始代码加行号，用来精准定位Bug。还有一个关系级，用代码图把调用图、继承图存下来，这是理解依赖的关键。

检索的时候，我会先做文件级粗筛，拿到Top-K个相关文件，再对每个文件里的函数做精排，然后根据调用图自动扩展依赖，把上下游代码拉进来，最后组装上下文。这里有个坑，只看一个函数往往看不懂，所以依赖扩展是必须的。但扩展多了上下文又容易爆，我一般按调用深度排序，核心代码保留原文，非核心的用摘要代替。

上下文管理上，我会做显式位置编码，把文件路径、模块结构一起编码进去，让模型知道代码的物理位置。然后[[滑动窗口]]加关键节点锚定，入口函数和关键API永远保留，中间过程可以折叠。已经分析过的模块直接缓存摘要，避免重复解析。

工具链方面，我会集成静态分析和动态执行。静态分析用LSP查符号定义，遇到未定义标识符就自动跳转；动态执行用沙箱跑单元测试，生成代码后验证正确性。版本对比用Git diff，需求涉及修改现有代码时自动分析变更影响。

写入端我接Git webhook，触发增量索引更新，只解析变更的文件，AST没变就不重建。查询端在[[ReAct]]循环里嵌几个代码专用Action：search_code做语义检索，jump_to_def做符号跳转，run_test做执行验证。

不过我觉得，最关键的取舍在于预计算索引和实时解析的平衡。预计算索引延迟低，但遇到新代码或动态语言反射调用时可能不准；实时解析准确，但慢。我倾向于对低频查询走实时解析，高频路径走预计算缓存，再配合后台异步刷新。但这个问题还没完全解决，比如TypeScript的类型推断在预计算时怎么处理，我觉得还有优化空间。

所以我会把代码库Agent看成一套分层系统，每一层解决一个问题，而不是一个模型搞定所有。前提是你得有好的AST解析器和准确的调用图，不然检索质量会崩。常见失败场景是依赖扩展时拉入太多无关代码，导致上下文噪声过大。上线我会特别关注上下文命中率和依赖扩展的精度，如果召回率低，先看是不是Embedding模型没训好，再查依赖图是不是漏了边。