1. 项目概述：一个为AI编程工具设计的上下文压缩引擎
如果你每天都在用Cursor、Claude Code或者GitHub Copilot这类AI编程助手，那你肯定对“上下文窗口”和“Token消耗”这两个词不陌生。每次你让AI助手“看看这个文件”、“运行一下git status”或者“检查构建日志”，它都需要把这些信息塞进上下文里，然后发给背后的大模型。这些信息，无论是代码文件还是命令行输出，都是以Token计费的——而且价格不菲。
我自己的账单就曾让我心惊肉跳。一个中等规模的TypeScript项目，一次普通的编码会话，动辄消耗几万甚至十几万个Token。尤其是当AI反复读取同一个文件，或者执行npm run build、cargo test这种会产生大量输出的命令时，Token就像开了闸的水龙头一样哗哗流走。更让人头疼的是，这些信息里充斥着大量对AI理解任务毫无帮助的“噪音”：重复的导入语句、冗长的构建日志、格式化的JSON数据、甚至是终端里花花绿绿的ANSI颜色码。我们付钱让AI看这些，本质上是在为“信息垃圾”买单。
lean-ctx就是为了解决这个问题而生的。它不是一个简单的文本压缩工具，而是一个运行在你本地的、智能的“上下文运行时”（Context Runtime）。它的核心使命非常明确：在信息到达AI模型之前，用极高的压缩比过滤掉所有冗余，只保留对当前任务真正有用的部分，从而将Token成本降低60%到99%。
你可以把它想象成AI助手和你电脑之间的一个“智能过滤器”或“翻译官”。当AI想要读取文件时，lean-ctx会提供缓存、摘要、差异对比等多种读取模式，而不是傻乎乎地把整个文件原文送过去。当AI执行shell命令时，lean-ctx会拦截命令输出，用90多种预定义的模式识别并压缩掉无关信息（比如git status中未跟踪文件的完整列表，压缩后可能只显示计数）。这一切对AI工具本身是透明的，你不需要改变任何使用习惯——安装、配置一次，之后所有的Token节省都是自动的。
这个项目完全用Rust编写，是一个单一二进制文件，强调零遥测、完全本地运行和开箱即用的体验。它通过两种主要方式工作：一是作为MCP（Model Context Protocol）服务器，为支持MCP的编辑器（如Cursor, Claude Code）提供一系列智能工具（如ctx_read,ctx_shell）；二是通过Shell Hook，在系统层面劫持常见的命令行工具（如git,npm,docker），在输出到达终端（进而被AI捕获）前就完成压缩。
接下来，我会带你深入拆解lean-ctx的设计哲学、核心组件，并分享从安装配置到高级调优的完整实操经验，以及我踩过的一些坑和独家优化技巧。
1.1 核心需求与设计哲学
为什么我们需要lean-ctx？仅仅是为了省钱吗？不完全是。更深层次的需求是提升AI编程的效率和体验。
1. 成本可控化：AI编程工具的API成本对于重度用户来说是一笔不小的开支。lean-ctx的目标是将不可预测的、随项目复杂度飙升的成本，变得可预测、可管理。通过压缩，你可以用同样的预算完成更多工作，或者以更低的成本使用更强大的模型。
2. 上下文效率最大化：大模型的上下文窗口是宝贵的资源。浪费在冗余信息上的每一个Token，都挤占了本可用于更重要代码逻辑、系统指令或历史对话的空间。lean-ctx通过智能压缩，确保有限的上下文窗口里装的是“高营养密度”的信息。
3. 工作流无缝集成：任何需要改变开发者固有习惯的工具都很难推广。lean-ctx的设计原则是“零侵入”。它不应该要求你学习一套新的命令，或者改变你与AI助手的交互方式。无论是通过MCP集成还是Shell Hook，它都在后台默默工作，让你几乎感觉不到它的存在，直到你查看节省报告。
4. 隐私与安全至上：处理代码和命令行输出涉及敏感信息。lean-ctx坚持“零网络请求、零遥测”的原则，所有压缩、分析都在本地完成，数据从不离开你的机器。这对于处理公司专有代码的开发者来说至关重要。
基于这些需求，lean-ctx的架构围绕几个核心协议构建：
- CEP (Cognitive Efficiency Protocol):评估AI请求的“认知效率”，对任务复杂度分类，并自动验证压缩后的信息是否仍能满足AI的需求。
- CCP (Context Continuity Protocol):实现跨会话的记忆。AI助手通常“健忘”，新开一个聊天窗口就丢失了之前的上下文。CCP允许
lean-ctx在不同会话间持久化任务、发现和决策，极大减少“冷启动”所需的重复信息传递。 - TDD (Token Dense Dialect):一套特殊的符号和缩写体系，用于在AI和工具间进行极其紧凑的通信。例如，用
λ代表lambda，用§代表section。这在传输大量元数据或摘要时能额外节省8-25%的Token。
2. 核心组件与工作原理深度解析
lean-ctx并非一个黑盒魔法。理解其内部组件如何协同工作，能帮助你更好地利用它，并在出现问题时进行排查。
2.1 Shell Hook：命令输出的“实时压缩器”
这是lean-ctx最立竿见影的功能。它通过创建一系列shell别名（alias）或函数（function），在你执行如git、npm、docker等命令时，实际调用的是lean-ctx -c “原命令”。lean-ctx执行原命令，捕获其输出，应用匹配的压缩模式，然后将压缩后的结果打印到终端。
它是如何工作的？
- 模式匹配：
lean-ctx内置了90多种针对不同命令和工具的输出模式。例如，对于git status，它能识别“Changes not staged for commit:”等章节，并将文件列表压缩为“2 files modified, 1 file deleted”这样的摘要。对于npm install，它会过滤掉庞大的依赖树详情，只保留关键信息如新增/更新的包数量和严重性警告。 - 结构化提取：对于JSON、XML等结构化数据（常见于
curlAPI请求或docker inspect），它会提取schema或关键字段，丢弃冗余的格式空白和重复的样板数据。 - ANSI代码剥离：终端颜色和样式代码对AI毫无意义，但占Token。
lean-ctx会在压缩前自动剥离它们。 - 安全兜底：如果压缩过程出错，或者命令输出无法识别，
lean-ctx有一个“tee模式”配置，可以选择始终、仅在失败时或从不保留原始输出到日志文件，确保你不会丢失任何信息。
实操心得：Shell Hook的“副作用”启用Shell Hook后，你可能会发现终端里某些命令的输出“变短了”或者“格式不一样了”。这是正常现象。对于需要查看完整输出进行人工调试的场景，你有几种选择：
- 使用
lean-ctx bypass “git status”命令，这会绕过压缩直接执行。- 使用
lean-ctx-raw这个别名来运行任何命令（例如lean-ctx-raw git log）。- 临时关闭整个Hook：在当前shell会话中运行
lean-ctx-off。重新打开用lean-ctx-on。 我个人的习惯是在日常开发中保持Hook开启，享受节省；当需要仔细审查某个命令的详细输出时，就用lean-ctx-raw前缀。
2.2 MCP服务器：AI工具的“智能工具箱”
MCP（Model Context Protocol）是Anthropic提出的一种协议，允许外部工具（服务器）向AI模型（客户端）提供一系列可调用的功能。lean-ctx作为MCP服务器，向支持的编辑器（如Cursor、Claude Code）注册了40多个工具。
核心工具解析：
ctx_read（智能文件读取）：这是使用频率最高的工具。它不只是读取文件，而是提供了多种模式：full: 完整读取并缓存。首次读取消耗正常Token，后续重复读取同一文件（在缓存有效期内）仅需约13个Token来引用缓存。map: 生成文件“地图”——仅包含依赖（import/require）和导出的API签名。对于快速了解一个模块的接口，这通常只需5-15%的原始Token。signatures: 比map更详细，提取所有函数、类、方法的签名，忽略实现体。diff: 如果文件自上次读取后有修改，只发送差异部分。aggressive/entropy/task: 基于信息熵或任务相关性进行更激进的过滤，适用于大型或模板化文件。lines:N-M: 精确读取指定行号范围。
ctx_shell（增强版Shell执行）：与Shell Hook类似，但通过MCP调用。好处是AI可以直接使用这个工具，并且压缩逻辑更紧密地与AI的意图结合。例如，AI问“项目里有哪些测试文件？”，ctx_shell执行find . -name “*.test.*” -o -name “*.spec.*”后，可能会智能地分组和摘要结果。ctx_search（语义化代码搜索）：不仅仅是grep。它结合了文本匹配和简单的语义分析（如BM25算法），能更好地理解“查找处理用户认证的函数”这类查询。ctx_session/ctx_knowledge（记忆与知识库）：这是实现CCP协议的关键。ctx_session保存当前任务的状态；ctx_knowledge则像一个持久的项目笔记，AI可以往里存储“这个函数是性能瓶颈”或“数据库配置在这里”等信息，并在后续会话中查询。ctx_graph/ctx_architecture（项目智能分析）：通过分析导入关系（import/require），lean-ctx能为你的项目构建一个依赖图。当AI在修改auth.ts时，ctx_graph可以建议它“可能需要同时查看user-service.ts和permissions.ts”，从而实现上下文的智能预加载。
2.3 压缩引擎的科学基础
lean-ctx的压缩不是简单的字符串截短，而是基于信息论和代码特性的智能决策。
- 自适应熵分析（Adaptive Entropy）：它对不同编程语言使用不同的字节对编码（BPE）熵值阈值，并结合Jaccard相似度来识别和过滤高度重复或模板化的代码块（如自动生成的类型定义、大型常量枚举）。Kolmogorov复杂度调整则帮助它判断一段代码是否“简单可描述”。
- 注意力模型（Attention Model）：受Transformer模型中的注意力机制启发，
lean-ctx会对代码的不同部分赋予不同的“重要性权重”。例如，函数定义、类名、错误处理逻辑通常比内部的辅助变量赋值更重要。它采用一种启发式的U型曲线权重分配，并结合代码结构（如处于顶层作用域还是嵌套在深层循环内）来评分。 - TF-IDF代码本（TF-IDF Codebook）：在项目范围内，它使用类似TF-IDF（词频-逆文档频率）的技术来识别“跨文件公共模式”。例如，每个文件都有的相同版权声明、通用的工具函数导入，这些会被识别并在后续传输中大幅压缩或直接引用。
- 信息瓶颈理论（Information Bottleneck）：这是其
task模式的理论基础。它试图在压缩表示（减少Token）和保留与当前任务相关的信息之间找到最优平衡点。AI如果正在修复一个登录bug，那么auth.ts中与密码哈希相关的函数就比与邮件模板相关的函数更重要。
3. 完整安装、配置与集成实战
理论说再多，不如动手装一遍。下面是我在macOS（使用Zsh）和Linux环境下的完整配置流程，涵盖了从安装到与不同编辑器集成的细节。
3.1 基础安装与Shell集成
最推荐的方式是使用官方的一键安装脚本，它兼容性最好。
# 1. 下载并执行安装脚本 curl -fsSL https://leanctx.com/install.sh | sh这个脚本会自动检测你的系统架构和平台，下载对应的预编译二进制文件到~/.local/bin（或/usr/local/bin），并提示你将其加入PATH。
接下来，进行一键式设置。这个命令会做三件大事：配置你的Shell Hook、检测并配置你系统上已安装的AI编辑器、运行健康检查。
# 2. 一键配置（核心步骤） lean-ctx setup执行后，请仔细阅读它的输出。它会告诉你：
- 将在你的
~/.zshrc（或~/.bashrc）中添加哪些内容。 - 检测到了哪些AI编辑器（如Cursor、VS Code），以及将为它们创建或更新哪些配置文件。
- 在修改任何文件前，它都会创建备份（如
~/.zshrc.lean-ctx.bak）。
完成后，务必重启你的终端会话，或者执行source ~/.zshrc来让Shell Hook生效。
验证安装：
# 3. 运行诊断，确保一切正常 lean-ctx doctor这个命令会检查二进制文件、Shell Hook、MCP服务器连接等状态，并给出修复建议。
3.2 与主流AI编辑器集成详解
lean-ctx setup已经为你做了大部分工作，但了解其背后的原理有助于手动排查问题。
Cursor:Cursor原生支持MCP。lean-ctx setup会在~/.cursor/mcp.json中添加一个指向lean-ctx二进制文件的服务器配置。你可以在Cursor的设置中搜索“MCP”来确认。当你在Cursor中让AI执行操作时，它就会优先使用lean-ctx提供的工具。
Claude Code (Claude Desktop):Claude Code也支持MCP。lean-ctx会通过claude mcp命令行工具或直接编辑~/.claude/desktop-config.json来添加服务器。有时Claude Code在首次启动时会覆盖用户配置，因此lean-ctx在它的环境脚本中包含了一个“自愈”逻辑，会尝试重新注入配置。
VS Code with GitHub Copilot:如果你安装了GitHub Copilot插件，lean-ctx会在项目根目录或用户全局目录下的.github/copilot/mcp.json中配置服务器。注意：你需要确保使用的是Copilot的“聊天”功能，并且该功能已启用MCP实验性支持（通常在设置中）。
手动配置（以备不时之需）：如果自动配置失败，你可以手动为上述编辑器创建对应的JSON配置文件，内容基本一致：
{ "mcpServers": { "lean-ctx": { "command": "lean-ctx", // 或 "/full/path/to/lean-ctx" "args": [] } } }对于Windsurf、Zed等编辑器，配置文件路径不同，但结构类似。lean-ctx doctor命令通常会给出正确的路径提示。
3.3 高级配置与模式选择
lean-ctx提供了丰富的配置选项，可以通过环境变量、配置文件(~/.lean-ctx/config.toml)或命令行进行调节。
1. 工具模式选择：根据你使用的大模型上下文大小，可以选择暴露不同数量的工具，以减少描述工具本身所占用的“Schema Tokens”。
- Granular（默认）：暴露全部~46个工具，约消耗15-20K Token来描述。适合Cursor、Claude Code等使用大上下文模型（如Claude 3.5 Sonnet）的场景。
- Lazy：仅暴露9个核心工具（如
ctx_read,ctx_shell,ctx_search）外加一个ctx_discover_tools工具（用于按需动态加载其他工具）。Schema Token降至3-4K。适合在Hermes、Ollama本地模型等上下文较小的环境中使用。通过设置环境变量启用：export LEAN_CTX_LAZY_TOOLS=1。 - Unified（极端优化）：仅暴露5个最通用的工具，Schema Token约2K。设置：
export LEAN_CTX_UNIFIED=1。
2. 规则文件作用域：lean-ctx会为某些编辑器（如Cursor、Claude）生成“规则”文件，指导AI何时使用lean-ctx的工具。默认会同时安装在用户主目录（全局）和当前项目目录下。为了避免重复和节省上下文Token，你可以限制其作用域。
# 只使用全局规则（推荐，避免项目间干扰） lean-ctx config set rules_scope global # 或通过环境变量 export LEAN_CTX_RULES_SCOPE="global"你也可以在项目根目录创建.lean-ctx.toml文件进行项目级覆盖。
3. 缓存与性能调优：缓存是节省Token的重中之重。lean-ctx的缓存默认存储在~/.lean-ctx/cache/。
- 查看缓存状态：
lean-ctx cache status - 清除所有缓存：
lean-ctx cache clear（谨慎使用，会导致后续读取Token上升） - 使特定文件缓存失效：
lean-ctx cache invalidate /path/to/file.rs
4. 安全路径限制：出于安全考虑，lean-ctx默认只允许访问当前项目根目录下的文件。如果你需要让它访问项目外的配置（如全局的.config目录），需要显式允许：
export LCTX_ALLOW_PATH="/home/yourname/.config:/home/yourname/shared"4. 日常使用技巧与避坑指南
安装配置只是开始，如何高效使用才是关键。以下是我在实际开发中总结出的工作流和常见问题解决方案。
4.1 最佳实践工作流
会话开始：使用
ctx_overview开始一个新任务或打开一个新项目时，首先让AI执行ctx_overview。这个工具会分析项目结构、依赖关系，并生成一个极简的“项目地图”，帮助AI快速建立上下文，通常只需几百个Token，却能替代手动发送十几个文件。文件阅读：优先使用
map或signatures模式当AI需要理解一个文件是干什么的，而不是立刻修改它时，明确指定模式：ctx_read -m map src/auth/service.ts。这能立即节省85%以上的Token。如果map模式提供的信息不够（比如需要看函数参数类型），再升级到signatures模式。利用缓存，避免重复全量读取AI助手有时会反复要求“再给我看看那个文件”。由于
ctx_read的full模式带有缓存，第二次及之后的请求成本极低（~13 Token）。因此，不必阻止AI重复读取，缓存机制已经处理了成本问题。善用
ctx_shell处理复杂命令对于需要结合多个命令输出的复杂查询，可以指导AI使用ctx_shell。例如：“请用ctx_shell执行git log --oneline -5和git diff HEAD~5..HEAD --stat，然后总结最近的改动。”定期查看节省报告使用
lean-ctx gain查看漂亮的终端仪表盘，了解哪些命令节省最多，调整使用习惯。lean-ctx gain --live可以开启实时监控模式。
4.2 常见问题与排查实录
即使工具设计得再完善，在实际复杂环境中也会遇到问题。下面是一个我遇到过的典型问题排查表。
| 问题现象 | 可能原因 | 排查与解决步骤 |
|---|---|---|
AI助手完全无法使用lean-ctx的工具 | 1. MCP服务器未正确配置或启动。 2. 编辑器未启用MCP支持。 | 1. 运行lean-ctx doctor，查看MCP服务器状态。2. 检查编辑器对应的配置文件（如 ~/.cursor/mcp.json）是否存在且格式正确。3. 尝试在终端手动启动MCP服务器： lean-ctx mcp，看是否有错误输出。4. 确认你的AI编辑器版本支持MCP，并在设置中已开启相关实验功能。 |
| Shell Hook导致某些命令行为异常或输出乱码 | 1. 命令输出包含lean-ctx无法正确解析的特殊字符或动态内容。2. 管道(` | )或重定向(>`)与Hook冲突。 |
ctx_read读取文件返回空或错误 | 1. 文件路径超出了lean-ctx的安全允许范围。2. 文件权限不足。 3. 缓存损坏。 | 1. 确认文件在当前项目目录下，或已在LCTX_ALLOW_PATH中配置。2. 运行 lean-ctx read /path/to/file --raw查看原始错误信息。3. 尝试清除缓存： lean-ctx cache clear。 |
| Token节省效果不明显 | 1. AI助手没有使用lean-ctx的工具，而是回退到了原生文件读取/命令执行。2. 项目文件本身很小，或命令输出本就简洁。 3. 使用的读取模式不合适（如总是用 full）。 | 1. 在AI对话中，明确要求它使用ctx_read、ctx_shell等工具。例如：“请使用ctx_read -m map查看这个文件。”2. 查看 lean-ctx gain报告，确认哪些操作消耗了主要Token。可能是某个大型日志文件被反复完整读取。3. 检查编辑器的规则文件是否生效，它应该能自动引导AI使用优化工具。 |
更新lean-ctx后Hook失效 | Shell配置文件（如~/.zshrc）中的别名定义未更新。 | 1. 运行lean-ctx update会尝试自动更新Shell配置。2. 如果自动更新失败，手动运行 lean-ctx setup重新配置。3. 最彻底的方法：运行 lean-ctx init --global --dry-run查看它将添加什么，然后手动合并到你的配置中，或直接运行lean-ctx init --global覆盖（建议先备份原配置）。 |
4.3 在Docker或CI环境中的使用
在无交互的CI/CD流水线或Docker容器中，Shell的启动方式不同（通常是bash -c），不会加载~/.bashrc。为了让lean-ctx的Hook生效，需要利用BASH_ENV环境变量。
Dockerfile示例：
# 安装lean-ctx（假设通过curl安装） RUN curl -fsSL https://leanctx.com/install.sh | sh # 运行bootstrap，它会生成一个环境脚本 RUN lean-ctx bootstrap # 设置BASH_ENV，让非交互式bash shell也加载lean-ctx环境 ENV BASH_ENV="/root/.lean-ctx/env.sh" # 后续的RUN命令如果使用bash -c，就会自动加载Hook RUN npm install && npm run buildlean-ctx bootstrap命令会生成一个env.sh脚本，其中包含了必要的Hook和路径设置。通过BASH_ENV指向它，确保了在CI这种非交互式环境中Hook也能被加载。
5. 性能对比、监控与自定义扩展
了解工具的性能边界和如何监控其效果，是将其价值最大化的关键。
5.1 与同类工具对比
在lean-ctx出现前，社区已有一些尝试，如“Rust Token Killer”。以下是核心特性对比，解释了为什么lean-ctx更胜一筹。
| 特性维度 | Rust Token Killer (早期方案) | lean-ctx (当前方案) | 优势解读 |
|---|---|---|---|
| 架构 | 仅Shell Hook | Shell Hook + 持久化MCP服务器 | MCP服务器提供更丰富、更智能的工具集，且进程常驻，避免了频繁启动进程的开销和“EAGAIN”类错误。 |
| 文件读取 | 仅签名模式（正则提取） | 8种智能模式+ 缓存 + 差异对比 | 应对场景更全面。缓存是节省重复读取Token的核心；diff模式对于频繁修改的文件是杀手级功能。 |
| 压缩智能 | 基于固定规则 | 基于信息熵、注意力模型、TF-IDF | 从“规则匹配”升级到“智能分析”，压缩率更高，且能保持信息的有效性。 |
| 跨会话记忆 | 无 | CCP协议支持 | 让AI在多次对话中记住项目关键信息，避免了每次“冷启动”都要重新灌输上下文，从根源上减少Token消耗。 |
| 生态集成 | 支持少数编辑器 | 支持24+种编辑器/AI工具 | 开箱即用的体验更好，覆盖了几乎所有主流AI编程环境。 |
| 可观测性 | 有限 | 完整的仪表盘(gain)、成本估算、基准测试 | 让节省“看得见”，方便量化价值和优化使用习惯。 |
5.2 监控你的Token节省
lean-ctx提供了强大的数据统计功能，让你对节省效果一目了然。
终端仪表盘：运行lean-ctx gain，你会看到一个清晰的ASCII图表，展示总节省Token数、压缩率、估算的美元节省金额，以及按命令分类的节省排行。--live参数可以开启实时刷新模式。
生成节省报告：lean-ctx wrapped命令会生成一个类似“Spotify Wrapped”的趣味年度报告（基于已有数据），非常适合分享或复盘。
项目基准测试：如果你想在引入lean-ctx前后做一个严谨的对比，可以使用基准测试功能。
# 1. 首先，在不启用lean-ctx的情况下，记录一次“典型开发会话”的AI操作。 # 2. 启用lean-ctx后，运行基准测试来模拟相同操作。 lean-ctx benchmark run --scenario “my_typical_session” # 3. 生成对比报告 lean-ctx benchmark report这个报告会详细列出每个操作在压缩前后的Token消耗对比，并给出整体的节省比例。
5.3 自定义压缩模式与规则
虽然lean-ctx内置了90多种模式，但如果你使用的某个内部工具或特定命令的输出格式独特，你可以创建自定义的TOML规则文件。
规则文件位置：~/.lean-ctx/patterns.toml(用户全局) 或./.lean-ctx/patterns.toml(项目局部)。
示例：假设你有一个内部部署工具my-cli list-services，其输出冗长但结构固定。
[[patterns]] name = “my-cli list-services” command_regex = “^my-cli list-services” # 压缩逻辑：只保留状态不是“RUNNING”的服务 compress_script = “”” lines = output.split(‘\n’) filtered = [line for line in lines if ‘RUNNING’ not in line] result = ‘\n’.join(filtered) if len(filtered) < len(lines): result += f’\n[lean-ctx: filtered out {len(lines) - len(filtered)} RUNNING services]’ return result “”” # 优先级：用户自定义规则优先于内置规则 priority = 100编写完规则后，无需重启，lean-ctx会自动加载并应用。你可以用lean-ctx -c “my-cli list-services” --dry-run来测试压缩效果。
5.4 故障恢复与卸载
如果遇到无法解决的问题，或者你想暂时回到原始环境，恢复步骤很简单。
临时禁用：在当前终端会话中，运行lean-ctx-off。这会取消所有别名和函数Hook，所有命令将恢复原始行为。重新启用用lean-ctx-on。
完全卸载：如果你想彻底移除lean-ctx：
- 移除Shell配置：运行
lean-ctx init --global，它会显示出将要添加到你的shell配置文件中的内容块。手动从你的~/.zshrc或~/.bashrc中删除与之对应的整个代码块。 - 移除二进制文件：根据你的安装方式。
- curl安装：通常位于
~/.local/bin/lean-ctx，直接删除。 - Homebrew:
brew uninstall lean-ctx - Cargo:
cargo uninstall lean-ctx - npm:
npm uninstall -g lean-ctx-bin
- curl安装：通常位于
- 移除数据与配置：
rm -rf ~/.lean-ctx(这会删除所有缓存、统计数据和配置文件)。
最后的小建议：lean-ctx是一个正在快速迭代的工具。关注其GitHub仓库的Release页面，定期使用lean-ctx update进行升级，可以获取性能改进、新的压缩模式和Bug修复。这个工具的本质是让你与AI的协作更高效、更经济，把宝贵的Token和注意力都花在创造性的编程工作上，而不是为冗余信息付费。经过一段时间的适应和调优，你会发现它几乎成为了AI编程工作流中一个“无声却不可或缺”的基础设施层。
