有一种看似勤奋的做法：每次用户提问都把整个仓库读一遍，然后把所有文件内容塞给模型。
这就像把整座图书馆搬进会议室，只为了回答“《红楼梦》在哪一排”。信息很多，但答案更难找。
3.1 当前系统的选择：索引做地图，工具取证据
LoopAgent 初始化WorkspaceIntelligence，并创建browseSymbols、exploreCode等只读工具。它们的职责不同：
browseSymbols先用概念或部分名称发现真实符号；exploreCode在符号已知后，沿当前生产入口、调用关系和相关源码继续探索；readFile获取最终需要核对的原文；applyEdit和runCommand只在证据足够且任务允许时执行。
索引因此更像地图，不是目的地。地图告诉模型“可能从哪里走”，工具再把门牌号和房间里的实际内容带回来。
3.2 为什么信息密度比信息总量重要
假设仓库有 800 个文件，用户想把calculateTax(amount)改成calculateTax(amount, rate)。全量注入会带来三个问题：
- 大量无关文本消耗上下文预算；
- 同名变量、注释和测试夹杂在一起，增加误匹配；
- 模型可能看见旧生成文件，却不知道它不是编辑目标。
更高密度的流程是：
calculateTax -> browseSymbols：找到定义与候选符号 -> exploreCode：展开定义、引用和调用链 -> readFile：核对 4 个真实调用点 -> applyEdit：只改经过确认的范围 -> runCommand：用 typecheck/test 验证遗漏这条路径的关键不是某个检索算法，而是让每次取回的信息都回答一个当前问题。
3.3 代码索引也有预算
语义索引和代码块检索仍然需要限制入口节点、片段字符数、结果数量和未解析引用。codeIntelligenceContext.ts会记录已用字符与是否截断，sqliteIndexStore.
