3.7 万 Star 的「第二大脑」Khoj，为什么关掉了云服务

标签：RAG · 开源项目 · 知识库 · 向量检索 · 私有化部署 · 数字人
>

摘要：Khoj 是 GitHub 上最受关注的开源「第二大脑」项目之一——3.7 万 Star、YC S23 出身、七个客户端。2026 年 4 月它关掉了云服务，主仓库也在 8 月停止提交。本文基于仓库源码、GitHub API 实测数据和官方公告，拆解它做对了什么、卡在了哪里，并对比我们在私有化实时语音知识库上的另一套取舍。

数据采集日期：2026-10-12。文中所有数字按来源分档标注，来源说明见文末附录。

一、三件先要说清楚的事

如果只看 Khoj 的 GitHub 首页，你会得到这样的印象：3.7 万 Star、支持 Obsidian / Emacs / 桌面 / 手机等七个客户端、可以完全自托管，README 里还写着「use Khoj right away at app.khoj.dev — no setup required」。

但这些是过期信息。截至 2026 年 10 月 12 日，实际情况是：

• 云服务已经关停。 2026 年 4 月 15 日，Khoj 官方在 app.khoj.dev 挂出日落公告（sunset notice），停止托管服务。现在访问该域名，看到的只有这份公告。
• 主仓库已经停止提交。 默认分支最后一次 push 是 2026-08-02（commit ae229ca），两个多月没有动静。GitHub 上最后一个 Release 是 2.0.0-beta.28（2026-03-26）——2.0 从来没出过稳定版；PyPI 上 pip install khoj 拿到的仍然是 2025-07-15 发布的 1.42.10。
• 团队已经转向。 公告原文：「We're focusing our efforts on Open Paper，a research assistant … and Pipali，an AI coworker」。这两个新仓库在 2026-10-05 和 2026-09-26 还有提交，是活的；Khoj 本身不是。

仓库没有归档，维护者 Debanjum 在 issue #1334（2026-06-12）里也回复过「Khoj development has slowed down but it is not in maintenance mode」。但把所有可观测信号摆在一起——Release、PyPI、Docker latest、博客（最后更新 2025-01-14）、提交——它们指向同一个方向。

所以这篇文章不打算写成产品说明书。更值得回答的是：一个技术上并不差、社区认可度很高的项目，为什么走到了这一步？ 这对正在做知识库选型的人，比一堆功能罗列有用得多。

二、来龙去脉

2.1 起点是一个实验工具

Khoj 不是 2023 年那波大模型热潮的产物。官方公告里写着：

The Khoj project started out in April 2021 as an experimental tool to improve document search.

2021 年 4 月，比 ChatGPT 发布早了整整一年半，GitHub 仓库建于 2021-08-16。它最初的形态是一个「文档搜索」工具——用语义检索帮你从自己的笔记里找东西，这个内核从第一天到现在基本没变过。

2.2 YC S23，和一波「第二大脑」热

2023 年，Khoj 进入 Y Combinator 夏季批次。这里要纠正一个流传较广的错误：不少第三方页面写它是 W23 或 W24，而 YC 官方页面写的是 Summer 2023（S23）。

YC 页面把创始人背景写得很清楚：Debanjum Singh Solanky 和 Saba Imran，两人都出自微软的个人 AI 方向（Cortana / Viva Insights），原文是「scaled … from 0 to 20M daily active users」。这个背景解释了 Khoj 后来的产品直觉——它从一开始就按「面向个人的助手」来做，而不是面向组织的知识管理。

同一时期，Khoj 在 HN 上发了《Chat Offline with your Second Brain using Llama 2》（2023-07-30）。「第二大脑」和「本地离线」这两个标签，就是那时候立住的。

（有第三方资料称 Khoj 在 2023 年拿到约 50 万美元种子轮、投资方是 YC 和 Pioneer Fund。这个数字只出现在 Crunchbase / PitchBook 一类付费聚合站，我没有在首方页面上核实到，不作为事实使用。）

2.3 商业化选择：订阅制 + 云优先

2023 年 11 月，Khoj 从「自托管工具」变成「云服务」。商业模式是双轨：开源版自托管（AGPL-3.0），加上托管订阅版 app.khoj.dev（免费额度 + 付费档）。

这个选择在当时看是标准答案。但四年后，它被团队自己列进了失败原因。

