Agent-native Wiki：Yopedia 嘅 6 個 specialist agent 點樣取代 Confluence

你間公司用緊 Confluence 做 knowledge base，但有幾多人真心覺得好用？搜索永遠搵唔到想要嘅嘢，page 過咗三個月就變 digital landfill，最後大家寧願直接 DM 同事都唔開個 wiki。問題唔係 Confluence 唔好——問題係傳統 wiki 嘅設計假設已經過期。

過去兩年，大部分「AI + knowledge base」產品嘅做法係 RAG：你問一條問題，system 去 vector DB 搵相關 chunk，然後 LLM 即場砌個答案出嚟。聽落好聰明，但實戰過就知有 fundamental limitation——RAG 每次 query 都係重新推導，冇累積、冇迭代、冇辦法 distinguish between 「呢個答案係咪已驗證」。同一條問題問十次，十次都可能唔同答案。唔係 knowledge base，係一個識打字嘅搜尋引擎。

Yopedia 行另一條路。佢嘅設計哲學好簡單但 radical：wiki 唔應該只係俾人睇，應該同時係俾 AI agent 讀同寫嘅 knowledge substrate。六個 specialist agent 各自有明確職責，通過 GitHub Issues 溝通，形成一條 self-healing pipeline。

六個 agent 點樣分工——唔係 prompt engineering，係 system design

Yopedia 唔係一個 monolithic AI 幫你做晒所有嘢。佢拆成六個 agent，每個只有一個 job，各自有獨立嘅 judgment 同 taste：

Research Agent（每週日 9am 跑）——掃 competitor 動態同 field 上嘅新嘢，filter signal from noise。佢唔係「幫你搵資料」，而係判斷「呢樣嘢值唔值得改變我哋嘅 strategy」。每週最多開 3 個 issue，確保 quality over quantity。

PM Agent（每日 6am 跑）——讀 vision document、assess product gaps、決定下一步要做咩。最得意嘅係佢會 challenge 自己嘅 premise——如果冇 compelling reason，佢會 file 0 issues。呢個 restraint 比好多真人 PM 仲 disciplined。

Office Hour Agent（每日 7am + on issue open）——triage 所有 incoming issues。簡單嘅打 [ready] label，複雜嘅轉俾 Architect，垃圾嘢直接 close。佢有一套 taste filter：forcing questions、banned phrases、push-back patterns——好似一個有經驗嘅 engineering manager 喺度 gatekeep 緊 backlog。

Build Agent（on [ready] label + 每 4 小時）——真係寫 code 嘅 agent。Claim issue、implement solution、開 PR。佢有 minimize correct changes 嘅原則——唔會 over-engineer，唔會 refactor 無關嘅嘢。build fail 會有自動 retry（最多 5 次），仍然 fail 就 auto-revert + 開 [help-wanted]。

Review Agent（on PR opened）——code review。唔係剩係睇 syntax，而係 assess acceptance criteria、confidence scoring。pass 就 merge，fail 就 request changes。佢知道咩嘢值得 flag、咩嘢唔應該 flag——呢個 judgment 好多真人 reviewer 都做唔到。

Architect Agent（on [help-wanted] + 每日 8am）——拆解複雜問題。當 Build Agent 搞唔掂，Architect 會 read codebase、design plan、將大問題 split 成 atomic sub-issues。佢係個救火隊，亦係個架構師。

呢個分工嘅核心 insight：你唔可以俾一個 agent 做晒所有嘢。Single agent 嘅天花板好低——context window 有限、consistency 隨住 complexity 上升而下降。Specialist agent + shared communication bus（GitHub Issues）係目前見到最 scalable 嘅 pattern。

Accumulate，唔係 re-derive——點解 RAG 嘅 recall ceiling 係死症

Yopedia 最 radical 嘅 claim 係：Not RAG。唔係 marketing bullshit，而係 architecture-level 嘅決定。

RAG 嘅根本問題：每次 query 都係從 raw chunks「即場推導」答案。呢個設計假設係「knowledge 係 static 嘅、retrieval 係 reliable 嘅」——但現實中兩個 assumption 都錯。Knowledge 會過期、chunking 會 loss information、retrieval 會有 false positives。結果就係同樣嘅問題，今日問同聽日問可能得到唔同答案。你唔可以 trust 一個 RAG system 俾 consistently correct 嘅答案。

Yopedia 嘅 approach 係累積式知識庫：

• Pages 會更新——唔係 overwrite，而係保留 lineage，每個 page 有 confidence score 同 expiry date
• 矛盾會 reconcil——Talk pages 用嚟處理 contradictory claims，唔係 side-by-side 擺喺度就算
• 過期會 decay——Staleness 係 visible signal，令你可以判斷答案嘅 reliability
• Source 有 citation——每個 claim 都 traceable back to original source，唔係 black box generation

呢個 pattern 嘅靈感來自 Karpathy 嘅 LLM Wiki pattern——wiki 作為 persistent knowledge artifact，而唔係 ephemeral query response。Yopedia 將呢個 concept 推前一步：non-human 都可以貢獻、edit、maintain 呢個知識庫。

仲有一個好重要嘅細節：agent 之間嘅溝通係 persistent 嘅。Yopedia 有 .yoyo/journal.md 記錄每次 session 發生過咩事，.yoyo/learnings.md 記錄 agent 學到嘅嘢。呢啲 meta-knowledge 係 agent 可以 cross-session 累積經驗嘅關鍵——下次 session 唔係從零開始，而係 carry forward 之前嘅 context。呢個先係真正嘅「learning system」。

由 Karpathy 嘅 gist 到 54,300 lines codebase——zero human code 係點做到

呢個 project 嘅 origin story 本身已經值得寫。佢哋攞住 Karpathy 嘅 LLM Wiki gist（一個 single markdown file），丟俾一個 AI agent，話「build this」。55 個 session 之後——54,300+ lines code、1,986 tests、32 API routes、full-stack Next.js app、Dark mode、Docker、CLI、graph view——全部 agent 自己寫嘅。

關鍵係個 harness，唔係 LLM。Yopedia 嘅 harness（base on yoyo-evolve）有幾個 design decisions 值得 reference：

• Random boundary nonces 防止 prompt injection——public repo 任何人都可以開 issue，harness 用 nonce 確保 agent 處理嘅確實係 legit content
• Author allowlist——只有 approved users 嘅 issue 先會 processing
• Protected files——immutable 嘅 founding prompt 同 vision document，agent 冇得改
• Automatic revert——build fail 超過 threshold 就 auto-revert，唔會累積 bad state
• Build + lint + tests + independent eval agent——verification 唔係「looks good to me」，而係全自動 CI/CD

呢個 system 嘅 elegance 係：LLM is powerful but unreliable, the shell script is dumb but consistent. Trust the shell script.

香港做 SaaS 嘅 developers，仲有 startup founders，應該認真諗下呢個 pattern 點樣 apply 落自己嘅 product。而家用緊 Confluence / Notion 做 knowledge base 嘅，可以考慮 clone Yopedia、run local、connect 你嘅 LLM API key，然後睇下 agent 自動幫你 build 出咩嚟。唔係「AI assistant」，係一個 autonomous knowledge worker——呢個先係 agent-native 嘅未來。

行動點：Star Yopedia repo、clone 落嚟 run pnpm dev、開一個 issue 睇下 office-hour agent 點樣 triage。唔好再等 AI 幫你 search Confluence，開始用 AI 幫你 build 一個真正會成長嘅 knowledge base。

Actual code speaks louder than pitch decks.