一次结果为零的实验对 LightRAG 和 graphrag 两个项目运行cross-repo-intelligence：index_repository(repo_path="/path/to/LightRAG",mode="cross-repo-intelligence",target_projects=["mnt-hdd-...-graphrag"])输出：status: success cross_http_calls: 0 cross_async_calls: 0 cross_channel: 0 cross_grpc_calls: 0 total_cross_edges: 0 elapsed_ms: 1090 条跨库边。第一反应可能是"工具没找到东西，分析失败了"。但这个结论是错的。这个结果是完全正确的，而且非常有信息量。LightRAG 和 graphrag 是两个功能相近的开源框架——都在做基于图的 RAG——但它们是平行替代品，不是相互调用的集成系统。没有任何 LightRAG 的代码调用 graphrag 的 API，反过来也一样。cross-repo-intelligence找的是集成关系，不是功能相似性。两者之间本来就没有集成关系，返回 0 才是正确答案。这个结果之所以重要，是因为它划清了一条边界：跨库分析解决的问题，和单库分析完全不同。单库分析 vs 跨库分析：两个不同的问题回顾前十篇，单库知识库能回答的问题都在同一个仓库边界内：“这个函数在哪里”（符号路径）“它被谁调用”（图路径 inbound）“它调用了什么”（图路径 outbound）“哪些函数和它经常一起改动”（FILE_CHANGES_WITH）这些问题的答案都在同一个代码库里，调用图是完整的，可以从任意节点出发做 BFS。但当系统边界扩展到多个仓库时，出现了一类单库分析物理上无法回答的问题：“服务 A 调用了服务 B 的哪些接口？”“如果我修改了服务 B 的/query接口，哪些上游服务会受影响？”“服务 C 通过消息队列发给服务 D 的消息格式变了，D 能感知到吗？”“整个微服务网络里，谁是中心节点，谁是孤岛？”这些问题的答案横跨仓库边界。单库的调用图在服务边界处戛然而止，成了一张"有很多悬空终节点"的残缺地图——看起来像调用了某个外部 URL，但不知道那个 URL 是谁处理的。cross-repo-intelligence的工作，就是把这些悬空的终节点连起来。跨库边是怎么被发现的cross-repo-intelligence模式的核心逻辑是：把已索引项目里的 Route 节点和 HTTP_CALLS 节点做跨库匹配。具体来说：发现"服务端路由"：扫描所有项目，找Route类型的节点（即 HTTP endpoint 定义），建立path → 项目的路由表。发现"客户端调用"：扫描HTTP_CALLS边（即代码里的 HTTP 请求），提取被调用的 URL 或路径模式。
