如何搭建第二大脑——一份来自 Homelab 实践者的完整教程

xalso 2026-08-23 22:39 1

如何搭建第二大脑——一份来自 Homelab 实践者的完整教程

前置说明：本文不是纸上谈兵。下面是**我自己的知识库从 0 到 1、又从「能跑」演进出「能信」**的真实落地记录——踩过冻结区被漂移、同步引擎版本失配、断连窗口丢变更等一系列坑，最后收敛成目前这套三层 wiki + Agent 直写 + git + 多端同步的架构。写出来供同样在折腾知识管理的人参考。

一、先想清楚：你要的「第二大脑」到底是什么

市面上对「第二大脑」的解读五花八门，但抽象到底，核心诉求只有一条：

让「花过时间的东西」变成长效资产，而不是一次性消耗品。

传统笔记工具（文件夹 + 搜索）为什么不够？

搜索是重新发现，不是复用——每次找资料都要扫一遍，等于把已经做过的事再做一遍。

孤立笔记是死笔记——一篇笔记如果不跟其他笔记产生关联，它就不会被再次访问，慢慢腐烂。

没有编译环节——原始素材和提炼后的知识混在一起，查询时无法区分「来源」和「结论」。

那什么才算「第二大脑」？我的答案是三个要素缺一不可：

要素	解决什么
原子化知识单元	一笔记一概念，可被单独检索与复用
显式关联	用 `[[wikilinks]]` 把笔记织成网，形成「知识图谱」而不是「文件堆」
Agent 参与编译	让 AI 帮你做归纳、交叉引用、矛盾标注，而不是只做全文搜索

而具体怎么实现，决定了这套系统是「能跑」还是「能信」。下面是我的方案。

二、目标架构：四层自治，一层保鲜

先说结论性的总览。一个值得信任的第二大脑，应该是四层结构 + 一套同步保鲜机制：

vault/

├── SCHEMA.md            # 层0：约定层（规则、tag 词表、阈值）

├── index.md             # 层0：目录索引（每页一行摘要）

├── log.md               # 层0：操作日志（append-only，可轮转）

│

├── raw/                 # 层1：源料冻结区（不可变）

│   ├── articles/        #   文章剪藏

│   ├── papers/          #   论文/PDF

│   ├── transcripts/     #   会议/访谈

│   └── assets/          #   图片/附件

│

├── entities/            # 层2：实体页（人/组织/产品）

├── concepts/            # 层2：概念页（主题/技术）

├── comparisons/         # 层2：对比分析页

└── queries/             # 层2：值得留存的查询结果

再加一层行动/输入缓冲（PARA 精神保留下来，但没有喧宾夺主）：

00_Inbox/    # 输入层：新素材先落这里

01_Projects/ # 行动层：进行中的项目

04_Life_Work # 行动层：生活/工作事项

关键洞察：知识层（raw + 编译层）走 wiki 原生形态，行动层（PARA）作为独立缓冲存在，二者互不污染。

三、四层拆开讲：每一层为什么这样设计

层 0 · SCHEMA / index / log —— 让 Agent 有「法可依」

这是整套系统最容易忽略、但也最简单致命的一层。Agent 不是人，它每次运行都像失忆重启，必须靠书面约定约束行为：

SCHEMA.md：规定页面的 frontmatter 结构、tag 词表、什么才够格建一个新页（阈值），新 tag 必须先加进词表才能用——否则 tag 会迅速长成噪音。

index.md：所有页的目录，每页一行摘要。Agent 每次干活前先读它，才知道「这个实体是不是已经有了」，避免建重复页。

log.md：append-only 的操作日志。每次 ingest/update/lint 记一行；超过 500 条就轮转存档。

这三份文件就是 Agent 的「宪法」。没有它们，越多的 Agent 参与，知识库腐烂得越快。

层 1 · raw 冻结区 —— 知识库的「证据链」

raw/ 存放原始素材（文章剪藏、论文、会议记录），设计上不可变：

Agent 只读不写；原始素材有误，改正写在编译层页面里，而不是回去改源料。

每个源料带 frontmatter：source_url、ingested 日期、sha256 摘要。

