基于CodeGraph的LLM代码分析：Token消耗优化策略与实践

在大型语言模型（LLM）应用开发中，尤其是在处理复杂代码库分析、智能代码补全或生成任务时，Token消耗是一个绕不开的核心成本与性能瓶颈。无论是调用OpenAI API、Claude API还是部署本地模型，每一次请求的Token数量都直接关系到响应速度、费用开销以及模型处理复杂问题的能力上限。当我们需要分析一个庞大的项目源码时，简单的文件拼接和发送很快就会触及模型的上下文窗口限制，导致分析不完整或请求被拒绝。

CodeGraph（代码图）技术正是应对这一挑战的利器。它通过将源代码抽象为结构化的图数据（如抽象语法树AST、控制流图CFG、数据流图DFG、调用关系等），使得LLM能够以更高阶、更紧凑的“理解”而非“背诵”的方式来处理代码。然而，如何构建一个高效的CodeGraph，并基于此设计出真正能大幅降低Token消耗、提升分析深度的增强策略，是当前开发者面临的实际难题。

本文将围绕“Token消耗优化”这一核心目标，深入探讨如何利用和增强CodeGraph分析能力。我们将从概念入手，逐步拆解CodeGraph的构建方法，并重点分享几种经过实践验证的Token优化策略，包括代码语义压缩、增量式分析、分层摘要生成等。无论你是正在开发AI编程助手、代码安全审计工具，还是希望优化现有基于LLM的代码理解流水线，本文提供的思路和示例代码都能为你带来直接的参考价值。

1. 理解Token消耗与CodeGraph的核心价值

在深入技术方案之前，我们有必要厘清两个基本概念：Token消耗为何成为瓶颈，以及CodeGraph如何从根本上改变游戏规则。

1.1 Token消耗：成本与能力的双重约束

在LLM语境下，Token是文本处理的基本单位。对于英文，一个Token大约对应0.75个单词；对于中文，一个字可能对应1-2个Token。当我们向模型发送一个请求时，输入的提示词（Prompt）和模型返回的答案（Completion）共同消耗Token。

约束主要体现在三个方面：

1. 成本：绝大多数商用API按Token数量计费。输入（Input）和输出（Output）通常分开计价。分析一个大型项目意味着极高的输入Token消耗。
2. 上下文长度：每个模型都有固定的上下文窗口上限（如4K、8K、16K、32K、128K甚至更长）。即使不计成本，超过这个限制的请求也无法被处理。
3. 性能与精度：过长的输入会降低模型处理速度，并可能因信息过载导致模型忽略关键细节，影响分析结果的准确性。

例如，直接将一个包含100个文件、总计10万行代码的项目源码作为Prompt发送给一个上下文窗口为8K的模型，是根本行不通的。

1.2 CodeGraph：从“文本序列”到“知识结构”

传统方法将代码视为纯文本序列送入LLM，这种方式效率低下，因为它迫使模型重新“解析”代码结构。CodeGraph则预先完成了这一步解析工作。

一个典型的CodeGraph可以包含以下节点和边：

• 节点：包（Package）、模块（Module）、类（Class）、函数/方法（Function/Method）、变量（Variable）、字面量（Literal）等。
• 边：继承（Inherits）、实现（Implements）、包含（Contains）、调用（Calls）、被调用（Called By）、引用（References）、被引用（Referenced By）、赋值（Assigns To）等。

通过构建CodeGraph，我们可以：

• 压缩信息：用“函数A调用函数B”这条边（几个Token）替代两个函数的完整源码（可能上百个Token）。
• 精准定位：当模型需要理解某个函数的逻辑时，我们可以只提供该函数节点及其直接关联的子图（如函数体、它调用的函数签名），而非整个文件。
• 支持复杂查询：可以执行图查询，例如“找到所有未被调用的函数”、“分析从入口点到敏感API的数据流路径”，这些查询结果可以转化为极简的描述再喂给LLM。

简单来说，CodeGraph将代码的“结构知识”外化，让LLM专注于需要“推理”和“理解”的部分，从而避免了在重复解析代码结构上浪费宝贵的Token。

2. 环境准备与工具选型

要实现CodeGraph分析增强，我们需要一套工具链来解析代码、构建图数据、执行查询和与LLM交互。

2.1 核心工具与库

以下是一个基于Python的推荐工具栈，它平衡了能力与易用性：

