我开源了一个给 Agent / RAG / AI Coding 用的上下文压缩引擎：Context Engine

这段时间我做 Agent、RAG 和 AI Coding 相关东西时，有一个感受越来越强：

很多系统不是“模型不够强”，而是“喂给模型的上下文太脏、太长、太乱”。

比如：

• 日志场景里，真正的报错可能只占 3 行，但前面堆着几百行 heartbeat、poll、retry
• RAG 场景里，检索能召回很多 chunk，但相关和不相关内容混在一起，模型很容易抓错重点
• 代码修复场景里，模型看到的是一堆文件和测试输出，但缺少“最小修复上下文”

最后就会出现一种很常见的问题：

不是没信息，而是信息密度太低。
不是模型不会推理，而是上下文质量太差。

所以我做了一个项目，叫Context Engine。

它不是聊天产品，也不是又一个 Agent 框架。
它更像一个底层的上下文压缩层：

把原始日志、RAG 检索结果、代码上下文，压缩成更适合大模型处理的高信号输入。

项目地址：
https://github.com/melonelish/context-engine

这个项目解决什么问题？

一句话概括：

把 noisy context 变成 LLM-ready signal。

当前它主要处理三类输入：

1. logs

从大量日志里提取：

• likely root cause
• traceback tail
• 重复噪声归并结果
• 更适合继续交给模型排障的结构化上下文

2. rag

围绕用户问题，对检索结果做二次整理：

• 区分高信号 chunk 和低信号 chunk
• 不只是保留“检索顺序”，而是更接近“回答顺序”
• 尽量减少模型被偏题 chunk 带偏

3. code

围绕 issue / test failure 整理代码上下文：

• 识别更可能的 hotspot file
• 保留 supporting file
• 输出最小修复上下文
• 把明显无关文件降权

为什么我会做它？

因为我发现很多项目都在解决“生成”，但很少有人认真解决“喂给模型什么”。

但在工程里，真正决定效果的往往是前一层：

• 你给模型的是完整原始日志，还是已经去掉噪声后的 root-cause context
• 你给模型的是所有检索 chunk，还是按问题重新排序后的 evidence
• 你给模型的是整个 repo 片段，还是最可能相关的 2~3 个文件

这层如果做不好，后面的模型再强，也会被浪费。

所以我想把这件事单独抽出来，做成一个可以复用的基础层。

当前版本已经能做什么？

现在这个版本已经不是单纯 demo 了，已经具备这些能力：

• 支持logs/rag/code三种模式
• 支持 CLI
• 支持 MCP 接入
• 返回结构化 success / error envelope
• 有 regression tests
• 有 benchmark 样例
• 有 GitHub Actions CI
• 有输入大小限制和错误提示
• 有 README / CHANGELOG / LICENSE / release assets

现在的定位更像：

一个可以给外部开发者试用和接入验证的 early beta / v0.1.0

不是终极版，但已经不是随手拼出来的原型。

现在怎么用？

1. 安装

建议用虚拟环境：

python-m venv.venv.venv\Scripts\Activate.ps1 python-m pip install-e.[dev,mcp]

2. 直接跑 CLI

python-m context_engine.cli--mode logs--input examples/logs/sample.log--budget medium python-m context_engine.cli--mode rag--input examples/rag/sample.json--budget medium python-m context_engine.cli--mode code--input examples/code/sample.json--budget medium

3. 作为 MCP 工具接入

启动：

python-m context_engine.mcp_server

它会暴露一个工具：

• compress_context

适合直接接到 agent workflow 里。

它和普通 summarization 有什么不一样？

这是我比较在意的一点。

我不希望它只是“把长文本缩短一点”。

我更希望它是task-aware compression：

• logs更关注 root cause、traceback、噪声归并
• rag更关注问题相关性和 evidence packing
• code更关注 issue、failure signal、hotspot file、supporting file

也就是说，它压缩的不是“字数”，而是“任务无关信息”。

我做了哪些工程化处理？

为了让它更接近可接入的基础设施，而不是一个展示项目，我这几轮主要做了这些事：

输入与错误处理统一

CLI 和 MCP 现在都走统一 request builder，不是两套逻辑。

结构化错误返回

失败时不是裸 traceback，而是：

{"ok":false,"error":{"error_code":"invalid_field","message":"...","hint":"..."}}

输入大小保护

当前内置保护包括：

• 最大文本：200000 字符
• 最大列表项：64
• 最大文件：2000000 字节

回归测试

我补了更脏的数据样例，不只是 happy path。

例如：

• 混合噪声日志
• 偏题 RAG chunk
• code failure + supporting file + irrelevant file

CI

现在 push / PR 都能自动跑测试。

当前我最满意的地方

如果说这版最让我满意的地方，不是“它功能很多”，而是这几个点开始有基础设施味道了：

• 有统一接口
• 有错误约束
• 有测试
• 有 CI
• 有边界说明
• 有发布文案
• 有 benchmark

也就是说，它开始像一个“别人可以试着接入”的项目，而不只是“我本地能跑”的项目。

当前还不够好的地方

我也不想把它说得太满，下面这些问题我自己是清楚的：

1. RAG 排序还是启发式

现在还不是 embedding-aware rerank，更多是规则和特征打分。

2. Code 排序还是 lexical

虽然比最初版本强了不少，但还没有真正做到调用链、依赖图、符号级关联。

3. Benchmark 还不够大

现在足够说明方向，但还不够支撑“通用基础设施已经验证完毕”这种结论。

4. 输入类型还不够广

目前重点是logs/rag/code，还没扩到 PDF、Word、HTML、URL 抓取等更复杂输入。

后面我准备怎么继续做？

如果这个方向继续推进，后面我会重点补这几条线：

压缩效果继续升级

• embedding / rerank 驱动的 RAG 排序
• 更强的 code hotspot 识别
• 更稳的 logs root-cause extraction

工程稳定性继续升级

• 更细的错误码体系
• 更强的输入验证
• 更多回归样本和 golden cases
• 更细的 benchmark

接入形态继续升级

• Python API 文档
• HTTP API
• Docker
• 更多 Agent / MCP 接入示例

我现在最想收集什么反馈？

如果你正好在做这些方向：

• Agent workflow
• RAG 系统
• AI Coding
• MCP 工具链
• 上下文工程 / context engineering

我最想收集两类反馈：

1. 哪些真实输入会把它打崩，或者压错重点？

这类反馈最有价值。

2. 对logs/rag/code三类场景来说，哪一块最值得继续加强？

我可以据此判断下一轮优先级。

最后

我现在对这个项目的定义不是“已经完美”，而是：

它已经从想法，变成了一个可公开试用、可继续演进的上下文压缩引擎。

如果你对这个方向感兴趣，欢迎看看仓库，也欢迎直接拿真实脏数据来打它：

https://github.com/melonelish/context-engine