把你的 (k)nowledge 带进 Antigravity

转载说明：本文经作者授权转载自 abn.is，原文发表于 2026 年 7 月 24 日。

作者 Arun 开发了文中介绍的 Google Antigravity 插件，并将其捐赠给 Nowledge Labs。目前项目代码已开源在 nowledge-co/nowledge-mem-google-antigravity。

中文版由 Nowledge Labs 翻译。为了方便阅读，我们在不改变原文技术内容和整体结构的前提下做了少量编辑调整：全文统一以作者第一人称视角展开；将原文提示框调整为引用样式；文中五张图表由原文自己的 Mermaid 源码直接渲染，图中文字因此是页面文本，而不是锁在图片里的像素。

除上述调整外，正文内容、代码和图表均保持原意。

以下内容从作者 Arun 第一视角展开：

在本文我将讲述如何把 Nowledge Mem 接入 Google Antigravity 2.0，并兼顾稳定性、性能和开发者体验。

AI 编程助手很快，也很强，但默认情况下，每次新对话几乎都要从头开始。之前修过哪些 bug、为什么会做出某个架构设计决定、项目里有哪些坑，以及你习惯怎样工作，这些经验并不会自动延续到下一次对话。它们要么留在你的脑子里，要么埋在过去漫长的聊天记录中。

Nowledge Mem 解决的正是这个问题：它为 AI Agent 提供一个持久化的个人知识库，用来保存原子记忆、每日 working memory 简报、长期生效的规则，以及可执行、且能追溯来源依据的 skills。

AI 工具会不断变更，但你的记忆应该持续被积累。Mem 可以让对话、决策，以及 Agent 在工作过程中发现的信息跨工具延续下去。每一次 session 都建立在之前积累的内容之上，同时也会让下一次 session 变得更聪明。

Google 在 Antigravity 2.0 中引入了一套用于自定义 Agent 的 Plugin 架构。在这篇文章里，我会介绍自己如何设计和构建 nowledge-mem-google-antigravity Plugin：一个同时兼顾低延迟、故障恢复，并把关键操作控制权交给开发者的混合集成方案。

GitHub 项目：nowledge-co/nowledge-mem-google-antigravity

1. Nowledge Mem 能带来什么

Nowledge Mem 并不只是一个被动保存日志的地方，而是一个面向 AI Agent 的主动式个人知识引擎。

Nowledge Mem 提供的核心能力包括：

Situational Context Bundles：把当前项目、关注重点以及相关记忆引用整理成一份启动简报（<nowledge_context_bundle>）。
Standing Rules：为所有 Agent 或特定 Agent 设置长期生效的行为规则，比如敏感信息脱敏、Flatpak D-Bus 规则、代码规范等，并自动跨 session 执行。
Compiled Agent Skills：根据真实的历史工作过程整理出可复用的操作流程（SKILL.md bundle），通过测试用例验证，并标记不同的信任等级（Checked 或 Proven）。
Nowledge FS（mem_fs）：一个统一的、以路径为核心的虚拟文件系统，通过 /memories、/threads、/wiki、/skills 等路径浏览整个知识树。

使用本地模型完成知识 Embedding 推理

Nowledge Mem 原生支持本地模型。既可以使用 GPU 或 CPU 运行 embedding 模型，也可以在设备本地完成后台智能任务所需的推理。

我个人使用 Lemonade Server 管理本地模型，同时也会利用 NPU 生成 embedding。Nowledge Mem 直接支持 Lemonade，可以把它作为一个 LLM Provider 来使用。

2. Google Antigravity 2.0 的 Plugin 架构

Google Antigravity 2.0 把 Plugin 定义成带有 namespace 的 package，将 Agent 的各种自定义能力统一放在一个结构中：

nowledge-mem-google-antigravity/
├── plugin.json       # Required manifest
├── mcp_config.json   # MCP Server definitions
├── hooks.json        # PreInvocation, PreToolUse, and Stop lifecycle hooks
├── rules/            # Always-on system rules
│   └── nowledge-mem.md
└── skills/           # Bundled agent skills
    ├── nmem-memory-search/
    ├── nmem-skill-load/
    └── nmem-thread-save/