• 编程语言：Python 3.8+
• 代码解析与AST生成：
  • tree-sitter：一个高效的增量式解析器生成工具和解析库，支持多种语言（Python, Java, JavaScript, Go, Rust等），速度快，适合构建生产级工具。
  • libcst(用于Python)：保留格式的Python源码解析器，适合需要修改代码并保持格式的场景。
  • 标准库ast(用于Python)：Python内置模块，轻量但功能强大，适合快速原型。
• 图数据库/图计算库：
  • networkx：纯Python的图论与复杂网络库，易于上手，适合中小规模代码库的分析和算法实验。
  • Neo4j(通过py2neo驱动)：专业的图数据库，适合超大规模、需要持久化存储和复杂图查询的代码库分析。
• LLM交互：
  • openai/anthropic官方SDK：用于调用商业API。
  • langchain：框架提供了与CodeGraph结合的高级抽象，如GraphIndexCreator、GraphCypherQAChain等（社区可能有相关实现或可借鉴思路）。
• 项目与依赖管理：pip,venv,requirements.txt或poetry。

2.2 项目初始化

创建一个新的项目目录并安装核心依赖。

# 创建项目目录 mkdir codegraph-token-optimizer && cd codegraph-token-optimizer # 创建虚拟环境（可选但推荐） python -m venv venv # 激活虚拟环境 # Windows: venv\Scripts\activate # Linux/Mac: source venv/bin/activate # 创建 requirements.txt 并安装依赖 cat > requirements.txt << EOF tree-sitter networkx>=2.6 openai>=1.0.0 # 或其他LLM SDK python-dotenv # 用于管理API密钥 EOF pip install -r requirements.txt # 此外，还需要下载 tree-sitter 的语言解析库（以Python为例） git clone https://github.com/tree-sitter/tree-sitter-python # 后续代码中会演示如何加载

3. 构建基础CodeGraph：从源码到图结构

我们以分析一个Python项目为例，演示如何使用tree-sitter和networkx构建一个基础的调用关系图（Call Graph）。这是最常用的一种CodeGraph。

3.1 使用Tree-sitter解析代码

首先，我们需要编写一个解析器，它能从源代码中提取出函数定义和函数调用关系。

# file: code_parser.py import os from tree_sitter import Language, Parser import networkx as nx # 加载Tree-sitter Python语言库 # 假设你已经将 tree-sitter-python 克隆到了项目根目录的 `vendor` 文件夹下 PYTHON_LANGUAGE_PATH = './vendor/tree-sitter-python' PYTHON_LANGUAGE = Language(PYTHON_LANGUAGE_PATH, 'python') class CodeGraphBuilder: def __init__(self): self.parser = Parser() self.parser.set_language(PYTHON_LANGUAGE) self.graph = nx.DiGraph() # 使用有向图 def parse_file(self, file_path): """解析单个文件，提取函数定义和调用，添加到图中""" with open(file_path, 'r', encoding='utf-8') as f: source_code = f.read() tree = self.parser.parse(bytes(source_code, 'utf-8')) root_node = tree.root_node # 获取当前文件的模块名（用于标识函数） module_name = os.path.splitext(os.path.basename(file_path))[0] # 提取所有函数定义 function_defs = self._extract_functions(root_node, source_code, module_name) # 将函数定义作为节点加入图 for func_name, func_info in function_defs.items(): node_id = f"{module_name}.{func_name}" self.graph.add_node(node_id, **func_info) # 在每个函数定义节点内，查找调用关系 for func_name, func_info in function_defs.items(): caller_id = f"{module_name}.{func_name}" calls = self._extract_calls_from_function(func_info['node'], source_code, module_name, function_defs) for callee_id in calls: # 添加一条从调用者到被调用者的边 self.graph.add_edge(caller_id, callee_id, relation='calls') def _extract_functions(self, root_node, source_code, module_name): """从AST中提取函数定义""" functions = {} query = PYTHON_LANGUAGE.query(""" (function_definition name: (identifier) @func_name parameters: (parameters) @params body: (block) @body) @func_def """) captures = query.captures(root_node) func_def_node = None for node, tag in captures: if tag == 'func_def': func_def_node = node elif tag == 'func_name' and func_def_node: func_name = source_code[node.start_byte:node.end_byte] # 获取函数体文本（用于后续可能的摘要生成） body_node = func_def_node.child_by_field_name('body') body_text = source_code[body_node.start_byte:body_node.end_byte] if body_node else "" functions[func_name] = { 'name': func_name, 'module': module_name, 'node': func_def_node, 'body_preview': body_text[:200] + '...' if len(body_text) > 200 else body_text, # 预览 'start_line': func_def_node.start_point[0] + 1, 'end_line': func_def_node.end_point[0] + 1, } func_def_node = None return functions def _extract_calls_from_function(self, func_node, source_code, module_name, local_functions): """从一个函数定义节点中提取它调用的其他函数""" calls = set() # 查询函数调用表达式 query = PYTHON_LANGUAGE.query(""" (call function: (identifier) @func_name) @call_expr """) captures = query.captures(func_node) for node, tag in captures: if tag == 'func_name': called_func_name = source_code[node.start_byte:node.end_byte] # 判断被调用函数是否在当前文件已定义 if called_func_name in local_functions: callee_id = f"{module_name}.{called_func_name}" else: # 对于外部函数，我们用一个通用标识符，实际项目中需要更复杂的解析（如导入分析） callee_id = f"external.{called_func_name}" calls.add(callee_id) return list(calls) def build_graph_from_directory(self, directory_path): """递归遍历目录，解析所有.py文件""" for root, dirs, files in os.walk(directory_path): for file in files: if file.endswith('.py'): file_path = os.path.join(root, file) print(f"Parsing: {file_path}") try: self.parse_file(file_path) except Exception as e: print(f"Error parsing {file_path}: {e}") return self.graph def get_graph_info(self): """打印图的基本信息""" print(f"Number of nodes (functions): {self.graph.number_of_nodes()}") print(f"Number of edges (calls): {self.graph.number_of_edges()}") # 可以计算入度/出度来分析函数重要性 print("\nTop 5 functions with most outgoing calls (fan-out):") out_degree = dict(self.graph.out_degree()) for node, degree in sorted(out_degree.items(), key=lambda x: x[1], reverse=True)[:5]: print(f" {node}: {degree} calls")

