Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

amem 競品掃描 — 最接近的對手是誰

研究日期：2026-08-11。唯讀研究，未修改任何 project repo。 方法：先讀 amem 自家 SPEC/RFC/design 與 ~/.amem/wiki/ 實際產出，再做廣掃，再對前三名做原始碼層級驗證。 llm_wiki 與 llm_wiki_skill 已 clone 至本 scratchpad 逐檔查核。

0. 結論先講

最接近的競品是 LLM Wiki（nashsu/llm_wiki）。

它不是「同類產品」，而是同一張架構圖的另一個實作：Chrome MV3 clipper 抓當前分頁 → 本機 Rust daemon 用 LLM 兩段式摘要 → 寫成 Obsidian 相容的 markdown wiki → 內建 MCP server 讓 frontier model 取用並附引用。amem 的 SPEC「Mental model」四層，它四層都有。

更關鍵的是兩者同源。amem SPEC 的 storage layout 寫「wiki/ # compiled wiki notes (Karpathy style, agent-friendly chunks)」；llm_wiki 的 README 首段就寫「This project is based on Karpathy’s LLM Wiki pattern」。兩個產品在讀同一份 gist。這不是巧合式撞車，是同一個公開設計模式的兩個實作，而對方已經做到 16,173 stars。

前一份 OpenWiki 研究漏掉它，是因為那份研究從「interop 對象」出發，掃的是 LangChain 生態。llm_wiki 不在那條線上，它在 Karpathy gist 那條線上——也就是 amem 自己站的那條線。

1. 為什麼是它：逐項對照 amem 的 Mental model

以下每一列都經我親自 clone 原始碼查核，非讀行銷文案。

amem SPEC 的層amem 現況llm_wiki 現況證據
Clipper（Chrome MV3 web sensor）有有，MV3，activeTab+scripting+Readability.js+Turndown.js，Alt+Shift+Lextension/manifest.json、extension/clipper-core.js
本機 daemon（Rust）amem-librarian（Rust）有，Tauri v2 Rust backend，本機 HTTP API 127.0.0.1:19827（clip）與 :19828（API）src-tauri/、mcp-server/README.md
AI 摘要編譯成 wiki有有，two-step chain-of-thought ingest（先分析再生成）README「3. Two-Step Chain-of-Thought Ingest」
Obsidian 相容 markdown有（扁平 ~/.amem/wiki/）有，而且更完整——自動產生 .obsidian/ 設定README:79「the wiki directory works as an Obsidian vault」、README:370
MCP 供 frontier model 取用有（amem_recall/amem_cite/amem_ground…）有，bundled MCP server，10 個 toolmcp-server/src/index.ts
附引用的 grounded recallamem_ground 回傳 hits + inline_md有，[1] [2] 編號引用 + Cited references panel + 引用持久化README:229、README:242-243
來源可追溯frontmatter url有，每頁 frontmatter sources: [] 指回 raw 檔README:132
Raw 原件保留~/.amem/raw/有，raw/sources/ 明訂 immutableREADME 目錄結構
index.md / log.mdSPEC 承諾但檔案不存在有，wiki/index.md + wiki/log.md 皆已實作README 目錄結構
蒸餾成 Claude skill（RFC-007）未實作部分——見 §3，這格要講精確llm_wiki_skill/SKILL.md
iOS sensoramem-pockist（TestFlight）無全 repo 無 mobile
fact-checkRFC-003 規劃中無全 repo 無 claim verification

成熟度：16,173 stars、1,918 forks，建立於 2026-04-08（僅 4 個月），最新 v0.6.8（2026-08-08），最後 push 2026-08-10，GPL-3.0（LICENSE 檔為 GPL v3 全文，作者 Yong Su；GitHub API 因檔頭多一行版權宣告而回 NOASSERTION）。桌面三平台 macOS / Windows / Linux。作者 nash_su。

四個月 16k stars，代表這個方向的市場需求已被驗證，也代表時間視窗正在關閉。

2. Top 6 競品對照表

軸線取「真正決定重疊度」的九項。「登入頁」欄位特別標註推論與明文的差別。

