Khoj

Khoj 是由 Debanjum Singh Solanky 与 Saba Imran 发起、以 khoj-ai 组织维护的开源“个人 AI 第二大脑”，核心定位是“一个自托管、模型不锁定、把语义搜索、文档对话、自定义 Agent、定时自动化与长期记忆装进同一套 Python 进程的个人知识中枢——数据与索引全部留在你自己的机器上，对话模型可以是本地 Ollama、也可以是任意 OpenAI 兼容端点，不替你决策、不替你写作，只把你散落在笔记、PDF、Notion、GitHub 里的上下文，变成一套随时可追问、可审计、可离线的检索与对话基础设施”。它不满足于做一个“更聪明的搜索框”，而是把语义搜索、多模型对话、自定义 Agent、自动化任务、长期记忆（Muninn）、七端客户端、文档索引流水线整合进一个以 Django + FastAPI + Postgres/pgvector 为骨架的单体后端中，采用 AGPL-3.0 许可，Docker Compose 一条命令拉起，pip install 'khoj[local]' 亦可在嵌入式模式下跑起来。截至 2026 年，项目已积累约 3.7 万—3.8 万 GitHub Star，累计 5,000 余次提交，但云服务已于 2026 年 4 月 15 日关停，主仓库自 2026 年 8 月起无新提交，最新版本仍停留在 2.0.0-beta.28（2026-03-26）。这意味着：它是一个功能完整、社区认可度极高、但处于自托管“冻结维护”状态的开源项目，适合作为个人知识基础设施长期使用与自行修补，不适合期待频繁功能迭代或商业支持的场景。

一、Khoj 是什么

Khoj 的起点远早于这一轮大模型热潮。它于 2021 年 4 月作为一个“改进文档搜索的实验工具”起步，最初的内核就是语义检索；2023 年进入 Y Combinator S23 批次后，逐步扩展为覆盖文档索引、多模型对话、Agent 与自动化的“个人 AI 第二大脑”。它和市面上大多数“知识库问答”工具有一个根本区别：Khoj 把“个人”作为第一架构假设。它的权限模型只有两个隔离维度——用户和 Agent，没有文档级 ACL，也没有 workspace 或知识库实体。这不是能力缺失，而是一种明确的设计选择：“这份笔记是我的，不是你的”。在个人自托管场景下，这种设计干净、够用，甚至比多租户系统更不容易出错；但如果你需要的是一批合同由法务和销售按角色分权查看，Khoj 没有对应机制。

架构上，Khoj 采用双框架单体后端：FastAPI 承载 API 路由与流式对话，Django ORM 负责数据库管理与 Admin，二者跑在同一个 Python 进程中，共享一个 Postgres + pgvector 实例。这种“一个进程、一个数据库”的形态，与它“自托管、零外部消息队列、零额外运维组件”的定位是自洽的。索引层把文档切块后写入 Entry 表，每条记录包含原文、编译文本、嵌入向量与来源哈希；对话层通过适配器模式访问数据，Agent 和定时自动化在同一个进程内调度。在此基础上，Khoj 在 2026 年 1 月并入了一套长期记忆机制 Muninn：UserMemory 表以“每条记忆一行、带 pgvector 嵌入”的形式，在每一轮非自动化对话结束后提取关于用户的事实，并在下一轮按“最近 7 天中的 10 条 + 余弦最近的 10 条”合并召回，以带日期的列表注入上下文，模型被明确告知“不相关时忽略”。

二、Khoj 能做什么

语义搜索与文档索引——不是关键词匹配，而是跨格式的向量检索。Khoj 支持 Markdown、Org-mode、PDF、纯文本、DOCX、Notion、GitHub 仓库和图片（通过 OCR 抽取文字）等来源，把文档切块后写入 pgvector，用双编码器生成嵌入，检索时以 top_k=10 召回、默认返回 5 条，相似度阈值 0.18；分块大小 256 token、重叠 0，切分优先级为“段落 > 句子 > 词 > 字符”。图片检索依赖 rapidocr_onnxruntime 做 OCR，抽不到文字的文件不会被索引——这是 Khoj 在“多模态”上的真实边界，不要把它当成视觉理解。