3.2 构建并查看图

创建一个示例项目目录和Python文件进行测试。

# file: demo_project/main.py def entry_point(): """程序入口""" data = fetch_data() processed = process_data(data) save_result(processed) def fetch_data(): return [1, 2, 3, 4, 5] def process_data(numbers): total = sum_numbers(numbers) avg = calculate_average(total, len(numbers)) return {"total": total, "average": avg} def sum_numbers(nums): return sum(nums) def calculate_average(total, count): if count == 0: return 0 return total / count def save_result(result): print(f"Result saved: {result}")

# file: demo_project/utils.py def helper_function(): print("I'm a helper.") def another_helper(): helper_function() print("Another helper done.")

现在，运行我们的解析器来构建图。

# file: build_demo_graph.py from code_parser import CodeGraphBuilder if __name__ == '__main__': builder = CodeGraphBuilder() graph = builder.build_graph_from_directory('./demo_project') builder.get_graph_info() # 可以简单可视化或导出图数据 # 1. 导出为GEXF格式，可用Gephi等工具打开 nx.write_gexf(graph, "code_graph.gexf") print("\nGraph exported to 'code_graph.gexf'") # 2. 打印某个函数的调用链 print("\nCall chain for 'demo_project.main.process_data':") if 'demo_project.main.process_data' in graph: print(" Calls:", list(graph.successors('demo_project.main.process_data'))) # 它调用了谁 print(" Called by:", list(graph.predecessors('demo_project.main.process_data'))) # 谁调用了它

运行python build_demo_graph.py，你会看到类似以下输出：

Parsing: ./demo_project/main.py Parsing: ./demo_project/utils.py Number of nodes (functions): 7 Number of edges (calls): 6 Top 5 functions with most outgoing calls (fan-out): demo_project.main.process_data: 2 calls demo_project.main.entry_point: 2 calls demo_project.utils.another_helper: 1 calls demo_project.main.save_result: 0 calls demo_project.main.fetch_data: 0 calls Graph exported to 'code_graph.gexf' Call chain for 'demo_project.main.process_data': Calls: ['demo_project.main.sum_numbers', 'demo_project.main.calculate_average'] Called by: ['demo_project.main.entry_point']

至此，我们已经成功将一个小型代码库转换为了一个结构化的调用关系图。这个图本身的数据量（节点和边的列表）远小于原始源代码的文本量。

4. Token消耗优化策略：基于CodeGraph的增强分析

拥有了CodeGraph，我们就可以设计一系列策略来优化LLM交互时的Token消耗。核心思想是：用图查询代替全文发送，用结构摘要代替代码粘贴。

4.1 策略一：语义压缩与摘要生成