LLM WikiSiYuanObsidian Clipper（+社群 MCP）Karakeepbasic-memorySurfSense
Capture 面Chrome MV3，抓當前分頁 DOM官方 Chrome/Edge extensionChrome/Firefox/Safari（含 iOS/iPadOS）Chrome/Firefox/Safari + iOS/Android app無Chrome extension
登入頁結構上可（讀 live DOM），官方未明文同上，未明文同上，未明文同上，未明文—舊 README 宣稱可抓 authenticated，現行 docs 已無此頁（404），無法驗證
抓自己的 AI 對話無專用支援無無官方 template無—無
Mobile share sheet無iOS/Android/HarmonyOS appSafari extension，非 share sheet有無無
儲存本機 markdown 檔.sy JSON（非 plain md）本機 markdown 檔SQLite/Postgres + assets本機 markdown 檔server 端 DB
Obsidian 相容是，自動產 .obsidian/否（僅單向匯入/匯出）原生否是否
誰消費agent（MCP）+ 桌面 UIagent（MCP）+ UI人（vault）／agent 靠第三方 MCPagent（MCP）+ UIagent 為主agent（MCP）+ web UI
MCPserve（10 tools，內建）serve + consume（官方，30+ tools）官方無；社群 mcp-obsidian 4,287★serve（官方 @karakeep/mcp）serve（原生，20+ tools）serve
Provenancesources: [] + raw immutable + [1] 引用clipper 寫入原始 URL + 時間戳frontmatter 有 source URL/author/datemonolith 全頁存檔（verbatim 最強）無 source 追蹤引用式回答
內容 hash僅圖片去重用 sha2，非 provenance無無無無無
Fact-check無無（web_search 是查資料非驗證）無無無無
Skill 迴路消費 skill（/skill）+ 官方 access skill消費 skill（SKILL.md 機制）無無無無
LicenseGPL-3.0AGPL-3.0MITAGPL-3.0AGPL-3.0未在 README 明示
平台mac/Win/Linux 桌面桌面+行動+Docker瀏覽器自架+行動CLI/MCPDocker 自架+雲
商業模式免費 OSSFree / $64 買斷 / $148 年App 個人免費；Sync $4/mo免費自架本機免費；雲端 $15/mo自架免費；雲 PAYG
成熟度16,173★，4 個月，v0.6.8 (2026-08-08)45,733★，v3.7.3 (2026-07-21)4,993★，1.7.1 (2026-07-22)28,249★，v0.33.1 (2026-08-01)3,627★，v0.22.1 (2026-06-13)15,876★，v0.0.36 (2026-08-06)，自陳未達 production

star / release 數據以 GitHub REST API 於 2026-08-11 查核。

表格讀出來的三件事：

  1. MCP 不再是差異點。 六家有五家 serve MCP，SiYuan 甚至雙向。amem 把「MCP 存取層」當賣點已經失效。
  2. 「本機 markdown + agent 可讀」也不再是差異點。 llm_wiki、basic-memory、Obsidian 生態都做到了。更要命的是 Claude Code 自己的 auto memory 就寫在 ~/.claude/projects/<project>/memory/ 的明文 markdown，是免費預設值。
  3. 內容 hash 與 fact-check 兩格全業界皆空。 這是 amem 唯一真正無人佔領的象限——但見 §4，amem 自己也還沒真的佔住。

3. 對 LLM Wiki 的攻防拆解

3.1 幾乎完全重疊的部分

  • capture 機制一模一樣。 兩者都是 MV3 extension 在使用者真實 session 讀 live DOM，經 Readability 抽取後 POST 到 localhost 的本機 daemon。amem 用 :7601，llm_wiki 用 :19827。連「登入頁能不能抓」的答案都一樣：結構上可以，因為 content script 跑在使用者已登入的分頁裡。
  • compile 目標一模一樣。 LLM 摘要 → Obsidian 相容 markdown wiki → wikilink 知識圖譜。
  • agent 取用方式一模一樣。 本機 HTTP API 包一層 MCP server 給 Claude Code / Codex。
  • 知識來源三層架構一模一樣。 raw immutable → wiki → schema，因為都照 Karpathy gist。

3.2 amem 真正領先的地方

