三条路径都答不上来的那类问题

前几篇反复演示了三路检索：

• search_graph（向量路径）：问"哪个函数负责文档分块策略"，返回QueryParam
• trace_path（图路径）：问"ainsert的完整执行链是什么"，返回 36 个节点
• search_code（符号路径）：问"哪些地方用了BaseVectorStorage"，返回 fan_in=268

但有一类问题，三条路径全都回答不了：

“这段代码为什么是这样写的？”

比如——

priority_limit_async_func_call是 LightRAG 里复杂度最高的函数之一（complexity=233，函数体长达 1360 行）。仅看当前代码，很难理解为什么一个"限制并发调用数量"的装饰器需要写这么复杂。

defpriority_limit_async_func_call(max_size:int,llm_timeout:float=None,max_execution_timeout:float=None,max_task_duration:float=None,max_queue_size:int=1000,cleanup_timeout:float=2.0,queue_name:str="limit_async"