代码智能体处理持续演化的仓库时，往往要反复搜索文件、定位符号并保留任务上下文。现有的文本索引、语言服务器和单次任务历史彼此分离，不仅造成重复发现，也让索引构建、更新和请求延迟等生命周期成本难以统一衡量。CodeNib试图把这些能力收束为一个仓库上下文运行时。
按提交构建三类可复用视图
CodeNib为每个仓库提交构建词法、稠密向量和结构视图，并把检索结果统一映射为仓库相对路径中的源码范围。运行时可据此提供排序搜索、符号导航和有长度边界的上下文，同时在代码编辑后维护选定视图，而不是让智能体每次从头发现仓库结构。
这种设计的重点不是增加一种检索器，而是统一不同检索方式的输出坐标与生命周期。论文强调“按操作划分的有效性边界”：某个视图在一次编辑后是否仍然可用，需要根据具体操作判断，不能简单假定所有索引始终同步，也不能把局部更新等同于完整重建。
更新、导航与令牌成本
研究在100个仓库快照上比较质量与成本边界。当增量更新结果与独立重建一致时，图视图和向量视图更新的中位速度分别快8.7倍和25.4倍。该条件很重要：数字描述的是输出匹配时的更新收益，并非所有编辑场景下都能稳定获得同等加速。
在1,000次请求中，静态导航结果有63%能够匹配归一化后的在线语言服务器位置；仅在这一匹配子集上，在线与静态方案的单请求延迟中位比为4.7倍。另一个实验覆盖五个模型，选定的上下文策略在保持定位能力的同时，相比配对的grep/read流程减少50%至87%的轨迹令牌。结果表明，仓库级上下文复用可以同时影响工具调用延迟和智能体轨迹长度。
我的判断
CodeNib的价值在于把仓库上下文从任务内临时产物变成可维护、可复用的基础设施，并把一致性条件显式纳入性能结论。它更适合反复处理同一仓库、需要搜索与符号导航的代码智能体系统。不过，静态导航结论只覆盖63%的匹配请求，增量加速也以结果等同独立重建为前提；摘要没有说明其对复杂编辑、更多语言或长期运行负载的表现。因此，它更像一套值得验证的上下文服务架构，而不是已经可以全面替代语言服务器和传统工具链的结论。