Antigravity 启动时会扫描两个 Plugin 位置：

Workspace Level：<workspace-root>/.agents/plugins/，只对当前项目生效。
Global Level：~/.gemini/config/plugins/，可以在所有项目中使用。

3. 关键设计决策与架构考量

要把本地或远程知识库连接到自主运行的 Agent Engine，需要在三个工程问题之间做好平衡：

延迟：Hook 必须在毫秒级完成，不能给开发者拖后腿。
稳定性：短暂断网或 Sandbox 限制不能让整个 session 失败，更不能导致数据丢失。
UX 控制：重要的状态变化应该由开发者确认，但又不能让重复弹出的确认 Prompt 不断打断开发者的工作。

下面是我在这些问题上做出的几个核心设计选择。

A. 3 个启动通道：控制 Context 成本

为了减少冷启动时间，同时避免把模型的 Prompt 塞得过满，Plugin 会通过三个互补的通道初始化 Antigravity。

设计考量：按需提供 Context，而不是一次塞满 Prompt

如果把完整的知识图谱全部塞进 system prompt，不仅会迅速占满 context，还会产生额外的 KV cache 成本。

因此，我把启动阶段需要的知识拆成 3 层：

Channel 1（PreInvocation Hook）：只注入当天正在使用的简报，以及直接相关的记忆链接（nowledgemem://memory/<id>）。

Channel 2（Always-On System Rules）：设置持续生效的行为规则。

Channel 3（Available Skills Index）：只提供轻量级 Skill 索引，等当前任务真正需要某个 Skill 时，再读取完整内容。

B. 分层 Transport Access：兼顾性能与 Sandbox 限制

如果后台每执行一次 Hook 都要启动一个 CLI 子进程，单次调用就会额外增加 300～500ms 的延迟。

为了把执行时间控制在 30ms 以内，我在 hooks/nmem_shared.py 中实现了一套三层 Transport 机制。

设计考量：不同环境使用不同访问方式

Tier 1（原生 Python HTTP REST）：使用 Python 自带、无需额外依赖的 urllib.request，直接通过 HTTP 查询 /context、/working-memory 或 /threads/import，耗时低于 30ms。对于远程 Mem endpoint，nmem_shared.py 会自动加入 Authorization: Bearer 和 X-MEM-API-Key header。为什么优先使用原生 HTTP？创建子进程（subprocess.run）本身就会带来较高的系统开销。直接发起 REST 请求，可以把 Hook 延迟从约 400ms 降到 30ms 以下，避免 session 初始化打断开发者的工作流。

Tier 2（Multi-Path System CLI）：如果 HTTP 请求失败，或者确实需要调用本地 CLI 工具，就回退到 nmem。为什么要解析多个路径？在 Sandbox 中运行的工具子 shell（BypassSandbox: false）里，如果用户目录下的符号链接，例如 ~/.local/bin/nmem，指向当前 workspace 之外的位置，它经常会被隐藏或阻止。 nmem_shared.py 会解析符号链接真正指向的位置，同时检查标准的系统 package 路径（/usr/lib/nowledge-mem/nmem、/usr/lib64/nowledge-mem/nmem），确保即使在严格的 Sandbox 环境下也能可靠执行。

Tier 3（Local Buffer Queue）：如果 session 结束时，后端完全不可访问，例如你正在离线使用笔记本电脑，session-end.py 会把 session transcript payload 写入带文件锁的本地离线队列： ~/.nowledge-mem/antigravity_unsynced.json 为什么需要离线队列？ Session 数据和学习计划不应该因为短暂的断网而丢失。重新联网后，后台 retry worker 会自动把队列里的 session 补传回去。

C. 动态同步 MCP 配置：保持 Git 工作区干净

当 Nowledge Mem 运行在远程服务器上，或者运行在 Tailscale 之类的网络里，比如 https://mem.example.com，客户端的 ~/.nowledge-mem/config.json 会保存远程 apiUrl 和 apiKey。

但 Antigravity 的 MCP client 读取的是 mcp_config.json。

如果 mcp_config.json 仍然写死为 http://127.0.0.1:14242，MCP tools 就会直接返回 403 Forbidden。

