一次结果为零的实验

对 LightRAG 和 graphrag 两个项目运行 cross-repo-intelligence：

index_repository(repo_path="/path/to/LightRAG",mode="cross-repo-intelligence",target_projects=["mnt-hdd-...-graphrag"])

输出：

status: successcross_http_calls: 0cross_async_calls: 0cross_channel: 0cross_grpc_calls: 0total_cross_edges: 0elapsed_ms: 109

0 条跨库边。

第一反应可能是“工具没找到东西，分析失败了”。

但这个结论是错的。这个结果是完全正确的，而且非常有信息量。

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 节点做跨库匹配。

具体来说：

1. 发现“服务端路由”：扫描所有项目，找 Route 类型的节点，即 HTTP endpoint 定义，建立 path → 项目 的路由表。

2. 发现“客户端调用”：扫描 HTTP_CALLS 边，即代码里的 HTTP 请求，提取被调用的 URL 或路径模式。

3. 路径匹配：对每条 HTTP_CALLS，尝试在其他项目的路由表里找到匹配的 Route。找到了，就创建一条 CROSS_HTTP_CALLS 边，跨越仓库边界连接调用方和被调用方。

除了 HTTP，同样的逻辑也适用于：

• CROSS_ASYNC_CALLS：消息队列（Kafka topic 名、RabbitMQ exchange 等）
• CROSS_GRPC_CALLS：gRPC service/method 名
• CROSS_CHANNEL：其他命名通道（WebSocket 频道、Redis pub/sub key）

这就解释了为什么 LightRAG × graphrag 返回 0。

LightRAG 里没有任何代码向 graphrag 的路由发起 HTTP 请求，graphrag 也没有调用 LightRAG 的 API。

工具没有失败，它正确地报告了“这两个系统之间没有集成关系”。

实际看两个系统的路由面貌

即使没有跨库边，看两个系统各自的路由定义，也能快速理解它们的角色。

LightRAG：REST API 服务端

Route 节点（lightrag/api/routers/）：GET/queryPOST /queryGET/query/streamPOST /query/streamGET/healthPOST /loginGET/auth-statusGET/graph/label/listPOST /documents/paginated...

LightRAG 暴露了完整的 HTTP 服务端接口。

文档管理、查询、图浏览、健康检查一应俱全。

从跨库分析的视角看，它是一个被调用方。

如果你在另一个服务里向 http://lightrag-host/query 发请求，那条请求就会成为跨库边的一端。

对应的代码结构：create_query_routes 是 1566 行的路由注册函数，复杂度 118、认知复杂度 266。

这是整个项目里最难的函数之一，因为它需要处理所有 HTTP 层面的边界情况。

graphrag：LLM 客户端

需要厘清的是，Route 节点（位于 graphrag/ 目录下）涉及的外部调用指向 https://litellm.ai 以及 GitHub 上的 cspell.schema.json 文件。

核心在于，graphrag 本质上并非一项持续运行的服务，而是一个集命令行工具与 Python SDK 于一体的应用。

其所谓的“路由”，实则是向外部 LLM 服务（如 LiteLLM）和 GitHub 发起的 HTTP 请求，而非自身暴露的 API 端点。

从跨库分析的视角审视，它扮演的是纯粹的调用方角色。

例如，若在统一系统内同时部署 graphrag 与 LightRAG，分析结果会显示：graphrag 可能通过 LiteLLM 发起跨库 HTTP 调用（CROSS_HTTP_CALLS），但两者之间不存在直接的相互调用关系——graphrag 不调用 LightRAG，LightRAG 亦不调用 graphrag。

这个角色差异，从代码层面一眼可辨。

一个有真正的 REST API 路由，一个只有对外的 HTTP 客户端调用。

跨库分析在实际工程里的价值

既然 LightRAG × graphrag 没有跨库边，什么样的系统才有？

典型的微服务架构。

在这样一套架构下，假设 User Service 的 GET /users/{id} 接口发生变动，例如返回字段调整。

跨库分析能精准定位到哪些服务通过 CROSS_HTTP_CALLS 依赖了该接口，并提示它们需同步更新。

这种全局视角，是单纯依靠单库分析永远无法实现的。

cross_service 模式的 trace_path：