多模型对话——对话模型不锁定，自托管下反而比云版更自由。Khoj 支持 OpenAI、Anthropic、Google 原生模型，也支持通过任意 OpenAI 兼容端点接入 Ollama、LM Studio、vLLM、LiteLLM、OpenRouter 等本地或第三方服务；向量模型可以是任意 sentence-transformers 模型或远程 API，默认 thenlper/gte-small，重排（cross-encoder）默认关闭，只有显式请求或另行配置推理服务时才启用。在自托管模式下，索引、嵌入和对话都可以在完全离线的环境中完成——官方镜像使用 CPU 版 torch，本地大模型由宿主机上的 Ollama/vLLM 提供。

自定义 Agent 与定时自动化——不是一次性问答，而是可复用的“角色 + 知识 + 工具”组合。Khoj 允许为 Agent 挂载自定义知识、人格设定、对话模型和工具集，使其承担特定角色；自动化（Automate）则可以把重复性研究任务变成定时运行的工作流，例如生成个性化简报、监控特定主题、自动分析文档。这是 Khoj 在 2024 年下半年之后的技术重心，也是它从“文档问答”向“个人 AI 工作流”延伸的关键一步。

长期记忆 Muninn——跨会话的事实记忆，有召回也有删除。每次非自动化对话结束后，后台任务把最近两轮对话和本轮召回的记忆交给一个名为 “Muninn” 的提取器，由它输出需要 create 的事实列表和需要 delete 的记忆 ID；创建时用搜索模型嵌入写入，删除为硬删除。记忆的作用域按 用户 + Agent 双重轴控制：自定义 Agent 下保存的事实对该 Agent 和默认 Agent 可见，但对其他自定义 Agent 不可见；默认 Agent 下保存的事实 agent=NULL，仅默认 Agent 可见。记忆功能有两道开关：服务端模式（disabled / default-off / default-on）和每用户开关，任意组合都有测试覆盖。Muninn 的弱点也很清楚：提取器能看到的“已有事实”只是本轮召回集合，而不是全量记忆库，因此它无法删除一条本轮没有被召回的记忆；表中也没有索引声明在向量列上，余弦排序在 ORM 层是全扫描。

七端客户端——同一个后端，多个入口。Khoj 提供 Web、Obsidian 插件、Emacs 包、桌面应用（macOS/Windows/Linux）、手机应用、WhatsApp 以及 Discord 入口，这在开源个人知识管理项目中几乎没有对手。Emacs 和 Org-mode 这条线尤其值得注意：用户基数不大，但忠诚度极高，而大多数商业产品完全忽略这批人；Khoj 认真服务了这个群体，也因此获得了最早期的一批硬核用户。代价同样直接：六个客户端意味着六份持续维护成本，团队在关停公告中把 “multiple (6!) clients” 明确列为项目难以为继的原因之一。

数据源与索引流水线——覆盖面宽，但每条源都是手搓的。Markdown、Org-mode、纯文本、DOCX、PDF、Notion、GitHub 以及图片 OCR，基本覆盖了个人知识工作者的长尾格式。但 GitHub 集成官方自己标注为 “Unmaintained”，文档中明确写“正在考虑废弃”；DOCX 虽然能处理，但文档里几乎不提；扫描版 PDF 的上限完全取决于 OCR 质量。官方关停公告里那句 “hand-building data integrations was going to be a long tail of effort”，与源码目录中一个源对应一个独立处理器的结构完全对得上——每接一个来源，就是一份长期维护成本。

三、Khoj 适合谁用

想要一个完全自托管、数据不出机器的个人知识库的用户。Khoj 的索引、嵌入、对话和记忆都可以在本地完成；自托管模式下你甚至可以完全不配置任何云模型，用 Ollama 加本地 sentence-transformers 跑通整条链路。对于“笔记里有客户合同、私人日记、未发表研究”的人来说，这是决定性的。

笔记散落在 Obsidian、Org-mode、Markdown、PDF 和 Notion 里、需要在同一个入口追问的人。Khoj 的索引层把这些来源统一成可检索的 Entry，对话层让问题跨源召回，而你不需要把笔记迁移到另一个“知识库系统”里。尤其是 Obsidian 和 Emacs 用户，Khoj 提供了官方插件/包级别的集成，而不是一个需要手动导出再导入的旁路工具。

