1. 项目概述：一次对Coding Agent上下文压缩技术的深度“考古”

最近在折腾几个主流的Coding Agent项目，想搞清楚它们内部处理长代码上下文的“压缩”机制到底是怎么实现的。这玩意儿对提升开发效率至关重要，毕竟没人想每次问个问题，都得把整个项目几万行代码全塞给大模型，那成本高得吓人，速度也慢。我原本打算在网上找些现成的分析文章或者开源实现作为参考，结果发现了一个挺有意思的现象：关于这些Agent如何压缩上下文，网上流传的说法和代码示例，有一半左右都存在不同程度的偏差，甚至是完全错误的。

这促使我决定自己动手，直接去读源码。我选取了六个在开发者社区中讨论度较高、且有明确开源实现的Coding Agent项目，深入它们的核心模块，把上下文压缩这块的逻辑从头到尾捋了一遍。这个过程有点像技术考古，剥开层层封装，去看最底层的实现逻辑。我发现，很多误解源于对“压缩”这个词的过度简化理解，以及将不同层次的技术方案混为一谈。这次阅读源码的收获，远不止是弄懂了几个API的调用方式，更是对LLM（大语言模型）在代码场景下的工程化应用有了更立体的认识。如果你也在研究AI编程助手、或者对如何高效利用LLM的上下文窗口感兴趣，那么我接下来的这些发现和踩过的坑，或许能帮你省下不少时间。

2. 核心概念澄清：上下文压缩到底在压缩什么？

在深入源码之前，我们必须先统一认识：在Coding Agent的语境下，“上下文压缩”究竟指什么？网上很多文章一提到压缩，就立刻联想到类似ZIP的算法压缩，或者简单理解为“提取摘要”，这其实是第一个常见的误区。

2.1 压缩的目标与层次

Coding Agent处理代码上下文，目标非常明确：在有限的LLM上下文窗口内（比如GPT-4的128K，Claude的200K），尽可能塞入对当前编程任务最相关、信息密度最高的信息。这里的“压缩”是一个广义概念，至少包含三个层次：

1. 信息筛选（Selection）：从海量的项目文件、历史对话、文档中，智能地挑选出与当前用户查询最相关的片段。这不是压缩数据本身，而是减少数据量。比如，用户问“如何修改登录接口的验证逻辑？”，Agent应该优先提供auth.py、login_controller.py以及相关的API文档片段，而不是把image_processing.py也一股脑儿塞进去。

2. 信息浓缩（Summarization）：对选中的、篇幅较长的代码块或文本，生成一个更短的、保留核心信息的摘要。例如，将一个200行的类，总结成一段描述其核心职责、主要方法和关键属性的文字。

3. 表示压缩（Representation Compression）：使用更高效的编码方式来表示信息。这在当前Coding Agent中相对少见，但一些前沿研究在尝试，比如学习代码的嵌入向量，然后用向量来近似表示语义，或者使用特定的标记化策略来减少Token数量。

我读的这六个Agent的源码，它们的“压缩”核心，几乎都集中在信息筛选和信息浓缩这两个层面，而且往往是组合使用。网上很多错误的示例，要么只讲了浓缩（摘要），却忽略了更关键的筛选步骤；要么把筛选的逻辑描述得过于简单，比如直接用文件名关键词匹配，这在实际复杂项目中效果很差。

2.2 为什么网上信息容易出错？

根据我的观察，错误主要来源于几个方面：

• 概念混淆：将学术论文中提到的理想化“上下文压缩”算法，与工业界Agent中实际采用的、更工程化的混合策略混为一谈。
• 过度简化：为了教程的易懂性，示例代码只展示了最基础的、基于规则的方法（如：取文件的前N行后N行），但读者误以为这就是最佳实践。
• 版本滞后：Agent项目迭代很快，一些早期的、实验性的压缩策略已经被淘汰或重构，但相关的博客文章没有更新。
• “黑盒”误解：很多文章只分析了Agent调用LLM的“外层”逻辑，而没有深入到其内部如何准备和组装prompt的细节，而压缩恰恰发生在这个准备阶段。

注意：当你看到“上下文压缩”时，首先要问：它是在哪个阶段、针对什么数据、以什么目标进行的压缩？接下来，我们进入源码层面，看看真实的Agent是怎么做的。

3. 六大Agent源码压缩策略横向剖析

