【开源发布】Context Engine:解决 AI 助手日志太脏、检索太乱、代码上下文太散的问题！

我开源了一个给 Agent / RAG / AI Coding 用的上下文压缩引擎Context Engine这段时间我做 Agent、RAG 和 AI Coding 相关东西时有一个感受越来越强很多系统不是“模型不够强”而是“喂给模型的上下文太脏、太长、太乱”。比如日志场景里真正的报错可能只占 3 行但前面堆着几百行 heartbeat、poll、retryRAG 场景里检索能召回很多 chunk但相关和不相关内容混在一起模型很容易抓错重点代码修复场景里模型看到的是一堆文件和测试输出但缺少“最小修复上下文”最后就会出现一种很常见的问题不是没信息而是信息密度太低。不是模型不会推理而是上下文质量太差。所以我做了一个项目叫Context Engine。它不是聊天产品也不是又一个 Agent 框架。它更像一个底层的上下文压缩层把原始日志、RAG 检索结果、代码上下文压缩成更适合大模型处理的高信号输入。项目地址https://github.com/melonelish/context-engine这个项目解决什么问题一句话概括把 noisy context 变成 LLM-ready signal。当前它主要处理三类输入1. logs从大量日志里提取likely root causetraceback 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. 直接跑 CLIpython-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 medium3. 作为 MCP 工具接入启动python-m context_engine.mcp_server它会暴露一个工具compress_context适合直接接到 agent workflow 里。它和普通 summarization 有什么不一样这是我比较在意的一点。我不希望它只是“把长文本缩短一点”。我更希望它是task-aware compressionlogs更关注 root cause、traceback、噪声归并rag更关注问题相关性和 evidence packingcode更关注 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 chunkcode failure supporting file irrelevant fileCI现在 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 APIDocker更多 Agent / MCP 接入示例我现在最想收集什么反馈如果你正好在做这些方向Agent workflowRAG 系统AI CodingMCP 工具链上下文工程 / context engineering我最想收集两类反馈1. 哪些真实输入会把它打崩或者压错重点这类反馈最有价值。2. 对logs/rag/code三类场景来说哪一块最值得继续加强我可以据此判断下一轮优先级。最后我现在对这个项目的定义不是“已经完美”而是它已经从想法变成了一个可公开试用、可继续演进的上下文压缩引擎。如果你对这个方向感兴趣欢迎看看仓库也欢迎直接拿真实脏数据来打它https://github.com/melonelish/context-engine