Show HN: エージェントが管理するKarpathy式LLM wiki（MarkdownとGit）

Apr 25, 2026 · ai devtools web · Source ↗

要約

WUPHFは、複数のエージェント（Claude Code、Codex、OpenClaw）が共同作業するオフィス環境で、型付きfact、エンティティ別ログ、lintスイートを備えたgitネイティブのmarkdown wikiを共有する。

デフォルトのwikiバックエンド（v0.0.6から追加された--memory-backend markdown）は、型付きfactのtriplet、エンティティ別の追記専用ログ、LLMが合成したブリーフを~/.wuphf/wiki/のローカルgitリポジトリに保存する。
エージェントはノートブックからwikiへのプロモーションフローを使用：生のコンテキストはエージェントごとにスコープされ、エージェントが明示的に永続的なfactを共有wikiに昇格させる仕組み。
ターンごとにセッションを新規作成する設計により、Claude API prompt cache hit率97%を達成し、8ターンにわたって累積セッション型オーケストレーターの484kトークンに対してターンあたり約87kトークンの入力を維持。
ロール別のMCPスコーピングにより、DMモードで4ツール、フルオフィスモードで27ツールを読み込み、プロンプトサイズを小さく保ちキャッシュのアライメントを高く維持。
1.0以前の安定性に関する警告：mainは毎日変更される。READMEではフォークをリリースタグに固定するよう明示的に記載。

技術的な主要懸念はプロモーションの品質：必須の人間レビューがなければ、エージェントが書いたwikiエントリは数ヶ月で自信たっぷりな誤情報に劣化し、/lintによる矛盾チェックではどのエントリが間違っているかを確実に検出できない。
複数のコメンターが、24時間以内にHNフロントページにLLM-wikiプロジェクトが3件登場したことを指摘。特定バックエンドへの依存リスクと、エコシステムの断片化リスクが高いとしている。
マルチエージェントの長時間実行に対する反論として、LLMは確率的であるためターンをまたぐたびに失敗確率が複合することが繰り返し挙げられた。推奨パターンは、永続的な共有オフィスではなく、短い有界なrunとevaluate-and-rerunループ。

@Abby_101：プロモーションに人間の承認が必要かエージェントが自己昇格できるかを直接質問。lintが検出できない、自信過剰な誤エントリが6ヶ月で蓄積する具体的シナリオを挙げている。
@dataviz1000：エージェントは自分自身の指示を書くのが得意と主張。thinking stepsを制限し、長時間の連続実行よりevaluate-update-rerunパターンを推奨。