当LLM需要理解一个函数时，我们不发送其完整的、可能很冗长的源代码，而是发送一个由CodeGraph生成的语义摘要。

这个摘要可以包括：

1. 函数签名：名称、参数、返回值类型（如果语言支持）。
2. 功能描述：用一句话描述该函数做什么（可以尝试用小型LLM或规则生成）。
3. 调用关系：它调用了哪些核心函数（来自图）。
4. 关键代码片段：只提取核心逻辑行（如循环、条件判断的主体），省略样板代码。

# file: graph_summarizer.py class GraphSummarizer: def __init__(self, graph): self.graph = graph def generate_function_summary(self, node_id): """为一个函数节点生成文本摘要""" if node_id not in self.graph.nodes: return f"Node {node_id} not found in graph." node_data = self.graph.nodes[node_id] summary_parts = [] # 1. 基本信息 summary_parts.append(f"Function: {node_id}") # 这里可以尝试从docstring提取描述，示例中我们用预览代替 if 'body_preview' in node_data: # 一个非常简单的“描述”生成：看函数名猜功能 func_name = node_id.split('.')[-1] guessed_desc = f"Performs operations related to '{func_name}'." summary_parts.append(f"Description: {guessed_desc}") # 2. 调用关系（来自图） outgoing = list(self.graph.successors(node_id)) incoming = list(self.graph.predecessors(node_id)) if outgoing: summary_parts.append(f"Calls: {', '.join(outgoing[:5])}") # 限制数量 if incoming: summary_parts.append(f"Called by: {', '.join(incoming[:5])}") # 3. 关键代码预览（来自解析时存储的预览） if 'body_preview' in node_data and node_data['body_preview']: summary_parts.append(f"Code Preview:\n```python\n{node_data['body_preview']}\n```") return "\n".join(summary_parts) def summarize_for_llm_query(self, central_node_id, depth=1): """ 为一个中心节点及其周边生成用于LLM查询的浓缩上下文。 depth=1 表示包含中心节点及其直接邻居。 """ if central_node_id not in self.graph: return "" # 使用BFS获取指定深度的子图节点 visited = set([central_node_id]) queue = [(central_node_id, 0)] nodes_to_include = set([central_node_id]) while queue: current_node, current_depth = queue.pop(0) if current_depth >= depth: continue for neighbor in self.graph.successors(current_node): if neighbor not in visited: visited.add(neighbor) queue.append((neighbor, current_depth + 1)) nodes_to_include.add(neighbor) for neighbor in self.graph.predecessors(current_node): if neighbor not in visited: visited.add(neighbor) queue.append((neighbor, current_depth + 1)) nodes_to_include.add(neighbor) # 为这些节点生成摘要并拼接 context_parts = [f"# Code Context for analyzing '{central_node_id}' (Depth={depth})"] for node in nodes_to_include: context_parts.append("---") context_parts.append(self.generate_function_summary(node)) full_context = "\n".join(context_parts) # 估算Token数（近似值） estimated_tokens = len(full_context) // 4 print(f"Generated context length: ~{estimated_tokens} tokens (approx).") print(f"Original code for these functions would be much larger.") return full_context

使用示例：

# file: test_summarizer.py from code_parser import CodeGraphBuilder from graph_summarizer import GraphSummarizer builder = CodeGraphBuilder() graph = builder.build_graph_from_directory('./demo_project') summarizer = GraphSummarizer(graph) # 为 `process_data` 函数生成深度为1的上下文 context = summarizer.summarize_for_llm_query('demo_project.main.process_data', depth=1) print(context)

输出将是一个结构化的文本摘要，包含了process_data、sum_numbers、calculate_average和entry_point函数的关键信息，但其文本量远小于这四个函数的完整源代码。这个摘要可以直接作为Prompt的一部分发送给LLM，使其快速理解该函数的上下文。

4.2 策略二：增量式与聚焦式分析

很多代码分析任务不需要一次性理解整个项目。CodeGraph支持我们进行增量式和聚焦式的交互。

• 场景：LLM作为助手，回答开发者关于代码的特定问题。
• 流程：
  1. 开发者提问：“process_data函数里如果传入空列表会怎样？”
  2. 系统通过CodeGraph定位到process_data节点。
  3. 系统发现process_data调用了calculate_average。
  4. 系统查看calculate_average的摘要，发现其中有if count == 0:的判断。
  5. 系统将process_data的摘要和calculate_average的摘要（特别是条件判断部分）组合成Prompt，发送给LLM。
  6. LLM基于这个高度相关的、Token极少的上下文，给出精准回答：“会返回{'total': 0, 'average': 0}，因为calculate_average函数对count为0的情况做了处理，返回0。”