2.4 关停：团队自己的复盘

公告里最值得逐字读的一段，是团队列出的「initial bets」：

…a subscription, cloud-first service, complex document syncs, custom data integrations, multiple (6!) clients — made it very difficult to scale in utility.

以及关于护城河的那句：

…challenges in defensibility with all the big labs coming out with similar products.

翻译成大白话：他们同时压了五个重资产方向，每一个都要持续投人，而没有一个是能建立壁垒的。 模型能力被大厂快速拉平，「检索你自己的笔记」这件事本身的差异化，不足以支撑一门订阅生意。

这句话和 Khoj 技术做得好不好无关。是商业模型的问题。

时间线

三、它到底是怎么做的

这一节的依据是仓库源码（快照 commit ae229ca，即 2026-08-02 的 master）。我核对过：今天 master 上 pyproject.toml 的依赖列表与快照完全一致，所以这份快照可以当作当前状态的一手证据。

3.1 技术栈：两个 Web 框架并存

• Python ≥3.10, <3.13（3.13 装不上，这点文档没写，issue #1224 里用户自己踩出来的）；
• FastAPI 做 API 层，Django 5.1 做 ORM、模型和管理后台，两套框架共存；
• ASGI 用 uvicorn / gunicorn，定时任务用 apscheduler。

3.2 检索链路：纯稠密向量，没有关键词通路

这是最容易被误解的一点。Khoj 的检索是单一的稠密向量检索，实现是 PostgreSQL + pgvector：

CosineDistance("embeddings", query_vec) → order_by("distance") → distance <= max_distance

两个源码层面的事实：

1. 没有混合检索。 全仓库 grep tsvector|SearchVector|tsquery|bm25|trigram|full text|lexical，除一条无关注释外零命中。它没有 BM25 / 关键词这一路。对「第十六条」「RFC 编号」「函数名」这类精确匹配需求，这条链路天然是短板。
2. 没有 ANN 索引。 在 migrations 目录里 grep hnsw|ivfflat|CREATE INDEX|vector_cosine_ops，同样零命中。配合 VectorField(dimensions=None)（pgvector 的 HNSW / IVFFlat 要求固定维度），可以判断检索走的是全表精确扫描。这一点是推断，但 grep 零命中是事实。

模型和参数的默认值：

重排默认关闭这件事值得单独说：/api/search 的签名是 r: bool = False，只有请求显式带上 r=true，或者另外配了一个 cross-encoder 推理服务，才会重排。

3.3 数据源：覆盖面广，但都是手搓

src/khoj/processor/content/ 下的目录就是全部支持的来源：markdown、org_mode、plaintext、pdf、docx、images、notion、github。

几个需要点破的细节：

• 图片不是多模态。 走的是 rapidocr_onnxruntime 做 OCR 抽文字，抽不到就整个文件不索引。只支持 png / jpg / jpeg / webp。
• GitHub 集成官方自己标了「Unmaintained」，文档原话「We are considering deprecating it」。
• DOCX 用 docx2txt，有处理器，但文档里几乎不提。
• 扫描版 PDF 依赖 OCR，能力上限取决于此。

官方关停公告里那句「hand-building data integrations was going to be a long tail of effort」，和这里的目录结构是对得上的：每接一个源，就是一份独立维护成本，五年下来攒了八个。

3.4 隔离与权限：只有「用户」和「Agent」，没有文档级 ACL

Khoj 里没有「知识库」这个实体。隔离只有两个维度：按 user（Entry.user），按 agent（Entry.agent，agent 可以挂自己的知识，也就是 README 说的「custom knowledge」）。检索时的过滤条件是：

Q(user=user) | Q(agent=agent)

没有文档级权限。 整个 docs 目录 grep acl|rbac|role.based|permission|multi-tenant，只命中一条无关的 GCP 排错文本。实际存在的只有服务级认证开关（默认 --anonymous-mode，可开 magic link 或 Google OAuth），以及 agent 上的一个三档 PrivacyLevel（PUBLIC / PRIVATE / PROTECTED）。

所以 Khoj 的权限模型是为个人设计的——「这份笔记是我的，不是你的」。这在个人场景下完全够用，甚至是对的选择。但如果你的场景是「同一批合同，法务能看全部、销售只能看自己负责的」，Khoj 没有对应机制。

3.5 部署：五个容器起步，镜像 1 GB+

