LLM Wiki

Appearance

Built 26/04/18 11:07commit 70d11fe

LLM Wiki 运行架构 ​

中文 | English

摘要 ​

这一页解释独立 LLM Wiki Architecture 架构图所展示的具体运行模型：每个分区是什么意思、每条连线是什么意思，以及为什么有些关系被显式画出来，而有些关系则保持隐含。

这页和 知识库架构 不同。Vault Architecture 解释的是仓库的耐久三层模型；这一页解释的是从采集到维护再到发布的日常运行路径。

分区含义 ​

Capture Inputs ​

这个分区表示系统的来源入口侧。

  • Chrome 表示通过浏览器和 clipper 进行网页采集。
  • Notes 表示手工文本记录、本地草稿和直接 markdown 编辑。
  • Images 表示截图和其他视觉证据，后续可能通过 OCR 参与解释。

之所以把它们拆开，是因为它们是不同的输入模态，虽然最终都会影响同一个本地仓库。

Local Knowledge Workspace ​

这个分区表示本地工作面和耐久本地状态。

  • llm-wiki repo 是仓库本体，包含 raw/、wiki/、文档和仓库规则。
  • Obsidian 是主要的本地阅读与编辑界面。
  • Bilingual corpus 强调耐久页面以英文加 .zh sibling 的方式维护。
  • Rules and memory 指 AGENTS.md、index.md 和 log.md，它们约束维护应如何落地。

本地工作区被刻意画成主中心，因为这套系统是本地优先的：采集、综合和作者工作都先发生在这里，之后才进入发布。

Codex Maintenance Boundary ​

这个分区表示维护层，而不是一个单独部署出来的服务。

  • Ingest Loop 表示来源整合工作。
  • Codex agent 表示读取仓库规则并执行更新的维护会话。
  • Wiki outputs 表示被写回仓库的耐久综合结果。

外层粉色虚线框表示“逻辑上的维护边界”，不是一个隔离运行时环境。

Versioning & Site Build ​

这个分区表示从本地维护状态到可分享站点输出的路径。

  • Git workflow 表示本地 commit 和有意图的历史打包。
  • GitHub 表示权威远端和共享 source of truth。
  • VitePress 表示把仓库内容渲染成可读网站的静态构建层。

Hosted Access ​

这个分区表示交付和消费。

  • Vercel 负责托管部署。
  • Public URL 是稳定的浏览器入口。
  • Readers 代表真正从桌面和手机浏览器消费内容的读者。

连线类型 ​

图里用不同连线样式表达不同含义。

  • 灰色实线箭头表示主运行流。
  • 粉色虚线箭头表示维护侧的辅助路径，而不是主发布链路。
  • Hosted 分区中的竖向箭头是为了让右侧结构更易读而做的布局化简。

这张图是选择性的，不是穷举性的。它只画出理解系统端到端运行所必须的关系，不会把每个框之间所有可能依赖全部画出来。

逐条连线解释 ​

从采集到工作区 ​

  • Chrome -> llm-wiki repo：浏览器中裁剪的内容会落成当前仓库里的本地来源材料。
  • Notes -> Obsidian：手工写作和本地编辑通常先通过本地编辑界面发生。
  • Images -> Bilingual corpus：截图和视觉证据在被解释后，常常会影响耐久知识层。

这些箭头表示的是最有代表性的落点路径，不是唯一可能存在的路径。

从工作区到维护层 ​

  • llm-wiki repo -> Ingest Loop：新的或更新过的来源材料是 ingest 工作的主要触发器。
  • Obsidian -> Codex agent：本地阅读、编辑和检查往往会先于或伴随维护会话出现。
  • Bilingual corpus -> Wiki outputs：耐久知识是通过维护被延展，而不是每次都重新生成。

从维护到发布 ​

  • Codex agent -> GitHub：一旦维护作为 commit 过的仓库状态落地，它就进入权威远端路径。
  • GitHub -> Public URL：公开站点最终依赖于版本化远端状态和后续部署流程。

中间偏右的分区没有把 Git workflow、GitHub、VitePress、Vercel 之间每一条中间箭头都画出来。这些关系仍然存在，只是图里做了压缩，以保持主流程可读。

Hosted 区域中的竖线 ​

  • Public URL -> Vercel：公开入口背后有托管平台支撑。
  • Public URL -> Readers：同一个入口也是浏览器真正消费的对象。

之所以竖着画，是因为右侧 Hosted 区域本身就是按交付块纵向组织的。

粉色虚线箭头 ​

粉色虚线箭头刻意与主实线箭头区分开。

  • 它表示维护侧的辅助路径。
  • 它不是主发布链路。
  • 它的作用是说明某些维护动作会把系统往后推进，但它不是整张图的主端到端流。

所以它使用的是粉色虚线，而不是灰色实线。

为什么有些框之间没有直接连线 ​

没有画线是有意为之。

同一区域已经足够表达关系 ​

有些框被放在同一个分区里，本身就足以说明它们之间的关系。

例如：

  • Obsidian 和 llm-wiki repo 同处本地工作区，因为前者就是后者的主要编辑界面。
  • Rules and memory 概念上会影响维护，但仓库规则已经通过本地工作区和维护边界叙事体现出来。

关系真实存在，但不是主表达重点 ​

有些依赖没有画出来，是因为画上之后只会增加密度，却不会明显提升理解。

例如：

  • Git workflow -> GitHub
  • GitHub -> VitePress
  • VitePress -> Vercel

这些关系都成立，但如果每一条都单独画出来，中右侧会更拥挤，而它们表达的故事与当前分区结构已经传达的内容高度重复。

这张图优先追求运行模型清晰，而不是穷举 ​

它不是依赖图生成器输出，而是一张运行模型图。

因此规则是：

  • 如果去掉一条线会让生命周期变得模糊，那就画出来
  • 如果外围分区或邻近流向已经足够说明关系，就可以不画

设计意图 ​

这套架构偏向本地优先、发布路径紧凑的运行模型。

  • 采集从普通本地工具开始
  • 耐久综合被写回同一个仓库
  • 版本控制保持可见且有意图
  • 仓库状态被 push 之后，发布自动发生
  • 浏览器访问被视为下游展示层，而不是编辑系统本身

相关页面 ​