这种方式避免了将main.py甚至整个项目的代码都发送给LLM。

4.3 策略三：图查询先行，LLM润色后行

对于许多结构化问题，完全可以先用图查询算法得出答案，再让LLM将其转化为自然语言。

• 问题：“帮我找出项目中所有未被任何其他函数调用的‘死代码’函数。”
• 传统LLM方式：发送大量代码，让LLM通读并判断。Token消耗巨大，且可能出错。
• CodeGraph增强方式：
  1. 在图数据库（如Neo4j）中执行一个简单的Cypher查询：MATCH (f:Function) WHERE NOT (:Function)-[:CALLS]->(f) RETURN f.name。或者用networkx计算入度为0的节点（排除入口点等）。
  2. 瞬间得到结果列表：['demo_project.utils.helper_function']（假设只有它未被调用）。
  3. 将这个结果列表和问题一起，用极少的Token发送给LLM：“根据图分析，以下函数是未被调用的：helper_function。请为开发者生成一个清晰的报告，说明这个发现，并建议是否可以考虑删除或检查其用途。”
  4. LLM基于这个明确的结果，生成友好、专业的回答。

这种方法将计算密集型、确定性的代码结构分析交给专门的图算法，LLM只负责最擅长的语言生成和解释工作，分工明确，效率极高。

5. 与LLM集成实战：构建一个智能代码问答系统

我们将上述策略整合，构建一个简单的命令行智能代码问答系统原型。

# file: code_qa_system.py import os from typing import List from code_parser import CodeGraphBuilder from graph_summarizer import GraphSummarizer from openai import OpenAI # 示例使用OpenAI API，需配置API_KEY from dotenv import load_dotenv load_dotenv() # 从 .env 文件加载环境变量 class CodeQASystem: def __init__(self, codebase_path): print("Building CodeGraph...") self.builder = CodeGraphBuilder() self.graph = self.builder.build_graph_from_directory(codebase_path) self.summarizer = GraphSummarizer(self.graph) self.client = OpenAI(api_key=os.getenv("OPENAI_API_KEY")) print("CodeGraph ready.") def _find_relevant_nodes(self, question: str) -> List[str]: """ 一个简单的基于关键词的节点查找。 在实际系统中，这里应该用更高级的语义搜索（如嵌入向量+相似度）。 """ question_lower = question.lower() relevant_nodes = [] for node in self.graph.nodes(): if question_lower in node.lower(): relevant_nodes.append(node) # 如果没找到，返回一些中心节点（如出度高的） if not relevant_nodes: # 简单返回图的前几个节点 relevant_nodes = list(self.graph.nodes())[:3] return relevant_nodes[:3] # 限制返回数量 def answer_question(self, question: str) -> str: """ 回答关于代码库的问题。 1. 找到相关问题节点。 2. 为这些节点生成浓缩上下文。 3. 组合Prompt调用LLM。 4. 返回答案。 """ # 1. 查找相关节点 central_nodes = self._find_relevant_nodes(question) if not central_nodes: return "I couldn't find any specific functions mentioned in your question." # 2. 为每个相关节点生成上下文（深度=1） all_context_parts = [] for node in central_nodes: context = self.summarizer.summarize_for_llm_query(node, depth=1) all_context_parts.append(context) full_context = "\n\n".join(all_context_parts) # 3. 构建Prompt system_prompt = """You are an expert software engineer analyzing a codebase. Use the provided structured code context (function summaries, call relationships) to answer the user's question accurately and concisely. If the context does not contain enough information to answer fully, state what is missing.""" user_prompt = f"""Code Context: {full_context} Question: {question} Please answer based solely on the context above.""" # 估算Token并打印（实际调用API前） total_chars = len(system_prompt) + len(user_prompt) print(f"[DEBUG] Estimated prompt tokens: ~{total_chars // 4}") # 4. 调用LLM (这里模拟一个响应，实际需要调用API) # 注意：为了示例可运行，我们模拟一个回答。实际使用时请取消注释下面的API调用。 # try: # response = self.client.chat.completions.create( # model="gpt-4o-mini", # 或 "gpt-3.5-turbo" # messages=[ # {"role": "system", "content": system_prompt}, # {"role": "user", "content": user_prompt} # ], # temperature=0.2, # max_tokens=500 # ) # answer = response.choices[0].message.content # except Exception as e: # answer = f"Error calling LLM API: {e}" # 模拟回答 answer = f"""Based on the provided context about functions like `{central_nodes[0]}`: The function `process_data` calls `sum_numbers` and `calculate_average`. The `calculate_average` function contains a guard clause `if count == 0: return 0`, which prevents division by zero. Therefore, if an empty list is passed to `process_data`, the `count` will be 0, and `calculate_average` will return 0. The `sum_numbers` function will return 0 for an empty list. So the final result would be `{{'total': 0, 'average': 0}}`. This indicates the code handles the edge case of empty input gracefully.""" return answer if __name__ == '__main__': # 假设代码库路径 CODEBASE_PATH = "./demo_project" qa_system = CodeQASystem(CODEBASE_PATH) while True: user_question = input("\nAsk a question about the codebase (or 'quit'): ") if user_question.lower() in ['quit', 'exit']: break if not user_question.strip(): continue print("\n" + "="*50) print("Thinking...") answer = qa_system.answer_question(user_question) print(f"Answer:\n{answer}") print("="*50)

