Agent 如何在大型代码库中定位业务、模块和相关代码？

大型代码库定位应从业务入口逐步收窄到模块、符号和调用链，再用真实代码与运行证据确认。把全仓库塞进上下文、只靠向量相似度找几个文件，都容易漏掉配置、动态调用和跨模块约束。

先把用户描述转换成项目里的路由、页面、错误码、表名或领域术语；结合目录说明和代码搜索找到入口。随后用符号定义、引用关系和依赖图扩展相关代码，读取完整函数及必要的调用方、测试和配置。最后沿一个具体请求验证“输入从哪里进入、在哪处理、状态写到哪里、结果如何返回”，形成可回查的文件与行号证据。

精确符号、报错和配置键优先使用关键词检索；“购物车价格为什么不同”这类业务表达，可以用语义检索找到候选模块，再追踪实际调用。AST/LSP适合查定义和引用，代码图适合补依赖，README和模块说明负责解释业务边界，几种线索各有分工。

索引按函数或类保存签名、路径及版本信息，比固定长度切碎代码更容易保留语义。代码变更后只更新受影响文件与符号，删除旧条目；检索结果携带commit或内容哈希，读取时确认对应当前工作区。动态加载、反射、生成代码和跨服务调用还要结合注册配置、接口契约与日志，静态图不能包办全部关系。

Aider的Repository Map就是一种可参考的做法：先提供关键符号与签名，再根据依赖关系和上下文预算选择相关部分；它帮助导航，仍需读取实际实现。

假设问题是“订单退款后优惠券未退回”。先从退款事件处理器追到优惠券服务，再检查事件订阅、重试分支和对应测试。只找到退款页面组件，说明业务入口或跨服务关系没召回；正确函数已进入上下文却仍判断错误，则要检查上下文噪声、遗漏条件及模型理解。

评估可以准备带真实相关文件和符号的任务，分别看候选召回率、排序、定位后解释是否正确，以及多读了多少无关内容。把“没找到”“找到了没理解”“理解了但改错”分开，才能决定该改索引、检索、上下文组装还是执行验证。

需要一开始建立完整知识图谱吗？ 不一定。先用目录地图、关键词和符号导航建立可用基线；跨模块关系确实成为主要瓶颈时，再补图索引。索引建设成本和更新延迟也需要计入取舍。

参考答案