WUPHF - KarpathyスタイルのLLMウィキをエージェントが直接維持するシステム
(github.com/nex-crm)- Markdown & GitベースのAIエージェント向けウィキレイヤー
- AIエージェントがセッションをまたいでコンテキストを蓄積できるよう設計されたLLMネイティブな知識基盤レイヤーで、
~/.wuphf/wiki/にローカル保存され、git cloneで丸ごと取得可能 - Postgres、pgvector、Neo4j、Kafkaのような重いインフラの代わりに、markdown + gitだけで構成し、ベクターDBなしでBM25 + SQLiteによる知識管理を実現
- markdownで保存し、bleveでBM25検索、SQLiteで構造化メタデータ（facts、entities、edges、redirects、supersedes）を管理
- ベクターDBを使わない状態で、500個のアーティファクト・50個のクエリのベンチマーク基準で**recall@20 85%**を達成
- 特定のクエリクラスがこの基準を下回る場合に備え、sqlite-vecの利用を予定
- 各エージェントは
agents/{slug}/notebook/*.mdパスに個人ノートブックを持ち、team/パスの共有ウィキにアクセス- ノートブック項目をエージェントまたは人間がレビューした後、ウィキへ**昇格（promotion）**するフローがあり、バックリンクが自動生成される
- 小さなステートマシンが期限切れ（expiry）と自動アーカイブを管理
- Per-entity fact log:
team/entities/{kind}-{slug}.facts.jsonlにappend-only JSONLとして記録- 合成ワーカーがN個のfactごとにentity briefを再構築し、コミットは**"Pam the Archivist"**という別のgit identityで残されるため、出典を
git logですぐ確認できる - Fact IDは文のオフセットを含む決定論的IDで、canonical slugは一度付与された後、redirect stubとしてマージされ、絶対に変更されない
- rebuildは論理的には同一だが、バイト単位での同一性は保証されない
- 合成ワーカーがN個のfactごとにentity briefを再構築し、コミットは**"Pam the Archivist"**という別のgit identityで残されるため、出典を
- [[Wikilinks]]をサポートし、壊れたリンクは赤でレンダリングされ、毎日のlint cronが矛盾・古い項目・壊れたウィキリンクを検出
/lookupスラッシュコマンドとMCPツールで引用ベース検索を提供- ヒューリスティック分類器が短い照会はBM25に、説明的なクエリはcited-answerループにルーティング
- 既知の制限
- recallのチューニングは進行中であり、85%は汎用的に保証される数値ではない
- 合成品質はエージェントが記録したfactの品質に依存し（garbage in, garbage out）、lintは補助するが判断エンジンではない
- 現在は単一オフィスの範囲で、クロスオフィスのフェデレーションは未対応
- WUPHF（Claude Code、Codex、OpenClaw、ローカルLLMをサポートするオープンソースAIエージェントオフィス）の一部として提供されるが、ウィキレイヤー単体でも利用可能 — 既存のエージェントセットアップにWUPHFを接続するとウィキが自動で追加される
- MITライセンス
1件のコメント
Hacker Newsの意見
ノート自動化の要点がよくわからない。以前もテキストをコピペしてノートに入れるやり方はまったく役に立たなかったのに、今それを100倍にしたからといって変わるのだろうかと思う
自分にとってノートの核心は、出典を批判的に読み、自分のメンタルモデルに合わせて咀嚼したうえで、それを記録することにある
詳細は後から調べればいいし、結局重要なのはそのモデルを磨く過程だ
だとすると、わざわざそのメンタルモデルを自分で作らず、共有されたLLM brainに渡すのが目的なのかもしれない
ただ、こうしたアプローチでプロダクトオーナーに本当に価値のある何かを作れるのかはかなり疑わしい。プロンプトとエージェントハーネスだけで価値ある製品が作れるなら、その製品は誰でも再現でき、製品開発そのものがcommodityになり、結局価値が残るのはトークンだけかもしれない
私の仮説では、Paul Grahamのdo things that don’t scaleは今後も有効であり続けるが、そのスケールしない仕事の中身だけが変わる可能性が高い
それでも最近、私はObsidianを本格的に使い始めた。ノート作成、調査、リンク接続、分割、ナレッジベース再構成のためのスキルを設定しておくと、整理を代行してくれるデジタル秘書ができたような感覚だ
いまでは雑多な考えを書き留めるだけでエージェントが構造を整えてくれ、追加の質問も投げ、他の作業ともつないでくれる。出典を読み、メンタルモデルを作るのは依然として自分だが、質の高いノートはほとんど無料同然で得られている
とてつもない無駄だ
たいていのものはそもそもノートに入れる必要がなく、LLMは検証やフィルタリングもろくにしないままノイズを増やしすぎる
このテーマをうまく扱った動画としてJA Westenbergのエッセイがあった
https://youtube.com/watch?v=3E00ZNdFbEk
かなり興味深かった
私の考えでは最適点は人間によるキュレーションで、特にdebtやdriftを意識的に管理しないなら、無監督運用は答えにならない
しかも名前がThe Officeに出てきたあの無用で重複した製品Wuphf.comと同じなので、なおさらそう感じた
製品名にAIと付けるだけで数十億ドルが付いてきて、ブログ記事にKarpathyと入れるだけでAnthropicの主席エンジニアに採用される、そんな空気に見える
流行が続く間に金を絞り取ろうとする動きばかりで、顧客が何を必要としているかはあまり見ていない感じだ
みんな波があるうちにせめて手でも洗っておこうという調子で走っている
それでも当時は実際に何かを作ってはいたし、あの頃の厳しめの資金環境が過熱を多少は抑えていた
今回のLLMブームは少なくとも実際の可能性と価値がある程度あり、学んで触ってみるにもかなり面白い技術だ
私はかなり前から、こういうところに金が集まるなら、非倫理的でない限り、そこで機会をつかむのが正しいと受け止めてきた。VC/PE資金があふれている間に、価値あるクールなものを作ることもできる
私はいまだにClaude Codeに代わる世界級のCLIハーネスを待っている。メモリ問題と設計問題を解決してくれるものが必要だ
WebデザインはまだLLMでやるには悪夢に近い
エンタープライズPoCもやったし、そのすべてが結局は自分の個人的な作業を助けるために横で作っていたこのプロジェクトへと凝縮された。結果として、context infraを実際に使いやすいインターフェースにしたのがまさにこれだった
Anthropicの主席エンジニア職には興味がない。以前はHubSpotのProduct Managerで、収入も今よりずっと良く、今後数年もその水準は稼げない可能性が高い
何度も賭けて何度も修正したのは、顧客と直接話しながら進化してきたからだ。一方で以前の競合はまだAI CRMをステルスで作っている
業界に長くいる立場からすると、波そのものは重要ではないが、その波の下にある実質的な価値は確かにあると思う
このレビューを見た: https://zby.github.io/commonplace/agent-memory-systems/reviews/wuphf/
24時間以内にフロントページに上がった3つ目のLLM wikiなので、確かに熱い話題だ
私もこの分野に利害関係があるので完全に客観的ではないが、こうしたシステムに求めることを別にまとめてある
https://zby.github.io/commonplace/notes/designing-agent-memory-systems/
みんながそれぞれ自分のシステムを作り直しているのは重複投資が大きすぎるように見えるので、協業できる道があればいいと思う
ただ文体を見るとLLMが書いたのが明らかに見えるので、こういう設計ノートは後で自分の言葉でまとめ直して、本当に自分の考えが入っているか確認するタイプなのか気になる
私たちはKarpathyがLLM wikiのアイデアを出すずっと前から、nex.aiというcontext infra企業として始めていて、その機能はWUPHFにはまだほとんど表に出していないが、いま少しずつ公開しているところだ
比較記事に書いてあった懸念のかなりの部分は、私たちがすでに作ってきたcontext infraで扱ってきた内容なので、共感できてうれしかった
それでも重複を減らし、お互いに学んだことを共有する協業はいつでも歓迎だ
協業の機会があればいいと言っていたが、まるで今はその機会がないかのように聞こえて不思議だ
Obsidian vaultにQMDを載せるだけでも80%くらいはいけるし、たぶん2時間もかからない
文脈用にKarpathyの元ポストへのリンクもある
https://x.com/karpathy/status/2039805659525644595
https://xcancel.com/karpathy/status/2039805659525644595
AI Notesが価値を足すのか、それともノイズを作るだけなのか気になる
それでもWebサイトのASCIIスタイルはかなり気に入った
この問題の解決策としては、StackOverflow revivalのようなものを誰かが作ってくれるといいと思う
人間がキュレーションしつつ、集団的なLLMたちが問題を解いていて行き詰まったら、昔ながらのやり方で質問を投稿する分散知識グラフになればいい
自分のエージェントが「ここで詰まったので、SOに質問を投稿しておいた。回答が付いたら後でまた戻ろう」と言っても十分ありだと思う
どうすればLLMが書きすぎないようにできるのか気になる
似たようなツールやシステムをいくつか作ってみたが、どれもLLMが文書をどんどん膨らませて、最終的にはシステム全体が台無しになり、大きくなるほど役に立たなくなった
以前やった実験の一つは、リンクをいくつか渡すとLLMが関連トピックを調べ、自分のknowledge wikiを作って各ページに要約と相互リンク、出典を整理するというものだった
見た目は良さそうだったが、実際のデータを読むといまいちだった
数年前の実験なので、今ならopus 4.7のようなものでやり直す価値はあるかもしれない
話の種として言うと、TiddlyWikiコミュニティも当然AIツールを探ってきた
TiddlyWikiは自己改変可能な単一HTMLファイルベースのWikiで、20年以上続いている
必ずしもagenticな環境へ発展したわけではないが、markdownプラグインもあり、ファイルを実行可能にしたりself-servingなWebアプリに変えたりするツールもある。Gitはやや扱いづらい
だから理論上は、単一ファイルのagentic wikiが持ち運ばれながら自分自身を編集することも可能だ
https://tiddlywiki.com/
あなたが言うsingle-file構成にはすでに複数のLLMコネクタがある。たとえば https://github.com/rimir-cc/tw-llm-connect
魅力もまさにその点にある。依存関係もなく、インストールも不要で、保管も非常に簡単なので、単一ファイルのagentic wikiが自分で編集する構成は今日この場でも可能だ
KarpathyのLLM Wikiパターンにより近いものとして、私が取り組んでいるtwillmもある
https://github.com/Jermolene/twillm
これはTiddlyWikiのNode.js構成を使い、tiddlerを個別ファイルとして保存するので、既存のMarkdown vaultをそのまま参照し、Claude Codeのようなツールと一緒に使える
TiddlyWikiの利点もかなり明確だ。オープンソースなので長期的に使い続けられ、Webベースなのでどこからでもアクセスできる
また計算ビューがmaterialized indexファイルを置き換える。Karpathy方式では、LLMがノートを追加するたびにindex.mdを同期し続ける必要があるが、こういうものはセッションが変わるほどstaleになりやすく、LLMが特に苦手な作業だ
一方、TiddlyWikiのビューはリアルタイムのフィルタ式なので、たとえば「conceptタグの付いたtiddlerをrating順に並べる」といった結果をレンダリング時にその場で計算する
Frontmatterもクエリ可能な構造になる。ObsidianはYAML frontmatterをノート上部のボックス型メタデータとして見せるが、TiddlyWikiはそのフィールドを第一級のtiddlerフィールドに引き上げ、フィルタリング、ソート、集計にすぐ使える
さらにLLMは単にコンテンツだけでなく、小さなアプレットも書ける。Markdownノートだけでなく、wikitext tiddler(.tid)を入れて、ダッシュボード、タグ探索ツール、ジャーナルインデックス、用語集のようなインタラクティブなライブビューを作ることもできる
self building artefactsの領域は面白く、最近はLLM、特にコーディング系モデルがこちらに急速に強くなってきたことで大きく伸びている
私も最近、依存関係を最小化し、ローカルでエージェントを制御することに焦点を当てたプロジェクトを試していた
https://github.com/GistNoesis/Shoggoth.db/
プロンプトで与えた長期タスクを実行するために、自分でsqliteデータベースを作って整理し、ソースデータにはローカルのWikipediaコピーを使う
エージェントのdriftを試すためのハーネスとツールもごく最小限だけ入れてある
画像処理ツールをつなぐのも比較的簡単だ。画像をbase64でエンコードしてllama.cppに渡せばよく、細かな実装はローカルLLMで適当にvibecodingしてもよい
かなり汎用的に役立つツールだと思う
たとえば以前は、フォルダ内の請求書や領収書から金額、日付、販売元を抽出するためにAmazon Textractを使うスクリプトがあり、その後で数字を人間が確認して会計士に渡すCSVを作っていた
今ならそのAmazon Textract呼び出しを、適切なプロンプトを与えたllama.cppモデル呼び出しに置き換えられるし、既存の請求書ツールもそのまま生かしつつ、もっと創造的な会計処理までできるようになった
また、カメラ画像シーケンスで物理ロボットを動かす派生形も試したが、単純なケースでは実際に動いて目標に到達した
ただし私が使っているLLMはもともとロボット操縦用に訓練されておらず、次の行動を選ぶのに10秒もかかるので実用的ではなかった。現在の非ディープラーニング系の従来制御器はビジョンループを20Hzで回している
LLMモデルとその上のエージェントは決定論的ではなく確率的だ
何かを一定の確率ではやり遂げるが、毎回成功するわけではない
だからエージェントが一つの作業を長く引っ張るほど、失敗確率も上がり続ける。この種の長時間実行エージェントは結局失敗し、その過程でトークンコストも大量に燃やすことになる
LLMエージェントが得意なことの一つは、自分の指示文を書き直すことだ
コツはthinkingモデルの時間と思考ステップを制限したうえで、評価し、更新し、再実行することにある
たとえるなら、エージェントは転ぶものだと考えればいい。長く走らせて転ばせるのではなく、10分を1回より5分を2回の方がいいということだ
数週間もすれば、こうした自己参照エージェントがみんなTwitterフィード上部を埋めるようになるだろう
だからこの種のWikiも、ある状態に達するとそこで止まってしまう可能性が高い