（a）iOS sensor。 llm_wiki 完全沒有行動端。amem-pockist 已上 TestFlight。share sheet 是行動端唯一低摩擦的捕捉入口，這格對方短期補不上（要做原生 app + 一套同步）。

（b）登入頁與自有 AI 對話是「明講的產品主張」而非副作用。 兩邊技術上都能抓登入頁，但 llm_wiki 從未把它寫成賣點，也沒有 per-site recipe。amem 的 design memo（2026-07-31）已經把 per-site recipe 定為要建的東西，且 ~/.amem/wiki/ 裡真的躺著 Gmail 搜尋結果頁與 Zulip 登入牆後的 capture。把「別人抓不到的頁面」做成明確能力，是 llm_wiki 沒佔的位置。

（c）chunk 級 SHA-256 + 格式化 citation。 llm_wiki 的 sha2 依 src-tauri/Cargo.toml 註解明寫是「for the dedup cache (Phase 3) — same image hash」，只用於圖片去重；agent workspace 追蹤用的是非密碼學的 DefaultHasher。amem 的 cite.rs 有 text_sha256 per chunk、pdf_sha256，並輸出 APA/MLA/Chicago/IEEE/BibTeX。全業界只有 amem 做這件事——但只在 PDF/arxiv 路徑上，見 §4。

（d）fact-check 是規劃中的產品核心。 llm_wiki 只有 Read Sources Only（限縮回答來源）與人工 Review 佇列，沒有對外部 trust list 驗證 claim 的機制。全掃描 18+ 個標的皆無。

（e）分發成熟度（潛在）。 llm_wiki 的 extension 沒有上 Chrome Web Store，README 只教 chrome://extensions → Developer mode → Load unpacked。對非開發者是硬門檻。但這一格 amem 目前也還沒兌現——amem-clipper（id jgknnaaaobkdggmjhhbklagidilmadii）CWS 查詢顯示 crx 0.3.0、無 published version、in review。要贏這格得先真的上架。

3.3 LLM Wiki 領先的地方

（a）規模與動能。 16,173★ / 1,918 forks / 4 個月 / 每兩天一個 build。amem 是單人私有 repo。這是最大的落差，且會自我強化。

（b）多格式 ingest 遠勝。 PDF（含 MinerU）、DOCX、PPTX、XLSX、EPUB/MOBI、影音、圖片 vision caption。amem 只有 web clip 與 PDF。

（c）wiki 維護機制成熟。 index.md / log.md / overview.md / Lint / Review 佇列 / cascade 刪除（含 dead wikilink 清理）/ 4-signal 知識圖譜 + Louvain 分群。amem 的 ## Connections 至今是空的（節點裡還留著 <!-- amem-clipper v0.2 leaves this empty --> 註解），SPEC 承諾的 index.md 也不存在。

（d）Deep Research 迴路。 偵測知識缺口 → 自動 web search（Tavily/SerpApi/SearXNG）→ 合成新 wiki 頁 → 自動 ingest。amem 沒有主動補洞能力。

（e）purpose.md。 讓使用者宣告「這個 wiki 為什麼存在」，LLM 每次 ingest/query 都讀。這是把使用者意圖變成可執行 context 的簡單好設計，amem 沒有對應物。

（f）scenario templates。 Research / Reading / Personal Growth / Business 各自預設 purpose.md 與 schema.md，降低冷啟動成本。

3.4 一個必須修正的 amem 內部說法

RFC-007 寫：「Every clipper competitor (Obsidian Web Clipper, Readwise, Notion) stops at storage; nobody closes the loop into agent capability. Step 3 is the moat.」

這句話現在有一半是錯的，需要改。

llm_wiki 已經把迴路收到 agent capability：MCP server + 官方發布的 llm_wiki_skill，npx skills add 一鍵裝進 Claude Code / Codex。所以「沒人閉環到 agent capability」不成立。

但精確地看，amem 的主張仍然活著，只是範圍小得多。 我逐字讀了 llm_wiki_skill/SKILL.md：它是人手寫的、唯讀的存取型 skill，內容是「怎麼呼叫 127.0.0.1:19828 的 API」，frontmatter 的 description 甚至明訂「DO NOT trigger on generic ‘search my notes’」。它讓 agent 讀 wiki，不是把 wiki 內容編譯成新 skill。llm_wiki 的「Agent Skills」功能同樣是掃描並啟用既有 SKILL.md——消費 skill，不生產 skill。