为了解决这个问题：

Session 启动时，session-start.py 会调用 nmem_shared.sync_mcp_config_file()。
它会解析当前真正应该使用的 URL / Key，优先级为：NMEM_* 环境变量 → ~/.nowledge-mem/config.json → 127.0.0.1:14242。
如果最终指向远程服务器，它会自动更新磁盘上的 mcp_config.json，把 endpoint 改成远程的 /mcp/，同时加入 Authorization: Bearer 和 X-MEM-API-Key header。

json

{
  "mcpServers": {
    "nowledge-mem": {
      "serverUrl": "https://mem.example.com/mcp/",
      "headers": {
        "APP": "Google Antigravity",
        "Authorization": "Bearer nmem_sec_...",
        "X-MEM-API-Key": "nmem_sec_..."
      }
    }
  }
}

设计考量：不要让 Runtime 配置污染 Git

mcp_config.json 已经加入 .gitignore。

开发者和贡献者经常会直接 git clone Plugin 仓库，或者通过 symlink 使用它。如果 session 启动时动态修改 mcp_config.json，让它指向个人的远程 endpoint，就会不断在 git status 里产生无意义的改动。

让 Git 忽略 mcp_config.json 后，本地 runtime 配置可以随时同步，而不会把 working tree 弄脏。

D. 零延迟连接并同步 Host Skills

Nowledge Mem 会在你的服务器上编译并保存 Skills。

为了让当前可用的 Skills 能自动连接到 Antigravity，并持续保持最新，session-start.py 会在 session 启动时创建一个不会阻塞主流程的后台 daemon thread：

python

def sync_host_skills_async():
    # Connect host agent 'antigravity' & refresh client assets
    run_nmem_command(["skills", "connect", "antigravity"])
    run_nmem_command(["skills", "sync"])

设计考量：异步执行，以及如何处理同步尚未完成的情况

为什么放到后台执行？如果启动时同步执行 nmem skills connect 和 nmem skills sync，开发者需要额外等待 1～2 秒的网络往返。把它放进后台 daemon thread 后，session 启动不会因此增加等待时间。

如果 Skill 还没同步完怎么办？如果 Agent 在第一个 turn 就立刻触发某条 Skill 命令，而后台同步线程还没有完成，Plugin 会先读取本地 .agents/skills/ 缓存，或者回退到 REST API 直接获取信息，避免任务被卡住。

E. Thread 尾部增量同步：避免重复并保证数据完整性

一个长时间运行的 Antigravity session 结束时，远端可能已经保存过其中一部分消息。

如果这时候直接把完整 transcript 再追加一遍，就可能产生重复消息。

为了解决这个问题，hooks/session-end.py 使用了 Nowledge Mem 的：

POST /threads/{id}/reconcile-tail

endpoint。

设计考量：只同步发生变化的尾部

对于恢复后继续执行的长对话，或者已经同步过一部分的 transcript，直接追加很容易造成重复。

reconcile-tail 会先把远端已经存在的 messages 和新的 log steps 进行比较，找出前面已经一致的部分，也就是 matched_count，然后只更新后面新增或发生变化的内容。

这样就不需要每次重新写入整个 Thread，也不会因为多次同步产生重复消息。

如果某个离线 session 的 payload 之后才从 antigravity_unsynced.json 重新提交，retry worker 在重新联网后也会使用同样的机制完成同步。

F. 统一的 Skill 命名空间：`nmem-<domain>-<action>`

Plugin 中全部 10 个 Skills 都遵循统一的命名方式：

nmem-<domain>-<action>

skills/
├── nmem-fs-explore/        # Navigation & tree exploration
├── nmem-memory-distill/    # Atomic memory distillation
├── nmem-memory-search/     # Deep & semantic memory recall
├── nmem-memory-working/    # Daily working memory reader
├── nmem-skill-load/        # On-demand skill discovery & injection
├── nmem-skill-manage/      # Workspace skill manager & suggestion engine
├── nmem-skill-propose/     # Authoring & submitting new skills
├── nmem-status/            # Diagnostic connection status
├── nmem-thread-handoff/    # Resumable handoff summaries
└── nmem-thread-save/       # Full transcript importer