trace_path(function_name="get_user_by_id",project="user-service",mode="cross_service",depth=3)

这个调用会沿着 HTTP_CALLS → CROSS_HTTP_CALLS → Route 边界穿越。

它会找出所有跨服务的调用链。

可以从某个前端 handler 一路追到 User Service 的数据库查询。

跨库分析的三个实用场景

场景 1：服务依赖图

把所有微服务项目索引后，用 Cypher 查出跨库调用关系：

MATCH (a)-[r:CROSS_HTTP_CALLS]->(b)RETURN a.file_path, r.path, b.file_path

结果就是整个系统的服务依赖图。

• 哪些服务是“枢纽”：被多个服务调用
• 哪些是“孤岛”：没有跨库调用
• 哪些存在循环依赖

一条查询全都看到。

场景 2：接口变更影响评估

# 1. 找接口定义search_code("GET /api/v2/payments", project="payment-service")# 2. 找跨库调用方trace_path("get_payment", mode="cross_service", direction="inbound")→ 返回所有通过 CROSS_HTTP_CALLS 调用这个接口的上游服务

修改 /api/v2/payments 之前，先知道有哪些服务依赖它。

这个操作在没有跨库分析的情况下，需要在全组所有仓库里手动 grep 这个 URL。

而手动方式往往有遗漏。

场景 3：消息契约追踪

如果服务间通过 Kafka 通信：

MATCH (producer)-[r:CROSS_ASYNC_CALLS]->(consumer)WHERE r.channel = "order.completed"RETURN producer.file_path, consumer.file_path

找到 order.completed 这条消息的所有生产者和消费者。

消息 schema 要变更时，影响面一览无余。

没有跨库边的也有价值：相似性对比

回到 LightRAG 和 graphrag 这对没有跨库边的例子。

虽然跨库分析没有发现集成关系，但同时持有两个项目的索引，仍然可以做一件有价值的事：接口设计对比。

查 LightRAG 的查询接口：

# LightRAGasync def aquery(self, query: str, param: QueryParam) -> str

查 graphrag 的查询接口：

# graphragasync def local_search(config: GraphRagConfig,entities: pd.DataFrame,communities: pd.DataFrame,community_reports: pd.DataFrame,text_units: pd.DataFrame,relationships: pd.DataFrame,covariates: pd.DataFrame | None,community_level: int,response_type: str,query: str,) -> tuple[str | dict, str | list[pd.DataFrame] | dict[str, pd.DataFrame]]

两个做同类事情的框架，接口设计差异极大。

• LightRAG 把所有配置封装进 QueryParam（面向服务运行时）
• graphrag 要求调用方自己管理所有 DataFrame（面向批处理分析管道）

这两个接口设计哲学，反映了两个项目完全不同的使用场景定位。

这种跨项目接口对比，是技术选型调研时最有价值的视角之一。

而它恰好是跨库知识库的副产品。

不需要跨库边，只需要两个项目的索引同时存在。

总结

跨库分析不是“让单库分析变得更大”，而是解决了一类全新的问题：服务边界处的知识连接。

三条核心结论：

1. 0 条跨库边是有意义的答案。它说明两个系统之间没有集成关系，而不是分析失败。不要把“工具找到东西”和“工具工作正常”混同。

2. 跨库分析的核心是路由匹配。把一个服务暴露的 Route 节点，和另一个服务发出的 HTTP_CALLS / ASYNC_CALLS 节点做路径匹配——这是它能发现的，也只有这个它能发现的。功能相似性、代码风格对比、重复逻辑检测，都是别的工具的事。

3. 没有跨库边的项目对，同样可以做接口对比。跨库知识库让你同时查询多个项目，即使它们之间没有调用关系，并列的索引本身就有分析价值。

下一篇，我们把视角转向知识库的评测。

如何知道你的知识库“够不够好”？用什么指标衡量，怎么设计评测数据集，以及当 Recall@5 不再是唯一关注指标时，生产系统应该追踪什么。

欢迎访问 PrimeSkills —— 一个精心策划的 AI Agent 与技能市场，所有内容均经过真实企业级工作流验证。没有噱头，只有真正有效的东西。

更多实用知识和有趣产品，欢迎访问我的个人主页