WUPHFのLLM wikiにHN注目、共有記憶より難しいのは信頼
Original: Show HN: A Karpathy-style LLM wiki your agents maintain (Markdown and Git) View original →
HNはWUPHFを単なる multi-agent オフィスの見世物としては受け取らなかった。READMEは「AI社員のためのSlack」のように売り込んでいるが、実際に目を引いたのはその下にある memory 設計だ。各 agent は自分専用の notebook を持ち、チーム全体は共有 wiki を持つ。重要なのは流れである。作業中の観察や仮説は notebook に残し、長く使う価値がある事実や playbook だけを wiki に昇格させる。とにかく溜めるのではなく、何を残すかを選ぶ構造だ。
しかもその共有記憶は、かなり local-first に作られている。新規インストールでは markdown と git ベースの wiki が既定で、保存先は ~/.wuphf/wiki/。README では typed fact、append-only log、lookup、矛盾を洗う lint まで前面に出している。つまり agent memory をベンダーの画面の奥へ隠すのではなく、cat と grep と git log で人間が読める artifact にしようとしている。
HNのコメント欄は、このテーマがなぜ今熱いのかをよく示していた。ある読者は「24時間でフロントページに出た3つ目のLLM wikiだ」と書いた。agent memory が明確な設計競争になっているということだ。その一方で懐疑も強い。そもそもノートを取る行為は、人間が資料を咀嚼して自分の理解へ落とし込む工程なのに、それを自動化して何が残るのかという疑問が出た。さらに鋭かったのは “garbage facts in, garbage briefs out” という指摘で、agent が自分のメモを自分で昇格させるなら、半年後には自信満々で間違った事実が積み上がるのではないかという不安だ。
だからWUPHFが作った会話は、agent を何人並べるかという話ではない。記憶を増やすこと自体はもう難しくない。本当に難しいのは、その記憶をどこまで信じられるかである。WUPHFは chat の残りかすを共有知識へ変える方法をかなり具体的に示し、HNはその有用性と危うさを同時に読んだ。出典は GitHub リポジトリ と HN スレッド。
Related Articles
r/LocalLLaMAが900 points超まで反応した理由はscore表ではない。local coding agentがcanvas bugとwave completion issueを見つけて直したという使用感だった。
OpenAIはCodexを週300万超のdevelopersが使っているとし、desktop appをcode editorの外へ広げた。UpdateにはmacOS background computer use、in-app browser、gpt-image-1.5 image generation、90超のplugins、PR review workflow、SSH devboxes alpha、automations、memory previewが含まれる。
Googleは4月21日、Deep ResearchをGemini 3.1 Proベースへ引き上げ、MCP接続とMaxモードを加えた。Web検索、アップロード済みファイル、ライセンスデータを一つの調査フローにまとめたい金融・ライフサイエンス向けの動きだ。
Comments (0)
No comments yet. Be the first to comment!