KarpathyスタイルのLLM Wikiをエージェントが直接維持するシステム - MarkdownとGitベース
(github.com/nex-crm)- 複数のAIエージェントが同じオフィスで協業するよう構成されており、隠れたAPI呼び出しよりも、ブラウザUIと役割別のチーム編成による可視的な作業フローを前面に出している
- メモリはエージェントごとのnotebookとチーム共有のwikiに分かれており、生の作業コンテキストは個人側に残し、検証済みの事実と繰り返し使うプレイブックだけを共有知識として載せるよう設計されている
- デフォルトのwikiは単なる文書フォルダではなくローカルGitリポジトリとして動作し、typed facts、append-onlyログ、LLM合成brief、
/lookup、/lintのようなファイル優先のツール体系もあわせて提供する - セッションはターンごとに新しく開始され、ツールもエージェントごとに制限される。さらにpush-driven実行モデルとプロンプトキャッシュを組み合わせることで、セッション長に関係なくフラットな入力量を維持するよう調整されている
- Telegram、OpenClaw、One CLI、Composioまで接続して外部メッセージとアクション実行を取り込みつつ、セルフホスト可能なオープンソースと独自のAPIキー利用を前提に、チームメモリとエージェント協業をひとつの場所にまとめている
メモリとWikiの構造
- エージェントごとのnotebookとチーム共有wikiを分離し、個人の作業コンテキストと組織知識を別レイヤーで管理する
- notebookには作業中に得た生のコンテキスト、観察、暫定結論を保存し、繰り返し使うプレイブック・検証済みの事実・確定した嗜好のような長期的な情報だけがwikiへ昇格するよう設計されている
- どの情報も自動では昇格されず、エージェントがnotebookからwikiへ載せる項目を自分で決める
- wikiには最後にそのコンテキストを記録した主体を示す情報が含まれ、ほかのエージェントが誰に再メンションするべきかを判断できる
- 新規インストールでは
markdownバックエンドがデフォルトで、既存のNexまたはGBrainワークスペースは従来の知識グラフバックエンドをそのまま維持する noneバックエンドを選ぶと共有wikiは無効になるが、ローカルnotebookは引き続き動作する
markdown wikiの動作方式
- デフォルトwikiは単なるMarkdownフォルダではなく、ローカルGitリポジトリベースのチームwikiとして動作し、パスは
~/.wuphf/wiki/ - ここにはtriplet形式のtyped facts、エンティティごとのappend-only事実ログ、LLMが合成したbrief、引用ベースの
/lookup、矛盾・孤立文書・古い主張・壊れた相互参照を見つける/lintが含まれる - LLMが合成したbriefは
archivistというアイデンティティでコミットされ、cat、grep、git log、git cloneのようなファイル優先のツール体系をそのまま活用できる - このデフォルトwikiはAPIキーなしで利用できる
- コード内部の命名ではnotebookは
private、wikiはsharedメモリであり、markdownバックエンドとnex・gbrainバックエンドは異なるMCPツールサーフェスを使う markdownバックエンドのツール群とnex・gbrainのレガシーツール群は同じサーバーインスタンス上に共存しない- 関連する詳細文書は
DESIGN-WIKI.md、docs/specs/WIKI-SCHEMA.mdに続く
実行モデルと構成オプション
- デフォルトのエージェントCLIはClaude Codeで、
--provider codexを使えばCodex CLIも選べる - メモリバックエンドは
nex、gbrain、none、デフォルトのmarkdownから選択できる --no-nexを使ってもTelegramのようなローカル連携機能は引き続き動作し、実行後に/focusでCEOルーティング委任モードへ戻せるgbrainを選ぶと初期オンボーディングでOpenAIまたはAnthropicのキーが必要になり、埋め込みとベクトル検索が必要ならOpenAIを使う必要がある- ロールパックとして
starter、founding-team、coding-team、lead-gen-agency、revopsを提供する --opus-ceo、--no-open、--web-port、--unsafeのようなフラグでモデル、ブラウザ自動オープン、ポート、権限チェックを調整できる- リポジトリはpre-1.0の状態で
mainブランチが毎日変わる可能性があるため、フォーク時はmainではなくリリースタグ固定が推奨される
協業と外部連携
- Telegramブリッジをサポートしており、オフィス内で
/connectを実行した後、Telegramを選び、@BotFatherトークンを入れることでグループまたはDMとの双方向メッセージフローを接続できる - OpenClawエージェントも
/connect openclawで取り込め、ゲートウェイURLと~/.openclaw/openclaw.jsonのgateway.auth.tokenを使ってセッションをブリッジする - OpenClawセッションはオフィス内で第一級のメンバーとして参加し、
@mentionできる一方、実際の実行はそれぞれのサンドボックスで継続される - OpenClawゲートウェイ認証にはEd25519キーペアを使い、キーは
~/.wuphf/openclaw/identity.jsonに0600権限で保存される - 外部アクション実行のためにOne CLIとComposioという2つのプロバイダーを内蔵する
- One CLIはローカルバイナリとしてユーザーのマシン上でアクションを実行し、サードパーティへ資格情報を送らないフローに適している
- ComposioはComposioのホスティングOAuthフローでGmail、SlackのようなSaaSアカウントを接続する
設計上の選択と運用特性
- セッションはターンごとに新しく開始され、会話履歴を累積しない構造を採用している
- ツールはエージェントごとにスコープ制限され、DMでは4個のMCPツールのみ、オフィス全体では27個のツールをロードする
- エージェントはbrokerが通知をプッシュしたときだけ起動するpush-drivenモデルのため、heartbeat pollingは不要
- 作業中でも特定のエージェントにDMを送って再起動なしで途中調整できる
- Claude Code、Codex、OpenClawランタイムを1つのチャネルで混在させられる
- メモリはエージェントごとのnotebookとワークスペースwikiを併用し、
GBrainまたはNexの知識グラフベースのメモリも選択可能 - 価格面では、MITライセンス、セルフホスト、独自APIキー利用を組み合わせた無料のオープンソースモデルを打ち出している
- Codexベースの10ターンCEOセッション測定では、入力トークンは1ターンあたり約87kでフラットに維持された
- キャッシュ後の課金トークンは1ターンあたり約40k、10ターン合計は約286kとされる
- Claude APIプロンプトキャッシュ基準で97%のキャッシュヒット率を記録し、Claude Code 5ターンのコストは
$0.06と記されている - 累積セッション型オーケストレーターでは同一セッション内でターンごとの入力が124kから484kへ増える一方、WUPHFはセッション長に関係なくフラットな入力量を維持する
- この差は8ターン基準で7倍差と測定されたと記されている
- こうした特性は、fresh session、同一接頭辞ベースのprompt caching、DMモードの少ないツール数、heartbeat不要のpush-driven wake構造と結び付いている
- 再現スクリプトとしては
wuphf --pack starter &の後に./scripts/benchmark.shが提示され、すべての数値はユーザーのローカル環境とキーで実測されたものとしている
実装状況と検証フロー
- READMEの主要項目ごとにコードパスへ直接リンクしたclaim status表があり、何がshippedで何がpartialかを区別している
- デフォルトCEOがSonnetで
--opus-ceoでアップグレードできる点、collaborative modeのデフォルト、/focus切り替え、per-agent MCP scoping、fresh session、push-driven wake、ワークスペース分離、Telegramブリッジ、2種類のアクションプロバイダー、OpenClawブリッジ、wuphf import、--memory-backend markdownデフォルトはすべてshippedと表示されている - ライブWebエージェントのストリーミングはpartial、goreleaserベースのprebuilt binaryはconfig ready状態と表示されている
- 再起動時の進行中タスク復元は
v0.0.2.0でshippedと記されている - LLM Wikiはgit-nativeなチームメモリとWikipediaスタイルのUIとしてshipped扱いになっており、関連実装位置として
internal/team/wiki_git.go、internal/team/wiki_worker.go、web/src/components/wiki/、DESIGN-WIKI.mdが挙げられている - claimとstatusが衝突する場合はコードが優先であり、問題を見つけたらissueを開くよう案内している
評価とデモ資料
- フォーク前にAIコーディング支援ツールでリポジトリを評価するfork-or-skipプロンプトを提供しており、マーケティング文句なしで、ファイルパス・行番号・判定を500語以内で求めている
- このプロンプトはリリース前にも内部で使っていると記されている
- wikiが実際に書き込まれる流れを示す5分のターミナルデモとして
./scripts/demo-entity-synthesis.shを提示している - このデモではエージェントが5つの事実を記録し、合成しきい値が発動した後、brokerがローカルLLM CLIを呼び出し、その結果が
archivistアイデンティティでGitリポジトリにコミットされ、作成チェーン全体がgit logに残る - デモ要件として、
curl、python3、--memory-backend markdownで実行中のbroker、そしてclaude・codex・openclawのいずれか対応するLLM CLIがPATHにある必要がある
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も、ある状態に達するとそこで止まってしまう可能性が高い