官方给两条路：Docker Compose，或 pip install 'khoj[local]' + USE_EMBEDDED_DB=true。

但 docker-compose.yml 默认拉起 5 个服务：database(pgvector)、sandbox(代码沙箱)、search(searxng)、computer(带 VNC 的桌面容器，暴露 5900 端口)、server。哪怕你只想问一句「我上周写的那个方案叫什么」，searxng 和沙箱也会一起起来。

镜像体积实测（GHCR manifest，2026-10-12）：amd64 压缩后合计约 1087 MB。

GPU 方面：不是必须的，官方镜像用的是 CPU 版 torch。想跑本地大模型要自己在宿主机另起 Ollama / vLLM。官方给的离线模式建议配置是「最少 8 GB 内存，推荐 16 GB 显存，至少 5 GB 磁盘」。

四、优势：3.7 万 Star 不是白来的

先把话说清楚——Khoj 拿到的社区认可，绝大部分名副其实。它有几个别人真没做到的地方。

4.1 客户端广度

Emacs、Obsidian、桌面应用、Web、手机、WhatsApp、Discord——这个矩阵在开源知识库里几乎没有对手。尤其是 Emacs 和 Org-mode 这条线：人数不多，但极其忠诚，而且几乎被所有商业产品忽略。Khoj 认真服务了这批人，也因此拿到了最早期、最硬核的一批用户。

代价同样清楚：六个客户端意味着六份持续维护成本。团队在关停公告里把「multiple (6!) clients」明确列为压垮项目的原因之一。优势和包袱，在这里是同一件事。

4.2 数据源覆盖的长尾

Markdown、Org-mode、PDF、Notion、GitHub、纯文本——覆盖面比大多数开源同类宽。Notion 和 GitHub 这类需要 OAuth 和 API 集成的源，开源项目里很少有人愿意做。虽然 GitHub 那条现在标了 Unmaintained，整体广度仍是实打实的。

4.3 模型自由度

自托管模式下 Khoj 不锁模型。向量模型可以是任意 sentence-transformers 模型，也可以走远程 API；对话模型除了原生的 OpenAI / Anthropic / Google 三家，还能通过「任意 OpenAI 兼容 endpoint」接上 Ollama、LM Studio、vLLM、LiteLLM、OpenRouter、Vertex AI。

这里有个和直觉相反的点：在 Khoj 里，是云版更受限（文档原话「If you're using Khoj Cloud, you're limited to our first-party models」），自托管反而更自由。

4.4 Agent 与自动化

2024 年下半年起，Khoj 把重心往 agent 方向推：自定义 agent、代码执行、定时自动化（Automate）。这今天是它的重要加分项，也是团队最后的技术兴奋点。

4.5 完全自托管，数据不出机器

跑在本地时，索引、向量、模型调用都在你机器上。对隐私敏感的个人用户，这是决定性的。

五、缺点：有代码和 issue 支撑的那些问题

这一节的每一条，要么能在源码里指到行，要么能在 issue 里找到原始讨论。

5.1 内存：跨三年的头号问题

这是 Khoj 从 2023 年到 2024 年最反复出现的抱怨主题，而且至今没有解决。

• issue #301（2023-07-11）：用户有 18 年的笔记、11.3 GB。维护者 sabaimran 的回复很坦诚：

  I...don't think 11.3 GB is going to be feasible by our application as it stands

  并承认「we have a lot of room for improvement in memory consumption」。

• issue #634（2024-02-02，至今 open）：用户在 16.6 GB 内存的机器上索引 PDF——「CPU is in constant use … sometimes it hogs all available CPU and my machine becomes unresponsive for a minute or two … the process ends with the message 'Killed'」，原话是「Khoj has never managed to index all the PDFs」。

同主题的还有 #195（首次索引 MemoryError）、#303（有人专门开 issue 要求「分析内存占用」）、#1105（上传被 OOM kill，用户自己改脚本分批）。

一个「帮你管理笔记」的工具，在别人的真实笔记面前撑不住。这基本决定了它的用户上限。

5.2 检索质量：三个能指到代码的缺陷

（1）中文 / 日文 / 韩文分块基本失效。 issue #1354（2026-06-28，open）：

Markdown chunking fails for CJK languages due to text.split() tokenizer undercounting tokens

根因是分块的 tokenizer 就是 text.split()（按空格切）。中文没有空格，所以整篇中文文档会被当成一条 entry，不切分。后果不是「切得不好」，而是：

