Distill：为 AI Agent 打造的记忆可靠性层

！Distill 架构图 图1：Distill 核心架构 — 作为上下文工程栈的中间层，连接 RAG/工具/记忆与 LLM

想象一下：你是一位急诊室医生，每天轮班换人，上一班的医生什么都没交代就下班了。你要重新了解所有病人的病史、用药禁忌、主治医生的偏好——但外面排着长队，容不得你慢慢问。这就是当前 AI Agent 的真实处境：每次新建会话，模型就像失忆一样从零开始。

Siddhant Khare 花了两年时间构建 Agent 基础设施，他发现了一个被忽视的根本问题：Agent 忘记的不只是事实，还有事实的版本和优先级。当上下文跨越多个会话积累下来，30%~40% 是语义重复的信息，而矛盾的信息并存，没有人告诉模型哪条是最新的。压缩工具能减少 token，但解决不了"记什么"和"谁更重要"的问题。

他开源的 Distill 就是对这个问题的系统性回答：一个上下文智能层，通过持久化记忆、去重、冲突检测和分层衰减，让 Agent 在多会话中真正做到"记住重要的"。核心承诺是：零 LLM 调用、确定性行为、约 12ms 延迟。

不是 RAG，是记忆操作系统

很多人把 Distill 理解为一个高级 RAG 系统——这个认知偏差恰恰是它要解决的核心矛盾。RAG（检索增强生成）做的是"在推理时从外部找答案"，而 Distill 做的是"在写入时管理记忆的生命周期"。

两者的根本区别在于控制权归属。RAG 的记忆由检索算法决定，什么时候保留、什么时候淘汰、哪条优先，全靠向量相似度这个单一信号。Distill 则把记忆管理权还给了开发者：

• 敏感度标签（Sensitivity Tagging）：记忆可以被打上 auth、security、preference 等标签，不同任务、不同 Agent 可以按标签召回相关记忆，而不是每次都把全部记忆塞进上下文
• 写入时去重（Write-time Deduplication）：记忆写入时就检查是否已有相似记录，而不是查完再合并，从源头避免重复存储
• 冲突检测（Conflict Detection）：余弦相似度在 0.15 以内视为重复直接合并，在 0.15~0.35 之间的则标记为潜在冲突，明确告知开发者存在矛盾
• 分层衰减（Hierarchical Decay）：历史对话按轮次老化，逐步压缩，从 extractive（抽取关键句）到 placeholder（用摘要替代细节）再到完全淘汰，信号密度始终保持高位

这个设计哲学用一个比喻来说就是：RAG 是图书馆的检索系统，Distill 是图书馆管理员。管理员知道哪些书重要、哪些已经过时、哪些内容互相矛盾——而不只是帮你找到书。

核心技术栈：从向量数据库到确定性算法

Distill 采用纯 Go 语言开发，目标平台是生产级 AI 基础设施。选择 Go 的核心理由是：Goroutine 的并发模型天然适合高吞吐的向量检索和管道处理，而静态二进制意味着部署极度简单（一个容器镜像，不需要运行时依赖）。

依赖的外部系统主要是两类：

向量数据库：支持 Pinecone 和 Qdrant 两种主流选择。向量检索是 Distill 去重 pipeline 的第一步——Over-fetch 50 条相关记录，再通过聚类和 MMR（最大边际相关）重排选出 8 条代表性结果。这个流程不需要 LLM，是纯算法驱动的。

嵌入模型：Distill 抽象了一个嵌入接口层，支持 OpenAI、Cohere 和 Ollama 三种后端。自托管场景下可以直接用 Ollama 跑本地模型，完全不依赖外部 API。

存储层使用 SQLite（modernc.org/sqlite），适合单机部署；如果需要分布式，可以用 Redis 作为缓存层。架构上高度解耦，每个功能模块（memory、dedup、compress、cache、embedding、graph）都是独立包，可以按需组合。

管道设计是整个系统的核心抽象。POST /v1/pipeline 接受原始文本，依次经过以下阶段：

写入（Write） → Remember → Deduplicate → Compress → Cache
读取（Read） → Cache → Recall（相关性召回）