我选取的六个Agent涵盖了不同的设计哲学和技术栈，包括一些基于LangChain的框架、专为代码优化的Agent，以及一些明星开源项目。为了保护项目隐私并聚焦于技术模式，我将用代号A到F来指代它们。下面的分析将揭示它们策略的异同。

3.1 Agent A：基于向量检索的精准筛选

Agent A的策略非常直接，它重度依赖向量数据库（如Chroma、Weaviate）。它的压缩流程可以概括为：

1. 离线阶段：将整个代码库进行切片（比如按函数、类或固定大小文本块），为每个切片生成嵌入向量，并存入向量数据库。
2. 在线阶段：当用户提出问题时，将问题本身也转化为向量，然后在向量数据库中进行相似性搜索，召回Top-K个最相关的代码片段。
3. 组装上下文：将这些召回片段，连同问题一起，组装成最终的prompt发送给LLM。

源码中的关键发现：

• 它几乎没有做传统的“文本摘要式”浓缩。它的“压缩”体现在用向量相似度筛选代替了全文加载。
• 代码切片策略很关键。我看到的源码中，它并不是简单按行切分，而是尝试用语法解析器（类似Tree-sitter）识别代码结构，尽量保证一个切片是一个完整的函数或类。这避免了检索到半个函数这种尴尬情况。
• 它处理不了“分散的相关性”。比如，修改一个功能可能需要改动三个分散在不同文件中的函数。如果这三个函数各自的向量与问题的相似度都不是最高，它们可能无法被同时召回。这是该策略的一个局限性。

网上常见的错误描述：很多文章说Agent A“会智能总结代码”，这不对。它的智能体现在检索，而非总结。

3.2 Agent B：规则与摘要的混合模式

Agent B采用了一种分层策略，我认为它更贴近“压缩”的直觉。

1. 第一层：基于规则的粗筛。根据用户问题中的关键词（如文件名、类名、函数名、错误信息），在文件系统中快速定位可能相关的文件。
2. 第二层：语义摘要。对于上一步找到的文件，如果文件太大（比如超过200行），它会调用LLM（通常是一个更小、更快的模型）为这个文件生成一个简短的摘要，描述文件的主要作用和核心结构。
3. 第三层：最终组装。将用户问题、相关文件的路径、以及这些文件的摘要（而非完整内容）组合起来，发送给主LLM进行推理和代码生成。

源码中的关键发现：

• 这里的“压缩”核心在第二步：用文件摘要替代文件全文。这极大地节省了上下文窗口。
• 源码中有一个有趣的权衡：何时生成摘要？Agent B采用了缓存机制。第一次遇到一个大文件时生成摘要并缓存，后续直接使用，避免了重复调用摘要模型的消耗。
• 它的弱点在于第一层规则。如果关键词匹配失败（比如用户用自然语言描述一个没有明显命名特征的逻辑），整个流程就可能失效。

网上常见的错误描述：有些资料把第二步的“摘要”当成了唯一压缩手段，忽略了第一步的文件筛选，这会导致摘要模型需要处理大量无关文件，效率低下。

3.3 Agent C：利用LSP（语言服务器协议）的智能感知

Agent C的思路很巧妙，它直接“借用”了现代IDE的核心能力。

1. 集成LSP：它启动或连接到一个代码语言的LSP服务器（比如Python的pylsp， TypeScript的tsserver）。
2. 符号查询：当用户问题涉及具体符号（如函数名、变量名）时，它通过LSP的documentSymbols或workspace/symbol请求，快速获取该符号的定义位置、类型和引用关系。
3. 上下文构建：它不仅插入符号定义处的代码，还会根据LSP提供的信息，智能地包含一些调用者或被调用者的代码片段，形成一个小的相关代码子图。

源码中的关键发现：

• 这种方法的“压缩”是精准且结构化的。它提供的不是文本片段，而是代码语义单元及其关系。
• 它非常依赖LSP的质量和项目索引的完整性。对于新创建或未保存的文件，LSP可能无法提供信息。
• 源码中处理了LSP响应超时或失败的回退策略，通常会降级到基于文本的搜索。

网上常见的错误描述：几乎很少有文章详细分析这种基于LSP的方法。多数讨论仍停留在文本检索层面。

3.4 Agent D：对话历史的动态管理

Agent D特别关注多轮对话中的上下文累积问题。它的压缩主要针对历史对话记录。