想用自定义 Agent 和定时自动化把重复研究“外包”给自己 AI 的人。给 Agent 挂上特定知识源和人格，再挂一个定时触发，就可以把“每周一早上汇总某个领域的新动态”“每天检查某个文件夹里的文档并生成摘要”变成后台任务。这不是“AI 替你做决定”，而是 AI 替你做重复动作。

对模型选择有偏好、不想被单一厂商锁定的开发者。Khoj 的对话模型和嵌入模型都可以替换；你可以今天用 Claude，明天切到 Ollama 上的 Llama，而索引和记忆的向量空间保持可比（Muninn 的记忆嵌入与文档嵌入来自同一个搜索模型）。

需要 Agent 持久化记忆、但不想引入独立记忆中间件的自托管用户。Muninn 把“跨会话事实记忆”做成了同一张 Postgres 表加一个后台提取任务，没有额外的消息队列或记忆数据库。对于已经在跑 Postgres 的个人实例来说，这是最低摩擦的持久记忆方案。

需要明确的是它不适合谁。 如果你期待的是一个活跃维护、有稳定版发布、有商业支持的产品，Khoj 目前的状态需要慎重：云服务已于 2026 年 4 月 15 日关停，自托管是唯一运行方式；主仓库最后一次提交在 2026 年 8 月 2 日，最新 Release 是 2.0.0-beta.28，2.0 从未出过稳定版；PyPI 上 pip install khoj 拿到的最新版本仍是 2025 年 7 月的 1.42.10。如果你需要文档级权限控制（法务看全部、销售看自己负责的合同） ，Khoj 只有 user 和 agent 两层隔离，没有 ACL/RBAC，做不了这件事。如果你打算基于 Khoj 修改后作为网络服务对外售卖，AGPL-3.0 第 13 条要求你向这些用户提供修改后的源码，私有化商业分发在这条协议下走不通。如果你只有 8 GB 以下内存，官方离线模式建议最低 8 GB RAM、推荐 16 GB 显存、至少 5 GB 磁盘，而历史上索引大文件时 OOM 是被反复报告的顽固问题。

四、Khoj 的应用场景是什么

个人知识库的语义检索与对话——你有多年积累的 Markdown、Org-mode、PDF 和 Notion 页面，想用自然语言直接问“去年讨论过的那个架构方案里，关于缓存失效的结论是什么”，而不是靠文件名和关键词去猜。Khoj 把所有这些来源索引到同一个向量空间，对话时跨源召回，回答基于你的真实文档而不是模型的训练记忆。

Obsidian / Emacs 工作流内的 AI 追问——你已经在 Obsidian 或 Emacs 里写了大量笔记，不想为了用 AI 而切换到一个独立的 Web 应用。Khoj 的 Obsidian 插件和 Emacs 包让你在写作现场直接调用搜索与对话，把“第二大脑”嵌在第一大脑的工具链里，而不是旁边。

定时研究与信息汇总——你希望每天早上收到一份关于某个主题的最新资料汇总，或者每周自动检查某个文件夹里新增的文档并生成摘要。Khoj 的 Automate 功能把“研究”从一次性动作变成可调度的后台任务，Agent 的知识范围和人格在多次运行之间保持一致。

带持久记忆的私人助手——你不希望每次对话都从零开始解释“我是谁、我在做什么项目、我偏好什么格式”。Muninn 把跨会话的事实以带日期的列表注入上下文，同时允许你在设置页逐条查看、编辑和删除记忆；提取器只在召回集合上操作，意味着记忆的“遗忘”也需要你主动清理，而不是由系统自动淘汰。

多模型实验与自托管 AI 基础设施——你想在同一个知识索引之上对比不同对话模型的表现，或者今天用本地 7B 模型、明天用云端大模型处理更复杂的推理。Khoj 的模型自由度把“换模型”变成配置项变更，而不是重写索引流水线。

五、Khoj 为什么值得关注