所以 RFC-007 該改成這樣：閉環到 agent 存取（MCP + access skill）已是紅海；把重複出現的程序性 capture 叢集自動編譯成新的 SKILL.md，目前仍無人做。moat 不是「step 3」整段，而是 step 3 裡的「自動生成」那半段。這個修正很重要，因為前者站不住，後者站得住。

3.5 amem 該怎麼做

定位語言

  • 停用「local-first markdown wiki for agents」這類描述。llm_wiki、basic-memory、Obsidian 生態、Claude Code 內建 memory 全都符合這句話。
  • 改押兩件別人結構上做不到或沒做的事：（1）別人抓不到的頁面（登入牆後、自己的 AI 對話、行動端 share sheet）；（2）記憶可被稽核（chunk hash + verbatim + 格式化引用 + fact-check）。
  • 「sensor」這個字要繼續用，而且要講滿。競品的入口是「你手動匯入的文件」，amem 的入口是「你本來就在讀的東西」。這是敘事上的真差異。

table-stakes 但目前缺席，必須補

  1. ~/.amem/index.md 與 log.md。SPEC 已承諾、對手已實作、與任何 interop 決策無關。前一份 OpenWiki 研究的 §9.1 已經給了可直接移植的演算法。
  2. ## Connections 真的填上 wikilink。空的 Connections 讓 wiki 退化成一堆孤立檔案，知識圖譜是這個品類的基本盤。
  3. Lint / health 這類 wiki 維護迴路。
  4. 把 amem-clipper 真的推上 CWS。這是對 llm_wiki 少數幾個可立即兌現的優勢，卡在 review 就等於沒有。

不要做的事

  • 不要追多格式 ingest 與知識圖譜視覺化的 parity。那是 llm_wiki 有 60 個貢獻者級動能的地方，單人追不上，且不是 amem 贏的理由。
  • 不要把 MCP 當賣點寫在 landing page 第一屏。

4. amem 最沒防守的一塊

「verbatim archive + SHA-256 provenance」這個差異化主張，在實際出貨的路徑上不存在。

這是本次掃描對 amem 最不利、也最該立刻處理的發現。三個獨立證據：

  1. ~/.amem/wiki/ 34 個檔案中，32 個沒有任何內容 hash。 只有兩個 legacy PDF 節點（1776567380_vaswani2017attention.md、1776825486_belrose2023eliciting.md）帶 pdf_sha256 與 per-chunk sha256:。所有 url:* clipper 節點都沒有。
  2. clipper 路徑的 SHA-256 是拿來算 ID，不是算內容。 amem-librarian/src/clipper_bridge.rs 的 sha12() 把正規化後的 URL 做 SHA-256 再截前 12 個 hex，產出 url:d5ffad083d4a 這種節點 id。內容本身從未被 hash。
  3. amem_ground 不是 fact-check。 讀 src/mcp/mod.rs:172 的 tool description，它是「search the local wiki for the topic and return JSON hits」——對自有 wiki 的檢索加引用。SPEC 定義的核心差異化 amem_factcheck（recall + 撥出去打 trust list + 驗證）仍是 RFC-003 規劃中。

也就是說：對外講的兩個核心差異（可驗證的 provenance、fact-check），一個只存在於非主力的 PDF 路徑，一個還沒開始。而主力路徑正是 clipper——它產出 32/34 的節點，是整個產品的入口。

附帶的品質風險：clipper 節點的 ## Content 雖然是 verbatim，但實測是未經整理的 DOM 傾印。url:e55e42200ccb.md（Gmail）裡是大段錯亂的表格標記與 ![](images/cleardot.gif)。llm_wiki 用 Readability + Turndown 做過一輪清洗。「verbatim archive」若拿不出乾淨可引用的文字，對 fact-check 也撐不起來。

優先修的順序很清楚：先讓 clipper 節點帶 chunk 級 SHA-256 與乾淨的 verbatim 文字，再談 fact-check。 沒有前者，amem_factcheck 沒有可驗證的底層資料可站。這是整個 amem 論述的地基，而地基目前只鋪在 2/34 的面積上。