好处是双重的：一是可追溯——编译层的每一条结论都能顺着 provenance 标记 ^[raw/xxx.md] 找到原始出处；二是可侦测漂移——源网址内容变了，重跑 sha256 一比对就知道「要不要重新编译」。

⚠️ 血泪教训：早期这套冻结区只是「语义约定」，Obsidian 客户端对全库有同等写权限，某天两个不同端同时编辑，源料被复制回工作区、sha256 漂移，编译一致性被破坏。光靠约定是防不住的，必须技术强制——后面章节会讲（用只读权限 + 同步排除）。

层 2 · entities / concepts / comparisons / queries —— 编译后的知识本体

这是 Agent 真正拥有的层。是它把 raw 里的源料编译（归纳、去重、交叉引用、标注矛盾）后的产物：

entities/：一个实体一页（一个产品、一台机器、一个组织）。

concepts/：一个概念一页（一个技术、一种方法论）。

comparisons/：并排对比分析（用表格）。

queries/：值得留存的深度查询结果——下次遇到同一问题不再重查一遍。

规则：

每页至少 2 条出链 [[wikilinks]]，否则孤立页等于不存在。

编译多源时，段落末尾标 provenance ^[raw/xx.md]，读者可逐条回溯。

涉及观点/演进快的内容，frontmatter 标 confidence: medium/low；有未解矛盾标 contested: true。不成熟的结论不能悄悄长成熟。

层 0.5 · 行动/输入缓冲（PARA）

PARA（Projects/Areas/Resources/Archive）不是被抛弃，而是被吸收成两小块：

00_Inbox：所有新素材、剪藏、临时想法首先落这里，不分类。等积攒后统一处理。

01_Projects / 04_Life_Work：行动向内容（项目、人生事项）。它们不是「知识」，硬塞进知识层只会污染编译。

知识类素材从 Inbox 走「编译」进层2，行动类归行动层——两条流水线、互不交叉。

四、三个让系统「可信」的关键设计决策

上面的分层很多人也能想到，真正拉开差距的是下面三个决策。它们决定了这套系统从「演示」变成「生产」。

决策 1：Agent 直写本地文件系统，而不是经中间 API

第一个人人会问的问题是：AI 该怎么读写知识库？

❌ 错：Agent 通过某个服务的 HTTP API / MCP 转发读写——多一层 RPC，变化感知是全量枚举，每次 2 秒，且对冻结区的保护无法技术强制。

✅ 对：把 wiki 做成一个本地 markdown 目录，Agent 直接 read_file / write_file / mv，git 做版本控制。 毫秒级、O(changes) 的变更感知、git 本身就是完整操作日志。

这就是 Karpathy 的 LLM Wiki 原生形态：wiki = 一坨普通 markdown 文件，Agent 用最朴素的文件系统能力直接操作。去掉一切不必要的中间层。

决策 2：冻结区用「文件系统权限」技术强制，而不是靠约定

raw/ 冻结区设置成 目录 555 + 文件 444（owner 只读执行）：

人类/客户端侧：想改原始源料？权限拒绝。

同步侧：同步 daemon 尝试回写只读文件时 permission denied，原文件保持原样。

实测验证过：恶意在同步端篡改只读源 → 本地冻结区纹丝不动。这是文件系统级的保护，不依赖任何软件的逻辑。

注意一个细节：目录权限要 755、文件 444。目录 555 反而会让「合法搬迁进冻结区」（TORAW 迁移）也失败——目录需要写权限来创建/移动文件，但单文件 444 就足够让内容不可改。权限的粒度要精确对准「谁可以移动、谁不可修改」。

决策 3：显式「参与编译」意图标记，杜绝 Agent 自作主张

最大的失控风险是什么？Agent 把不该编译的东西也编译了。 比如你刚往 Inbox 丢了份敏感清单，Agent 当天就跑过去把它变成了公开知识。

解法是加一个 frontmatter 意图标记 wiki_raw: true：

源笔记必须显式打了这个标记，才触发 Agent 的 NEW/UPDATE 编译动作。

编译动作本身绝不自动补打这个标记——否则标记就失效了。

Inbox 里没打标的积压素材，Agent 只做 PARA 归档，绝不擅自编译。

一句话：**AI 只有被「点名」时才上手，否则它只是个归档员，不是搬运工。**这是边界，也是信任的基础。

