LeanCTX 上下文智能层
在本地筛选、压缩并记忆编码代理的上下文，同时核算令牌成本与结果。
证据显示默认启用项目路径隔离、秘密路径拒绝、工作区信任门、角色权限和本地审计；遥测为选择加入，代理默认关闭且绑定回环，并明确列出更新检查、模型下载及代理数据流，因此敏感数据处理与数据流透明度充分。对 shell、云命令和高风险工具也提供拒绝或角色禁用控制，但 ctx_execute 一经授权即拥有完整用户级 shell 能力，交互式设置可零提示运行，且项目配置、代理和附加组件会扩大攻击面，故最小权限、确认和外部影响未获满分。存在 unwrap、即时停用、内容恢复及快照恢复路径，但没有针对所有配置变更、命令副作用或附加组件安装的统一事务回滚，故回滚为2。依赖审计、cargo deny、校验和与固定版本有说明及工作流佐证，但未提供锁文件、审计报告或当前漏洞清单，且 HuggingFace 模型仅按大小检查，故依赖安全为2。仓库、许可证版权人、安全联系人清晰，但发布者企业身份未经验证且未给出更完整的组织归属，来源归属为2。
README、SECURITY 和测试共同支持本地客户端、HTTP 工具清单、适配器转换、错误解析及可选依赖的明确 ImportError；实时测试还设计了清单漂移门，但需环境变量和可选框架才能运行，故依赖可用性和失败消息为2。自洽性仅为1：README同时出现“79 MCP tools”，对象描述为76，安全文档称29个依赖和有限网络用途，却又描述大量服务器、代理、模型下载及生态功能；“local-only”也需要依赖后文的多项例外才能成立。静态材料未证明这些广泛声明在同一修订中完全同步。
材料针对初次安装、日常编码、记忆、代码理解、多仓库、运维和受监管环境给出具体场景，并覆盖多种代理、模型和SDK，受众与场景充分。能力边界尤其明确：PathJail、角色、ctx_shell与ctx_execute的不同约束、代理MITM性质及非内核沙箱均有说明，故为3。触发和激活有agents-only、wrap、显式代理启用及工作区信任，但onboard可“zero prompts”，透明 shell hook与自动合并配置仍可能使触发时机不够显著，故为2。支持多平台和多种安装渠道，也说明Windows残余风险及容器缓解；但生产TLS、外部模型、可选框架和各包管理器带来环境前提，故环境适配为2。
README有清晰导航、能力分区、快速开始、场景、SDK、故障排查及参考链接，信息架构、安装说明和示例充分。SECURITY详细列出残余风险、缓解措施和受监管配置，因此已知限制为3。完整Apache-2.0正文、版权人与README标识一致，许可证为3。命名整体稳定且客户端测试包含contract_version，但“AI Value Gate/Lean Context”、工具数量76/79及版本示例变化显示术语和清单仍有漂移，故命名稳定性为2。README指向CHANGELOG且安全文档记录版本变更和更新时间，但未提供CHANGELOG内容或明确兼容策略，版本管理为2。安全邮箱、GitHub私密报告、响应目标和版权人明确，但发布者身份未知、总线因子和正式支持主体未展示，维护责任为2。
命令、SDK示例、诊断、仪表盘、恢复句柄和结构化HTTP错误使产出可以直接用于实际工作，输出可用性为3。压缩、缓存、恢复、图搜索、记忆和成本台账相对普通代理工具具有明确增量价值，但提供的代码证据只覆盖Python客户端/适配器而非核心79项能力，故边际价值为2。材料给出50–80%、约13 token、基准工作流及CPAO/Shadow Mode，但没有附上本修订的基准报告或原始结果；安装复杂度、安全治理成本和误压缩代价也未量化，因此成本收益为2。
多项声明指向仓库内安全策略、演示带、参考文档、CI和基准命令，且测试代码具体覆盖HTTP转发、错误解析、适配器和清单一致性，因此可追踪性与跨来源佐证各为2；但未提供核心实现、基准产物、锁文件或CI结果，无法静态闭环验证广泛功能及百分比声明。事实与推断分离仅为1：营销性表述如“definitively a false positive”“never discards”“quality held”“zero config”较绝对，且没有在相邻位置持续区分已测结果、设计目标与路线图推断。
- ctx_execute不受ctx_shell允许列表约束；任何可调用它的代理都具有当前用户权限下的完整shell能力。高风险环境应通过角色禁用它并使用操作系统级沙箱。
- 可选LLM代理会读取请求正文和明文Authorization头。除非确有需要，应保持关闭并仅绑定回环地址。
- HuggingFace嵌入模型下载没有加密哈希固定；受监管环境应从已验证的内部镜像预置模型。
- Windows仍存在PathJail检查到使用的竞态，并依赖用户配置目录的NTFS ACL；共享或高对抗主机应使用容器或虚拟机隔离。
- 不要仅凭README中的50–80%节省、约13 token重读或79项工具声明做采购决策；本次材料未包含对应基准产物、核心实现或执行结果。
这个 Agent 能做什么，适合哪些场景？
LeanCTX 是一个面向 AI 编码代理的本地优先上下文工程层，以单个 Rust 二进制程序提供 MCP 服务器、Shell 钩子、可选请求代理、会话记忆、代码图谱和浏览器仪表盘。它可压缩文件读取、常见开发命令输出以及经代理发送给模型的请求，并将被裁剪内容保存到内容寻址存储中以供恢复。系统通过 Tree-sitter 支持 27 种语言的结构分析，提供 10 种读取模式，并以属性图支持搜索、影响分析和相关文件发现。它还记录令牌、成本、接受结果及 CPAO，提供 Shadow Mode、可验证的节省账本和上下文证明。项目支持 30 多种编码代理，并提供 Python、TypeScript/Node 和 Rust 客户端或压缩 SDK；代码、记忆与默认遥测均留在本地，除非用户明确启用外部能力。
在读取路径中，编码代理通过 ctx_* MCP 工具或 Shell 调用 LeanCTX；lean-ctx read 可按 full、map、signatures、diff、lines:N-M、density:X 等模式读取文件，Shell 钩子则压缩 git、npm、cargo、docker、kubectl、terraform 等命令的输出。Tree-sitter AST、ModePredictor 和 IntentEngine用于结构提取、读取模式选择与任务复杂度分类；被省略的原文进入内容寻址存储，可通过 ctx_expand、ctx_retrieve 或 /v1/references/{id} 恢复。会话记忆、知识图谱和多边属性图保存任务、事实、决策以及代码关系，并支持 lean-ctx graph impact、混合搜索和跨会话恢复。可选的 lean-ctx proxy enable 位于代理与 OpenAI、Anthropic或 Gemini 模型提供方之间，压缩系统提示、历史和工具结果。lean-ctx gain、savings、value-report、shadow 和 Context Manager 仪表盘生成令牌、美元成本、CPAO、质量及基线比较；ctx_proof 与 ctx_verify 提供四层验证和 CI 漂移门禁。它也能通过 ctx_agent、ctx_handoff、.ctxpkg 包、签名快照及 addon 网关支持多代理协作、上下文迁移和外部 MCP 服务接入。
- 每天使用 Cursor、Claude Code 或 Codex，并频繁运行 git、测试和构建命令的开发者，可用混合模式减少重复文件读取和冗长终端输出。
- 维护中大型仓库或 monorepo 的团队，可用 AST 签名、混合搜索、属性图和
graph impact快速定位接口及变更影响范围。 - 需要跨聊天延续长期重构或排障工作的用户，可将任务、事实和决策保存到本地会话记忆及知识图谱中。
- 同时使用 OpenAI、Anthropic 与 Gemini 的团队，可通过本地上下文层保留可移植缓存和记忆，并选择性启用请求代理。
- 需要证明 AI 成本收益的工程负责人，可使用节省账本、CPAO、Shadow Mode、基准报告和实时仪表盘比较令牌消耗与接受结果。
- 运行规划、开发和审查等多代理流程的团队，可用
ctx_agent、ctx_handoff、共享状态、日记和上下文传递包协调交接。
这个 Agent 有哪些优点和局限？
- 一个本地 Rust 二进制程序同时覆盖 MCP 文件读取、Shell 输出压缩、可选请求代理、记忆、图谱和成本观测，减少拼接多套上下文工具的需要。
- 压缩具有明确恢复路径：被裁剪内容进入内容寻址存储，可通过工具、内嵌标记或 HTTP 引用接口取回。
- 兼容 30 多种编码代理，并提供标准 MCP、HTTP
/v1、Python/TypeScript SDK 及 Python/TypeScript/Rust 客户端，模型提供方可在 OpenAI、Anthropic 和 Gemini 之间切换。 - 成本与质量观测较具体，包括实时令牌和美元统计、CPAO、Shadow Mode、可审计事件账本、基准命令与 CI 质量门禁。
- 默认无遥测，记忆、缓存和代码处理以本地为主，并支持
.ctxpkg、签名快照及跨机器或模型迁移。
- 收益依赖代理能否覆盖完整上下文窗口、会话是否长期存活以及提供方的提示缓存计价；文档明确说明不利组合可能只能达到盈亏平衡。
- 小型仓库、很少使用 Shell 的工作流或始终要求原始日志的用户收益较低；虽然可用
--raw绕过压缩，但会削弱采用价值。 - 完整接入会修改代理配置并安装 Shell、MCP、代理钩子和守护进程，团队需要评估这些本地集成对现有开发环境的影响。
- 请求代理、云同步、公共网页读取、addon 安装和模型调用会引入网络或外部服务边界，不再是完全离线流程。
- 部分高级方向仍在路线图中，例如托管的
ctxpkg.com历史注册表、统一团队上下文图和更完整的 OpenTelemetry/Prometheus 导出。
如何安装或部署这个 Agent？
任选一种已记录的安装方式：
curl -fsSL https://leanctx.com/install.sh | sh
brew tap yvgude/lean-ctx && brew install lean-ctx
npm install -g lean-ctx-bin
cargo install lean-ctx
pi install npm:pi-lean-ctx随后为目标代理执行一键配置，例如：
lean-ctx wrap cursor
lean-ctx wrap claude
lean-ctx wrap codex
lean-ctx wrap vscodewrap 会安装 Shell 钩子、注册 MCP 服务器、配置代理钩子、启动守护进程并验证连接。也可运行 lean-ctx onboard 自动连接检测到的工具，或用 lean-ctx setup 进入交互式配置。Windows 源码构建可在克隆仓库后从 PowerShell 执行 ./install.ps1；加 -BuildOnly 可只构建。基础本地使用未注明需要 API 凭据；若启用模型请求代理、云同步、网页读取或外部提供方，则需自行具备相应服务访问条件。
如何使用这个 Agent？
完成包装后，可先运行 lean-ctx doctor 检查连接。典型调用包括：
lean-ctx read src/server.rs -m map
lean-ctx -c "git status"
lean-ctx overview
lean-ctx graph impact src/auth.rs
lean-ctx gain --live
lean-ctx dashboard要压缩发送给模型的每个请求，可执行 lean-ctx proxy enable。要启用节省基线比较，在 ~/.config/lean-ctx/config.toml 中加入 [shadow] 与 enabled = true，使用一段时间后运行 lean-ctx savings 和 lean-ctx shadow --latest。应用集成可启动 lean-ctx serve，再通过 /v1/tools/call 或 lean-ctx-client 调用；只做消息压缩时，可安装 lean-ctx-sdk 并调用 Python 的 compress(messages, model="claude-sonnet-4") 或 TypeScript 的 compress(messages, { model: "gpt-4o" })。
这个 Agent 与同类方案有什么区别？
项目将 LeanCTX定位为可同时处理读取路径与模型请求路径的上下文层，并明确提到与 RTK、Context+、MemGPT 的比较资料。对于 Headroom、Sophon、Repomix、Serena、Mem0、Cognee、Letta 和 Sequential Thinking，LeanCTX 提供 addon 网关，可安装上游 MCP 服务并对其输出继续执行压缩、归档、索引和不可信内容标记。因此这些工具既可作为特定能力的替代方案，也可被纳入 LeanCTX；来源未提供足够数据来断言逐项性能优劣。
常见问题
本地使用是否收费或默认上传遥测？
压缩会不会永久丢失代码或日志？
ctx_expand、ctx_retrieve、内嵌标记和 HTTP 引用接口等恢复路径。不过使用者仍应验证压缩视图是否适合自己的诊断和审计要求。它只支持某一家模型或编辑器吗？
出现压缩问题时能否临时绕过或停用？
lean-ctx -c --raw "git status" 对单条命令禁用压缩，用 lean-ctx-off 停用当前 Shell，并用 lean-ctx doctor --json 生成诊断信息。如何干净移除？
lean-ctx uninstall --dry-run 预览，再用 lean-ctx uninstall 移除进程、钩子、编辑器配置、规则、自动启动项、数据目录及二进制；包管理器安装还需执行对应的 brew、cargo、npm 或 Pi 卸载命令。