一次结果为零的实验——痛点：工具返回空却不知是否正常

在对 LightRAG 和 graphrag 两个项目运行 cross-repo-intelligence 时得到的输出几乎全是空值：

status: success
cross_http_calls:
cross_async_calls:
cross_channel:
cross_grpc_calls:
total_cross_edges:
elapsed_ms:

为什么会出现“没有跨库边”？ 很多人第一反应是“工具出错了”。其实这正是正确且有价值的答案——两个程序之间根本不存在集成关系。

主要解释

• 功能相似不等于集成： LightRAG 与 graphrag 都是基于图的 RAG 框架。但它们是平行替代品，没有相互调用的代码。
• cross-repo-intelligence 寻找的是「集成关系」而非「功能相似性」： 没有匹配的路由/调用节点。就会返回零边，这说明「没有跨库调用」而不是分析失败。

单库分析 vs 跨库分析——痛点对比：单库只能看见局部地图

单库分析能回答的问题

• "这个函数在哪里"
• "它被谁调用"
• "它调用了什么"
• "哪些文件经常一起改动"

这些查询依赖完整的调用图，能够从任意节点进行 BFS。

跨库场景下单库分析的痛点：

• "服务 A 调用了服务 B 的哪些接口？"
• "修改服务 B 的 /query 接口，会影响哪些上游服务？"
• "消息队列中的格式变更，哪些使用者感知到？"
• "整个微服务网络里谁是中心节点，谁是孤岛？"

这些问题横跨仓库边界。单库的调用图在服务边界处戛只是止，形成大量悬空终节点——看起来像调用了外部 URL，却不知道对应的实现方。

跨库边是怎么被发现的——痛点：缺少自动匹配机制导致手工追踪成本高

cross-repo-intelligence 的主要原因是把已索引项目里的 Route 节点和 HTTP_CALLS 节点做跨库匹配。

发现步骤

1. 发现「服务端路由」：扫描所有项目。收集 Route 类型节点，生成 {path → 项目} 路由表。
2. 发现「客户端调用」：扫描 HTTP_CALLS 边，提取代码中的 URL 或方法模式。
3. 方法匹配：将每条 HTTP_CALLS 与其他项目的路由表比对。匹配成功则创建 CROSS_HTTP_CALLS 边，实现跨仓库连接。

一样的思路也适用于异步消息、gRPC、WebSocket 等其他通信方式：

• CROSS_ASYNC_CALLS: Kafka topic、RabbitMQ exchange 等。
• CROSS_GRPC_CALLS: gRPC service/method 名称。
• CROSS_CHANNEL: Redis pub/sub、WebSocket 频道等。

实际看两个程序的路由面貌——痛点：难以快速定位程序角色

LightRAG：REST API 服务端

Route 节点：
GET /query
POST /query
GET /query/stream
POST /query/stream
GET /health
POST /login
GET /auth-status
GET /graph/label/list
POST /documents/paginated
...

Lightrag 暴露完整的 HTTP 接口，是一个被调用方**。如果其他服务向其发起请求，该请求就会成为跨库边的一端。

graphrag：LLM 客户端

Route 节点：
PATCH /
从外部调用来看，https://litellm.ai
说到外部调用。https://raw.githubusercontent.com/...cspell.schema.json
...

Graphrag 并不提供自己的 REST API，而是通过 HTTP 客户端访问外部 LLM 服务和 GitHub。它在跨库视角下属于*纯粹的调用方**。即使与 LightRAG 同时部署，也只会产生对外部服务的跨库边。而不会与 LightRAG 建立连接。

跨库分析在真实工程中的价值——痛点：缺乏全局依赖视图导致改动风险不可控

典型微服务架构示例

前端 App
└─ CROSS_HTTP_CALLS → API Gateway
└─ CROSS_HTTP_CALLS → User Service
└─ CROSS_HTTP_CALLS → Auth Service
└─ CROSS_HTTP_CALLS → Order Service
└─ CROSS_ASYNC_CALLS → Kafka topic: order.created
└─ CROSS_ASYNC_CALLS → Notification Service

If User Service GET /users/{id}` endpoint changes,cross‑repo analysis instantly tells you which upstream services call it,enabling safe refactoring.

CROSS_SERVICE  模式下追踪完整链路

trace_path(
function_name="get_user_by_id",project="user-service",mode="cross_service"。depth=5
)
# 输出：从前端 handler -> API Gateway -> User Service -> DB 查询 的完整方法

三个实用场景 —— 痛点：手工 grep、文档不全、影响评估盲区

1. 服务依赖图

MATCH -->
RETURN a.file_path,r.path,b.file_path

The query yields a complete service dependency graph: identify hubs,islands,and circular dependencies with a single statement.

2. 接口变更影响评估

# 找到接口定义
search_code
# 找到所有使用该接口的上游服务
trace_path

This replaces tedious “grep across all repos” process and guarantees no caller is missed.

3. 消息契约追踪

MATCH -->
WHERE r.channel = "order.completed"
RETURN producer.filepath,consumer.filepath