Show HN: 你的代理维护的 Karpathy 风格 LLM 维基（Markdown 和 Git）

Source: Hacker News

Overview

我为 AI 代理实现了一个 wiki 层，使用 Markdown + Git 作为唯一真相来源，并在其上构建了 Bleve（BM25）+ SQLite 索引。它本地运行在 ~/.wuphf/wiki/，可以通过 git clone 将你的知识随身携带。设计遵循 Karpathy 风格的 LLM‑原生知识基底：代理既可以读取也可以写入 wiki，因而上下文会在会话之间累积，而不是每天早上重新粘贴。

Features

• 私有笔记本 – 每个代理在 agents/{slug}/notebook/.md 拥有自己的笔记本，并可访问位于 team/ 的共享团队 wiki。
• 草稿‑到‑wiki 推广流程 – 笔记本条目经过（代理或人工）审阅后，以反向链接的形式提升为正式 wiki 条目。一个小型状态机负责过期和自动归档。
• 实体事实日志 – 位于 team/entities/{kind}-{slug}.facts.jsonl 的追加式 JSONL 文件。合成工作者会每 N 条事实重建一次实体简介。提交使用独立的 “Pam the Archivist” Git 身份，以便在 Git 日志中看到来源。
• Wikilinks – [[Wikilinks]]，并具备断链检测（以红色显示）。
• 每日 lint 定时任务 – 检查矛盾、陈旧条目以及断开的 wikilink。
• 查询工具 – /lookup 斜杠命令以及用于引用检索的 MCP 工具。启发式分类器将短查询路由到 BM25，将叙事查询路由到引用‑答案循环。

Substrate Choices

• Markdown 以保证持久性：wiki 能够超越运行时存在，用户可以把每一个字节带走。
• Bleve 用于 BM25 检索。
• SQLite 用于结构化元数据（事实、实体、边、重定向、取代）。目前尚未使用向量。
• Benchmark（500 条文档，50 条查询）在仅使用 BM25 时达到 85 % recall@20，满足内部发布门槛。若某类查询的召回率低于该值，sqlite-vec 将作为预先准备的后备方案。
• Canonical IDs 为一等公民。事实 ID 是确定性的，包含句子偏移。规范化 slug 只在首次分配时生成，通过重定向桩合并，且永不更改。重建过程在逻辑上相同，虽非字节相同。

Known Limits

• 召回率调优仍在进行中；基准测试的 85 % 并非通用保证。
• 合成质量受限于代理的观察质量——“输入垃圾，输出垃圾”。lint 步骤有帮助，但系统并非判断引擎。
• 目前仅面向单一办公室；不支持跨办公室联邦。

Demo

一个 5 分钟的终端演示记录了五条事实，触发合成，调用用户的 LLM CLI，并以 Pam 的身份提交结果：

https://asciinema.org/a/vUvjJsB5vtUQQ4Eb

脚本位于 ./scripts/demo-entity-synthesis.sh。

Context

该 wiki 随 WUPHF 一起发布，WUPHF 是一个开源的 AI 代理协作办公平台，支持 Claude Code、Codex、OpenClaw 以及通过 OpenCode 接入的本地 LLM。它采用 MIT 许可证，可自行托管，并支持自带密钥。你 不必 使用完整的办公套件即可使用 wiki 层；如果已有代理配置，只需将 WUPHF 指向它，wiki 即会自动挂载。

• Source repository:
• Installation:

npx wuphf@latest

Further Discussion

我乐于进一步探讨：

• 基础层的权衡
• 推广流程状态机
• BM25‑优先检索策略
• 规范 ID 稳定性规则

如果你想了解为何不直接使用带插件的 Obsidian vault，也欢迎提问，我会一并说明。