24小时热榜

我为人工智能代理开发了一个维基层，使用Markdown和Git作为真实数据源，并在其上构建了一个Bleve（BM25）和SQLite索引。目前还没有使用向量或图数据库。 该系统在本地运行于~/.wuphf/wiki/，如果你想带走你的知识，可以通过Git克隆它。 这个形状是Karpathy一段时间以来一直在关注的：一个LLM原生的知识基础，代理既可以从中读取也可以写入，因此上下文在会话之间得以累积，而不是每天早上重新粘贴。大多数实现这个想法的方案使用Postgres、pgvector、Neo4j、Kafka和一个仪表板。 我想回归基础，看看Markdown和Git能走多远，然后再添加更复杂的东西。 它的功能包括： - 每个代理都有一个私有笔记本，位于agents/{slug}/notebook/.md，同时可以访问位于team/的共享团队维基。 - 草稿到维基的推广流程。笔记本条目由代理或人类审核，并以反向链接的形式推广到规范维基。一个小型状态机负责过期和自动归档。 - 每个实体的事实日志：在team/entities/{kind}-{slug}.facts.jsonl中以追加方式存储的JSONL。合成工作者每N个事实重建一次实体摘要。提交以独特的“Pam the Archivist”Git身份记录，以便在Git日志中可见来源。 - [[Wikilinks]]，并且断链检测以红色显示。 - 每日的Lint定时任务，用于检查矛盾、过时条目和断链。 - /lookup斜杠命令以及一个用于引用检索的MCP工具。启发式分类器将短查询路由到BM25，将叙述查询路由到引用答案循环。 基础选择： 使用Markdown以确保持久性。维基超越运行时，用户可以带走每一个字节。使用Bleve进行BM25检索。使用SQLite存储结构化元数据（事实、实体、边缘、重定向和替代）。目前还没有使用向量。当前基准（500个文档，50个查询）在仅使用BM25的情况下达到了85%的召回率@20，这是内部发布的门槛。如果某个查询类别低于该值，将使用预先承诺的sqlite-vec作为后备。 规范ID是第一类公民。事实ID是确定性的，并包括句子偏移量。规范slug只分配一次，通过重定向存根合并，并且永不重命名。重建在逻辑上是相同的，而不是字节上相同。 已知限制： - 召回调优仍在进行中。基准上的85%并不是普遍保证。 - 合成质量受代理观察质量的限制。垃圾事实输入，垃圾摘要输出。Lint检查有帮助，但它不是判断引擎。 - 当前仅限于单一办公室范围。没有跨办公室的联合。 演示：5分钟的终端演示，记录五个事实，触发合成，切换到用户的LLM命令行界面，并在Pam的身份下提交结果： [https://asciinema.org/a/vUvjJsB5vtUQQ4Eb](https://asciinema.org/a/vUvjJsB5vtUQQ4Eb) 脚本位于./scripts/demo-entity-synthesis.sh。 背景：该维基作为WUPHF的一部分发布，WUPHF是一个开源的协作办公环境，适用于像Claude Code、Codex、OpenClaw和通过OpenCode的本地LLM。MIT许可，自托管，用户自带密钥。你不必使用完整的办公环境就可以使用维基层。如果你已经设置了代理，只需将WUPHF指向它，维基将自动附加。 源代码：[https://github.com/nex-crm/wuphf](https://github.com/nex-crm/wuphf) 安装：npx wuphf@latest 我很乐意深入讨论基础的权衡、推广流程的状态机、BM25优先的检索策略或规范ID的稳定性规则。也很乐意回答“为什么不使用带插件的Obsidian库”这个合理的问题。