场景：你的想法散落在聊天记录、书签和 PDF 里 —— EchOS 如何把它们变成可搜索的自托管知识库
你有没有过这种时刻：上周看过的一篇技术文章、昨天随手记下的一句话、某个播客里的一个观点，想找的时候却完全想不起来在哪。知识散落在浏览器的书签、微信和 Telegram 的聊天记录、下载目录里的 PDF 和一堆音频文件里，彼此孤立。Obsidian、Notion AI、Mem 这些工具能帮你记，但它们要么把数据锁在专有格式里，要么把内容传上别人的服务器，检索精度则完全取决于你愿不愿意为云服务付钱。
EchOS（仓库名 echos，MIT 许可证，TypeScript 严格模式，要求 Node.js ≥ 20）走的是另一条路：它是一个自托管、Agent 驱动、单用户的个人 AI 知识系统。核心主张写在它的定位里——”self-hosted, agent-driven, always private”：数据只存在你自己的机器或服务器上，Agent 替你完成捕获、分类、打标签和检索。它明确声明是 single-user 而非 multi-tenant，也就是说它不是给团队开账号用的 SaaS，而是部署在你自己基础设施上的个人工具。
三种入口，捕获一切
EchOS 提供 Telegram、Web 和 CLI 三种接口，捕获的内容类型包括纯文本、URL、语音、图片、YouTube、PDF、播客/音频、RSS/Atom 订阅以及推文。
最有代表性的场景是语音捕获：走路时想到一个想法，直接在 Telegram 里说一句话，EchOS 会在 30 秒内把它转录成文本、自动分类、打上标签，并且立即可被搜索到。底层的语音转文本用的是 OpenAI Whisper 的 whisper-1 模型，音频按 24MB 分块处理，所以一段播客也不会因为太长而卡住。URL 和 YouTube 内容也会被抓下正文一并入库，PDF 走 pdf-parse 解析。这套”随手丢进来、Agent 替我整理”的流程，就是它相对手动记笔记的核心价值——你负责产生想法，剩下的整理脏活交给 Agent。
架构：一个 Agent 核心，四类工具
EchOS 是一个 pnpm monorepo，推理层由 pi-agent-core（底层是 pi-ai）承担，负责工具选择与会话持久化，任务调度用 BullMQ。它的运行时数据流是一条清晰的管线：接口层（Interface Adapter，即 Telegram / Web / CLI）把捕获请求交给 Agent Core，Agent Core 再分派到四类下游——核心工具（Core Tools）、插件工具（Plugin Tools）、调度器（Scheduler），最后落到三层存储（Storage Layer）。
这个分层有两个实际意义。第一，捕获入口和推理核心解耦：你换一种入口（比如从 Telegram 换到 CLI）不影响 Agent 怎么整理和检索，反之亦然。第二，插件是一等公民：文章、YouTube、Twitter、PDF、音频、RSS 这些”内容理解”能力都以插件形式挂在插件工具上，当配置了 ANTHROPIC_API_KEY 时还能对笔记做 AI 自动分类。换句话说，”能捕获什么”和”能检索得多好”是两个可以独立演进、独立替换的维度。
混合搜索管道：为什么它比单模态检索更强
普通知识库的痛点是”存得下、搜不出”。EchOS 把搜索做成了一条最多四段的流水线，每个阶段可以独立开关：
- Hybrid（FTS + 语义向量），默认开启：把 BM25 全文检索和向量语义检索的结果做倒数秩融合（reciprocal rank fusion），同时兼顾精确关键词命中和语义相近的改写查询。
- 时间衰减（Temporal decay），默认开启：较新的笔记排名略微上浮，符合”我上周记的 X 是什么”这类时间敏感查询。
- 热度加成（Hotness boost），默认开启：被频繁检索的笔记获得小幅流行度加分。
- Cross-encoder 重排，默认关闭（opt-in）：用 AI 对候选集做二次打分，换取最高精度，代价是额外延迟和 LLM 调用。
官方 README 声称完整流水线相比”纯关键词”或”纯语义”单模态检索能带来最多约 2 倍的召回率提升。文档站给出了可复现的基准，方法很具体：用 100 / 1000 / 10000 笔记规模的合成语料（覆盖文章、笔记、高亮、对话四种体裁），设计五类共 50+ 查询——关键词、语义改写、多跳、时间敏感、大海捞针，指标为 Precision@5、Recall@10、MRR 与中位延迟。
在中等语料（1000 笔记）上的实测，单模态各有短板：纯关键词 Precision@5 0.52、Recall@10 0.41、MRR 0.58、延迟 12ms；纯语义 Precision@5 提到 0.61、Recall@10 0.54，但语义单模态对精确关键词类查询并不占优。这正是融合管道的意义——把两类单模态各自的弱点补上，再用时间衰减和热度加成对齐真实使用场景。
存储：纯 Markdown，可开进 Obsidian
EchOS 的笔记就是带 YAML frontmatter 的纯 .md 文件，存放在 $ECHOS_HOME/knowledge（默认 ~/echos/knowledge）。这一点很关键：它没有私有数据库锁定，你可以直接把 knowledge 目录当 Obsidian 仓库打开，也能反过来从 Obsidian、Notion、PDF、音频、RSS 批量导入。对长期使用的知识工具来说，”数据可迁移”往往比功能花哨更重要——今天用 EchOS，明天想换回 Obsidian 手搓，你的笔记一个字都不用丢。
内置 MCP server：把知识库喂给你的编码 Agent
EchOS 内置了一个 MCP server，默认关闭，开启后绑定 127.0.0.1、监听 3939 端口，暴露 search_knowledge、create_note、get_note、list_notes、find_similar、knowledge_stats、recall_knowledge 等工具，以及 notes://、tags://、categories:// 三类资源，可以接入 Claude Code、Cursor 或 Windsurf。
实际价值在于：你的个人知识库变成了一个编码 Agent 可调用的上下文后端。比如在 Claude Code 里查”我上次记的那个关于 X 的结论”，Agent 通过 search_knowledge 命中笔记后直接 get_note 取全文，把散落记忆变成可被当下任务引用的事实。启用很简单，在 .env 里加三行：
ENABLE_MCP=true MCP_PORT=3939 MCP_API_KEY=换成你自己的密钥
安装与部署
官方提供三条路径。Homebrew（macOS）最省事：
brew tap albinotonnina/echos brew install echos echos-setup # 打开浏览器向导完成配置 brew services start echos
Linux 一键脚本：
curl -sSL https://raw.githubusercontent.com/albinotonnina/echos/main/install.sh | bash
手动构建（想看源码或定制时用）：
git clone https://github.com/albinotonnina/echos.git && cd echos pnpm install && pnpm build pnpm wizard # 打开 http://localhost:3456 的引导配置页 pnpm start
LLM 配置有两种：走 Anthropic 用 ANTHROPIC_API_KEY（注意是 pay-as-you-go 的 API key，不是 Claude 订阅），或走 pi-ai 用 LLM_API_KEY；也支持用 LLM_BASE_URL 指向任意 OpenAI 兼容端点（如 DeepInfra、Ollama）。
和别的知识工具放一起比
把它放进 Obsidian+AI、Notion AI、Mem、Apple Notes 这一档里比，差异点很清楚：
| 维度 | Obsidian + AI | Notion AI | Mem | EchOS |
|---|---|---|---|---|
| 数据归属 | 本地纯 Markdown | 专有云数据库 | 专有云端 | 本地纯 Markdown |
| 数据可迁移 | 强 | 弱（导出受限） | 弱 | 强（Obsidian 兼容） |
| 检索方式 | 插件/语义扩展 | 云端问答 | 语义问答 | 混合 FTS+向量，可加 cross-encoder |
| 捕获入口 | 手动/插件 | 手动/导入 | 手动/邮件 | Telegram/Web/CLI 多模态随手丢 |
| 隐私模型 | 完全本地 | 内容上云 | 内容上云 | 完全本地，可喂编码 Agent |
可以看出它和 Obsidian 最像（都是本地纯 Markdown、可迁移），但多了”多模态随手捕获 + 混合检索 + 内置 MCP”这条完整链路；和 Notion AI/Mem 相比，它的区别在于数据不出本机，检索精度靠可配置的多段管道而非黑盒云问答。
谁适合用它，谁不用
它最适合三类人：一是知识量大且碎片化、希望”随手一丢就不丢”的个人，尤其是已经在用 Telegram 的人——随手语音、随手截图、随手链接，回来再慢慢整理；二是重度本地化、不愿意把笔记内容交给云端、同时想要语义检索和编码 Agent 可访问能力的人；三是想要一个可迁移、可离线、数据归属自己的知识库底座，又不想自己从零搭 RAG 的人。反过来，如果你的核心诉求是一个可多人协作、可权限管理、可审计的团队知识库，或者你要的是一个开箱即用的 SaaS 问答产品，它的单用户、本地定位就不匹配，团队向的知识库或托管问答产品更合适。
一个真实的搜索用法
混合检索的价值在”关键词命中 + 语义命中”的组合上。举个贴近实际的查询：你三个月前随手丢了一句”调研一下本地推理的量化方案”，当时没展开。现在想找回它，用 search_knowledge 走混合检索：FTS 部分命中”量化”这个关键词，语义部分把”调研””方案””本地推理”这些相近表述也召回，再按时间衰减与热度排序，把更早但语义相关的笔记浮上来。这就是它和纯全文搜索的差别——纯关键词检索在你换了说法时很容易漏。
边界、取舍与失败模式
前面这张表已经给了一个方向，下面把取舍和失败模式说得更具体些。
- 单用户工具：它不是给团队开账号用的 SaaS，没有多租户协作，一个人一台机器的定位。
- 常驻依赖：需要一台能跑 Node.js ≥ 20 的常驻机器，用
brew services或手动pnpm start保活；关机就等于知识库离线。 - 精度上限取决于 LLM：cross-encoder 重排是 opt-in 的，不开就省延迟但牺牲精度上限；开了要多付 LLM 调用钱和额外延迟。
- 密钥边界：
MCP_API_KEY这类密钥设计给本地回环，做远程访问前要先读它的 Security 文档，别直接暴露 3939 端口。 - 语音质量依赖 Whisper：嘈杂环境或方言重的语音，
whisper-1的转写质量会直接影响分类和标签的准确度。
反过来它给出的确定性是——数据是你能直接读、能迁移的纯 Markdown，Agent 替你干的是”整理和检索”的脏活，而不是替你保管数据。如果你想要一个完全私有、随手丢东西就能被语义搜出来、还能喂给自己的编码 Agent 的个人知识库，这条自托管路线值得跑一次。