对话笔记直发：7.5 llm-wiki基于FNS三端同步架构的对抗性审查与实施方案。分类：小程序接单。
title: llm-wiki基于FNS三端同步架构的对抗性审查与实施方案 date: 2026-07-05 tags:
- obsidian
- llm-wiki
- fast-note-sync
- hermes
- architecture
- review aliases:
- llm-wiki FNS审查
- LLM Wiki 新架构审查
llm-wiki基于FNS三端同步架构的对抗性审查与实施方案
结论先行
在当前已经切换到
FNS + Hermes MCP + Windows/Android 客户端的新架构下，2026-07-04那份以/srv/obsidian-mirror/为中心的llm-wiki设计，已经不再是最优方案。当前最合适的方案不是把
llm-wiki直接放进 Vault，也不是继续围绕/srv/obsidian-mirror/设计，而是：
方案 D：影子工作区（Shadow Workspace） + MCP 发布投影（Publish Projection）
1. 审查范围
本文用于重新审查以下旧文的结论，并在今天已经落地的新同步架构下给出修正版方案：
[[Obsidian_llm_wiki架构修改]][[7.5 OCD同步迁移说明指南（FNS + Hermes）]]
本文目标不是重复旧讨论，而是回答一个更具体的问题：
在当前最新三端同步架构下，什么样的 llm-wiki 接入方式既不破坏 FNS，同步安全，又能让 Hermes 正确设计？
2. 当前前提已经变化
旧文的很多判断，建立在下面这个前提上：
/srv/obsidian-mirror/是真实主库路径- OneDrive / WebDAV / Remotely Save 是主同步链路
- Hermes 直接碰本地文件系统是合理的
这个前提现在已经失效。
根据今天已经定稿的新基线：
FNS是唯一同步中枢FNS是唯一权威写入口Hermes应通过MCP操作vault=feng/srv/obsidian-mirror/已降级为只读派生层 / 缓存层 / 备份辅助层
这意味着：
任何仍以
/srv/obsidian-mirror/作为 llm-wiki 主工作目录并直接写入 Vault 的设计，都会和当前主架构发生冲突。
3. 第一性原理重建问题
我们先不用旧方案名字，直接从约束出发。
3.1 真正约束
当前约束不是三条，而是五条：
FNS是唯一真源，不能被绕开llm-wiki需要一个稳定、本地、可自由读写的文件工作区- Windows / Android 只能消费“发布后的结果”，不应该消费
llm-wiki的内部缓存和工作垃圾 - Hermes 后续必须能自动化运行这个流程
- 原始笔记、整理中间态、最终知识产物，三者必须分层
3.2 真正问题
所以真正问题不是：
- “llm-wiki 放在哪个 Obsidian 目录下最好”
而是：
- “如何让一个需要本地文件工作区的系统，与一个以 FNS 为唯一权威源的多端同步系统稳定协同”
这是两个层级的问题：
工作层：llm-wiki 的本地运行时发布层：对 Obsidian / FNS 的可见结果
只要这两个层混在一起，系统就会开始发散。
4. 对旧方案 A / B / C 的重新审判
4.1 方案 A：/srv/obsidian-mirror/llm-wiki/<主题>/
旧文里它是“推荐方案”。
在旧架构下，这个判断是成立的。
在新架构下，它已经不是最优，而是条件性错误。
为什么现在不再推荐
问题 1：它默认绕开 FNS
如果 llm-wiki 直接写 /srv/obsidian-mirror/llm-wiki/...，那么它写入的是一个本地目录，不是 FNS 的权威存储语义层。
在当前架构下：
- Windows / Android 看到的是
FNS同步结果 - Hermes 的正式读写接口也是
FNS MCP /srv/obsidian-mirror/不再是主同步闭环的一部分
所以这个方案最大的问题不是“优雅不优雅”，而是：
它可能写到了一个对当前主同步平面并不 authoritative 的地方。
问题 2：它把内部工作垃圾暴露给移动端
llm-wiki 的这些东西：
raw/.wiki-cache.jsonlog.md.wiki-schema.md- 中间实体页
- 临时聚合产物
并不是所有都应该同步到手机端。
如果把它们直接放进主 Vault：
- 安卓会被迫同步大量低价值内部文件
- 图谱、搜索、最近修改、移动端文件树都会被污染
- FNS 更新日志也会被大量“机器工作痕迹”淹没
问题 3：它把“工作区”误当成“发布区”
llm-wiki 的本地工作树天然包含：
- 可回滚的中间状态
- 未审核的自动生成内容
- 跑到一半的半成品
- cache / manifest / 结构文件
这些不应该等于“最终要给 Obsidian 三端看的知识库”。
把两者合并，等于取消了发布门。
结论
方案 A 不再是当前架构下的推荐方案。
它在今天的架构里最多只能作为：
- 一个本地实验目录形式的过渡方案
不能作为正式生产方案。
4.2 方案 B：软链接桥接
这个方案在旧架构下就已经不推荐。
在新架构下更不成立。
新架构下它更糟的原因
- 它仍然建立在“本地文件系统就是主平面”的旧世界观上
- 它继续把 llm-wiki 的根锚点绑在派生层
/srv/obsidian-mirror/ - FNS 语义层并不会因为你本地做了 symlink，就获得一致性收益
- 软链接对移动端同步、目录索引、工具路径判断依旧不稳
结论
方案 B 在当前架构下应当直接排除。
4.3 方案 C：直接塞进 100_Wiki
这个方案旧文已经排除，当前仍然排除。
原因没有变，反而更严重：
- 它把 “长期成品知识” 和 “机器工作中间态” 混在一起
- 它会让
100_Wiki从成品区退化成运行时目录 - 它会破坏
100_Wiki的人工策展属性
结论
方案 C 继续排除。
5. 新的最优方案：方案 D
5.1 方案 D 名称
影子工作区（Shadow Workspace） + MCP 发布投影（Publish Projection）
这是今天基于当前架构得出的正式推荐。
一句话解释
llm-wiki在 Vault 外部运行- 它从 FNS 拉取输入快照
- 在本地工作区完成 ingest / digest / graph / crystallize
- 只把审核后的结果，通过
MCP回写到 Vault
这等于把系统拆成两层：
运行层：本地、可脏、可重建发布层：同步给所有设备、面向人阅读
5.2 推荐拓扑
┌──────────────────────────────┐
│ FNS (权威真源) │
│ vault=feng │
└──────────────▲───────────────┘
│
MCP 发布/拉取
│
┌───────┴───────┐
│ Hermes │
│ orchestration │
└───────▲───────┘
│
本地导出 / 本地运行
│
┌──────────────────────────┴──────────────────────────┐
│ /srv/llm-wiki-workspaces/<topic>/ │
│ │
│ raw/ ← 从 FNS 导出的输入快照 │
│ wiki/ ← llm-wiki 本地工作产物 │
│ log.md ← 本地运行日志 │
│ .wiki-* ← 本地缓存 / schema / 状态 │
│ publish/ ← 待发布结果 │
└──────────────────────────▲──────────────────────────┘
│
仅发布人类可读产物
│
┌──────────────┴──────────────┐
│ Vault 内的发布目标目录 │
│ │
│ 100_Wiki/<topic>/ │
│ 999_System/<topic>/│
└─────────────────────────────┘5.3 推荐目录设计
5.3.1 Vault 外：llm-wiki 工作区
推荐放在：
/srv/llm-wiki-workspaces/<topic>/推荐理由：
- 不在 FNS 主同步目录内
- 不污染 Obsidian 三端视图
- 可自由使用
.wiki-cache.json、日志、临时文件 - 可以整个删掉重建
推荐权限：
- owner:
hermes:hermes
不推荐继续挂到 openclaw 组共享权限，除非确有多人进程共用需求。
理由很简单：能缩权限就缩权限。
5.3.2 Vault 内：发布目录
推荐把发布后的内容落在：
100_Wiki/<topic>/
├── entities/
├── topics/
├── synthesis/
├── comparisons/
└── index.md
999_System/<topic>/
├── manifest.md
├── source-map.md
└── publish-log.md这里有一个关键区分：
100_Wiki/<topic>/：给人看999_System/<topic>/：给系统追踪
不要把 .wiki-cache.json 之类的内部文件同步进 Vault。
6. 为什么方案 D 比方案 A 更优
6.1 它不违反当前架构不变量
当前架构最大不变量是：
所有最终对三端生效的内容，必须通过 FNS 进入系统。
方案 D 满足这一点。
方案 A 不满足。
6.2 它把“运行时脏状态”和“发布结果”分开了
这非常重要。
llm-wiki 的原始运行目录，本质上类似：
- 编译产物目录
- 中间数据库
- 临时分析快照
你不会想把这些都直接暴露给手机端。
6.3 它更适合 Hermes 自动化
Hermes 的天然职责不是“编辑 Vault 底层目录”，而是：
- 从 FNS 取内容
- 在本地组织工具链
- 把结果按规则发布回 FNS
这正好和方案 D 的形状一致。
6.4 它允许重跑与回滚
如果某次 llm-wiki 跑坏了：
- 你可以清理工作区重建
- 不需要把 Vault 一起清掉
- 已发布内容仍然由 FNS 管理
这就是运行层和发布层分离的工程价值。
7. 对抗性审查重点
下面是从“最坏情况”出发，对设计的逆向质疑。