这样一来，Skills 在 IDE 自动补全、文件列表和 prompt index 中都会自然聚合在一起，同时也能对应到统一的 slash command，例如：

/nmem-skill-load <query> /nmem-thread-save。

4. 把控制权交给开发者：利用 Antigravity 的交互能力

Plugin 不会要求开发者不断在聊天里输入文字确认，而是尽可能利用 Antigravity 原生提供的交互 UI。

1. 交互式多选 Prompt（`ask_question`）

在发现或安装 Skills（/nmem-skill-manage）时，Agent 会通过 ask_question 展示可勾选的选项，并设置：

is_multi_select: true

同时把推荐项放在前面。

一个交互式多选问题的示例。

2. 待确认的执行计划（`skills_installation_plan.md`）

对于规模较大的 workspace 更新或记忆提炼任务，Plugin 会在下面的位置创建一个结构化 Markdown artifact：

<appDataDir>/brain/<conversation-id>/

并设置：

RequestFeedback: true

# Skill Installation Plan

| Skill ID | Trust Badge | Description | Target Path | Git Strategy |
| :--- | :--- | :--- | :--- | :--- |
| `makefile-pattern` | **Proven** | Makefile standards | `.agents/skills/makefile-pattern/` | Git Exclude |
| `docker-build` | **Checked** | Multi-stage Docker | `.agents/skills/docker-build/` | Committed |

设计考量：哪些 Skills 应该提交到 Git，哪些只留在本地

当用户把 Skill 安装到 workspace：

.agents/skills/<name>/SKILL.md

其中有些 Skills 是团队共同遵循的工作流程，应该提交到 Git；另一些则只是某个开发者自己的个人偏好。

为了避免把个人工作流规则提交到团队仓库，installer script 支持 --ignore 参数。它不会修改 .gitignore，而是把对应条目写入 .git/info/exclude。

带有 Proceed 按钮的 Plan 草稿。

5. 实际使用：动态加载 Skill（`/nmem-skill-load`）

下面看一个实际任务里，Skill 是如何按需发现并加载的。

Ephemeral Mode（临时模式，无需重启）：直接把获取到的 SKILL.md 内容作为结构化 context block（<skill_instruction>）注入当前 turn。 Antigravity 因此可以立即在当前任务中遵循这些专门的指示，不需要把文件写入磁盘，也不需要重启 workspace。
Persistent Mode（持久模式）：把 Skill 写入 .agents/skills/<name>/SKILL.md。如果用户希望这个 Skill 只在本地使用、不跟随仓库提交，还会把 .agents/skills/<name>/ 加入 .git/info/exclude。

在一个新的 session 中动态注入自定义 Makefile Skill。

总结与快速上手

通过把 Google Antigravity 2.0 的 Plugin hooks、Nowledge Mem 的多层 Transport 机制，以及 Antigravity 自身的交互 UI 结合起来，我做出了一套响应快、稳定可靠，同时又把控制权留给开发者的知识集成方案。

快速安装

安装 Plugin：

bash

mkdir -p ~/.gemini/config/plugins/nowledge-mem
curl -sSL https://github.com/nowledge-co/nowledge-mem-google-antigravity/releases/latest/download/nowledge-mem-google-antigravity.tar.gz \
  | tar -xz -C ~/.gemini/config/plugins/nowledge-mem

检查连接

重启 Antigravity，然后运行：

/nmem-status

或者检查：

nmem status

探索知识

使用：

/nmem-memory-search /nmem-skill-manage

或者：

/nmem-skill-load <query>

把你的个人知识库带进 coding workflow。

全局 Plugin Skills，可以在任意 Antigravity 对话中使用。

安装完成后，可以通过检查各项配置以及整个系统是否正常工作。

就这样，你的个人 context、工程知识和规则就被接入了 Agent 开发工作流。随着不断使用，这些知识也会持续积累，并在之后的 session 中被重新利用。

如果你对这篇文章有任何问题或评论，欢迎联系作者。如果你希望更深入地了解 Nowledge Mem 是如何工作的，可以阅读 Nowledge Mem 的相关文章。