每个阶段都是可插拔的，开发者可以只使用其中一部分。例如，只用 memory 模块做会话持久化，不用 dedup 或 compress。

MCP 协议：让 Claude Desktop 也记住你

Distill 最实用的特性之一是 MCP（Model Context Protocol）Server 实现。通过 distill mcp --memory --session 启动，Claude Desktop 可以直接调用 Distill 的记忆 API，实现跨会话的持久化。

这解决了一个很痛的场景：开发者用 Claude Code 处理一个多日的长项目，每次对话都要重新交代背景。用 Distill MCP 之后，Claude 可以直接查询"这个项目的认证方案是什么"，Distill 返回带敏感度标签的相关记忆，Claude 无需重复上下文。

MCP Server 还支持向量数据库模式（--vectordb），检索结果通过 Pinecone/Qdrant 的语义相似度排序，结合 Distill 的冲突检测和敏感度标签，召回质量远超朴素的向量检索。

部署：5 分钟内跑起来

Distill 的部署友好度在同类工具中属于第一梯队。多阶段 Dockerfile 产出一个约 15MB 的 Alpine 镜像，docker-compose.yml 甚至内置了 Qdrant 向量数据库支持，一行命令同时启动 Distill API 和向量存储。

API 本身是 REST 风格（OpenAPI 规范在 cmd/openapi.yaml），对于 Go 开发者，cmd 目录下有完整的 CLI 实现，直接 import github.com/Siddhant-K-code/distill 即可在代码中调用。

无状态 API 设计意味着可以水平扩展，配合 Kubernetes 的 HPA（Horizontal Pod Autoscaler）可以根据请求量自动扩缩容。内置 Prometheus metrics 端点（/metrics），开箱即用地接入 Grafana 监控。

硬件需求极低：不需要 GPU，普通 256MB RAM 的实例即可运行（Go 编译后的二进制本身约 15MB）。唯一的高要求是向量数据库——如果用 Pinecone 云服务则无本地硬件需求，用 Qdrant 自托管建议 2GB+ RAM。

局限与争议：什么 Distill 做不了

Distill 不是万能药。几个明显的局限需要正视：

向量检索的质量依赖嵌入模型：如果嵌入模型对特定领域（医疗、法律、金融）的语义理解不佳，去重和聚类的效果都会打折扣。去重 pipeline 的 Over-fetch → Cluster → MMR 流程完全基于向量相似度，没有 LLM 的语义判断兜底。

冲突检测的阈值是经验值：0.15/0.35 的余弦相似度阈值对不同类型的知识库效果差异很大。作者在 FAQ 中承认"这需要根据你的数据集调参"，没有给出通用的最优解。

多 Agent 共享记忆的并发安全：Distill 的记忆 API 目前是单租户设计，多个 Agent 并发写入同一会话时的冲突处理文档不充分，生产环境需要额外关注。

压缩策略依赖 extractive 算法：distill 不使用生成式摘要（因为那需要 LLM 调用），extractive 压缩在处理高度结构化文本（代码、JSON、日志）时效果较好，但自然语言连贯性可能受损。

行业意义：上下文工程的新范式

Distill 背后代表的是"上下文工程"（Context Engineering）这一新兴领域。作者 Siddhant Khare 在《The Agentic Engineering Guide》中系统阐述了这个概念：AI Agent 的可靠性问题不只是模型能力的问题，更是上下文管理的问题。

从 GitHub 的增长曲线看，Distill 的 stars 增长符合一个优质工具的典型模式：前期缓慢积累（2023 年发布），中期被 Agent 开发者社区认可后加速（2024-2025），最近随着 Claude MCP 和 OpenAI Agents SDK 的火热进入快速增长期。17 个 topic 覆盖了 AI agents、context-optimization、prompt-caching、deduplication、RAG 等多个相关领域，说明这个项目正在成为 Agent 基础设施栈的枢纽节点。

对于开发者而言，Distill 的价值在于它把"记忆管理"这个问题从 prompt engineering 层抽离出来，用工程化的手段解决。这让 Agent 开发者可以专注于业务逻辑，而不是每次都重新发明上下文管理的轮子。