1. 历史消息窗口：它维护一个固定长度的对话历史滑动窗口，只保留最近N轮交互。
2. 关键信息提取：对于被移出窗口的旧对话，它不是简单丢弃，而是尝试调用LLM从这些旧对话中提取出仍然相关的“关键决策”、“已确认的需求”或“系统状态变更”，将这些提取出的精华信息以一条总结性消息的形式，重新插入或保留在上下文头部。
3. 代码上下文的分离管理：它将“对话历史”和“当前代码上下文”分开管理。代码上下文的筛选可能采用类似Agent A或B的方法，而对话历史则用上述策略压缩。

源码中的关键发现：

• 这解决了长期对话中prompt无限增长的核心难题。其压缩对象是自然语言对话历史。
• 源码中实现“关键信息提取”的频率和触发条件是个调参难点。频繁提取会增加成本，不提取则会丢失重要信息。

网上常见的错误描述：常被笼统地称为“总结了聊天历史”，但没有说清它是与代码检索并行的独立压缩流程。

3.5 Agent E：基于抽象语法树的精确切片

Agent E追求极致的代码上下文精度，它的压缩策略是手术刀式的。

1. 解析AST：对于候选代码文件，它使用语法解析器生成完整的抽象语法树。
2. 定位焦点：分析用户查询，尝试定位到AST中的特定节点（例如，某个函数定义、某个类声明）。
3. 提取子图：不仅提取该焦点节点本身的代码，还提取其在AST中的直接父节点（如所属的类）、子节点（函数体内的语句）以及兄弟节点（同类中的其他方法），形成一个结构完整的代码块。
4. 丢弃无关部分：文件中的其他无关代码（如远处的导入、不相关的函数）被彻底排除在上下文之外。

源码中的关键发现：

• 这种方法的压缩比可以非常高，提供的信息也极度相关。它的“压缩”是通过语法树的精确裁剪实现的。
• 实现复杂，且严重依赖于解析器的准确性和对多种编程语言的支持。源码中包含了大量的错误处理逻辑，以应对解析失败的情况。
• 对于非结构化的文本文件（如配置文件、文档），此方法失效，需要回退到其他策略。

网上常见的错误描述：常被简化为“它只发送相关的函数”，忽略了其维护代码结构完整性的努力。

3.6 Agent F：预测性加载与预计算

Agent F的策略带有一定的前瞻性，试图预测用户下一步可能需要什么。

1. 行为模式学习：在后台，它可能会匿名收集（在符合规范的前提下）或内置一些常见的开发模式。例如，在用户查看一个API接口的定义后，接下来很可能会查看它的实现，或者查看调用它的代码。
2. 预计算上下文：当用户执行一个操作（如跳转到定义）时，Agent F不仅加载当前所需的上下文，还会在后台并行地预计算和加载它预测用户下一步可能需要的相关上下文（如该函数的调用链、相关测试文件）。
3. 快速切换：当用户真的发起相关查询时，所需上下文已经部分准备就绪，可以快速响应。

源码中的关键发现：

• 这更像是一种带宽换时间的优化，而非严格意义上的压缩。它通过提前准备来减少用户感知的延迟。
• 源码中需要精巧的缓存和垃圾回收机制，以防预计算的数据过多占用内存。
• 预测的准确性直接决定了该策略的收益。错误的预测会导致资源浪费。

网上常见的错误描述：这个策略很少被公开详细讨论，因为它通常与商业产品的用户体验优化深度绑定。

4. 实操：构建一个简易的混合压缩策略

看完了六大Agent的策略，我们来动手实现一个融合了其中几种思想的、简易但有效的上下文压缩模块。我们将结合向量检索筛选和关键代码摘要。

4.1 环境准备与依赖安装

我们使用Python，主要依赖langchain（用于组织流程）、chromadb（向量数据库）、openai（用于摘要和主推理，也可用其他兼容API的模型替代）以及tree-sitter（用于代码解析）。

# 创建虚拟环境并安装依赖 python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows pip install langchain langchain-openai chromadb tree-sitter # 可能需要额外安装 tree-sitter 的语言包，例如 Python pip install tree-sitter-python

4.2 核心模块一：基于AST的代码切片器

我们不能简单按行或按字符切分代码，那样会破坏结构。下面是一个使用tree-sitter将Python文件切分为函数/类级别片段的示例。