五、搭建步骤：从空目录到能跑起来的第二大脑

下面按实操顺序走一遍。假设你已经有一台可以常驻跑 Agent 的机器（Homelab 或 VPS）。

Step 1 · 建目录骨架 + 三份「宪法」文件

WIKI="$HOME/wiki"

mkdir -p "$WIKI"/{raw/{articles,papers,transcripts,assets},entities,concepts,comparisons,queries}

git init "$WIKI"

写 SCHEMA.md（约定）、index.md（空目录）、log.md（首条创建记录）。

Step 2 · 让 Agent 进入工作状态

把 Agent（我用的是 Hermes Agent + 它内置的 llm-wiki 技能）接进来，配置：

WIKI_PATH 指向 $WIKI。

Agent 每次会话必须先读 SCHEMA + index + 最近 log——这就是它「失忆重启」后的定向。

从此 Agent 就知道：什么该建页、什么不该建、tag 怎么打、矛盾怎么标。

Step 3 · 接入版本控制与多端同步

这是「能信」的最后一环。选型上我的结论：

git + GitHub 镜像做权威存储与备份（本地 git 直管，别依赖服务端自动提交）。

一个双向同步 daemon 让多端（桌面 Obsidian / 手机）内容一致。

❗ 关键技术点（我踩过的大坑）：必须验证同步 daemon 是「文件级双向同步」，而不是「服务端托管 + API 访问」。曾经用过一套服务端方案，发现笔记正文其实存数据库、根本不是真实文件夹——那意味着 Agent 没法直写、冻结区保护无从谈起。最终选了一个基于 WebSocket 协议把 vault 同步成本地真实目录的 daemon（go-fast-note-sync），Agent 直写本地 git 目录 + daemon 负责与远端双向同步，多端体验保留，冻结区保护是文件系统级的。

Step 4 · 加固冻结区

# raw/ 目录 755 可做 TORAW 迁移；单文件 444 冻结内容

find "$WIKI/raw" -type f -exec chmod 444 {} +

find "$WIKI/raw" -type d -exec chmod 755 {} +

# 同步 daemon 配置里 exclude raw/（冻结区不与多端同步）

Step 5 · 开跑与验证

丢一篇素材进 00_Inbox。

给源料打 wiki_raw: true 标记。

触达 Agent → 它建 raw 副本、编译概念页、更新 index/log。

检查：git diff 干净、同步后服务端/本地一致、冻结区 sha256 无漂移。

重复几次，直到流程顺手，再用 cron 定期 lint / ingest 自动化。

六、稳定性：版本配对与兜底

同步引擎是整套系统里最脆的一环——它是第三方项目，服务端协议频繁演进，客户端一旦跟不上就失配。

我的应对策略：

锁版本：服务端固定一个大版本（如 FNS 3.6.0），客户端固定配对的 v1.1.x，不盲目追新。

升级前查兼容表：服务端出新版，先看客户端 README 的「Verified Compatibility」确认支持，才升。不确定就不升。

本地 git 是权威：同步引擎最坏情况只是「同步暂停」，本地数据永远安全，可恢复。

留兜底通道：主通道挂了随时能切回备用接入（例如官方原生协议），不让单一依赖变成死锁。

还有一条同步一致性铁律值得牢记：拿客户端自报的「上游传 N 条」当成功是陷阱，必须查服务端实际状态（全库枚举）才算数。 曾经就出现过客户端日志说传了 3 条、服务端实际 0 条的诡异情况。

七、踩坑清单（都是钱买的）

坑	症状	修复方向
冻结区「语义只读」	多端同时编辑，源料漂移/副本回流	文件系统 444/555 技术强制 + 同步 exclude
服务端其实是数据库	Agent 没法直写，冻结区保护无从谈起	选「文件级双向同步」daemon
同步引擎版本失配	协议一变，客户端停更就废	锁版本 + 升级前查兼容表
daemon 断连窗口	断连期间的本地变更重连后不补推，远端永久滞后	强制全量 reconcile / 重启 daemon
Agent 擅自编译	Inbox 里的敏感素材被做成公开知识	`wiki_raw` 显式意图标记
盲目用 REST 兜底推送	对已存在的 path 新建而非更新，产生重复记录	主通道走 WS 增量协议，REST 仅做兜底