the bi-encoder averages the semantics of the entire document, and search hits land on the YAML frontmatter/first heading instead of relevant sections

整篇文档被平均成一个向量，检索命中会落在 YAML frontmatter 或者第一个标题上。我核对了源码，TextToEntries.tokenizer = text.split() 属实。对中文用户来说，这条是硬伤。

（2）多轮对话里的引用会静默消失。 issue #1270（2026-03-08，open）：因为一个 isinstance(item, dict) 类型判断写错，历史轮次的 references 永远为空。表现是答案里的「来源」无声无息地不见，界面上看不出任何异常。

（3）一个空标题能让索引永远跑不完。 issue #1437（2026-09-26，open）：笔记里出现空的 # 时，索引永不结束，一个 CPU 核 100% 空转。报告者用的正是 master 上的 ae229ca894，也就是我手上这份快照。

5.3 部署成本被低估

• issue #1224（2025-09-27）：pip 依赖冲突，社区结论「Python 3.13 不行、3.12 可以」，用户指出文档没写这一点。
• issue #1194：Windows 用户的原话——「the toml compiling need 30min MAYBE you can write a hint that its need time」（16 核 + RTX 4060 Ti）。
• issue #1100（2025-02-02，25 条评论，是仓库里讨论最多的 issue 之一）：「Unable to connect to local Ollama using self-hosted Docker」。有人试了几天，Mac 上 Docker 跑得通，换到 Ubuntu + GPU 就不行，根因是 Docker 网络和 OLLAMA_HOST 配置，而 UI 不给任何提示。
• 一批管理后台登录失败的 issue（#1152、#1187 等），用户根本不知道用户名密码是什么。

有中文深度测评给出的估计是「第一次装 Khoj 不是『5 分钟搞定』，要预留 1–3 小时」。对照它「开箱即用」的宣传，这个落差是客观存在的。

5.4 权限模型的缺失，对企业是硬伤

如 3.4 所述，Khoj 只有 user / agent 两级隔离，没有文档级 ACL、没有团队或共享空间、没有多租户权限模型。

个人用没问题。但只要场景里出现「不同角色的员工看不同的文档」——这在企业里几乎是必然的——Khoj 就得先补这一层，而这不是改配置能解决的。

5.5 官方评测数字不能用来论证「文档检索质量」

Khoj 在 2024-11-22 发过一篇评测博客《Evaluating Khoj for Helpfulness》，数字确实好看：

但这篇博客自己写明了关键限制，引用时必须带上：

Our current eval only measures retrieval from the internet, not from your documents.

也就是说，这份成绩完全不衡量「跟你自己的笔记对话」的检索质量——而后者才是 Khoj 的主场景。博文作者自己对 SimpleQA 那个跳变也存疑：「suggests either remarkable effectiveness of Khoj's approach or potential brittleness in the benchmark itself. Or maybe our eval is broken?」样本量是 200 题随机子集，误差约 6%。

另外，官方性能文档里那条「Semantic search < 100 ms」，自述数据是 2022 年的，测试机型 Mac M1。

所以：看到有人把 Khoj 的 FRAMES / SimpleQA 分数拿来证明「它检索比谁强」，可以直接跳过。

5.6 AGPL-3.0 的实际约束

Khoj 用的是 AGPL-3.0。LICENSE 是逐字的 AGPLv3 全文，pyproject.toml 写的是 AGPL-3.0-or-later，GitHub 的协议识别也是 AGPL-3.0。

关键在于第 13 条的网络服务条款：如果你把修改过的 Khoj 作为网络服务提供给用户，你有义务向这些用户提供源码。

对个人自用完全无影响。但如果你打算「基于 Khoj 改一改，做成私有化产品卖给客户」——这条路在 AGPL 下走不通，除非你开源自己的修改。这个坑值得在选型早期就想清楚，而不是立项三个月后才被法务发现。

（一个有意思的对照：团队的新项目里，Pipali 换成了 Apache-2.0，Open Paper 仍是 AGPL-3.0。协议选择上他们自己也在动。）

5.7 文档和代码脱节

几个具体表现：