from tree_sitter import Language, Parser import os # 加载Python语法库（需要提前编译，这里假设已存在） PYTHON_LANGUAGE = Language('/path/to/your/tree-sitter-python.so', 'python') class CodeSplitter: def __init__(self): self.parser = Parser() self.parser.set_language(PYTHON_LANGUAGE) def split_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 chunks = [] # 遍历AST，抓取函数和类定义 def _traverse(node): if node.type in ('function_definition', 'class_definition'): start_line = node.start_point[0] end_line = node.end_point[0] code_snippet = '\n'.join(source_code.splitlines()[start_line:end_line+1]) chunk_meta = { 'type': node.type, 'name': self._extract_name(node, source_code), 'start_line': start_line, 'end_line': end_line, 'file_path': file_path } chunks.append((code_snippet, chunk_meta)) for child in node.children: _traverse(child) _traverse(root_node) # 如果没有找到函数/类，则将整个文件作为一个块（可能是配置文件等） if not chunks: chunks.append((source_code, {'type': 'file', 'name': os.path.basename(file_path), 'file_path': file_path})) return chunks def _extract_name(self, node, source_code): """从节点中提取函数名或类名""" for child in node.children: if child.type == 'identifier': return source_code[child.start_byte:child.end_byte] return 'anonymous'

4.3 核心模块二：向量存储与检索

我们将切分好的代码片段嵌入并存储，然后根据问题检索。

from langchain.embeddings import OpenAIEmbeddings from langchain.vectorstores import Chroma from langchain.schema import Document import hashlib class CodeRetriever: def __init__(self, persist_directory="./chroma_db"): self.embeddings = OpenAIEmbeddings(model="text-embedding-3-small") # 使用小模型以节约成本 self.vectorstore = Chroma( embedding_function=self.embeddings, persist_directory=persist_directory ) self.splitter = CodeSplitter() def index_codebase(self, root_dir): """索引整个代码目录""" documents = [] for root, _, files in os.walk(root_dir): for file in files: if file.endswith('.py'): # 示例仅处理Python文件 file_path = os.path.join(root, file) chunks = self.splitter.split_file(file_path) for snippet, meta in chunks: # 为每个片段创建唯一的ID doc_id = hashlib.md5(f"{file_path}:{meta['start_line']}:{meta['end_line']}".encode()).hexdigest() doc = Document( page_content=snippet, metadata=meta, id=doc_id ) documents.append(doc) if documents: self.vectorstore.add_documents(documents) self.vectorstore.persist() print(f"已索引 {len(documents)} 个代码片段。") def retrieve(self, query, k=5): """检索与查询最相关的k个代码片段""" return self.vectorstore.similarity_search(query, k=k)

4.4 核心模块三：智能摘要压缩器

对于检索回来的长片段，我们可能还需要进一步压缩。

from langchain.chat_models import ChatOpenAI from langchain.prompts import ChatPromptTemplate from langchain.schema import StrOutputParser class CodeSummarizer: def __init__(self): self.llm = ChatOpenAI(model="gpt-3.5-turbo", temperature=0) # 用小模型做摘要 self.prompt = ChatPromptTemplate.from_messages([ ("system", "你是一个资深的代码分析师。请为下面的代码片段生成一个简洁的摘要，说明它的核心功能、输入输出和关键逻辑。摘要必须用中文，且不超过150字。"), ("user", "代码片段:\n```python\n{code}\n```\n所属文件：{file_path}") ]) self.chain = self.prompt | self.llm | StrOutputParser() def summarize(self, code_snippet, file_path): """生成代码摘要""" try: summary = self.chain.invoke({"code": code_snippet, "file_path": file_path}) return summary except Exception as e: print(f"摘要生成失败: {e}") return f"（摘要生成失败）代码来自 {file_path}"

4.5 整合：完整的上下文组装流程

现在，我们将上述模块组合起来，形成一个完整的上下文处理管道。