5. 亞軍與其他值得記錄的

SiYuan（45,733★, AGPL-3.0） — 功能面最完整的對手：官方 clipper（寫入原始 URL + 時間戳）、官方 MCP 雙向、AI Agent、SKILL.md 機制、三大行動平台官方 app。輸在資料主權敘事：.sy 是 JSON 不是 plain markdown，且非 Obsidian 相容，要匯出才拿得回來。amem 在「檔案就是你的」這點上贏它。

Obsidian Web Clipper（4,993★, MIT）+ 社群 mcp-obsidian（4,287★） — 「組裝出來的 amem」。官方 clipper 已有依網站自動套用 template 的機制，也就是 per-site recipe 概念已經存在於出貨產品裡。缺的是中間層：沒有常駐 daemon、沒有 AI 摘要編譯、沒有 provenance 層，且 capture 與 agent 存取由互不相關的專案提供。amem 的機會正是那個中間層。

Karakeep（28,249★, AGPL-3.0） — provenance 的另一種解法，且在「保真」這軸上其實比 amem 強：用 monolith 做全頁存檔對抗 link rot，加 yt-dlp 影片存檔。有官方 MCP、瀏覽器 extension、iOS/Android app。輸在儲存是 DB 不是 markdown，且無 Obsidian、無 agent 導向的 wiki 編譯。若 amem 要講「verbatim archive」，Karakeep 是必須被比較的對象。

basic-memory（3,627★, AGPL-3.0） — MCP 原生 + 本機 markdown + Obsidian 相容，agent-first 程度最高。完全沒有 capture 面，知識靠對話產生。它證明了「MCP + markdown」這半邊已被佔滿。

SurfSense（15,876★） — 曾以「儲存 authenticated 頁面」為 extension 主打，但現行 README 與 docs 已無該頁（/docs/browser-extension 回 404），無法從一手來源證實現況。官方自陳「not yet production-ready」。

Reor（8,573★，2026-03-07 已封存） — 值得引用的死亡案例。它有 local-first + 本機 LLM + 本機 vector DB 的完整組合，死在沒有 capture surface，匯入要人手動拷貝 markdown 進資料夾。這反向支持 amem 押 sensor 的判斷。

平台風險（非競品但更緊迫） — Claude Code auto memory 預設開啟，寫在 ~/.claude/projects/<project>/memory/ 的明文 markdown，使用者可直接編輯。「本機 markdown、agent 自寫、可稽核」已是 Anthropic 免費內建。它唯一缺的是 provenance——只記 modified 時間戳，不記來源。這再次指向同一個結論：amem 只能靠 provenance 與 sensor 活，不能靠儲存格式活。

6. 建議的定位句

amem 記錄你真正讀過的東西——包括登入牆後面那些——並且每一句話都能追回原文。

拆解：「你真正讀過的」＝ sensor（對手要你手動匯入）；「登入牆後面」＝ 結構性優勢，且 llm_wiki 沒佔；「追回原文」＝ provenance 與 fact-check，全業界空白。整句刻意不提 markdown、不提 local-first、不提 MCP——這三個詞現在都無法把 amem 和任何人區分開。

但這句話目前只有前半是真的。 後半要成立，得先讓 clipper 節點帶上內容 hash 與乾淨的 verbatim 文字。在那之前，這是一句願景，不是一句產品描述。

7. 未能驗證的項目

  1. 登入頁擷取能力：llm_wiki、SiYuan、Obsidian Clipper、Karakeep 官方文件皆未明文陳述。本報告全部標為「結構上可推論」，因為 MV3 content script 在使用者已登入的分頁執行。
  2. SurfSense extension 現況：/docs/browser-extension 404，surfsense_browser_extension/README.md 只有 Plasmo 建置指令。「儲存 authenticated 頁面」的說法來自舊版 README 與 fork 快照，無法確認是否仍為現行能力。
  3. llm_wiki 的 GitHub license 欄位回 NOASSERTION，但 LICENSE 檔內容為完整 GPL v3 全文加一行作者版權宣告。以檔案內容為準。
  4. llm_wiki 是否計畫做 mobile 或 fact-check：repo 內無 roadmap 佐證，僅能陳述「目前沒有」。