• README 的 FAQ 还在写「use Khoj right away at app.khoj.dev — no setup required」，而云服务 4 月就关了；
• README 里指向企业版的 khoj.dev/teams 现在 404；
• 下载页 khoj.dev/downloads 404；
• 文档和 credits 仍宣称「natively supports local LLMs available on HuggingFace in GGUF format」「Llama.cpp to chat with local LLM」，但 llama-cpp-python 既不在 pyproject.toml 里也不在 uv.lock 里——离线聊天现在实际是通过外部 OpenAI 兼容服务器实现的。

（补一个私人博客的实测体验，注意这是第三方主观评价、非受控实测：darkedge.world 上一位 Org-roam 用户记录了跑题的 query 扩展和捏造来源，「Khoj somehow finds it appropriate to mix in blockchain technologies into the query」，并抱怨「Running the context search locally on my laptop takes about half a minute at full throttle」。HN 上也有用户 kkfx 说，在他的 org-mode 笔记上「a mere rg (ripgrep) succeed」，而 Khoj 找不到。个体体验不能当结论，但方向一致。）

5.8 安全公告

GitHub Security Advisories 上共 6 条，其中两条值得一提：未认证的路径穿越可读服务器文件系统（GHSA-62mm-xwmv-crhg，2026-06-24）；Notion OAuth 的 IDOR 可导致索引投毒（CVE-2025-69207）。另有遥测争议：2026-07-13 的 issue #1374 指出遥测在发送客户端 IP，与隐私文档「we do not log your IP address」矛盾，维护者承认并停止发送。

六、横向看：Khoj 在同类里站在哪

社区实际拿来和 Khoj 比的，主要是这几个。Star 与活跃度数据均为 2026-10-12 用 GitHub API 实测。

几条社区共识（来源等级一并标出）：

• Khoj 被普遍归为「个人 / PKM」，其余大多被归为「团队 / 组织级」。 这几乎是所有对比文章的一致结论。
• Khoj 的差异化被反复归因于「客户端广度」和「agents + 定时自动化」，而不是检索深度。 这和我们对源码的观察吻合——它的检索链路确实是最朴素的那一种。
• AnythingLLM 是最常见的正面对比对象，第三方评述点出的 Khoj 短板是「single-backend architecture is designed for personal and team scale, not enterprise-scale distributed retrieval」。（注：这类对比站大多是模板化甚至 AI 生成内容，我只把它当作「社区怎么归类」的旁证，不作事实依据。）
• NotebookLM 被当作「打磨得更好但封闭」的对照：引用做得漂亮，但是个围墙花园；Khoj 赢在集成和隐私。也有评述把「retrieval accuracy can trail more polished closed products like NotebookLM」列为 Khoj 的缺点。
• 许可被反复当作决策轴。 有第三方原文说得直白：「It is also AGPL 3.0 licensed, a copyleft license people frequently confuse with the permissive Apache 2.0 or MIT licenses used by most of the tools it competes with.」

最后补一个诚实的信息缺口：没有找到任何第三方 benchmark 把 Khoj 和这些项目放在一起做量化对比（LoCoMo / LongMemEval 之类）。目前唯一可引用的量化数字就是 Khoj 自己那篇，而它测的是联网检索。所以任何声称「A 比 B 检索准 X%」的说法，基本都没有可靠出处。

七、我们走的是另一条路

到这里该讲讲我们自己（蔓藤AI）的选择了。但不是「我们比 Khoj 强」——那种比较没有意义，因为我们做的是另一件事。

7.1 问题本身就不一样

Khoj 要回答的是：「帮我找回我自己写过的东西。」

我们要回答的是：「用户正在说话，我该不该去查资料，查到之后要把它讲出来。」

这个差别看起来只是「加了个语音」，但它把整条链路的约束全换掉了：

最后一行是关键。没有屏幕意味着用户只能听，不能回看、不能滚动、不能点开来源。Khoj 里那种「返回 5 条结果让你自己挑」的交互模式，在这个场景下根本不存在——我们必须一次就说对。

7.2 于是检索层要做的事情完全不同

多路召回是必须的，不是加分项。 Khoj 是纯向量检索（3.2）。但在中文专业文档里，纯向量的盲区是明确的：「违约金」和「违约赔偿」靠向量能找到，「第十五条」和「第 15 条」就必须靠关键词。所以我们做的是向量 + FTS5 关键词 + 实体图谱三路并行召回，再用 RRF（Reciprocal Rank Fusion）融合：