class ContextCompressor: def __init__(self, code_root_dir): self.retriever = CodeRetriever() self.summarizer = CodeSummarizer() # 首次运行时需要索引代码库 if not os.path.exists("./chroma_db"): print("开始索引代码库，这可能需要一些时间...") self.retriever.index_codebase(code_root_dir) def build_context(self, user_query, use_summary=True, max_tokens=8000): """ 构建最终上下文。 :param user_query: 用户问题 :param use_summary: 是否对长片段使用摘要 :param max_tokens: 目标上下文最大token数（粗略估计） """ # 1. 检索相关片段 relevant_chunks = self.retriever.retrieve(user_query, k=8) # 多检索一些以备筛选 final_context_parts = [] current_token_estimate = 0 # 粗略的token估算（按4字符=1 token） def estimate_tokens(text): return len(text) // 4 # 2. 智能选择与压缩 for chunk in relevant_chunks: code_content = chunk.page_content meta = chunk.metadata token_count = estimate_tokens(code_content) # 如果启用摘要且片段较长，则进行摘要 if use_summary and token_count > 200: # 假设超过200 token的片段算“长” summary = self.summarizer.summarize(code_content, meta['file_path']) display_content = f"文件 `{meta['file_path']}` 中的 `{meta['name']}` (摘要):\n```python\n# 摘要: {summary}\n# 关键代码预览 (行 {meta['start_line']}-{meta['end_line']}):\n{code_content[:500]}...\n```" token_count = estimate_tokens(display_content) else: display_content = f"文件 `{meta['file_path']}` 中的 `{meta['name']}` (行 {meta['start_line']}-{meta['end_line']}):\n```python\n{code_content}\n```" # 3. 检查是否超出token限制 if current_token_estimate + token_count > max_tokens: # 如果快超了，可以尝试只加入更短的摘要或仅引用 if use_summary: brief_ref = f"相关代码位于 `{meta['file_path']}:{meta['start_line']}`，名为 `{meta['name']}`。" final_context_parts.append(brief_ref) current_token_estimate += estimate_tokens(brief_ref) break # 停止添加新内容 else: final_context_parts.append(display_content) current_token_estimate += token_count # 4. 组装最终提示 system_prompt = "你是一个智能编程助手。请根据以下提供的相关代码上下文，回答用户的问题。如果上下文不包含解决问题所需的信息，请如实说明。" user_prompt_with_context = f"相关代码上下文：\n\n" + "\n\n---\n\n".join(final_context_parts) + f"\n\n用户问题：{user_query}" final_prompt = [ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_prompt_with_context} ] return final_prompt, current_token_estimate

4.6 使用示例

# 初始化，指定你的代码根目录 compressor = ContextCompressor("/path/to/your/project") # 用户提问 query = "我们项目的用户登录验证逻辑是在哪里实现的？我想看看它是怎么检查密码的。" # 构建压缩后的上下文 prompt_messages, used_tokens = compressor.build_context(query, use_summary=True) print(f"构建的上下文大约使用了 {used_tokens} 个token。") print("System Prompt:", prompt_messages[0]['content'][:200], "...") print("\nUser Prompt Preview:", prompt_messages[1]['content'][:500], "...") # 接下来，你可以将 prompt_messages 发送给主LLM（如GPT-4）获取答案 # from langchain.chat_models import ChatOpenAI # main_llm = ChatOpenAI(model="gpt-4") # response = main_llm.invoke(prompt_messages)

5. 常见问题与避坑指南

在实现和调试上述流程中，我遇到了不少坑。这里总结一下，希望你能避开。

5.1 向量检索的准确性陷阱

• 问题：检索出来的代码片段看似相关（语义相似），但实际上对解决问题没用。比如，用户问“如何处理登录失败”，可能检索出一堆包含“失败”字眼的错误处理代码，但真正的认证逻辑却没被检索到。
• 排查与解决：
  1. 优化查询：不要直接将用户问题作为查询。尝试用LLM或规则将用户问题重写（Query Rewriting）成更利于代码检索的形式。例如，将“怎么登录？”重写为“def login, authenticate, password check, user authentication function”。
  2. 混合检索：结合关键词（BM25）和向量检索。LangChain的EnsembleRetriever可以做到这一点。关键词检索能保证术语匹配，向量检索保证语义匹配。
  3. 检查嵌入模型：确保你使用的嵌入模型对代码有较好的理解能力。通用文本嵌入模型（如text-embedding-ada-002）效果不错，但专门针对代码训练的模型（如OpenAI的text-embedding-3-large或开源模型）可能更佳。
  4. 分块策略：回顾我们实现的CodeSplitter。块太大，会包含无关信息；块太小，会丢失上下文。以完整的函数、类或逻辑段落为块通常是好的起点。

5.2 摘要模型的成本与质量平衡

• 问题：为每个长代码片段调用LLM生成摘要，成本高昂且速度慢。
• 排查与解决：
  1. 分层摘要：不要对所有文件都摘要。可以设置阈值，例如，只对超过150行或200个token的代码块进行摘要。对于小文件或短函数，直接提供完整代码。
  2. 缓存摘要：像Agent B那样，为每个代码块生成一次摘要并持久化存储。下次遇到相同的块，直接读取缓存。这需要以代码块的唯一标识（如文件路径+起止行号的哈希）作为缓存键。
  3. 使用更小更快的模型：摘要不需要GPT-4级别的创造力。GPT-3.5-Turbo、Claude Haiku甚至一些优秀的开源小模型（如Qwen2.5-Coder-7B）在代码摘要任务上表现足够好，且成本/速度优势明显。
  4. 静态分析摘要：对于结构良好的代码，可以尝试用规则生成基础摘要。例如，从函数定义行提取函数名和参数，从文档字符串（docstring）中提取第一句话。这可以作为LLM摘要的补充或降级方案。

