WUPHF – Ein System, in dem Agents ein LLM-Wiki im Karpathy-Stil selbst pflegen
(github.com/nex-crm)- Eine Markdown- & Git-basierte Wiki-Schicht für AI-Agents
- Eine LLM-native Wissensbasis-Schicht, die so entworfen wurde, dass AI-Agents Kontext über Sitzungen hinweg ansammeln können; sie wird lokal unter
~/.wuphf/wiki/gespeichert und kann pergit clonekomplett übernommen werden - Statt schwergewichtiger Infrastruktur wie Postgres, pgvector, Neo4j oder Kafka besteht das System nur aus Markdown + Git und verwaltet Wissen ohne Vektor-DB mit BM25 + SQLite
- Speicherung in Markdown, BM25-Suche mit bleve und Verwaltung strukturierter Metadaten (facts, entities, edges, redirects, supersedes) mit SQLite
- Im Benchmark ohne Vektor-DB wurden mit 500 Artefakten und 50 Abfragen 85 % recall@20 erreicht
- Für den Fall, dass bestimmte Query-Klassen unter diesen Wert fallen, ist der Einsatz von sqlite-vec geplant
- Jeder Agent besitzt ein persönliches Notebook unter
agents/{slug}/notebook/*.mdund hat Zugriff auf das gemeinsame Wiki unterteam/- Es gibt einen Ablauf, bei dem Notebook-Einträge nach Review durch Agent oder Mensch ins Wiki befördert (promotion) werden; Backlinks werden automatisch erzeugt
- Eine kleine Zustandsmaschine verwaltet Ablaufdaten (expiry) und automatische Archivierung
- Per-entity fact log: Aufzeichnung als append-only JSONL in
team/entities/{kind}-{slug}.facts.jsonl- Ein Synthese-Worker baut nach jeweils N facts den Entity-Brief neu auf; Commits werden mit einer separaten Git-Identität namens "Pam the Archivist" hinterlassen, sodass die Herkunft direkt im
git logsichtbar ist - Fact-IDs sind deterministische IDs inklusive Satz-Offset; ein canonical slug wird nur einmal vergeben, später per Redirect-Stub zusammengeführt und darf niemals geändert werden
- Rebuilds sind logisch identisch, aber Byte-für-Byte-Identität wird nicht garantiert
- Ein Synthese-Worker baut nach jeweils N facts den Entity-Brief neu auf; Commits werden mit einer separaten Git-Identität namens "Pam the Archivist" hinterlassen, sodass die Herkunft direkt im
- Unterstützung für [[Wikilinks]]; defekte Links werden rot dargestellt, und ein täglicher lint cron erkennt Widersprüche, veraltete Einträge und kaputte Wikilinks
- Bietet zitationsbasierte Suche über den Slash-Command
/lookupund MCP-Tools- Ein heuristischer Klassifikator leitet kurze Anfragen an BM25 weiter und beschreibende Queries in einen cited-answer-Loop
- Bekannte Einschränkungen
- Das Recall-Tuning läuft noch; 85 % sind kein allgemein garantierter Wert
- Die Qualität der Synthese hängt von der Qualität der von Agents erfassten facts ab (garbage in, garbage out); lint hilft unterstützend, ist aber keine Entscheidungs-Engine
- Derzeit auf einen einzelnen Office-Bereich beschränkt, keine Unterstützung für office-übergreifende Federation
- Wird als Teil von WUPHF bereitgestellt (Open-Source-AI-Agent-Office mit Unterstützung für Claude Code, Codex, OpenClaw und lokale LLMs), aber die Wiki-Schicht kann auch allein genutzt werden — wenn WUPHF an ein bestehendes Agent-Setup angebunden wird, wird das Wiki automatisch angehängt
- MIT-Lizenz
1 Kommentare
Hacker-News-Kommentare
Ich verstehe den Sinn von Notiz-Automatisierung nicht so recht. Früher hat es auch überhaupt nicht geholfen, Text einfach per Copy-paste in Notizen zu kippen – warum sollte es anders sein, wenn man das jetzt nur hundertfach skaliert?
Für mich liegt der Kern von Notizen darin, Quellen kritisch zu lesen, sie in mein mentales Modell einzuordnen und das dann festzuhalten.
Details kann man später nachschlagen; entscheidend ist letztlich der Prozess, dieses Modell zu verfeinern.
Dann könnte das Ziel auch sein, dieses mentale Modell gar nicht selbst aufzubauen, sondern an ein geteiltes LLM brain auszulagern.
Ich habe allerdings erhebliche Zweifel, ob man mit so einem Ansatz etwas schaffen kann, das für einen Product Owner wirklich wertvoll ist. Wenn man mit Prompts und Agent-Harnesses allein ein wertvolles Produkt bauen kann, dann kann dieses Produkt im Grunde jeder nachbauen, Produktentwicklung wird zur Commodity und am Ende bleiben womöglich nur die Tokens als Wert übrig.
Meine Hypothese ist, dass Paul Grahams do things that don’t scale auch künftig gültig bleibt – nur der Inhalt dieser nicht skalierenden Arbeit könnte sich stark verändern.
Trotzdem habe ich vor Kurzem angefangen, Obsidian wirklich richtig zu nutzen. Nachdem ich Skills für Notizen, Recherche, Verlinkung, Aufteilung und den Umbau der Wissensbasis eingerichtet habe, fühlt es sich an, als hätte ich einen digitalen Assistenten, der für mich Ordnung hält.
Jetzt muss ich nur lose Gedanken aufschreiben, und der Agent gibt ihnen Struktur, stellt Anschlussfragen und verknüpft sie mit anderer Arbeit. Das Lesen von Quellen und das Bilden meines mentalen Modells mache ich weiterhin selbst, aber hochwertige Notizen bekomme ich inzwischen fast zum Nulltarif.
Das ist eine enorme Verschwendung.
Das meiste müsste gar nicht erst in Notizen landen, und LLMs erhöhen das Rauschen massiv, ohne vernünftig zu validieren oder zu filtern.
Ein Video, das das Thema gut behandelt, ist der Essay von JA Westenberg.
https://youtube.com/watch?v=3E00ZNdFbEk
Das fand ich ziemlich interessant.
Ich denke, das Optimum liegt bei menschlicher Kuratierung, und unbeaufsichtigter Betrieb ist besonders dann keine Lösung, wenn man debt oder drift nicht bewusst managt.
Zumal der Name auch noch derselbe ist wie bei dem nutzlosen und redundanten Produkt Wuphf.com aus The Office.
Es wirkt fast so, als kämen Milliarden Dollar, sobald man nur AI in den Produktnamen schreibt, und als würde man zum Principal Engineer bei Anthropic eingestellt, wenn man Karpathy in einen Blogpost packt.
Das sieht vor allem nach dem Versuch aus, Geld aus einem Trend herauszupressen, solange er anhält – und weniger danach, sich dafür zu interessieren, was Kund:innen eigentlich brauchen.
Alle rennen los, nach dem Motto: Wenn schon eine Welle kommt, kann man sich wenigstens die Hände darin waschen.
Damals hat man immerhin tatsächlich etwas gebaut, und das knappere Funding-Umfeld hat die Überhitzung etwas gedämpft.
Der aktuelle LLM-Boom hat zumindest ein gewisses Maß an realer Machbarkeit und echtem Wert, und es ist auch eine ziemlich interessante Technologie zum Lernen und Ausprobieren.
Ich habe schon vor langer Zeit akzeptiert, dass man dort Chancen nutzen sollte, wo Geld hinfließt – solange es nicht unethisch ist. Während VC-/PE-Geld im Überfluss vorhanden ist, kann man durchaus etwas Wertvolles und Cooles bauen.
Ich warte immer noch auf ein wirklich erstklassiges CLI-Harness als Ersatz für Claude Code. Ich brauche etwas, das Memory- und Design-Probleme löst.
Webdesign ist mit LLMs immer noch nahezu ein Albtraum.
Wir haben Enterprise-PoCs gemacht, und all das ist schließlich in diesem Projekt kondensiert, das ich nebenbei gebaut habe, um meine eigene Arbeit zu unterstützen. Am Ende war genau das hier die Schnittstelle, die context infra wirklich gut nutzbar gemacht hat.
Ich habe kein Interesse an einer Stelle als Principal Engineer bei Anthropic. Früher war ich Product Manager bei HubSpot, habe deutlich besser verdient als heute, und wahrscheinlich werde ich dieses Niveau auch in den nächsten Jahren nicht wieder erreichen.
Ich habe mehrfach gewettet und immer weiter iteriert, weil sich das Produkt im direkten Gespräch mit Kund:innen entwickelt hat. Frühere Wettbewerber bauen derweil immer noch heimlich an einem AI-CRM.
Als jemand, der schon lange in der Branche ist, halte ich die Welle selbst nicht für das Entscheidende – aber ich glaube durchaus, dass es unter dieser Welle substanziellen Wert zu bergen gibt.
Ich habe diese Review gesehen: https://zby.github.io/commonplace/agent-memory-systems/reviews/wuphf/
Das ist bereits das dritte LLM-Wiki, das innerhalb von 24 Stunden auf der Frontpage landet – also definitiv ein heißes Thema.
Ich habe in diesem Bereich eigene Interessen und bin daher nicht völlig objektiv, aber ich habe separat aufgeschrieben, was ich mir von solchen Systemen wünsche.
https://zby.github.io/commonplace/notes/designing-agent-memory-systems/
Dass alle jeweils ihr eigenes System neu bauen, wirkt wie eine enorme Doppelarbeit; ich wünschte, es gäbe einen Weg zur Zusammenarbeit.
Am Stil ist allerdings ziemlich klar zu erkennen, dass sie von einem LLM geschrieben wurden. Daher frage ich mich, ob du solche Design-Notizen später noch einmal in deinen eigenen Worten zusammenfasst, um zu prüfen, ob wirklich deine eigenen Gedanken darin stecken.
Wir sind mit nex.ai als context infra-Firma gestartet, lange bevor Karpathy die Idee eines LLM-Wikis ins Spiel gebracht hat, und auch wenn man das in WUPHF bisher kaum sieht, öffnen wir diese Funktionen jetzt nach und nach.
Viele der Bedenken in dem Vergleich betreffen genau Dinge, an denen wir in unserer context infra bereits gearbeitet haben, deshalb habe ich mich gefreut, das zu lesen.
Trotzdem ist jede Zusammenarbeit willkommen, die Redundanz reduziert und gegenseitiges Lernen fördert.
Du meintest, du würdest dir Gelegenheiten zur Zusammenarbeit wünschen – deshalb wundert es mich, dass es so klingt, als gäbe es diese Gelegenheit im Moment nicht.
Wenn man auf ein Obsidian-Vault nur QMD draufsetzt, ist man vermutlich schon bei 80 %, und das dauert wahrscheinlich nicht mal zwei Stunden.
Der Vollständigkeit halber hier auch der Original-Link von Karpathy
https://x.com/karpathy/status/2039805659525644595
https://xcancel.com/karpathy/status/2039805659525644595
Ich frage mich, ob AI Notes echten Mehrwert bringen oder nur noch mehr Rauschen erzeugen.
Den ASCII-Stil der Website mag ich aber ziemlich.
Als Lösung für dieses Problem fände ich etwas wie eine StackOverflow-Wiederbelebung sinnvoll.
Menschen kuratieren, aber wenn kollektive LLMs beim Lösen eines Problems festhängen, posten sie auf die klassische Weise eine Frage – also ein verteiltes Wissensgraph-System.
Ich fände es völlig okay, wenn mein Agent sagt: „Hier komme ich nicht weiter, ich habe die Frage auf SO gestellt, lass uns später zurückkommen, wenn eine Antwort da ist.“
Ich frage mich, wie man verhindern kann, dass ein LLM zu viel schreibt.
Ich habe ein paar ähnliche Tools und Systeme gebaut, und bei allen hat das LLM die Dokumentation immer weiter aufgebläht, bis das gesamte System unübersichtlich wurde und mit zunehmender Größe immer weniger nützlich war.
Eines meiner früheren Experimente war, dem LLM nur ein paar Links zu geben, damit es verwandte Themen recherchiert und ein eigenes knowledge wiki aufbaut, in dem jede Seite Zusammenfassungen, Querverweise und Quellen enthält.
Auf den ersten Blick sah das gut aus, aber wenn man die echten Daten gelesen hat, war es eher enttäuschend.
Das Experiment liegt ein paar Jahre zurück; vielleicht wäre es heute einen neuen Versuch mit etwas wie opus 4.7 wert.
Als Denkanstoß: Auch die TiddlyWiki-Community hat natürlich AI-Tools erforscht.
TiddlyWiki ist ein Wiki auf Basis einer einzelnen HTML-Datei, das sich selbst verändern kann, und existiert seit über 20 Jahren.
Es hat sich nicht unbedingt in eine agentische Umgebung weiterentwickelt, aber es gibt ein Markdown-Plugin und auch Tools, um Dateien ausführbar zu machen oder in Self-Service-Webapps zu verwandeln. Git ist allerdings etwas umständlich.
Theoretisch wäre also auch ein einzelnes agentic wiki denkbar, das umherzieht und sich selbst verändert.
https://tiddlywiki.com/
Die von dir erwähnte single-file-Struktur hat bereits mehrere LLM-Connectoren, zum Beispiel https://github.com/rimir-cc/tw-llm-connect
Genau das macht sie so attraktiv. Es gibt keine Abhängigkeiten, keine Installation ist nötig, und die Ablage ist sehr einfach – ein einzelnes agentisches Wiki in einer Datei, das sich selbst bearbeitet, ist also heute schon machbar.
Näher am LLM-Wiki-Muster von Karpathy ist auch twillm, an dem ich gerade arbeite.
https://github.com/Jermolene/twillm
Das nutzt die Node.js-Konfiguration von TiddlyWiki, speichert Tiddler als einzelne Dateien und kann direkt auf bestehende Markdown-Vaults zeigen, zusammen mit Tools wie Claude Code.
Die Vorteile von TiddlyWiki sind ebenfalls ziemlich klar. Es ist Open Source und damit langfristig weiter nutzbar, und weil es webbasiert ist, kann man von überall darauf zugreifen.
Außerdem ersetzen berechnete Ansichten materialisierte Indexdateien. Beim Karpathy-Ansatz muss das LLM index.md jedes Mal weiter synchronisieren, wenn es neue Notizen hinzufügt, und genau solche Dinge werden mit wechselnden Sessions leicht stale – etwas, worin LLMs besonders schlecht sind.
Die Ansichten in TiddlyWiki sind dagegen Echtzeit-Filterausdrücke: Ein Ergebnis wie „sortiere Tiddler mit dem Tag concept nach Bewertung“ wird also direkt beim Rendern berechnet.
Frontmatter wird ebenfalls zu einer abfragbaren Struktur. Obsidian zeigt YAML-Frontmatter als kastenförmige Metadaten oben in der Notiz an, während TiddlyWiki diese Felder zu erstklassigen Tiddler-Feldern macht, die sofort zum Filtern, Sortieren und Aggregieren genutzt werden können.
Und LLMs können nicht nur Inhalte schreiben, sondern auch kleine Applets. Zusätzlich zu Markdown-Notizen können sie Wikitext-Tiddler (.tid) anlegen, um interaktive Live-Ansichten wie Dashboards, Tag-Navigation, Journal-Indizes oder Glossare zu bauen.
Der Bereich self building artefacts ist spannend und wächst gerade stark, vor allem weil LLMs – insbesondere Coding-Modelle – in letzter Zeit sehr schnell besser darin werden.
Ich habe kürzlich ebenfalls ein Projekt ausprobiert, das auf minimale Abhängigkeiten und lokale Kontrolle von Agenten setzt.
https://github.com/GistNoesis/Shoggoth.db/
Es erstellt und pflegt selbstständig eine sqlite-Datenbank, um langfristige Aufgaben auszuführen, die man per Prompt vorgibt, und verwendet als Quelldaten eine lokale Kopie der Wikipedia.
Ich habe außerdem nur ein sehr minimales Harness und einige wenige Tools eingebaut, um Agent drift zu untersuchen.
Auch Bildverarbeitung lässt sich recht leicht ergänzen. Man kodiert Bilder einfach in base64 und übergibt sie an llama.cpp; die Details kann man mit einem lokalen LLM grob vibecoden.
Ich halte das für ein ziemlich allgemein nützliches Werkzeug.
Früher hatte ich zum Beispiel ein Skript, das aus Rechnungen und Belegen in einem Ordner Beträge, Daten und Händler extrahierte, dafür Amazon Textract nutzte und anschließend von Menschen prüfen ließ, bevor eine CSV für den Steuerberater entstand.
Heute könnte man diesen Amazon-Textract-Aufruf durch einen llama.cpp-Modellaufruf mit geeignetem Prompt ersetzen, das bestehende Rechnungs-Tool weiterverwenden und dabei sogar deutlich kreativere Buchhaltungsabläufe ermöglichen.
Ich habe auch eine Variante ausprobiert, die einen physischen Roboter anhand einer Sequenz von Kamerabildern steuert; in einfachen Fällen hat er sich tatsächlich bewegt und das Ziel erreicht.
Das war allerdings nicht praktisch, weil das von mir genutzte LLM nie fürs Roboterfahren trainiert wurde und 10 Sekunden brauchte, um die nächste Aktion auszuwählen. Ein klassischer, nicht auf Deep Learning basierender Controller fährt den Vision-Loop derzeit mit 20 Hz.
LLM-Modelle und darauf aufbauende Agenten sind nicht deterministisch, sondern probabilistisch.
Sie schaffen Dinge mit einer gewissen Trefferquote, aber eben nicht jedes Mal.
Deshalb steigt die Ausfallwahrscheinlichkeit weiter an, je länger ein Agent an einer einzelnen Aufgabe arbeitet. Solche langlaufenden Agenten werden am Ende scheitern und dabei auch noch enorme Token-Kosten verbrennen.
Eine Sache, die LLM-Agenten gut können, ist das Umschreiben ihrer eigenen Instruktionen.
Der Trick besteht darin, Zeit und Denkstufen eines Thinking-Modells zu begrenzen und dann zu evaluieren, zu aktualisieren und erneut zu starten.
Als Metapher kann man sagen: Agenten fallen hin. Man sollte sie also nicht so lange laufen lassen, bis sie stürzen – zweimal 5 Minuten ist besser als einmal 10 Minuten.
Ich vermute, dass solche selbstreferenziellen Agenten in wenigen Wochen überall ganz oben in den Twitter-Feeds auftauchen werden.
Deshalb ist es gut möglich, dass solche Wikis ab einem bestimmten Zustand einfach stehenbleiben.