Why not just grep?
grep finds text. LeanCTX finds the right symbols, ranks them by relevance, and returns budgeted, structural context instead of 500 raw matches you still have to read and filter.
诚实对比
您已经拥有工具了。 这就是区别所在。
压缩工具缩小通过线路发送的数据量。LeanCTX 也做到了这一点——它不仅决定了最初读取什么，还对其进行保护、记忆和证明。我们将直观地查看它的优势、相同点以及您根本不需要使用的情况。
并列对比
您的代理 有与没有的对比。
相同的 Agent，相同的仓库。唯一的变量是它们之间的层级。
| Feature | 无工具 | 手动规则 | LeanCTX |
|---|---|---|---|
| Token 节省量 | 无 | 低（静态规则） | 60–95%（缓存：99%） |
| 设置难度 | 无 | 每个项目手动配置 | 一键式命令 |
| Agent 支持 | 不适用 | 仅支持一个 Agent | 29+ Agents |
| Caching | 无 | 无 | 自动 + 增量 |
| Shell 压缩 | 无 | 无 | 95+ 模式 |
| 代码分析 | 无 | 无 | Tree-sitter AST |
| 维护 | 无 | 手动更新 | 自动 |
| 安全与治理 | 无强制执行 | 基础文件ACL | 符合OWASP：PathJail、shell白名单、密钥脱敏、OS沙箱代码执行(ctx_execute)、审计跟踪 |
| Compliance & Evidence | Screenshots | 手动证据收集 | 签名证据包 + 离线leanctx-verify，覆盖欧盟AI法案 / ISO 42001 / SOC 2，CGB + 策略覆盖 |
| SDK与可扩展性 | 无 | 定制粘合代码 | Python + TypeScript SDKs (14检查符合性)，/v1 OpenAPI + 能力，ctx_tools网关，WASM和插件扩展 |
The cached figure (99%) is a repeat read served from cache at ~13 tokens; a first read never returns more tokens than the raw file, and every saving is measured net of injection, so the number reconciles to your provider bill.
Context engineering isn't compression. It's what decides what gets read.
对比替代方案
LeanCTX 与其他工具的比较 其他工具
按功能逐一与 RTK、Context+、MemGPT/Letta 和 Headroom 进行比较，这些是引用最频繁的替代方案。基于事实，来源于其公开文档。
| Feature | RTK | Context+ | MemGPT / Letta | Headroom | LeanCTX |
|---|---|---|---|---|---|
| 读取模式 | 单模式 | 基础过滤 | 不适用（侧重内存） | 读取后压缩 | 10 种模式（自动、映射、签名、差异、熵...） |
| Shell 压缩 | 否 | 否 | 否 | 否 | 95+ 模式，自动检测 |
| 会话内存 | 基础状态 | 对话历史 | 核心功能（分层记忆） | 带去重交叉代理存储 | 情景式 + 过程式 + 知识图谱 |
| Multi-Agent | 否 | 否 | 有限（单代理焦点） | 共享存储 | 交接、共享会话、上下文总线 |
| 代码图 / AST | 基础索引 | 否 | 否 | 否 | Tree-sitter AST，26 种语言，符号解析 |
| Governance & Budgets | 否 | 否 | 否 | 否 | 基于角色的预算、SLO和审计跟踪 |
| Local-First / Privacy | 依赖云端 | 本地 | 基于服务器 | Python包 + 代理 | 100% 本地，零遥测 |
| MCP 工具 | 有限 | 无 MCP | 无 MCP | 封装外部工具 | 81 个粒度化的 MCP 工具 |
| Security Hardening | None | None | Basic auth | None | Sandboxing, signed bundles, audit reports |
基于截至 2026 年 6 月公开可用的文档和源代码。RTK (github.com/rtk-ai/rtk)，Context+ (github.com/ForLoopCodes/contextplus)，MemGPT/Letta (arxiv.org/abs/2310.08560)，Headroom (github.com/chopratejas/headroom)。所有工具都解决了实际问题。LeanCTX 仅在一个二进制文件中覆盖了更多层次的上下文问题。
与压缩层对比
压缩缩小了已读取的内容。 上下文工程决定了什么内容被读取。
像 Headroom 这样的工具是在传输线上压缩请求。LeanCTX 本身就提供了这一层——一个可选的本地代理可以压缩所有请求，在不破坏 prompt-cache 的情况下——并且更深入一层，直接作用于源头：它决定了什么内容是否会被读取。与 Headroom 兼容，但您通常不需要额外的上层代理。这是真实的区别。
| Dimension | 压缩层（例如 Headroom） | LeanCTX |
|---|---|---|
| 所在位置 | 消息路径：压缩代理已读取的内容 | 源头：决定什么内容以及如何读取（10 种模式，意图路由，~13 个 token 缓存重读） |
| Memory | 带去重的跨代理存储 | 持久知识：属性图、会话、交接、证据账本 |
| Governance | — | PathJail、shell 白名单、秘密脱敏、预算、注入检测 |
| 证明 | 统计端点 | Ed25519签名，哈希链账本 + 可复现基准 |
| 可逆性 | 参考检索存储 | 也支持可逆：所有原始数据都得以保留 ctx_retrieve 之外 |
| Form | Python 包 + 代理 | 一个 Rust 二进制文件，自动检测 30+ 工具，零配置 |
注意：一些第三方比较表将 lean-ctx 列为“可逆性：否”；这是不正确的。LeanCTX 中每次压缩读取都会在本地存档并通过 ctx_retrieve 检索。压缩是 LeanCTX 的五个子系统之一。这两个工具甚至可以一起运行；Headroom 将 lean-ctx 列为兼容的上下文工具。
为什么不直接…
你的堆栈已经做了一些类似的事情。 但它没有做到这些。
LeanCTX 不会取代 grep 或你的编辑器。它是决定哪些内容值得 AI 注意力的层级。
Why not just read the files?
A raw read dumps 4,200 tokens when ~920 carry the signal. LeanCTX keeps the signal and drops the noise, and a cached re-read costs about 13 tokens instead of the whole file again.
Why not just compact more often?
Compaction throws away history you might still need. With LeanCTX there's never a dead end: every original is archived on disk and your agent retrieves it on demand. Nothing is silently lost.
Why not another MCP server?
Most MCP servers add tool-definition overhead and hand back raw output. LeanCTX is a full cognitive context layer: caching, persistent memory, shell hooks, and governance, all in one local binary.
最佳适用场景
当使用 lean-ctx 时 优势点
LeanCTX 在以下场景中提供最大的价值。
大型代码库
对于包含数百甚至数千个文件的项目，益处最大。需要管理的上下文越多，节省的成本就越大。
多智能体工作流
当多个 AI 智能体处理同一个项目时，LeanCTX 为它们提供了一个共享的大脑：为每个智能体提供一致、受控的上下文。
迭代开发
长时间的编码会重复读取文件，这会击中缓存——重新读取仅消耗约 13 个 tokens，而不是数千个。
透明度
何时需要 无需使用
我们相信诚实的工具。LeanCTX 专为拥有庞大代码库的项目设计——而非所有项目。
并非总是必需
- 单文件脚本或小型实用程序
- 少于 50 个文件的项目
- 没有文件上下文的一次性提示
在这些情况下，引入上下文层的开销是不合理的。当您的项目增长、上下文管理成为瓶颈时，LeanCTX 才真正发挥作用。
比较问题解答。 answered.
Straight answers about where LeanCTX fits and what makes it different.
手动提示工程需要手工构建每个上下文窗口。LeanCTX通过10种读取模式、AST感知压缩和会话内存实现自动化，无需人工干预即可节省88%+的token。
LeanCTX是一个完整的认知上下文层，而不仅仅是一个普通的MCP服务器：包括CLI集成、shell钩子、81个MCP工具、持久内存、代码智能图和带有角色及预算的治理层。
是的。LeanCTX 支持包括 Cursor、Claude Code、GitHub Copilot、Windsurf、Gemini CLI、Codex 和 JetBrains IDEs 在内的 30 多个 AI 工具。运行 lean-ctx setup 可自动配置。
像 Headroom 这样的工具是在传输线上压缩请求——即代理层。LeanCTX 本身就提供了这一层：一个可选的本地代理（lean-ctx proxy enable）可以压缩所有请求——系统提示、历史记录和工具结果——在不破坏 prompt-cache 的情况下，并计量实际节省的成本，因此您通常不需要额外的请求压缩代理。而 LeanCTX 更深入一层，直接作用于源头：它决定了什么内容首先被读取（10 种读取模式，~13 个 token 缓存重读），记住跨会话的知识，保护文件和 shell 访问，并在可验证的账本中记录每一次保存。压缩——无论是读取侧还是传输线侧——只是其五个子系统之一，并且是完全可逆的：每一个原始数据都可以通过一个 ctx_retrieve 恢复。
是的。每次压缩读取都会在本地存档，并通过 ctx_retrieve 按需检索完整的原始内容。没有任何信息会静默丢失；甚至 LeanCTX 会告诉您的代理何时请求完整内容。
这些功能让您的 AI 供应商记住您的公司——您标记它，在线程中跟进，它就会建立记忆。但这种记忆存在于它们的黑箱中：您无法看到它的位置、移动它或更换其底层的模型。这是一种上下文登录，而不是模型登录——最终您只是租回了属于自己的公司知识。LeanCTX 将护城河保留在您的一方：会话、知识图谱和可移植的 .ctxpkg 包都保持本地化和可检查性，并且对 OpenAI、Anthropic 和 Gemini 等模型是无关的。采用与代理作为队友相同的流程；您掌握着上下文。