“个人优先”的架构选择，而不是事后打补丁。大多数知识库系统先做团队/多租户，再把个人场景当成一个“免费版”。Khoj 反过来：用户和 Agent 是唯一的隔离轴，没有文档级 ACL，没有 workspace 抽象，没有角色权限表。这种设计在个人场景下让数据模型、检索过滤和记忆作用域都保持简单；Muninn 的用户 + Agent 双重 WHERE 子句、十六个设置矩阵测试和七个隔离测试，都是在这个简单模型上做深，而不是在一个复杂权限系统上做浅。对个人自托管用户来说，“简单且正确”比“灵活但可能配错”更有价值。

一个 Postgres 行，就是一条可审计、可手动修复的记忆。Muninn 把长期记忆做成了 UserMemory 表中的一行：raw 文本、embedding 向量、created_at、user 和可选 agent。没有不透明的向量数据库、没有外部记忆服务、没有不可读的二进制状态。记忆可以在设置页逐条编辑，可以用 Django 管理命令批量回填或删除，表是纯 SQL、可以手工修复。在一个“AI 记忆”越来越被包装成黑盒服务的时代，这种“记忆就是数据库里的一张表”的透明性，本身就是一种工程立场。

模型自由度与数据主权的真正落地，而不只是口号。Khoj 的自托管模式不锁定对话模型和嵌入模型；向量模型可以是任意 sentence-transformers 模型，对话模型可以是本地 Ollama、vLLM，也可以是任意 OpenAI 兼容端点。更反直觉的是：云版反而更受限——官方文档原话是 “If you're using Khoj Cloud, you're limited to our first-party models”，而自托管才是模型自由的那一侧。这种“把自由度放在自托管侧”的选择，与很多“云端功能更全、自托管是阉割版”的商业开源策略形成鲜明对照。

七端客户端 + Emacs/Org-mode 长尾的覆盖，是社区认可的真实来源。3.7 万 Star 不是来自又一个 Web 聊天界面。Emacs 包、Obsidian 插件、桌面应用、手机、WhatsApp、Discord——这个矩阵在开源个人知识管理项目中几乎找不到对手，尤其是对 Emacs 和 Org-mode 用户的服务，几乎是商业产品的真空地带。社区认可的正是这种“不放弃长尾工作流”的姿态。

AGPL-3.0 的开放边界：个人自由，商业分发有约束。Khoj 采用 AGPL-3.0，个人自托管使用完全自由；但第 13 条的网络服务条款意味着，如果你把修改后的 Khoj 作为网络服务提供给用户，你有义务向他们提供修改后的源码。“基于 Khoj 改一改做成私有化产品卖给客户”这条路在 AGPL 下走不通，除非你开源自己的修改。这不是缺陷，而是一种明确的选择：它保护了项目在个人和社区场景下的开放性，同时把商业闭源分发挡在门外。对于个人用户，这条约束几乎无感；对于有商业封装意图的团队，这是一条必须在选型第一周就弄清楚的红线。

现实挑战与生态成熟度：一个“功能完整但处于冻结维护”的项目。Khoj 的技术完成度不低，但项目状态需要被诚实地标注。云服务关停、主仓库自 2026 年 8 月起无提交、2.0 始终停留在 beta、PyPI 稳定版停在 2025 年 7 月的 1.42.10。团队已把精力转向 Open Paper 和 Pipali，Khoj 本身“开发放缓但未进入维护模式”，然而从 Release、PyPI、Docker 和提交信号综合来看，它实际上处于自托管可用的冻结状态。部署层面，docker-compose.yml 默认拉起 5 个服务——database（pgvector）、sandbox、search（searxng）、computer（带 VNC 的桌面容器）和 server，镜像 amd64 压缩后合计约 1,087 MB，哪怕你只想搜一句笔记，searxng 和沙箱也会一起启动。内存是跨越 2023—2024 年的头号问题：官方离线建议最低 8 GB RAM，但 issue #301（11.3 GB 笔记）、issue #634（16.6 GB 机器索引 PDF 被 OOM kill）和 issue #1105（上传被 OOM kill）都指向同一个现实——索引大文件时的内存峰值，是 Khoj 从早期到后期都没有彻底解决的工程债。安全层面，GitHub Security Advisories 上有 6 条公告，其中未认证路径穿越读文件系统（2026-06）和 Notion OAuth IDOR 导致索引投毒（2025）值得在部署时收紧网络暴露面；2026 年 7 月还有一次遥测 IP 与隐私文档不一致的争议，维护者已停止发送。