每日文摘
深挖 · semantica：12.8k star 的「开源 Palantir」，与 claude-mem、Basic Memory 什么关系
semantica 是一个 12.8k star 的「Graph-Native Infrastructure for Context and Accountable AI Systems」——图原生的上下文与可问责 AI 基础设施，做 LLM、向量库、agent 框架「下方」的那层语义/上下文。它经常被当成「AI 记忆工具」讨论，但如果你手里已经有 claude-mem 和 Basic Memory，先说结论：三者是正交关系，semantica 不是来替代它们任何一个的。这篇把它拆开看清楚：它到底是什么、怎么跑、数据含金量如何、什么场景才轮到它出场。
是什么
官方一句话定位是「LLM、向量库、agent 框架下方的语义/上下文层」，目标用户写在 README 里：做高影响决策 agent 的平台团队、合规/风险/审计团队、受监管行业（金融/医疗/法律/政府/国防）、要自托管的平台工程师。注意这个受众列表——它面向的是企业，不是个人开发者的聊天记忆。
社区给它贴的标签是「The Open Source Palantir for AI Agents」，这不是官方自述，但传得很广。一个值得知道的背景：项目曾用名 Hawksight-AI/semantica（PyPI 0.5.0 的作者字段还是 Hawksight AI），2026 年迁移到 semantica-agi 组织，8 月 9/10 日登上 GitHub Trending #1 后 8 天暴涨约 4,800 star，随后一个月再增约 6,000。当前 12,812 star、MIT 协议。
还有一点容易误解：它不是「agent 记忆框架」起家的项目，而是企业知识图谱 + 治理 + 审计平台。agent 记忆（semantica.context 模块）只是 31 个顶层模块之一。
核心机制（技术）
确定性是它的第一主张：图构建、推理、溯源全程不需要 LLM。实体抽取默认用 spaCy（methods=["spacy"]，另有 rule-based，LLM 是可选项，经 LiteLLM 支持各大厂商）。完整管线是 Sources → Ingest → Parse → Normalize → 实体感知分块 → NER/关系/事件抽取 → 冲突检测 → 去重 → 知识图谱 → 推理/溯源/决策 → 向量库+图库。README 对标向量库的那句话很能说明立场：“conflicts are detected, not silently overwritten”（冲突被检测，而不是被静默覆盖）。
存储是多后端可换的 polyglot 架构：RDF 三元组库（内嵌 Oxigraph、Blazegraph、Jena、RDF4J）+ 属性图（Neo4j、FalkorDB、Neptune、AGE）+ 独立向量层（faiss/qdrant/milvus/pgvector/sqlite 等，含 dense+sparse RRF 融合的 HybridSearch）。内嵌 Oxigraph 意味着零外部服务也能跑。
招牌功能是「决策智能」：每个决策是一等图节点——record_decision() 记录、trace_decision_chain() 追因果链、find_precedents() 找历史先例、check_decision_rules() 查规则，可导出 W3C PROV-O 审计轨迹。再配上 Rete/Datalog/SPARQL 确定性推理引擎（带可解释推理路径）和 bi-temporal 时间旅行（state_at("2024-01-01") 查任意时点快照），这套东西的组合在开源圈确实少见。
但对记忆工具用户，它有三个明确缺口：写入是显式 API 调用（store() 三路 write-through），没有自动挂接会话的采集钩子（plugins 里的 Claude Code hooks 只是开发 semantica 自身用的 lint）；AgentMemory 进程内驻 RAM，不显式 save() 就丢；没有 Letta 式的 sleep-time 后台巩固——worker.py 是个 time.sleep(5) 的空壳轮询。
工程质量：实测约 34.5 万行 Python、816 个文件、31 个模块目录、360 个测试文件、2,925 commits、11 个 CI workflow（codeql/Trivy/OpenSSF scorecard）。架子正规，但仍是 v0.x（最新 0.6.8，1-2 周一版），功能广度明显跑在质量前面——评测一节会展开。
怎么跑起来（环境）
门槛比它 34.5 万行的体量听起来低得多：
- 安装：
pip install semantica（核心自称 22 个必备依赖），细分 extras 按需加（[graph-neo4j]、[llm-ollama]、[gpu]等）。零强制外部服务：内嵌 Oxigraph + FAISS/SQLite 向量 + JSON 图就能跑。 - LLM key 可选：FAQ 原话 “pattern extraction works with no keys”。Ollama 免 key（base_url 直连），本地 embedding 走 sentence-transformers/fastembed——存在一条全本地、零 API 成本的完整链路。MIT 协议无付费墙，企业版（on-prem/SLA）定价未公开。
- 硬件：无 GPU 要求。官方性能基准就是纯 CPU 跑的（AMD EPYC + 64GB RAM，11.8 万节点图）。GPU 只用于自动加速 embedding/ML——对有 3090 的用户这属于过剩配置，本地 LLM 需求由 Ollama 独立承担。
- coding agent 接入：MCP server 一条 stdio JSON 配置即可（
semantica-mcp，15 个工具 + 3 个只读资源，覆盖实体抽取/决策记录/先例检索/图查询），与 Basic Memory 的 MCP 并列注册无冲突；Claude Code/Codex/Cursor/Cline/Windsurf/VS Code 等另有原生插件包（17 skills + 3 agents）。一个已知陷阱：不设SEMANTICA_KG_PATH绝对路径，MCP server 是内存态，重启丢图。 - 数据主权：全部落本地文件（KG JSON、Oxigraph 目录、provenance.db、FAISS 索引），官方声明 “No data is sent to a third-party SaaS”，可导出 Turtle/JSON-LD/Parquet/Cypher 标准格式。
小瑕疵也有：Python 最低版本三处文档不一致（3.8/3.9/3.10），Explorer 端口两说（8000/5174）——v0.x 项目的文档漂移，实操按 3.10–3.12 选。
数据说话（评测）
这部分的结论比前两部分更值得记住：
- 零公开质量基准。全仓库 1,450 个文件里没有任何 LOCOMO 或记忆类基准；README「Performance」只有 11.8 万节点图的自报微基准（节点搜索 24ms→0.004ms 等），且 README 自己承认部分数字来自 CHANGELOG 历史测量、“production graph” 数据集不公开。它以「Palantir/审计治理」定位完全绕开了 mem0/Zep 打得头破血流的记忆评测赛道。
- 零独立实测。HN 全部 4 帖最高 12 分且 0 评论（其中两帖是创始人自投）；r/LocalLLaMA、r/ClaudeAI 没有实测专帖；中文/聚合站报道基本是转抄 star 数的内容农场。没有找到任何第三方独立复现。
- 星数结构耐人寻味：watcher 仅 67（star 数的 0.5%）、PyPI 月下载 2.2 万——「收藏远多于使用」。没有买星的直接证据（issue 区 0 条指控），但一年慢烧仅 1.3k star、改名换话术后 8 天 +4.8k，issue 区还有申请列入 Qdrant/Milvus/Agno 上游目录的营销任务，增长运营痕迹明显。
- 旗舰功能存在「一用就坏」级 open bug（bug 标签 17 条）：#1140
find_precedents()永远返回空列表（先例检索是核心卖点）；#1247query_decisions的过滤把所有结果滤掉；get_provenance因 schema 与 handler 字段不一致，符合 schema 的调用全部失败；check_compliance()内部出错时静默返回 False。bug 直指 provenance/compliance/decision 三大营销卖点。 - 安全面一好一坏：好的一面是 1 条 high 级 SSRF advisory（GHSA-8c7v-62gr-hj6g，匿名可读云凭据）在 v0.6.5 规范修复并附 12 个网络测试（顺带辟谣：传闻「修复了 6 个漏洞」不实，advisory 只有 1 条）；坏的一面是「面向受监管企业」的产品出现无需认证的 SSRF 本身就是硬伤。
- 团队：创始人 Kaif Ahmad 一人贡献约 78% 的 commits（2,022/2,925）；官网无团队页、挂着「Fund Us」募资入口、无投资方披露。早期单人主导 + 正在募资，是判断成熟度时该放进天秤的砝码。
值不值得跟（三种正交形态，别选错赛道）
回到标题的问题。把三者放进一张表：
| 维度 | semantica | claude-mem | Basic Memory |
|---|---|---|---|
| 本质 | 可审计决策图基础设施 | 会话压缩器 | 人机共写本地知识库 |
| 存储 | 图库+向量库+provenance.db | SQLite(FTS5)+Chroma | Markdown 文件真源+SQLite 图谱 |
| 写入 | 显式 API | 全自动 hook | agent 显式写，人随时共编辑 |
| 记忆层 | 结构化决策/实体图 | 会话情景记忆 | 长期语义知识 |
| 人可读 | 弱（靠导出与 Explorer） | 中（web viewer，AI 摘要非逐字） | 强（Obsidian 直读，最 user-owned） |
| 主权 | MIT、自托管 | 本地为主但正推托管化 | AGPL、文件可带走 |
claude-mem 的机制顺带说清：hook 全自动管线——PostToolUse 每次工具调用后捕获（官方称单 session 可达 100+ 次）→ worker 经 AI 压缩提取 → Stop 生成摘要 → 下次 SessionStart 自动注入，检索走三层渐进披露（search→timeline→get_observations）。它解决的是「会话之间失忆」；Basic Memory 解决的是「知识和决策的长期沉淀、人机共编辑」；semantica 解决的是「结构化世界模型 + 每个决策可审计可追溯」。三者恰好覆盖记忆的不同层，重叠比想象中少——专程去找 semantica vs claude-mem 的直接对比文章，一篇都没有。
所以什么时候轮到 semantica 出场？当你需要可审计的决策记录、因果链、provenance、实体消解、时间旅行查询时——典型如受监管行业的合规场景、企业级知识治理、或者想让多个 agent 共享一个结构化事实底座。经 MCP 接入与现有系统并存，成本不高（一条 JSON 配置）。反过来，如果你只是想改善现有记忆体验，它给不了 claude-mem 的自动会话捕获，也给不了 Basic Memory 的人类可读真源，改造成本大于收益。
当下的具体判断：观望或小规模试点，不生产依赖。理由有三条硬的——v0.x 阶段、旗舰功能（先例检索/provenance/合规检查）存在一用就坏的 open bug、零独立实测。另外提一句与本场景相关的风险：claude-mem 的 README 已宣布改名 Grok Mem、安装默认引导托管 observer 登录、还出现了 CMEM 代币段落——作为现有用户，这个生态漂移值得持续盯着。
参考阅读
- semantica README — 本体：定位、管线、性能自述、MCP/插件接入
- semantica ARCHITECTURE.md — Sources→KG→推理/溯源的完整管线图
- AgentMemory Guide — 记忆模块机制：分层、RAM-only、save() 语义
- MCP Server Guide — stdio 接入、15 工具、KG_PATH 陷阱
- Trendshift: semantica — 增长曲线第三方：上榜与引爆时点
- Issue #1140 — 旗舰功能 find_precedents 失效的实证
- claude-mem Architecture Overview — 竞品机制：hook→worker→压缩→注入全链路
- Memory MCP Servers Compared (Mnemoverse) — 同时覆盖 claude-mem 与 basic-memory 的第三方横评