你让 AI 编程助手检查一个项目，它可能反复读取同一份文件，把整段聊天记录和冗长的命令输出一遍遍交给模型。结果是：真正有用的代码没增加，发送的文字却越来越多；敏感资料能否外发，也缺少一道清楚的关口。LeanCTX 想做的，就是在 Agent、本地工具与模型之间加一层“值班编辑”：先决定该看什么、记住什么，再压缩需要外发的内容。
这是本刊继 7 月 23 日后再次关注同一项目。本期更值得看的，是它试图用一个本地 Rust 二进制统一管理读取、记忆、权限和成本。二进制是编译后可直接运行的程序；Rust 是常用于系统工具的语言。以下功能与效果均来自项目方 yvgude/lean-ctx，目前没有外部测评或第三方基准交叉验证。
先筛选，再把材料交给模型
LeanCTX 把“上下文工程”从 Agent 中抽了出来。上下文工程，就是安排模型这次任务能看到哪些指令、文件和工具结果。它提供 10 种文件读取模式：既能读取全文，也能只给出代码结构、函数签名、指定行或经过筛选的内容。思路类似先看目录和摘要，发现关键章节后再展开正文。
项目还称，它会用 Tree-sitter AST——按代码语法结构生成的分析结果——理解 27 种编程语言，并针对 git、npm、cargo、docker、kubectl、terraform 等命令压缩输出。被裁掉或截短的内容不会直接消失，而是进入本地内容存储，并留下可再次取回的标记。换句话说，Agent 先拿精简版，确有需要时再调回原文。
可选的本地代理还会压缩发给模型的整个请求，包括 system prompt（规定模型行为的系统指令）、聊天历史和工具结果。项目方称这种做法兼容 prompt cache，即模型服务对重复提示内容的缓存机制。不过，“兼容”目前仍是项目自述，材料没有给出逐个平台的验证结果。
记忆、权限和账本放在一起
普通聊天结束后，上下文往往随会话重置。LeanCTX 则提供可跨聊天保存的 session memory，把任务、事实和决定留在本地，并允许导出为 .ctxpkg，在机器或模型供应商之间迁移。项目方称，用户可以在 OpenAI、Anthropic、Gemini 等服务之间切换，而不必把这部分记忆锁在单一供应商处。
它也把上下文当成一种有预算的资源。token 是模型切分和计量文字的基本单位，可能是一个字、词的一部分或标点；发送得越多，通常占用的计算与调用额度也越多。LeanCTX 提供实时 dashboard、每个 Agent 的预算与限流策略，以及带签名、可验证的节省账本。这个账本能核对项目记录的计算，却不能自动证明压缩后任务质量没有下降。
为什么现在值得看
它切中了三个常被分开处理的问题：上下文膨胀、资料外泄和操作权限。LeanCTX 的“本地优先”意味着主要处理和状态留在用户机器上，只把必要材料交给外部模型。这样一来，减少 token、控制 Agent 能碰什么，以及保留长期记忆，都能在同一层处理。
项目方宣称，它可减少 60%–90% 的 token；重复读取文件可从约 2000 tokens 降至约 13 tokens，原始 git status 输出可从约 800 tokens 压至约 120 tokens。这里要谨慎：60%–90% 有时被描述为总体用量，有时只指文件读取与命令输出；约 13 tokens 也只是缓存后的重复读取，不能代表首次读取或一次完整请求的成本。
局限与未知
- 这些数字没有披露测试任务、样本量、模型、计费口径、质量损失和完整对照条件，不能视为普遍效果。
- 项目称可用一条
lean-ctx setup命令接入 Cursor、Claude Code、Copilot、Windsurf、Codex、Gemini 等 30 多种 Agent，但兼容性仍需逐项实测。 - “本地优先”不等于模型推理也在本地；可选代理仍会把压缩后的请求交给模型服务，具体隐私边界取决于实际配置与调用路径。