5.3 上下文组装后的Token超限

• 问题：即使经过了检索和摘要，组装起来的上下文仍然可能超过LLM的窗口限制。
• 排查与解决：
  1. 动态裁剪：在build_context方法中，我们实现了简单的token估算和截断。但估算可能不准。更稳健的做法是使用模型的Tokenizer（如tiktoken）进行精确计数，并设置一个安全阈值（例如，最大窗口的80%）。
  2. 优先级排序：不要简单按检索分数顺序添加内容。可以设计一个优先级算法，综合考虑检索分数、代码片段长度、类型（定义可能比引用更重要）等因素，优先添加高优先级、高信息密度的内容。
  3. 二次压缩：当内容过多时，可以对已选中的、重要性相对较低的片段进行“激进摘要”，比如只保留函数签名和一行功能描述，彻底移除函数体。

5.4 处理非代码文件与复杂查询

• 问题：项目中有配置文件（YAML, JSON, .env）、文档（MD, RST）等。用户查询也可能是复杂的、多步骤的（如“为这个函数添加错误处理并写个测试”）。
• 排查与解决：
  1. 多模态分块器：扩展CodeSplitter，使其能根据文件类型使用不同的解析策略。对于Markdown，可以按章节切分；对于JSON/YAML，可以按顶级键切分。
  2. 查询分解：对于复杂查询，可以先让一个LLM（或一个规则系统）将其分解成多个子问题。例如，“添加错误处理并写测试”可以分解为“1. 找到目标函数；2. 分析可能出现的错误；3. 为函数添加try-catch；4. 根据函数功能编写测试用例”。然后针对每个子问题分别进行上下文检索和组装，或者按顺序处理。

5.5 性能与实时性

• 问题：向量数据库索引构建慢，检索延迟影响用户体验。
• 排查与解决：
  1. 增量索引：监控文件系统变化，只对新增或修改的文件进行重新索引，而不是每次全量重建。
  2. 内存缓存：对高频或最近使用的检索结果进行缓存。相同的用户查询在一定时间内可以直接返回缓存上下文。
  3. 异步处理：索引和摘要生成等耗时操作应放在后台异步执行，不阻塞主交互流程。

6. 从源码阅读中获得的更深层启示

读完六个Agent的源码，并自己动手实现一遍后，我对“上下文压缩”这件事有了几个超越具体技术点的认识。

第一，没有银弹，只有权衡。每个Agent的策略选择，都是在其设计目标、资源约束和性能要求下的权衡。追求极致响应速度的Agent可能选择简单的规则筛选；追求答案准确性的Agent可能不惜成本进行多轮检索和精炼；面向企业的Agent则必须考虑安全、可控和可解释性。网上很多文章的错误，就在于宣扬某一种方法是“最好的”，而忽略了场景。

第二，压缩的本质是“信息检索”加“信息呈现”问题。它一半是搜索工程（如何找到最相关的信息），另一半是交互设计（如何以最有效的方式把信息喂给LLM）。很多创新发生在两者的结合部，比如利用LSP的符号信息来增强检索的准确性，或者用对话历史总结来优化信息呈现的结构。

第三，数据质量决定上限，工程细节决定下限。再好的算法，如果代码库的注释一塌糊涂、命名随意，向量检索和摘要的效果都会大打折扣。同样，工程上的细节，比如缓存策略、错误处理、降级方案，决定了系统在真实复杂环境下的稳定性和可用性。这些细节在源码中随处可见，但在网上的概括性文章里却常常被忽略。

最后，保持对“黑盒”的好奇心。直接阅读源码是破除迷雾、获得真知的最有效途径。当网上众说纷纭时，最好的办法就是自己打开代码仓库，从main函数或入口点开始，一步步跟踪数据流和控制流。这个过程本身，就是一次极好的学习。我这次“考古”之旅最大的收获，不是记住了六个Agent的具体实现，而是建立起了一套分析AI工程系统的方法论——看它的输入输出、拆解它的处理管道、理解它的设计取舍。这套方法论，对于理解未来任何新的Agent或AI系统，都同样适用。