def rrf_fuse(ranked_lists, k=60):
    """多路召回融合：分数 = Σ weight / (k + rank)"""
    scores = {
   }
    for weight, ranking in ranked_lists:
        for rank, item in enumerate(ranking, start=1):
            scores[item] = scores.get(item, 0) + weight / (k + rank)
    return sorted(scores.items(), key=lambda x: -x[1])

三路权重是向量 1.0 / 关键词 1.0 / 图谱 0.4——图谱作为增强，权重刻意压低，避免它把精确匹配的结果挤掉。

重排必须是默认开启的。 Khoj 的 cross-encoder 重排默认关（r: bool = False）。但在一次说对的场景里，我们没法接受「先给 10 条宽的，用户自己挑」——所以候选集放宽到 20 条，用 BGE-reranker-v2-m3 交叉编码器重新打分，只留 5 条进上下文。

中文分块不能靠空格。 前面 5.2 讲了 Khoj 的 text.split() 在 CJK 上的问题。我们用的是 jieba 分词，并且针对中文法律 / 合同类文档做了条款级分块——识别「编、章、节、条、款、项」的编号模式映射成标题层级，让「条款号即结构」。索引时用小块做向量匹配（精确），返回时扩到父块给大模型看完整上下文，也就是常说的「小到大」父子块。这是「检索要准」和「生成要有料」之间最直接的一个折中。

闲聊要能跳过检索。 用户说「你好」的时候不该去查合同库。我们有一个查询分析器做意图判断，置信度到 0.9 以上直接走闲聊路径；FAQ 问答对命中（阈值 0.75）也直接返回，不走大模型——这在实时场景里省下的是实打实的延迟。

7.3 权限：企业场景下没法省的一层

Khoj 没有文档级 ACL（3.4）。我们的做法是给每个文档块打 ACL 标签，空标签表示公开，检索时按调用方权限过滤。

这里有个容易做错的细节值得单独说：权限过滤必须下推到检索层，不能在应用层后置过滤。 如果先取 top-k 再剔掉无权结果，实际有效召回会低于 k，用户会莫名其妙地「少看到了一些内容」。我们把过滤条件直接下推到向量检索的查询里。

7.4 存储：能离线运行的单文件

私有化交付的第一条红线是数据不能出内网。所以我们的默认存储形态是 SQLite + sqlite-vec + FTS5，全部落在单个文件里：部署时不需要额外搭向量数据库，单文件即可备份迁移；模型侧（向量化、重排、文档解析）全部本地推理，模型下载完之后，拔网线也能用。

这不是「不愿意上向量数据库」，而是在企业内网的现实条件下，多一个外部组件就多一份部署和运维成本。存储层我们做了抽象，需要时可以换成 Postgres / pgvector，业务代码不变。

顺带说一个我们自己在存储层做过的基准测试（两种实现的结果逐位一致）：

有两点值得说明，因为它们是这份表里最有信息量的部分。

第一，KNN 在千级 chunk 以下反而更慢——它有一个约 2 ms 的固定开销。所以「用了 ANN 就一定快」是错的认识，交叉点在千级左右。

第二，也是最该记的一条：我们在这个优化里一度拿到过 46 倍加速的错误结果。 原因是我们在过滤条件里加了一个防御性的 OR kb_id IS NULL，而 sqlite-vec 的分区表会因为这个 OR 放弃分区剪枝，退化成「先取全局前 k 再过滤」——k=20 时只剩 4 行，是静默的大规模少召回，不报任何错。是「KNN 结果必须与暴力检索逐位一致」这条断言把它抓出来的。这件事后来被写成了契约测试。

讲这个是想说明一类事：检索系统的性能优化，如果不配一个「优化前后结果必须一致」的验证网，你很可能拿到一个又快又错的系统，而且不会收到任何报警。

7.5 交付形态

• 生成式大模型走 OpenAI 兼容接口，可对接 Qwen / DeepSeek 等，也可换成本地 LLM；
• 推理侧做了统一加速器抽象，自动识别并择优调度 NPU（昇腾）→ CUDA（NVIDIA）→ CPU，覆盖 GPU 工作站、国产 NPU 一体机和纯 CPU 环境；
• 多服务可编排：主服务、检索服务、语音 / ASR 服务、前端静态服务，单机即可跑通。

7.6 说实话，我们不占优的地方

对称才可信，所以这几条也写在这里：