这个系统演示了核心工作流：解析代码为图 -> 根据问题定位相关子图 -> 生成摘要上下文 -> 构造高效Prompt -> 获取LLM答案。整个过程中，发送给LLM的文本是高度压缩和结构化的，Token消耗得到有效控制。

6. 常见问题与排查思路

在实现CodeGraph分析和Token优化策略时，你可能会遇到以下典型问题。

7. 最佳实践与工程建议

将CodeGraph分析集成到生产级应用中，需要考虑更多工程细节。

1. 增量更新与缓存

   • 代码库是不断变化的。每次提交都重新解析整个项目成本高昂。
   • 实现增量解析：利用tree-sitter的增量解析能力，只解析发生变更的文件，并增量更新图结构。
   • 建立缓存：将构建好的CodeGraph序列化（如使用pickle或存储到图数据库）并缓存。为每个文件版本或提交哈希存储对应的图快照。

2. 混合策略与降级方案

   • CodeGraph不是万能的。对于某些极其复杂或高度依赖具体实现的逻辑问题，LLM可能仍然需要查看部分原始代码。
   • 设计混合策略：系统优先使用CodeGraph摘要。如果LLM返回的答案置信度低（可通过提示工程让LLM输出置信度），或用户明确要求“显示具体代码”，则系统可以按需附上原始代码片段。
   • 提供降级路径：始终保留一个“回退”模式，当图分析服务不可用时，能降级到传统的基于全文检索或简单AST分析的方法。

3. 安全与边界

   • 输入验证：确保解析的代码来源可信，防止通过恶意构造的代码进行路径遍历或注入攻击。
   • 资源隔离：解析第三方或用户上传的代码应在沙箱环境中进行，限制其内存、CPU和网络访问。
   • 敏感信息过滤：在生成摘要或发送到LLM前，对代码进行扫描，过滤掉硬编码的密码、API密钥、内部IP等敏感信息。

4. 评估与监控

   • 定义评估指标：衡量优化效果不能只看Token数。需要监控：
     • 平均每次问答的Token消耗（输入+输出）。
     • 问答准确率/用户满意度（通过反馈或人工评估）。
     • 系统响应延迟（图查询+LLM调用的总时间）。
   • A/B测试：可以对比“纯CodeGraph摘要”和“CodeGraph摘要+部分源码”两种策略在不同类型问题上的效果，持续优化策略选择算法。

5. 扩展性与多语言支持

   • 抽象解析接口：将CodeGraphBuilder设计为支持多语言后端的抽象类。为每种语言实现特定的解析器（使用tree-sitter对应语言库）。
   • 统一图模型：定义一套通用的、语言无关的图节点和边类型（如Function,Class,Calls,Inherits），不同语言的解析器都将代码映射到这个统一模型上。这样，上层的分析和查询逻辑就可以与语言解耦。

通过将CodeGraph分析与LLM智能结合，我们能够在代码理解、智能问答、代码审查、架构分析等场景中，实现精度与效率的平衡。Token消耗的优化不是目的，而是实现更强大、更实时、更经济的AI编程工具的手段。希望本文提供的思路和代码示例，能帮助你启动自己的项目，并在此基础上探索出更优的解决方案。下一步，你可以尝试集成更强大的图查询语言（如Cypher）、引入向量数据库进行语义检索，或者探索如何用小型、专用的模型来替代部分摘要生成工作，从而构建一个完全自主、高效、低成本的代码智能分析系统。