• 客户端广度：我们没有 Emacs、Obsidian 插件这类个人笔记客户端。七个客户端的矩阵是 Khoj 的长处，我们没有对等物。
• 个人笔记数据源：Notion、GitHub 这类个人 SaaS 源的直连，我们覆盖得不如它宽。
• 社区规模：37.6k Star 对任何项目都是一笔真实资产，短时间补不上。
• 模型完全自由：我们走 OpenAI 兼容接口 + 本地 LLM，自由度够用，但没有 Khoj 那种「任意 sentence-transformers 模型随插随用」的灵活度。

八、所以该怎么选

不用绕弯子。

选 Khoj，如果——你是个人用户，笔记以 Markdown / Org-mode 为主，主要用 Emacs 或 Obsidian，在意数据完全本地，且不介意自己花一两个小时折腾部署。它的客户端矩阵和数据源广度，在这个场景里没有对手。

别选 Khoj，如果——你要做的是企业交付：需要文档级权限、需要处理扫描件和中文法律 / 合同文档、需要多知识库隔离、需要「开口讲出来」的交互形态。这些不是配置问题，是架构层面的缺口。另外，如果你打算基于开源项目做成商业产品卖出去，AGPL-3.0 这条得先过法务。

另外有个现实提醒：不管选不选 Khoj，都要注意它的维护状态。云服务已关停、主仓库自 2026-08 无提交、最新版仍是 beta。选一个活跃度在下降的项目，本质是在赌社区会接手。

九、回到那个问题

Khoj 团队在关停公告里写的那句话，我认为是整件事里最有价值的一段：

…a subscription, cloud-first service, complex document syncs, custom data integrations, multiple (6!) clients — made it very difficult to scale in utility.

五个重资产方向同时推进，每一个都需要持续投人，每一个都不是壁垒。这不是技术失败，是在一个已经被大厂快速拉平的赛道上，用个人工具的方式去撑一门订阅生意。

对我们的启示很直接：与其在「通用检索」这个正被模型能力抹平的维度上竞争，不如去做那些模型能力无法替代的工程约束——实时性、权限、专业文档的结构化理解、私有化交付、语音输出。这些事做起来苦，但不容易被一个大模型版本更新抹掉。

附录：数据来源与核实说明

本文所有事实按来源分三档。

一档｜一手可核实（GitHub / PyPI 官方 API 实测，或仓库源码）

• 仓库规模、Star / Fork、提交与 Release 时间、协议：GitHub API，2026-10-12 实测
• pip 稳定版版本与日期：PyPI JSON API
• 云服务关停公告及其原文引用：app.khoj.dev（2026-10-12 仍返回该页）
• 技术栈、检索实现、数据源目录、模型默认值、docker-compose 服务列表、镜像体积：本地仓库快照（commit ae229ca，2026-08-02），并已核对今日 master 的依赖列表与快照一致
• 各 issue 的标题、日期、状态与原话：GitHub Issues API 逐条拉取
• 安全公告：GitHub Security Advisories API
• 对比项目的 Star 与活跃度：GitHub API，2026-10-12 实测

二档｜官方但需注意时效

• 评测数字（FRAMES / SimpleQA）：官方博客 2024-11-22，且只衡量联网检索，不衡量个人文档检索
• 性能数字（语义检索 < 100 ms）：官方文档，自述数据为 2022 年
• YC 批次与创始人背景：YC 官方公司页

三档｜第三方，仅作旁证，不单独作为结论依据

• HN 讨论帖与用户评论
• 个人博客实测（darkedge.world 等），主观体验，未经受控复现
• 各类「对比站」评述，多为模板化或 AI 生成内容，仅用于说明「社区如何归类」

明确未核实、故未采用的

• Khoj 云服务的历史定价档位与免费额度（首方页面已失效，archive.org 在本环境不可达）
• 种子轮的确切金额与投资人名单（仅见于付费聚合站）
• 创始人详细履历（学位、历任雇主与年份，仅见于二手聚合资料）
• Reddit 上的相关讨论（未检索到可验证的原始帖链接，故不引用任何「Reddit 用户抱怨」）
• 任何第三方量化 benchmark 对比（不存在，故本文不含此类数字）

说明：本文涉及的开源组件均为公开发布，模型与参数默认值来自公开源码；我们自己的性能数据来自仓库内基准脚本，可复现。工程参数以实际交付为准。